Dynamic Data View Block Headings?
Hi,
I would like to ask everyone: what options do we have when we wish for dynamic headers in our data views? My client is still in Board12, but we have a Board14 upgrade planned for the near future.
Specific issue: the client would like to have a report that has dynamic headers with regards to months and versions. There is a report of the rolling 12 months, and they would like to see the YYMM of the last month (eg. "Actuals R12 2409"). Similarly, they have a report of their Plans for Year 3, but instead of "Year 3", they wish to be able to see "Year YYYY" (eg. "Plan 2027").
I have used labels for this, but they move around depending on the size of the screen used, and they aren't there when the client drills down, which is an issue.
Simply having block references doesn't always work, for example, if I have a month block reference for R12, I would only see the data for that last month, not the other months.
How would you work around this? I am thinking of building a new entity whose members are these dynamic names, and use the @Selection parameter in the header. However, that is not something we could update with a procedure, member codes and descriptions would need to be updated manually by the user, which they don't want. (or we could update them with an export to csv and then import via data reader, but I am not a fan of exporting data from the system just for a workaround, if there's any other way I am missing, I would love to learn about it!) Another hangup with this solution is that I would need to introduce this new entity to the reporting cubes, decreasing screen load performance for the sake of headers…
Does anyone have any smarter workaround for this issue? Are dynamic block headings a thing in Board 14? It would be great if the headers could use dynamic block references.
Answers
-
Hi @Krisztina Zappert ,
there is not the way to accomplish those requirements and as you've said yourself, all currently possible solutions have their own ups and downs.
I've worked with labels - that might look nice on the screen, if everyone works with the same resolution and you don't want to drill, don't want to export the data to xls, …
I've worked with references, being set by procedures—that might overcome the issue of needing additional dimensions in the reporting cubes, but it does not in every case. On the other hand this solution takes some time to develop and it requires additional cubes and entities just for this purpose; so in most cases the effort is not justified. Apart from that, performance suffers.
I've worked with dataviews hidden behind the ones used to display data, only displaying fake headers—but those will not be exported when the data is exported (xls or otherwise).
There are some ideas regarding this topic (even accepted to be part of the roadmap), for example
I can only encourage you to share your thoughts as ideas as well.
Best,
Helmut0
