The daily Axapta WTF

[dech]

Наткнулся в недрах класса JournalRunBaseBatch

public container  pack()
{
    throw error(Error::missingOverload(funcName()));
}

То же самое и для unpack().
Здесь как бы разница есть, перегружен метод, или переопределен.
Причем в Х++ сроду не было перегруженных методов.
Видимо, не сильно-то и важно. Заходим внутрь и видим:

//Do not use!
//Declare method as abstract instead or call Error::missingOverride();
#obsolete static LabelType missingOverload(str name)
{
    return Error::missingOverride(name);
}

Ладно, здесь возможно заглушку поставили на случай будущих апгрейдов в сторону нормальных языков.
Но что мешало сразу использовать missingOverride()?
Напомню, кто может не въехал.
Override - переопределение метода в рамках наследования.
Overload - перегрузка метода, т.е. в теле одного класса мы можем разместить дофига методов с одним и тем же именем, но разными параметрами. Что очень распространено в C#, Java и Delphi.
Такое чувство, что разработчики MS просто сами не сильно понимают в чем разница.

[Vadik]

Гендерно- и расово-нейтральный новояз прекрасен

[Ace of Database]

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

[Владимир Максимов]

Вот не знаю, это ошибка или сознательно сделали

dax2012R3

Табличный метод PurchTable.initFromPurchAgreementHeader()

    select firstonly DeliveryPostalAddress, DeliveryName, Project, ContactPerson,
                     CashDiscountCode, MiscChargeGroup, DeliveryTerm, DeliveryMode,
                     PaymentSchedule, PaymentTerms
        from agreementHeaderDefault
        where agreementHeaderDefault.AgreementHeader == _purchAgreementHeader.RecId
        join firstonly    MethodOfPayment
                        , PaymentSpecification
                        , BuyerGroup
                        , VendorInvoiceAccount
                        , PurchasePool
            from purchAgreementHeaderDefault
            where purchAgreementHeaderDefault.PurchaseAgreementHeader == _purchAgreementHeader.RecId
        // <GEERU>
        outer join firstonly RecId,
                             InventProfileType,
                             InventProfileId,
                             VendPostingProfile,
                             vatOperationCode,
                             vatChargeSource
        from purchAgreementHeaderExt
        where purchAgreementHeaderExt.AgreementHeader == _purchAgreementHeader.RecId
        // </GEERU>
            ;

Тут проблема в том, что на таблицах AgreementHeaderDefault и PurchAgreementHeaderDefault стоит контроль на пустоту. Если все значимые поля пустые, то запись не создается или удаляется. Как следствие, если хотя бы по одной таблице записи не существует (т.е. не заполнены поля с данными), то не получим данные из остальных таблиц, даже если там что-то есть

В этом был какой-то глубокий смысл или "так получилось" ?

[mayk]

Наткнулся на прелести обновления индексированных полей InMemory таблиц
Пример 3 разных попыток обновления

   TmpFontName tmp;    
    ;    
    //(update_recordset)
    delete_from tmp; tmp.insert();
    update_recordset tmp setting FontName = tmp.FontName + 'a';
    while select tmp {info (tmp.FontName);}
    
    //(select forupdate)
    delete_from tmp; tmp.insert();
    while select forupdate tmp{ tmp.FontName += 'a'; tmp.update(); }
    while select tmp {info (tmp.FontName);}

    //(select forupdate order)
    delete_from tmp; tmp.insert();
    while select forupdate tmp order recid{ tmp.FontName += 'a'; tmp.update(); }
    while select tmp {info (tmp.FontName);}

Что выведет джоб? Вот что:

Цитата:

Сообщение (16:16:38)
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
a

А с TempDb такой ерунды нет. Обновление выполняется лишь один раз.

[Ace of Database]

Axapta 2012 R3
Расчеты с клиентами - Журналы - Платежи - Журнал платежей
Создаем первую строку в журнале. Вводим какого-то клиента
Создаем вторую строку в журнале. Вводит другого клиента
Стоя на второй строке журнала нажимаем "Фукнции - Сопоставление".
Помечаем проводки для сопоставления.
Потом не закрывая форму сопоставлений возвращаемся на форму строк журнала и встаем на первую строку
Потом возвращаемся на форму сопоставлений и закрываем её
И вуаля - в первую строку журнала записывается аналитика из клиента, который указан для второй строки.
А потом удивляемся при сведении балансов.

