История изменений API

v.1.48 - 25.10.2017

  • Появился новый метод GetDocumentTypes, возвращающий описание типов документов, доступных в ящике.
  • В структуре MessageToPost, которую принимает метод /V3/PostMessage, изменилось поле CustomDocumentAttachments. Теперь оно называется DocumentAttachments и может использоваться для отправки документов любых типов.

19.10.2017

  • Добавили ограничение на количество документов в структуре MessageToPost, которую можно отправить через метод PostMessage. Текущее максимально допустимое количество документов в сообщении - 30.

v.1.47.1 - 18.09.2017

  • В структуре User, которая возвращается методом /GetMyUser, изменилась структура CertificateInfo. В неё были добавлены два новых поля: OrganizationName - наименование организации, на которую выдан сертификат и Inn - ИНН организации, на которую выдан сертификат.

v.1.47 - 06.09.2017

  • В API Диадока появилась новая версия метода /V4/GetMessage. Основное отличие версии V4 от версии V3 в том, что новая версия метода имеет дополнительную опцию injectEntityContent. Подробное описание есть метода здесь.

v.1.46.2 - 31.08.2017

  • Появилась новая структура данных CancellationInfo, содержащая информацию об отмене сущности.
  • Изменилось поведение GetMessage. Возвращаются отменённые запросы на согласование вместе с соответствующими сущностями отмены. Ранее, отменённый запрос на согласование не возвращался и, соответственно, не было возможности определить, что данный запрос на соглавание был отменён.

v.1.46.1 - 30.08.2017

v.1.46 - 23.08.2017

  • Появилась новая структура данных SignatureInfo, содержащая информацию о подписи и сертификате.
  • Добавлен метод GetSignatureInfo, получающий на вход идентификаторы подписи и возвращающий данные в структуре SignatureInfo.
  • В структуре данных InvoiceItemAmountsDiff поле Subtotal, отражающее сумму с учетом налога, теперь является опциональным.
  • Появилась вторая версия метода ExtendedSignerDetails, принимающая на вход структуру DocumentTitleType

v.1.44.2 - 13.07.2017

Добавлены следующие поля:

  • В структуре данных Organization добавлено поле CertificateOfRegistryInfo, в котором указана информация о свидетельстве о государственной регистрации.
  • В структуре данных DocumentInfo добавлено поле AttachmentVersion, в котором указана версия документа.

v.1.44.1 - 29.06.2017

Добавлен признак «Разрешить посылать зашифрованные документы».

В структуре данных Box появилось поле EncryptedDocumentsAllowed, в котором указан признак «Разрешить посылать зашифрованные документы».

v.1.44 - 06.06.2017

Добавлено наименование первичного документа.

В структуре данных EncryptedXmlDocumentAttachment появилось поле DocumentName, в котором указано наименование первичного документа, определенное организацией (НаимДокОпр).

v.1.43 - 02.06.2017

Добавлена дата ликвидации организации.

В структуре данных Organization появилось поле LiquidationDate, в котором указана дата ликвидации организации по данным из ЕГРЮЛ и ЕГРИП.

v.1.42 - 03.05.2017

Добавлены подписи промежуточных получателей и их статусы.

В структуре данных Document появилось поле ProxySignatureStatus, отвечающее за статус подписи промежуточного получателя. В структуре Message в поле Entities теперь возвращаются сами подписи промежуточного получателя.

v.1.41.3 - 11.04.2017

Появилась возможность определить версию XSD-схемы, в соответствии с которой был отправлен документ.

В структурах данных Document и Entity появилось поле AttachmentVersion. Значения, возвращаемые в данном поле, показывают версию XSD-схемы. Версия XSD возвращается для документов, сформированных в соответствии с приказами ФНС №155 от 24 марта 2016 и №189 от 13 апреля 2016. В дальнейшем планируется расширение перечня возвращаемых значений.

v.1.41.1 - 30.03.2017

Появилась возможность отправлять неформализованные акты и акты сверки без указания номера документа.

В структурах данных ReconciliationActAttachment и AcceptanceCertificateAttachment поле DocumentNumber стало необязательным.

v1.41 - 27.03.2017

В API Диадока появилась возможность снимать документ с маршрута согласования, подробнее см. описание поля ResolutionRouteRemovals в структуре MessagePatchToPost. Также произошла замена термина «цепочка согласования» на маршрут согласования в документации, а в названиях структур данных и HTTP-методах слово Chain было заменено словом Route.

