Почему не печатается QR-код на фискальном регистраторе при выводе текста и как это исправить

← На главную

В процессе интеграции систем быстрых платежей (СБП) в старые конфигурации, такие как 1С:Управление торговлей 10.3, программисты часто сталкиваются с ситуацией, когда отработанный механизм печати QR-кода внезапно перестает функционировать. Особенно остро эта проблема проявляется после обновления платформы (например, до версии 8.3.22) или смены драйверов торгового оборудования. В данной статье мы подробно разберем, почему фискальный регистратор начинает печатать ссылку текстом вместо генерации QR-кода, и как это исправить программным путем.

Проблема: QR-код превращается в обычный текст

Рассмотрим классическую ситуацию: для печати нефискального документа (слип-чека) используется стандартный механизм торгового оборудования 1С. Программист формирует массив строк, где одна из строк содержит специальный префикс, указывающий драйверу, что далее следует не текст, а данные штрихкода. Ранее код мог выглядеть следующим образом:


МассивСтрокСлипЧека = Новый Массив;
СсылкаДляГенерацииКода = "https://qr.nspk.ru/97c3358659a149e0a53f8e8b38...";
МассивСтрокСлипЧека.Добавить("ШтрихКод|QR|" + СсылкаДляГенерацииКода);

РезультатФР = ПолучитьСерверТО().ПечатьТекста(ФР, МассивСтрокСлипЧека, ШиринаЧека);

После определенных обновлений системы или платформы этот код перестает работать корректно: касса просто печатает на чековой ленте строку ШтрихКод|QR|https://.... Это происходит потому, что внутренняя логика обработки обслуживания (или сам драйвер ККТ) перестает распознавать управляющую команду в начале строки.

Разбор работы метода ПечатьТекста()

Давайте проанализируем, что происходит внутри функции ПечатьТекста. В большинстве типовых решений на обычных формах эта функция обращается к объекту драйвера через обработку обслуживания:


Функция ПечатьТекста(Идентификатор, МассивСтрокСлипЧека, ШиринаЧека) Экспорт
    Обработка = Неопределено;
    Объект    = Неопределено;
    Результат = ПолучитьОбъектДрайвера(Идентификатор, Обработка, Объект);
    
    Если НЕ ЗначениеЗаполнено(Результат) Тогда
        // Вызов метода печати в обработке обслуживания
        Результат = Обработка.НапечататьСтроки(Объект, МассивСтрокСлипЧека, ШиринаЧека);
    Иначе
        // Обработка ошибки подключения
    КонецЕсли;
    Возврат Результат;
КонецФункции

Метод НапечататьСтроки внутри обработки обслуживания (файл формата .epf) преобразует переданный массив в XML-пакет, который затем отправляется непосредственно в драйвер ККТ. Проанализируем структуру этого XML:


<?xml version="1.0" encoding="UTF-8"?>
<Document>
    <Positions>
        <TextString Text="ШтрихКод|QR|https://qr.nspk.ru/..."/>
    </Positions>
</Document>

Здесь мы видим тег TextString. Это критически важный момент: драйвер воспринимает содержимое этого тега как обычный текст. Однако в старых драйверах АТОЛ и Штрих-М была заложена логика «самостоятельного распознавания». Если строка начиналась с ключевого слова ШтрихКод, драйвер пытался переключиться в режим печати графического кода. Любое изменение в парсинге строки (например, добавление невидимых символов или изменение кодировки платформой 8.3.22) ломает это распознавание.

Решение №1: Использование корректного разделителя (Вертикальная черта)

Как показывает практика и опыт форумчан, для восстановления работоспособности необходимо явно указать разделитель в начале строки. Изменим формирование строки штрихкода, добавив символ | перед ключевым словом:


// Было:
// МассивСтрокСлипЧека.Добавить("ШтрихКод|QR|" + СсылкаДляГенерацииКода);

// Стало (рабочий вариант):
МассивСтрокСлипЧека.Добавить("|ШтрихКод|QR|" + СсылкаДляГенерацииКода);

Почему это помогает? Внутри многих обработок обслуживания для 1С используется функция РазложитьСтрокуВМассивПодстрок. Когда строка начинается сразу с текста, индекс первого элемента может определяться некорректно в зависимости от версии платформы или используемых регулярных выражений. Добавление | в начало гарантирует, что первым элементом массива после разложения будет «пустая строка», а вторым — команда ШтрихКод. Для многих внутренних парсеров 1С это является триггером для корректной идентификации команды.

Решение №2: Переход на использование тега Barcode (Современный метод)

Если решение с вертикальной чертой не помогает, или вы хотите сделать интеграцию более надежной, следует пересмотреть способ формирования XML-пакета. Согласно современным стандартам 1С для работы с ККТ, штрихкоды должны передаваться не в теге TextString, а в специализированном теге Barcode.

Правильная структура XML для печати QR-кода должна выглядеть так:


<Document>
    <Positions>
        <Barcode Type="QR" ValueBase64="W0RUWF0gaHR0cHM6Ly9xyi5uc3BrLnJ1Lz..."/>
    </Positions>
</Document>

Обратите внимание на следующие моменты:

Используется атрибут ValueBase64. Текст ссылки должен быть предварительно сконвертирован в формат Base64. В платформе 1С это делается встроенной функцией Base64Строка().
Атрибут Type="QR" явно указывает драйверу тип кода, избавляя его от необходимости угадывать формат по косвенным признакам.

Технические нюансы платформы 8.3.22 и выше

Разберем, почему проблема часто возникает именно при обновлении платформы. В новых версиях 1С (начиная с 8.3.22) произошли изменения в механизмах сериализации данных в XML и работе со строками в памяти:

1. Экранирование спецсимволов. Ссылки СБП содержат символы &, ? и =. Если раньше платформа могла передавать их «как есть», то новые версии строго следуют стандартам XML, заменяя, например, & на &. Если драйвер ККТ не ожидает такого экранирования внутри управляющей строки ШтрихКод|QR|..., он не сможет распознать команду.

2. Ограничение длины строки. Ссылки СБП могут быть очень длинными (более 150 символов). У многих моделей фискальных регистраторов (особенно старых серий Штрих-М и АТОЛ) существует жесткое ограничение на длину строки в методе PrintText. Если строка превышает лимит, она обрезается, и управляющая последовательность становится невалидной.