Интеграция 1С с сервисами электронного документооборота (ЭДО), такими как Диадок, через REST API — это эффективный способ автоматизировать передачу первичных документов. Однако на пути разработчика часто встают сложности, связанные с жесткими требованиями ФНС к форматам XML, нюансами работы с криптографией и спецификой методов самого API. В этой статье мы подробно разберем, как выстроить процесс подписания и отправки Универсального передаточного документа (УПД), избежав типичных ошибок при формировании титулов.
Для начала проанализируем высокоуровневую логику взаимодействия вашей информационной базы с сервером Диадока. Процесс состоит из нескольких последовательных этапов, которые мы должны реализовать в коде:
PostMessage для окончательной доставки документа получателю.Одной из главных ошибок является попытка собрать XML-файл УПД вручную с помощью текстовых строк или построчного формирования DOM. Формат УПД (особенно по новым приказам ФНС № 820 или № 970) крайне сложен и чувствителен к порядку элементов. Рассмотрим более правильный путь — использование метода GenerateTitleXml. Для сценариев, где требуется предварительное формирование файлов на стороне 1С, существуют готовые обработки для выгрузки XML, которые помогают избежать ошибок ручного составления — для этой задачи подойдёт обработка формирования XML УПД по формату ФНС.
Этот метод принимает на вход структуру данных (в формате JSON или Protocol Buffers) и возвращает готовый XML, который соответствует всем требованиям законодательства. Выясним причину частых ошибок: если API возвращает сообщение о невалидном дочернем элементе, значит, в структуре запроса нарушена иерархия или пропущены обязательные поля для конкретной версии документа.
Проанализируем пример структуры для передачи данных о подписанте. В новых форматах УПД рекомендуется использовать объект ExtendedSignerDetails (расширенные сведения о подписанте). Рассмотрим пример кода на языке 1С для подготовки такой структуры (в упрощенном виде для понимания логики):
// Подготовка структуры для формирования титула продавца
ДанныеТитула = Новый Структура;
ДанныеТитула.Вставить("SellerTitle", Новый Структура);
ДанныеТитула.SellerTitle.Вставить("DocumentDate", Формат(ТекущаяДата(), "ДФ=dd.MM.yyyy"));
ДанныеТитула.SellerTitle.Вставить("DocumentNumber", Объект.Номер);
// Заполнение сведений о подписанте (ExtendedSignerDetails)
Подписант = Новый Структура;
Подписант.Вставить("JobTitle", "Генеральный директор");
Подписант.Вставить("FirstName", "Иван");
Подписант.Вставить("Surname", "Иванов");
Подписант.Вставить("Inn", "123456789012");
Подписант.Вставить("SignerType", 1); // 1 - индивидуальный предприниматель или представитель юрлица
ДанныеТитула.SellerTitle.Вставить("Signers", Новый Массив);
ДанныеТитула.SellerTitle.Signers.Добавить(Подписант);
Важно: При формировании запроса к GenerateTitleXml обязательно указывайте правильный TypeNamedId (например, utd) и Function (например, СЧФДОП для УПД со статусом 1).
После того как мы получили бинарные данные XML от сервера Диадок, их необходимо подписать. Если вы работаете на стороне сервера 1С под Windows, можно использовать COM-объект CAdESCOM.CadesSignedData, внешние компоненты, поставляемые Диадоком, или готовые обработки для подписи файлов средствами платформы. Разберем ситуацию, когда используется стандартный крипто-плагин. Результатом должна быть отсоединенная подпись (detached signature) в кодировке Base64.
Если в вашей компании внедрена Машиночитаемая доверенность (МЧД), информацию о ней необходимо включить в запрос при отправке сообщения. В структуре подписи или в параметрах метода отправки указывается идентификатор доверенности (GUID) и ИНН организации-доверителя. Чтобы упростить контроль за сроками действия сертификатов и доверенностей, полезно вести учет ЭЦП и МЧД в информационной системе.
При работе с большими документами или массовой отправкой передача бинарного контента напрямую в методе PostMessage может приводить к таймаутам и чрезмерному потреблению памяти. Посмотрим на альтернативный метод — использование "Полки" (хранилища временных файлов).
Процесс выглядит так:
/CloudSign/Upload или аналогичным для загрузки контента.FileId (или NameOnShelf).PostMessage в структуре DocumentAttachment вы не заполняете поле Content, а передаете идентификатор в поле NameOnShelf.Это позволяет развязать процесс загрузки тяжелых данных и процесс регистрации сообщения в системе.
Если вы выступаете на стороне получателя и вам нужно подписать входящий УПД, алгоритм немного меняется. Вы не можете просто отправить подпись к чужому файлу. Вам необходимо:
GenerateTitleXml для генерации "Титула покупателя" (BuyerTitle).PostMessagePatch, привязав его к EntityId исходного документа.Часто разработчики сталкиваются с ошибкой: The element 'UniversalTransferDocumentBuyerTitle' has invalid child element 'SignerDetails'. Это происходит из-за того, что в разных версиях формата УПД используются разные поля для описания полномочий. Если вы используете актуальный формат, вместо устаревшего SignerDetails ожидается массив Signers, содержащий структуры Employee или ExtendedSignerDetails. Выясним причину: схема XSD строго определяет последовательность элементов. Даже если данные верны, но нарушен их порядок (например, Signers идет после AdditionalInfoId, а должно быть наоборот согласно схеме), сервер выдаст ошибку.
Совет: Всегда проверяйте актуальную документацию Диадок API в разделе "Генерация титулов", так как требования ФНС регулярно обновляются, и то, что работало в формате 820, может потребовать корректировки в формате 970.
В завершение отметим, что несмотря на кажущуюся сложность, REST API Диадока предоставляет все необходимые инструменты для бесшовной интеграции. Главное — делегировать формирование сложных XML самому сервису через GenerateTitleXml и внимательно следить за соответствием типов данных в JSON-запросах. После завершения документооборота важно обеспечить надежное хранение файлов, с чем может помочь «Архив ЭДО (Лайт)» — поможет автоматизация загрузки и архивирования документов из Диадок.