forum.clarionlife.net

Привет всем !

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

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

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

SergioRaguzini писал(а): 06 Май 2026, 11:46 если в учетной системе имеется собственный механизм исключения дубликатов

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

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

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

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

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

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

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

SergioRaguzini писал(а): 06 Май 2026, 12:47Так?

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

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

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

finsoftrz писал(а): 06 Май 2026, 15:11 так периодически может на свое усмотрение очищаться и требовать инициализации

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

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