Как реализовать маркировку табака в 1С 7.7 через драйвер Штрих-М

Реализация требований законодательства по маркировке товаров в устаревших конфигурациях на платформе 1С 7.7 — задача нетривиальная. Основная сложность заключается в том, что стандартные средства платформы не всегда корректно взаимодействуют с современными методами драйверов ККТ. В данной статье мы подробно разберем, как правильно передать код маркировки табачной продукции через драйвер Штрих-М, проанализируем типичные ошибки программного кода и рассмотрим нюансы настройки форматов фискальных данных (ФФД).

Разбор механизма передачи кода маркировки

Для того чтобы данные о проданной пачке сигарет попали в систему «Честный ЗНАК», кассовый аппарат должен сформировать и отправить в ОФД тег 1162 («Код товара»). При использовании драйвера Штрих-М для этого чаще всего применяется метод FNSendItemCodeData(). Рассмотрим базовую логику, которую необходимо реализовать в коде 1С 7.7.

Прежде всего, нам необходимо получить строку штрихкода (DataMatrix) с пачки табака. Предположим, что считанный штрихкод записан в переменную ИДТабак. Для корректной передачи данных в драйвер ККТ нам нужно разбить эту строку на составляющие: GTIN и Серийный номер.

Проанализируем пример кода, который изначально содержал ошибку, и выясним причину сбоя:

// Неправильный пример формирования данных
FR.MarkingType = 5; // Указываем тип маркировки (5 - табак)
FR.GTIN = Лев(14, ИДТабак); // ОШИБКА: перепутаны параметры
FR.SerialNumber = Сред(СокрЛП(ИДТабак), 15, 7); 
FR.FNSendItemCodeData();

В приведенном выше фрагменте кода закралась критическая ошибка в использовании функции Лев(). В 1С 7.7 синтаксис функции выглядит следующим образом: Лев(Строка, КоличествоСимволов). Автор перепутал порядок аргументов, в результате чего в драйвер передавались некорректные данные, и хотя чек пробивался без ошибок со стороны ККТ, система «Честный ЗНАК» помечала такие документы как ошибочные.

Корректный алгоритм выделения данных

Рассмотрим исправленный и рабочий вариант реализации. Важно помнить, что GTIN табачной продукции всегда занимает первые 14 символов кода маркировки, а серийный номер следует сразу за ним (обычно это 7 символов для пачки сигарет).

// Правильный пример формирования данных
ИДТабак = СокрЛП(СчитанныйШтрихкод);
// 1. Устанавливаем тип маркировки. Для табака это значение 5
FR.MarkingType = 5; 
// 2. Выделяем GTIN (первые 14 символов)
FR.GTIN = Лев(ИДТабак, 14); 
// 3. Выделяем серийный номер (начиная с 15-го символа, длиной 7 символов)
FR.SerialNumber = Сред(ИДТабак, 15, 7); 
// 4. Вызываем метод драйвера для формирования тега 1162
FR.FNSendItemCodeData();
// 5. После этого вызывается стандартный метод продажи (например, Sale)

Важный нюанс: Перед вызовом FNSendItemCodeData() убедитесь, что объект FR (связь с драйвером) инициализирован и соединение с кассой активно. Также рекомендуется использовать функцию СокрЛП(), чтобы исключить попадание лишних пробелов в начало или конец строки.

Проверка результата в Честном Знаке и ОФД

После пробития чека данные попадают в ОФД. Многие операторы фискальных данных позволяют увидеть тег 1162 в электронном представлении чека. Однако появление чека в личном кабинете «Честного Знака» может занять некоторое время — обычно до 4 часов. Если в ЛК отображается статус «Документ с ошибками», проверьте следующие моменты:

1. Соответствие GTIN: Если в коде маркировки GTIN содержит 13 символов, необходимо добавить лидирующий ноль в начало строки, так как драйвер ожидает ровно 14 знаков.
2. Версия прошивки ККТ: Старые прошивки могут некорректно обрабатывать метод FNSendItemCodeData(). Убедитесь, что ККТ поддерживает работу с маркировкой.
3. Формат JSON: Техподдержка может запросить чек в формате JSON. Этот файл можно выгрузить непосредственно из личного кабинета ОФД или через запрос к API Честного Знака. В нем четко видно, какие именно байты были переданы в составе тега 1162.

Переход на ФФД 1.2: что изменилось

Если ваша организация перешла на формат фискальных данных 1.2, использование старого метода FNSendItemCodeData() может быть недостаточно. ФФД 1.2 подразумевает проверку кода маркировки в реальном времени через фискальный накопитель нового образца (ФН-М). В этом случае процесс усложняется:

Рассмотрим последовательность действий для ФФД 1.2:

1. Запрос проверки кода (метод FnCheckItemBarcode): Программа отправляет полный код маркировки в ККТ. Касса связывается с сервером ОИСМ для получения статуса кода.
2. Получение ответа: Драйвер возвращает результат проверки. Если код валиден, на чеке будет напечатан признак [M+].
3. Подтверждение реализации (метод FnAcceptMarkingCode): После успешной печати чека необходимо подтвердить, что товар выбыл из оборота.

В условиях 1С 7.7 реализовать этот цикл гораздо сложнее из-за асинхронности некоторых процессов. Однако для работы в режиме ФФД 1.05 или 1.1 вышеописанный метод с ручным выделением GTIN и SerialNumber остается актуальным и рабочим.

Особенности обработки спецсимволов GS1

Проанализируем ситуацию, когда сканер штрихкода настроен неправильно. Код маркировки DataMatrix содержит невидимый символ-разделитель GS (ASCII 29). При считывании кода в 1С 7.7 этот символ может превращаться в пробел или вовсе исчезать. Для маркировки табака (пачек) это критично в меньшей степени, чем для блоков, но для надежности рекомендуется настраивать сканер в режим эмуляции COM-порта. В коде 1С при необходимости передачи полной строки можно использовать конструкцию Симв(29) для восстановления структуры кода перед отправкой в драйвер.

Выясним причину возможных «зависаний» при печати чеков с маркировкой. Передача дополнительных данных в ФН увеличивает время обработки чека. Рекомендуем увеличить таймаут в настройках драйвера (обычно в разделе «Свойства» -> «Параметры связи») до 500-1000 мс. Это предотвратит ошибки разрыва связи в момент записи тега 1162 в фискальную память.

Таким образом, для успешной работы с табаком в 1С 7.7 достаточно корректно парсить строку DataMatrix и использовать штатные методы актуальных версий драйвера Штрих-М, внимательно следя за порядком передаваемых параметров.