ЭД2 Инвойс

Назначение

ЭД2 документ для формализации данных из коммерческих инвойсов. Не следует путать с приложением Инвойс.

Особенности заполнения стоимости и расходов

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

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

Указание величин доп.расходов для каждой позиции ЭД2-Инвойса

Поле Фактурная стоимость у каждого товара вводится УЖЕ с учетом доп.расходов и скидки. Это опосредованно подтверждается тем, что идентификатор фактурной стоимости в товаре называется TotalCost, при этом поле с идентификатором TotalCost в заголовке документа описывается как "Общая стоимость с учетом расходов и скидки". Логично предположить, что Фактурная стоимость в понимании инвойса считается "грязной стоимостью", т.е. включающей в себя доп.расходы и скидку.

Суммы Дополнительных расходов и Скидки вводятся в соответствующие поля положительными числами. Поле Цена товара\услуги рассчитывается автоматически путем деления на Количество значения поля Фактурная стоимость', из которой вычтены дох.расходы.

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

То, что именно такой принцип заполнения является верным, косвенно подтверждает формула в таможенном XSLT шаблоне. Эта формула при отображении Инвойса в АРМ инспектора рассчитывает число в скобках. Увидеть такой отчет можно выгрузив ЭД2-инвойс в XML формат и на предложение просмотреть выбрать пункт "Как в Таможне".

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

Следующая особенность, то что в шапке документа имеется 3 поля под суммарные "доп.расходы" (транспорт, страхование и прочее). А расходы к каждому товару вводятся в специальное дополнение, каждая запись которого состоит из названия и суммы. Чтобы программа автоматически могла подсчитать шапку, она должна понимать к какому типу из 3х относится та или иная запись у каждого товара. Сделать можно только анализируя текст названия доп.расхода. Таким образом есть в названии доп. расхода присутствует "трансп" или "дост", то это считается транспортный расход. Если "страх" - то страхование. Все остальные суммируются в прочие расходы.

Указание суммарных доп.расходов в заголовке ЭД2-Инвойса

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

При просмотре такого ЭД2-Инвойса в виде "HTML как в таможне" также получается приемлемый вариант.

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

Альбомный формат требует для полей стоимость и цена указания с точностью до копеек (2 знака) и сотых копеек (4 знака после запято). В случае, если в бумажном коммерческим инвойсе была цена с десятитысячными и более долями, то возникает коллизия: ввести можно только округленную цену, а в АИСТе (в XSLT отображении "как в таможне") стоимость без учета скидок считается "вшитой" формулой с введенной цены. Но при этом получается, что стоимость из бумажного инвойса (посчитанная с настоящей цены), естественно, не будет совпадает с расчетной в скобках в АИСТе (посчитанной с округленной цены). Некоторые инспектора начинают браковать заполненные таким образом инвойсы.

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

Варианты решения следующие:

• Объяснить всю ситуация с округлением инспектору и указывать ПРАВИЛЬНУЮ (из реального физического инвойса) стоимость и округленную цену. Для этого в Инвойсе придется выключить автоматический пересчет. Вшитая в XSLT формула будет считать в скобках ФИКТИВНУЮ стоимость по округленной цене, и она не будет совпадать с ПРАВИЛЬНОЙ.

• Указывать ФИКТИВНУЮ стоимость в поле стоимость и округленную же цену. Т.е. не отключать автоматический пересчет и вводить только цену. Тогда при HTML отображении стоимость товара и стоимость в скобках будут формально совпадать. НО сумма всего инвойса тоже станет ФИКТИВНОЙ и не будет совпадать с суммой в ГТД. Отображаться инвойс будет красиво, но в "ИТОГО" не соответствовать бумажной действительности. Инспектору придется объяснить, что это связано с ситуаций с округлением в формате.

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

• не заполнять поле ЦЕНА вообще, заполнить только стоимость реальными данными. Поле цена является обязательным, но можно попробовать поставить туда любой символ, например, пробел или 0 (при отключенном автоматическом пересчете). Документ пройдет форматный контроль, стоимости будут настоящие. Сумма товаров будет совпадать с шапкой, а та в свою очередь с гр.42 ГТД. При отображении инвойса в HTML, формула в скобках не сможет умножить пробел на количество и напишет NaN. Данный метод уже невозможен, т.к. инвойс с пустой ценой не проходит форматный контроль.

Как видно, любое из этих решений не универсально и требует предварительного согласования таможней.