При настройке обмена данными между современными конфигурациями на базе Библиотеки стандартных подсистем (БСП), такими как 1С:Бухгалтерия предприятия 3.0, и программными продуктами предыдущего поколения, такими как 1С:Управление производственным предприятием 1.3, специалисты часто сталкиваются с проблемой бесконечного дублирования данных. Суть проблемы заключается в том, что после успешной загрузки информации в базу-приемник база-источник (БП 3.0) «не узнает» о том, что данные были приняты, и при следующем сеансе обмена снова выгружает те же самые документы.
В этой статье мы подробно разберем механизмы подтверждения получения данных (квитирования), выясним причины программного сбоя в связке БП 3.0 — УПП 1.3 и рассмотрим практические способы решения этой задачи с примерами кода.
Для начала проанализируем ситуацию и поймем, как работает механизм регистрации изменений в 1С. Когда мы настраиваем обмен через планы обмена, система фиксирует каждое изменение объекта в специальной таблице. При выгрузке данных программа считывает эти изменения, упаковывает их в XML-файл и присваивает сообщению определенный номер (например, номер 15).
Чтобы база-источник «успокоилась» и очистила таблицу регистраций для этих объектов, она должна получить от базы-приемника ответный файл, в котором будет указано: «Я успешно приняла твое сообщение номер 15». Этот процесс называется квитированием. В современных конфигурациях (БП 3.0, УТ 11, ERP) этот механизм автоматизирован через БСП. Однако УПП 1.3 использует старую технологию обмена (универсальный обмен данными XML), которая не всегда корректно формирует заголовок ответного сообщения.
Если в ответном файле из УПП отсутствует атрибут УдалитьРегистрациюИзменений="true" или номер принятого сообщения не совпадает с отправленным, Бухгалтерия 3.0 будет считать, что данные не дошли, и отправит их повторно. Рассмотрим, как это исправить.
Самый эффективный способ решить проблему — внести небольшое изменение в программный код обработки, отвечающей за обмен данными в УПП. Нам необходимо принудительно заставить УПП сообщать Бухгалтерии, что регистрацию изменений можно удалять.
Для этого нам потребуется изменить обработку ОбменДаннымиXML в конфигурации УПП 1.3 (или использовать её как внешнюю). Разберем по шагам, что нужно сделать:
ОбменДаннымиXML.ЗаписатьИнформациюОбОбменеДаннымиЧерезПланыОбмена.Добавим следующий фрагмент кода:
// В процедуре ЗаписатьИнформациюОбОбменеДаннымиЧерезПланыОбмена
// Находим место, где устанавливаются атрибуты узла приемника
УстановитьАтрибут(Приемник, "УдалитьРегистрациюИзменений", Истина);
После внесения этого изменения УПП начнет записывать в XML-файл ответа признак успешного получения, и Бухгалтерия 3.0 при загрузке этого «пустого» (или содержащего встречные данные) файла автоматически очистит регистрацию для ранее отправленных документов.
Если вы не хотите вносить изменения в код конфигурации УПП, мы можем попробовать решить задачу через Конвертацию данных 2.0. В правилах обмена существует возможность прописать алгоритмы, выполняемые на разных этапах выгрузки и загрузки.
Проанализируем возможность использования обработчика ПослеВыгрузкиДанных. Чтобы данные не выгружались повторно, можно принудительно очищать регистрацию изменений сразу после генерации файла, не дожидаясь ответа от приемника. Однако помните: это рискованный метод, так как если файл потеряется или не загрузится из-за ошибки, данные в приемник не попадут, а в источнике они уже не будут числиться как измененные.
Пример кода для обработчика ПослеВыгрузкиДанных в правилах обмена:
Если Параметры.Свойство("УзелДляОбменаСсылка") И ЗначениеЗаполнено(Параметры.УзелДляОбменаСсылка) Тогда
ПланыОбмена.УдалитьРегистрациюИзменений(Параметры.УзелДляОбменаСсылка);
КонецЕсли;
Данный код полностью очистит таблицу регистрации для данного узла. Рассмотрим ситуацию более детально: если вы используете частичную выгрузку, лучше удалять регистрацию только для конкретных типов метаданных, чтобы не затронуть те объекты, которые еще не должны быть выгружены.
Часто причина кроется в банальной рассинхронизации кодов узлов. Выясним, корректно ли настроены планы обмена в обеих базах. Для успешного квитирования должны соблюдаться следующие условия:
Если коды перепутаны или в одной из баз используется «пустой» узел (без кода), механизм MessageNo (номер сообщения) и ReceivedNo (номер принятого сообщения) работать не будет. Проверьте в УПП справочник «Настройки обмена данными». Убедитесь, что поле «Номер принятого сообщения» увеличивается после каждой загрузки файла из Бухгалтерии. Если оно всегда равно 0, значит, обработка в УПП не понимает, какое сообщение она получила.
Типовые механизмы УПП 1.3 могут быть устаревшими. Рекомендуем попробовать выполнить обмен с помощью внешней обработки Универсальный обмен данными в формате XML (версии 2.1.8 или выше), которая входит в состав поставки «Конвертации данных».
Рассмотрим порядок действий:
Иногда использование внешней обработки вместо встроенной позволяет обойти ошибки старых релизов конфигурации УПП без вмешательства в код базы.
Мы проанализировали проблему повторной выгрузки данных и выяснили, что основной причиной является отсутствие подтверждения (квитка) в файле ответа от УПП 1.3.
Резюмируем наши действия:
УстановитьАтрибут(Приемник, "УдалитьРегистрациюИзменений", Истина); в обработку ОбменДаннымиXML на стороне УПП.Помните, что корректная синхронизация — это прежде всего диалог между двумя системами. Если Бухгалтерия 3.0 «кричит» о новых данных, УПП должна четко «ответить», что информация принята. Настройка этого диалога через атрибут УдалитьРегистрациюИзменений — ключ к стабильной работе вашего обмена.