При настройке обмена данными между конфигурациями на платформе 1С:Предприятие 8.3 (такими как 1С:ERP, 1С:Комплексная автоматизация или 1С:Бухгалтерия 3.0) часто возникает вопрос: как поведет себя система, если из другой базы придет документ, дата которого попадает в закрытый период? Рассмотрим эту ситуацию детально, разберем программные механизмы и выясним, как правильно настроить систему, чтобы избежать нежелательного изменения данных.
Для начала проанализируем, как работает программная запись объекта при обмене. В 1С существует специальное свойство ОбменДанными, которое есть у каждого объекта (документа, справочника, набора записей регистра). При выполнении синхронизации программный код загрузки устанавливает свойство Загрузка в значение Истина.
Разберем, на что это влияет. В типовых конфигурациях, построенных на БСП (Библиотеке стандартных подсистем), практически все проверки (включая проверку даты запрета) обернуты в условие. Если установлен флаг загрузки, то проверка просто игнорируется. Посмотрим на пример кода, который обычно встречается в подписках на события:
Процедура ПроверитьДатуЗапретаИзмененияПередЗаписью(Источник, Отказ) Экспорт
// Если выполняется загрузка данных при обмене, проверка пропускается
Если Источник.ОбменДанными.Загрузка Тогда
Возврат;
КонецЕсли;
// Вызов основной логики проверки даты запрета
ДатыЗапретаИзменения.ПроверитьДатуЗапретаИзменения(Источник, Отказ);
КонецПроцедуры
Таким образом, если в системе установлена обычная дата запрета изменения (которая действует на пользователей), то при синхронизации документ все равно будет записан, даже если он относится к прошлому году, который давно закрыт для редактирования бухгалтерией. Система считает, что данные из другой базы являются "доверенными", и их нужно принять "как есть".
Многие специалисты путают эти два понятия. Выясним причину их разделения. В современных версиях 1С:ERP реализовано два независимых механизма:
ОбменДанными.Загрузка = Истина.Рассмотрим подробнее работу даты запрета загрузки. Если вы установите эту дату в настройках синхронизации, то при попытке загрузить объект из другой базы система проверит дату этого объекта. Если дата документа меньше даты запрета загрузки, объект не будет загружен. Это именно то средство, которое позволяет защитить закрытые периоды от изменений со стороны других информационных баз.
Проанализируем ситуацию, упомянутую в обсуждении: документ загрузился, но не провелся. Почему так происходит? В 1С:ERP и других современных конфигурациях при обмене через универсальный формат (EnterpriseData) документы обычно передаются вместе со своими движениями (проводками). Это означает, что при записи документа в базу-приемник также записываются и наборы записей регистров с флагом ОбменДанными.Загрузка = Истина.
Однако, если обмен настроен таким образом, что передается только объект (документ), а движения должны сформироваться уже в базе-приемнике (через проведение), ситуация меняется. Рассмотрим этот процесс по шагам:
Загрузка = Истина. Он успешно записывается, игнорируя дату запрета.Записать() для регистров) флаг Загрузка может быть уже равен Ложь (если проведение инициируется как обычное действие).В результате мы получаем "битый" документ: сам объект в базе есть, а проводок у него нет, и провести его вручную пользователь не может, так как период закрыт. Именно поэтому крайне важно синхронизировать настройки дат запрета в обеих базах или использовать специализированную дату запрета загрузки.
Посмотрим, где именно в интерфейсе 1С:ERP настраиваются эти ограничения. Нам необходимо выполнить следующие действия:
Настройка даты запрета в разрезе организаций также возможна. Если вам нужно установить дату запрета для всех разделов учета сразу, выберите способ указания даты "По всем разделам". После этого вы сможете добавить в список нужные организации и указать для них даты закрытия периода.
Важно отметить отличие РИБ от обычной синхронизации. В РИБ (распределенной базе) механизм обмена работает на более низком уровне платформы. Там данные (включая движения) мигрируют максимально идентично. Если в главной базе документ был проведен, в периферийную базу он придет вместе с проводками. Проверки бизнес-логики (подписки на события) в РИБ при загрузке сообщений обмена обычно подавляются более жестко, чтобы обеспечить полную идентичность конфигураций и данных.
Подводя итог нашему анализу, можно сформулировать основные правила "дружбы" обмена и даты запрета:
Во-первых, помните, что обычная дата запрета, которую вы ставите для бухгалтеров, не является препятствием для синхронизации. Программный код обмена её обходит через ОбменДанными.Загрузка = Истина.
Во-вторых, для реального ограничения импорта данных используйте специальную настройку "Дата запрета загрузки данных" в меню синхронизации. Это единственный надежный способ защитить закрытый период от изменений "извне".
В-третьих, всегда проверяйте свои кастомные (самописные) подписки на события. Если вы создаете свой регистр или документ, обязательно добавляйте в начало процедур ПередЗаписью или ПриЗаписи проверку флага загрузки. Это спасет вас от ошибок, когда документ загружается, но "валится" на попытке записать движения из-за программных ограничений.
// Правильный шаблон для любой подписки на событие
Процедура ПриЗаписиРегистра(Источник, Отказ, Замещение) Экспорт
Если Источник.ОбменДанными.Загрузка Тогда
Возврат; // Не мешаем обмену данными
КонецЕсли;
// Ваша логика проверки
КонецПроцедуры
Соблюдение этих правил позволит вам настроить стабильный обмен данными, при котором информация в базе будет оставаться целостной и защищенной от некорректных правок в закрытых периодах.