При разработке подсистемы контроля качества в 1С:ERP перед программистом часто встает дилемма: как организовать хранение данных, если видов номенклатуры много, а у каждого из них свой уникальный набор контролируемых параметров? Рассмотрим подробно архитектурные подходы, разберем плюсы и минусы использования расширений и проанализируем оптимальные структуры регистров сведений.
Первый и самый важный вопрос: создавать ли по одному регистру на каждый вид номенклатуры или использовать один общий? Разберем ситуацию. Если мы пойдем по пути создания множества регистров, мы столкнемся с «комбинаторным взрывом» объектов метаданных. Каждый новый вид продукции будет требовать внесения изменений в конфигурацию, что крайне неэффективно для сопровождения.
Рассмотрим универсальный подход. Большинство экспертов сходятся на том, что при альтернативе «один или много» всегда следует выбирать один. Это упрощает написание запросов, построение отчетов и поддержку системы. Однако здесь возникает вопрос структуры данных. Посмотрим на два основных варианта:
Номенклатура (или Серия, Партия), ПараметрКонтроля. Ресурс — Значение. Это максимально гибкая схема.Проанализируем пример структуры универсального регистра, который подойдет для большинства задач контроля качества:
// Пример структуры регистра сведений "РезультатыКонтроляКачества"
// Измерения:
// - ОбъектКонтроля (ЛюбаяСсылка: Номенклатура, Серия, ЭтапПроизводства)
// - ПараметрКонтроля (ПланВидовХарактеристикСсылка.ДополнительныеРеквизитыИСведения)
// - ДатаПроверки (ДатаВремя)
// Ресурсы:
// - Значение (Характеристика.ПараметрКонтроля)
// - Пройден (Булево)
Разберем по шагам риски использования расширений для хранения данных. Хотя расширения позволяют обновлять типовую 1С:ERP «безболезненно», они несут в себе скрытые угрозы для целостности данных.
Во-первых, выясним причину опасений опытных разработчиков. При критических сбоях платформы или некорректных манипуляциях с расширением (например, удаление и повторная установка) данные в таблицах расширения могут быть потеряны. Для статистических данных контроля, которые приходят от оборудования каждые 10 минут, это может быть критично.
Во-вторых, проанализируем работу с запросами. В старых версиях платформы работа с метаданными расширений в консоли запросов или конструкторе могла вызывать сложности. Поэтому рекомендуется: новые таблицы (регистры, справочники) добавлять в основную конфигурацию, включив возможность изменения, но оставив объекты на поддержке. А вот логику (формы, методы заполнения, обработчики) выносить в расширение.
Если планируется автоматическая загрузка данных с датчиков или стендов (например, проверка герметичности каждые 10 минут), нам необходимо минимизировать блокировки. Посмотрим, как это сделать правильно.
Использование одного регистра для всех станков может привести к очередям при записи. Чтобы этого избежать, проанализируем состав измерений. Если в качестве ведущего измерения использовать ДатаВремя с высокой точностью или уникальный идентификатор замера, СУБД будет проще управлять блокировками строк.
Для записи данных от оборудования лучше использовать HTTP-сервисы. Разберем пример логики приема данных:
Функция ПринятьДанныеКонтроля(ДанныеJSON)
// Парсим JSON от оборудования
СтруктураДанных = ПрочитатьJSON(ДанныеJSON);
// Создаем набор записей регистра
МенеджерЗаписи = РегистрыСведений.РезультатыКонтроля.СоздатьМенеджерЗаписи();
МенеджерЗаписи.Период = ТекущаяДата();
МенеджерЗаписи.ОбъектКонтроля = НайтиОбъектПоИдентификатору(СтруктураДанных.ID);
МенеджерЗаписи.Параметр = СтруктураДанных.Параметр;
МенеджерЗаписи.Значение = СтруктураДанных.Значение;
МенеджерЗаписи.Записать();
КонецФункции
Зачем изобретать свои справочники параметров, если в 1С:ERP уже есть мощный механизм Планов видов характеристик? Мы можем создать свой ПВХ для параметров контроля или использовать типовой Дополнительные реквизиты и сведения.
Рассмотрим преимущества такого подхода:
Выясним, как связать параметры с видами номенклатуры. Мы можем создать справочник НаборыПараметровКонтроля, который будет хранить список необходимых проверок для каждого вида продукции. При открытии формы проверки система будет анализировать этот набор и динамически формировать список полей для заполнения.
Подводя итог нашему анализу, сформулируем оптимальную стратегию построения архитектуры:
ОбъектКонтроля (ссылка на номенклатуру или серию) и Параметр (ссылка на ПВХ).Этап производства или создать отдельный документ Регистрация результатов контроля. Это позволит отслеживать, кто и когда внес данные.В пределах секунды и записывайте данные через фоновые задания, чтобы не блокировать работу пользователей в интерфейсе.Таким образом, мы получаем масштабируемую и отказоустойчивую систему, которая легко адаптируется под новые виды продукции без переписывания программного кода.