Здравствуйте. У нас УТ 10.3, марка приходит в ОФД, но не попадает в ЧЗ, даже на закладку Чеки. Техподдержка ЧЗ утверждает, что к ним наши запросы, вообще, при приходят... Но в ОФД же есть и отображается...

(0) Но в ОФД же есть и отображается...

Не стесняйтесь, расскажите подробнее.
Что есть и отображается?
Какой тег с маркой?
Какой ОФД?
Какая касса?
Какая прошивка?
Какой драйвер?
Какая связь? Порт ОИСМ настроен?
На чеке [M+] есть?
После чего это стало так, или никогда не работало?

Отправкой продаж марок занимается сам кассовый аппарат, через ОФД в ОИСМ, но, должна правильно марка передаваться в него, в правильный тег и в правильном формате из программы...

У нас ФД 1.2, первые 31 символ от маркировки переводим в двоичные данные, кодируем в base64 и передаем в GoodCodeData, тег 1163, в нем в GS1.M. КМ, для примера, 0104813352025241215j58lgocctxeb91EE1092xb/NeJ0eYCT0CZrP5PxFvUOM1FPBQIwHfgw/x97bnsE=
ОФД Ярус, с него приходит и видно КМ, скрин во вложении.
Но, настораживает, что в ОФД отображается как GS1.0, хотя передаем GS1.M.
Касса Штрих-М сити,
Версия ПО               : C.3
Сборка ПО               : 62778
Дата ПО                 : 29.08.2025

Драйвер 5.18, в таблицах настройка сервера и порта для передачи КМ верные. Но в ЧЗ даже на закладке Чеки пусто...

(2) У нас ФД 1.2, первые 31 символ от маркировки переводим в двоичные данные, кодируем в base64 и передаем в GoodCodeData, тег 1163, в нем в GS1.M.

Зачем? Что-то Вы перепутали... Так делалось раньше, на "заре маркировки", когда еще ФФД-1.05 был и тег 1162...
Для ФФД-1.2, марка передается "как есть", целиком, со всеми разделителями GS1, и ни во что не кодируется.

Вот фрагмент из обработки Штриха, с комментариями:

// Перед таблицей чека:
    Если ФискальныйРегистратор.ECRMode             = 4 Тогда
        ФискальныйРегистратор.FNBeginOpenSession();
        Если СокрЛП(глПользователь.Сотрудник.ИНН)         <> "" Тогда
            ФискальныйРегистратор.TagNumber                = 1203;
            ФискальныйРегистратор.TagType               = 7;
            ФискальныйРегистратор.TagValueStr            = СокрЛП(глПользователь.Сотрудник.ИНН);
            ФискальныйРегистратор.FNSendTag();
        КонецЕсли;        
        Рез = ФискальныйРегистратор.FNOpenSession();               // Открываю смену, если закрыта
    КонецЕсли

ФискальныйРегистратор.CheckType = 0;
Рез    = ФискальныйРегистратор.OpenCheck();

// Дальше, в цикле, формируем строки чека.
// Ну, то, что не связано с маркировкой, пропущу...

        Рез = ФискальныйРегистратор.FNOperation();

// Обязательно!!! ДО передачи марки начинаем FNOperation
        
        Если ПустоеЗначение(ОбрДок.КТН) = 0 Тогда
            
            КТН                                     = СтрЗаменить(СокрЛП(ОбрДок.КТН), "(GS1)", Симв(29));

// Это у меня "восстановление" символов GS, так, как в строках документа я их хранить не могу, первое ТиИ - грохнет их, как недопустимые символы в текстовом поле(но, это клюшки, в 8-рке не знаю, может и умеет хранить "как есть").
            
            Если ОбрДок.Касса.ФФД_ККТ                 = Перечисление.ФФД_ККТ.ФФД1_2 Тогда
                            ФискальныйРегистратор.BarCode         = КТН;
                Рез                                 = ФискальныйРегистратор.FNSendItemBarcode();

Вот, марку передали, а дальше уже все остальное.

(2) в ОФД отображается как GS1.0, хотя передаем GS1.M.

Дык правильно, внутренний софт ККТ не распознает марку, после того, что Вы с ней сделали.

PS Проверка марки и по РР и по ОИСМ, у меня идет при добавлении товарной позиции/марки в чек, при печати чека марка уже проверена, добавление составного 1260 для РР я тут не стал приводить, это уже "отдельная песня", если надо отдельно напишу. А проверка по ОИСМ - прошла при добавлении марки в чек, так-же там передается полный код марки, и здесь, при закрытии чека, так-же по полному коду марки этот результат сама ККТ "вытягивает" из своего буфера. Проверка по ОИСМ на каждую марку должна была быть обязательно, и храниться в буфере ККТ, иначе будет ошибка.

Спасибо, попробую. Просто странно, что в ОФД все определяется... Да и Вы работаете напрямую с драйвером кассы, а у нас через обработку обслуживания, т.е. через компоненту.

(0) В ОФД наверняка в карантине. Ждите письмо с налоговой

(4) Да и Вы работаете напрямую с драйвером кассы

Да, это пример под 7.7, или любую программу, которая с драйвером напрямую умеет работать...

Под компоненту - все тоже самое, просто там нужно смотреть ревизию компоненты и обработки, что-бы она тоже под ФФД-1.2 была, там марка тоже целиком, как есть, должна передаваться. Что-то это: "первые 31 символ от маркировки переводим в двоичные данные, кодируем в base64 и передаем в GoodCodeDat" мне очень ФФД-1.05 напоминает, там именно на подобии такого кодировались КМ...
(0) У нас УТ 10.3
А компонента, и обработка обслуживания тоже из нее, типовые? Тогда, может в этом и причина - они устаревшие?

Я не знаю, что и как отображает Ярус, я с ним не работаю...
Но, вот, как марка видна в 1-ОФД:
В режиме просмотра чека:



А это если скачать текстовиком чек, у них он называется TLV, хотя, имхо с форматом TLV это не имеет ничего общего:



Как видите - марка целиком.
Ни каких "44 4D", отдельно GTIN, серийник - там нет, это все было по ФФД-1.05...

(4) А точно ли у вас максимально крайняя обработка обслуживания?
К примеру, тут: https://releases.1c.ru/additional_file?nick=TradeWareEpf82&path=TradeWare%5cExtrafiles%5cATOLkkt.epf
обработка от 29.08.2025, драйвер не ниже 5.20 требуется. Вообще, Штрихи НЯП всегда отстают в плане каких-либо новых тегов.

(7) https://releases.1c.ru/additional_file?nick=TradeWareEpf82&path=TradeWare%5cExtrafiles%5cShtrihMkkt.epf
Не та ссылка, пардон, вот эта Штрих.

(8) Все это хорошо конечно. Но большой вопрос - заработает ли  эта обработка под УТ 10.3 топик-стартера...

(2) А что за футболка такая, если не секрет, за пять с половиной тыр?! О.о

Спасибо, попробую.

(10) Какой-то мерч на неумеренный ценник.