При настройке обмена данными между конфигурациями «1С:Управление торговлей 11» и «1С:Бухгалтерия предприятия 3.0» через универсальный формат (Enterprise Data) пользователи часто сталкиваются с проблемой: система раз за разом пытается отправить одни и те же документы, которые уже были успешно загружены в базу-приемник. Это приводит к колоссальным временным затратам, особенно если объем данных исчисляется тысячами документов. Разберем детально, почему так происходит и как правильно настроить сценарий синхронизации, чтобы обмен работал эффективно.
Для начала проанализируем ситуацию: почему 1С «забывает», что документы уже отправлены? В основе любой синхронизации в среде 1С лежит механизм ПланыОбмена. Когда объект (документ или справочник) изменяется, он попадает в специальную таблицу — регистрацию изменений. При выполнении выгрузки система берет все зарегистрированные объекты, упаковывает их в файл обмена и присваивает этому пакету порядковый номер (номер исходящего сообщения).
Однако просто отправить данные недостаточно. Система-отправитель (в нашем случае УТ 11) должна получить подтверждение от системы-приемника (БП 3.0), что файл был успешно получен и обработан. Этот процесс называется квитированием. Если подтверждение (номер принятого сообщения) не получено, УТ 11 считает, что доставка не удалась, и при следующем запуске синхронизации снова включит все эти 20 000 документов в новый файл обмена.
Рассмотрим подробнее, как это реализовано в протоколе обмена. Это не UPD-протокол, где данные уходят «в никуда», а строгий TCP-подобный механизм подтверждения на уровне бизнес-логики 1С. Если вы настроили в сценарии только «Отправку данных», то цепочка обмена разрывается: БП данные принимает, но УТ об этом не узнает.
Выясним причину, по которой квитанция не доходит до отправителя. Чаще всего это происходит из-за неполного сценария в настройках обмена. Если вы используете автоматическую синхронизацию по расписанию, проверьте состав действий в сценарии.
Разберем по шагам настройку правильного сценария:
Отправка данных, это и есть корень проблемы.Получение данных.Даже если вы не планируете выгружать документы из БП в УТ (например, учет ведется строго в одну сторону), действие Получение данных жизненно необходимо. Именно в этот момент УТ считывает технический файл-ответ, в котором БП сообщает: «Я успешно приняла сообщение №45». Получив этот номер, УТ автоматически очищает таблицу регистрации для всех объектов, входивших в сорок пятое сообщение.
Посмотрим на ситуацию со стороны «1С:Бухгалтерии». Чтобы она не перегружала УТ лишними данными, но при этом исправно отправляла подтверждения, нужно правильно выставить фильтры. Рассмотрим настройки в БП:
В параметрах синхронизации на стороне БП 3.0 установите следующие значения:
При таких настройках БП не будет формировать пакеты с полезными данными, но при выполнении синхронизации она создаст «пустое» сообщение, в заголовке которого будет передан номер последнего принятого сообщения от УТ. Этого достаточно для очистки очереди регистрации в УТ.
Проанализируем ситуацию, когда за раз нужно передать 20 000 документов (как в примере автора). В условиях облачного сервиса 1C:Fresh или при медленном интернет-соединении, синхронизация может длиться 15 часов и обрываться по таймауту. Если сессия обмена прервана до завершения записи подтверждения, регистрация не снимется.
В таких случаях рекомендуется выполнять первую выгрузку порциями. Хотя в стандартном интерфейсе Enterprise Data нет явной кнопки «выгружать по 100 объектов», мы можем воспользоваться обработкой Регистрация изменений для обмена.
Рассмотрим пример логики, которую можно применить для анализа регистрации (фрагмент для разработчика):
// Пример кода для проверки количества зарегистрированных объектов в плане обмена
ПланОбменаСсылка = ПланыОбмена.СинхронизацияДанныхЧерезУниверсальныйФормат.НайтиПоНаименованию("БП 3.0");
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| СУММА(Т.Количество) КАК ВсегоРегистраций
|ИЗ (
| ВЫБРАТЬ КОЛИЧЕСТВО(*) КАК Количество ИЗ Документ.РеализацияТоваровУслуг.Изменения ГДЕ Узел = &Узел
| ОБЪЕДИНИТЬ ВСЕ
| ВЫБРАТЬ КОЛИЧЕСТВО(*) ИЗ Документ.ПоступлениеТоваровУслуг.Изменения ГДЕ Узел = &Узел
|) КАК Т";
Запрос.УстановитьПараметр("Узел", ПланОбменаСсылка);
Результат = Запрос.Выполнить().Выбрать();
Если Результат.Следующий() Тогда
Сообщить("Объектов к отправке: " + Результат.ВсегоРегистраций);
КонецЕсли;
Если вы видите, что число регистраций критическое, можно временно снять регистрацию со всех объектов, а затем добавлять их к обмену порциями, например, по месяцам, используя стандартную обработку регистрации изменений.
Работа в облаке накладывает свои ограничения. Посмотрим на наиболее критичные моменты:
УТ 11 и БП 3.0 используют идентичную версию формата EnterpriseData (например, 1.13). Если версии различаются, некоторые поля могут не сопоставиться, что вызовет ошибки загрузки и, как следствие, отказ в подтверждении приема пакета.Подводя итог, можно сказать, что «ручное» удаление документов из списка отправляемых — это временная и опасная мера. Если в документах были ошибки (например, незаполненные обязательные реквизиты), они не попадут в бухгалтерию, а ручное снятие регистрации приведет к тому, что система больше никогда не попытается их отправить автоматически.
Правильное решение: всегда включайте действие Получение данных в сценарий обмена на стороне УТ 11. Это обеспечит корректную работу механизма квитирования, и ваши 20 000 документов исчезнут из списка к отправке сразу после того, как БП 3.0 подтвердит их успешный прием. После завершения первичного массового обмена настройте расписание синхронизации на каждые 15–30 минут — это позволит передавать данные небольшими порциями (по 200–300 документов), что займет не более пары минут и исключит блокировки базы.