Полный список всех переименований:

  • в enum-е AttachmentType элемент ResolutionChainAssignment переименован в ResolutionRouteAssignment
  • в структуре MessagePatchToPost поле ResolutionChainAssignments переименовано в ResolutionRouteAssignments
  • структура ResolutionChainAssignment переименована в ResolutionRouteAssignment
  • в структуре ResolutionRouteAssignment поле ChainId переименовано в RouteId
  • структура ResolutionChainList переименована в ResolutionRouteList
  • в структуре ResolutionRouteList поле ResolutionChains переименовано в ResolutionRoutes
  • структура ResolutionChain переименована в ResolutionRoute
  • в структуре ResolutionRoute поле ChainId переименовано в RouteId
  • HTTP-метод GetResolutionChainsForOrganization переименован в GetResolutionRoutesForOrganization

v1.40 - 24.03.2017

В API Диадока появились методы для парсинга титулов УКД: продавца и покупателя

v1.39 - 15.03.2017

В API Диадока появилась новая версия метода /V5/GetNewEvents /, для получения ленты событий по ящику.

Основное отличие версии V5 от версии V4 в том, что новая версия метода работает для всех пользователей в ящике.

Лента событий формируется по подразделению организации, в котором состоит пользователь. Подробное описание есть метода здесь /.

v1.38.3 - 10.02.2017

В структуре OrganizationWithCounteragentStatus добавилось поле LastEventTimestampTicks.

v1.38 - 23.12.2016

В Диадоке появилась возможность работать с новыми типами документов УПД и УКД, в связи с чем в документации появились новые разделы:

Появились новые методы API:

Появились новые структуры в API:

В структуре MessageToPost добавилось поле UniversalTransferDocumentSellerTitles:

  • для отправки УПД с функцией СЧФ,
  • для отправки УКД с функцией КСЧФ,
  • для отправки титула продавца УПД с функцией ДОП и СЧФДОП,
  • для отправки титула продавца УКД с функцией ДОП и СЧФДОП,

Для отправки титула покупателя УПД и УКД в структуре MessageToPost добавилось поле UniversalTransferDocumentBuyerTitles:

  • для отправки титула покупателя УПД с функцией ДОП и СЧФДОП,
  • для отправки титула покупателя УКД с функцией ДОП и СЧФДОП,

В структуру PrepareDocumentsToSignRequest добавилась возможность указать расширенные данные о подписанте.

В DocflowAPI произошли следующие изменения:

v1.37 - 10.10.2016

Добавлена структура для отправки кастомных типов документов - CustomDocumentAttachment.

Примечание

Функциональность находится в разработке

v1.36 - 07.04.2016

  • Добавлен параметр includeRelations у метода GetOrganizationsByInnKpp, который позволяет получить данные о количестве запросов на поиск и приглашения к сотрудничеству для данной организации.

v1.35 - 25.03.2016

  • Добавлена возможность авторизации по логину/паролю и сертификату с ключом, полученным доверенным сервисом (см. описание методов Authenticate и AuthenticateConfirm)

v1.34 - 10.03.2016

  • Добавлена возможность редактировать пакеты документов:

    • В структуре MessagePatchToPost добавлено поле EditDocumentPacketCommands.
    • Добавлена новая структура EditDocumentPacketCommand, описывающая операцию редактирования пакета документов.

v1.33 - 10.02.2016

  • Добавлен метод GetDepartment, позволяющий получить информацию о конкретном подразделении организации.

v1.32 - 19.01.2016

  • Значения перечисления ResolutionType (Resolution) синхронизированы со значениями, возвращаемые с сервера (значение Undefined заменено на UndefinedResolutionType)
  • В структуру MessageToPost добавлен флаг залоченного пакета LockPacket.

v1.31 - 02.12.2015

  • Добавлено свойство с сообщением об ошибке при доставке в роуминг RoamingNotificationStatusDescription в структуре Document.
  • Добавлены новые версии методов GetCounteragent и GetCounteragents, в которых изменилась логика показа видимых подразделений.

v1.30 - 11.11.2015

  • Добавлено свойство признак прочитанности IsRead в структуре Document.
  • В методе GetDocuments теперь можно искать непрочитанные документы.

v1.29 - 14.10.2015

  • Появилась возможность отправлять новый тип документа «Дополнительное соглашение к договору».

    • в структуре MessageToPost добавилась стуктура SupplementaryAgreementAttachment для передачи дополнительного соглашения к договору
    • в структуре Entity и DocumentType появился новый тип для дополнительного соглашения к договору
    • в структуре Document появилась вложенная структура для описания метаданных дополнительного соглашения к договору - SupplementaryAgreementMetadata
    • в структуре DocumentInfo появилась вложенная структура для описания метаданных дополнительного соглашения к договору - SupplementaryAgreementInfo

