Проанализируем ситуацию. Нужно подписать договор в электронном виде, но у сторон разные операторы ЭДО, а дополнительный тариф или роуминг для обмена документами не подключен. Возникает практический вопрос: обязательно ли проводить договор через оператора ЭДО или можно подписать файл квалифицированной электронной подписью, отправить его контрагенту по электронной почте, получить его подпись и считать договор заключенным?
Для обычного гражданско-правового договора такой вариант в общем случае возможен. Оператор ЭДО является удобным транспортом и средством автоматизации обмена, но именно для договора его участие само по себе не является обязательным условием юридической силы электронной подписи. Можно подготовить один электронный файл договора, подписать его квалифицированной электронной подписью, передать файл и подпись контрагенту по электронной почте, попросить контрагента проверить подпись и подписать тот же самый файл своей квалифицированной электронной подписью, а затем сохранить у обеих сторон исходный файл и обе электронные подписи.
Идея из обсуждения на форуме о применении пункта 2 статьи 434 ГК РФ в целом верная, но рассмотрим подробнее несколько важных нюансов. Недостаточно просто обменяться двумя похожими файлами или поставить на PDF изображения подписей. Нужно правильно организовать именно электронное подписание, проверить полномочия подписантов и сохранить доказательства, позволяющие позднее подтвердить действительность подписей и неизменность документа.
Разберем правовую основу. Согласно пункту 2 статьи 434 ГК РФ письменный договор можно заключить не только путем подписания одного бумажного экземпляра. Допускается составление одного документа, в том числе электронного, подписанного сторонами, а также обмен письмами, электронными документами или иными данными в порядке, позволяющем соблюсти требования к письменной форме сделки.
Дополнительно статья 160 ГК РФ предусматривает, что письменная форма считается соблюденной и при использовании электронных или иных технических средств, если содержание сделки можно воспроизвести в неизменном виде, а применяемый способ позволяет достоверно определить лицо, выразившее волю на совершение сделки.
Поэтому сама электронная почта может выступать каналом передачи договора. Однако здесь необходимо разделить два понятия: способ передачи документа и способ его подписания. Электронная почта передает файл от одной стороны другой, а квалифицированная электронная подпись подтверждает, кем подписан конкретный электронный файл и изменялся ли он после подписания.
Теперь посмотрим на Федеральный закон от 06.04.2011 № 63-ФЗ «Об электронной подписи». По статье 6 информация в электронной форме, подписанная квалифицированной электронной подписью, признается равнозначной бумажному документу, подписанному собственноручной подписью, если законодательством для конкретного документа не установлено требование составлять его исключительно на бумаге.
Следовательно, наличие оператора ЭДО не создает юридическую силу квалифицированной электронной подписи. Эту силу устанавливает закон. Оператор ЭДО решает другие задачи: обеспечивает транспорт документов, маршрутизацию, служебные подтверждения, роуминг между системами, контроль форматов, хранение истории обмена и другие технологические процедуры.
Рассмотрим подробнее практическую схему, которая наиболее близка к обычному подписанию двухстороннего договора.
Согласуем окончательный текст договора. Сначала завершите все правки и получите подтверждение контрагента, что текст является финальным. После начала подписания уже не редактируйте файл.
Сформируем один итоговый файл. Для обычного договора удобно использовать PDF. Главное требование состоит не в конкретном расширении, а в том, чтобы стороны подписывали один и тот же электронный документ. PDF обычно практичнее DOCX, поскольку меньше вероятность случайно отредактировать содержание.
Передадим финальный файл первой стороне для подписания либо подпишем его сами. Создадим квалифицированную электронную подпись непосредственно для этого файла.
Сохраним исходный договор без изменений. Если используется отсоединенная подпись, у нас получится, например, файл договора и отдельный файл электронной подписи. Расширение подписи зависит от используемого программного обеспечения и может выглядеть как .sig, .p7s и т. п.
Отправим контрагенту сам договор и файл подписи. Если документ подписывает представитель, одновременно передадим сведения или файл доверенности, необходимой для подтверждения его полномочий.
Попросим контрагента сначала проверить нашу подпись. Проверим, что подпись относится именно к полученному файлу, сертификат корректен, цепочка сертификации проверяется, документ после подписания не изменялся, а сертификат не был отозван в значимый момент.
Контрагент подпишет тот же исходный файл собственной КЭП. При использовании двух отсоединенных подписей контрагенту не нужно изменять PDF, вписывать туда свое имя или добавлять изображение печати. Его подпись должна быть сформирована для того же файла.
Контрагент вернет вторую электронную подпись. После этого проверим ее со своей стороны.
Сохраним комплект документов у обеих сторон. В архив положим сам договор, подпись первой стороны, подпись второй стороны, документы или сведения о полномочиях подписантов, а также переписку, сопровождавшую обмен.
В результате получим один электронный договор, относительно которого существуют две действительные электронные подписи. При проверке каждой подписи должно подтверждаться, что она сформирована именно для сохраненного файла.
Это существенно надежнее, чем ситуация, когда организация А подписывает свой файл, а организация Б самостоятельно создает другой файл с тем же текстом и подписывает его.
В ответе на форуме справедливо обращено внимание на необходимость убедиться, что тексты договоров идентичны. Для электронной подписи пойдем еще дальше: желательно обеспечить не только визуальную идентичность текста, но и использование одного и того же исходного электронного файла.
Разберем на примере. Допустим, организация А подготовила договор в DOCX и отправила его организации Б. Организация Б открыла файл, сохранила его заново и получила визуально абсолютно такой же документ. Для человека содержание не изменилось, однако внутреннее содержимое файла может отличаться: могут поменяться служебные метаданные, дата сохранения, внутренние XML-файлы DOCX и другие технические данные.
Электронная подпись рассчитывается не по тому, как документ выглядит на экране, а по его электронным данным. Поэтому подпись первого файла может не пройти проверку на втором файле, даже если оба документа визуально выглядят одинаково.
Организуем процесс проще:
подготовим финальную редакцию договора;
зафиксируем один PDF;
не будем больше его пересохранять и редактировать;
создадим подпись первой стороны для этого PDF;
создадим подпись второй стороны для этого же PDF;
сохраним исходный PDF и обе подписи одним комплектом.
Если изменить хотя бы один байт файла после создания электронной подписи, проверка криптографической подписи должна показать, что подписанные данные больше не соответствуют подписи. Именно это свойство электронной подписи защищает договор от незаметного изменения после подписания.
Не обязательно. Рассмотрим два технических варианта.
Первый вариант — две отсоединенные подписи одного исходного файла. Это один из наиболее понятных способов для ручного обмена без оператора ЭДО. Имеем условный файл «Договор.pdf», подпись организации А «Договор_А.sig» и подпись организации Б «Договор_Б.sig». Обе подписи относятся к одному файлу «Договор.pdf».
Преимущество такого способа заключается в том, что после первой подписи не требуется изменять сам договор. Второй участник также подписывает исходный документ. В дальнейшем для проверки предоставляем электронный договор и соответствующие файлы подписей.
Второй вариант — подписи, последовательно включаемые в электронный контейнер или непосредственно в поддерживающий такой сценарий документ. Здесь используем программу, которая корректно работает с несколькими подписями. Первая сторона подписывает документ, затем вторая программа добавляет вторую подпись, не разрушая первую.
При отсутствии заранее согласованного программного обеспечения между организациями первый вариант обычно проще для понимания и проверки.
Не будем применять сомнительную последовательность: подписать PDF, затем открыть его в редакторе, вставить графическое изображение второй подписи, снова сохранить и ожидать, что первая электронная подпись останется действительной. После обычного изменения файла первая криптографическая подпись перестанет соответствовать документу.
Выясним еще одну распространенную причину ошибок. Иногда под фразой «подписать договор ЭЦП» понимают добавление в PDF картинки с подписью директора и печатью. Это совершенно другой механизм.
Квалифицированная электронная подпись — криптографические данные, связанные с электронным документом. При ее проверке можно определить сертификат подписанта и обнаружить изменение подписанных данных.
Изображение подписи, вставленное в PDF или Word, таких свойств само по себе не имеет. Картинка не заменяет КЭП. Скан бумажного договора с подписью также не становится документом, подписанным КЭП, только потому, что на изображении видна рукописная подпись.
Поэтому, если договоренность заключается именно на использовании квалифицированной электронной подписи, передавайте криптографическую подпись, а не ее визуальное изображение.
После получения договора не ограничимся тем, что рядом с файлом лежит файл с расширением .sig. Проверим подпись средствами программы электронной подписи либо соответствующей функциональностью 1С.
Статья 11 Федерального закона № 63-ФЗ связывает признание квалифицированной электронной подписи с выполнением ряда условий. В частности, проверка должна подтвердить принадлежность подписи владельцу квалифицированного сертификата и отсутствие изменений подписанного документа. Также необходимо учитывать действительность сертификата и срок действия ключа электронной подписи.
Разберем по шагам, что желательно проверить:
Убедимся, что подпись математически корректна. Программа должна подтвердить, что подпись соответствует именно этому файлу.
Посмотрим владельца сертификата. Сопоставим его с организацией и человеком, который должен подписывать договор.
Проверим квалифицированность сертификата. Для рассматриваемого надежного сценария обмена договором используем именно квалифицированную электронную подпись.
Проверим срок действия сертификата и информацию об отзыве.
Проверим полномочия подписанта. Отдельно рассмотрим этот вопрос ниже, поскольку действительная электронная подпись физического лица еще не означает автоматически наличие у человека права заключать договор от имени конкретной организации.
Убедимся, что документ после подписания не изменялся.
Не удаляйте файл электронной подписи после успешной проверки. Для дальнейшего доказывания подписания договора необходимо сохранить сам электронный документ вместе с электронными подписями.
Рассмотрим подробнее вопрос полномочий. Здесь очень важно не ограничиваться технической проверкой сертификата.
Если от имени юридического лица действует лицо, имеющее право действовать без доверенности, применяется соответствующая квалифицированная электронная подпись юридического лица в установленном Федеральным законом № 63-ФЗ порядке. Для обычной коммерческой организации речь прежде всего идет о руководителе, сведения о котором подтверждают право действовать без доверенности.
Если договор от имени организации подписывает представитель по доверенности, электронный документ подписывается квалифицированной электронной подписью представителя и одновременно должна представляться доверенность в порядке, установленном законодательством и соглашением сторон. Закон № 63-ФЗ предусматривает данный механизм для электронного взаимодействия юридических лиц.
Поэтому не будем считать достаточным рассуждение: «подпись КЭП проверяется, значит договор точно подписан организацией». Сначала выясним, кому принадлежит сертификат и на каком основании этот человек вправе действовать от имени организации.
Если подписывает сотрудник по доверенности, обеспечим передачу или возможность проверки соответствующей машиночитаемой доверенности. При организации прямого обмена без оператора заранее согласуем с контрагентом, каким способом будет предоставляться МЧД и как вторая сторона сможет ее проверить.
Аналогичный принцип действует для представителя индивидуального предпринимателя: документ подписывается КЭП представителя, а полномочия подтверждаются доверенностью.
Теперь рассмотрим техническую сторону для пользователей 1С. Не будем автоматически отождествлять сервис 1С-ЭДО с подсистемой электронной подписи в самой конфигурации.
В современных конфигурациях на базе Библиотеки стандартных подсистем присутствует функциональность «Электронная подпись и шифрование». Она используется для работы с сертификатами, подписания файлов, проверки электронных подписей и других криптографических операций. В документации 1С среди возможностей подсистемы работы с файлами прямо предусмотрены электронная подпись и шифрование.
В зависимости от конфигурации и версии настройку обычно ищем в разделе «Администрирование» — «Общие настройки» — «Электронная подпись и шифрование» либо в близком по смыслу разделе настроек обмена электронными документами. Конкретный путь меню может отличаться между «1С:Бухгалтерией», «1С:ERP», «1С:Управлением торговлей» и другими решениями.
Включим использование электронной подписи, добавим сертификат и настроим используемое средство криптографии. После этого возможность подписания может быть доступна непосредственно при работе с присоединенными файлами. Современная БСП поддерживает работу с сертификатами и криптографическими средствами через подсистему электронной подписи.
Важно: наличие подсистемы электронной подписи в 1С не означает, что документ обязательно будет отправлен через оператора ЭДО. Подписание файла и транспорт электронного документа — технологически разные операции.
Если типовая конфигурация позволяет сохранить подписанный файл или подпись на диск, используем эту возможность и затем передадим подготовленный комплект контрагенту согласованным каналом.
Если задачу требуется не только выполнить вручную, но и автоматизировать в собственной конфигурации или расширении, рассмотрим стандартные механизмы Библиотеки стандартных подсистем.
Для создания электронной подписи в БСП предусмотрен общий модуль ЭлектроннаяПодписьКлиент. Для инициирования подписания используется процедура ЭлектроннаяПодписьКлиент.Подписать. Для проверки электронной подписи используются механизмы ЭлектроннаяПодпись.ПроверитьПодпись и соответствующая клиентская функциональность. В разных версиях БСП состав параметров методов изменяется, поэтому при разработке обязательно сверим программный интерфейс с документацией той версии БСП, которая встроена именно в нашу конфигурацию.
При работе с присоединенными файлами обратим внимание на процедуру РаботаСФайламиКлиент.ПодписатьФайл. В актуальных версиях БСП у нее предусмотрены параметры, позволяющие управлять типом электронной подписи и выбором доверенности при подписании.
Если уже получена внешняя подпись и ее необходимо добавить в систему, в БСП существует механизм ЭлектроннаяПодписьКлиент.ДобавитьПодписьИзФайла. Для хранения сертификатов используется справочник СертификатыКлючейЭлектроннойПодписиИШифрования. В программном интерфейсе также присутствуют методы для добавления, удаления, проверки и получения информации об электронных подписях.
Для разработчика полезно ориентироваться на следующие стандартные объекты и методы:
ЭлектроннаяПодписьКлиент.Подписать — организация клиентского сценария подписания;
ЭлектроннаяПодпись.ПроверитьПодпись — проверка электронной подписи;
ЭлектроннаяПодписьКлиент.ДобавитьПодписьИзФайла — подключение полученной извне подписи;
РаботаСФайламиКлиент.ПодписатьФайл — сценарий подписания присоединенного файла;
ЭлектроннаяПодпись.УстановленныеПодписи — получение информации об установленных подписях в поддерживающих ее версиях БСП;
СертификатыКлючейЭлектроннойПодписиИШифрования — справочник сертификатов электронной подписи и шифрования.
Не будем копировать программный код из другой версии БСП без проверки. Интерфейсы подсистемы развиваются, появляются новые параметры проверки сертификатов, работы с доверенностями, мобильной подписью и усовершенствованными форматами подписи. Сначала определим версию БСП нашей конфигурации, затем откроем документацию соответствующего программного интерфейса.
Если хотим сохранить привычный полноценный ЭДО, сначала рассмотрим роуминг. Разные операторы сами по себе не означают, что обмен невозможен. В инфраструктуре ЭДО существуют межоператорские механизмы обмена, а ФНС публикует требования и технологические правила для операторов. В типовых решениях 1С для полноценного электронного документооборота настраивается учетная запись ЭДО и обмен с контрагентом.
Поэтому возможны два организационных решения:
Настроим роуминг или другой поддерживаемый операторами межоператорский обмен. Этот вариант удобнее, если документов много, нужно автоматически получать статусы, использовать формализованные документы и хранить централизованный журнал обмена.
Для отдельного обычного договора откажемся от транспортной функции оператора и обменяемся подписанными КЭП файлами напрямую. Этот вариант подходит, когда необходимо подписать ограниченное количество неформализованных документов, а подключать дополнительную услугу только ради одного договора нецелесообразно.
Выбор зависит не столько от юридической силы подписи, сколько от масштаба документооборота и требований к автоматизации.
Рассмотрим и второй возможный сценарий. Статьи 160 и 434 ГК РФ позволяют в определенных случаях подтвердить письменную форму договора обменом электронными сообщениями, если используемый способ позволяет достоверно определить лицо, выразившее волю. Поэтому судебное доказательство заключения договора не всегда требует квалифицированной электронной подписи.
Например, стороны могут заранее указать в договоре официальные адреса электронной почты и установить, что сообщения и документы, направленные с этих адресов, признаются исходящими от соответствующей стороны.
Однако такой способ не нужно смешивать с КЭП. При обычной электронной почте значительно больше внимания потребуется уделять доказательствам принадлежности адреса, содержанию переписки, полномочиям отправителя и отсутствию подмены документа.
Если у обеих сторон уже есть квалифицированные электронные подписи, разумнее использовать их. Тогда электронная почта будет выполнять только транспортную функцию, а авторство и целостность конкретного файла будут подтверждаться криптографической подписью.
Чтобы дополнительно уменьшить вероятность спора, рассмотрим возможность заранее включить в договор условие об электронном взаимодействии.
Зафиксируем, что стороны вправе подписывать договор, дополнительные соглашения и иные согласованные документы квалифицированной электронной подписью и передавать их непосредственно друг другу по указанным адресам электронной почты либо через согласованные информационные системы.
Укажем официальные электронные адреса сторон и порядок сообщения об их изменении.
Отдельно установим, что электронный документ, подписанный квалифицированной электронной подписью уполномоченного лица, признается сторонами равнозначным документу на бумажном носителе с собственноручной подписью в пределах, допускаемых законодательством.
Также определим порядок предоставления доверенности, если документы подписываются представителями.
Для отсоединенных подписей полезно прямо договориться, что договор может представлять собой неизменный файл документа и отдельные файлы КЭП каждой стороны.
Такой раздел не является источником юридической силы квалифицированной подписи — основные правила уже установлены Федеральным законом № 63-ФЗ. Он нужен прежде всего для того, чтобы стороны одинаково понимали процедуру обмена и впоследствии не спорили о допустимом канале передачи документов.
Разберем вопрос хранения. Не будем ограничиваться сохранением распечатанного PDF с надписью «подписано электронной подписью». Распечатка не содержит криптографической подписи в исходном виде.
Для полноценного электронного архива сохраним:
исходный электронный файл договора;
электронную подпись первой стороны;
электронную подпись второй стороны;
при необходимости сертификаты, используемые для проверки;
МЧД или сведения, позволяющие подтвердить полномочия представителей;
электронные письма, которыми стороны передавали подписанные документы;
при необходимости результаты проверки электронной подписи.
Храним все составляющие как единый комплект. Если через несколько лет останется только PDF, а файлы отсоединенных подписей будут удалены, доказать факт именно криптографического подписания станет существенно сложнее.
Если договор должен храниться много лет, рассмотрим использование усовершенствованных форматов электронной подписи и доверенных меток времени. Современные версии механизмов 1С поддерживают, в частности, работу с подписями CAdES-T и CAdES-A, а также усовершенствование ранее созданных подписей.
Для разового короткого договора этот вопрос может не иметь практического значения, но для документов с длительным сроком хранения он помогает сохранить дополнительные доказательства существования подписи в определенный момент времени.
При этом не будем считать обычную дату файла или дату электронного письма достоверной меткой времени электронной подписи. Если требуется криптографически подтверждаемое время подписания, используем соответствующие механизмы доверенной метки времени.
Теперь рассмотрим главное ограничение. Из того, что обычный договор можно подписать КЭП и передать напрямую, нельзя делать вывод, что любой электронный документ можно отправлять таким образом.
Для отдельных видов документов законодательство устанавливает специальные форматы, информационные системы или порядок передачи.
Например, для электронных счетов-фактур действует специальный порядок электронного обмена через операторов ЭДО. ФНС указывает, что выставление и получение электронных счетов-фактур по телекоммуникационным каналам связи производится через организации, обеспечивающие такой электронный документооборот.
Поэтому не подменяйте официальный электронный счет-фактуру файлом PDF, подписанным КЭП и отправленным обычным письмом. Для документов, для которых законодательством установлен специальный электронный формат или транспорт, необходимо соблюдать именно этот порядок.
Это же правило применим всякий раз, когда специальный закон, нормативный акт, условия государственного контракта, информационная система или соглашение сторон устанавливают конкретный способ оформления и передачи документа.
Перед использованием прямого обмена зададим три вопроса:
Является ли передаваемый файл обычным гражданско-правовым договором или специальным формализованным документом?
Не установлена ли законом обязательная специальная форма или обязательная информационная система?
Не договорились ли сами стороны ранее, что документы считаются подписанными только после обмена через конкретную систему ЭДО?
Если специальных ограничений нет, схема с КЭП и прямой передачей файла значительно проще.
Посмотрим еще на один важный случай. Статья 434 ГК РФ учитывает не только обязательные требования закона, но и форму, о которой договорились сами стороны. Если стороны прямо предусмотрели конкретную форму заключения договора или обязательный способ электронного обмена, такое условие нельзя без анализа просто проигнорировать.
Например, если в рамочном соглашении указано, что юридически значимые документы стороны обменивают исключительно через определенную систему ЭДО, сначала изменим это соглашение или отдельно согласуем допустимость другого способа.
Если же никакой обязательной процедуры ранее не установлено, можем организовать непосредственный обмен КЭП-подписанными файлами.
Теоретически письменный договор может заключаться путем обмена документами, и именно на это указывает пункт 2 статьи 434 ГК РФ. Поэтому наличие одного физического файла с двумя подписями не является универсальным обязательным условием для всех договоров.
Однако с практической точки зрения при электронном подписании лучше упростить доказательственную ситуацию и подписывать один исходный файл.
Если организация А подписала «Договор-А.pdf», а организация Б подписала «Договор-Б.pdf», в случае спора потребуется дополнительно доказывать, что документы действительно содержали одни и те же согласованные условия.
Если обе стороны подписали один файл «Договор.pdf», вопрос решается намного проще: проверяем обе электронные подписи относительно одного объекта данных.
Кроме того, необходимо учитывать пункт 4 статьи 434 ГК РФ: законом или соглашением сторон может быть предусмотрено, что договор заключается только путем составления одного документа, подписанного сторонами.
Поэтому для универсальной практической инструкции используем один итоговый файл.
Соберем решение в единый рабочий процесс.
Завершим согласование договора и зафиксируем финальную редакцию.
Сохраним договор в PDF и присвоим файлу понятное имя, например «Договор_125_от_20-08-2026.pdf».
Больше не будем редактировать этот файл.
Проверим, кто подписывает документ от нашей организации. Если это руководитель, убедимся в его полномочиях. Если представитель — подготовим необходимую доверенность.
Подпишем исходный PDF квалифицированной электронной подписью средствами используемой программы или доступной функциональности 1С.
Если используется отсоединенная подпись, сохраним полученный файл подписи вместе с PDF.
Перед отправкой сами выполним проверку созданной подписи. Убедимся, что программа сообщает о корректности подписи и неизменности файла.
Отправим контрагенту исходный PDF, электронную подпись и необходимые сведения о полномочиях подписанта.
Попросим контрагента проверить полученную подпись до подписания договора со своей стороны.
Контрагент подпишет тот же PDF своей квалифицированной электронной подписью.
Получим от контрагента его файл электронной подписи и при необходимости сведения о доверенности.
Проверим вторую подпись.
Сохраним PDF, обе подписи, подтверждение полномочий и электронную переписку в одной папке или в электронном архиве организации.
Если используем 1С и конфигурация поддерживает стандартную подсистему электронной подписи, рассмотрим хранение договора как присоединенного файла и сохранение информации о его электронных подписях непосредственно в информационной базе. Это упростит последующий поиск и контроль документа.
Вернемся к исходной задаче: операторы ЭДО разные, дополнительный тариф не подключен, необходимо подписать именно договор.
Если речь идет об обычном хозяйственном договоре и специальные нормы не требуют другого способа оформления, не обязательно подключать дополнительный тариф только ради передачи этого договора.
Используем следующий вариант:
сформируем окончательный договор в одном файле;
подпишем его КЭП первой стороны;
отправим исходный файл и электронную подпись контрагенту по электронной почте;
контрагент проверит подпись;
контрагент подпишет тот же файл своей КЭП;
получим его электронную подпись;
проверим вторую подпись;
сохраним исходный договор и обе подписи.
Таким образом, полезный ответ из обсуждения о возможности заключения договора посредством обмена электронными документами дополним главным техническим правилом: не просто следите за совпадением текста, а по возможности обеспечьте подписание обеими сторонами одного и того же неизменного файла.
Также проверим полномочия подписантов и МЧД, если договор подписывает представитель. Не будем использовать эту схему для электронных счетов-фактур и других документов, для которых установлен специальный обязательный порядок электронного обмена.
Подведем итог. Оператор ЭДО удобен, но для обычного договора не является единственным способом организовать юридически значимое электронное подписание. Статья 434 ГК РФ допускает заключение договора в электронной форме и обмен электронными документами, статья 160 ГК РФ определяет общие требования к соблюдению письменной формы, а Федеральный закон № 63-ФЗ устанавливает правовой статус квалифицированной электронной подписи.
Поэтому при отсутствии подходящего тарифа или возможности межоператорского обмена подпишем один финальный файл договора квалифицированной электронной подписью и передадим его контрагенту напрямую. Контрагент проверит подпись, подпишет этот же файл своей КЭП и вернет вторую подпись.
При работе в 1С используем доступную в конфигурации подсистему «Электронная подпись и шифрование». Для разработок на БСП ориентируемся на стандартные механизмы ЭлектроннаяПодписьКлиент.Подписать, ЭлектроннаяПодпись.ПроверитьПодпись, РаботаСФайламиКлиент.ПодписатьФайл и ЭлектроннаяПодписьКлиент.ДобавитьПодписьИзФайла, сверяя параметры методов с версией БСП конкретной информационной базы.
Главное — не изменяйте подписываемый файл, проверяйте обе КЭП, подтверждайте полномочия подписантов и сохраняйте электронный договор вместе со всеми файлами подписей. Для документов со специальным обязательным порядком обмена, в частности электронных счетов-фактур, применяйте установленный законодательством механизм и не заменяйте его обычной электронной почтой.
Информация носит справочный характер