Skip to content

Latest commit

 

History

History
executable file
·
139 lines (73 loc) · 14.3 KB

InvoiceDocflow.rst

File metadata and controls

executable file
·
139 lines (73 loc) · 14.3 KB
Raw

Документооборот счетов-фактур

Обмен электронными счетами-фактурами в России регулируется Министерством финансов РФ и Федеральной налоговой службой.

Порядок документооборота, связанного с выставлением и получением счетов-фактур в электронном виде с ЭП, утвержден приказом Минфина от 10.11.2015 N 174Н.

Note

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

Форматы

Электронные счета-фактуры можно создавать:

Форматы служебных документов, используемых при выставлении и получении счетов-фактур в электронном виде, утверждены приказом ФНС России от 30.01.2012 N ММВ-7-6/36@.

В силу приказа N ММВ-7-15/155@ электронный счет-фактура может быть в следующем формате:

  • XSD-схема формата счета-фактуры (СФ) <../xsd/ON_SCHFDOPPR_1_995_01_05_01_05.xsd>; эта схема описывает формат СФ, исправления СФ (ИСФ);

В силу приказов N ММВ-7-15/189@ корректировочный счет-фактура может быть в следующих форматах:

  • XSD-схема формата корректировочного счета-фактуры (КСФ) <../xsd/ON_KORSCHFDOPPR_1_996_01_05_01_03.xsd>; эта схема описывает формат исправления КСФ (ИКСФ);

В обоих случаях, и для СФ и для КСФ, форматы электронных документов, возникающих в ходе реализации порядка обмена ЭСФ, описываются следующими XSD-схемами:

  • XSD-схема извещения о получении документа <../xsd/DP_IZVPOL_1_982_00_01_01_02.xsd>;
  • XSD-схема подтверждения оператора о дате отправки СФ/ИСФ/КСФ/ИКСФ <../xsd/DP_PDPOL_1_984_00_01_01_02.xsd> (выдается Продавцу);
  • XSD-схема подтверждения оператора о дате доставки СФ/ИСФ/КСФ/ИКСФ <../xsd/DP_PDOTPR_1_983_00_01_01_02.xsd> (выдается Покупателю);
  • XSD-схема уведомления об уточнении СФ/ИСФ/КСФ/ИКСФ <../xsd/DP_UVUTOCH_1_985_00_01_02_02.xsd> (формируется Покупателем).

Структуры

Для документов, возникающих в ходе документооборота счетов-фактур, в Диадоке зарезервированы специальные типы сущностей <../proto/Entity message>.

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

  • Attachment/Invoice,

Для исправления СФ (ИСФ) можно использовать следующую структуру:

  • Attachment/InvoiceRevision,

Для корректировки СФ (КСФ) можно использовать следующую структуру:

  • Attachment/InvoiceCorrection,

Для исправления корректировки СФ (ИКСФ) можно использовать следующую структуру:

  • Attachment/InvoiceCorrectionRevision,

Для служебных документов, возникающих в ходе реализации порядка обмена ЭСФ, можно использовать следующие структуры:

  • Attachment/InvoiceConfirmation (подтверждение оператора электронного документооборота, для обоих приказов),
  • Attachment/InvoiceCorrectionRequest (уведомление об уточнении СФ/ИСФ/КСФ/ИКСФ, для обоих приказов),
  • Attachment/InvoiceReceipt (извещение о получении СФ/ИСФ/КСФ/ИКСФ, подтверждения оператора электронного документооборота или уведомления об уточнении СФ/ИСФ/КСФ/ИКСФ, для обоих приказов).

Порядок обмена

Порядок обмена счетами-фактурами, разработанный Минфином, не ложится на концепцию неформализованного документооборота <NonformalizedDocflow>. Поэтому в Диадоке для поддержки этого порядка были разработаны специальные механизмы.

Счет-фактура и все множество служебных документов, предусмотренных порядком Минфина, помещаются в Диадоке в одно сообщение <../proto/Message> (в одну цепочку документооборота).