v1.28 - 10.08.2015

  • Добавилась возможность отправлять зашифрованные товарные накладные и акты выполненных работ. Для этого были внесены следующие изменения:

    • в структуре MessageToPost добавились поля EncryptedXmlTorg12SellerTitles, EncryptedXmlAcceptanceCertificateSellerTitles
    • появилась структура EncryptedXmlDocumentAttachment для передачи зашифрованных накладных и актов

v1.27 - 10.08.2015

  • Добавлен параметр autoRegister у метода GetMyOrganizations, который позволяет управлять автоматической регистрацией пользователя с сертификатом КЭП в организации.

v1.26 - 30.07.2015

  • Добавилась возможность отправлять зашифрованные счета-фактуры. Для этого были внесены следующие изменения:

    • появились структуры CounteragentCertificateList и Certificate для описания списка сертификатов контрагента
    • в структурах Document и Entity появился флаг IsEncryptedContent, этот флаг указывается для передачи контента в зашифрованном виде
    • появились структуры EncryptedInvoiceAttachment, EncryptedDocumentMetadata, EncryptedInvoiceMetadata, EncryptedInvoiceCorrectionMetadata для передачи зашифрованных счетов-фактур, и метаданных для исправлений и корректировок.
    • в структуре MessageToPost добавилось поле EncryptedInvoices, для передачи зашифрованных счетов-фактур
    • в структуре MessagePatchToPost добавилось поле SignatureVerifications, для передачи резльтатов проверки подписей на стороне получателя
    • появился метод GetCounteragentCertificates для запроса списка сертификатов контрагента
    • в структуре Signer добавилося отпечаток сертификата SignerCertificateThumbprint
  • Добавилась возможность изменения подписанта в неотправленных исходящих документах:

    • появилась структура DocumentToPatch представляющая изменение исходящего неотправленного документа
    • изменились структуры DocumentSignature, PrepareDocumentsToSignRequest - в них добавилась возможность ссылаться на изменение исходящего неотправленного документа

v1.25 - 28.05.2015

  • Добавлен новый метод http/GetResolutionChainsForOrganization для получения списка цепочек согласования организации. Также изменен протобуфер MessagePatchToPost - добавились структура ResolutionChainAssignment для постановки документа на цепочку согласования.

v1.24 - 25.05.2015

  • Добавлен новый метод для получения печатной формы со штампом для пересланного документа - GenerateForwardedDocumentPrintForm

v1.23 - 28.04.2015

  • Добавлен метод аутентификации по ключу, полученному доверенным сервисом (см. описание метода Authenticate)

v1.22.1 - 13.04.2015

  • Изменены структуры данных InvoiceInfo и InvoiceCorrectionInfo, которые предоставляют исходные данные для формирования СФ и КСФ в XML-формате при помощи метода GenerateInvoiceXml
  • Появилась возможность указывать версию формата СФ и КСФ и также указывать поля, соответствующие новой версии XML-формата СФ
  • Изменилась логика работы метода ParseInvoiceXml в зависимости от формата СФ
  • Версия сборки SDK не изменилась, всем кто скачал сборку в период с *10.04.2015-12.04.2015*, необходимо скачать свежую сборку от 13.04.2015

v1.22 - 10.04.2015

  • Изменены структуры данных InvoiceInfo и InvoiceCorrectionInfo, которые предоставляют исходные данные для формирования СФ и КСФ в XML-формате при помощи метода GenerateInvoiceXml, появилась возможность указывать версию формата СФ и КСФ.

v1.21 - 02.04.2015

  • Добавлена возможность отравлять приглашения организациям, не подключенным к Диадоку. Соответствующие изменения были внесены в методы AcquireCounteragent и AcquireCounteragentResult.

Старая версия метода AcquireCounteragent через некоторое время будет отключена.

v1.20 - 20.01.2015

v1.19 - 15.10.2014

  • Добавлен метод GenerateDocumentZip, позволяющий формировать zip-архив с документом, подписями к нему и файлами документооборота.

v1.18 - 02.10.2014

  • Добавлена возможность привязывать к документам произвольные данные «ключ-значение». Соответствующие изменения были внесены в структуры MessageToPost и MessagePatchToPost.

v1.17 - 05.06.2014

  • В Диадоке появилась возможность получать статус доставки документа в роуминг - RoamingNotification

v1.16 - 25.02.2014

В Диадоке появилась поддержка новых типов полуформализованных документов:

v1.15 - 05.02.2014

  • Появилась возможность получать через API протокол передачи документа. См. описание метода GenerateDocumentProtocol.

Выгрузка протокола передачи документа адресатом пересылки документа третьей стороне производится при помощи метода GenerateForwardedDocumentProtocol.

v1.14 - 24.01.2014

Выгрузка содержимого связанных с документом сущностей адресатом пересылки документа третьей стороне производится при помощи метода GetForwardedEntityContent.

