ЭД2 Инвойс: различия между версиями

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

Версия 08:57, 21 января 2013

Назначение

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


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

Отдельного пояснения требует специфика заполнения данных о дополнительных расходах. Фактурная стоимость у каждого товара должна вводится УЖЕ с учетом доп.расходом и скидки. Суммы и расходов, и скидки вводятся положительными числами. Цена товара\услуги рассчитывается автоматически путем деления на количество фактурной стоимости, из которой вычтены дох.расходы и прибавлена скидка.

Т.е. фактурная стоимость это "грязная" ("брутто"-стоимость), а Цена товара\услуги - это "чистая" цена.

Edinvcalc.png


То что именно такой принцип заполнения является верным, подтверждает XSLT преобразование при помощи которого в АИСТ происходит отображение инвойса. Например, если пытаться заполнить фактурную стоимость без учета скидок, то цифра в скобках в столбике "Общая стоимость" отображается неверно. Увидеть такой отчет можно сохранив документ в XML и на предложение просмотреть ответить "Как в Таможне".

Edinvaist.png

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


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

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

Ediround.png

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

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

  1. Объяснить ситуация с округлением инспектору и указывать ПРАВИЛЬНУЮ (из реального физического инвойса) стоимость и округленную цену. Для этого в Инвойсе придется выключить автоматический пересчет. Вшитая в XSLT формула будет считать в скобках ФИКТИВНУЮ стоимость по округленной цене, и она не будет совпадать с ПРАВИЛЬНОЙ.
  1. указывать ФИКТИВНУЮ стоимость в поле стоимость и округленную же цену. Тогда при HTML отображении стоимость товара и стоимость в скобках будут формально совпадать. НО тогда сумма всего инвойса тоже станет ФИКТИВНОЙ и не будет совпадать со суммой в ГТД. Отображаться инвойс будет красиво, но по "ИТОГО" не соответствовать действительности. Инспектору придется объяснить, что это связано с ситуаций с округлением в формате.
  1. указывать везде фиктивную стоимость, но в шапке инвойса заполнить "ИТОГО" настоящей суммой из бумажного инвойса. Для этого так же придется выключить автоматичский пересчет инвойса. Шапка инвойса будет совпадать с ГТД, а стоимость и стоимость в скобках будут совпадать. НО если просуммировать фиктивные стоимости товаров, то они не совпадут с шапкой. При однотоварном Инвойсе это будет особенно очевидно.
  1. не заполнять поле ЦЕНА вообще, заполнить только стоимость реальными данными. Поле цена является обязательным, но можно попробовать поставить туда любой символ, например, пробел или 0 (при отключенном автоматическом пересчете). Документ пройдет форматный контроль, стоимости будут настоящие. Сумма товаров будет совпадать с шапкой, а та в свою очередь с гр.42 ГТД. При отображении инвойса в HTML, формула в скобках не сможет умножить пробел на количество и напишет NaN.

Данный метод не возможен, т.к. инвойс с пустой ценой не проходит форматный контроль.

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