Прошу каким-нибудь способом снять ограничение на использование в вычисляемых полях параметров из разных веток дерева параметров, доступных для использования в отчетах.
Вы пытаетесь “прикрывать” это ограничение дублируя многократно одни и те же параметры в в разных ветках дерева, но это только усложняет работы с отчетами.
Сейчас столкнулся с тем, что нужно “смешивать” в вычисляемых полях атрибуты объекта учета и параметры выделенных веток.
Это ограничение компонента редактора отчетов. Мы обратимся к разработчикам редактора отчетов с этим вопросом.
А почему не использовать решение предложенное в примере ‘Использование в вычисляемых полях данных из разных узлов’?
Использую, но скрипты сильно увеличивают время создания шаблонов. А так как клиентов много, то время - это важный параметр.
И каждый обходя скриптами это ограничение раз понимаешь, что это неестественно так работать с данными.
Хотелось бы понять, почему это “ограничение DevExpress” является препятствием до сих пор. Вот мое последнее сообщение на эту тему
Могу добавить, что при работе со сводными отчетами такой проблемы нет, это ограничение влияет на работу только в ведомости параметров. Отличие этих видов отчетов в том, что в сводном все дерево данных имеет 1 корневой узел и это удачное решение при работе с DevExpress
, а в ведомости Вы так не сделали, у Вас аж 12 корневых узлов и это, по-моему, не удачное решение.
При этом наличие определенных корневых узлов не вытекает, вроде, из логики связности данных друг с другом или удобства использования.
Например, выделенные на картинке корневые узлы содержат измеренную информацию и часто дублируют друг друга, а часть информации вообще 3 раза содержится в дереве данных.
Данные в узле “Нормативные месячные температуры для территории” получается либо можно просто показать, либо использовать только через скрипты.
Похоже, такая структура сложилась исторически и вытекала из удобства реализации, а не пользования.
Т.е. текущие ограничения на операции с разными данными в ведомостях параметров (самой популярный тип отчета в ЛЭРС Учет) это не “ограничение DevExpress”, это следствие выбранной Вами модели данных.
И устранение этого неудобства - тоже Ваших рук дело. Самый экстремальный - просто продублируйте все данные в 1 дополнительный 13-ый ( :-): ) корневой узел. Не знаю как это скажется на быстродействии формирования отчетов - Вам виднее.
Сделайте конвертеры для шаблонов, чтобы правили ссылки, при необходимости. Лет через 5 наверное можно удалить прочие узлы - если будут мешать, а может и не будут мешать.
Но повторюсь. То что я предлагаю, не единственный способ.
Важно, что это ограничение, сдерживает использование ЛЭРСа, т.к. нередко оказывается, что отчет для простого шаблона, принятого у пользователя, сделать без скриптов нельзя.
Создать один корневой узел для ведомости параметров можно, но это приведет к тому, что перестанут работать все ранее созданные пользовательские отчетные формы, т.к. придется менять привязку к данным в ячейках, скриптах и вычисляемых полях, а.это не всегда можно автоматизировать.
Создание дубля всех узлов в один приведет к снижению быстродействия.
Каких, на ваш взгляд узлов, чаще всего не хватает в Архиве потреблений и интеграторов?
Я же сказал, что это экстремальный способ. Только я имел ввиду создание дубля всего. И кстати он будет не таким большим, т.к. копировать в него нужно не все, а только уникальные данные.
Наиболее часто есть потребность использовать с измеряемыми данными параметры из узлов “точки учета” и “объекты учета”
В последних версиях DevExpress появилась возможность использовать механизм привязки к выражениям (Expression Binding).
В выражениях можно использовать данные из любых узлов без каких-либо ограничений.
Во вложении пример отчетной формы с использованием выражений вместо вычисляемых полей.
В документации для ЛЭРС УЧЁТ v3.38 будет приведен пример и описание использования выражений.
Пример использования привязки к выражениям.lersreport (12.4 KB)
обновите ссылки на документацию пожалуйста
Если информация о снятии ограничения по использованию в вычисляемых полях данных из разных узлов? За 8 лет проблема не решилась? и обновите ссылки пжл