v1.11 - 20.12.2013

  • Сборка protobuf-net.dll теперь внедрена в библиотеку DiadocApi.dll. Это позволяет интегратору использовать в своем проекте другую версию сборки protobuf-net.dll.

v1.10 - 06.12.2013

  • В Диадоке появилась возможность отправлять формализованные отказы от подписи документов. Xml файл отказа формируется при помощи метода GenerateSignatureRejectionXml.

    Для отправки отказов используется метод PostMessagePatch, куда передается структура MessagePatchToPost с заполненным списком MessagePatchToPost.XmlSignatureRejections.

Для получения документов с отказом в подписи через метод GetDocuments используются такие же фильтры, как для неформализованных отказов. Формализованным отказам соответствует тип XmlSignatureRejection из перечисления AttachmentType.

  • Отправка неформализованных отказов от подписи в адрес роуминговых организаций теперь запрещена.
  • Новые отказы от подписи, при получении их через старые версии SDK, будут иметь тип SignatureRequestRejection (как отказы старого формата), но в содержимом соответствующих сущностей вместо строки с комментарием к отказу теперь будет возвращаться xml файл отказа в кодировке CP1251.

v1.9 - 20.10.2013

  • В Диадоке появилась возможность аннулирования документов.

Для отправки предложения об аннулировании через API при обращении к методу PostMessagePatch следует наполнять список MessagePatchToPost.RevocationRequests.

Каждый элемент этого списка представляет собой структуру RevocationRequestAttachment.

Для принятия предложения об аннулировании через API при обращению к методу PostMessagePatch следует наполнять список MessagePatchToPost.RequestedSignatures.

Для отказа от предложения об аннулировании через API при обращении к методу PostMessagePatch следует наполнять список MessagePatchToPost.XmlSignatureRejections.

Каждый элемент этого списка представляет собой структуру XmlSignatureRejectionAttachment. При получение информации о документах через API при помощи методов GetMessage, GetDocument и т.п. для любых документов в структуре Document заполняется поле RevocationStatus.

v1.8 - 13.08.2013

v1.7 - 10.04.2013

  • В Диадоке появилась поддержка нового типа полуформализованных документов - ценовых листов.

Ценовой лист представляет собой двусторонний документ (для него требуется подпись контрагента / отказ в запросе подписи) со следующими обязательными реквизитами: дата составления и номер самого ценового листа, дата вступления ценового листа в силу, дата и номер договора, к которому относится ценовой лист.

Для отправки ценовых листов через API при обращении к методу PostMessage следует наполнять список MessageToPost.PriceLists.

Каждый элемент этого списка представляет собой структуру PriceListAttachment.

При получение информации о документах через API при помощи методов GetMessage, GetDocument и т.п. для ценовых листов в структуре Document заполняется поле PriceListMetadata.

При фильтрации документов методом GetDocuments также можно использовать новый тип документов PriceList.

  • Для получения списка пользователей конкретной организации добавлен метод GetOrganizationUsers.
  • У структуры Organization добавлено поле IfnsCode, позволяющее получить код налоговой инспекции - место подачи декларации по НДС.

v1.6 - 14.03.2013

  • Добавлена возможность отправлять документы, подписанные тестовой подписью (см. описание флага SignedContent.SignWithTestSignature).
  • Добавлены методы ParseAcceptanceCertificateSellerTitleXml и ParseTorg12SellerTitleXml, позволяющие преобразовывать xml-файлы формализованных актов (титул исполнителя) и ТОРГ-12 (титул продавца) в структуры AcceptanceCertificateSellerTitleInfo и Torg12SellerTitleInfo соответственно.
  • Функциональность метода PostMessage была расширена: при помощи флага MessageToPost.DelaySend можно задержать отправку документа, чтобы была возможность провести его согласование. В связи с этим изменился набор возможных состояний документов, что требует обновления логики клиентских решений.
  • Для определения, может ли конкретный пользователь запрашивать согласования, может использоваться флаг OrganizationUserPermissions.CanRequestResolutions в свойствах пользователя, возвращаемых вызовом GetMyPermissions.
  • В сообщение EntityPatch добавлено поле ContentIsPatched, через которое сервер выдает информацию о том, что исходный документ в процессе подписания был модифицирован (в документ была внедрена информация о том, кто подписал этот документ).
  • Изменена логика работы с перечислимыми типами: теперь в большинстве перечислений имеется специальное значение с именем UnknownИмяПеречисления.

Клиент может получить (и получит) такое значение в том и только том случае, если имеет место рассогласование версий API между клиентом и сервером, и клиент не может правильно интерпретировать информацию, возвращаемую сервером (например, в случае добавления новых элементов к перечислению клиент будет получать вместо вновь добавленных элементов этот самый UnknownИмяПеречисления элемент). Клиент обязан корректно обрабатывать такие ситуации (например, путем информирования пользователя о необходимости обновить интеграционный модуль).

