Класс для API ТС ПИоТ ЕСМ от АО «ЕСП»

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

Привет всем !

Класс для разрешительной проверки КМ (кодов маркировки) через API ТС ПИоТ ЕСМ от АО «ЕСП».
Полный боевой комплект с описанием интерфейса API и примерами.

Реализованный в классе функционал полностью соответствует ПФС ЦРПТ (версия 1.13 / 26 сценариев)
для получения сертификата совместимости и допуска в промышленную среду работы с ТС ПИоТ.

Благодарность за помощь на старте проекта: FinsoftRZ и Alex412.
Любые замечания, исправления и дополнения - приветствуются !
----------------------------------------------------------------------------------------------------
НАСТОЯТЕЛЬНО рекомендуем использовать актуальные версии классов LibCURL, cJSON и PrintF.

esp.png (13.96 КБ) 2458 просмотров

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

И еще написано про тег 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]

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

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

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

Свежая статья по сабжу: https://ok.ru/dzen/article/aYBeeyEWjXGlEZP8