Коллеги, прошу подсказать, если кто проходил проверку совместимости ПМСР для ТС ПИоТ. Я так понял, что сотрудники ЦРПТ подключаются чем-то типа Zoom, я сканирую товар по методичке, а они наблюдают ответы ПМСР (на данный момент это 25 проверок) и убеждаются, что моё ПО корректно реагирует на ответы ТС ПИоТ. Возник вопрос, на который я не могу добиться от ЦРПТ ответа. Как показать им, что корректно формируется "Уведомление о реализации"? В методичке сказано "ПМСР формирует фискальный документ «Уведомление о реализации»". Но фискальный документ может формировать только ККМ. Я лишь отправляю драйверу данные с помощью тегов. Мне что, нужно взять живую кассу, подключить её и показать им, что в логах драйвера кассы отправляются нужные теги? Или какой-то ещё способ есть?

(0) Подключаюсь к вопросу. Да и в целом очень хочется узнать, кто и для его уже пробовал проходить данную сертификацию.

Я банально даже не смог получить официальный ответ - "для чего эта сертификация, на что она влияет" ?

+ Что делать с тем фактом, что система постоянно дорабатывается и изменяется...мы должны после каждого изменения проходить сертификацию заново?

(1) можете разработчикам ПИоТ предложить идею:

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

(0) Мне что, нужно взять живую кассу, подключить её

По большому счету, да. С МГМ вместо ФН.

А возможно, и как-то проще, тоже интересно.

У меня, если дойдет до этого, есть реальная тестовая ККТ, с ЭФН, в тестовом ЛК ОФД которого я смогу показать уведомление, "в лучшем виде"... Но, может это и не нужно?

(2) хешсумму исполняемого файла приложения

Что есть "исполняемый файл" в случае 1С - ? :-)))

(2) Самое забавное, что тех.поддержка ЕСП не может даже сформулировать четко и понятно, что они понимают под термином "кассовая программа". А ссылаются они на этот термин буквально в каждом предложении.

Допустим:

Есть 1С:Ут (в которой непосредственно работает кассир), она посылает запросы в еще одну программу 1С:Интегратор, а она в свою очередь обращается на выделенный ККМ сервер, который посылает данные на кассу.

И что в данном случае будет "кассовой программой" ?

(0) в идеале да, взять живую кассу и с ОФД показать чек, тогда вопросов не будет. Бывало что в отладке можно показать, что теги правильно уходят в драйвер ККТ, но это нужно чтобы проверяющие вам доверяли.
(1) без сертификации не получите ключ, с помощью которого пмср будет взаимодействовать с тс пиот

(6) "без сертификации не получите ключ, с помощью которого пмср будет взаимодействовать с тс пиот"

Не совсем понятно. Допустим, берем типовую конфу (розницу) с немного допиленным функционалом (там поправили, тут поправили). Получаем уже НЕ типовую конфу. Получается я ее тоже должен сертифицировать? Если "ДА" - тогда под сертификацию попадает 90% рынка пользователей 1С. Если "НЕТ" - тогда где та самая грань, которая делить мир на "нужно сертифицировать" и "не нужно" ?

+ Если типовая конфа, сертифицированная, должна иметь некий ключ, то кто этот ключ выдавать будет? Или он будет зашит в саму конфу жестко? Если "да" - что мне мешает его использовать своей конфе. Если "нет" - где и как его брать?

И подобных вопросов у меня еще целый мешок. Кто б ответил

(7) Грань там где барьер отсечения лишних конкурентов, монополизации (с помощью лоббирования нужных законов) и картельного сговора с задиранием ценников.

А вот интересно, вроде вышла какая-то типовая, со встроенным ПИоТ, а ранее с поддержкой внешнего, вроде Розница... Если кто-то уже протестил, расскажите, есть там ключи или нет? Или еще не вышла?

(4) я вел речь о кассовых программах, которые бизнес разработал самостоятельно. сомневаюсь, что крупные торговые сети "кассят" из 1С.

(7) в случае типовых 1С-конфигураций, предположу, что функционал в контексте "ККМ-ПИоТ" (модули, двоичные данные и т.п.) сделают с двойным замком, который невозможно сбросить.
"Двойные замки" будет невозможно модифицировать и в расширении. Тогда между пользователями типовых конфигураций и внешними госсервисами будет полное доверие.

(11) Двойные замки это как?

Лично я бы положился на шифрование с открытым и закрытым ключами
Никакой ключ-токен наружу из ВК не уходит, только одноразовый токен из ТС ПИоТ шифруется внутри и отправляется как ключ авторизации
Сама ВК привязывается к конфе и железу через СЛК
Все обращение/вызовы в закрытых модулях, обязательно обфусцированных
И обязательно смена ключей по расписанию, путем замены ВК на новую если есть подписка
И да для каждой версии конфы и клиента своя пара ключей уникальных

(12) "Двойные замки" - это образно. Как реализовать запрет модификации механизмов это забота архитекторов.

(7) типовой выдадут свой ключ, т.к. 1с так же проходит сертификацию. Но ключ понятное дело будет закрык и использовать его нельзя. Будет что-то типа "закрытой библиотеки", которая будет работать с ТС ПИоТ и взаимодействовать с ККТ.
Со временем думаю типовая придет к тому, что вы указываете код маркировки, а она говорит можно ее продать и пробить на ККТ или нельзя. И обойти это никак не выйдет. Ну, если только не указать другую товарную группу, не подлежащую маркировки.

А то что вы конфу меняете - ничего страшного, главное "закрытую библиотеку" по взаимодействую с ТС ПиоТ не меняете, именно она получает ключ при сертификации

(14) "типовой выдадут свой ключ, т.к. 1с так же проходит сертификацию" - это Ваше предположение или есть официальная информацию об этом?