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

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

Привет всем !

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

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

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

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

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

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

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

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

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

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

[SergioRaguzini]

Спасибо за оперативный отклик, но прошу уточнить:

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

Т.е., например, КМ успешно прошла проверку через пр-ру Honest::CheckReceipt, далее анализируем передачу чека в ФР, если чек в ФР закрыт корректно, то выполняем запись КМ с использованием пр-ры Honest::EditSoldList,
если же чек в ФР не закрылся (например, нет чековой ленты), то тогда, после устранения ошибки ФР, делаем повторную попытку передачи в ФР чека и, если, на этот раз удалось безошибочно закрыть, то выполняем Honest::EditSoldList
Так?

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

Так?

Да. Успешное создание фискального кассового чека (печать на ленту или электронный чек) означает передачу
КМ из содержания чека Вашему ОФД и далее в "Честный ЗНАК", где фиксируется выбытие КМ для On-Line проверки.

А Вы после этого, на своей стороне, фиксируете выбытие этих же КМ в БД ПО ЛМ или своей БД для Off-Line проверки,
на то случай если БД ГИС МТ будет не доступна On-Line. Конкретно ТС ПИоТ это переключение проверки выполняет сам.

[finsoftrz]

Если кассовое ПО само умеет проверять дубли марок, то использовать для этого ЛМ не обязательно. Это вспомогательный механизм, не обязательный для использования. Я не стал такое реализовывать, так как будут еще всякие заморочки с резервным копированием/восстановлением базы ЛМ, которая и так периодически может на свое усмотрение очищаться и требовать инициализации. Буквально сегодня такое видел в нескольких магазинах.

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

так периодически может на свое усмотрение очищаться и требовать инициализации

Есть такое дело ! ПО ЛМ реализовали в виде BackEnd, как REST сервер.
И это классно, делайте FrontEnd хоть на Windows, хоть на распилочных "русских" Linux.

Но вот когда этот REST сервис с суверенной БД Енисей стали ставить на ноутбуки с 4 GB RAM,
торрентами и несколькими бесплатными антивирусами - всё пошло немного не по плану ...