Как программно изменить обмен между УТ 11 и БП 3 и предотвратить потерю данных

Программист 1С v8.3 (Управляемые формы) Управленческий учет IT и автоматизация бизнеса
← На главную

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

Анализ архитектуры обмена: КД 2.0 против КД 3.0

Прежде всего, разберем ситуацию, описанную в теме. Обычно франчайзи настраивают обмен по гибридной схеме. Из УТ в БП данные часто уходят через Конвертацию данных 2.0 (используя XML-правила), а обратно из БП в УТ — через Конвертацию данных 3.0 (используя формат EnterpriseData). Выясним, почему это важно:

  1. Конвертация данных 2.0 (КД 2.0): Логика обмена описывается во внешнем XML-файле правил. Система ищет объект в приемнике и замещает реквизиты согласно ПКО (Правилам конвертации объектов).
  2. Конвертация данных 3.0 (КД 3.0): Это современный стандарт на базе Библиотеки стандартных подсистем (БСП). Здесь нет внешнего файла правил в привычном понимании. Вся логика преобразования данных (XDTO) прописана непосредственно в коде конфигурации в Модулях менеджера обмена.

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

Где искать код обмена в конфигурации

Для того чтобы изменить логику загрузки, нам нужно найти место, где система обрабатывает входящий файл обмена. Проанализируем структуру объектов в 1С:УТ 11:

Способ 1: Использование механизма «Слияния» данных (Merging)

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

Нам необходимо сравнить данные, которые уже есть в базе, с данными, которые пришли в обмене. Проанализируем пример реализации защиты характеристик:


Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
    Если ОбменДанными.Загрузка Тогда
        // Получаем старые данные из базы данных для сравнения
        СсылкаНаОбъект = ЭтотОбъект.Ссылка;
        Если Не СсылкаНаОбъект.Пустая() Тогда
            ТаблицаИзБазы = СсылкаНаОбъект.Товары.Выгрузить();
            
            Для Каждого СтрокаТЧ Из ЭтотОбъект.Товары Цикл
                // Пытаемся найти строку по номеру строки или по номенклатуре
                ПараметрыПоиска = Новый Структура("НомерСтроки", СтрокаТЧ.НомерСтроки);
                НайденныеСтроки = ТаблицаИзБазы.НайтиСтроки(ПараметрыПоиска);
                
                Если НайденныеСтроки.Количество() > 0 Тогда
                    СтараяСтрока = НайденныеСтроки[0];
                    // Если в пришедших данных характеристика пустая, а в базе была — восстанавливаем
                    Если Не ЗначениеЗаполнено(СтрокаТЧ.Характеристика) 
                        И ЗначениеЗаполнено(СтараяСтрока.Характеристика) Тогда
                        СтрокаТЧ.Характеристика = СтараяСтрока.Характеристика;
                    КонецЕсли;
                    // Аналогично для серий номенклатуры
                    Если Не ЗначениеЗаполнено(СтрокаТЧ.Серия) 
                        И ЗначениеЗаполнено(СтараяСтрока.Серия) Тогда
                        СтрокаТЧ.Серия = СтараяСтрока.Серия;
                    КонецЕсли;
                КонецЕсли;
            КонецЦикла;
        КонецЕсли;
    КонецЕсли;
КонецПроцедуры

Способ 2: Настройка правил в Конвертации данных 3.0

Если мы хотим решить задачу «красиво» на уровне самого обмена, нам придется работать с ПОД (Правила обработки данных) и ПКО (Правила конвертации объектов) внутри модуля менеджера обмена. Разберем шаги:

  1. В модуле МенеджерОбменаЧерезУниверсальныйФормат найдем функцию, описывающую правила для документа.
  2. Используем свойство КомпонентыОбмена.ПравилаЗагрузкиДанных.
  3. Для реквизитов Характеристика и Серия установим режим, при котором они не обновляются, если объект в базе-приемнике уже существует.

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

Альтернативный вариант: Использование COM-соединения

Как отмечали участники обсуждения на форуме, иногда проще отказаться от стандартного двустороннего обмена в пользу прямой дописки данных. Мы можем создать небольшую обработку, которая по расписанию будет подключаться из БП к УТ через COM-соединение и обновлять только два поля: Цена и Сумма.

Преимущества этого подхода:

Рекомендации по бизнес-процессу

Важно понимать, что технические «костыли» часто являются следствием неправильного распределения обязанностей. Рассмотрим классическую схему работы в УТ 11, которая решает проблему автора без программирования:

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

Если же организация настаивает на обратной выгрузке цен из БП, то лучшим решением будет доработка модуля менеджера обмена в части сопоставления табличных частей, чтобы обновление цен происходило методом ЗаполнитьЗначенияСвойств только для конкретных колонок, не затрагивая аналитику складского учета.

← На главную