R12.1.1 – Projects Reporting Pack
The Oracle Projects suite of applications has always suffered from a reporting problem, or at least many user organisations have, for a long time, had a perception that this is the case. The reason for this can be summarised into a couple of salient points:
- There have always been widely diverse reporting requirements for Projects reporting, not only between user organisations, but also between different users groups within these organisations.
- Oracle has never quite come up with a ‘one size fits all’ solution to reporting in Projects. In fact the reporting capabilities in Projects have never really measured up to the rich functionality offered by these applications.
So taking a step back and thinking for a minute one can conclude that there is no ‘one size fits all’ solution. To report from the Projects applications you need to consider various options and be prepared to use multiple solutions, even within one organisation, dependent on requirements. There are a numerous options / combinations for consideration, and the selection of the most appropriate ones can be a bit of a minefield, even for the specialist. I do not, in this article, seek to migrate through this minefield, but to let people know that there is something new out there that needs to be considered. That is the R12.1.1 Projects Reporting Pack.
What is it?
It is a feature that enables you to monitor project performance without accessing the applications i.e. it sends reports to via email to recipients who are key members on a project(s). A number of reporting templates are supplied that can be added to a ‘reporting pack’ which is then run through the standard concurrent manager and distributes the reports accordingly.
Basic Implementation Steps
- First define the following profile options in system administrator responsibility
PA: Reporting Pack E-mail Sender Address – This is the email address from which people will receive emailed reports. You may want to define a new email account specifically for this purpose. Invariably it is also going to be the email account that people respond to with issues, so bear this in mind when defining this profile option.
PA: Reporting Pack SMTP Server Address – This needs to be defined to give access to the email gateway, and determines the outgoing mail server that the reporting pack process uses to send the emailed reports. Liaise with your DBA to define this.
PA: Reporting Pack Worker Quantity – When a reporting pack process is run using the concurrent manager, it spawns a number of worker processes to run in parallel to improve the efficiency of the generation and distribution of the emailed reports. This is defaulted to 4. - One for the DBA’s… You also need to consider that when running Java v1.4.2 and above you do not need to have an X11 server running to process SVG requests. However, you do need to tell Java to run in “Headless AWT mode”. Normally this is done by passing in a parameter on the command line, but with Java Concurrent Programs this is slightly different. Therefore in system administrator, on the Concurrent Program Definition screen, query back the relevant Concurrent Program (in this case Project Manager Reporting Pack, short name PARPPROJMGR) and add the following into the Options field of the Executable section options field: -Djava.awt.headless=true
This parameter is then passed to the JVM instance that is started for this Java Concurrent Program - Don’t forget to ensure that users and employee record email addresses are up to date and correct, so that the emailed reports end up where they should do. All the intended recipients need to be defined within the HRMS. I am not sure if they need to be employees, or if contingent workers will also be included. I would hope that contingent workers would be included. If anyone knows please comment on the blog and let me know?
Note: The Reporting Pack requires you to have implemented Oracle Project Intelligence and be running this for Oracle Project Management (PJT) i.e. be running the PJT performance reporting (PJR) summarisation processes. This is because the reporting templates are picking up pretty much the same information / summarised data that appears in PJR e.g. under the reporting tab for each project in PJT. It doesn’t look like Reporting Packs can be used for distributing any of the standard MGT prefixed reports. Certainly the IMP prefixed reports do not fit the model.
Running / Scheduling Reporting Packs
After carrying out the above implementation you are ready to run the one predefined Reporting Pack: ‘Project Costs’. You may ask why there is only one! It’s my guess that Oracle has only given you one as an example, as they are so simple to define for yourself. See below for more details on defining your own. To run / schedule them and look at some sample output – click the Play icon on the following desk top video, then click on the icon to ensure that HD is on, and click on the full screen icon to the left of the “vimeo” logo:
Defining Reporting Packs
In Oracle Project Management you can define reporting packs using a super user responsibility
- N > Project Manager Reporting Pack > Create Reporting Pack: Give your reporting pack a meaningful name, this will be the name that appears on user’s emails when they receive their output, so its needs to mean something to the end user.
- Define which report template(s) you want in your pack. The seeded templates are listed below. For each of these specify which report format you want the output to be delivered in e.g. PDF. Click on each to see sample output:
Project Change Order Report (preview)
Project Committed Cost Report (preview)
Project Cost Detail (preview)
Project Cost Labour (preview)
Project Cost Summary (preview)
Project Earned Value (preview)
Project Financial Summary (preview)
Project Forecast Summary (preview)
Project Revenue At Risk (preview) - Define which project role(s) you wish to distribute the report pack to e.g. Project Manager
- Save your new reporting pack, and run / schedule it in the same way as the predefined one, as shown previously.
Nice and simple as it seems, there are a however a few things to bear in mind with Reporting Packs. Here are a few additional tips to help you:
Tips:
- Remember that all the existing templates run on summarised data from Performance Reporting (PJR) in Oracle Project Management (PJT). You therefore need to coordinate the running of the summarisation processes, the setting of the current reporting period in PJT, and the scheduling of your reporting pack processes.
- It pains me to say this, but Oracle has unfortunately missed out YTD measures in the Reporting Pack Data Definition. It’s taken nearly four years for this to be recognised as a weakness in Performance Reporting, and Oracle have pretty much corrected it in R12. Would you believe that they have left YTD out of the Reporting Packs! Why, anyone please help?
- Test the output of your reports thoroughly, do not just give them a once over and assume they are fine. It is important that the selection of parameters you choose is thoroughly tested for all the templates you use. As an example of a potential problem, it does not seem possible to select a value for the ‘specific period’ parameter when running any reporting pack.
- If you don’t like what you get or you want to modify the standard report templates then refer to the ‘Coming soon’ section below
Coming Soon: “How to create and modify templates and how to modify the Reporting Pack Data Definition”. Subscribe to our RSS or Twitter feed to stay in touch on this.
Comments are now closed... Please contact us if you have any queries.