код boxid контур диадок где найти

Как получить счет-фактуру¶

Рассмотрим последовательность действий к функциям интеграторского интерфейса Диадока, которые требуется совершить покупателю при получении счета-фактуры (СФ), корректировочного счета-фактуры (КСФ), исправления счета-фактуры (ИСФ).

Порядок согласно приказу N 14Н¶

Порядок документооборота со стороны Покупателя:

Более подробно о порядке обмена электронными счетами-фактурами между компаниями можно почитать в соответствующем разделе или на сайте

Поиск счета-фактуры¶

Сначала необходимо найти входящие счета-фактуры, которые требуется обработать, для этого нужно воспользоваться методом GetDocuments :

Пример запроса на получение счета-фактуры выглядит следующим образом:

В теле ответа вернется список документов в виде структуры DocumentList с вложенной структурой Document. Для каждого из этих документов запоминаем: MessageId, EntityId.

Получение счета-фактуры и подтверждения оператора¶

Пример структуры подтверждения оператора InvoiceConfirmation в теле ответа:

Формирование извещения о получении счета-фактуры¶

На полученный счет-фактуру Покупатель должен отправить в ответ подписанное извещение InvoiceReceipt о получении СФ.

Например HTTP-запрос для формирования извещение о получении счета-фактуры выглядит следующим образом:

Пример структуры в теле запроса, содержащей данные о подписанте генерируемого извещения Signer :

Отправка извещения о получении счета-фактуры¶

Для этого нужно подготовить структуру MessagePatchToPost следующим образом:

Пример структуры в теле запроса, содержащей данные о передаваемом извещении MessagePatchToPost :

Подтверждение оператора на извещение о получении счета-фактуры¶

После того, как покупатель сформировал и отправил извещение о получении СФ, оператор в ответ должен сформировать подтверждение оператора о дате получения извещения о получении СФ.

Счет-фактура перейдет в статус InboundFinished. Ответного действия покупателя на полученное подтверждение оператора не предусмотрено.

Запрос на исправление или корректировку по счету-фактуре¶

После того, как будет получен XML-файл, его нужно отправить с помощью метода PostMessagePatch

Для этого нужно подготовить структуру MessageToPost следующим образом:

Пример кода на C# для получения счета фактуры:

Пример кода на C# для отправки уведомления об уточнении счета-фактуры:

Порядок согласно приказу N 174Н (утратил силу с 01.07.2021)¶

Порядок документооборота со стороны Покупателя:

Поиск счета-фактуры¶

Действия аналогичны инструкции для обмена СФ по 14Н (см. Поиск счета-фактуры ).

Получение счета-фактуры и подтверждения оператора¶

Действия аналогичны инструкции для обмена СФ по 14Н (см. Получение счета-фактуры и подтверждения оператора ).

Формирование извещения о получении подтверждения оператора¶

После того, как покупатель получил подтверждение оператора, он должен отправить в ответ подписанное извещение InvoiceReceipt о получении подтверждения.

Последовательность действий для формирования извещения о получении подтверждения оператора аналогична последовательности действий для формирования извещения о получении СФ (см. Формирование извещения о получении счета-фактуры ).

За исключением того, что в attachmentId нужно указать идентификатор полученного подтверждения оператора.

Отправка извещения о получении подтверждения оператора¶

Полученное на предыдущем этапе извещение нужно подписать и отправить.

Последовательность действий для отправки сформированного извещения о получении подтверждения оператора аналогична последовательности действий для отправки сформированного извещения о получении СФ (см. Отправка извещения о получении счета-фактуры ).

За исключением того, что в поле ParentEntityId нужно указать идентификатор (EntityId) подтверждения оператора, полученного на предыдущем шаге.

Формирование извещения о получении счета-фактуры¶

Действия аналогичны инструкции для обмена СФ по 14Н (см. Формирование извещения о получении счета-фактуры ).

Отправка извещения о получении счета-фактуры¶

Полученное на предыдущем этапе извещение нужно подписать и отправить. Действия аналогичны инструкции для обмена СФ по 14Н (см. Отправка извещения о получении счета-фактуры ).

Подтверждение оператора о дате отправки извещения о получении счета-фактуры¶

