Как изменить типовые правила обмена EnterpriseData при переходе с Конвертации данных 2.1 на 3.0

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

Переход с конфигураций предыдущего поколения, таких как «1С:Розница 2.3», на современные решения, например «1С:Управление нашей фирмой 3.0» (УНФ) и «1С:Бухгалтерия предприятия 3.0» (БП), влечет за собой фундаментальную смену механизма интеграции. Если ранее обмен настраивался через «Конвертацию данных 2.1» (КД 2.1) и оперировал выгрузкой и загрузкой XML-файлов с правилами конвертации, то в УНФ и БП обмен строится на базе универсального формата EnterpriseData и концепции «Конвертации данных 3.0 / 3.1» (КД 3).

Разберем детально, как устроена современная архитектура синхронизации, можно ли менять типовые правила так же, как в КД 2.1, и как решить практическую задачу выборочной выгрузки розничных документов.

Ключевые архитектурные различия между КД 2.1 и КД 3.x

Главная трудность при переходе на новые рельсы — изменение самой парадигмы хранения и исполнения правил конвертации:

  1. Правила конвертации данных (ПКД) теперь являются программным кодом. В КД 2.1 правила конвертации представляли собой отдельный XML-файл, который можно было просто загрузить в пользовательском режиме «1С:Предприятие» в узел плана обмена. В формате EnterpriseData логика сопоставления объектов жестко зашита в код общих модулей конфигурации (таких как МенеджерОбменаЧерезУниверсальныйФормат в УНФ или МенеджерОбменаЧерезУниверсальныйФормат13 в БП). Загрузить отдельный XML-файл с логикой конвертации в пользовательском режиме больше нельзя.
  2. Правила регистрации данных (ПРД) остались внешними. Логика, определяющая, какие именно объекты должны регистрироваться к выгрузке при записи, по-прежнему может загружаться в виде XML-файла из внешнего источника через пункт «Загрузить правила регистрации данных» в меню синхронизации БСП.

Специфика выгрузки розницы: чеки ККМ и отчеты о розничных продажах

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

  1. Сворачивание чеков в ОРП. При закрытии кассовой смены в УНФ розничные чеки архивируются и объединяются в итоговый документ ОтчетОРозничныхПродажах.
  2. Состав данных в формате EnterpriseData. В типовом сценарии обмена между УНФ и БП отдельные документы ЧекККМ в бухгалтерию не передаются — выгружается именно сформированный сводный документ ОтчетОРозничныхПродажах (за исключением редких ситуаций чеков предоплаты, формирующих кассовые ордера).
  3. Определение точки фильтрации. Если требуется передавать не все продажи, необходимо выяснить, на каком этапе ставить отбор: на уровне оперативного учета кассовых смен в УНФ (разделение по кассам ККМ, подразделениям или организациям) или на уровне уже готовых документов ОРП перед отправкой в БП.

Способ 1. Фильтрация через правила регистрации данных (ПРД) без изменения кода

Если задача заключается только в том, чтобы исключить определенные документы из отправки, наиболее правильный и безопасный подход — отсекать их на этапе регистрации изменений. Это предотвращает засорение таблиц регистрации и ускоряет работу обмена.

Рассмотрим порядок действий для настройки ПРД:

  1. Выгрузим текущие типовые правила регистрации данных из плана обмена в файл через стандартные инструменты БСП или конфигурацию «Конвертация данных 3.1».
  2. Откроем правила в конфигурации «Конвертация данных 3.1», перейдем к объекту ОтчетОРозничныхПродажах и настроим обработчик «Перед обработкой» или «При обработке».
  3. Установим признак отказа для документов, не подходящих под наши условия:
    
    Если Объект.КассаККМ.ТипКассы = ПредопределенноеЗначение("Перечисление.ТипыКассККМ.АвтономнаяККМ") Тогда
        Отказ = Истина;
    КонецЕсли;
    
  4. Сохраним файл правил регистрации в формате XML и загрузим его в УНФ в настройках синхронизации данных через команду Загрузить правила регистрации данных.

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

