При интеграции 1С с контрольно-кассовой техникой (ККТ) перед разработчиками и аналитиками часто встает задача вывода на чек различной сопроводительной информации. Это могут быть маркетинговые сообщения, информация о накопленных бонусах, условия проведения акций, гарантийные обязательства или просто вежливое напутствие клиенту. В XML-пакете, который формирует 1С для передачи в драйвер кассы, для этих целей предусмотрен специальный тег текстовых строк. Однако критически важно понимать, куда именно попадают эти данные: остаются ли они только на бумажной ленте или уходят дальше — оператору фискальных данных (ОФД) и в Федеральную налоговую службу (ФНС).
В этой статье мы подробно разберем механизм обработки нефискального текста в ККТ, выясним особенности работы современных форматов фискальных документов (ФФД) и рассмотрим гарантированные способы передачи дополнительных реквизитов на серверы налоговой службы.
Рассмотрим стандартный XML-пакет CheckPackage, который передается из учетной системы 1С в драйвер ККТ для пробития чека. В структуре XML-документа мы можем использовать специализированный тег:
<TextString Text="Спасибо за покупку! Ваш промокод на следующую скидку: 1С_2025" />
Давайте проанализируем путь этой строки с момента формирования пакета в 1С до момента выхода чека из печатающего устройства кассы:
TextString, он распознает его как команду прямой печати нефискальной текстовой информации.Вывод для разработчика: Использовать произвольные текстовые строки TextString можно только для визуального информирования покупателя, который забирает физический бумажный чек. Если клиент запрашивает исключительно электронный чек (на email или по SMS), то он вообще не увидит информацию, переданную через TextString, поскольку в электронной версии чека, сформированной ОФД, этих данных просто не будет.
Что же делать, если перед нами стоит задача передать в ОФД и ФНС конкретные дополнительные данные (например, уникальный идентификатор клиента, номер договора, ID транзакции во внешней системе)? Для этого в форматах фискальных документов ФФД 1.05, 1.1 и 1.2 предусмотрен специализированный реквизит — тег 1084 («Дополнительный реквизит пользователя»).
Среди разработчиков долгое время бытовало мнение, что данный тег остался лишь на бумаге в требованиях ФНС и не поддерживается реальными кассовыми аппаратами. Давайте выясним истинное положение дел. На сегодняшний день тег 1084 полностью и штатно поддерживается программным обеспечением (прошивками) всех ведущих производителей ККТ (включая АТОЛ, Штрих-М, Инкотекс/Меркурий) и без проблем обрабатывается всеми аккредитованными ОФД.
Тег 1084 представляет собой составной реквизит (структуру), состоящую из двух дочерних тегов:
Давайте посмотрим на пример того, как эти теги передаются в составе фискального документа из 1С через XML-пакет. В структуре XML-документа для этого описываются специальные свойства параметров чека:
<AdditionalUserAttribute>
<Name>Договор поставки</Name>
<Value>№ А-154 от 12.10.2024</Value>
</AdditionalUserAttribute>
При обработке такой структуры драйвер кассы дает команду фискальному накопителю записать данные тега 1084 в тело фискального документа. Эти данные подписываются криптографической подписью ФН, уходят в ОФД и отображаются в электронной версии чека в личном кабинете налогоплательщика и в официальном приложении ФНС «Проверка чеков».
Техническое ограничение: При проектировании выгрузки этих данных обязательно учитывайте ограничения ККТ на длину текстовых полей. Как правило, длина наименования реквизита (тег 1085) ограничена 64 символами, а длина значения (тег 1086) не должна превышать 256 символов. Превышение этих лимитов может привести к ошибке генерации чека на уровне драйвера.
Изучая спецификации ФФД, вы можете столкнуться с еще одним похожим реквизитом — тегом 1192 («Дополнительный реквизит чека»). Разберем по шагам, почему не стоит использовать его для передачи произвольных пользовательских данных.
Тег 1192 жестко регламентирован ФНС России и имеет строгое целевое назначение. Наиболее частый сценарий его использования — оформление чеков коррекции. В данном теге при формировании чека коррекции обязательно указывается фискальный признак (ФПД) того исходного чека, который вы корректируете или аннулируете. Если попытаться записать в тег 1192 произвольный текст (например, маркетинговую информацию), то чек с высокой долей вероятности не пройдет форматно-логический контроль (ФЛК) на стороне сервера ОФД или налоговой службы и будет отвергнут как некорректный. Для пользовательских целей всегда выбирайте исключительно тег 1084.
Для того чтобы убедиться, уходят ли ваши данные в ОФД, нет необходимости проводить тесты на «боевой» кассе с реальным фискальным накопителем, тратя при этом деньги и регистрируя ложные продажи в налоговой. Проанализируем, как организовать надежный процесс тестирования:
TextString, там полностью отсутствуют, в то время как реквизит "Дополнительный реквизит пользователя" (тег 1084) со всеми значениями успешно отображается на экране.Используя этот подход, мы можем гибко управлять выводом информации: отправлять маркетинговые тексты на печать через TextString, а важную учетную информацию надежно фиксировать в базах данных налоговой службы через тег 1084.