При настройке типовой синхронизации между конфигурациями «Зарплата и управление персоналом 3.1» (ЗУП) и «Бухгалтерия предприятия 3.0» (БП) через файл обмена часто возникает вопрос: как система понимает, что данные уже переданы? Почему при повторной синхронизации программа не выгружает одни и те же документы бесконечно? Разберем подробно внутреннее устройство этого процесса, который в профессиональной среде 1С называется квитированием.
Прежде чем рассматривать сам процесс передачи файла, проанализируем, как 1С узнает, что объект вообще нужно выгрузить. В каждой конфигурации существуют специальные объекты метаданных — Планы обмена. Рассмотрим их роль: для каждого документа (например, ВедомостьНаВыплатуЗарплаты или ОтражениеЗарплатыВБухучете), включенного в состав плана обмена, система создает скрытую таблицу регистрации изменений.
Разберем три ситуации, когда объект попадает в эту таблицу:
Важно понимать: пока запись находится в таблице регистрации, 1С считает, что данные «изменены и не переданы». Но снятие этой записи происходит вовсе не в момент нажатия кнопки «Синхронизировать» в базе-источнике.
Рассмотрим пошагово цикл обмена через файл, чтобы выяснить, в какой момент очищается регистрация. Для корректной работы требуется выполнение «круга» из трех этапов:
Этап 1: Выгрузка из ЗУП. Программа собирает все зарегистрированные объекты, упаковывает их в XML-файл и присваивает этому пакету НомерСообщения (например, №10). В этот момент в таблице регистрации изменений для этих объектов проставляется пометка: «отправлено в сообщении №10». Однако сами записи из таблицы не удаляются.
Этап 2: Загрузка в БП и ответ. Когда вы загружаете этот файл в Бухгалтерию, программа считывает данные. Если загрузка прошла успешно, БП запоминает, что последнее принятое сообщение от ЗУП имеет номер 10. При следующей выгрузке из БП в сторону ЗУП (даже если данных для передачи нет) в заголовке XML-файла будет передана техническая информация: «Я успешно получила твое сообщение №10».
Этап 3: Снятие регистрации в ЗУП. Когда ЗУП принимает файл от БП, она первым первым делом смотрит на номер подтвержденного сообщения. Увидев число 10, ЗУП выполняет команду:
ПланыОбмена.УдалитьРегистрациюИзменений(УзелОбмена, 10);
Только после этого объекты, у которых номер сообщения был меньше или равен 10, исчезают из таблицы регистрации и больше не выгружаются.
Проанализируем содержимое самого файла обмена. Если открыть его текстовым редактором, в самом начале можно увидеть блок Header (или его аналог в зависимости от формата EnterpriseData). Нас интересуют два ключевых атрибута:
Посмотрим на пример логики: если ЗУП отправила файл с MessageNo = 50, то регистрация снимется только тогда, когда она получит от БП файл, где в поле ReceivedNo будет стоять число 50 или выше. Это гарантирует, что если файл потеряется или в процессе загрузки произойдет сбой (например, отключится электричество), данные не будут считаться переданными и выгрузятся повторно при следующем сеансе.
Иногда пользователи сталкиваются с тем, что одни и те же документы «гуляют» между базами постоянно. Проанализируем основные причины такой ситуации:
Если вы хотите убедиться, какие именно объекты ожидают отправки и какой номер сообщения им присвоен, можно воспользоваться запросом к виртуальной таблице изменений. Рассмотрим пример для документа «Начисление зарплаты»:
ВЫБРАТЬ
Изменения.Ссылка КАК Документ,
Изменения.НомерСообщения КАК НомерПакета
ИЗ
Документ.НачислениеЗарплаты.Изменения КАК Изменения
ГДЕ
Изменения.Узел = &УзелОбмена
В колонке НомерСообщения вы увидите либо NULL (объект зарегистрирован, но еще ни разу не включался в файл), либо конкретное число (объект уже был отправлен, но база-источник еще не получила подтверждение о его доставке).
В современных версиях ЗУП 3.1 и БП 3.0 используется универсальный формат EnterpriseData. Механизм квитирования здесь работает по тем же принципам Планов обмена, но сама структура файла более сложная. Выясним важный нюанс: при обмене через универсальный формат подтверждение об успешном приеме передается даже в том случае, если в базе-приемнике не было создано новых объектов (например, если присланный объект идентичен текущему по версии). Это позволяет «разгружать» таблицы регистрации изменений в источнике, не засоряя базу-приемник лишними записями.
Таким образом, мы выяснили, что обмен в 1С — это всегда двусторонний диалог. База-приемник не просто молча принимает данные, она отправляет «уведомление о вручении», которое является единственным законным основанием для базы-источника очистить свою очередь выгрузки.