После того, как покупатель сформировал и отправил извещение о дате получении СФ, оператор в ответ должен сформировать подтверждение оператора о дате отправки извещения о получении СФ.

Это подтверждение покупатель должен получить, затем сформировать извещение о получении подтверждения оператора, подписать его и отправить.

Формирование извещения о получении подтверждения оператора аналогично формированию извещения о получении СФ (см. Формирование извещения о получении счета-фактуры ). За исключением того, что в attachmentId нужно указать идентификатор полученного подтверждения оператора.

Подписание и отправка извещения о получении подтверждения оператора аналогичны действиям по подписанию и отправке извещения о получении СФ (см. Отправка извещения о получении счета-фактуры ). За исключением того, что в поле ParentEntityId нужно указать идентификатор (EntityId) подтверждения оператора.

После того, как покупатель сформировал все необходимые извещения, счет-фактура перейдет в статус InboundFinished

Запрос на исправление или корректировку по счету-фактуре¶

Действия аналогичны инструкции для обмена СФ по 14Н (см. Запрос на исправление или корректировку по счету-фактуре ).

Пример кода на C# для получения счета фактуры:

Пример кода на C# для отправки уведомления об уточнении счета-фактуры:

Источник

Доставка

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

Коннектор может работать с четырьмя типами источников файлов:

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

Чтобы отправить документы в одном письме нужно сгруппировать их любым из способов:

Ниже на схемах приведены примеры группировки файлов в письма при установке уровня вложенности «0» или «1».

Схема 1. Пример группировки файлов в письма с уровнем вложенности «0»

Схема 2. Пример группировки файлов в письма с уровнем вложенности «1»

Типы и форматы документов

Коннектор позволяет отправлять любые типы документов, которые поддерживает Диадок.

Основные типы документов:

Поддерживаемые форматы формализованных документов, которые закреплены законодательством: 820@, 736@, 551@, 552@.

Некоторые неформализованные документы требуют дополнительных данных, таких как: дата, номер, сумма. Их можно указать в имени исходного файла документа.

Если учетная система не может выгрузить счета-фактуры, накладные, акты или УПД в формате установленном ФНС или в формате, который необходим для отправки в электронном виде (произвольный PDF или XML), то можно воспользоваться функцией преобразования документов. Поддерживаемые форматы исходных файлов, для которых применима функция преобразования:

Возможен вариант сложного преобразования, когда из одного файла требуется сформировать несколько файлов.

Эти настройки выполняются в индивидуальном порядке через менеджера.

Загрузка документов в Диадок

Для отправки документа потребуется задать правила маршрутизации для определения:

Исходящие для последующей отправки и подписи

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

Получатель документа может быть определен по:

При маршрутизации по паре ИНН-КПП применяется следующий порядок поиска организации в Диадоке:

Поиск по КПП одновременно происходит как по реквизитам ящика организации, так и по реквизитам подразделений ящика организации.

Отправка документов в роумнговые ящики осуществляется в головное подразделение.

Исключение составляют документы с типом «Приглашение». Для них нет проверок на наличие получателя в списке контрагентов.

Более гибкие настройки по маршрутизации документов представляет «файл маршрутизации». Это текстовый файл, который содержит строки, состоящие из пары ключ–значение, разделенные пробелами. Кодировка файла: UTF-8 или UTF-8 (без BOM). Если указан ключ, то должно быть указано значение.

Файл маршрутизации определяется по имени, которое удовлетворяет заданному регулярному выражению (подробнее смотрите в разделе «Использование регулярных выражений» ). Файл маршрутизации не должен располагаться в корне рабочей папки. Его можно разместить в подпапке вместе с отправляемыми документами или на уровень выше.

Источник

OrganizationInfo¶

Структура данных OrganizationInfo служит для представления реквизитов организаций-контрагентов при формировании счетов-фактур (см. InvoiceInfo ), товарных накладных (см. Torg12SellerTitleInfo ) и актов о выполнении работ / оказании услуг (см. AcceptanceCertificateSellerTitleInfo ) в XML-формате.

В зависимости от контекста использования структуры OrganizationInfo требования к обязательности заполнения ее полей могут меняться. Однако в любом случае всегда требуется указывать название организации (OrganizationInfo.Name) и ее адрес ( OrganizationInfo.Address ).

