Косяк в логике работы формы DimensionsLookup

[gl00mie]

На работе возникла относительно привычная, думаю, ситуация с кодами аналитик: какие-то коды, например, подразделений (отделов) уже неактуальны, в связи с чем необходимо заблокировать возможность их дальнейшего ввода и не показывать их в lookup'ах. Для этого в таблицу аналитик был добавлен признак, по которому аналитика считается неактивной. Чтобы реализовать описанные изменения, есть простое, ясное и неправильное решение: поменять relation на соотв. EDT, добавив тип связи "поле ссылки фиксировано" и прописать там, что означенный признак активности для записи в таблице аналитик должен иметь нужное значение. Неправильным такое решение видится потому, что оно автоматически делает старые проводки с неактивными кодами аналитик некорректными, о чем будет постоянно ругаться какая-нить проверка целостности данных, да и в исходной постановке задачи говорится лишь о том, чтобы нельзя было вводить неактивные коды в новые проводки. Но это так, небольшая вводная...
В общем, начал я разбираться с lookup'ами для кодов аналитик, в частности, с работой формы DimensionsLookup, прописанной в качестве FormHelp для EDT SysDim. Что же может быть интересного в lookup'е для кодов аналитик? Кроме того, что в ряде случаев (в проводках по ГК, например) этот lookup должен брать данные из другой компании, еще существует такая вещь, как всякие уровни проверки кодов аналитик при разноске по счету ГК (см. Главная книга/План счетов, закладка Аналитика, группа Обязательная аналитика и соотв. Контрольные списки). Т.е. можно прописать в настройках счета ГК, что такая-то аналитика (Отдел, к примеру) по данному счету может быть не абы какая, а строго из указанного списка, либо вообще можно жестко задать определенное значение кода аналитики. Форма DimensionsLookup такие тонкости пытается учитывать и показывать лишь допустимые для того или иного бух.счета коды аналитик; другое дело, что усердствует она в этом более, нежели необходимо (как вариант, можно вспомнить модель ленивого программиста), во всяком случае, я нашел один косяк в логике ее работы.
Итак, если выполняются определенные условия, а именно:

1. таблица - не LedgerJournalTrans
2. в таблице определено поле с названием AccountNum, OffsetAccount, либо LedgerAccount (интерес в данном случае представляет лишь AccountNum)
3. в таблице определено поле(поля) для указания кодов аналитик
4. в записи таблицы, для которой вызывается lookup для кода аналитики, установлено значение поля AccountNum, OffsetAccount, либо LedgerAccount
5. на форме, с помощью которой устанавливается значение кода аналитики для записи из такой таблицы, в качестве lookup-формы вызывается (явно или неявно) форма DimensionsLookup; это происходит, например, если EDT поля (полей) аналитик из условия 3) унаследован от SysDim
6. в плане счетов для определенного счета настроено допустимое значение или список допустимых значений кодов определенной аналитики или аналитик (для режима проверки "Список", "Таблица", "Фиксировано")
7. самое главное, значение в поле с названием AccountNum/LedgerAccount/OffsetAccount совпадает с бух.счетом (а что, имеем же мы право завести, скажем, клиента с кодом "50.100")
8. lookup вызывается для того кода аналитики, для которого реализованы настройки в плане счетов в соотв. с условием 6)

так вот, если выполняются эти условия, то в lookup'е кода аналитики будут показаны лишь те коды, которые настроены как допустимые для "одноименного" бух.счета, хотя, очевидно, связи между исходной таблицей и планом счетов может не быть абсолютно никакой, и в поле с названием AccountNum может быть что угодно, скажем, код клиента/поставщика, а вовсе не код бух.счета...
Косяк кроется в методе useSelectableLookup() (для AX3) либо getLookupType() (для AX4) формы DimensionsLookup, точнее в "эвристическом" алгоритме получения значений accountNum/offsetAccount, использующем в качестве критерия поиска определенные названия полей. Единственное, что извиняет эту форму, - что она при этом не прячет дополнительную закладку с неотфильтрованным списком аналитик.
Проверено на AX 3.0 SP3, AX 4.0 SP1