Я даже не называл бы это "статьёй" или "публикацией". Это скорее заметка, по итогам потраченного времени.
Дело в том, что мне и коллегам за неделю поисков не удалось найти в сети адекватную и непротиворечивую информацию о том, что же должен включать двумерный штрихкод, размещённый на чеке, чтобы быть адекватно прочитанным с точки зрения ФНС. Мы знаем, что ФНС запустила мобильное приложение под Андроид для чтения и проверки чеков, мы знаем, что делаются порталы и службы от разных ОФД, мы знаем о сторонних утилитах некоторых умельцев. Тут интернет просто пестрит предложениями проверить ваш чек. А вот если задача стоит - эмулировать этот штрихкод, то сведений нету. Зачем? Например, генерировать электронный чек, чтобы потом посылать его клиенту на е-мейл.
Попытка изысканий в типовых конфигурациях кончилась маловразумительно - стало ясно лишь то, что ни пресловутая большая 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-кодов, под обычные формы и УФ. Авось кому пригодится.