Для доступа к новой функциональности и во избежание возможного конфликта версий убедительная просьба скачать и обновить версию инструментария для разработчиков Diadoc SDK v1.6 <https://diadoc.kontur.ru/sdk/>__

v1.5 - 31.01.2013

  • Появилась возможность работы с документами, пересылаемыми внутри организации.

Для этого добавились новые элементы в перечислениях NonformalizedDocumentStatus, BilateralDocumentStatus и UnilateralDocumentStatus, а также добавились поля для работы с подразделениями организации в структурах Department, Entity, Document, Message и MessageToPost.

  • Были расширены возможности работы с «черновиками», то есть с подготовленными, но не отправленными документами. Для отправки ранее созданного черновика добавился метод SendDraft.

Кроме того, черновики теперь можно загружать в Диадок при помощи метода PostMessage (это предпочтительный путь).

Для этого обновилась структура MessageToPost, добавилась структура DraftToSend и структура RequestedSignature была переименована в DocumentSignature (см. описание MessagePatchToPost).

  • Появилась возможность загружать большие по размеру документы в Диадок при помощи сервиса «полки документов». Для этих целей добавился метод ShelfUpload и обновилась структура SignedContent, в которой появилось поле NameOnShelf, позволяющее сослаться на уже загруженный на «полку» файл.
  • Появилась возможность восстанавливать ранее удаленные отдельные документы и сообщения целиком. Для этих целей добавлен метод Restore, а в структурах EntityPatch и MessagePatch добавлены поля, позволяющие узнать, были ли конкретный документ или сообщение восстановлены.
  • Появилась возможность по документу (Document <Document>) или сообщению (Message <Message>) понять, является ли он юридически значимым. Для этих целей в каждую из названных структур добавлено поле IsTest.
  • Добавилась возможность проводить эвристический семантический разбор строк, представляющих почтовый адрес в Российской Федерации. За это отвечает метод ParseRussianAddress.
  • Добавилась возможность выполнять трансформацию XML-файла СФ/ИСФ, сформированного в соответствии с XML-схемой, в структуру InvoiceInfo. За это отвечает метод ParseInvoiceXml.

v1.4 - 29.08.2012

  • В структуру данных Organization добавилось поле Departments, содержащее список всех подразделений в организации. Это поле позволяет получать информацию об оргструктуре при помощи методов GetMyOrganizations, GetOrganization, GetCounteragents, GetCounteragent.
  • В методах PostMessage и PostDraft появилась возможность отправлять документы в конкретное подразделение контрагента. Для этого в структуру данных MessageToPost добавилось новое поле ToDepartmentId, а в метод PostDraft был добавлен новый параметр toDepartmentId.
  • Появился новый метод MoveDocuments для перемещения документов своей организации между подразделениями. Информация о перемещениях документов между подразделениями (неважно было это сделано через API или через Web) доступна через метод GetNewEvents, в структуре данных EntityPatch добавилось поле MovedToDepartmentId.
  • В структуру данных Entity добавилось поле RawCreationDate, содержащее метку времени создания сущности. Это поле заполняется для всех сущностей, его можно использовать для получения времени подписания или согласования документа.
  • Появилась возможность осуществлять согласование (или отказ в согласовании) документов через API. Для этого добавилась структура данных Resolution, а в структуре данных MessagePatchToPost добавилось поле Resolutions.

Все действия по согласованию видны в структуре данных Message как сущности с типом Attachment/Resolution.

Содержимое этой сущности - байты строки комментария к согласованию в кодировке UTF-8. В структуру данных Entity добавилось поле ResolutionInfo, содержащее тип действия по согласованию и ФИО согласователя в виде новой структуры данных ResolutionInfo.

v1.3 - 26.06.2012

  • Был добавлен метод Delete, позволяющий помечать документы как удаленные. Также в структурах данных Document и Message появились соответствующие флаги IsDeleted.

