ЭД2 Инвойс

Назначение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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