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