DAX4 Интеркомпани, ошибка разноски внутрихолдинговой накладной

[Raven Melancholic]

Еще наткнулись. Ка-то странно работает кэш (я про это уже писал, но тогда было только тестирование и как-то не зациклились на этой теме).
У нас в разных компаниях номенклатура ведет себя по разному (например, в производственной это спецификация с номенклатурной группой "Готовая продукция", в торговых домах это номенклатура с номенклатурной группой Товар, ну и т.п.). Поэтому справочник не общий, а в каждой компании свой (есть доработка по вводу и синхронизации определенных номенклатур, но суть не в этом). Так вот, простой код джоба:

itemId = 'ВентиляторWRW50/40';
intentTable = InventTable::find(itemId);
changeCompany('TRD')
{
   inventTableChg = null;
   select firstOnly inventTableChg where inventTableChg == itemId;
   ...
}

Думаете, что после переключения мы нашли номенклатуру в компании TRD? Сильно ошибаетесь. Возвращена номенклатура компании, в которой запустили джоб! Если в компании запуска не было поиска по этому номенклатурному номеру, то все нормально.
То же происходит если в разных компаниях номера складских лотов совпадают. Если после переключения компании искать складские операции по номеру лота, совпадающему с тем, что был выполнен ранее, то вернется ранее найденный лот.
Помогает включения в код запрет кэша:

itemId = 'ВентиляторWRW50/40';
intentTable = InventTable::find(itemId);
changeCompany('TRD')
{
   inventTableChg = null;
   inventTableChg.disableCash(true);
   select firstOnly inventTableChg where inventTableChg == itemId;
   ...
}

Если по номенклатуре это можно понять (есть кэширование), то по InventTrans что-то невнятное: у этой таблице CashLookup стоит NONE.
Такое впечатление, то кэш игнорирует компании. вобщем-то можно было бы отключить кэш DAX для всех таблиц (кэш MS SQL хорошо справляется со своей работой), но InventTrans не кэшируется DAX!
Так же понятно, что из-за этой проблемы следует стараться иметь для одних и тех же таблиц в разных компаниях разные уникальные идентификаторы. Но, в нашем случае, это возможно для InventTrans, но не интересно для InvntTable. Можно всегда добавлять disableCach, но в наших разработках мы так и делаем, но есть стандартный код!
PS: кстати, без использования disableCash Trasert MS SQL показывает, что к базе данных было только оно обращение, то есть цепочка: поиск в одной компании, changeCompany, поиск в другой компании того же значения обрабатывает DAx независимо от типа кэширования.

[Raven Melancholic]

Еще один момент. Правда это не ошибка, но непонятка.
В SalesLine и PurchLine для механизма Интеркомпани есть поле InterCompanyInventTransId по которому связаны строки заказа на покупки и заказа на продажу Интеркомпани. Но в классах, наследниках от TradeInterCompany поиск связанной строки почему-то происходит не по этим лотам, а по номерам строк.
Я, конечно, понимаю, что индекс, включающий номер строки является кластерным и когда требуется получить все данные строки он работает быстро (тем более, что в интерфейсе поле LineNum не представлено, а в методах InteCompanyMirror оно синхронизируется). Но, все-таки, во всех остальных местах связь идет по полю InterCompanyInventTransId, к тому же, индекс, включающий LineNumне уникальный, что позволяет при работе не из интерфейса, а из кода дублировать номера строк (кстати, в стандартном приложении бывает, что номер строки несколько раз бывает нулевым, правда это относится не к заказам на покупку-продажу, а складским журналам и журналам ГК).
Почему для классов, наследников TradeInterCompany сделано исключение из общего правила?