Некорректный drilldown на поле отчета

[Paul_ST]

Dynaimics 4.0
Проблема:
Формируем отчет InventOnHand. Правая кнопка мыши на поле номенклатуры - возможен переход к справочнику.
Как только модифицируем EDT ItemId (добавим ограничение на какое-нибудь дополнительное поле), AX пытается осуществить переход по MenuItem InventJournalTrans, который не существует. Выбрасываетс соответсвующее сообщение об ошибке. На таблице InventSum есть Reltion на InventJournalTrans по полю ItemId, очевидно он "сбивает" AX с толку.

Все попытки поиграть с Relations на таблицах InventTable, InventSum (равно как и найти подходящие методы для переопределения) не принесли успеха.
Как можно решить проблему?
Спасибо!

[miklenew]

Цитата:

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

добавим ограничение на какое-нибудь дополнительное поле

А что это такое?

[Paul_ST]

Попробую объяснить еще раз другими словами:
сформировали отчет (InventOnHand). Не закрывая окно отчета, кликаем правой кнопкой на идентификаторе номенклатуре в какой-либо строке (т.е. на поле InventSum.ItemId) - всплывает маленькое контекстное меню, в котором один пункт - переход к справочнику для текущей номеклатуре, по которой ткнули мышкой. Это и есть drilldown.
Проблема в том, что если изменить EDT ItemId, добавив там еще какое-нибудь ограничение (Relation) на какое-нибудь поле таблицы InventTable, то АХ не может больше произвести описанный выше drilldown (а пытается применить Relation таблицы InventSum для InventJournalTrans и естественно обламывается, сообщая об ошибке).
Не получилось найти, что нужно сделать для того, чтобы восстановить эту нехитрую фишку перехода из отчетов.

[Bober]

Цитата:

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

Проблема в том, что если изменить EDT ItemId...

Ответ содержится в постановке вопроса. Этим вы действительно создаете проблему. Не нужно НИКОГДА так поступать с ItemId.

[miklenew]

Цитата:

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

Проблема в том, что если изменить EDT ItemId, добавив там еще какое-нибудь ограничение (Relation) на какое-нибудь поле таблицы InventTable.

Это называеться не ограничение, а связь.
На ItemId???
Если нужно изменить связь создавайте новый EDT, можно даже наследник от ItemId.
А ItemId не трожьте. Много мест поламаете.
Пусть у вас в отчёте InventOnHand, появился список номенклатур.
Ном1
Ном2
Ном3... и т.д.
Кликая на ном2 куда бы вы хотели попасть?
Разве не в справочник номенклатур на эту номенклатуру?

[ZVV]

Цитата:

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

Попробую объяснить еще раз другими словами:
сформировали отчет (InventOnHand). Не закрывая окно отчета, кликаем правой кнопкой на идентификаторе номенклатуре в какой-либо строке (т.е. на поле InventSum.ItemId) - всплывает маленькое контекстное меню, в котором один пункт - переход к справочнику для текущей номеклатуре, по которой ткнули мышкой. Это и есть drilldown.
Проблема в том, что если изменить EDT ItemId, добавив там еще какое-нибудь ограничение (Relation) на какое-нибудь поле таблицы InventTable, то АХ не может больше произвести описанный выше drilldown (а пытается применить Relation таблицы InventSum для InventJournalTrans и естественно обламывается, сообщая об ошибке).
Не получилось найти, что нужно сделать для того, чтобы восстановить эту нехитрую фишку перехода из отчетов.

Очевидно, вы завели в InventTable какой-то признак, и теперь у вас там есть "нормальные номеклатуры" (которыми вы хотите ограничить ItemId) и "остальной шлак"? Так?
Тогда вы сделали неправильно. Заведите отдельные типы-наследники ItemId, и у каждого из них укажите соответсвующие связи. А ItemId трогать не стоит...

[Paul_ST]

Проблематика понятна, спасибо!
Проблема конечно же в том, что ItemId описанным образом модифицировали до меня и изменить это будет скорее всего уже проблематично (придется в нужных местах заменять ItemId на созданных наследников).

Все же остается вопрос - можно ли с помощью каких-либо специальных классов и методов "подсунуть" АХ нужный MenuItem, через который она открывает форму, когда осуществляется переход из отчета к справочнику? На контролах форм есть ведь великолепный метод jumpRef().

[miklenew]

Цитата:

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

Проблема конечно же в том, что ItemId описанным образом модифицировали до меня и изменить это будет скорее всего уже проблематично (придется в нужных местах заменять ItemId на созданных наследников).

Вам главное задачу решить?
А за проект кто биться будет?
Блин, кто же такую шляпу вам подложил.
Поверьте легче сейчас это исправить. Чем каждый раз оправдываться что здесь и здесь сыпится, потому что виноват тот кто был до.
Найдите ТЗ по которому это модификация делалась и сделайте как надо.
Черпайте вдохновение из народной мудрости:
Раз. Глаза боятся, а руки делают.
Два. У страха глаза велики.
И т..д.

[DSPIC]

Цитата:

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