Кроме того, в структуру данных MessagePatch был добавлен флаг MessageIsDeleted и поле EntityPatches, содержащее список структур данных типа EntityPatch с флагом DocumentIsDeleted. Данные расширения структуры данных MessagePatch позволяют отслеживать моменты удаления документов и/или сообщений, анализируя поток событий в ящике, возвращаемый методом GetNewEvents.

  • Был добавлен метод CanSendInvoice, позволяющий для данного идентификатора ящика и сертификата ЭП узнать, был ли этот сертификат зарегистрирован в ФНС в качестве сертификата, используемого для подписания электронных счетов-фактур, отправляемых участником ЭДО, которому принадлежит данный ящик в Диадоке. Проще говоря, метод CanSendInvoice отвечает на вопрос, может ли тот или иной сертификат ЭП использоваться для подписания ЭСФ, отправляемых из данного ящика. Также в структуру данных Organization было добавлено поле FnsRegistrationDate - дата подачи заявления в ФНС на регистрацию данной организации в качестве участника документооборота ЭСФ.
  • Метод PostDraft теперь позволяет загружать в черновики товарные накладные и акты о выполнении работ / оказании услуг в рекомендованном ФНС XML-формате (документы с типами Attachment/XmlTorg12 и Attachment/XmlAcceptanceCertificate). Также в метод PostDraft была добавлена поддержка счетов на оплату (документов типа Attachment/ProformaInvoice).

v1.2 - 09.06.2012

  • Был расширен перечень сведений, возвращаемых методами, дающими доступ к справочнику организаций в Диадоке (например, GetMyOrganizations). Теперь структура данных Organization включает поля Ogrn (ОГРН организации), Address (юридический адрес организации) и FnsParticipantId (уникальный идентификатор участника документооборота СФ, который должен указываться при формировании XML счетов-фактур).
  • Метод GenerateInvoiceXml теперь позволяет формировать не только XML-файлы счетов-фактур, но и XML-файлы исправлений счетов-фактур, корректировочных счетов-фактур, а также исправлений корректировочных счетов-фактур.

v1.1 - 11.05.2012

  • Появилась поддержка рекомендованных ФНС России форматов электронных товарных накладных и актов о выполнении работ / оказании услуг. Теперь при помощи метода PostMessage можно загружать в Диадок титулы продавца XML-накладных (новый тип документов Attachment/XmlTorg12) и титулы исполнителя XML-актов (новый тип документов Attachment/XmlAcceptanceCertificate), а при помощи метода PostMessagePatch можно загружать в Диадок соответствующие титулы покупателя/заказчика. В Diadoc SDK включены XML-схемы, описывающие рекомендованные ФНС России форматы товарных накладных и актов о выполнении работ / оказании услуг:

Также появились методы GenerateTorg12XmlForSeller, GenerateTorg12XmlForBuyer и GenerateAcceptanceCertificateXmlForSeller и GenerateAcceptanceCertificateXmlForBuyer, облегчающие процесс формирования корректных XML-файлов товарных накладных и актов. Поддержка новых типов документов была добавлена и в метод GetDocuments.

  • Появилась возможность при помощи метода PostMessage загружать в Диадок счета на оплату (новый тип документов Attachment/ProformaInvoice). Поддержка данного типа документов была добавлена и в метод GetDocuments.
  • Также в метод PostMessage была добавлена возможность загружать в Диадок вложения специального типа «структурированные данные» (Attachment/StructuredData <proto/Entity message>), при помощи которого можно организовать передачу рядом с юридически-значимой печатной формой документа каких-то данных, подлежащих автоматизированной обработке.
  • Метод GetDocuments теперь позволяет получать информацию обо всех СФ-подобных документах (СФ/ИСФ/КСФ/ИКСФ) единым списком. Для этого в качестве первой части параметра filterCategory нужно передать специальное значение «AnyInvoiceDocumentType». Например, чтобы получить список всех входящих СФ/ИСФ/КСФ/ИКСФ, нужно в метод GetDocuments передать параметр filterCategory=AnyInvoiceDocumentType.Inbound.

v1.0 - 04.04.2012

  • Появилась поддержка официально утвержденных версий форматов документов, фигурирующих в документообороте счетов-фактур. В связи с этим поменялись сигнатуры методов GenerateInvoiceDocumentReceiptXml и GenerateInvoiceCorrectionRequestXml. В Diadoc SDK включены соответствующие XML-схемы, описывающие форматы документов, фигурирующих в документообороте счетов-фактур:

В целях обеспечения обратной совместимости с существующими пилотными проектами по итеграции Диадок в течение еще какого-то времени будет продолжать принимать счета-фактуры в старом формате. Однако нужно иметь в виду, что такие документы не будут иметь юридической значимости.

  • Появился метод GenerateInvoiceXml, облегчающий процесс формирования корректного XML-файла счета-фактуры.

