D365FO, AX2012: Паспорт записи списком (поля списком) - расширение

[sukhanchik]

Добрый день! Решил я расширить всем известную функциональность, которая изначально пришла из DeveloperTools от компании Columbus (первый автор - Роман, db) и которую выложил Денис (trud) в рамках проекта DEVTools (https://github.com/TrudAX/XppTools/t.../DEVRecordInfo).

Здесь описывается версия для D365FO.
Версия для AX2012 ниже, в следующем сообщении
В рамках расширения добавлено:

• Возможность правки складских аналитик (перевычисление InventDimId). Поле InventDimId вычисляется по Relation-у к таблице InventDim на исходной таблице
• Позиционирование на нужном InventDimId, если паспорт записи открывается с поля таблицы InventDim (Т.е. из аналитик В в строке журнала переноса мы автоматически попадаем на InventJournalTrans.ToInventDimId, а с аналитик Из - на InventJournalTrans.InventDimId). Т.о. сразу исключается попадание на таблицу InventDim (чтобы не было желания ее править)
• Объединение кнопок ChangeValue и ChangeValueDim для финансовых аналитик. Теперь система сама догадывается (по Relation-у) - что из себя представляет текущее поле (складские аналитики или финансовые). Функциональность правки (перевычисления кода комбинации) финансовых аналитик осталась такой же.
• Возможность правки значений полей, представленных на форме сегментированным контролом. При этом, если паспорт записи был запущен с самого контрола, то наследуются свойства контрола (отображение счета ГК с аналитиками или без аналитик, а также в зависимости от типа счета, как в журнале ГК). Если паспорт записи был запущен не с самого контрола, то поведение контрола, в котором можно изменить значение - устанавливается в зависимости от расширенного типа поля: для типа LedgerDimensionDefaultAccount и его наследников устанавливается режим отображения счета ГК без аналитик; для типа DimensionDynamicAccount и его наследников устанавливается режим отображения счета ГК в зависимости от типа счета (тип счета жестко определен - это енум LedgerJournalACType). Если в списке полей отсутствует поле с енумом LedgerJournalACType, то сегментированный контрол не отображается и текущее поле представляет собой просто значение RecId. Важно! Именно поэтому для правки корсчета в журнале ГК важно это делать именно с контрола, поскольку иначе определится тип счета для поля Счет, что неверно. Во всех остальных случаях (т.е. когда расширенный тип поля не наследуется ни от LedgerDimensionDefaultAccount ни от DimensionDynamicAccount) - отображается счет ГК с аналитиками.
• Поля с дополнительной информацией о типе данных поля (длина строки и ссылка на связанное поле в другой таблице, например для поля Сотрудник будет выведена информация HcmWorker.RecId)
• Перемещение полей с дополнительной информацией в грид.
• Кнопка скрытия / отображение полей с дополнительной информацией по типам данных поля (Show types / Hide types)

Код писался в рамках моего ответвления этой утилиты (в свое время мне ее дали без кнопки Change value и сказали сделать возможность правки - ну я и сделал эту возможность напрямую в гриде с использованием лукапа. А потом выяснилось - что "нормальные пацаны" делали кнопку). В связи с этим доработки переносились в стиле устранения фатального недостатка.






Прилагаю архив модели. В ней изменена только форма и таблица.

[sukhanchik]

До кучи выложу это же расширение, но адаптированное под AX2012.
Разница есть достаточно существенная в части обработки сегментированного контрола и финансовых аналитик.

Имеются следующие ограничения:
Как я писал выше - мне эта форма досталась без кнопки Change value и автор (db) мне сказал сделать возможность правки данных, которую я сделал через редактирование грида и лукапа. И я бы может и не стал бы развивать эту версию, если бы совершенно случайно на одном из клиентов не увидел бы именно свою версию утилитки (что было невероятно приятно увидеть знакомые мне комментарии в коде). Поэтому здесь правка аналитик реализована через кнопку лукапа у поля FieldValue
Для сегментированного контрола (в отличие от D365FO) нет возможности узнать - какой контроллер его обрабатывал (счет ГК без аналитик, с аналитиками или динамический по типу счета). Поэтому приходится ориентироваться только на расширенный тип поля и рассчитывать, что он соответствует используемому контроллеру в коде.
Как следствие - если в записи используется 2 сегментированных контрола - то система сама не угадает, в каком поле содержится нужный тип счета (пример - строка ЖГК, поля Счет и Корсчет). Пришлось конкретно этот пример "в лоб" прописать в коде.
Как следствие - система полагается, что тип счета - это енум LedgerJournalACType. Случаи, где это не так - придется в явном виде допрописывать в коде.
Для финаналитик (DefaultDimension) также я использую контроллер по умолчанию - т.е. без счета ГК. Опять-таки отдельные ситуации могут потребовать отдельного программирования.
Редактирование в гриде работает только, если не скрыта группа полей Редактирование данных. Если группа скрыта (свёрнута) -редактирование запрещается.
При сравнении разных записей есть возможность отфильтроваться только по различным строкам.

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