Стоит отметить, что при формировании XML счетов-фактур (при заполнении структуры InvoiceInfo) используются только поля Name, Inn, Kpp, Address, IsSoleProprietor, FnsParticipantId.

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

В этом случае реквизиты организации (DiadocOrganizationInfo.OrgInfo) можно явно не заполнять, и тогда будут использоваться данные из БД учетных записей| Диадока, ассоциированные с соответствующим ящиком (DiadocOrganizationInfo.BoxId). В структуре DiadocOrganizationInfo должно быть заполнено хотя бы одно из полей BoxId, или OrgInfo. Если поле OrgInfo заполнено, то будут использоваться данные из него; обращений к справочнику организаций Диадока не будет.

Структура данных DocflowParticipant содержит данные, необходимые для идентификации участника электронного документооборота. Вне зависимости от контекста использования, одно из полей DocflowParticipant.BoxId или DocflowParticipant.Inn должно быть заполнено. Для определения идентификатора участника системе требуется его ИНН-КПП, который может быть определен на основе значения DocflowParticipant.BoxId, если поле DocflowParticipant.Inn не заполнено.

Источник

Идентификатор участника ЭДО

Что такое идентификатор

Идентификатор участника ЭДО состоит из комбинации цифр и латинских букв разного регистра.

Первые три символа в номере — это ID оператора электронного документооборота. Набор последующих знаков помогает распознавать пользователей ЭДО.

Как определить оператора ЭДО по идентификатору? Если вы хотите узнать, какой провайдер у контрагента, обратите внимание на первую часть идентификационного номера. Найдите на сайте ФНС России список доверенных операторов юридически значимого электронного документооборота. В списке приведены основные сведения об операторах, в том числе идентификаторы ОЭД. Зная идентификатор участника ЭДО, вы легко определите оператора по первым трем символам.

Так, ID участника ЭДО для клиентов оператора СКБ Контур будет начинаться с 2ВМ.

Зачем нужен идентификатор

Для обмена счетами-фактурами и другими формализованными документами организации необходимо получить идентификатор участника ЭДО. В xml-файлах электронных документов должны быть заполнены поля с номерами отправителя и получателя. Использование уникальных кодов дает возможность ФНС и операторам ЭДО определить организацию в своих системах.

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

Как получить идентификатор

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

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

Где посмотреть в Диадоке

Чтобы узнать идентификатор участника ЭДО в Контур.Диадоке, зайдите в веб-интерфейс сервиса. Откройте меню «Настройки». Вы сразу же увидите идентификатор участника ЭДО (GUID).

Если вы перейдете в раздел «Реквизиты организации», тоже сможете посмотреть идентификационный номер своей организации.

Как узнать идентификатор ЭДО контрагента

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

Подключиться к Диадоку, чтобы использовать все преимущества ЭДО

Источник

GetDocuments¶

Элементы в списке DocumentList.Documents идут в порядке возрастания меток времени (поля Document.TimestampTicks). В поле DocumentList.TotalCount указывается общее количество документов, удовлетворяющих запросу.

В массиве DocumentList.Documents содержится не более 1000 элементов; для получения остальных документов нужно вызывать метод GetDocuments с теми же параметрами, меняя значение afterIndexKey.

Первая часть этой строки задает тип документа и может следующие значения:

Возможные варианты ¶

Вариант	Описание	Примечание
Строковый идентификатор любого доступного в организации типа (см. поле TypeNamedId )	Например, Invoice, XmlAcceptanceCertificate, Nonformalized и т.п.
Any	Аггрегированный запрос для всех документов в ящике без учета по типу
AnyInvoiceDocumentType	Аггрегированный запрос только для типов Invoice, InvoiceRevision, InvoiceCorrection, InvoiceCorrectionRevision	более не поддерживается и не рекомендуется к использованию
AnyBilateralDocumentType	Аггрегированный запрос только для типов Nonformalized, Torg12, AcceptanceCertificate, XmlTorg12, XmlAcceptanceCertificate, TrustConnectionRequest, PriceList, PriceListAgreement, CertificateRegistry, ReconciliationAct, Contract, Torg13	более не поддерживается и не рекомендуется к использованию
AnyUnilateralDocumentType	Аггрегированный запрос только для типов ProformaInvoice, ServiceDetails	более не поддерживается и не рекомендуется к использованию

