Нет сертификата руководителя
Самая частая. Заявление уходит, а сертификат директора не подкреплен в учетной записи Отчетности или ЭДО.
Решение: убедиться, что сертификат вставлен и добавлен в учетную запись.
Статьи директора · ЭДО и отчетность
Машиночитаемая доверенность выглядит страшнее, чем есть. По сути МЧД — это связка личного сертификата физлица и сертификата директора: файл, который говорит «вот этот сертификат связан с этой организацией». Не более того.
Основное время уходит не на доверенность, а на получение сертификата физлица. Проблемы начинаются в другом месте — разберем, в каком.
Самая частая. Заявление уходит, а сертификат директора не подкреплен в учетной записи Отчетности или ЭДО.
Решение: убедиться, что сертификат вставлен и добавлен в учетную запись.
Решение: сверить карточку организации и справочник физических лиц. В самой МЧД нажать «Уточнить реквизиты» и проверить заполнение. Если все верно, а ошибка осталась — отправить заявление на ЭЦП руководителя заново.
Для ЭДО добавляется своя проверка: убедиться, что в сертификате в поле «использует» указаны именно вы. И следить за датой — она не должна быть вчерашней или позже даты выпуска.
Полный текст: «не удалось отправить машиночитаемую доверенность, произошла ошибка при выполнении криптоопераций над запросом к серверу».
Решение по порядку: проверить, что релиз конфигурации актуален; очистить файловый кеш по пути %appdata%; очистить кеш учетной записи.
Тут дело не в технике.
МЧД выпускается из базы клиента, а в базе должны вестись нормальные физические лица — с паспортными данными, ИНН и СНИЛС.
Но доверенности часто делают из управленческих баз, где с разграничением доступа, мягко говоря, не очень. А чаще — никак. Логично, что персональных данных там нет. А раз их нет, МЧД нормально не выпускается.
Дальше начинается неприятное: людей просят внести эти данные, и они переживают, что их паспорт увидит половина компании. И правильно делают, что переживают. Правильный ответ здесь не «внесите и не волнуйтесь», а настроить разграничение доступа — до того, как заносить данные.
По-хорошему сертификат должен лежать на отдельном носителе и быть неизвлекаемым — например, на носителе класса Рутокен ЭЦП 3.0.
На практике для удешевления его чаще держат на компьютере или на обычной флешке. И сотрудники против — тоже обоснованно.
Совет физлицам: получите свой личный сертификат — на нормальном защищенном носителе, в МФЦ — и носите с собой. Дать работодателю доступ к своему сертификату — это как положить ключи от квартиры на рабочий стол. Доверяете — ваше дело, но мы бы не стали. Побочная выгода: этот же сертификат пригодится на Госуслугах.
В МЧД есть полноценный классификатор полномочий. И почти никто им не пользуется — ставят «все полномочия», потому что так быстрее.
Что это означает на практике: человек с такой доверенностью может внести изменения в ЕГРЮЛ, сдать за вас отчетность, подписать договор с контрагентом. Любое действие от имени организации.
Полномочия стоит ограничивать. Это ровно тот случай, когда не нужно оставлять ключи от квартиры на рабочем столе — а именно так поступает большинство.
Отсюда растет большинство вопросов «почему не работает».
Единого формата машиночитаемой доверенности нет. Каждое ведомство вправе установить свой, и на практике доверенности отличаются по типу — в зависимости от того, где вы собираетесь ими пользоваться.
Подписание документов с покупателями и поставщиками. Оформляется отдельно от отчетной.
Своя доверенность в формате ФНС. Для отправки писем представителем организации нужна именно она — единый формат здесь не подойдет.
Доверенность для ФНС в СФР не годится. Формат зависит еще и от вида отчета.
Ряд ведомств подключился к обмену доверенностями через блокчейн-платформу ФНС и принимает единый формат версии 003. Он объединяет обмен с контрагентами и часть госорганов — но не все.
Практическое следствие: у сотрудника, который и подписывает документы контрагентам, и сдает отчетность, доверенностей будет несколько. Это не ошибка настройки, а устройство системы. В нашей нормировке работ это отражено прямо: доверенность с полномочиями ЭДО и доверенности для ФНС, СФР и УПУП — разные работы с разной трудоемкостью.
Частый вопрос: есть ли разница, через какого оператора ЭДО выпускать доверенность. Для доверенностей, которые лежат в распределенном реестре ФНС, — разницы нет.
Реестр — это единое блокчейн-хранилище. Оператору ЭДО, Честному знаку или Национальному каталогу передается только номер доверенности: ни сертификаты, ни персональные данные никуда не уходят. Система сама подтягивает документ из реестра и проверяет сертификат.
Поэтому доверенность, выпущенную в одном сервисе, обычно можно подтянуть по номеру в другом — она уже в реестре, выпускать заново не нужно.
Но есть условие, о которое спотыкаются. Подтянуть можно доверенность подходящего типа. Если у вас на руках доверенность для обмена с контрагентами, а нужна отчетная — она не подойдет, сколько ее ни загружай. Ошибка при этом выглядит непонятно: «доверенность не найдена» или «не соответствует требованиям».
И еще: загрузка по идентификатору срабатывает не всегда с первого раза — это касается и сторонних сервисов, и Честного знака. Если не подтянулась, стоит проверить тип и повторить, а не выпускать новую.
Одобрение проходит в течение суток, иногда дольше. Дальше:
Выпустить заявление, где используется «сотрудник», и добавить в сертификат ЭЦП физлица — снизу появится окно для самой доверенности.
После одобрения зайти в настройки обмена с КО, в расширенные настройки, и добавить МЧД для нужных органов.
Чем подтверждаем опыт
Настраиваем весь контур: разграничение доступа к персональным данным, выпуск сертификатов, оформление доверенностей с внятными полномочиями и подключение их в Отчетности и ЭДО. И разбираем ошибки, если доверенность не выпускается, — обычно причина в одном из трех пунктов выше.
Не выпускается доверенность? Опишите, на каком шаге встали и какой текст ошибки — подскажем, что проверить.
Статья написана по надиктовкам директора — Евгения Карпова, ГК «Солвикс». Это практика с внедрений и сопровождения, а не пересказ документации: то, что видно, когда сам разбираешь чужие базы.
В активе: 43 пройденных курса и 1328 учебных часов, первый экзамен сдан в 2009 году. «1С:Специалист-консультант» по 1С:ERP (управленческий и регламентированный учет), по 1С:Управление торговлей и по 1С:Документообороту.