forum.clarionlife.net

Привет всем !

Класс для выполнения разрешительной проверки КМ (кодов маркировки)
через API ГСЦМ "Честный ЗНАК" (ГИС МТ + ПО Локальный Модуль) и ТС ПИоТ.

Полный боевой комплект с описанием интерфейса API и примерами.

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

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

На самом деле это только вводит всё в жуткий ступор.
Никто не пойдёт платить по 5 тр с кассы и долбиться с глючным ПИоТом если всё и так работает.
Сейчас все продаваны просто забьют на это болт и всё. Проблема будет перенесена на лето.

В ЦРПТ постоянно виноват, то рынок, то разработчики софта.
А они, гении архитектуры систем, уже так всё запутали с этой маркировкой,
что сами не могут даже грамотно и без ошибок написать задание на тестирование.

Привет Всем!
Столкнулся с ситуацией, когда при попытке зарегистрироваться в "Реестре партнеров и интеграторов" сайта https://registry.intuot.crpt.ru/byteam ... ml?lang=RU, видимо понаставил неверные опции, за что в регистрации было отказано. После двухнедельной переписки с техподдержкой, регистрацию одобрили и в полученной от crpt, после регистрации, инструкции указано о необходимости дозаполнить:

«Добавить партнерское решение» следует выбирать, если не требуется тестирования с СУЗ
«Добавить продукт к интеграции» следует выбирать при необходимости провести тестирование с СУЗ.

В связи с этим, хочу поинтересоваться у тех, кто уже прошел данную процедуру - для простого случая, когда необходима интеграция cla-приложения для КММ, видимо заполняется только (?) "Продукты к интеграции" ? что тут заполнять:
Наименование - это нарицательное имя программы?
Описание/Состав модели ТС ПИоТ - тут что пишем?
Облачное решение - тут понятно, что "НЕТ"
Видимость - а это что и что тут выбрать?
Версия - это, наверное, тоже условно нами присвоенный номер?
Выполняемые задачи - просто краткое описание функционала (магазин или общепит)?

p.s. pdf-документ "Инструкция по работе с реестром партнёров и интеграторов", конечно, читал, но т.к. при регистрации уже один раз так "напортачил", что отказали в регистрации, поэтому прошу совета

Спасибо

SergioRaguzini писал(а): 19 Февраль 2026, 14:50 Видимость - а это что и что тут выбрать?

Будет ли видна Ваша ПМСР в списке для сторонних УОТ (участников оборота товаров).
Например, если Вы разрабатываете ПО которое будет работать только на Вашем предприятии, тогда видимость: НЕТ.

Остальное всё верно - информационные данные в свободном формате.
Кстати, в описании всё это есть, причём с картинками.

Есть такое замечание: если проверяется список (qCodes), в котором вообще отсутствуют коды маркировки (весь товар в чеке не подлежит маркировки), то выводится сообщение "Если нет доступа к сервису - установите ПО Локальный Модуль «Честный ЗНАК»."
Предлагаю проверить список на полное отсутствие в нем КМ (qCodes.GS1='') с последующим Return True.
Типа как в анекдоте "Товарищ полковник, Ваше приказание выполнено!", "А я ж ничего не приказывал.", "А я ничего и не делал!".
PS. В связи с новой стратегией обработки соответствия записей в очередях (с v.16.02.2026) я вообще исключил из передачи в qCodes немаркированных товаров.

И еще, было бы здорово, если можно было бы отключать выдачу сообщения об ошибках выполнения проверки, чтобы можно было полностью взять разбор ошибок в "свои руки" (и это не я выдумал ). Тут было бы хорошо, если бы в qCodes передавался и результат проверки qCodes.LockFlag и qCodes.LockName, чтобы не лазить и в qCodes и в qResponce.

zmi писал(а): 24 Февраль 2026, 13:38 Если нет доступа к сервису - установите ПО Локальный Модуль «Честный ЗНАК»

Это ответ сервиса такой - он не понимает зачем ему прислали пустой список для проверки !

Здесь Вы пытаетесь переложить на класс разрешительной проверки принятие решения о том, что делать если
список КМ для провеки оказался пустым. И это вовсе не значит что проверка пройдена успешно.

Может быть много причин по которой возникает такая ситуация, и это отработывается на стороне прикладного ПО.
1. Формируем список КМ для разрешительной проверки на основании чека.
2. Если есть записи в списке - выполняем проверку и принимаем решение по результату.
3. Если нет записей в списке - принимаем решение о печати чека.

Я закрою сообщения через существующий флаг gContact.bSilentMode, но дело в том, что это касается только
ошибок на основании ответа ТС ПИоТ ... и всё равно у Вас будет недостаточно информации для их полноценного разбора.
А ещё есть ошибки подключения к сервису и его нештатные режимы работы.

Ну и как следствие про запись ошибок проверки в список проверки qCodes - в принципе, ничего плохого в этом нет.
Если есть желание можете добавить поля и сделать. Это одна процедура с тем же самым кодом, что и для записи
результата проверки КМ (тег 1260). Просто сейчас в классе реализована схема, по которой ошибки обрабатываются внутри
класса, что бы не дублировать их разбор в разных программах и способах проверки (выписка одного КМ, проверка пакета
при печати чека и т.д.).

Но я полностью согласен, что здесь возможны варианты, особенно если есть время свободное, да удаль молодецкая !

Всем привет !

