При настройке обмена данными между конфигурациями часто возникает необходимость переноса информации о пробитых чеках. Например, когда чеки физически пробиваются в одной программе (например, «Альфа-Авто»), а бухгалтерский и управленческий учет ведется в другой — «1С:Комплексная автоматизация» (КА) или «1С:ERP Управление предприятием». В современных конфигурациях статус чека в документе (отображение гиперссылки «Чек пробит» или «Чек не пробит») напрямую зависит от наличия записей в регистрах фискальных операций.
В этой статье мы подробно разберем, как решить технические сложности при переносе фискальных данных с помощью конфигурации «Конвертация данных 2.1» (КД2). Мы выясним причину дублирования записей, разберемся с назначением регистров и настроим правильную выгрузку данных «прицепом» к документам без использования лишних правил выгрузки данных (ПВД).
Сначала проанализируем ситуацию с дублированием регистров в типовых конфигурациях 1С. В процессе развития Библиотеки подключаемого оборудования (БПО) фирма 1С изменила архитектуру хранения фискальных чеков:
ЖурналФискальныхОпераций — устаревший регистр. Он активно использовался в старых версиях БПО (до перехода на форматы фискальных данных ФФД 1.05 и 1.2, ориентировочно до весны 2019 года). В современных конфигурациях он оставлен исключительно для обратной совместимости, чтобы при обновлении не потерялись старые данные.ФискальныеОперации — актуальный рабочий регистр сведений. Именно на его основе современные документы КА 2, ERP 2 и УТ 11 определяют статус фискализации (пробит чек или нет).Вывод: При настройке правил обмена в КД2 переносить данные необходимо только в регистр сведений ФискальныеОперации. Наполнение старого регистра ЖурналФискальныхОпераций больше не требуется.
Регистр сведений ФискальныеОперации имеет два ключевых измерения: ДокументОснование (документ, по которому пробит чек) и ИдентификаторЗаписи (уникальный GUID попытки фискализации).
Если при выгрузке генерировать ИдентификаторЗаписи динамически через создание нового GUID:
Если Не ОбъектНайден Тогда
Объект.ИдентификаторЗаписи = Строка(Новый УникальныйИдентификатор());
КонецЕсли;
То при каждом повторном обмене данными для одного и того же документа будет создаваться новая запись в регистре, так как КД2 не сможет сопоставить существующую запись. Для решения этой проблемы мы должны использовать детерминированный идентификатор — уникальную строку, которая всегда будет одинаковой для одного и того же документа-источника при любых повторных выгрузках.
Рассмотрим два варианта формирования такого идентификатора:
Вариант А. На один документ в источнике всегда приходится только один чек.
В этом случае идеальным решением будет использование уникального идентификатора (GUID) самого документа-источника. Нам нужно получить GUID документа и передать его в качестве измерения ИдентификаторЗаписи.
Вариант Б. У одного документа может быть несколько чеков (например, предоплата и доплата).
В этом случае к GUID документа-источника необходимо добавить уникализирующий суффикс, например, номер чека или номер смены. Пример формирования строки:
Строка(Источник.Ссылка.УникальныйИдентификатор()) + "_" + Строка(Выборка.НомерЧекаККМ)
Многие разработчики совершают ошибку, создавая отдельные Правила выгрузки данных (ПВД) для регистра сведений и пытаясь настроить там сложные отборы. На самом деле, регистр сведений ФискальныеОперации жестко подчинен документам-основаниям. По стандарту КД2 такие данные должны выгружаться автоматически вместе с самим документом.
Рассмотрим по шагам, как это реализовать:
ФискальныеОперации. Источник оставляем пустым, Приемник выбираем РегистрСведенийСсылка.ФискальныеОперации.ДокументОснование и ИдентификаторЗаписи.ПриходныйКассовыйОрдер) переходим в обработчик события После выгрузки и пишем программный код выгрузки записей регистра.Проанализируем пример кода для обработчика После выгрузки в ПКО документа:
// Запрос для получения фискальных реквизитов из базы-источника.
// В зависимости от конфигурации источника (например, Альфа-Авто),
// данные могут храниться в реквизитах самого документа или связанных регистрах.
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| Док.Ссылка КАК ДокументОснование,
| Док.Организация КАК Организация,
| Док.СуммаДокумента КАК Сумма,
| Док.НомерЧека КАК НомерЧекаККМ,
| Док.НомерСмены КАК НомерСменыККМ,
| Док.КассаККМ.ЗаводскойНомер КАК РегистрационныйНомерККТ
|ИЗ
| Документ.ПриходныйКассовыйОрдер КАК Док
|ГДЕ
| Док.Ссылка = &ТекущийДокумент";
Запрос.УстановитьПараметр("ТекущийДокумент", Источник.Ссылка);
Выборка = Запрос.Выполнить().Выбрать();
Пока Выборка.Следующий() Цикл
// Создаем структуру для передачи параметров в ПКО регистра
ПараметрыЗаписи = Новый Структура;
ЗаполнитьЗначенияСвойств(ПараметрыЗаписи, Выборка);
// Формируем детерминированный ИдентификаторЗаписи на основе GUID документа
ИдентификаторСвязи = Строка(Источник.Ссылка.УникальныйИдентификатор());
ПараметрыЗаписи.Вставить("ИдентификаторЗаписи", ИдентификаторСвязи);
// Выгружаем запись регистра сведений по правилу конвертации
ВыгрузитьПоПравилу(,, ПараметрыЗаписи,, "ФискальныеОперации");
КонецЦикла;
Использование этого метода решает сразу несколько серьезных проблем интеграции:
ФискальныеОперации выгружаются строго вместе со своими документами-основаниями. Ситуация, когда запись регистра загрузилась, а документ нет (или наоборот), полностью исключена.ИдентификаторЗаписи на основе GUID документа-источника, повторный обмен будет корректно перезаписывать существующие записи регистра в приемнике, а не создавать новые дубли.