Отправьте баги в Майкрософт

[glibs]

В АОТе в табличке можно в группу полей затащить drag and drop-ом табличный display метод.

Удобненько.

Но если имя display метода совпадет с именем поля, то в результате drag and drop-а в группу полей добавится поле. Даже если добросовестно тащить туда display метод.

[lev]

Axapta 3.0 SP3
Конечно это не так уж прям и бага, но иногда очень раздражает (может в четверке и выше исправили, не знаю).
Иногда (не всегда, но частенько бывает), при переносе drag & drop, menuItem в menu, которые находятся В ОДНОМ ПРОЕКТЕ (ключевое слово в одном проекте, при переносе в АОТе такого не замечал) падает аксапта!

[raz]

Цитата:

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

Axapta 3.0 SP3
Конечно это не так уж прям и бага, но иногда очень раздражает (может в четверке и выше исправили, не знаю).
Иногда (не всегда, но частенько бывает), при переносе drag & drop, menuItem в menu, которые находятся В ОДНОМ ПРОЕКТЕ (ключевое слово в одном проекте, при переносе в АОТе такого не замечал) падает аксапта!

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

[glibs]

На страничке

https://mbs.microsoft.com/partnersou...rintpage=false

ссылка

https://mbs.microsoft.com/downlolads...Paper_Cash.pdf

(Касса (1.5 MB - .pdf))

битая. Вроде.

[glibs]

А почему при создании кредит-ноты по заказу на покупку у поставщика несмотря на то, что в форме создания кредит-ноты стоят галки копирования заголовка и точного копирования в шапку сторно-закупки не переносится номер договора?

Помнится, таким болело обычное копирование давно (в 3.0). Но там сделали как положено.

[ZVV]

Цитата:

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

А почему при создании кредит-ноты по заказу на покупку у поставщика несмотря на то, что в форме создания кредит-ноты стоят галки копирования заголовка и точного копирования в шапку сторно-закупки не переносится номер договора?

Помнится, таким болело обычное копирование давно (в 3.0). Но там сделали как положено.

Да нет, и в тройке было тоже самое, вроде...
Банально не копируются договора в коде purchTable.initFromVendInvoiceJour()...

[glibs]

Да, спасибо. Это я путаю. Обычное копирование строк из накладной не работает и в 4.0.

[Raven Melancholic]

Шаблоны записей компании.
Понадобилось настроить в пустой базе некоторое количество шаблонов номенклатуры для того, чтобы пользователи уже по готовым шаблонам ввводили в дальнейшем номенклатуру. В справочнике номенклатуры создал записи, на их основе через паспорт записей создал шаблоны компании. Проверил и немного подкорректировал шаблоны и записи из справочника удалил. Захожу в форму изменения любого шаблона, а она пустая! Более того, данные в соответствующем поле таблицы SysRecordTemplateTable для шаблонов, которые открывал удалены.
Выяснилось, что очистка производится в методе initValue класса SysRecordTemplate. Для таблицы InventTable все нормально, а для трех записей таблицы InventTableModule и одной записи таблицы InventItemLocation код:

if (!excludeValidateField.in(fieldId) && !common.validateField(fieldId))
{
        doClear = true;
        common.(fieldId) = nullValue(conpeek(valueSet, 2));
}

очищает поле ItemId, что естественно, так как common.validateField(fieldId) не проходит проверку из-за того, что в таблице InventTable нет соответствующей записи (в форме редактирования шаблона эта таблица временная).
Конкретно для номенклатуры по аналогии с таблицей EventRuleData для InventTableModule и InventItemLocation добавил поле ItemId в excludeValidateField. Грубо, но работает. Только вот как определить все варианты для других шаблонов непонятно.

[petr]

DAX 5.0.

В печатной форме подтверждения заказа (Sales confirmation -> AOT/Reports/SalesConfirm), в методе fetch() "забыто" изменение значения переменной hasReportBeenPrinted на true, т.е. выделенная скобками bug-fix строчка.

boolean  fetch()
{
    QueryRun    tradeLoopTrans;
    boolean     hasReportBeenPrinted = false;

    setprefix(this.design().caption());

    while (custConfirmJour)
    {
        setprefix(strfmt("@SYS70899", custConfirmJour.ConfirmId));

        .....
        while (salesFormLetterReport.moveNextPrintSetting())
        {
            ....
            if (salesFormLetterReport.checkNextPrintSetting())
            {
                element.reset(true);
            }
        }

        // All printing must be done in the context of the fetch() method and not
        // in the print() method. This ensures printing errors are associated with the
        // appropriate documents.
        element.reset(true);
        
        // Bug-fix -->
        hasReportBeenPrinted = true;
        // Bug-fix <--

        // The journalList is used when printing is delayed until after all posting is complete.
        if (!journalList.next(custConfirmJour))
        {
            break;
        }
    }

    // If the report has been printed, return false to indicate the print method should not be run
    return (!hasReportBeenPrinted);
}

Из-за этого при печать данного документа всегда выдается инфолог с сообщение, что отчет не содержит данных. Если посмотреть на код метода fetch в аналогичных документах (напримера накладная, AOT/Reports/SalesInvoice), то понятно как эту ошибку можно исправить.