[dech]

Как бы и ошибок нет, Но индусы снова поражают своей логикой!
В классе PurchTableType:

/// <summary>
/// Checks if the invoice can be updated.
/// </summary>
/// <returns>
/// Returns true if the invoice can be updated.
/// </returns>
// <GIN>
public boolean  canInvoiceBeUpdated_IN()
{
    boolean  ok = true;

    ok = this.mayInvoiceBeUpdated();
    if (ok && !VendTable::canVendorBeUpdated(purchTable.OrderAccount, purchTable.InvoiceAccount, DocumentStatus::Invoice))
    {
        ok = false;
    }
    if (ok)
    {
        if (purchTable.InterCompanyOrder
            &&  purchTable.InterCompanyOriginalSalesId
            &&  purchTable.InterCompanyDirectDelivery)
        {
           ok = (!purchTable.interCompanyEndpointActionPolicy().PostPurchInvoice
                &&   purchTable.interCompanySalesTable().SalesStatus == SalesStatus::Invoiced);
        }
        ok = ok && true;  // Что это за дикость?
    }

    if (ok)
    {
        ok = this.checkPurchQty(DocumentStatus::Invoice);
    }

    return ok;
}
// </GIN>

[Raven Melancholic]

ok = ok && true;

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

До DAX2012, в которой точки останова срабатывают на скобке, завершающей блок кода или метода, иногда сам так делал.

Правда в рабочем приложении такое видеть, конечно, дикость.

[Logger]

Цитата:

Сообщение от Raven Melancholic

ok = ok && true;

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

Я обычно завожу в глобале метод пустышку с именем dummy или empty и ставлю в код его вызов.

[dech]

Цитата:

Сообщение от Raven Melancholic

ok = ok && true;

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

В данном случае не нужно писать дополнительный код для точки останова.
Следующий if (ok) вполне пригоден для просмотра значений переменных.
Скорее выглядит как копипаста, когда лишний код убрали, оставив такую конструкцию.

[fed]

Не вполне баг кодинга, но все равно - неприятно поразившая меня фича D365FO.
С древних времен версии 2.1 и по крайней мере до последнего релиза DAX2012, удаление складских проводок при уменьшении количества в заказе шло в порядке OnOrder->ReserveOrdered->ReservePhysical. Все это происходило независимо от наличия/остуствия складской маркировки. В D365FO, добавили два прохода: Сначала оно обрабатывает в таком порядке складские проводки без маркировки, а потом с маркировкой.
У меня у клиента часто возникает такая ситуация: Клиент заказал допустим 40 подарков к рождеству; На складе удалось зарезервировать 30, и еще 10 примаркировали к закупке с ожидаемым сроком доставки 22.12. Потом клиент звонит и говорит что не хочет ждать, хочет 30 штук сразу, а вместо 10 недостающих подарков купит что-то другое в другой фирме.
В традиционных версиях DAX, если уменьшить количество в строке заказа до 30, то система оставит 30 штук физически зарезервированых и удалит складскую проводку на 10 штук в статусе "Зарезервировано в заказаных". В D365FO, она выкинет 10 штук из физически зарезервированой проводки (поскольку она не примаркирована), и оставит в итоге 20 штук зарезервированых на складе и 10 штук в заказаных. Так что если мы попытаемся отгрузить клиенту обещенные прямо сейчас 30 штук, система скажет что в этот раз мы можем отгрузить только 20 штук и тп. Единственный выход - отмаркировать злополучную складскую проводку от закупки до удаления количества...

[axm2017]

Может чего то не догоняю но в форме PurchTotals (ax 2012) переменная
PurchTotals purchTotals;
не используется а существует для фана.

[Владимир Максимов]

Скорее всего, когда переделывали форму на разные таблицы-источники просто забыли удалить уже не нужную переменную из ClassDeclaration. Или была идея, что класс PurchTotals также будет общий. Возможно, как класс-родитель

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