Строка DocumentClass задает класс документа и может принимать следующие значения:

Возможные варианты ¶

Вариант	Описание
Inbound	Только входящие
Outbound	Только исходящие
Internal	Только внутренние
Proxy	Только документы, переданные через промежуточного получателя

Строка DocumentStatus задает статус документа и может принимать следующие значения:

Возможные варианты ¶

Вариант	Описание
Пустое значение	Любой документ указанного класса Class
NotRead	Документ не прочитан
NoRecipientSignatureRequest	Документ без запроса ответной подписи
WaitingForRecipientSignature	Документ в ожидании ответной подписи
WithRecipientSignature	Документ с ответной подписью
WithSenderSignature	Документ с подписью отправителя
RecipientSignatureRequestRejected	Документ с отказом от формирования ответной подписи
WaitingForSenderSignature	Документ, требующий подписания и отправки
InvalidSenderSignature	Документ с невалидной подписью отправителя, требующий повторного подписания и отправки
InvalidRecipientSignature	Документ с невалидной подписью получателя, требующий повторного подписания и отправки
Approved	Согласованный документ
Disapproved	Документ с отказом согласования
WaitingForResolution	Документ, находящийся на согласовании или подписи
SignatureRequestRejected	Документ с отказом в запросе подписи сотруднику
Finished	Документ с завершенным документооборотом
HaveToCreateReceipt	Требуется подписать извещение о получении
NotFinished	Документ с незавершенным Документооборотом
InvoiceAmendmentRequested	Документ, по которому было запрошено уточнение
RevocationIsRequestedByMe	Документ, по которому было запрошено аннулирование
RequestsMyRevocation	Документ, по которому контрагент запросил аннулирование
RevocationAccepted	Аннулированный документ
RevocationRejected	Документ, запрос на аннулирование которого был отклонен
RevocationApproved	Документ, запрос на аннулирование которого был согласован
RevocationDisapproved	Документ с отказом согласования запроса на аннулирование
WaitingForRevocationApprovement	Документ, находящийся на согласовании запроса аннулирования
NotRevoked	Неаннулированный документ
WaitingForProxySignature	Документ в ожидании подписи промежуточного получателя
WithProxySignature	Документ с подписью промежуточного получателя
InvalidProxySignature	Документ с невалидной подписью промежуточного получателя, требующий повторного подписания и отправки
ProxySignatureRejected	Документ с отказом от формирования подписи промежуточным получателем
WaitingForInvoiceReceipt	Документ в ожидании получения извещения о получении счета-фактуры
WaitingForReceipt	Документ в ожидании получения извещения о получении
RequestsMySignature	Документ, по которому контрагент запросил подпись
RoamingNotificationError	Документ с ошибкой доставки в роуминге

Примеры строки filterCategory:

Необязательный параметр counteragentBoxId позволяет ограничить выдачу только теми документами, у которых идентификатор ящика контрагента совпадает с counteragentBoxId.

Необязательные параметры timestampFromTicks и timestampToTicks позволяют задать интервал времени, в котором осуществляется поиск.

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

Однако при этом фильтрация списка документов производится по дате формирования документа в учетной системе (реквизиту самого документа), а не по метке времени, связанной с загрузкой документа в ящик Диадока.

Если какой-то параметр отсутствует в запросе, то его значение неявно принимается равным +/- бесконечности. В выдачу метода GetDocuments попадают только те документы, у которых заполнен реквизит «Дата документа».

Параметры fromDocumentDate и toDocumentDate задаются в формате ДД.ММ.ГГГГ, то есть представляют собой только даты, а не полноценные метки времени.

Необязательный параметр afterIndexKey позволяет итерироваться по списку документов, удовлетворяющих фильтру.

Если в запросе присутствует параметр afterIndexKey, то список документов в выдаче начинается с документа, следующего за документом, имеющим ключ afterIndexKey (поле Document.IndexKey ).

Cам документ с ключом afterIndexKey в выдачу при этом не попадает. Если данный параметр в запросе отсутствует, то выдается начало списка документов, удовлетворяющих фильтру.

Источник