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