Проблематика понятна, спасибо!
Проблема конечно же в том, что ItemId описанным образом модифицировали до меня и изменить это будет скорее всего уже проблематично (придется в нужных местах заменять ItemId на созданных наследников).

Все же остается вопрос - можно ли с помощью каких-либо специальных классов и методов "подсунуть" АХ нужный MenuItem, через который она открывает форму, когда осуществляется переход из отчета к справочнику? На контролах форм есть ведь великолепный метод jumpRef().

Похоже, что так, как нам бы хотелось - нельзя

http://msdn.microsoft.com/en-us/library/bb314839.aspx

[Lemming]

Итак, что есть: есть изнасилованный EDT ItemId. Автор вопроса сказал что надругались над ним до него и давно, плюс на это завязано много чего другого. Вероятнее всего на этот "харасмент" завязана и другая функциональность. Возможно, на это завязано много функциональности и переписывание может занять не мало времени. Пока что, автор вопроса просто натолкнулся на малозначительную багу в отчетах. Почему малозначительную см. ниже. Предлагается переписать все по нормальному...ну, а теперь варианты, при каких обстоятельствах "овладели" EDТ ItemId:

1. Это сделала компания внедрявшая проект, которую за это и еще пару сотен других, более серьезных, решений давным-давно изгнали, но тем не менее, функционал базирующийся на их "былинных" решениях работает в продакшене и с ним нужно жить.

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

3. Это сделал Lead, который на это еще повесил треть функциональности проекта, идите, объясните ему что он не прав и стоит все переписать Перед митингом не забудьте обновить профиль на hh.ру.

4. Сам автор облажался, да еще и заложил на эту идею много другого функционала, все уже успешно крутится на рабочем приложении, а тут такая ерунда вылезла.

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

Почему я считаю этот drill-down недоделкой. Ну просто представьте себе формы без jumpRef или невозможность перекрывать lookup методы То есть, Микрософт сделал "клевую доработку" движка отчетов который, с Датских времен, не трогал и все должны быть рады. ИМХО, эту штуку вообще нельзя показывать пользователям, потому что невозможность использовать ее действительно для расшифровки строк отчета вызовет массу вопросов. Так что, лучше особо не ориентироваться на её наличие, что бы предотвратить вопросы: "а пачему по документу ГК нельзя перейти к бух. проводкам, как это можно в форме N ?"

Таким образом, если объем доработок, связанных с EDT ItemId действительно большой, автору предлагаю забить на эту тему и сослаться на "негибкость" и не совместимость, с реальными условиями использования. Если же вопрос в исправлении кода в паре, тройке некритичных мест, тады конечно нужно вернуть EDT в норму.

p.s. Вот это да, буковок многа вышло. "Хиде кат"!?! Что бы эту простыню спрятать...

[miklenew]

Если предположить, что у них самая самая страшная ситуация, которая может быть.
И людей внутри с необходимой квалификацией нет, чтоб это исправить.
Значит надо обращаться в консалтинг. Чтоб они помогли.
Архитектура должна быть правильной. Именно с этой точки зрения я давал совет.
Представьте проект длится года три с подобным косяком, люди работают, получают деньги, затыкают дыры.
А прейдет время сотрудничать с внешними исполнителями или перейти на другую версию. И что с этой прилагой делать?
Был на одном проекте.
Навояли на таблицу номенклатур свой функционал.
Пришёл консалтинг.
Какой функционал не знаю, куратор сказал, что для этого функционала нельзя было использовать эту таблицу. И ужится не получится.
Ну и понятно чтоб не ...ться, а давайте сдублируем все стандартные таблицы, которые они использовали и переправим их функционал на них.
Гемору был много. Я так и не знаю, чем эта история закончилась (ушёл из консалтинга, не из-за задачи).
В общем, слабость в таких вопросах проявлять нельзя.
Иначе потомки вам этого не простят. Или признают ламерами и выкинут годы вашей работы в корзину. А там может есть очень очень замечательные вещи.
PS: Коготок увяз всей птичке пропасть.

[DSPIC]

Будьте осторожны в советах и действиях по изменению мира к лучшему

Пусть исправления будут корректны, и не нарушат работоспособности системы... но при первом чихе пальцем могут указать на вас: а вот он чего-то там корректил; поди потом докажи, что это не ты все поломал...

P.S. При подобных, рвениях меня часто тормозили фразой: "Нам за это не платят."

[miklenew]

Цитата:

СОФИСТИКА - рассуждение, основанное на преднамеренном нарушении законов логики

Заниматься рассуждением основанном на преднамеренном нарушении законов архитектуры (а именно в это тема сейчас уходит) мне совсем не хочется.
Я свою точку зрения высказал. Если у автора есть вопросы, задаст. Поясню.
Lemming тоже чётко высказался. Хоть в его позиции и много допущений.
Если автор захочет, начнёт капать, не захочет - не начнёт.
Дальше желание над вопросом работать будет - хорошо, не будет ну что ж это его решение.
Если бы моё мнение не озвучил никто, это было бы по меньшей мере странно.