Итак, что есть: есть изнасилованный EDT ItemId. Автор вопроса сказал что надругались над ним до него и давно, плюс на это завязано много чего другого. Вероятнее всего на этот "харасмент" завязана и другая функциональность. Возможно, на это завязано много функциональности и переписывание может занять не мало времени. Пока что, автор вопроса просто натолкнулся на малозначительную багу в отчетах. Почему малозначительную см. ниже. Предлагается переписать все по нормальному...ну, а теперь варианты, при каких обстоятельствах "овладели" EDТ ItemId:
1. Это сделала компания внедрявшая проект, которую за это и еще пару сотен других, более серьезных, решений давным-давно изгнали, но тем не менее, функционал базирующийся на их "былинных" решениях работает в продакшене и с ним нужно жить.
2. Это сделал программист, который давно свинтил в другую компанию, так что, с него "взятки гладки", а вот автору вопроса с этим еще работать и поддерживать.
3. Это сделал Lead, который на это еще повесил треть функциональности проекта, идите, объясните ему что он не прав и стоит все переписать
Перед митингом не забудьте обновить профиль на hh.ру.
4. Сам автор облажался, да еще и заложил на эту идею много другого функционала, все уже успешно крутится на рабочем приложении, а тут такая ерунда вылезла.
Все это к тому, что кто готов на себя взять ответственность переписать существенную часть проекта? Кто будет отвечать, если убрав это решение свалится пол системы? Причем, падает обычно не на этапе тестирования, а уже когда все на продакшене и завтра нужна отчетность. Да, сделали ерунду, увы на нее серьезно заложились, но стоит ли ворошить, пусть и неидеальный, но хрупкий и непредсказуемый механизм!?! Я бы, крепко подумал, потому что если нет желающих взять, или хотя бы разделить, ответственность за попытку "правильного" решения сложившейся проблемы, то стоит ли на себя брать роль супермена из-за дурацкой недоделки вендора!?!
Почему я считаю этот drill-down недоделкой. Ну просто представьте себе формы без jumpRef или невозможность перекрывать lookup методы
То есть, Микрософт сделал "клевую доработку" движка отчетов который, с Датских времен, не трогал и все должны быть рады. ИМХО, эту штуку вообще нельзя показывать пользователям, потому что невозможность использовать ее действительно для расшифровки строк отчета вызовет массу вопросов. Так что, лучше особо не ориентироваться на её наличие, что бы предотвратить вопросы: "а пачему по документу ГК нельзя перейти к бух. проводкам, как это можно в форме N ?"
Таким образом, если объем доработок, связанных с EDT ItemId действительно большой, автору предлагаю забить на эту тему и сослаться на "негибкость" и не совместимость, с реальными условиями использования. Если же вопрос в исправлении кода в паре, тройке некритичных мест, тады конечно нужно вернуть EDT в норму.
p.s. Вот это да, буковок многа вышло. "Хиде кат"!?! Что бы эту простыню спрятать...