Класс для API ГСЦМ «Честный ЗНАК» / ТС ПИоТ

[Игорь Столяров]

Привет всем !

Класс для разрешительной проверки КМ (кодов маркировки) API ГСЦМ "Честный знак" и ТС ПИоТ.
Поддержка целевой реализации в ПО ЛМ "Честный Знак" (обязательна с 01.09.2025 г.) и
проверки КМ с использованием ТС ПИоТ (обязательна с 07.01.2026 г.).
Полный боевой комплект с описанием интерфейса API и примерами.

Благодарность за помощь на старте проекта: FinsoftRZ и Alex412.
Любые замечания, исправления и дополнения - приветствуются !
----------------------------------------------------------------------------------------------------
Рекомендуем использовать актуальные версии классов LibCURL и cJSON.

[Игорь Столяров]

Вроде как его сама ккм автоматически формирует

Ну да. ПМСР пробивает чек на реализацию с выбытием КМ.

И еще написано про тег 2000, который содержит полную марку

Это исходный КМ который подаётся на вход ККТ для распарса. В ФД ОФД это уже тег 1163 -> 1305 с КИЗ

Если код маркировки сформирован (например, в составе реквизита «КТ GS1.М» (тег 1305) или «КТ КМК» (тег 1306)),
тег 2000 принимает значение прочитанного кода маркировки.

Тестовое задание ЕСМ для ПМСР - это копипаст задания ЦРПТ для тестирования самой ТС ПИоТ ЕСМ.
Кстати, сценарий 5.9 с продажей блока сигарет за 1800 руб. у Вас вопросов не вызвал ?

[Игорь Столяров]

И еще написано про тег 2000

Например для JSON АТОЛ мы подаём исходный КМ в IMC:

[finsoftrz]

Вроде как его сама ккм автоматически формирует

Ну да. ПМСР пробивает чек на реализацию с выбытием КМ.

Видимо, 8.18 (продажа товаров, прошедших проверку в ЛМ) предполагает проверку, что придет в ЧЗ после пробития чека. Завтра попрошу там проверить, какие реквизиты передаются из ККМ. То есть, в этом задании хотят проконтролировать работу посредством ккм, в том числе, как передаются реквизиты локального модуля.

[Игорь Столяров]

предполагает проверку, что придет в ЧЗ после пробития чека

Вы не можете никак влиять на то, что и в каком виде передаст ОФД в ЧЗ.
Это проверка на то, что ПМСР вообще передаёт данные КМ в чеке.

Есть много программ, где как сделали передачу КМ 10 лет назад через регистры и байтовые команды -
так с тех пор костылями их и поддерживают. Ну или просто [M+] пририсовывают в наименование.

[finsoftrz]

Тестовое задание ЕСМ для ПМСР - это копипаст задания ЦРПТ для тестирования самой ТС ПИоТ ЕСМ.
Кстати, сценарий 5.9 с продажей блока сигарет за 1800 руб. у Вас вопросов не вызвал ?

Я смотрел тестовые задания ЕСМ, которые Вы выкладывали. Запрос на регистрацию я в ЦРТП отправил вчера, написали, ждите, ответим на почту после проверки. Пока тишина.
Продажи с ограничением по ценам я прогнал, на цифры не обращал внимания. А что там не так? У меня с блоками немного по другому работает. Как таковых отдельных позиций на блоки нет, а при сканировании блока на кассе создается строка с отдельными пачками с количеством, равным количеству пачек в блок и ценой на пачку. Это идет в учет, а на ккм отправляется как блок.
С табачными будет интересный момент. Сейчас их продают по цене, которая написана на пачке и, соответственно, включена в маркировку. Была ситуация, что цена на старые пачки вылезала за рамки минимальная / максимальная. Что с этим делать, хз. Обращались к регулятору, те только плечами пожали, мы тоже не знаем, наверно, нельзя продавать. А поставщик тоже возврат не берет. При подходе, чтобы автоматически выравнивать цены, как предлагают в ЧЗ, возможно расхождение цены на пачке/в маркировке с ценой продажи. Скорее всего, в ЧЗ не знают, что такое возможно.

[finsoftrz]

предполагает проверку, что придет в ЧЗ после пробития чека

Вы не можете никак влиять на то, что и в каком виде передаст ОФД в ЧЗ.
Это проверка на то, что ПМСР вообще передаёт данные КМ в чеке.

Есть много программ, где как сделали передачу КМ 10 лет назад через регистры и байтовые команды -
так с тех пор костылями их и поддерживают. Ну или просто [M+] пририсовывают в наименование.

