Почему документы не регистрируются и не выгружаются при настройке синхронизации через Конвертацию данных 3.1

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

При настройке обмена данными между конфигурациями на базе 1С, использующих современную технологию Enterprise Data (Конвертация данных 3.1), специалисты часто сталкиваются с ситуацией, когда справочники переносятся успешно, а документы упорно игнорируют все попытки их выгрузить. Проблема осложняется тем, что система не выдает явных ошибок, а просто «пропускает» объекты. Чтобы не гадать о причинах сбоя, полезно внедрить мониторинг ошибок обмена с автоматическим уведомлением на почту. Разберем детально, почему это происходит и как заставить механизм синхронизации работать корректно.

Анализируем режим работы: Ручная синхронизация против автоматической

Первым делом проанализируем настройки самого узла обмена. В Библиотеке стандартных подсистем (БСП), на которой базируется КД 3.1, существует принципиальная разница между режимами автоматической регистрации и ручного выбора объектов. Если при создании настройки выбран вариант «Синхронизация в ручном режиме», поведение системы радикально меняется.

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

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

Разбираемся с номерами сообщений и механизмом квитирования

Одной из самых частых причин, по которым зарегистрированные документы не попадают в файл обмена, является механизм квитирования и решение проблем с номерами сообщений. Рассмотрим ситуацию на конкретном примере номеров сообщений:

Проанализируем эти цифры. Мы видим, что Источник отправил пакет №10, но последним подтвержденным пакетом от Приемника для него является №9. Приемник же сообщает, что он уже успешно принял пакет №10. Однако, пока Источник не «увидит» во входящем файле-ответе подтверждение получения своего 10-го сообщения, он будет находиться в режиме ожидания. В некоторых версиях БСП это приводит к тому, что новые данные в файл просто не добавляются. Если вы используете типовые решения, такие как УНФ 3.0 или УТ 11.5, рекомендуется настроить отправку оповещений на почту при остановке обмена, чтобы оперативно реагировать на подобные «зависания».

Разберем, как исправить ситуацию по шагам:

  1. Выясним текущие номера сообщений в обеих базах.
  2. Если возник рассинхрон, попробуйте выполнить полный цикл обмена: Выгрузка из А -> Загрузка в Б -> Выгрузка из Б (квитанция) -> Загрузка в А.
  3. Если это не помогает, радикальным, но эффективным методом является сброс счетчиков. В обеих базах для данного узла обмена установите номера отправленного и принятого сообщения в 0. Это «обнулит» историю отношений между базами и позволит начать выгрузку с чистого листа.

Изучаем влияние Правил Регистрации Данных (ПРД)

В технологии Enterprise Data регистрация объектов управляется не только составом плана обмена в конфигураторе, но и внешними или встроенными правилами регистрации данных (ПРД). Это отдельный слой логики, который может отсекать документы даже при ручной попытке их добавить.

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

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

Проблема на уровне Менеджера обмена и XDTO-пакетов

Если документы зарегистрированы (вы видите их в списке «Состав отправляемых данных»), но в XML-файле их нет, проблема кроется в менеджере обмена через универсальный формат (XDTO). Это специальный модуль, который преобразует объект 1С в структуру XDTO.

Проанализируем работу метода ОпределитьДанныеДляВыгрузки. В КД 3.1 перед тем как превратить документ в XML, вызывается этот метод. Если в нем прописана проверка, которая возвращает Отказ = Истина, объект молча пропускается. Иногда для корректной работы требуется реализовать выборочный перенос документов из УТ путем добавления специального флага «Не выгружать», чтобы вручную управлять логикой исключения объектов из обмена.

Выясним причину через код. Нам нужно обратить внимание на следующие моменты в модуле менеджера обмена:


// Пример логики, которая может блокировать выгрузку
Процедура ПКО_Документ_ПоступлениеТоваровУслуг_Отправка_ПриОбработке(ДанныеИБ, ДанныеXDTO, КомпонентыОбмена, СтекВыгрузки)
    // Если дата документа меньше даты начала обмена, отменяем выгрузку
    Если ДанныеИБ.Дата < ДатаНачалаОбмена Тогда
        ДанныеXDTO = Неопределено;
        Возврат;
    КонецЕсли;
КонецПроцедуры

Если в вашей системе реализовано расширение состава данных Enterprise Data и добавлены обязательные поля, которых нет в стандартном XDTO-пакете, выгрузка также может сорваться. После настройки обмена обязательно должна быть выполнена сверка документов между конфигурациями через http-сервис, чтобы подтвердить, что все данные перенесены без потерь и искажений.

Использование прямого подключения как альтернатива

Как показывает практика обсуждений, обмен через файлы (особенно через FTP или почту) в КД 3.1 более капризен к подтверждениям, чем прямое подключение (COM или HTTP). При прямом подключении база-источник сразу получает ответ от базы-приемника об успешном получении данных в рамках одного сеанса.

Если инфраструктура позволяет, рекомендуем настроить прямое подключение к базе (COM/HTTP) как альтернативу файловому обмену. Это снимет большинство вопросов с «зависшими» номерами сообщений и квитированием, так как статус будет обновляться мгновенно. Рассмотрим этот вариант как приоритетный при отладке сложных обменов с документами.

Итоговый чек-лист для проверки

Для успешной выгрузки документов в КД 3.1 убедитесь, что:

  1. Номера сообщений в источнике синхронизированы (номер принятого в источнике равен номеру отправленного в приемнике).
  2. В ПРД (правилах регистрации) отсутствуют фильтры по дате, организации или незаполненным реквизитам, которые отсекают ваши документы.
  3. Версия формата Enterprise Data совпадает в обеих информационных базах.
  4. В модуле менеджера обмена нет условий, принудительно устанавливающих ДанныеXDTO = Неопределено для данного типа документа.
  5. Если обмен идет через файл, убедитесь, что вы загрузили в источник «файл-ответ» из приемника.
← На главную