← На главную

Часто перед разработчиками 1С встает задача: необходимо реализовать возможность ставить отметку (булево) о получении оригинала документа. При этом ключевым требованием является возможность изменять эту отметку даже в закрытом периоде (без перепроведения самого документа). Дополнительно требуется регистрировать пользователя, который изменил эту отметку, и выводить статус в динамический список документов.

Давайте подробно разберем эту задачу, проанализируем различные подходы к архитектуре и посмотрим, как правильно реализовать такой функционал, чтобы он работал быстро и не вызывал проблем при масштабировании.

Вариант 1: Разработка собственного регистра сведений

Поскольку нам необходимо изменять данные без модификации самого объекта документа (чтобы обходить запрет редактирования в закрытом периоде), очевидно, что хранить этот реквизит в самом документе нельзя. Нам потребуется отдельный РегистрСведений. Но какой выбрать: периодический или непериодический?

Рассмотрим два основных подхода, которые обсуждаются в сообществе разработчиков:

1. Периодический регистр сведений (с периодичностью "Секунда"). Этот вариант отлично подходит, если бизнес-логика требует жесткого хранения всей истории изменений: кто, когда и на какое значение поменял отметку. Система автоматически строит виртуальную таблицу СрезПоследних, что позволяет удобно получать актуальный статус на текущий момент. Если отметку нужно выводить в список документов, периодический регистр справится с этой задачей, хотя объединение списка с таблицей среза последних может быть тяжелым для производительности базы данных при больших объемах.
2. Непериодический (обычный) регистр сведений. Если полная история изменений каждую секунду фактически не нужна (ведь нас чаще всего интересует только актуальный статус и автор последнего изменения), обычный регистр будет работать быстрее. В измерения мы добавляем ссылку на документ, а в ресурсы — саму отметку и автора изменения. Запрос к такой плоской таблице для вывода в динамический список будет отрабатывать максимально эффективно. Если же когда-то потребуется узнать, кто менял статус год назад, мы всегда сможем поднять Журнал регистрации.

Вывод по архитектуре: Если вам строго не требуется выводить исторические срезы на конкретные даты в отчетах, то оптимальным решением будет создание обычного непериодического регистра сведений. Это избавит базу от лишней нагрузки по расчету итогов среза последних.

Вариант 2: Использование типовых механизмов БСП (Библиотека стандартных подсистем)

Проанализируем ситуацию с точки зрения современных конфигураций (таких как ERP, Комплексная автоматизация, Бухгалтерия предприятия 3.0). В большинстве современных решений 1С, построенных на базе БСП, изобретать собственный регистр уже нет необходимости. Выясним, какие готовые инструменты мы можем использовать.

Штатная подсистема «Учет оригиналов первичных документов»

В типовых конфигурациях встроен мощный и готовый механизм контроля оригиналов. Посмотрим на его преимущества:

• Независимость от закрытого периода: Статусы хранятся в отдельных системных регистрах. Пользователи могут менять состояние «Оригинал получен» прямо из форм списков документов или журналов, не затрагивая сами документы.
• Автоматическое логирование: Подсистема сама фиксирует информацию о том, кто из сотрудников установил статус и в какое время.
• Детализация до печатных форм: В отличие от простого булева значения, типовой механизм умеет отслеживать статусы для каждой печатной формы отдельно (например, акт подписан, а счет-фактура еще в пути). Итоговое состояние документа вычисляется автоматически.
• Гибкость состояний: Используется не просто флажок «Да/Нет», а справочник состояний. Вы можете добавить свои элементы: «Отправлен курьером», «Ожидает исправления» и т.д.

Использование механизма «Дополнительные сведения»

Если штатная подсистема учета оригиналов по каким-то причинам вам не подходит, разберем альтернативный типовой путь — использование дополнительных сведений.

1. Переходим в раздел администрирования и включаем использование дополнительных реквизитов и сведений.
2. Создаем Дополнительное сведение (не реквизит!) с типом Булево (или ссылкой на дополнительное значение) для нужного вида документа.
3. Поскольку дополнительные сведения хранятся в типовом независимом регистре сведений ДополнительныеСведения, их редактирование не меняет версию самого документа. Это полностью решает проблему закрытого периода.
4. Чтобы фиксировать авторство, достаточно включить типовое версионирование для регистра сведений, либо просто опираться на журнал регистрации.
5. Вывести дополнительное сведение в динамический список можно стандартными пользовательскими настройками формы (через «Изменить форму»), платформа сама сгенерирует правильный и оптимальный запрос для связи списка с регистром сведений.

Подводим итоги

Мы подробно разобрали задачу и выяснили, что если вы разрабатываете конфигурацию с нуля, выбор между периодическим и непериодическим регистром зависит от требований к истории (для скорости вывода актуальных данных в списки лучше непериодический регистр). Однако, если вы работаете в современной конфигурации на управляемых формах, настоятельно рекомендуем задействовать готовые механизмы БСП — подсистему учета оригиналов или дополнительные сведения. Это сэкономит ваше время, обеспечит высокую производительность и избавит от необходимости писать дополнительный код для работы с закрытым периодом.