Таможня в AX 2009 Rollup 5: смешные баги и концептуальные проблемы

[EVGL]

Как известно, Австрия славится специалистами по российской бухгалтерии; сегодня господа Е. Глазов и Р.Р. Штайнер экспериментировали с новым функционалом таможни в RU5, много смеялись.

Начнем с очевидных багов:

1) Начислять задолженность можно перед таможней, а можно перед брокером. Такая идея, по крайней мере, была у разработчиков. Проблема только в том, что при создании заголовка журнала при выборе опции "На брокера" в поле "Брокер" список всегда пустой. Брокера можно выбрать только тогда, когда начисление идет на таможню, т.е. в только в том режиме, когда он не нужен.

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

3) Если в модуле ГК идет проверка на дубликаты ваучеров, невозможно разнести журнал в случае перехода права собственности "после таможни": класс CustomJournalPost_RU работает исключительно на клиенте (умно, умно) и вызывает методы проверки RLS в LegderVoucher..., которые на клиенте вызвать нельзя.

Не очень очевидные баги:
4) Если отключен конф. ключ российских договоров, то помимо номеров договоров не виден и сам код поставщика в журнале таможни, сделать с таким журналом ничего невозможно.

5) Да, в документации написано, что работать можно только с включенными аналитиками "ГТД" и "Профиль разноски", но при работе с журналом проверка на это идет весьма пассивно, если вообще идет: при выпуске ГТД пробивка номера ГТД в складских проводках идет вне зависимости от того, активна эта аналитика в группе складских аналитик, или нет. Аналогично топорно идет работа и с профилем разноски в режиме "переход права собственности до таможни".


Перейдем к предложениям и концептуальным проблемам:
А) В режиме "переход права собственности до таможни" выпуск ГТД переводит складские проводки в статус "Зарегистрировано". По-видимому, люди, разработавшие эту концепцию, считают, что регистрация товара - эта такая экзотическая функция, которая сделана для решения всяких проблем локализаторов, ими застолблена и может в любое время быть использована. Им невдомек, что приемка товара - это мощный инструмент в логистике, с помощью которого консультанты решают многие запросы клиентов. Например, при физическом приходе товара можно пробивать такие вещи, как номер палеты или серийные номера, фактический вес или объем - т.е. данные об отгрузке, которые на момент прибытия груза на таможню не известны или не важны. Увы: чтобы сделать приемку растаможенного товара на склад и разделить его на палеты, груз придется сначала принудительно "разрегистрировать".

Б) Почему бы не заполнить код страны по умолчанию в заголовке журнала из справочника поставщика? Почему режим "Изменить склад" при выпуске ГТД всегда активирован по умолчанию?

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

Уверен, что мы пока только царапнули поверхность этого удивительного функционала и нас ждет еще много интересных открытий на проекте.

[Logger]

Прикольно. Столько всего интересного нашлось.

Цитата:

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

Как известно, Австрия славится специалистами по российской бухгалтерии; сегодня господа Е. Глазов и Р.Р. Штайнер экспериментировали с новым функционалом таможни в RU5, много смеялись.

Любопытно, с чем связан такой интерес ? Возвращаетесь на историческую родину ?

[EVGL]

Цитата:

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

Любопытно, с чем связан такой интерес ? Возвращаетесь на историческую родину ?

В своем роде: проект в Санкт-Петербурге идет.

[TasmanianDevil]

Евгений, Вы такими темпами и на святое, постинг в ГК и финансовую аналитику , то есть, начнете покушаться с критикой

[Ich@Ru]

Евгений, ряд багов действительно имеют место и будут исправлены. Спасибо! Ряд не подтвердились, свяжемся с Вами, чтобы воспроизвести ошибки.
Относительно концептуальных моментов:
1. Страна поставщика не всегда является страной происхождения товара. А заполнение данного значения по умолчанию опасно, так как пользователь может не обратить внимание, что страна указана неверная.
2. Использование Интрастат не подошло по следующим моментам. В России одна и та же номенклатура может разными таможенными постами определяться под разными кодами ТН ВЭД и действительно зависит от дат. Кроме того справочник номенклатур обычно общий для компаний в DAX, и занять российским кодом Интрастат код некорректно. Определять некую группу не стали намеренно так как трудозатраты по заведению большого количестве шаблонов для создания номенклатур аналогично дублированию справочника ТН ВЭД. Тут продумаем механизм наследования ТН ВЭД при использовании шаблона.
3. Про "зарегистрировано", нам вдомек про инструменты в логистике. Здесь мяч на нашей стороне.

[EVGL]

Понятно, спасибо.

Цитата:

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

Кроме того справочник номенклатур обычно общий для компаний в DAX, и занять российским кодом Интрастат код некорректно.

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

[EVGL]

Цитата:

1) Начислять задолженность можно перед таможней, а можно перед брокером. Такая идея, по крайней мере, была у разработчиков. Проблема только в том, что при создании заголовка журнала при выборе опции "На брокера" в поле "Брокер" список всегда пустой. Брокера можно выбрать только тогда, когда начисление идет на таможню, т.е. в только в том режиме, когда он не нужен.

Update: "ошибки" N 1 на самом деле не существует. PEBKAC, виноват пользователь EVGL, неправильно настроивший брокера.

[EVGL]

Работаю под английским интерфейсом, при внедрении строк в журнал система обращается ко мне на чистом русском языке:
"Заказ: 2000004, номенклатура IN01399, Инвойсная стоимость не может быть равна 0"

В полном соответствии с Best Practices разработчики оставили в методе \Classes\CustomJournalCalc_RU\calcInvoiceCostInclMarkup текстовую константу вместо метки.

[George Nordic]

Это специально дл тебя Привет, так сказать, с Родины Остальны все равно не поймут, что там накалякано

Г.

[EVGL]

Цитата:

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

Работаю под английским интерфейсом, при внедрении строк в журнал система обращается ко мне на чистом русском языке:
"Заказ: 2000004, номенклатура IN01399, Инвойсная стоимость не может быть равна 0"

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

Попробую зарегистрировать баг в MS, если нервов на общение с Золтанами и Субраманьянами хватит.

[Ich@Ru]

Евгений, готовы взять общение с вышеуказанными персонами на себя

[EVGL]

Цитата:

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

Евгений, готовы взять общение с вышеуказанными персонами на себя

Ой, спасибо! К сожалению, в случае с этим загадочным сообщением все немного сложнее. Прислали очередной тест-кейс, где одним удалением закупки все не объясняется. Сейчас проанализирую.

[EVGL]

P.S. Нет, никаких багов больше нет. Народ просто не рюхает, что такое "доступное количество" для внесения в журнал.

[Ich@Ru]

Зарегистрировали. Часть выявленных ранее ошибок исправлены в RU-6.

[Ivanhoe]

Коллеги, найдена ошибка при заполнении проводок поставщика - не заполняется договор.

Предлагаемое решение - в метод CustVendVoucher.getContractFieldIds_RU() добавить блок:

//+ Ivanhoe
case tablenum(CustomJournalTable_RU) :
	contractAccount = fieldnum(CustomJournalTable_RU, rContractAccountCustom);
        contractCode    = fieldnum(CustomJournalTable_RU, rContractCodeCustom);
        break;
//- Ivanhoe

[EVGL]

Хм, а зачем нам там проводка поставщика? Проводка идет на брокера или таможню, так? А они не должны являться частью контракта с нашим контрагентом.

[Ivanhoe]

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

[Ivanhoe]

Продолжаем разговор (актуально для AX2009 SP1 RU6):

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

Исправлять в классе CustomJournalCalc_RU:

public void initFromTable(CustomJournalTable_RU _customJournalTable)
{
    ;

    customJournalTable = _customJournalTable;
    customJournalType  = _customJournalTable.CustomJournalType;

    //+ Ivanhoe
    //dlvTermId          = _customJournalTable.rContractTable().DlvTermCode_RU;
    dlvTermId          = _customJournalTable.DlvTermId;
    //- Ivanhoe
}

[EVGL]

В последнем Роллапе "улучшили" связь номенклатуры с кодом ТН ВЭД: поле "Код таможни" теперь стало обязательным, логика поиска при этом осталась неизменной. Боже, какой абсурд!

[EVGL]

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

• импортные фактуры по инвойсам не позвяют обрабатывать инвойсы, в которых единица измерения закупок не совпадает с единицей складского учета
• если при приходе разносятся отборочные накладные датой, отличной от даты инвойса, то обработать инвойсы не удастся
• все так же не получится обработать строки счетов, в которых есть сумма, но нет цены. Такое случается сплошь и рядом, если цена в строке счета отличается на цент от строки заказа на покупку, и бухгалтер начинает выправлять по сумме
• как известно, таможенная стоимость никогда не совпадает с тем, что предлагает в ее качестве Аксапта. НИКОГДА. Тому причин может быть масса, начиная с трансграничных транспортных расходов и заканчивая банальным разделением труда между отделами. Однако, редактировать по разделу можно только пошлину, а надо: пошлину по разделу, сбор за обработку ГТД (!), НДС по разделу (!), таможенную стоимость по разделу.
• классическая ошибка, описанная Ivanhoe: нет контракта в заголовке - нет и транспортных расходов в стоимости
• без доработок попытка разнести пошлины на себестоимость - это как русская рулетка, что связано с отсутствием должной обработки ошибки округления
• навязчивые индикативные цены, зацикленность на профилях учета, переносах со склада на склад
• новый таможенный пост обязательно требует нового поставщика - раздвоение, растроение кредиторской задолженности
• таможенный журнал по экспорту принимает только те накладные, которые сформированы в режиме отложенного перехода права собственности. Шаг влево, шаг вправо - расстрел.