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

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

Привет всем !

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

Реализованный в классе функционал соответствует ПФС версии 1.18 от 26.06.2026 г. (27 сценариев),
для получения сертификата совместимости и допуска к работе в промышленной среде ТС ПИоТ ЦРПТ.

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

Список изменений в версии от 10.07.2026 г.
----------------------------------------------------------------------------------------------------
- В процедуре ESML::Info() показаны срок действия и статус лицензии ЕСМ;
- Добавлена возможность изменять хост и порт подключения к ТС ПИоТ / ПО ЛМ;
- НКМТ: Определение принадлежности GTIN / ТНВЭД к маркируемым товарным группам;
- НКМТ: все поля ответов на запросы сразу доступны в кодировке ANSI;
- Устранены проблемы по запросам и внесены изменения в примеры.
----------------------------------------------------------------------------------------------------
Рекомендуем использовать актуальные версии классов LibCURL, cJSON и PrintF.

esp.png (13.96 КБ) 189632 просмотра

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

В ЛК у них контактных адресов нет (или я не нахожу)

support@crpt.ru

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

Вышел вот такой рекламный буклет с разъяснением терминов ТС ПИоТ на примере ЭВОТОР.
Распространяется бесплатно и по открытой ссылке: https://disk.yandex.by/i/B-KXlJHb12ithw

P/S. Да ! Не кажется. На обложке нарисован АТОЛ-30Ф.

[SergioRaguzini]

рекламный буклет с разъяснением терминов ТС ПИоТ на примере ЭВОТОР

Именно "рекламный", вроде как и о ТС ПИоТ, но с подтекстом, что у Эвотор это лучше всех

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

Список изменений в текущей версии публикуется в заглавном сообщении темы.

[SergioRaguzini]

Приветствую!

Отключена поддержка эмуляции Off-Line режима ТС ПИоТ на стенде

теперь для сертификации такой режим не будет применяться?

[finsoftrz]

А где можно узнать идентификатор программы и версии после сертификации, те, которые надо указывать в запросе к пиот? Что-то в ЛК не вижу похожего.
PS. Интересно, это счастье с сертификацией теперь каждый год надо проходить? Они про какой-то ключ тс пиот написали, что действует в течении года.

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

А где можно узнать идентификатор программы

Просто идёте далее по инструкции ЦРПТ там есть описание где брать ключ регистрации ПО:

P/S: Поздравляю !

[finsoftrz]

Ага, увидел, не там смотрел. Спасибо.

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

Ага, увидел, не там смотрел. Спасибо.

Я забочусь обо всех, кто сюда попал ... (С) За разломом Орла

[finsoftrz]

Я бы сказал, вляпался.

[SergioRaguzini]

Привет Всем!
При заполнении заявки "Продукты к интеграции" в поле "Совместимая модель ТС ПиоТ" удается сделать выбор только одного варианта.
Получается, что для случая, если ПМСР работает с двумя моделями ККТ, например, и с "Штрих" и с "Атол" необходимо заполняють две заявки "Продукты к интеграции"?

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

с "Штрих" и с "Атол" необходимо заполняють две заявки "Продукты к интеграции"?

Нет. Включение в список совместимости с ККТ зависит только от прохождения функционального теста с ККТ.

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

Если позволите - я немного поясню свой ответ, что бы было понимание происходящего здесь.

Сама по себе разрешительная проверка кодов маркировки (КМ) выполняется ДО печати
кассового чека и никак не зависит от производителя или модели ККТ.

Другой вопрос - конкретная реализация ТС ПИоТ для выполнения разрешительной проверки.
ТС ПИоТ ЕСМ выполняет шифрование пакетов ключом ФН с обменом через сервер GRPC.
И вот здесь ключевым является поддержка драйвера и прошивки ККТ, т.к. создаётся некий
"виртуальный многокомпонентный аппаратно-программый комплекс", или попросту ТС ПИоТ.

Поэтому в сабже (и любой другой реализации взаимодейсвия с API ТС ПИоТ) вообще нет упоминаний
о поддерживаемых моделях ККТ. Но Ваша ПМСР должна уметь создать эту самую среду взаимодействия
с учётом конкретного поддерживаемого ТС ПИоТ драйвера и модели ККТ.

И именно это взаимодействие Вашей ПМСР с (ТС ПИоТ + драйвер ККТ) проверяется на функциональном тесте
и определяет совместимость предлагаемого в ПМСР решения для выполнения разрешительной проверки КМ
для конкретного ККТ.

Аналогия для понимания. Вся работа сабжа построена на работе с КМ в формате GS1.
Но абсолютно по барабану как и где Вы получите этот код маркировки в GS1.
Можете сформировать его вручную, считать USB сканером через HID интерфейс или получить через
драйвер COM порта (или уже скорее совместимого протокола обмена COM-порта). Как Вам удобно.

Тоже самое и с конкретной ККТ - требуется обеспечить любым способом взаимодействие ПМСР с ТС ПИоТ
через сервер GRPC ККТ для выполнения разрешительной проверки КМ.

[SergioRaguzini]

Привет Всем!
В данном классе для проверки КМ имеется удобная процедура Honest::CheckReceipt(gContact,qCodes,gVerified), которая, по завершении, дает развернутый ответ результата проверки.
В ситуации, когда, например, в чек заносится несколько позиций, проверяю "на лету" каждую вносимую позицию чека (заполняя, при этом, для каждой позиции чека очередь одной записью) и сохраняю ответ в соответв.поля записи таблицы бд, что бы потом заполнить тег 1265

Вопрос - нужно ли при успешном закрытии чека в ККМ, в обязательном порядке, дополнительно использовать пр-ру Honest::EditSoldList или, если в учетной системе имеется собственный механизм исключения дубликатов, такое можное не применять, а будет достаточно того, что параметры выбытия марк.продукции будут переданы самим ФР в ОФД и ЧЗ?

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

если в учетной системе имеется собственный механизм исключения дубликатов

Здесь ответ нужно разделить на два:

1. При проверке в ГИС МТ - проверяйте локально дубликаты КМ как считаете нужным;

2. При проверке в ТС ПИоТ - система сама будет проверять локальные дубликаты в ПО ЛМ при отсутсутвии подключения к ГИС МТ,
и устанавливать признак SOLD для проверямого КМ. А значит для этого нужно записывать выбытие КМ в БД ПО ЛМ.

В принципе, если есть время свободное, да удаль молодецкая - Вы можете самостоятельно анализировать результат
проверки всего пакета КМ и при установке флага isCheckedOffline = true проверять весь пакет по своей локальной БД КМ.
Без проблем и в этом случае не нужно записывать КМ в БД ПО ЛМ для отслеживания дубликатов выбытия.
Но от использования ПО ЛМ Вас это не избавит, т.к. всё равно ТС ПИоТ должен проверять по ней заблокированные ОГВ КМ.