МЧД в ЕГАИС : ЕГАИС в опте и рознице

Источник - [ ➜ ]

- с июля 2023 г. на тестовом контуре ЕГАИС планируется начать тестирование взаимодействия с внешними информационными системами с использованием МЧД.

- на сайте Росалкогольрегулирования планируется создать подраздел «МЧД» в разделе ЕГАИС ([ ➜ ]), который будет содержать актуальную информацию по вопросам взаимодействия с информационными системами Росалкогольрегулирования с использованием МЧД, а также дополняться по результатам доработки информационных систем.

- c целью применения МЧД при взаимодействии с информационными системами Росалкогольрегулирования планируется использовать приложение «Машиночитаемые доверенности» на базе распределенного реестра ФНС России и формат доверенности, размещенный Минцифры на ЕПГУ.

- формировать, отзывать и получать сведения об МЧД через информационные ресурсы Росалкогольрегулирования не планируется, все перечисленные действия необходимо будет проводить в Реестре МЧД ФНС с использованием сервиса ФНС России m4d.nalog.gov.ru или операторов ЭДО, также использующих Реестр МЧД ФНС.

- для определения полномочий будет использоваться классификатор полномочий, определенный приказом Минцифры № 856 ([ ➜ ]), в который планируется добавить полномочие по направлению документов в Росалкогольрегулирование.

-проводятся работы по доработке УТМ ЕГАИС в части возможности обеспечения формирования RSA-ключа участником алкогольного рынка после загрузки МЧД в УТМ ЕГАИС.

-закупка на выполнение работ по доработке программных средств ЕГАИС, включающая реализацию механизма использования машиночитаемых доверенностей, размещена 07.04.2023 ([ ➜ ]), госконтракт № 0173100005123000006 заключен 10.05.2023 ([ ➜ ]).

4.4 Доработка программных средств ЕГАИС в части реализации механизма использования машиночитаемых доверенностей
Для реализации следующих механизмов и функций должны быть созданы необходимые программные компоненты (в ЕГАИС, при технической возможности, доработаны существующие).
4.4.1 Состав комплекса задач
Комплекс задач включает в себя:
- реализацию проверки сведений о доверенности при генерации RSA-ключей;
- реализацию проверки сведений о Доверенности по XML-файлу Доверенности;
- актуализацию сведений о статусах Доверенностей;
- модификацию форматно-логического контроля ЕГАИС с целью проверки доверенностей при осуществлении документооборота.

4.4.2 Реализация проверки сведений о доверенности при генерации RSA-ключей
Проверка сведений о доверенностях при генерации RSA-ключей проводится по загружаемому XML-файлу Доверенности.
При генерации RSA-ключа с использованием сертификата руководителя юридического лица или индивидуального предпринимателя RSA-ключ должен формироваться без запроса номера доверенности и проверки ее статуса.
4.4.3 Реализация проверки сведений о Доверенности по XML-файлу Доверенности
При проведении проверки Доверенности при генерации RSA-ключа в УТМ должен быть реализован функционал загрузки подписанного XML-файл Доверенности. После получения XML-файла Доверенности проводятся следующие проверки (перечень проверок может быть дополнен на этапе проектирования):
· валидация XSD-схемы Доверенности Единой форме доверенности (в формате XSD), формируемой и размещаемой уполномоченным федеральным органом на едином портале государственных и муниципальных услуг;
· действительность доверенности на момент запроса RSA-ключа;
· соответствие загруженного XML-файла Доверенности XML-файлу такой Доверенности, полученной из Приложения МЧД ФНС.
При положительных результатах проверок выдается RSA-ключ и в Реестре сведений о доверенностях вносится соответствующая запись о номере и сроке действия имеющейся Доверенности с привязкой к номеру RSA-ключа, номеру сертификата физического лица и идентификатору организации (FSRAR ID).
В случае выявления ошибок или недостоверных данных на любом этапе проверок, заявитель получает сообщение об отказе в выпуске RSA-ключа.
4.4.4 Актуализации сведений о статусах Доверенностей
С целью актуализации сведений о статусах Доверенностей Реестр сведений о доверенностях должен своевременно запрашивать статусы по всем содержащимся в нем номерам доверенностей в Приложении МЧД ФНС. Период запроса статусов Доверенностей из Приложения МЧД ФНС определяется на этапе проектирования.
Также статус Доверенности должен быть изменен на «недействительна» в случае истечения её срока действия, указанного в Реестр сведений о доверенностях, а также при получении сведений из Приложения МЧД ФНС об отзыве Доверенности.
4.4.5 Модификация форматно-логического контроля ЕГАИС с целью проверки доверенностей при осуществлении документооборота
В случае, если какая-либо из Доверенностей стала недействительна или привязанный к ней RSA-ключ отозван или истек его срок действия, документы или запросы документов, направляемые в ЕГАИС и подписанные сертификатом физического лица направляемые в соответствии с такой Доверенностью не должны приниматься сервисами ЕГАИС. В ответ на направляемые документы или запросы документов должно направляться сообщение в УТМ отправителя о недействительности используемой Доверенности.
Сообщение о недействительности используемой Доверенности согласовывается с заказчиком на этапе разработки проектной и рабочей документации.
Проверка действительности Доверенности в рамках ведения электронного документооборота в ЕГАИС проводится в момент проверки корректности электронной подписи направленного документа путем направления запроса об актуальности, привязанной к данному номеру сертификата физического лица Доверенности в Реестр сведений о доверенностях.

