AXForum - Переход с 3.0 на 4.0. Мелкие пакости локализаторов...

AXForum (//axforum.info/forums/index.php)

- DAX: База знаний и проекты (//axforum.info/forums/forumdisplay.php?f=7)

Переход с 3.0 на 4.0. Мелкие пакости локализаторов...

В перечислимом типе ItemType в 3.0 Asset_RU (Основные средства) числился под значением 3. В 4.0 у Asset_RU значение 100.

Судя по тому, что после переноса данных с 3.0 в 4.0 номенклатура, у которой раньше тип номенклатуры был Основные средства отображается вообще без типа номенклатуры, семейство классов ReleaseUpdate* этой хитрости не обучена.

Править можно по факту ручками с помощью Функции\Смена типа номенклатуры (если номенклатурных единиц немного) ли путем написания джоба.

Также можно внести правки в код одного из классов ReleaseUpdate* еще до миграции (чтобы сделалось само).

Главное — не промазать. А то из номенклатуры ОС сделать можно, а из ОС номенклатуру назад штатными средствами — нет.

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

И что же мы видим в локализованной Аксапте?

Подробные результаты вскрытия (с детализацией до полей таблиц) в приложении.

Так, кажется свои слова "Вся буржуйская Аксапта" я в некоторой степени забираю назад...

Пройдемся сначала по расширенным типам.

BankAccountStatementNum
BankBillOfExchangeNum
BankCheckNumCreated
BankChequeNum
BankNegInstNum
BankPromissoryNoteNum
CzTaxCreditMemoNum_Cust
CzTaxDocumentNum_Cust
InventJournalReport_BOMReqId_RU
InventJournalReport_CountCollId_RU
InventJournalReport_LossId_RU
InventJournalReport_TransferId_RU
InventJournalReportId_RU
LicenseCardNum_RU
LicenseCardRegNum_RU
LicenseCardSeries_RU
LtTruckTrailerNum
PBADisplayRouteJobPayType
PrintoutJournalNum_CustInvM15_RU
RAssetAdjustmentNum
RAssetInferiorDisposalNum
RAssetInventoryNum
RAssetStandardId
RAssetStandardIdAc
RAssetStandardIdDefault
RAssetTransferNum
RCashDocCorrectionId
RCashDocDisbSlipId
RContractAccount
RContractAccountActive
RContractAccountCust
RContractAccountVend
RDeferralsBookId
RDeferralsId
SortingStringRight

Считать лень, но навскидку примерно 85 процентов нарушений доктрины — это локализация, из которых процентов 80 — это русская локализация.

У нас "свои методы".

Еще одно развлечение для разработчиков при выполнении работ по переносу модификаций с 3.0 на 4.0. Хотя, конечно, можно оставить и так...

Литература:
http://axapta.mazzy.ru/lib/adjustment/

По поводу ItemType::Asset_RU, только что посмотрел в Axapta 3.0 SP4 имеет значение 100. С более ранних SP четверка не должна апдейтиться.

Спасибо.

Писал по памяти. Действительно, в сп3 еще было 3, а в поздних версиях — 100.

А насчет того, что с более ранних СП апгрейд запрещен — это официальная информация или подпольная? Это касается русской или буржуйской версии?

Эта информация _должна_ быть официальной.
Касается только версии Axapta 4.0 SP1 Eastern Europe, куда входит и Россия.

Ладно. Будем искать.

Задался вопросом, почему в 3.0 сп5, откудова я апгрейдил данные, тоже для номенклатур-ОС тип номенклатуры не заполнен у меня, оказывается.

Пока не нашел и следа кода, который бы менял 3 на 100.

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

А у кого-то был успешный опыт автоматического обновления типа номенклатуры при апгрейде?

А есть какие-либо аналогичные "чудеса" во всенародно "любимом" модуле ОС ?

Еще про мелкие пакости: есть ряд элементов, где программисты забыли проставить конф. ключи. Результат налицо: отключаем все вост.-европейские ключи, запускаем под языком DE или EN-GB, а формы и меню пестрят метками типа "@GEE167346". Клиент в недоумении.

Изменения в лукап-форме выбора ODBC источников

Расширенный тип OdbcDsn_RU - лукап форма у него OdbcDsnLookUp_RU. Так вот, насколько я могу судить, она некорректно работает.

метод close() неправильный - переменная iIndx используется до инициализации выбранным значением, соответственно, вылетает, так как listView.getItem(iIndx) возвращает null.
Максимальный размер описания источника - 261 символ, но в коде у них стоит 40, и описания обрезаются. Более того, от этого значения магическим образом зависит результат выполнения АПИ. К примеру, при значении 40 функция возвращает 1, а при значении 60 - 0. Я не копался, в чем там дело, Но при значении 261 вроде бы все корректно. Соответственно, изменил также свойства ширины формы и колонок ListView

В приложении измененная форма.

Есть в Аксапте функциональность журналов пакетных заданий. Если кто не знает, то Основное\Настройки\Пакет\Типы журналов и Основное\Настройки\Пакет\Наименования журналов, а также Основное\Периодические операции\Пакет\Обработка журнала пакетных заданий (и в поиске можно посмотреть, про них писали).

Так вот при открытии формы типов журналов пакетных заданий в 4.0 вываливается следующее информационной сообщение.

Класс RAssetAdjustmentPost не имеет метод description.
Класс RAssetInventoryPost не имеет метод description.
Класс RAssetScrapCalcPrice не имеет метод description.
Класс RAssetTransferPost не имеет метод description.
Класс RAssetTransferPost_Both не имеет метод description.
Класс RAssetTransferPost_CompanyIssue не имеет метод description.
Класс RAssetTransferPost_CompanyReceipt не имеет метод description.
Класс RAssetTransferUnPost_Both не имеет метод description.
Класс PurchFormLetter_Facture_RU не имеет метод description.
Класс SalesFormLetter_Facture_RU не имеет метод description.
Класс RAssetInferiorDisposalPost не имеет метод description.
Класс PurchFormLetter_SadInvoice_PL не имеет метод description.
Класс CustInterestCreate_PL не имеет метод description.
Класс PlCustInvoiceJourEditTax не имеет метод description.

Для чего в классах RAsset* потребовалось устанавливать параметр возможности их включения в журнал пакетной обработки, если из интерфейса их в пакетном режиме не запустишь, я пока не понял. Впрочем, создание метода description() для этих классов тоже лишним не было бы.

Лечится добавлением description() для классов. Это если пользоваться принципом "the way of least resistance" (путем наименьшего сопротивления). По-хорошему для классов имеет смысл отключить возможность запуска в журнале пакетной обработки.