Обновление версия класса для API НСЦМ «Честный ЗНАК» / ТС ПИоТ.
-------------------------------------------------------------------------------
- Добавлена возможность отключать сообщения в методе проверки списка КМ;
- Добавлена поддержка API ver. 2 по документации 1.04 (прилагается);
- Добавлена информация о версии API в сообщение о параметрах ТС ПИоТ;
- Отработаны мелкие помарки по запросам.

kreator писал(а): 18 Февраль 2026, 15:57 На сыре экономить нельзя!!!

Больная тема. Исчез хороший сыр из розницы в регионах. Наверно из-за цены. Приходится ездить в АШАН.

А анкету после отправки они долго проверяют? У меня уже больше недели на рассмотрении висит без обратной связи...

finsoftrz писал(а): 24 Февраль 2026, 17:24 А анкету после отправки они долго проверяют?

Ну у нас она уже месяц "На подтверждении" с синим флагом. Я так понимаю, что она нафиг никому не нужна вообще. Но порядок такой.

Игорь Столяров писал(а): 24 Февраль 2026, 14:19 Здесь Вы пытаетесь переложить на класс

Я немного не о том - я о некоторой некорректности сообщения, и как вариант решения, хотя и сам тоже подумал, что не очень хорошо получится.

Игорь Столяров писал(а): 24 Февраль 2026, 14:19 можете добавить поля и сделать

Да я уже так и сделал (в двух процедурах: ЛМ и ПИоТ). Теперь только при обновлении класса вставки надо делать.
Игорь, спасибо! И за эти доработки и за 25-й сценарий!

zmi писал(а): 24 Февраль 2026, 23:22 я о некоторой некорректности сообщения

Неть ! Здесь идёт некорректное действие, которое приводит к ошибке в ответе ТС ПИоТ.
Нельзя передавать на проверку пустой список - давайте пожалуйста, перед тем как писать
посты, - откроем описание (которое идёт в комплекте) и посмотрим вот на этот плюсик:


Безусловно, можно решать внутри класса придуманные проблемы, проверять наличие кодов для проверки,
корректность указания самих кодов маркировки и т.д. ... но поверьте на слово - здесь вполне хватает и реальных проблем,
которые создаёт ЦРПТ.

zmi писал(а): 24 Февраль 2026, 23:22 Теперь только при обновлении класса вставки надо делать.

И отлично ! Можете просто сделать свой форк на основании класса и вести его.

Мне кажется, все же правильнее проверять на пустой список перед отправкой запроса. С их точки зрения пустой список это неверно переданная информация в запросе. Тем более, сделать такую проверку работы на 5-10 минут.
Свой форк это не так просто, понять кисть другого художника занимает времени на 1-2 порядка больше, чем свою собственную. Особенно у тех, кто мыслит нестандартно. Проще писать автору. Помнится, один коллега не так давно дедушку до истерики довел.

finsoftrz писал(а): 25 Февраль 2026, 8:04 С их точки зрения пустой список это неверно переданная информация в запросе.

Полностью с Вами согласен. Я ведь не против.
Добавим в следующем релизе "защиту от дурака" с контролем наличия записей в списке проверки.

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

finsoftrz писал(а): 25 Февраль 2026, 8:04 Свой форк это не так просто

В принципе, ТС ПИоТ был задуман как очень простая технология ... но сделано как обычно, и люди те же.
Поэтому уже пошли плодиться версии запросов с костылями и рассылаться угрозы с отлючением.

zmi писал(а): 24 Февраль 2026, 23:22 Да я уже так и сделал (в двух процедурах: ЛМ и ПИоТ)

Формально говоря, Вам даже добавление полей в список qCodes не требуется, т.к. можно использовать
для кода / наименования ошибки поля Price / FractionalAmount - они после выполнения запроса уже не нужны ...

Если пустой список, то возвращать специальный код ошибки. Что с этим дальше делать, решать в верхнем ПО. Я бы так сделал.

Я вот смотрю, что с Егаис творится. Там запрос на остатки марок по одному приходу можно раз в двое суток сделать (сейчас лень смотреть, может еще увеличили). Походу все забили, как-то вроде работает, а что там с остатками, никто не знает. Оставили кого-то на поддержке по минимуму, так как совсем отказаться и признать провал эксперимента не могут, уже отчитались. С ЧЗ договориться по пиву вроде не удалось, народ так и занимается параллельным списанием продаж в Егаис на следующее утро. Хорошо хоть пивную декларацию отменили.

finsoftrz писал(а): 25 Февраль 2026, 8:43 Я вот смотрю, что с Егаис творится.

Как я понимаю, что сейчас идёт под ковром передел больших денег из маркировки.
И то, что "Честный ЗНАК" в одно прекрасное утро вдруг стал на букву "Г"сцм - это из той же серии.

Если бы пришла новая команда в ЦРПТ, то в идеале вся маркировка могла бы упроститься.

1. ДО печати чека ТС ПИоТ выдаёт отпечаток разрешительной проверки для каждой марки (есть).
Для Off-Line проверки действует та же схема что и с чеками в ОФД: 72 часа и блокировка.

2. В чеке передаётся только этот отпечаток в теге 1260 для каждой марки (есть).
Данные о самой марке в чеке не нужны или просто информационные данные.

3. ОФД передаёт только тег 1260 в ГИС МТ и по нему и данным из п.1. выполняется выбытие КМ.

Всё !