Ошибки в строках журнала ГК

[Ivanhoe]

DAX 2009 SP1 EE RU4.

Проблема №1.
Есть поле OffsetCompany в таблице LedgerJournalTrans - оно привязано к ключу LedgerAdvIntercompanyAccounting "Внутрихолдинговый учет".
Это поле участвует в Relations по полю OffsetAccount, предполагая, что для внутрихолдингового учета корр.счет может быть из другой компании.

Если ключик выключить, получаем ряд проблем при работе со строками журналов:

1.1. Неверно отрабатывает лукап по полю "Корр.счет" - для типов счета, явно не прописанных в классе LedgerJournalEngine.offsetAccountNumLookUp(): подотчетников, русских ОС и расходов будущих периодов. Делается фильтр по пустой компании - лукап пустой.

1.2. Неверно отрабатывает переход к основной таблице - для всех типов счетов, кроме явно прописанных в методе jumpRef() на поле датасорса: ГК, Клиент, Поставщик. Делается фильтр по пустой компании - в итоге форма пустая.

Исправление: убрать конфиг. ключ с поля, изменить метод InitValue в таблице, чтобы поле заполнялось всегда.

Проблема №2
Вызов некорректных форм лукапа для русских типов счетов.
1. По полю "Счет" если тип счета "Подотчетное лицо" - не вызывается форма EmplTableLookUp, хотя именно она используется в закупках, авансовых отчетах и т.п.
2. По полю "Корр.счет" если тип счета "ОС" (русские), "Расходы будущих периодов", "Подотчетное лицо" - не вызывается нужная форма (первые два типа - надо по аналогии с полем "Счет", а третье - см. п.1).

Исправление: добавить корректные вызовы в методы LedgerJournalEngine.offsetAccountNumLookUp() и accountNumLookup().

Возможны есть и другие решения проблем - пишите
P.S. запрос в MS постараюсь зарегистрировать.

[Daiver]

DAX 2009 SP1 EE RU6

Проблема №3

На таблице LedgerJournalTrans есть замечательные Relations в которых связывается поле LedgerJournalTrans.Company (OffsetCompany, ... ) и поле dataAreaId таблицы которая участвует в Relations.

К примеру рассмотрим поле LedgerJournalTrans.RContractAcountDebit. Для него не перекрыт (точнее вызывается super() если компании одинаковые) lookup на форме LedgerJournalTransDaily, но Рег.Номер договора пустой (договора у поставщика есть, и активные).
Справочник поставщиков и договоров находится в виртуальной компании. Компания в которой происходит создание строчки имеет доступ в таблице договоров, тут все нормально.

Если мы убираем связку LedgerJournalTrans.Company == RContractTable.dataAreaId в Relations RContractTableVend, то все работает нормально.

В DAX 4 SP2 FP1 EE все работает нормально при таких же связках и коде.
Мои кривые руки? Что не так?

[SRF]

А в dax 4.0 договоры тоже включены в виртуальную компанию ? (мне что то подсказывает что нет, поскольку тогда бы по логике вещей и в четверке не работало).

Проблема в том, что в случае когда договоры включены в виртуальную компанию, то dataAreaId у такой записи = 'код виртуальной компании', в то время как в поле company = 'код текущей компании', из за различий кодов компании и наличия relation по полям LedgerJournalTrans.Company = RContractTable.dataAreaId получаем пустой лукап.

P.S. Кстати, не работают и переходы к основной таблице из полей счет\корр.счет журналов ГК в случае, если справочники включены в виртуальную компанию(но от этой болезни, есть ряд хотфиксов от MS), а вот насчет исправления лукапов - не видел, видимо придется самим пока исправлять.

[Daiver]

Цитата:

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

А в dax 4.0 договоры тоже включены в виртуальную компанию ? (мне что то подсказывает что нет, поскольку тогда бы по логике вещей и в четверке не работало).

Проблема в том, что в случае когда договоры включены в виртуальную компанию, то dataAreaId у такой записи = 'код виртуальной компании', в то время как в поле company = 'код текущей компании', из за различий кодов компании и наличия relation по полям LedgerJournalTrans.Company = RContractTable.dataAreaId получаем пустой лукап.

P.S. Кстати, не работают и переходы к основной таблице из полей счет\корр.счет журналов ГК в случае, если справочники включены в виртуальную компанию(но от этой болезни, есть ряд хотфиксов от MS), а вот насчет исправления лукапов - не видел, видимо придется самим пока исправлять.

Да, в 4-ке договора тоже в виртуальной компании, при этом договора выбираются. Делал переход с данными DAX 4 SP2 FP1 EE --> DAX 2009 SP1 EE RU6.
С переходами к основной таблице тоже проблемы.

То есть выход один, дописывать самому lookup и jumpRef? Если не затруднит, может дадите ссылки на хотфиксы?

[SRF]

Ссылка вот Hot Fixes Released For Microsoft Dynamics AX 2009, (ссылка на CustomerSource), поиск по слову virtual, хотя по идее в rollup 6 все эти исправления должны были быть включены(мы вносили исправления еще в rollup 1 или 2).

Других способов кроме правки кода пока не знаю.

[Logger]

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

Аксапта кривой запрос выдаст и ничего не переименуется.

В общем криво ядро обрабатывает Relations когда есть связка по DataAreaID и таблица на которую ссылаются включена в виртуальную компанию. По крайней мере в 3-ке это так.