О сломанных шестеренках в большом моторе

[EVGL]

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

Суть в том, что в AX2009 появилась возможность разноски счета (RU: накладной) с количеством из предварительно оприходованной накладной (RU: отборочной накладной, по сути - акт прихода на склад). Раньше нам рассказывали, что такая возможность совершенно ни к чему - разнести накладную с проверкой по акту прихода. Когда они эту возможность предоставили, этот метод разноски почему-то сразу оказался режимом по умолчанию.


Одновременно была добавлена возможность попытаться разнести заново счет, в котором были ошибки. Недоразнесенный счет попадает в таблицу VendInvoiceInfoTable, а его связи с отборочными накладными сохраняются в таблице VendInvoiceInfoSubTable и -Line. На тех же данных основана и проверка количества/цены - пресловутое "трехстороннее сопоставление".

Комбинация этих двух фичей породила монстра. В каких-то особых ситуациях VendInvoiceInfoTable переходит в статус Ожидание, пробивая при этом границы транзакции, и зависает навсегда, причем заново ввести счет невозможно: его источник - отборочная накладная - считается заблокированной и ждущей обработки другим пользователем. Форма разноски счета просто остается навсегда пустой и не выбирает больше закупку.

Теоретически, из клинча можно выйти через форму РсП / Места / Необработанные заказы на покупку - накладные, однако разрабочики избрали оригинальный способ взаимодействия с пользователем: если форма не пустая, а параметр "Трехсторонне сопоставление..." в параметрах модуля неактивен, пользователю предлагается продолжить работу в дебаггере (Debug::assert() прямо из источника данных). Можете представить себе мое злорадство, когда как-то раз представитель Microsoft сам нарвался на эту мину, теперь уже в версии AX2012.

Результат: у пользователя вообще нет шанса вырваться из порочного круга. Консультанту же рекомендуется залезть в обозреватель таблиц и стереть все, что начинается на VendInvoiceInfo*.

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

[sukhanchik]

Цитата:

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

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

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

Речь идет о форме Настройка-Налог из заказов на покупку. Вкладка Корректировка появляется только для исходящего налога (форма TaxTmpWorkTrans).

Вот что на форме прописано в методе init (особенно порадовало - КАК это написано - formstr и название формы с апострофами):

......     
        switch (callerForm.name())
        {
            case formstr('PurchTable') :

                regulationTab.visible(false);
                tmpTaxRegulation_ds.allowCreate(false);
                tmpTaxRegulation_ds.allowDelete(false);
                break;
......

Здесь - relulationTab - как раз та самая закладка Коррекция

Метод setAllowEdit той же формы:

    if (callerForm)
    {
        if (callerForm.name() == formstr('PurchTable'))
        {
            purchaseOrderForm = true;
        }
    }

    if (sourceSingleLine || (!taxRegulation.taxLinesExist() && !invoiceRegister)
        || purchaseOrderForm == true)
    {
        tmpTaxRegulation_ds.allowEdit(false);
        taxRegulationField.allowEdit(false);

Что любопытно:
1. "Врезки" с упоминанием PurchTable сделаны аккуратно. Если их также аккуратно убрать - то функционал корректировки входящего НДС появляется. Правда в этом случае начинает (как и ожидалось) крышу сносить у трехстороннего сопоставления - НДС-то уже "не тот" . Я имею в виду конечно вариант, когда цена включает НДС.
2. Код формы TaxTmpWorkTrans в 4.0 SP2 отличается от кода формы в 2009 RU6 исключительно этими вставками
3. То, КАК было написано название формы в коде позволяет сделать вывод о гхм... сравнительно небольшом опыте работы в АХ разработчика, писавшего этот код. Неудивительно - что он "поломал" функциональность корректировки - он просто мог не знать для чего она нужна....

А теперь самое интересное. В официальных тренингах от МС корректировка входящего НДС описана как работающая функциональность, которую нужно показывать слушателям (ну, само собой, трехстороннее сопоставление тоже должно показываться). Правда, налоги рассказываются в курсе по финансам (Финансы 1, глава 6; Корректировка на стр. 6-62), а сопоставление - в курсе по логистике (Логистика 1, глава 3 на стр. 3-64) .