The daily Axapta WTF - Страница 6 - Курилка

TasmanianDevil · 14.01.2011, 14:52

2S.Kuskov
Тут даже гадать не надо, какое ТЗ - в методе объем тупизны измеряется возом и маленькой тележкой. У LedgerJournalTrans в репозитарии всего чуть менее 20 полей с запретом редактирования - для них этот метод не будет работать, ибо запрет на репозитарии приоритетнее. Для остальных полей редактирование в репозитарии разрешено. На источнике данных на форме ни одно из полей не имеет запрета на редактирование. Часть полей закрыто на редактирование на контролах. Все итерации по перебору полей, кроме этих семи, и выставление им свойства на разрешение редактирования будут либо повторять выставление уже имеющихся свойств, либо работать впустую - т.е. по сути будут абсолютно бесполезны. LedgerJournalTrans - очень тяжелая таблица, полей в ней очень много (в нашей конфигурации - почти 200) и они перебираются все. Дополнительный тормоз на active() в виде такой кучи бесполезных итераций никуда и никому не уперся, IMHO

2Wamr
Именно в ходе своей доработки с закрытием (которое не работало) собственных полей и нарыл сию прелесть

S.Kuskov · 14.01.2011, 15:15

Претензии понял, негодование разделяю. Но ИМХО Индус не специально

Logger · 19.01.2012, 21:10

Индийский код или я чего-то не понимаю ?

\Classes\DirUtility\getPartyCompanyList

X++:

static container getPartyCompanyList()
{
    DirPartyTable   partyTable;
    container       dataAreaIdList;
    container       ret;
    int             i;
    container       virtualCompanyList = DirUtility::getVirtualDataAreaList();
    ;
    if (confind(virtualCompanyList,partyTable.DataAreaId))
    {
        dataAreaIdList= conpeek(virtualCompanyList,confind(virtualCompanyList,partyTable.DataAreaId)+1);
        for (i=1 ; i<=conlen(dataAreaIdList) ; i++)
        {
            ret = conins(ret,i,conpeek(dataAreaIdList,i));
        }
        return ret;
    }
    return [partyTable.DataAreaId];
}

Зачем этот блок ?

X++:

        for (i=1 ; i<=conlen(dataAreaIdList) ; i++)
        {
            ret = conins(ret,i,conpeek(dataAreaIdList,i));
        }
        return ret;

если можно просто написать

X++:

return dataAreaIdList

TasmanianDevil · 23.01.2012, 12:44

DAX2009, ядро 5.0.1000.52

Объявляем EDT на основе int64 с любым ArraySize, бОльшим 1, и именем MyType.
Создаем элементарный класс

X++:

class TestClass
{
    MyType x;
}

делаем в нем классический parm-метод

X++:

MyType parmX(MyType _x = x)
{
    if(x != _x) x = _x;

    return x;
}

пытаемся скомпилировать и получаем ошибку "Операнд несовместим с типом функции." на операторе возврата.

kashperuk · 13.06.2012, 12:18

Цитата:

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

DAX2009, ядро 5.0.1000.52

Объявляем EDT на основе int64 с любым ArraySize, бОльшим 1, и именем MyType.
Создаем элементарный класс

X++:

class TestClass
{
    MyType x;
}

делаем в нем классический parm-метод

X++:

MyType parmX(MyType _x = x)
{
    if(x != _x) x = _x;

    return x;
}

пытаемся скомпилировать и получаем ошибку "Операнд несовместим с типом функции." на операторе возврата.

Попробовал на последней версии, у меня компилируется без проблем.
Мой EDT называется правда Type1, но я не думаю, что есть разница.

Napalm · 13.06.2012, 17:44

Верхнюю половину метода написал один человек; нижнюю - другой, не глядя на верхнюю, и - внимание - ловко "оптимизировал" код использовав список полей. BestPractice ошибок нет - все отлично. Это из стандартного кода AX 2012.

CustWriteOff\checkForDuplicateVouchers

X++:

protected boolean checkForDuplicateVouchers(Voucher _voucher, TransDate _transDate, recId _existingCustTransRecId)
{
    boolean found;
    VendTrans vendTrans;

    // check for duplicate customer transaction
    found = (select firstonly RecId from custTrans
                where custTrans.Voucher == _voucher
                   && custTrans.TransDate == _transDate
                   && custTrans.RecId != _existingCustTransRecId).RecId != 0;

    if (found == true)
    {
        return true;
    }

    // check for duplicate vendor transactions
    select count(RecId) from vendTrans
        where vendTrans.Voucher == _voucher
           && vendTrans.TransDate == _transDate;

    found = vendTrans.ReasonRefRecId == 0 ? false : true;

    return found;
}

