Ситуация, при которой кассовый аппарат выполняет печать двух фискальных документов для одной операции продажи маркированного товара, является критической. Это не только приводит к излишнему расходу чековой ленты, но и создает серьезные риски для бизнеса, так как налоговые органы могут расценить это как нарушение правил применения контрольно-кассовой техники. Давайте разберем по шагам, почему возникает эта проблема и какие методы помогут ее устранить.
Основная причина заключается в нарушении последовательности обмена данными между 1С:ERP и фискальным регистратором Штрих-М. Процесс продажи маркированного товара подразумевает два этапа:
ФН (фискальный накопитель).Если используемый драйвер оборудования или прошивка ККТ устарели, они могут неверно интерпретировать команду проверки кода маркировки как команду на завершение фискального чека. В итоге касса печатает «пустой» или частичный чек, а после получения подтверждения от ИС МП, 1С отправляет команду на печать второго, уже полного чека. Именно поэтому в 1С документ создается один, а на ленте мы видим два разных фискальных номера.
Прежде чем приступать к доработке конфигурации, необходимо исключить аппаратные ошибки. Выполним следующие действия:
Драйвер ККТ от производителя. Устаревшие библиотеки часто не поддерживают корректную работу с новыми тегами ФФД 1.2.ФФД 1.2. Именно эта версия формата создана специально для работы с маркировкой и имеет наиболее стабильные механизмы взаимодействия с кодами товаров.Если обновление драйверов не дало результата, необходимо реализовать проверку «на лету» средствами 1С. Суть метода заключается в создании своеобразного «предохранителя» перед отправкой команды фискализации в кассу. Давайте рассмотрим логику реализации:
Нам необходимо перед вызовом функции фискализации проверять текущее состояние чека или наличие записи в регистре, подтверждающей, что печать по данному коду маркировки уже была запущена. Рассмотрим примерную логику работы:
// Пример логики для реализации проверки перед печатью
Функция ВыполнитьФискализацию(ДанныеЧека)
// Проверяем наличие записи в регистре о текущей попытке печати
Если РегистрыСведений.СтатусПечатиЧеков.СуществуетЗапись(ДанныеЧека.ИдентификаторМарки) Тогда
Возврат Неопределено; // Блокируем повторную отправку
КонецЕсли;
// Записываем статус «В процессе печати»
РегистрыСведений.СтатусПечатиЧеков.ЗаписатьСтатус(ДанныеЧека.ИдентификаторМарки);
// Далее вызов штатной функции фискализации
Результат = ФискальныйРегистратор.НапечататьЧек(ДанныеЧека);
Возврат Результат;
КонецФункции
Используя данный подход, вы исключаете отправку дублирующих команд в драйвер. Если первая команда проверки уже инициировала процесс, вторая попытка будет заблокирована кодом 1С.
Если проблема сохраняется, включите расширенное Логирование в настройках драйвера Штрих-М. Это позволит увидеть детальный лог команд, уходящих в кассу. Анализируя логи, ищите команды, которые предшествуют печати первого (ошибочного) чека. Если вы видите, что отправляется команда фискализации вместо команды проверки, значит, проблема однозначно в интерпретации данных драйвером.
Важное примечание: При работе с маркировкой всегда учитывайте наличие признака успешной проверки [M+]. Если в ОФД уходят чеки без данного признака, это означает, что проверка марки по каким-то причинам не была выполнена, что также является нарушением. Всегда проверяйте актуальность настроек в справочнике Подключаемое оборудование в вашей 1С:ERP.
Решение проблемы «задвоения» — это комплексная задача. Начните с обновления программного обеспечения кассы, так как в 90% случаев это устраняет несовместимость протоколов. Если аппаратная часть работает исправно, примените программную блокировку в 1С, чтобы защитить систему от отправки дублирующих команд в условиях сетевых задержек или сбоев обмена с Честным ЗНАКом.