При реализации маркированной продукции (обуви, одежды, парфюмерии и др.) через кассовые аппараты, программисты 1С сталкиваются с необходимостью заполнения специфических атрибутов в XML-пакете, который передается драйверу ККТ. Одним из самых важных и неоднозначных является атрибут MarkingCode в составе структуры GoodCodeData. В этой статье мы подробно разберем, что это за поле, как оно связано с тегом 1162 и как правильно сформировать его значение программно.
Для начала проанализируем нормативную базу. Согласно требованиям ФНС и форматам фискальных документов (ФФД), сведения о маркированном товаре должны записываться в тег 1162 («Код товара»). Однако драйверы торгового оборудования, работающие по стандартам 1С, не принимают «сырой» код DataMatrix напрямую. Вместо этого они ожидают специально подготовленную строку в формате Base64, которая упакована в атрибут MarkingCode.
Этот атрибут представляет собой бинарные данные, которые кассовый аппарат (или фискальный накопитель) может корректно интерпретировать для передачи в ОФД и далее в систему «Честный ЗНАК». Содержимое этого поля напрямую зависит от типа маркируемой продукции.
Разберем ситуацию на примере обувной продукции, которая наиболее часто упоминается в практике. Для того чтобы сформировать корректный MarkingCode, нам необходимо собрать массив байтов, состоящий из трех сегментов:
44 4D (ASCII-символы «DM», что означает Data Matrix). В десятичном представлении, которое часто требуют драйверы (например, «Штрих-М»), это число 17485.Рассмотрим, как это реализовано в типовых конфигурациях (например, в УПП 1.3 или последних версиях БСП). Основная задача — записать данные в поток в правильном порядке байтов (обычно BigEndian) и закодировать результат.
Проанализируем пример кода, который позволяет сформировать это значение вручную:
// Предположим, у нас есть ДанныеМаркировки, содержащие тип, GTIN и серийный номер
Префикс = 17485; // Для обуви (0x444D)
ЗначениеЧисла = "00000046199737"; // Пример GTIN
ЗначениеСтроки = "ic8kvjr"; // Серийный номер
Тело = Новый ПотокВПамяти();
ЗаписьДанных = Новый ЗаписьДанных(Тело);
// 1. Записываем префикс типа маркировки (2 байта)
ЗаписьДанных.ЗаписатьЦелое16(Префикс, ПорядокБайтов.BigEndian);
// 2. Записываем GTIN (в типовых часто используется ЗаписатьЦелое64)
ЗаписьДанных.ЗаписатьЦелое64(Число(ЗначениеЧисла), ПорядокБайтов.BigEndian);
// 3. Добавляем серийный номер, если он есть
Если Не ПустаяСтрока(ЗначениеСтроки) Тогда
ЗаписьДанных.ЗаписатьСимволы(ЗначениеСтроки);
КонецЕсли;
ЗаписьДанных.Закрыть();
РезультатHEX = Тело.ЗакрытьИПолучитьДвоичныеДанные();
// Преобразуем полученный массив байтов в Base64 для передачи в XML
ЗначениеMarkingCode = Base64Строка(РезультатHEX);
Важный нюанс: В разных версиях драйверов и конфигураций порядок записи префикса и GTIN может отличаться. Рассмотрим подробнее: в некоторых случаях префикс пишется в начало потока, в некоторых — в конец. Рекомендуется ориентироваться на актуальную версию БСП вашей конфигурации.
При работе с драйверами разных производителей возникают специфические моменты, которые мы выясним, изучив опыт практикующих специалистов:
FNSendItemCodeData(), вам нужно передать MarkingType = 17485, GTIN и SerialNumber. При этом касса сама может преобразовать эти данные в тег 1162. Если же вы формируете XML самостоятельно, используйте расчет 17485 (10-ичное) для 444D (16-ичное).MarkingCode является стандартным при использовании XML-интерфейса 1С. Важно убедиться, что версия драйвера не ниже 10.6.x, так как в более ранних версиях поддержка тега 1162 могла работать некорректно.MarkingCode в печатной форме чека рядом с наименованием товара должен появиться символ [M]. Если прошивка старая, некоторые разработчики имитируют этот символ нефискальной строкой, однако для корректного списания товара в ЦРПТ это бесполезно — данные должны уйти в электронном виде через тег 1162.Рассмотрим ситуации, когда данные заполнены, но проверка в системе «Честный ЗНАК» не проходит:
1. Неверный префикс: Использование префикса 1520 (десятичное) вместо новых кодов. Ранее для меховых изделий использовались одни идентификаторы, для обуви и одежды — другие (DM). Ошибка в префиксе приведет к тому, что ОФД не сможет «распаковать» GTIN.
2. Ошибки кодирования Base64: Если передать в XML «сырые» байты вместо Base64-строки, парсер XML выдаст ошибку, и чек не будет фискализирован.
3. Лицензии на кассу: У производителей «Штрих-М» и «АТОЛ» работа с тегом 1162 (маркировкой) часто требует платной лицензии на обновление прошивки ККТ. Без действующей лицензии касса может просто игнорировать блок GoodCodeData, даже если он сформирован идеально.
Проанализируем перспективу. Все вышеописанное касается форматов ФФД 1.05 и 1.1. В современном формате ФФД 1.2 подход изменился. Вместо ручной упаковки GTIN и префикса в бинарный код, драйверы позволяют передавать полную строку кода маркировки (вместе с криптохвостом), а ККТ сама выполняет проверку и разбор кода. Если ваша организация перешла на ФФД 1.2, использование MarkingCode в старом бинарном виде может быть избыточным или замещено новыми структурами данных.
В завершение подчеркнем: атрибут MarkingCode — это «мостик» между текстовым кодом DataMatrix и фискальным документом. Правильное бинарное представление GTIN и префикса — залог того, что товар будет успешно выведен из оборота, а ваша компания не получит штрафы от контролирующих органов.