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