Переход на формат фискальных данных (ФФД) 1.2 и введение разрешительного режима для маркированных товаров (в частности, обуви) ставят перед разработчиками сложные задачи, особенно когда речь идет об устаревших конфигурациях, таких как УТ 10.3. В этой статье мы подробно разберем, как адаптировать систему для работы с новыми требованиями, правильно сформировать XML-пакеты для драйверов АТОЛ и обеспечить корректную проверку кодов маркировки (КМ).
Одной из главных технических трудностей является обработка управляющего символа Group Separator (GS), имеющего ASCII-код 29. Платформа 1С при передаче строки через экранные формы или промежуточные переменные часто «теряет» этот непечатный символ, что делает код маркировки невалидным для фискального накопителя.
Проанализируем ситуацию: чтобы касса приняла код, он должен быть передан в формате Base64, причем исходная строка обязана содержать все разделители. Рассмотрим правильный подход к формированию строки маркировки перед отправкой в драйвер:
// Пример восстановления символа GS, если он был потерян при чтении
ЛевСтр = Лев(ПараметрыОперации.КонтрольнаяМарка, 31);
Длина = СтрДлина(ПараметрыОперации.КонтрольнаяМарка);
ПравСтр = Прав(ПараметрыОперации.КонтрольнаяМарка, Длина - 31);
Длин = СтрДлина(ПравСтр);
// Склеиваем с использованием Символ(29) и переводим в Base64
МаркаДляДрайвера = ЛевСтр + Символ(29) + Лев(ПравСтр, 6) + Символ(29) + Прав(ПравСтр, Длин - 6);
ЗаписьXML.ЗаписатьАтрибут("MarkingCode", XMLСтрока(ШтрихкодированиеИСКлиентСервер.ШтрихкодВBase64(МаркаДляДрайвера)));
Важный совет: старайтесь выполнять преобразование в Base64 сразу после сканирования кода в обработке внешнего события, не сохраняя «сырой» код в текстовые реквизиты документа, доступные для интерактивного редактирования.
Согласно требованиям ФФД 1.2, перед пробитием чека ККТ должна выполнить запрос к информационной системе маркировки (ОИСМ). В 1С:УТ 10.3 этот механизм приходится реализовывать вручную через методы драйвера ЗапросКМ и ПолучитьРезультатыЗапросаКМ.
Разберем по шагам алгоритм взаимодействия с драйвером:
ОткрытьСессиюРегистрацииКМ.ЗапросКМ, передавая параметры товара и код в Base64.Посмотрим на пример реализации цикла ожидания с использованием системной паузы:
WS = Новый COMОбъект("WScript.Shell");
КомандаWindows = "cmd /c timeout /t 1 /nobreak"; // Пауза в 1 секунду
Для Попытка = 1 По 60 Цикл // Ждем до 60 секунд
WS.Run(КомандаWindows, 0, -1);
Результат = ОбъектДрайвера.ПолучитьРезультатыЗапросаКМ(ПараметрыПодключения.ИДУстройства, ВходныеПараметры, ВыходныеПараметры);
Если Результат Тогда
Статус = ВыходныеПараметры.Получить(0).СтатусРезультата;
Если Статус = Перечисления.СтатусРезультатаЗапросаКМ.Получен Тогда
// Обработка успешного ответа, сохранение ИдентификатораСессии и UUID
Прервать;
ИначеЕсли Статус = Перечисления.СтатусРезультатаЗапросаКМ.НеМожетБытьПолучен Тогда
// Обработка ошибки
Прервать;
КонецЕсли;
КонецЕсли;
КонецЦикла;
В современных версиях платформы вместо вызова WScript.Shell рекомендуется использовать встроенную функцию ВызватьПаузу(1000).
После успешной проверки кода маркировки необходимо передать данные в пакет ДанныеЧекаXML. Для ФФД 1.2 структура узла позиции (Item) значительно усложняется. Выясним, какие атрибуты являются критичными:
MarkingCode — код маркировки в Base64.PlannedStatus — планируемый статус (обычно "1" для продажи).MeasureOfQuantity — мера количества (тег 2108). Для штучного товара в драйверах АТОЛ часто используется значение "255".AttributeValue — содержит UUID сессии и метку времени проверки. Без этого атрибута касса может выдать ошибку «Контрольная марка не проверена».Пример фрагмента XML-структуры:
<Item Name="Ботинки мужские"
Quantity="1"
PriceWithDiscount="5000"
Amount="5000"
Department="1"
TaxCode="1"
ItemType="1"
MeasureOfQuantity="255">
<MarkingCode="MDEwNDYyNzE2MTc3MjU3NTIxNW9YQXU5bFpt..." />
<PlannedStatus="1" />
<AttributeValue="UUID=7f663d7c-b6b5-4c1c-9746-460c2c902af0&Time=1738399947946"/>
</Item>
Проанализируем ситуацию возврата. В случае возврата товара от покупателя необходимо выполнить те же действия, что и при продаже, но с изменением планируемого статуса. Товар должен вернуться в оборот.
В XML-пакете для возврата (ВозвратПрихода) устанавливайте PlannedStatus="3" (ШтучныйТоварВозвращен). Это сигнализирует системе «Честный Знак», что данный код маркировки снова становится активным и доступным для последующей перепродажи. Если проверка КМ при возврате невозможна (например, марка повреждена), оформляется возврат без кода, но с последующей перемаркировкой через личный кабинет ОИСМ.
Если при попытке пробития чека вы получаете ошибку «Неверный формат команды», проверьте следующие настройки:
УстановитьПараметры) ревизия должна быть не ниже 3000. Именно с этой ревизии начинается полноценная поддержка ФФД 1.2.Рассмотрим важный нюанс: если касса работает в режиме offline (без интернета), полноценная проверка в ОИСМ не пройдет. В этом случае касса должна печатать на чеке символ [M] вместо [M+]. Для корректной работы в этом режиме в коде 1С нужно обрабатывать тайм-ауты и разрешать фискализацию, даже если онлайн-ответ не был получен в отведенное время (регулируется флагом ОжидатьПолучениеОтветаОИСМ).
Используя приведенные выше примеры и рекомендации, вы сможете обеспечить стабильную работу маркировки обуви в 1С:УТ 10.3, соблюдая требования законодательства по ФФД 1.2.