ЕД2 Інвойс

Зміст

Призначення

ЕД2 документ для формалізації даних із комерційних інвойсів. Не слід плутати з програмою Інвойс.

Особливості заповнення вартості та витрат

Окремого пояснення вимагає специфіка заповнення даних про вартість та додаткові витрати у документі. В описі альбомних форматів XML немає чітких пояснень як правильно вносити інформацію про додаткові витрати. З аналізу XSD схеми документа, назв його полів та екрану XSLT форми, що застосовується для відображення документа в АРМ інспектора, можна сформулювати дві можливі схеми заповнення додаткових витрат.

Це вказівка ​​додаткових витрат у спеціальному доповненні для кожного товару або вказівка ​​лише сумарних значень додаткових витрат у заголовку документа.

Вказівка ​​величин додаткових витрат для кожної позиції ЕД2-Інвойсу

ПолеФактурна вартістьу кожного товару вводиться ВЖЕ з урахуванням додаткових витрат і знижки. Це опосередковано підтверджується тим, що ідентифікатор фактурної вартості в товарі називаєтьсяTotalCost, при цьому поле з ідентифікаторомTotalCostу заголовку документа описується як "Загальна вартість з урахуванням витрат та знижки". Логічно припустити, щоФактурна вартістьу розумінні инвойса вважається " брудною вартістю " , тобто. включає доп.витрати і знижку.

СумиДодаткових витраттаЗнижкивводяться у відповідні поля позитивними числами. ПолеЦіна товару\послугирозраховується автоматично шляхом поділу наКількістьзначення поляФактурна вартість', з якої віднято дох.витрати.

Тобто.фактурна вартістьце "брудна" вартість, аЦіна товару\послуги- це "чиста" ціна, що дорівнює "чистій" вартості поділеної накількість. Таким чиномвимальовується наступна схема заповнення:

інвойс

Формула працює автоматично у митній програмі і вплинути на її розрахунок неможливо. Декларант може лише правильно заповнювати поля, з яких обчислюється значення в дужках. Наприклад, якщо спробувати заповнитифактурну вартістьвеличиною без додаткових витрат ("чистою" вартістю), то цифра в дужках у стовпчикуЗагальна вартістьвідобразиться невірно.

Наступна особливість, що в шапці документа є 3 поля під сумарні "додаткові витрати" (транспорт, страхування та інше). А витрати до кожного товару вводяться у спеціальне доповнення, кожен запис якого складається з назви та суми. Щоб програма автоматично могла підрахувати шапку, вона повинна розуміти до якого типу з 3х належить той чи інший запис кожного товару. Зробити можна лише аналізуючи текст назви додаткової витрати. Таким чином є в назві дод. витрати є "трансп" або "дост", то це вважається транспортна витрата. Якщо " страх " - то страхування. Усі інші підсумовуються інші витрати.

Вказівка ​​сумарних додаткових витрат у заголовку ЭД2-Инвойса

У реальних же комерційних інвойсах часто немає розбиття додаткових витрат по товарах. Вони просто вказуються загальними сумами у заголовку документа. У цьому випадку можна вфактурна вартістьписати "чисту" вартість, а витрати вказувати сумами в заголовку Інвойсу. При такій схемі сумарне поле в заголовкуЗагальна вартість з урахуванням витрат(TotalCost) відрізняється від сумифактурних цінтоварів на величину додаткових витрат зазначених у заголовку.

Проблема заокруглення ціни

Альбомний формат вимагає для поліввартістьіцінавказівки з точністю до копійок (2 знаки) та сотих копійок (4 знаки)після ком). У разі, якщо в паперовому комерційному інвойсі була ціна з десятитисячними і більше частками, то виникає колізія: ввести можна тільки заокруглену ціну, а в АІСТі (в XSLT відображенні "як у митниці") вартість без урахування знижок вважається "вшитою" формулою із введеної ціни. Але при цьому виходить, що вартість з паперового інвойсу (порахована зі справжньої ціни), природно, не збігається з розрахунковою в дужках в АІСТі (порахованої з округленої ціни). Деякі інспектори починають бракувати заповнені в такий спосіб інвойси.

вартість

Універсального вирішення проблеми немає, т.к. викликана вона обмеженням самого альбомного митного формату: з одного боку, альбом не дає ввести дані ціни "як на папері", з іншого боку інспектор вимагає отримати в дужках вартість ідентичну паперовому інвойсу.

Варіанти рішення такі:

  • Пояснити всю ситуацію із округленням інспектору та вказувати ПРАВИЛЬНУ (із реального фізичного інвойсу)вартістьта округлену ціну. Для цього в Інвойсі доведеться вимкнути автоматичний перерахунок. Вшита в XSLT формула вважатиме у дужках ФІКТИВНУ вартість за округленою ціною, і вона не співпадатиме з ПРАВИЛЬНОЮ.
  • Вказувати ФІКТИВНУ вартість у полі вартість та округлену ціну. Тобто. не вимикати автоматичний перерахунок та вводити лише ціну. Тоді при HTML відображенні вартість товару та вартість у дужках формально збігатимуться. АЛЕ сума всього інвойсу теж стане ФІКТИВНОЮ і не співпадатиме із сумою в ВМД. Відображатися інвойс буде красиво, але в "РАЗОМ" не відповідати паперовій дійсності. Інспектору доведеться пояснити, що це пов'язано із ситуацією із округленням у форматі.
  • вказувати скрізь фіктивнувартість як у другому випадку, але в шапці інвойсу заповнити "РАЗОМ" вручну справжньою сумою з паперового інвойсу. Для цього знову ж таки доведеться вимкнути автоматичний перерахунок. "Разом" інвойсу співпадатиме з ВМД, а вартість у дужках співпадатиме з вартістю. Однак, якщо підсумувати фіктивні вартості товарів, то вони не співпадуть із шапкою. За однотоварного Інвойсу це буде особливо помітно.
  • не заповнювати поле ЦІНА взагалі, заповнити лише вартість реальними даними. Поле ціна є обов'язковим, але можна спробувати поставити туди будь-який символ, наприклад пробіл або 0 (при відключеному автоматичному перерахунку). Документ пройде форматний контроль, вартість буде справжньою. Сума товарів співпадатиме з шапкою, а та у свою чергу з гр.42 ВМД. При відображенні інвойсу в HTML формула в дужках не зможе помножити пробіл на кількість і напишеNaN. Цей спосіб вже неможливий, т.к. інвойс із порожньою ціною не проходить форматний контроль.

Як видно, будь-яке з цих рішень не є універсальним і вимагає попереднього узгодження митницею.