kashperuk · 14.06.2012, 16:43

Цитата:

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

CustWriteOff\checkForDuplicateVouchers

Napalm, а расскажите подробнее про эту находку.
Где и как столкнулись? Я посмотрел, и этот код там существовал в таком виде с декабря 2008 года.

Раз до этого не заметили (а я проверил - не заметили), то скорее всего никто из кастомеров с этим не сталкивался

Napalm · 14.06.2012, 19:04

Цитата:

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

Napalm, а расскажите подробнее про эту находку.
Где и как столкнулись? Я посмотрел, и этот код там существовал в таком виде с декабря 2008 года.

Раз до этого не заметили (а я проверил - не заметили), то скорее всего никто из кастомеров с этим не сталкивался

Копировал бизнес логику для списания НДС. Не думаю, что у кого-то будут проблемы из-за этого.

Скорее всего проблемы будут если этот код "починить". Какой смысл искать дубликаты в VendTrans по полю Voucher, используя значение Voucher из CustTrans?

Возможно будут ложные срабатывания - зависит от настройки номерных серий.

DTD · 08.02.2013, 02:23

\Classes\CustAutoCreate\setCustTable

X++:

protected void setCustTable()
{
    NumberSeq       num;
    ;

    custTable.clear();
    custTable.initValue();
    custTable.data(CustTable::find(templateCustAccount));

    if (custAccount)
    {
        custTable.AccountNum = custAccount;
    }
    else
    {
        custTable.AccountNum = NumberSeq::newGetNum(CustParameters::numRefCustAccount()).num();
    }

    if (CustTable::exist(custTable.AccountNum))
    {
        if (num)
        {
            num.abort();
            checkFailed("@SYS59641");
        }
        checkFailed("@SYS59639", custTable.AccountNum);
        throw error("@SYS23020");
    }

    if (num)
    {
        num.used();
    }
}

Logger · 23.01.2012, 12:55

Где-то видел обертку в виде темповой таблички для типа Dimension. Табличка состояла из одного поля Dimension и была очевидно нужна для корректного хранения и передачи индексной переменной.
Может вам что-то подобное сделать, пока ядро не пофиксили ?

belugin · 28.04.2012, 09:25

ax-erp: Format real number

TasmanianDevil · 30.05.2012, 09:32

В продолжении темы о EDT-массиве на основе int64 ...
Имеется:
1) наличие поля с таким EDT в таблице
2) некий коде, обращающийся к значению этого поля по индексу, являющемуся переменной типа MyTable.MyField[i] = X.
3) дебаггер, в котором либо помещаем в Watches это конкретное поле, либо просто наводим на него курсор, чтобы получить tooltip со значением
Клиент лег ...

**fed** · 10.09.2012, 11:42

В последнем DAX2009RU8 наткнулся на замечательный кусочек кода в reqTrans.findCommon():

X++:

            if (reqTrans.RefType == ReqRefType::TransferDemand)
            {
                select firstonly reqTrans
                    index hint RefIdx
                    where reqTrans.ReqPlanId     == reqTrans.ReqPlanId                &&
                          reqTrans.RefType       == ReqRefType::TransferPlannedOrder  &&
                          reqTrans.RefId         == reqTrans.RefId;
            }

Конечно можно понять, что автор просто хотел найти приходную половинку спланированного заказа на перенос. Но учитывая что условия reqTrans.refId==reqTrans.refiId и reqTrans.reqPlanId==reqTrans.reqPlanId выполняются автоматически, на самом деле, он нашел первую попавшуюся чистую потребность типа "Спланированный заказ на перенос" в первом попавшемся плане. В результате - посмотреть развертывание заказа на перенос из формы "Профиль потребностей", приводит к развертыванию первого попавшегося заказа на перенос.
Можно починить примерно вот так:

X++:

                reqTransCaller=reqTrans;
                select firstonly reqTrans
                    index hint RefIdx
                    where reqTrans.ReqPlanId     == reqTransCaller.ReqPlanId                &&
                          reqTrans.RefType       == ReqRefType::TransferPlannedOrder  &&
                          reqTrans.RefId         == reqTransCaller.RefId;

abv2703 · 10.04.2019, 11:57

В последнем DAX2009RU8 наткнулся на замечательный кусочек кода в reqTrans.findCommon():
X++:
if (reqTrans.RefType == ReqRefType::TransferDemand)
{
select firstonly reqTrans
index hint RefIdx
where reqTrans.ReqPlanId == reqTrans.ReqPlanId &&
reqTrans.RefType == ReqRefType::TransferPlannedOrder &&
reqTrans.RefId == reqTrans.RefId;
}