что-то я не до конца понимаю происходящее.
Условно, у меня 10 торговых точек с алкоголем. Как раньше, выпускать все ключи на директора и писать нужные на них RSA сейчас нельзя. Поэтому все сертификаты ГОСТ пишутся на кассиров/сотрудников. Т.е. уже и так основной сертификат выпускается от предприятия на физлицо по обычной доверенности. И дальше, чтобы на этот же ключ записать RSA, нужно будет ещё МЧД куда-то загружать.
Типа мы сомневаемся в доверенности на это физлицо, на которого вы записали ГОСТ, дайте нам ещё одну доверенность, чтобы выпустить RSA. Так что ли?

Нет, речь о том, что с 1.09.2023 вы не можете выпустить подпись на сотрудника предприятия ( в законе убрали такую возможность).

Вам надо взять подпись физического лица (записанную, видимо на Rutoken 2.0).
На это физ.лицо оформить МЧД.
И вот с этой парой сущностей должен работать УТМ.

Т.е. не будет ключей от предприятия на сотрудника, а будут персональные подписи физ.лиц + МЧД от предприятия и на основании этого будет получаться RSA на разные КПП?
У меня сейчас такая схема - есть доверенность от предприятия на действия от его имени с удостоверяющим центром, удостоверяющий центр выпустил мне персональную подпись, с помощью которой в выделенном мне ЛК я пишу ключи на сотрудников торговых точек. Теперь эта схема накрывается медным тазом, потому что выпускать подписи предприятия по доверенности предприятия это одно, а выпускать подписи разным физлицам от имени УЦ это как бы немного другая ответственность.
Теперь мне нужно будет гонять кассиров в УЦ для оформления своих подписей, а потом на их ключ писать свой RSA?
В связи с этим возникают вопросы
1. Формально теперь это их подпись на их ключе. Как мне контролировать "мой" RSA находящийся у них? Или RSA будет писаться на отдельный ключ?
2. На ключе подпись не предприятия, а физлица. Ни один здравомыслящий кассир не оставит свой ключ сменщику. Выпускать 2 RSA? ... но ведь действителен только последний выпущенный.
3. Как попадать в ЛК для записи? Нынешняя схема - по ГОСТу предприятия, но у нас на ключе будет подпись физлица, а не предприятия.
4. Кстати, до сих пор непонятно - как записывать первый ключ через УТМ, если УТМ без действующего RSA не запускается в принципе, а тут вообще подпись "левого" физлица.

Ну вот то, что сходу в голову пришло.
Что-то вопросов много, а понимания происходящего -1. (((

Не так. Как можно сомневаться в том, чего вы не делали? ЭЦП физ-лица никакого отношения не имеет к Вашей организации. ФизЛицо оформляет себе ЭЦП самостоятельно, Вы, даже если и помогавете ему в этом - это Ваши добрые начинания, данные своей организации, Вы при этом ни где не указываете.

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

Огромный минус всей этой схемы - необходимость заполнения СНИЛСов, дат рождения, паспортных данных, должностей для формирования МЧД на каждого ФЛ. У многих сейчас нет в УС этих данных. Ну и каждый магазин будет звонить и спрашивать где это брать, куда это указывать и т.д...

Ну с этим проблем не вижу - всё это есть в ЗУПе. Думаю, что там в сотрудниках появится просто кнопка "Создать и отправить доверенность по ЭДО".
Для меня вопрос в другом - если на одном рутокене будет персональная подпись физлица и RSA, то как это передавать по сменам? Я бы хрен кому дал такой ключ со своей личной подписью.
Или RSA будет существовать самостоятельно на отдельном ключе?

конечно же, РСА будет на одном ключе с ГОСТ, все как и раньше. Вопрос "На кого выдавать подпись физ.лица?" был озвучен как только ФНС и Минкомсвязи начало обсуждать переход на МЧД (2018-19гг). И задавался при этом такими крупными участниками как Тандер и Х5. Официального ответа к сожалению, до сих пор нет. Это будет такой же "фековый" владелец каким и сейчас является владелец ключа уполномоченного. В этом отношении, в принципе, ничего и не меняется. На каких представителей сейчас выпускаете ключи для ЕГАИС - на тех и продолжайте.
Так же, ФСРАР не решен вопрос отслеживания изменений ФИО ответственного (смена фамилии), его увольнения или смерти. Все держится на честном слове участников рынка