Передачу идентификатора запроса, временного штампа и реквизитов ЛМ мы организуем самостоятельно, у них это составная строка. Если проверка была онлайн, то реквизиты ЛМ не передаются. И они, как я понимаю, не могут так просто проконтролировать, когда мы не передаем реквизиты ЛМ, а вроде как должны.

[Игорь Столяров]

что цена на старые пачки вылезала за рамки минимальная / максимальная

В ПФР есть явное указание в такой ситуации продавать товар по МРЦ / ЕМЦ указанных в коде маркировки.
У нас - замена цены с вопросом. Либо мы устанавливаем цену из КМ, либо снимаем товар с продажи и далее
уже с его ценами разбирается товаровед. Задача ПМСР не пропустить товар с КМ и "плохой" ценой в ОФД.

[finsoftrz]

что цена на старые пачки вылезала за рамки минимальная / максимальная

В ПФР есть явное указание в такой ситуации продавать товар по МРЦ / ЕМЦ указанных в коде маркировки.

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

У нас - замена цены с вопросом. Либо мы устанавливаем цену из КМ, либо снимаем товар с продажи и далее
уже с его ценами разбирается товаровед. Задача ПМСР не пропустить товар с КМ и "плохой" ценой в ОФД.

Да, у меня тоже такая мысль возникла, с какого бодуна мы вместо товароведа цены автоматом на кассе подменяем. Потом, нет как-то доверия, что из ЧЗ все корректно придет. Наверно, такие вещи надо на настройку выносить. Я бы просто запретил продажу.

[Игорь Столяров]

что при продаже по мрц, указанной на пачке, мы попадаем ниже минимальной

Здесь нужно смотреть конкретную марку. Я пока не видил, что бы в марке МРЦ был меньше ЕМЦ.
Но у этих всё возможно.

А конкретно в сабже, на сертификационном тесте, обработка превышения МРЦ выглядит вот так:
(можно и просто банить выписку, если я эту возможность ещё не забанил )

[finsoftrz]

А конкретно в сабже, на сертификационном тесте, обработка превышения МРЦ выглядит вот так:
(можно и просто банить выписку, если я эту возможность ещё не забанил )

Любите вы, программисты, перекладывать все на пользователей.
Мне сложно представить ситуацию, когда на кассе нужно делать подобный выбор. Могу представить, когда заменять. При обычной же работе надо запрещать, причем лучше всего не доводя дело до продажи товаров на кассе (за исключением ситуаций со скидками).

[Игорь Столяров]

Любите вы, программисты, перекладывать все на пользователей

Это называется свобода выбора !
На самом деле я тоже считаю, что на кассе должно быть просто сообщение и запрет на продажу.
Но кроме кассовых модулей, бывают ещё и программы для торговли с ККТ и вот мы ближе именно к ним.

Добавлен и протестирован опциональный режим работы в сабж. Теперь можно вот так:

[Игорь Столяров]

Всем привет !

Версия класса для API НСЦМ «Честный ЗНАК» / ТС ПИоТ от 28.01.2026 г.
-------------------------------------------------------------------------------
- ПО ЛМ: Отключено списание дробного выбытия по КМ для контроля дубликатов выписки;
- Актуализирован вид сообщения в запросах на корректировку цен по данным в КМ;
- Добавлена опция Self.PIoT_NoPriceChanges "Выписка без изменения цен по КМ (запрет продажи)";
- Корректная обработка блокировки КМ в ОГВ при отсутствии указания самого ОГВ;
- В запросе информации о ККТ и ошибке подключения CURL показан Endpoint ТС ПИоТ;
- Внесены изменения в сообщения и запросы класса;
- Устранены известные проблемы, не исключаю, что добавлены новые.

P/S: Сейчас класс настроен для сертификации на Endpoint:

Код: Выделить всё

PIoT:RootHost  Equate('https://tspiot.sandbox.crptech.ru')  ! SandBox ЦРПТ

[finsoftrz]

А сколько по времени проходит обработка заявки на регистрацию в реестре партнеров и интеграторов ЧЗ? Третий день ни ответа, ни привета...

[Игорь Столяров]

Да где-то так и проходит. Я посмотрел почту - нам ответили через 3 дня.
Вы можете написать в техподдержку support@crpt.ru и узнать в каком состоянии находится рассмотрение заявки.
Всякое бывает, возможно какие-то проблемы, ожидают сведений или ответ был и потерялся, в спаме и т.д.

[kreator]

Всякое бывает, возможно какие-то проблемы, ожидают сведений или ответ был и потерялся, в спаме и т.д.

Снегопад в Москве. Пробки.