Сумма рублевого НДС при разноске валютного заказа

[wedmak_dk]

Добрый день.
Проблема такова: Сумма рублевого НДС при разноске валютного заказа в USD рассчитывается на основании суммы НДС в валюте, что при текущем курсе доллара дает разницу до 30 копеек.
Проблема уже обсуждалась в ветке
Сумма НДС в руб. при реализации в валюте рассчитывается на основе суммы НДС в валюте еще в 2005 году, и, как видимо, для Ax 3.0
Нет ли каких-нибудь решений этой проблемы в Ax 2009?

[Ivanhoe]

А вы таким образом (накладная в валюте) оформляете покупку в у.е.?

[wedmak_dk]

Нет, речь идет о заказе на продажу. Для иностранных клиентов тарифы определены в долларах. Соответственно, НДС выделяется тоже в долларах. А в фактуре сумма НДС считается переводом долларового НДС в рубли по курсу.
Например:
Цена номенклатуры - 40,25$ , в рублях по курсу - 2263,56 р.
Кол-во – 1
НДС – 7.25$, в рублях по курсу – 407.72 р.
2263,56 * 0,18 = 407,44 р.

[mikeSch]

Счет выставляется в валюте, (тарифы валютные) оплачивается в рублях по курсу.
Все остальные документы выставляются в рублях (Долларовый заказ разностся рублевой накладной.)

Т.е. для вышеуказанного примера

Сумма счета USD - 40.25+7.25(ндс) = 47.50$ или 47.50*56.2376(курс) = 2671,29

И все бы было замечательно если бы в рублевой фактуре не была строчка:
База НДС 2263.56 , НДС 407.72.
Бухгалтеров это категорически не устраевает, так как по закону я должен
взять 18% от базы (сумма * курс на день продажи ) они хотят видеть 407,44
но если я скорректирую таким образом НДС, изменится и рублевая сумма счета.

Следовательно я должен скорректировать и рублевую базу, что бы выйти на те же
итоги по счету:

БазаMST 2263.80 НДСMST 407.49(48) (2263.80 + 407.49 = 2671.29 )

Куда копать? что делать ? Ведь вроде бы типовая ситуация, особенно сейчас,
когда многие фирмы начинают формировать цены в УЕ.

[mikeSch]

..Далее... Но такая коррекция, по сути меняет долларовый тариф
2263,80/56,2376 = 40.25 на целых 25 центов !!! что же делать?

как же правильно выставить валютный счет?
по логике я должен определить базу в рублях по курсу и взять 18% - получить пресловутые 407,44 и перевести их в валюту 407,44/56,2376 = 7,24$
И в таком виде выставлять, что как мы видим не решает проблему.

7,24*56,2376 = 407,16 ...
Получается заколдованый круг, как бы я не выставлял валютный счет,
все равно не получится выполнить требование налогового законадательства...

[mikeSch]

Товарищи экспеты - помогите! По идее я могу (или не могу?) выставить фактуру в валюте.
Тогда все будет правильно - как в аксапте, размер рублевого ндса будет определяться как курс*(база$*0.18). А что собственно должно быть в рублевой фактурее, если тариф валютный и счет (с ндсом) выставленный клиенту валюный.?

[mnt_dx]

В долларах можно только, если расчеты в валюте с контрагентом, но всё равно в книгах покупок/продаж надо отражать в рублях
http://www.glavkniga.ru/situations/199993

[mikeSch]

Ну ладно, даже если все расчеты и документы должны быть рублевые, и только ТАРИФ в иностранной валюте, то заказ будет вылютный и НДС выделится валютный с точностью до цента. (следовательно +- 30 коп по отношению к правильному рублевому.) Или такую ситуацию можно как либо обыграть ? Можно ли создать заказ в котором тариф валютный а НДС рублевый ? Может быть можно как либо повысить точность Валютного НДС (до 4 знаков после запятой), или ввести какой - нибудь особый курс для НДС. Или как то поколдовать с корректировкой налога ? Или переделать заказ в рублевый, пересчитав тарифы из валюты в рубли ?

[ashu]

"Или как то поколдовать с корректировкой налога ?"
Собственно это первый вариант который приходит в голову, есть только маленький нюанс- что корректировка НДС система делает в целом по накладной, а не по строкам (если ничего не изменилось) но это лечится модификацией.

