Как настроить обмен УТ 11 и БП 3.0, чтобы измененные документы не затирались?

Довольно часто при интеграции баз «Управление торговлей» (УТ) и «Бухгалтерия предприятия» (БП) возникает классическая проблема: менеджеры создают документы в УТ, они выгружаются в БП, где бухгалтер вносит в них свои корректировки. Однако при следующем обмене, если документ был хотя бы минимально затронут в УТ, он снова прилетает в бухгалтерию и безвозвратно затирает все ручные изменения бухгалтера. Разберем подробно, как мы можем настроить систему, чтобы выгружались только новые документы, а измененные бухгалтером данные оставались в сохранности.

Способ 1. Использование механизма «Дата запрета загрузки» (Типовой функционал)

Самый простой и правильный с точки зрения методологии 1С способ защитить изменения — использовать дату запрета загрузки данных. Разберем по шагам, как это работает:

1. Бухгалтер регулярно проверяет документы за определенный период и вносит необходимые корректировки в базе БП.
2. После закрытия периода (или просто проверки пула документов) устанавливается дата запрета загрузки данных из других программ.
3. При последующих сеансах обмена УТ физически не сможет перезаписать документы в БП, дата которых меньше или равна указанной дате запрета.

Этот подход не требует программирования и легко настраивается пользователями с полными правами.

Способ 2. Настройка разрешения коллизий

В типовых настройках синхронизации (в параметрах подключения узла обмена) присутствуют правила обработки коллизий. Коллизия возникает, когда документ был изменен одновременно в обеих базах между сеансами обмена. Посмотрим на эту настройку внимательнее. Обычно по умолчанию приоритет отдается базе-источнику. Если грамотно настроить приоритет получения данных (например, отдавать приоритет базе БП при совпадении объектов), можно существенно снизить риск случайного затирания важной бухгалтерской информации.

Способ 3. Доработка логики загрузки через Расширения конфигурации (Современный подход)

Современные версии УТ 11 (начиная с 11.3) и БП 3.0 по умолчанию используют обмен через универсальный формат EnterpriseData (технология «Конвертация данных 3.0»). В этом случае вся логика обмена зашита в общих модулях конфигурации, таких как МенеджерОбменаЧерезУниверсальныйФормат. Проанализируем ситуацию: чтобы не снимать конфигурацию с поддержки, мы воспользуемся механизмом Расширений.

На стороне УТ (отмена регистрации):

С помощью расширения мы можем вмешаться в подписки на события при записи документа. Добавляем проверку: если документ уже участвовал в обмене (для этого можно добавить дополнительный реквизит или свойство, например, ВыгруженВБП), то при его последующем изменении в УТ мы программно отменяем его регистрацию на узле обмена.

На стороне БП (отказ от загрузки):

В базе БП с помощью расширения переопределяем процедуры загрузки данных. В обработчиках конвертации объекта XDTO мы пишем код, который выполняет поиск документа по ссылке. Если документ уже существует в базе БП и имеет признак ручной корректировки (например, бухгалтер ставит специальный флажок или пишет кодовое слово в комментарий), то мы устанавливаем параметр Отказ = Истина, и загрузка новых данных для этого конкретного документа игнорируется.

Способ 4. Использование статусов документов

В УТ 11 для многих документов предусмотрена система статусов. Мы можем доработать правила регистрации объектов (ПРО) таким образом, чтобы документы отправлялись в БП только после установки финального статуса, например, Закрыт или Реализовано.

После установки этого статуса любые дальнейшие изменения документа в УТ блокируются на уровне прав доступа. Это вынуждает менеджеров согласовывать любые последующие изменения напрямую с бухгалтерией, полностью исключая неконтролируемое фоновое затирание данных.

Способ 5. Отключение миграции через правила обмена (Для Конвертации данных 2.0)

Если вы используете старый формат обмена на базе правил обмена (файл ExchangeRules.xml), то шаманить нужно непосредственно в них. Рассмотрим пример, в котором полностью отключается выгрузка определенных табличных частей, чтобы они не затирались.

В файле правил можно прописать команду Отключить="true" для нужной группы свойств или табличной части, а также задать условие отказа от выгрузки. Посмотрим на пример кода из правил:

<Правило>
    <Код>ОтражениеЗарплатыВБухучете</Код>
    <Наименование>Документ: Отражение зарплаты в бухгалтерском учете</Наименование>
    <Порядок>400</Порядок>
    <ПослеЗагрузки>Выполнить(Алгоритмы.ЗаполнитьТЧИзПараметровОбъекта);</ПослеЗагрузки>
    <СинхронизироватьПоИдентификатору>true</СинхронизироватьПоИдентификатору>
    <Источник>ДокументСсылка.ОтражениеЗарплатыВБухучете</Источник>
    <Приемник>ДокументСсылка.ОтражениеЗарплатыВБухучете</Приемник>

    <Группа Отключить="true">
        <Код>10</Код>
        <Наименование>НачисленнаяЗарплатаИВзносы --> НачисленнаяЗарплатаИВзносы</Наименование>
        <Порядок>350</Порядок>
        <Источник Имя="НачисленнаяЗарплатаИВзносы" Вид="ТабличнаяЧасть"/>
        <Приемник Имя="НачисленнаяЗарплатаИВзносы" Вид="ТабличнаяЧасть"/>
        <ПередОбработкойВыгрузки>
        //+ отключена выгрузка табличной части
        Если Параметры.НеВыгружатьПерсональныеДанныеФизическихЛиц Тогда
            Отказ = Истина;
        КонецЕсли;
        </ПередОбработкойВыгрузки>
    </Группа>
</Правило>

Если вам нужно, чтобы не улетал весь документ целиком (а не только табличная часть), атрибут Отключить="true" можно применить к корневой группе правила конвертации объекта (ПКО). Однако стоит помнить, что прямое редактирование XML-файлов актуально только для старых обменов, и в современных реалиях предпочтение следует отдавать расширениям и правилам регистрации.