We’ve been having an ongoing conversation with one of our loyal blog readers with respect to nVision, Business Units, and Queries. One of the things she found was that Queries didn’t quite behave as expected with settings on the report request and was interested in learning more about it.
A Brief History of nVision and Queries
Let’s start this discussion by going back to the beginning of nVision, where it was initially developed as part of the GL product and there was no such thing as PS/Query yet. It was built to perform reporting against the ledger and that was pretty much it. In PeopleTools 3, there was a bunch of new things that came in the reporting area: nVision was moved from being part of the GL development team to becoming a PeopleTool, Query and Crystal were introduced as additional reporting capabilities, and nVision received several new features out of the mix, allowing it to perform analysis against content other than Ledgers (as well as drilling into supporting transactional detail through queries).
On the nVision side, this was accomplished by extending the product to support Query as a data source in addition to ledgers as well as support of tabular layouts (in addition to Matrix layouts).
More about Query Support
Adding support for queries as a data source was a very elegant way of identifying data to be used while still leveraging much of the metadata in the PeopleSoft system. This allowed a business user to identify fields of interest, specify how to aggregate data to be analyzed, as well as leveraging effective dating logic.
nVision has special logic inside it to handle the additional criteria specified in a report layout, or to apply scope criteria to the report (it actually modifies the query on the fly to add the additional value or tree criteria and process it). However, a Query simply does not have the same level of metadata as a ledger does, which means that there are limitations. For example, there is no calendar mapping to queries as there is for ledger (which is the primary key to identify what a timespan means). Therefore, although the scope and criteria extensions of queries in nVision work seamlessly, much of the other extensions that are part of the report request are not applied (in the circumstance in question, the business unit specification in the report request is not used to filter the data, although it is used for setid indirection.
One other thing that has intracies (or rather inconsistencies) with how it works is tabular layouts. For example, it would be nice to be able to take a query and apply worksheet criteria to it in a tabular layout. Unfortunately, worksheet criteria does not work and if you want to apply additional criteria to a tabular report without modifying the query, you will need to use a scope.
Labels: nVision, Query