[d&m]

Цитата:

Сообщение от mikeSch

...Или переделать заказ в рублевый, пересчитав тарифы из валюты в рубли ?...

делали так на нескольких проектах, это решает в том числе проблему, когда по будущей отгрузке есть частичная предоплата и отгрузку нужно сделать по смешанному курсу (частично на дату предоплату, частично на дату отгрузки - соответственно при смене валюты заказа нужно переводить как раз по этому смешанному курсу). Однако будьте готовы, что это не последняя проблема с НДС, к примеру, если взять калькулятор, то часто ставка полученная расчетным путем на основании строки/итого накладной будет отлична от 10/18% и некоторые клиенты на это жалуются (точнее, они скорее всего жалуются на то, что накладная из аксапте по сумме не сходится с любимой желтой программой бухгалтера =)

Цитата:

Сообщение от ashu

...есть только маленький нюанс- что корректировка НДС система делает в целом по накладной, а не по строкам ...

если точнее, то коррекция налога работает в разрезе кодов НДС. Если в накладной один код НДС (10% или 18%), тогда в целом по накладной; если в накладной разные НДС (10 и 18) - то можно отдельно скорректировать 10%-ный НДС и 18%-ный НДС. Как по мне, то коррекция НДС не спасет, Т.К. коррекция НДС работает в валюте заказа (т.е. опять же точность до цента, а не до копейки)

[mikeSch]

Решили делать так (малой кровью). До разноски, заказ везде фигурирует как валютный (с валютным НДСом) перед разноской, переводим его в рубли, ндс выравнивается, разносим как рублевый. Если требуется вернутся к первичным валютным документам, делаем разнесенный
заказ опять доллоровым, а ндс тянем рублевый из накладной * курс. Валютный Ндс может поплыть, но вроде все это готовы стерпеть.

[mikeSch]

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

[Fizik]

Мы сейчас столкнулись с именно этой же проблемой. Компания утвердила валютные ставки, а расчеты ведет в рублях. Также осталось очень много нерешенный вопросов с копейками.
Могу сказать, что вариант перевода заказа с валютными ставками в рублевый отбросили быстро, т.к.:
1) курс, по которому переводить валюту, должен быть средневзвешенным в зависимости от дат авансов, которыми будет закрываться будущая фактура.
2) При сопоставлении такой рублевой накладной с фактической оплатой за другую дату должна возникать курсовая разница между средневзвешенным курсом и курсом на дату оплаты. Понятно, что сама система никаких подобных проводок по курсовой разнице сделать не может, а доработки потребуются большое
3) В продолжение п.2, если фактура не оплачена в отчетном периоде, то необходимо провести переоценку, что тоже должно порождать проводки курсовой разницы между рублевыми проводками.

Пока мы остановились на варианте обработки накладной и фактуры в долларах, а печать фактуры в основной валюте. При этом курс, по которому выполняется расчет, вычисляется как средневзвешенный перед обработкой накладной.
И все бы ничего, если бы не проблема: сумма проводки в рублях (AmountMST) иногда отличается от той суммы, которая получается в результате сложения сумм в основной валюте (AmountMST) накладной.
Т.е. сумма по заказу 473,46
курс 5623,7600
Проводка в баланс 473,46*5623,7600 = 26 626,25.

Заказ состоит из 3 строк с разными ценами, что с сумме при обработке накладной дает 26 626,24. Т.е разница на 1 копейку. Фактура получается на 26 626,24.

Как это обыграть в учете?
Неужели стандартный функционал не может решить такую проблему?

[Ivanhoe]

Коллеги, можно вопрос? Вы все просто делаете, что сказали, или все-таки обсуждали варианты с бухгалтерией? Если у вас не валютные сделки, а именно у.е. нет никакой проблемы делать пересчет в рубли и выставлять ровно рублевые документы. Клиент же эти документы принимает к учету тоже, и фактуры у него в рублях, соответственно НДС в у.е. его не должен волновать. Все остальные варианты - это ерунда в головах бухгалтерии, которая не хочет думать, а хочет "чтобы само".

[Михаил Андреев]