Способ 2. Корректировка через расширение конфигурации (рекомендуемый метод)

Если требуется скорректировать не только факт выгрузки, но и состав переносимых реквизитов, маппинг полей или поведение загрузки, правила в КД 3.x изменяются через доработку общего модуля МенеджерОбменаЧерезУниверсальныйФормат. Чтобы сохранить конфигурации УНФ и БП на полной типовой поддержке, все доработки выполняются через механизм расширений.

Разберем по шагам доработку через расширение:

  1. Создадим новое расширение в режиме «Конфигуратор» в базе-источнике (УНФ).
  2. Добавим в расширение общий модуль МенеджерОбменаЧерезУниверсальныйФормат.
  3. Найдем процедуру, отвечающую за инициализацию правил обработки данных (ПОД) или правил конвертации объектов (ПКО), например ПриНастройкеПравилОбмена.
  4. Используем директиву &После или &ИзменениеИКонтроль для переопределения логики выгрузки. Например, в процедуре выборки данных документа можно наложить дополнительное программное условие:
    
    &После("ЗаполнитьПравилаОбработкиДанных")
    Процедура Расш1_ЗаполнитьПравилаОбработкиДанных(ПравилаОбработкиДанных)
        // Доопределяем или переопределяем правила выборки объектов
        ПланОбработки = ПравилаОбработкиДанных.Найти("ОтчетОРозничныхПродажах", "Имя");
        Если ПланОбработки <> Неопределено Тогда
            // Подключение собственного обработчика выборки
        КонецЕсли;
    КонецПроцедуры
    
  5. Если условие вычисляется непосредственно в процессе выгрузки самого объекта, установим отказ в обработчике ПКО:
    
    Если Источник.СуммаДокумента <= 0 Тогда
        Отказ = Истина;
    КонецЕсли;
    

Способ 3. Визуальное редактирование через конфигурацию «Конвертация данных 3.1»

Если логика сопоставления объектов сложная и писать всё вручную в коде неудобно, можно воспользоваться специальной средой разработки правил — конфигурацией «Конвертация данных 3.1».

Посмотрим, как выстроен этот технологический процесс:

  1. Из рабочей конфигурации УНФ или БП выгружаются структура метаданных и текст общего модуля менеджера обмена.
  2. В КД 3.1 создается конвертация, куда загружаются метаданные и типовой модуль менеджера обмена.
  3. В визуальном редакторе настраиваются ПКО (Правила конвертации объектов), ПКС (Правила конвертации свойств) и ПОД (Правила обработки данных).
  4. После внесения правок КД 3.1 генерирует и выгружает обновленный текст модуля менеджера обмена.

Предостережение: разработчики фирмы «1С» периодически вносят в типовой модуль МенеджерОбменаЧерезУниверсальныйФормат ручные правки, которые могут быть перезаписаны при повторной генерации кода из КД 3.1. Перед внедрением сгенерированного модуля в базу всегда сравнивайте исходный файл модуля и выгруженный из КД с помощью внешних утилит сравнения текстов, чтобы не потерять важные типовые механизмы.

Штатные отборы узла плана обмена

Прежде чем приступать к программным доработкам или изменению правил регистрации, проанализируем параметры самого узла плана обмена. В типовых сценариях БСП многие типовые фильтры уже предусмотрены разработчиками без необходимости влезать в код:

  1. Откроем форму настройки правил отправки данных узла синхронизации в УНФ.
  2. Проверим доступные отборы: синхронизация EnterpriseData часто позволяет отфильтровать документы розницы по конкретным организациям, подразделениям или складам/кассам.
  3. Если требуемый сценарий разделения чеков укладывается в разделение торговых точек по разным складам или подразделениям, достаточно установить соответствующий флаг в настройках узла без правки правил.
← На главную