Коллеги, прошу подсказать, если кто проходил проверку совместимости ПМСР для ТС ПИоТ. Я так понял, что сотрудники ЦРПТ подключаются чем-то типа 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с так же проходит сертификацию" - это Ваше предположение или есть официальная информацию об этом?

(15) это мои слова на основании порядка сертификации ПСМР, установленного ЧЗ. Порядок сертификации для всех един. Итогом служит получение ключика, по которому ЧЗ будет понимать, какая ПМСР прислала данные через ТС ПИоТ

(16) Ок, допустим. Развиваем тему:

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

Какое ПО из обозначенных должно пройти сертификацию?

Я вообще не понимаю, почему кассовая программа должна удовлетворять каким-то требованиям ПИОТ. Кассовая программа посылает в ПИОТ марку и получает ответ валидная марка или нет. Для валидной марки получает идентификатор и время проверки, которые пишутся в специальный тег. Все!! что еще надо? Даже если кассовая программа не будет анализировать причины (выведена из оборота, срок годности и тд), то что? Какое до этого дело Пиоту? На что это влияет? Конечных результатов все равно только два - можно продать и нельзя продать. Остальная детализация интересна только продавцу, причем тут ПИОТ? ) Почему он в роли некоего арбитра ?

(18) Когда все-все товары и услуги под маркировкой
Нужны ли ККТ?

Проходил в ЧЗ.
Зум.
Смотрят в экран.
Есть методичка по прохождению сертификации.
Там набор марок.
Их сканируете и программа должна реагировать так, как в методичке описано.
ФР или МГМ нужен только для одной марки. И то можно показать лог программы, что там верно заполнен тэг 1265 (кажется)

(14)

НаименованиеБГосИС = "БиблиотекаИнтеграцииГосИС";
    
    ДанныеКлиента = Новый Структура();
    ДанныеКлиента.Вставить("НаименованиеКассовогоПО",  НаименованиеБГосИС);                              // Наименование ПМСР (кассового ПО)
    ДанныеКлиента.Вставить("ВерсияКассовогоПО",        ВерсияБГосИС);                                    // Версия ПМСР (кассового ПО)
    ДанныеКлиента.Вставить("ИдентификаторКассовогоПО", ИдентификаторПМСР_ТСПИоТ());                      // Идентификатор ПМСР (кассового ПО) в реестре ГИС МТ
    ДанныеКлиента.Вставить("КонтрольнаяСумма",         ОбщегоНазначенияИС.ХэшСуммаСтроки(ВерсияБГосИС)); // Контрольная сумма/ЭЦП исполняемого файла ПМСР (кассового ПО)

Функция ИдентификаторПМСР_ТСПИоТ()
    Возврат "5af4663c-a113-4b47-b959-079ca6dda199";
КонецФункции

Вот похоже и весь ключ. Т.е.ЭЦП исполняемого файла ПМСР - это хэш от версии библиотеки. ИдентификаторПМСР_ТСПИоТ идентичны по крайней мере для УТ и УПП, для остальных думаю тоже самое.

А нельзя взять просто эти параметры и не заморачиваться с сертификацией?

(21)Так без сертификации Вы не купите ПИОТ, в этом вся заморочка
(20)Это мы все понимаем, непонятна привязка ПИОТ к Вашему ПО

(22) "Так без сертификации Вы не купите ПИОТ" - С чего бы это ? Сам ТС ПИОТ от ESP вообще бесплатен. Скачиваете с официального сайта и устанавливаете. Платите только за привязку касс - лицензия на 1 кассу 5000 в год.

(23) Первый раз слышу такое. В запросе к ПиОТ от ЕСП для проверки марок нужно указывать наименование, версию и идентификатор кассового ПО. Идентификатор как раз выдается при сертификации, причем на все конфигурации 1С он похоже идентичен - "5af4663c-a113-4b47-b959-079ca6dda199", при этом контрольная сумма - разная (версии библиотек например в УТ 11 и УПП разные).

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

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

(3) "Мне что, нужно взять живую кассу, подключить её
По большому счету, да. С МГМ вместо ФН".

После долгих пыток сотрудники ЦРПТ ответили, что да - для тестирования нужна живая касса с МГМ.

(18) "Какое до этого дело Пиоту? На что это влияет? Конечных результатов все равно только два - можно продать и нельзя продать. Остальная детализация интересна только продавцу, причем тут ПИОТ? ) Почему он в роли некоего арбитра ?"

Тут ответ простой: 400000 ККМ * 5000 руб. = 2 млрд.руб. в год.

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

(25)Вы сертифицировали свой ПМСР ?

(28) "Вопрос же не про надобность ПИОТ, а для чего ПИОТу сертификация кассового ПО"

Ну надо же чем-то обосновывать существование ПИОТа. Вот какой-то "академик" и обосновал :)))

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

(29) "Вы сертифицировали свой ПМСР ?"

Заканчиваю тесты, готовлюсь подавать заявку.

(31) Вы для собственных нужд разрабатываете или можно купить ваши наработки?

(32) "Вы для собственных нужд разрабатываете или можно купить ваши наработки?"

Не уверен, что вам подойдёт, я ПМСР на C# написал.