Поддерживаю! Более того. Чисто технически невозможно обеспечить отсутствие ошибок округление с реальными курсами. Условно говоря, если общая сумма не делится ровно на 100%+Ставка НДС (1,18 и т.п.), то как не считай, не сойдётся. Попробуйте из цены 1,17 выделить НДС при количестве более 1000, всё сразу станет понятно. А если ещё и валюта с округлением до 2 знаков после запятой с курсом около сотни, ошибка возникает уже при количестве, равном единице. Как говорил доктор Преображенский, "разруха не в клозетах, а в головах". Пока в голове у заказчика порядок не наведёте, программа ничем помочь не сможет.

[mikeSch]

Цитата:

Сообщение от Ivanhoe

Коллеги, можно вопрос? Вы все просто делаете, что сказали, или все-таки обсуждали варианты с бухгалтерией?

Для иностранных клиентов утверждаются валютные тарифы. Расчеты ведутся в рублях по курсу. Отраслевым стандартом определена форма первичного документа акта - который является суть счетом на оплату с выделенным НДСом по каждой позиции. Исторически все делалось следующим образом:
Акт полностью валютный с валютным НДСом. Для рублевой фактуры - переводится в рубли по курсу, а рублевая сумма делится на базу и налог так что бы налог составлял 18% от базы и все были рады и хотели что бы мы сделали так же. Сначала убедили бухгалтерию что так делать нельзя потому как, При таком подходе мы суть меняем тариф (что должно вызывать вопросы у клиента) и базу НДС (что должно вызывать вопросы у налоговой.) Если выставлять рублевую фактуру правильно - по валютному счету, то появляется расхождение в сумме НДС.
Закон с одной стороны говорит что НДС должен выделятся с базы * курс, с другой не чего не говорит что делать в ситуации когда счет валютный.

Цитата:

Сообщение от Михаил Андреев

Более того. Чисто технически невозможно обеспечить отсутствие ошибок округление с реальными курсами.

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

[ena_ax]

При создонии рублевого документа есть несколько вопросов
1. По какому курсу делать конвертацию? Необходимо учитывать курс авансовых платежей.
2. Если не ошибаюсь, то на остаток задолженности необходимо начислять курсовые разницы
3. Как отслеживать расчеты в у.е.?
4. Как обеспечить, что рублевая сумма последнего платежа будет равна остатка по продаже, чтобы расчеты закрылись в ноль?

У нас бухгалтерия закрывает глаза на расхождения по теме

[Fizik]

Могу сказать, что мы со своей бухгалтерией нашли некий компромисс и решение.

Цитата:

Сообщение от ena_ax

При создонии рублевого документа есть несколько вопросов
1. По какому курсу делать конвертацию? Необходимо учитывать курс авансовых платежей.
2. Если не ошибаюсь, то на остаток задолженности необходимо начислять курсовые разницы
3. Как отслеживать расчеты в у.е.?
4. Как обеспечить, что рублевая сумма последнего платежа будет равна остатка по продаже, чтобы расчеты закрылись в ноль?

У нас бухгалтерия закрывает глаза на расхождения по теме

1. Курс рассчитываем как фиксированный перед обработкой заказа в зависимости от существующих авансов. Если их не хватает, то на остаток берем курс на дату оказания услуги.
2. Расчеты проводим в у.е., а документы печатаем в основной валюте.
3. При сопоставлении накладных и предоплатами и оплатами закрываются суммы и возникают автоматические курсовые разницы.

Если ставка ндс = 0, то при расхождении суммы проводки и суммы по с/ф на 1 комейку система делает проводку на суммовую разницу. При этом сумма в книге продаж и сумма в балансе сходится.
Если ставка ндс = 18, то проводки на 1 копейку нет, система корректирует округление за счет суммы НДС. В этом случае получаются расхождения, но не более рубля за отчетный период по нашим оценкам. Бухгалтерия согласна с этим смириться.

[Вельмесь]

Цитата:

Сообщение от Fizik

Т.е. сумма по заказу 473,46
курс 5623,7600
Проводка в баланс 473,46*5623,7600 = 26 626,25.

Заказ состоит из 3 строк с разными ценами, что с сумме при обработке накладной дает 26 626,24. Т.е разница на 1 копейку. Фактура получается на 26 626,24.

Как это обыграть в учете?
Неужели стандартный функционал не может решить такую проблему?

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