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