ЭД2 Инвойс: различия между версиями
Belousov (обсуждение | вклад) |
Belousov (обсуждение | вклад) м (→Проблема округления цены) |
||
Строка 36: | Строка 36: | ||
== Проблема округления цены == | == Проблема округления цены == | ||
− | Альбомный формат требует для полей стоимость и цена указания с точностью до копеек. | + | Альбомный формат требует для полей ''стоимость'' и ''цена'' указания с точностью до копеек (2 знака) и сотых копеек (4 знака после запято). |
− | В случае если в реальном коммерческим инвойсе была использована цена с | + | В случае, если в реальном коммерческим инвойсе была использована цена с десятитысячными и более долями, то возникает коллизия: |
− | + | ввести цену можно только округленную, а в АИСТе (в XSLT отображении "как в таможне") ''стоимость без учета скидок'' считается "вшитой" формулой как раз с введенной цены. Но при получается, что стоимость из бумажного инвойса (посчитанная с настоящей не округленной цены), естественно, не будет совпадает с расчетной в скобках в АИСТе (посчитанной с округленной цены). | |
− | Но при | + | Некоторые инспектора начинают браковать заполненные таким образом инвойсы. |
[[Файл:ediround.png]] | [[Файл:ediround.png]] | ||
− | Универсального решения проблемы не существует. | + | Универсального решения проблемы не существует, т.к. вызвана она ограничением альбомного таможенного формата: с одной стороны альбом не дает ввести данные цены "как на бумаге", с другой стороны инспектор требует получить в скобках стоимость идентичную физическому инвойсу. |
− | + | Варианты решения следующие: можно | |
− | |||
− | |||
− | |||
− | + | # Объяснить ситуация с округлением инспектору и указывать ПРАВИЛЬНУЮ (из реального физического инвойса) стоимость и округленную цену. Для этого в Инвойсе придется выключить автоматический пересчет. Вшитая в XSLT формула будет считать в скобках ФИКТИВНУЮ стоимость по округленной цене, и она не будет совпадать с ПРАВИЛЬНОЙ. | |
+ | |||
+ | # указывать ФИКТИВНУЮ стоимость в поле стоимость и округленную же цену. Тогда при HTML отображении стоимость товара и стоимость в скобках будут формально совпадать. НО тогда сумма всего инвойса тоже станет ФИКТИВНОЙ и не будет совпадать со суммой в ГТД. Отображаться инвойс будет красиво, но по "ИТОГО" не соответствовать действительности. Инспектору придется объяснить, что это связано с ситуаций с округлением в формате. | ||
+ | |||
+ | # указывать везде фиктивную стоимость, но в шапке инвойса заполнить "ИТОГО" настоящей суммой из бумажного инвойса. Для этого так же придется выключить автоматичский пересчет инвойса. Шапка инвойса будет совпадать с ГТД, а стоимость и стоимость в скобках будут совпадать. НО если просуммировать фиктивные стоимости товаров, то они не совпадут с шапкой. При однотоварном Инвойсе это будет особенно очевидно. | ||
+ | |||
+ | # <strike>не заполнять поле ЦЕНА вообще, заполнить только стоимость реальными данными. Поле цена является обязательным, но можно попробовать поставить туда любой символ, например, пробел или 0 (при отключенном автоматическом пересчете). Документ пройдет форматный контроль, стоимости будут настоящие. Сумма товаров будет совпадать с шапкой, а та в свою очередь с гр.42 ГТД. При отображении инвойса в HTML, формула в скобках не сможет умножить пробел на количество и напишет '''NaN'''.</strike> | ||
+ | Данный метод не возможен, т.к. инвойс с пустой ценой не проходит форматный контроль. | ||
+ | |||
+ | Как мы видим, любое из этих решений не является полноценным и требует предварительного согласования таможней. | ||
[[Категория:Альта-ГТД]] | [[Категория:Альта-ГТД]] |
Версия 08:57, 21 января 2013
Назначение
ЭД2 документ для формализации данных из коммерческих инвойсов. Не следует путать с приложением Инвойс.
Особенности заполнения стоимости и расходов
Отдельного пояснения требует специфика заполнения данных о дополнительных расходах. Фактурная стоимость у каждого товара должна вводится УЖЕ с учетом доп.расходом и скидки. Суммы и расходов, и скидки вводятся положительными числами. Цена товара\услуги рассчитывается автоматически путем деления на количество фактурной стоимости, из которой вычтены дох.расходы и прибавлена скидка.
Т.е. фактурная стоимость это "грязная" ("брутто"-стоимость), а Цена товара\услуги - это "чистая" цена.
То что именно такой принцип заполнения является верным, подтверждает XSLT преобразование
при помощи которого в АИСТ происходит отображение инвойса. Например, если пытаться
заполнить фактурную стоимость без учета скидок, то цифра в скобках в столбике "Общая стоимость"
отображается неверно. Увидеть такой отчет можно сохранив документ в XML и на предложение просмотреть
ответить "Как в Таможне".
Следующая особенность, то что в шапке документа имеется 3 поля под суммарные "доп.рассходы" (транспорт, страхование и прочее). А расходы к каждому товару вводятся в специальное дополнение, каждая запись которого состоит из названия и суммы. Чтобы программа автоматически могла подсчитать шапку, она должна понимать к какому типу из 3х относится та или иная запись у каждого товара. Сделать можно только анализируя текст названия доп.расхода. Таким образом есть в названии доп. расхода присутствует "трансп" или "дост", то это считается транспортный расход. Если "страх" - то страхование. Все остальные суммируются в прочее.
Проблема округления цены
Альбомный формат требует для полей стоимость и цена указания с точностью до копеек (2 знака) и сотых копеек (4 знака после запято). В случае, если в реальном коммерческим инвойсе была использована цена с десятитысячными и более долями, то возникает коллизия: ввести цену можно только округленную, а в АИСТе (в XSLT отображении "как в таможне") стоимость без учета скидок считается "вшитой" формулой как раз с введенной цены. Но при получается, что стоимость из бумажного инвойса (посчитанная с настоящей не округленной цены), естественно, не будет совпадает с расчетной в скобках в АИСТе (посчитанной с округленной цены). Некоторые инспектора начинают браковать заполненные таким образом инвойсы.
Универсального решения проблемы не существует, т.к. вызвана она ограничением альбомного таможенного формата: с одной стороны альбом не дает ввести данные цены "как на бумаге", с другой стороны инспектор требует получить в скобках стоимость идентичную физическому инвойсу.
Варианты решения следующие: можно
- Объяснить ситуация с округлением инспектору и указывать ПРАВИЛЬНУЮ (из реального физического инвойса) стоимость и округленную цену. Для этого в Инвойсе придется выключить автоматический пересчет. Вшитая в XSLT формула будет считать в скобках ФИКТИВНУЮ стоимость по округленной цене, и она не будет совпадать с ПРАВИЛЬНОЙ.
- указывать ФИКТИВНУЮ стоимость в поле стоимость и округленную же цену. Тогда при HTML отображении стоимость товара и стоимость в скобках будут формально совпадать. НО тогда сумма всего инвойса тоже станет ФИКТИВНОЙ и не будет совпадать со суммой в ГТД. Отображаться инвойс будет красиво, но по "ИТОГО" не соответствовать действительности. Инспектору придется объяснить, что это связано с ситуаций с округлением в формате.
- указывать везде фиктивную стоимость, но в шапке инвойса заполнить "ИТОГО" настоящей суммой из бумажного инвойса. Для этого так же придется выключить автоматичский пересчет инвойса. Шапка инвойса будет совпадать с ГТД, а стоимость и стоимость в скобках будут совпадать. НО если просуммировать фиктивные стоимости товаров, то они не совпадут с шапкой. При однотоварном Инвойсе это будет особенно очевидно.
не заполнять поле ЦЕНА вообще, заполнить только стоимость реальными данными. Поле цена является обязательным, но можно попробовать поставить туда любой символ, например, пробел или 0 (при отключенном автоматическом пересчете). Документ пройдет форматный контроль, стоимости будут настоящие. Сумма товаров будет совпадать с шапкой, а та в свою очередь с гр.42 ГТД. При отображении инвойса в HTML, формула в скобках не сможет умножить пробел на количество и напишет NaN.
Данный метод не возможен, т.к. инвойс с пустой ценой не проходит форматный контроль.
Как мы видим, любое из этих решений не является полноценным и требует предварительного согласования таможней.