Данный метод позволяет интегратору не погружаться в детали XML-формата СФ, а передавать в Диадок только необходимые первичные данные в виде структуры InvoiceInfo. По этим данным метод GenerateInvoiceXml, при необходимости дополнив их сведениями из своих справочников, сформирует корректный XML-файл счета-фактуры, который затем можно будет отправить методом PostMessage, либо загрузить в черновики методом PostDraft. В частности, в структуре InvoiceInfo можно вообще не заполнять реквизиты продавца и покупателя, достаточно указать идентификаторы их ящиков в Диадоке, и тогда соответствующие реквизиты будут подтянуты из справочника организаций Диадока.

  • В Диадоке появилась возможность работать с исправлениями счетов-фактур и корректировочными счетами-фактурами. Для этого были введены новые типы сущностей: Attachment/InvoiceRevision (исправление счета-фактуры), Attachment/InvoiceCorrection (корректировочный счет-фактура), Attachment/InvoiceCorrectionRevision (исправление корректировочного счета-фактуры). Для связывания исправлений и корректировок с оригинальными СФ нужно использовать уже имеющийся в Диадоке механизм установки ссылок между документами, находящимися в разных сообщениях. Кроме того, в структуре Document.InvoiceMetadata, описывающей метаданные счета-фактуры в Диадоке, появилось поле InvoiceAmendmentFlags, которое отражает статус счета-фактуры с точки зрения наличия уведомления об уточнении или отправленного исправления / корректировки. Например, при отправке корректировочного СФ, у исходного счета-фактуры, по которому было запрошено уточнение, поле Document.InvoiceMetadata.InvoiceAmendmentFlags поменяет свое значение с AmendmentRequested на AmendmentRequested|Corrected.

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

  • Появилась возможность при помощи методов PostMessage и PostDraft загружать в Диадок акты о выполнении работ / оказании услуг (новый тип документов Attachment/AcceptanceCertificate). Поддержка нового типа документов была добавлена и в метод GetDocuments.

  • Метод GetDocuments научился фильтровать список документов по дате формирования документа в учетной системе (реквизиту самого документа), а не только по дате загрузки документа в Диадок. Для этого в метод GetDocuments добавлены необязательные параметры строки запроса fromDocumentDate и toDocumentDate, которые позволяют задать интервал времени, в котором осуществляется поиск. При этом метод GetDocuments продолжает поддерживать фильтрацию списка документов при помощи параметров timestampFromTicks и timestampToTicks.

  • Было расширено API для работы с черновиками:

    • Метод GetNewEvents теперь возвращает информацию о событиях, происходящик с черновиками: создание черновика (и начальный набор документов в нем), добавление к черновику документов, утилизация черновика (просто удаление, либо отправка на основе него полноценного сообщения). Методы GetEvent и GetMessage также теперь возвращают информацию о черновиках.
  • Появился метод RecycleDraft, который позволяет удалять еще не отправленные черновики.
  • У сообщения Message появилось необязательное поле CreatedFromDraftId, в которое заносится идентификатор черновика, на основании которого было создано данное сообщение (или черновик). Также и у черновика появилось симметричное поле DraftIsTransformedToMessageId, куда заносится идентификатор сообщения (или черновика), которое было создано из данного черновика. Флаг Message.DraftIsRecycled означает, что черновик был утилизирован, то есть просто удален, либо преобразован в полноценное сообщение или в другой черновик. Соответственно, поля DraftIsTransformedToMessageId и DraftIsRecycled могут присутствовать в структуре Message, описывающей черновик, одновременно.
  • Метод PostDraft стал позволять создавать нередактируемые черновики, то есть такие черновики, которые можно только отправить, или удалить. Добавление или удаление документов из таких черновиком заблокировано как в веб-интерфейсе Диадока, так и в API-методе PostDraft. Для создания нередактируемого черновика нужно в метод PostDraft передать параметр lock без значения.

v0.9 - 18.01.2012

  • Появились методы для управления списком своих контрагентов. Метод GetCounteragents позволяет получить список контрагентов, отфильтрованный по их статусу. Метод GetCounteragent позволяет получить информацию о контрагенте по его идентификатору. Метод AcquireCounteragent позволяет добавить организацию в список своих контрагентов. Метод BreakWithCounteragent позволяет исключить организацию из списка своих контрагентов.
  • Был переработан механизм получения справочной информации об организациях и ящиках в Диадоке. Методы GetBoxInfo и GetBoxesByInnKpp, а также метод GetBoxesByAuthToken объявлены устаревшими и не рекомендуются к использованию. Через некоторое время их поддержка будет прекращена. Вместо метода GetBoxesByAuthToken теперь нужно использовать метод GetMyOrganizations, позволяющий получить информацию обо всех организациях и ящиках, к которым имеет доступ владелец текущего авторизационного токена. Вместо метода GetBoxesByInnKpp теперь нужно использовать метод GetOrganizationsByInnKpp, позволяющий получить информацию о ящиках в Диадоке по ИНН и КПП организации. Наконец, на смену методу GetBoxInfo пришли методы GetOrganization и GetBox, позволяющие получить информацию соответственно о конкретных организации и ящике по их идентификаторам.