Добавление служебных документов к счету-фактуре по мере прохождения им различных этапов документооборота производится при помощи описанного механизма дополнений (см. описание модели данных <../DataModel>).

Передача исправлений СФ, а также корректировочных СФ и исправлений КСФ с точки зрения API Диадока производится точно также, как и передача СФ.

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

  1. Продавец формирует счет-фактуру Invoice1, подписывает его и направляет Покупателю.
  2. Диадок формирует подтверждение оператора InvoiceConfirmation2о дате получения счета-фактуры, подписывает его и направляет Продавцу.
  3. Диадок формирует подтверждение оператора InvoiceConfirmation2'о дате отправки счета-фактуры, подписывает его и направляет вместе со счетом фактурой Покупателю.
  4. Продавец получает подтверждение оператора и отправляет в ответ подписанное извещение InvoiceReceipt3о получении подтверждения.
  5. Покупатель получает счет-фактуру и подтверждение оператора и отправляет в ответ подписанные извещение InvoiceReceipt5о получении счета-фактуры и извещение InvoiceReceipt4о получении подтверждения.
  6. Диадок формирует подтверждение оператора InvoiceConfirmation6о дате отправки извещения о получении счета-фактуры, подписывает его и направляет Покупателю.
  7. Покупатель получает подтверждение оператора и отправляет в ответ подписанное извещение InvoiceReceipt7о получении подтверждения.
  8. Если Покупатель обнаружил ошибки в полученном счете-фактуре, он формирует уведомление об уточнении счета-фактуры InvoiceCorrectionRequest8, подписывает его и направляет Продавцу.
  9. Продавец получает уведомление об уточнении счета-фактуры, и отправляет в ответ подписанное извещение InvoiceReceipt9о получении уведомления.

image

На схеме, на зеленном фоне, изображены документы, которые формирует Продавец, на желтом фоне – документы, которые формирует Покупатель, на синем – документы, формируемые Диадоком, в качестве оператора электронного документооборота.

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

Например, у сущности InvoiceConfirmation2поле ParentEntityId будет указывать на сущность Invoice1.

Также у сущности InvoiceCorrectionRequest8поле ParentEntityId будет указывать на сущность Invoice1.

Если же мы рассмотрим сущность InvoiceConfirmation6, представляющую подтверждение оператора, отправленное в ответ на извещение о получении счета-фактуры Покупателем, то у нее поле ParentEntityId будет указывать на сущность InvoiceReceipt6, представляющую это извещение.

Чтобы пояснить сказанное, на схемах ниже изображены структуры Диадок-сообщений в ящиках Продавца и Покупателя, представляющих один и тот же полностью завершенный документооборот (со всеми возможными служебными документами):

image

image

Стрелками обозначаются связи типа ParentEntityId между сущностями. Сущности типа Signature, представляющие ЭП под документами (в соответствии с порядком Минфина все документы возникающие в ходе документооборота счетов-фактур должны сопровождаться ЭП), на схемах не изображены.

Для облегчения процесса формирования корректного XML-файла счета-фактуры Диадок предоставляет API метод ../http/utd/GenerateUniversalTransferDocumentXmlForSeller.

Данный метод позволяет интегратору не погружаться в детали XML-формата СФ, а передавать в Диадок только необходимые первичные данные в виде структуры ../proto/utd/UniversalTransferDocumentSellerTitleInfo.

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

Как видно из представленных выше схем, порядок Минфина помимо построения в специальном XML-формате собственно счета-фактуры требует от Продавца и Покупателя умения формировать ряд служебных документов, XML-формат которых также строго определен.

Диадок облегчает работу интеграторов в части формирования таких служебных документов, предоставляя методы API ../http/GenerateInvoiceDocumentReceiptXml и ../http/GenerateInvoiceCorrectionRequestXml, которые скрывают знание о деталях XML-форматов этих документов.

Кроме того, для удобства работы с документами (в частности, со счетами-фактурами) в Диадоке реализован метод ../http/GetDocuments, позволяющий быстро получать списки документов, удовлетворяющих различным условиям отбора.