[axm2017]

Так и делал


Думаю переделали но забыли убрать атавизм.

[gl00mie]

В D365FO семейство классов RAssetProposal очень "занятно" распаковывает параметры в unpack(), из-за чего не так просто добавлять в это семейство новые параметры для сохранения в pack()/unpack().
Коллега недавно наткнулся на проблему, пытаясь применить к этому семейству рекомендации по расширению наследников RunBase. В рекомендациях говорится, что в pack() вашего класса-расширения нужно написать примерено так:

public container pack()
{
    container packedClass = next pack();
    return SysPackExtensions::appendExtension(packedClass, classStr(MySysUserLogCleanup_Extension), this.myPack());
}

При этом - внимание! - в конец общего контейнера допишется еще один элемент-контейнер с параметрами вашего расширения. Если расширений несколько, то, вероятно, допишется не один элемент, а несколько. В unpack() же класса-расширения вам надо написать примерно вот так:

public boolean unpack(container _packedClass)
{
    boolean result = next unpack(_packedClass);
    if (result)
    {
        container myState = SysPackExtensions::findExtension(_packedClass, classStr(MySysUserLogCleanup_Extension));
        result = this.myUnpack(myState); //Also unpack the extension
    }
    return result;
}

Но в случае RAssetProposal следование официальной инструкции приводит к ошибке времени выполнения в расширяемом классе: невозможно инициализировать queryRun из контейнера.
Вот как бы вы работали с queryRun в pack/unpack? Обычно это выглядит так:

public container pack()
{
    return [#CurrentVersion, #CurrentList, queryRun.pack()];
}

public boolean unpack(container _packedClass)
{
    Version version = RunBase::getVersion(_packedClass);
    boolean ret = true;

    switch (version)
    {
        case #CurrentVersion :
            container packedQuery;
            [version, #CurrentList, packedQuery] = _packedClass;
            if (SysQuery::isPackedOk(packedQuery))
            // ...

Обратите внимание, что конструкция вида

[version, #CurrentList, packedQuery] = _packedClass;

симметрична конструкции

return [#CurrentVersion, #CurrentList, queryRun.pack()];

она позволяет безболезненно отбросить все лишние элементы в конце контейнера _packedClass и взять своё строго с тех позиций, какие получились в вашем pack().
Но локализаторы же хитрее всех, поэтому они считают, что их запакованный queryRun всегда идет последним, и пишут вот что:

public boolean unpack(container packedClass)
{
    Integer     version = conPeek(packedClass,1);
    container   packedQuery = conPeek(packedClass, conLen(packedClass));

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

[ax_mct]

Цитата:

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

...
Но в случае RAssetProposal следование официальной инструкции приводит к ошибке времени выполнения в расширяемом классе: невозможно инициализировать queryRun из контейнера.
...
Вот как бы вы работали с queryRun в pack/unpack? Обычно это выглядит так:
...

Re: "контейнер стал длиннее"

Спасибо за опыт! Делаю вывод что в топку их инструкцию так любое их обновление unpack может вызвать подобный сценарий ошибки.

Часв два времени сделать свою таблицу и отладить код для хранения своего контейнера.

То есть:
CoC на pack/unpack но без изменений того что кладется и вынимается.
Собственная таблица для хранения своего дополнительного контейнера.

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

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

Кто будет виноват. Мы. Из-за нашего расширения ошибка - да.
Подстава.

[trud]

Ну может автор хотел чтобы вы в каждом экстеншене паковали его query. Имеет же право

[ax_mct]

Цитата:

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

Ну может автор хотел чтобы вы в каждом экстеншене паковали его query. Имеет же право

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

[axm2017]

Долго не мог понять какого моя ER конфигурация (технически стандартный функционал ER\SSRS накладных) отказывается работать
Пришлось заглянуть в код.

Много думал на тему рукожопства с ограничением по RU.

[axm2017]

Делал доклад по ER
Традиционно (когда еще замечать косяки как не в ходе показа?) в его процессе заметил возможность добавить void в модель
Попробовал ради интереса.

Много думал о команде ER и нехватке тестеров.