v0.8 - 16.12.2011

  • Появился метод GetDocuments, позволяющий быстро получать информацию о документах (например, о счетах-фактурах) в своем ящике, задавая различные критерии фильтрации документов. Также появился метод GetDocument, позволяющий получить всю метаинформацию об отдельном документе, зная его идентификатор.
  • Появилась возможность при помощи методов PostMessage и PostDraft загружать в Диадок новые типы докуметов, в частности, товарные накладные (ТОРГ-12) и запросы на инициацию канала обмена документами через Диадок TrustConnectionRequest.
  • Структура данных Entity расширена полем DocumentInfo. Для сущности типа Attachment это поле содержит дополнительную информацию о документе, представляемом этой сущностью.

v0.7 - 03.10.2011

  • Появились методы Recognize и GetRecognized, позволяющие использовать Диадок для распознавания печатных форм счетов-фактур. Печатная форма подается на вход метода Recognize в формате XPS.

    В случае успешного распознавания на выходе метода GetRecognized получается XML-файл счета-фактуры в формате, удовлетворяющем требованиям ФНС и пригодном для отправки в соответствии с порядком, утвержденным Минфином РФ.

v0.6 - 26.08.2011

  • В патчи с уведомлениями о невозможности доставки (DFN), возникающими по причине невалидности подписей под передаваемыми документами, теперь добавляются так называемые протоколы проверки подписей в виде отдельных сущностей для каждой подписи. Эти сущности-протоколы имеют тип Attachment/SignatureVerificationReport и привязываться к «своим» подписям при помощи поля Entity.ParentEntityId. Протоколы проверки формируются для всех подписей (как валидных, так и невалидных), поэтому чтобы понять, какие именно подписи были признаны недействительными, нужно анализировать содержимое соответствующих протоколов. Содержимое сущности-протокола (массив байтов Entity.Content.Data) представляет собой сериализованную в протобуфер структуру SignatureVerificationResult.

v0.5 - 15.08.2011

  • Появилась возможность запрашивать формирование ЭП под пересылаемыми данными «по доверенности». В этом случае изготавливать ЭП на клиенте не нужно (и значит, можно не устанавливать на рабочее место криптопровайдер), вместо этого формирование необходимой подписи будет произведено на сервере в момент доставки отправленного сообщения.

Изменения отразились в структурах данных MessageToPost и MessagePatchToPost.

v0.4 - 08.07.2011

Появилась возможность формирования печатных форм различных документов (в частности, счетов фактур) при помощи метода GeneratePrintForm.

v0.3 - 17.06.2011

  • Появилась возможность связывать документы в разных сообщениях. Для организации такой связи вводится структура данных DocumentId, которую можно заполнить, например, в структуре XmlDocumentAttachment при отправке корректировочного счета-фактуры.

    DocumentId включает в себя два идентификатора: поле DocumentId.MessageId - это идентификатор сообщения, содержащего исходный документ; поле DocumentId.EntityId - это идентификатор сущности, представляющей исходный документ в этом сообщении.

  • Появилась возможность отправить через API отказ от запрошенной подписи. Для этого в структуре MessagePatchToPost появилось необязательное поле RequestedSignatureRejections.

  • Появилась возможность отслеживания отдельных документов при отправке их через черновики. Для этого метод PostDraft начал возвращать вместе с идентификатором черновика еще и идентификатор сущности, в которую превращается загруженный документ.

  • Уведомления о невозможности доставки теперь ссылаются на недоставленные куски сообщения.

    • Для этого в структуре Entity появилось необязательное поле NotDeliveredEventId. NotDeliveredEventId - это идентификатор сообщения или патча, который не удалось доставить (например, из-за некорректности одной или нескольких подписей в нем).
    • Получить недоставленный кусок сообщения можно при помощи метода GetEvent, передав ему в качестве параметра eventId значение NotDeliveredEventId. Данное поле заполняется только у сущности типа Attachment с типом вложения DeliveryFailureNotification.

v0.2.2 - 15.04.2011

Справочные методы GetBoxInfo, GetBoxesByAuthToken и GetBoxesByInnKpp научились отдавать данные в формате XML.

v0.2.1 - 07.04.2011

Появилась возможность создавать черновики при помощи метода PostDraft.

v0.2 - 30.03.2011

Появилась возможность вести документооборот по счетам-фактурам в соответствии с порядком Минфина.

v0.1.1 - 18.02.2011

  • Появились методы для получения справочной информации GetBoxInfo и GetBoxesByInnKpp.
  • Появился метод для получения контента вложений по отдельности — GetEntityContent.
  • Метод GetMessage перестал отдавать весь тяжелый контент скопом (свыше 1Мб). Нужно учиться использовать метод GetEntityContent.

v0.1 - 09.12.2010

Первоначальный релиз интеграторского интерфейса.