QR-штрихкод на кассовом чеке

Я даже не называл бы это «статьёй» или «публикацией». Это скорее заметка, по итогам потраченного времени.

Дело в том, что мне и коллегам за неделю поисков не удалось найти в сети адекватную и непротиворечивую информацию о том, что же должен включать двумерный штрихкод, размещённый на чеке, чтобы быть адекватно прочитанным с точки зрения ФНС. Мы знаем, что ФНС запустила мобильное приложение под Андроид для чтения и проверки чеков, мы знаем, что делаются порталы и службы от разных ОФД, мы знаем о сторонних утилитах некоторых умельцев. Тут интернет просто пестрит предложениями проверить ваш чек. А вот если задача стоит — эмулировать этот штрихкод, то сведений нету. Зачем? Например, генерировать электронный чек, чтобы потом посылать его клиенту на е-мейл.

Попытка изысканий в типовых конфигурациях кончилась маловразумительно — стало ясно лишь то, что ни пресловутая большая xml-строка, ни параметры команд логическим устройствам ФР/ККТ не содержат собственно названия товаров. Логично: даже у qr-кода ограниченная вместимость, а чек может быть из десятков позиций и их названия могут быть длинными. Вывод: в qr-коде содержится лишь итоговая информация, которая служит для идентификации уже собственно в базе ФНС и уже по ней, по ключевым полям, прочитанным из штрихкода, будут тянуться подробные сведения чека.

Найденная в Рознице 2.0 механика давала невалидную строку. Уж не знаю, когда поменялся стандарт, но весенний релиз не подошёл.

Поэтому сделали просто: отсканировали кучу разных чеков с самых разных мест пробития, и экстраполировали.

Итого, формат получился следующий: 

t=ДатаТВремя&s=СуммаСКопейкамиБезТриад&fn=НомерФискальногоНакопителяККТ&i=НомерФискальногоДокументаЧека&fp=УникальныйыФискальныйПризнакЧека&n=УСН

Или, если в коде,

    ТекстНаQR="t="+Формат(ДатаВремяЧека,"ДФ=ггггММддТЧЧммсс")+
разд+"s="+Формат(ОбщаяСуммаЧека,"ЧРД=,;ЧЦ=10;ЧДЦ=2;ЧН=0,00;ЧГ=0")+
разд+"fn="+СокрЛП(НомерФНвашегоККТ)+
разд+"i="+Формат(ТекущийЧекФД,"ЧГ=0")+
разд+"fp="+Формат(ТекущийЧекФП,"ЧГ=0")+
разд+"n="+?(ЭтоУСН,"0","1");

Причём: номер ФН это свойство аппарата, зашитое в нём; можно прочитать с любого чека и единожды зафиксировать; а вот номер ФД и номер ФП — данные, уникально идентифицирующие каждый чек, поэтому они должны читаться программно. Штатный способ для семейства драйверов Штрих-М выглядит примерно следующим образом:

Функция ПолучитьФДиФП(фр)
фр.Password=30; // административные права
рез=фр.FNGetStatus();
Если рез<>0 Тогда
Возврат Неопределено; // ошибка
КонецЕсли;
фд=фр.DocumentNumber;
рез=фр.FNFindDocument();
Если рез<>0 Тогда
Возврат Неопределено; // ошибка
КонецЕсли;
фп=фр.FiscalSign;
Возврат Новый Структура("ФД,ФП",фд,фп);
КонецФункции

Замечу: вроде бы, согласно руководствам, независимо от фр.DocumentType всегда есть правильный FiscalSign, но на практике встретились случаи, когда ФР возвращает верное значение в утилите драйвера, и неверное — в программном обращении из 1С. Если он вернул вам отрицательное значение — значит, неверно. Причину пока понять не удалось, некоторые источники в сети кивают на кривую прошивку. Также замечу: был добавлен метод FNGetFiscalizationResultByNumber, но он есть только в самых свежих прошивках. Про АТОЛ и прочие вики вообще ничего сказать не могу.

Признак УСН — 0 (если ОСН) или 1 (если УСН), другие системы не знаю, как отражаются, не попалось таких чеков. Кто знает — отпишитесь, пожалуйста. Вообще, знающие да скажут больше)

Ну и чтоб не так грустно было, вот простенькая обработочка для генерации QR-кодов, под обычные формы и УФ. Авось кому пригодится.