Сбор за таможенное оформление

[EVGL]

Руководство по Rollup 5 умалчивает о настройке ступенчатой ставки сбора за таможенное оформление, который зависит от общей суммы ГТД:
http://www.tamognia.ru/payments/gathering/#1a

Цитата:

Таможенные сборы за таможенное оформление товаров, в том числе транспортных средств, перемещаемых через таможенную границу РФ в качестве товаров, а также легковых автомобилей, классифицируемых в товарных позициях 8702 и 8703 ТН ВЭД России, перемещаемых через таможенную границу РФ физическими лицами для личных, семейных, домашних и иных не связанных с осуществлением предпринимательской деятельности нужд, уплачиваются по следующим ставкам:

500 рублей - за таможенное оформление товаров, таможенная стоимость которых не превышает 200 тыс. рублей включительно;

1 тыс. рублей - за таможенное оформление товаров, таможенная стоимость которых составляет 200 тыс. рублей 1 копейку и более, но не превышает 450 тыс. рублей включительно;

2 тыс. рублей - за таможенное оформление товаров, таможенная стоимость которых составляет 450 тыс. рублей 1 копейку и более, но не превышает 1200 тыс. рублей включительно;

5,5 тыс. рублей - за таможенное оформление товаров, таможенная стоимость которых составляет 1200 тыс. рублей 1 копейку и более, но не превышает 2500 тыс. рублей включительно;

7,5 тыс. рублей - за таможенное оформление товаров, таможенная стоимость которых составляет 2500 тыс. рублей 1 копейку и более, но не превышает 5000 тыс. рублей включительно;

20 тыс. рублей - за таможенное оформление товаров, таможенная стоимость которых составляет 5000 тыс. рублей 1 копейку и более, но не превышает 10000 тыс. рублей включительно;

50 тыс. рублей - за таможенное оформление товаров, таможенная стоимость которых составляет 10000 тыс. рублей 1 копейку и более, но не превышает 30000 тыс. рублей включительно;

100 тыс. рублей - за таможенное оформление товаров, таможенная стоимость которых составляет 30000 тыс. рублей 1 копейку и более.
...

Может быть, кому-нибудь пригодится мое нижеследующее руководство. Тонкость в том, что ступенчатые налоги в AX считаются нарастающей суммой.
Итак: создать налоговый код типа "Таможенный сбор", Тип сбора = "Оформление импорта", Основание = "Сумма на единицу", База ... = "Чистая сумма по строке", Метод расчета = "Интервал", Единица измерения = "RUR" (некая мнимая единица).

После этого в "Значениях" надо ввести такую лестницу:
.

[Alexius]

По просьбам трудящихся я вообще выкинул расчет сборов и дал пользователям напрямую вводить сумму. Бодаться с государевыми органами обычно себе дороже

[Ivanhoe]

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

offtop: про индикативные цены вообще молчу, ни один клиент ими не пользуется (а цены, зачастую - "know how" конкретного поста), а если их не использовать, то все равно выдаются предупреждения что они не рассчитаны.

[dn]

Зачем вообще сделали этот расчет? Эта функциональность нужна на стороне таможни, а ни как ни клиента.

[Ich@Ru]

Индикативные цены призваны помочь проанализоровать возможные разногласия с таможенным органом. Введение параметра: принимать во внимание индикативные цены или нет - вероятно не помешало бы.

[EVGL]

Цитата:

Сообщение от Ich@Ru

Индикативные цены призваны помочь проанализоровать возможные разногласия с таможенным органом. Введение параметра: принимать во внимание индикативные цены или нет - вероятно не помешало бы.

Вероятно. А также не помешало бы отменить обязательность указания профиля - все прекрасно работает и без него. Уже на втором проекте отключаю, очередной Change Request прошел под названиям "Typical improvements in Russian customs journals". Разумеется, пакет включает и устранение индикативных цен.

Еще одно слабое место, как уже было отмечено мною год назад, - это связь кода номенклатуры и кода ТНВЭД. С одной стороны, эта связь недостаточно навороченная, чтобы уметь работать с номенклатурными аналитиками, но при этом достаточно нормализованная, чтобы ее было неудобно вводить и/или копировать из шаблона. "Хотели, как лучше, а получилось как всегда."

[EVGL]

История со сбором получила продолжение: остается только присоединиться к оратору Alexius. Самая первая же ГТД попала на границу 1 200 000 рублей: система посчитала стоимость по инвойсам в размере 900 000, а на самом деле она была 1 300 000. Идеальный мир программистов и аналитиков не выдержал столкновения с суровой действительностью.

Источник расхождения был совершенно ясен: в таможенную стоимость надо включать не только стоимость по инвойсу по курсу (какому?), но и стоимость доставки до границы РФ. При этом имеем следующие осложнения:
1) система берет инвойсную стоимость с распределенными накладными расходами. Не всегда можно ожидать, что та часть накладных расходов за доставку, что прошла до границы, будет умело занесена и распределена по разным кодам накладных расходов, чтобы потом часть - включить, а часть - не включать в таможенную стоимость.
2) Где гарантия, что сама таможенная декларация оформлена и рассчитана идеально верно?

Слава богу, редактировать рассчитанный сбор легко: достаточно открыть на редактирование поле CustomJournalTable.EstimativeAdminCharge и поместить его в подходящую группу в заголовке журнала.
Гораздо страшнее неизбежные ошибки округления при разноске на себестоимость. Но об этом - в следующий раз.

[EVGL]

Обещанное продолжение: если под одним номером ГТД и номером инвойса проходит несколько проводок InventTrans, а разноска идет на себестоимость, то рано или поздно при попытке разноски ГТД произойдет ошибка, связанная с округлением. Такая ситуация неминуемо возникнет, если идет учет по палетам или серийным номерам.

Опять-таки, я получил это на первой же наипростейшей реальной ГТД, состоящей из одной строки инвойса.


Программист метода \Classes\CustomJournalGTDPostImport_RU\createInventAdjust наивно поставил throw error на случай, если ему не удалось до конца распределить сумму ГТД на проводки. При этом он совершил ряд логических и технических ошибок:

в строке 81 встречается пассаж

        if (remainAdjustNow <= Currency::find(customCurrencyCode).RoundOffAmount)
        {
            adjustNow += remainAdjustNow;
            remainAdjustNow = 0;
        }

в котором идет попытка скомпенсировать ошибку округления. При этом customCurrencyCode - это не что иное, как рубли, причем всегда. Проверяется параметр на валюте "рубль", который обычно на проекте выставляют в копейку. Легко понять, что эта проверка в описанной ситуации практически не работает.

Паллиативное решение заключается в том, чтобы поменять проверку на

if (remainAdjustNow <= LedgerParameters::find().MaxRoundingDifferenceMST)

которая будет срабатывать гораздо чаще.

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


Сам цикл, в котором идет поиск InventTrans для распределения, тоже неверен, поскольку не проверяется InvoiceReturned да и вообще знак проводки. Если в инвойс замешалась строка со сторно, жди очень интересных эффектов.

[Sada]

А если у меня remainAdjustNow меньше нуля. Это я что то делаю не так? Я корректирую таможенный сбор и пошлины. То есть мне нужно изменить себестоимость (увеличить или уменьшить). Так вот если уменьшить, то как то не правильно работает на мой взгляд это дело...