В SP1 проблема не решена.

[kashperuk]

Цитата:

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

DAX 5.0.

В печатной форме подтверждения заказа (Sales confirmation -> AOT/Reports/SalesConfirm), в методе fetch() "забыто" изменение значения переменной hasReportBeenPrinted на true, т.е. выделенная скобками bug-fix строчка.

boolean  fetch()
{
    QueryRun    tradeLoopTrans;
    boolean     hasReportBeenPrinted = false;

    setprefix(this.design().caption());

    while (custConfirmJour)
    {
        setprefix(strfmt("@SYS70899", custConfirmJour.ConfirmId));

        .....
        while (salesFormLetterReport.moveNextPrintSetting())
        {
            ....
            if (salesFormLetterReport.checkNextPrintSetting())
            {
                element.reset(true);
            }
        }

        // All printing must be done in the context of the fetch() method and not
        // in the print() method. This ensures printing errors are associated with the
        // appropriate documents.
        element.reset(true);
        
        // Bug-fix -->
        hasReportBeenPrinted = true;
        // Bug-fix <--

        // The journalList is used when printing is delayed until after all posting is complete.
        if (!journalList.next(custConfirmJour))
        {
            break;
        }
    }

    // If the report has been printed, return false to indicate the print method should not be run
    return (!hasReportBeenPrinted);
}

Из-за этого при печать данного документа всегда выдается инфолог с сообщение, что отчет не содержит данных. Если посмотреть на код метода fetch в аналогичных документах (напримера накладная, AOT/Reports/SalesInvoice), то понятно как эту ошибку можно исправить.

В SP1 проблема не решена.

Уже пофиксили. Спасибо

[raz]

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

Воспроизводится так:

На форме SalesTable у датасорса SalesTable меняем активный индекс на CustIdx.
Потом открываем форму и пробуем перейти к основной талице по какому нибудь заказу (на поле заказ через контекстное меню)...

ЗЫ. AX3 SP4 KR2

[kashperuk]

Цитата:

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

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

Воспроизводится так:

На форме SalesTable у датасорса SalesTable меняем активный индекс на CustIdx.
Потом открываем форму и пробуем перейти к основной талице по какому нибудь заказу (на поле заказ через контекстное меню)...

ЗЫ. AX3 SP4 KR2

Кх-кх. А что именно происходит? И что должно происходить?
У меня переходит, к тому заказу, на котором переходил

[raz]

Цитата:

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

Кх-кх. А что именно происходит? И что должно происходить?
У меня переходит, к тому заказу, на котором переходил

Ну должен переходить, к тому заказу, на котором переходил, однако переходит к другому.

Проверил на чистой AX3 SP4 KR2 и на DAX4.0.2501.116 APP4.0.2501.122


ЗЫ. Открыл чистый DAX4.0.2501.116 APP4.0.2501.122 с демоданными.
Форма CustTable, на датасорсе CustTable поменял индекс на PhoneIdx.
При переходе попадаю на другого клиента.

Тестовую запись, с которой делать переход, конечно выбираю из середины списка.

[Logger]

Цитата:

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

Форма CustTable, на датасорсе CustTable поменял индекс на PhoneIdx.
При переходе попадаю на другого клиента.

Если это сильно напрягает то можно внутри формы анализировать Element.args().lookupValue(), Element.args().lookupField() и если заполнены, то сбрасывать сортировку на стандартную. Все равно при таком переходе сортировка не так важна, важно попасть на нужную запись.

[Dron AKA andy]

Есть такая "особенность", уже обсуждалась на форуме.

[kashperuk]

Это особенность использования lookupValue(), который юзается для переход к основной таблице.
он там хитро запрос строит, и из-за того, что сортировка идет в другом порядке, получается, что сбивается ожидаемый порядок..

[glibs]

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

Формы CustTransOpen и VendTransOpen не доделаны. Первую в 5.0 слегка починили (в 4.0 грид с открытыми проводками не меняет свой размер при изменении размера формы), но грид со скидками по оплате не меняет свой размер при изменении размера формы до сих пор. Вторая форма вообще не хочет менять свой размер.

[glibs]

АОТ\Data Dictionary\Base Enums\OriginalDocument

Пункт 7, "Purchase".

Метка "@SYS23989" — "Requisition", "Заявка" некорректна, т.к. речь идет о заказе на покупку.

[glibs]

АОТ\Data Dictionary\Tables\CustInvoiceJour\Methods.origInvoiceId_PL()

Ощутимо подтормаживает на непустой но и весьма слабо заполненной базе.

Метод вызывается при открытии списка накладных клиентов (РК\Запросы\Журналы\Накладные).

Самому вникать в суть пока лень, но может есть способ оптимизировать производительность формы.

[gl00mie]

Цитата:

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

АОТ\Data Dictionary\Tables\CustInvoiceJour\Methods.origInvoiceId_PL()
Ощутимо подтормаживает на непустой но и весьма слабо заполненной базе.
Самому вникать в суть пока лень, но может есть способ оптимизировать производительность формы.

Как вариант, на CustInvoiceTrans выставить CreateRecIdIndex == Yes - в этом случае план запроса получается очень "дешевым":