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