Хе, я эту фигню нашел сегодня в 4-ке.

))

abv2703 · 10.04.2019, 12:12

Цитата:

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

В последнем DAX2009RU8 наткнулся на замечательный кусочек кода в reqTrans.findCommon():

X++:

            if (reqTrans.RefType == ReqRefType::TransferDemand)
            {
                select firstonly reqTrans
                    index hint RefIdx
                    where reqTrans.ReqPlanId     == reqTrans.ReqPlanId                &&
                          reqTrans.RefType       == ReqRefType::TransferPlannedOrder  &&
                          reqTrans.RefId         == reqTrans.RefId;
            }

Конечно можно понять, что автор просто хотел найти приходную половинку спланированного заказа на перенос. Но учитывая что условия reqTrans.refId==reqTrans.refiId и reqTrans.reqPlanId==reqTrans.reqPlanId выполняются автоматически, на самом деле, он нашел первую попавшуюся чистую потребность типа "Спланированный заказ на перенос" в первом попавшемся плане. В результате - посмотреть развертывание заказа на перенос из формы "Профиль потребностей", приводит к развертыванию первого попавшегося заказа на перенос.
Можно починить примерно вот так:

X++:

                reqTransCaller=reqTrans;
                select firstonly reqTrans
                    index hint RefIdx
                    where reqTrans.ReqPlanId     == reqTransCaller.ReqPlanId                &&
                          reqTrans.RefType       == ReqRefType::TransferPlannedOrder  &&
                          reqTrans.RefId         == reqTransCaller.RefId;

Хе, я эту фигню нашел сегодня в 4-ке

macklakov · 11.09.2012, 10:23

Столкнулся с совершенно удивительным и поразительным функционалом банковских чеков. В них применена уникальная технология формирования строк отчета. Это просто много-строчная текстовая переменная, которую запихивают в контрол отчета. Расстояние между колонками и набор доступных полей захардкожены. Причем в десятках мест одновременно:
\Classes\BankChequeCopy\fillSlipText
\Classes\CustVendCheque\fillSlipTxt
\Classes\CustVendCheque\fillSlipTxtHF
\Classes\BankPrintTestCheque\createTestCheque
Самое веселое, что этот хардкод одинаков для всех возможных форматов. И перемешан с логикой. Так что если в вашей стране или банке принято использовать другой набор колонок или просто зазор между ними, придется изрядно кодить. Если нужно поддерживать несколько форматов в холдинге, кодить приходится в несколько раз больше.
Что характерно, сей код используется, как минимум, с версии 4.0. Создается впечатление, что это какая-то запатентованная методика создания отчетов, которой дорожат, а потому бережно переносят из версии в версию.

TasmanianDevil · 24.09.2012, 09:58

DAX2009, kernel/application 5.0.1500.6491
На источнике данных формы N edit-методов, возвращающих значение Enum'а NoYes. Выделяем эти методы и перетаскиваем на дизайн формы - часть контролов создались checkbox'ами, часть создалась radiobutton'ами. Удаление контролов и повтор этого действия дает аналогичную картину, только меняется распределение кому из методов достается checkbox, а кому radiobutton - некая лотерея.

Меняем возвращаемый тип для этих методов с закрытого NoYes на открытый NoYesCombo, у которого прямо прописан combobox как стиль контрола для отображения, и повторяем процедуру drag-n-drop'а методов с источника данных формы на ее дизайн - аналогичная картина.

EVGL · 24.09.2012, 18:07

Модуль управления цехом в русском исполнении изобилует изумительными перлами:
Название: StrangeDays.png
Просмотров: 2466

Размер: 5.0 Кб

N00b registration

S.Kuskov · 25.09.2012, 10:04

Это наверное больше для вот этой темы подходит Метка @xxx##### переведена на русский некорректно...

Evgeniy2020 · 18.10.2012, 14:16

Курьез.
Есть Axapta 3. Есть системная таблица AccessRightsLists.
До этого кто то добавил несколько (10-12) запретов (NoAccess) для группы прав 'Admin' на несколько SecurityKey с id = 1, 23, и т.д.

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

После чего решено было удалить эти несколько 10-12 записей для группы прав Admin из этой таблицы. Выделив эти записи в Обозревателе таблицы AccessRightsList и нажав Alt+F9, записи благополучно удалились.
при этом слетели все права для группы прав Admin.

При попытке зайти пользователем с правами 'Admin' на экране не отображалось главное меню и доступ ко всему был закрыт, включая АОТ. Вот такая оказалась опасная операция удаления записей из этой таблицы для группы прав.

Благодаря наличичую второй группы прав эквивалентных админским удалось восстановить полный доступ для группы Admin.