Reporting is an area of constant concern among SAP customers regardless of tool or reporting need. No matter how much technology and new features that SAP pushes out, customers still struggle with this topic. Even after they’ve developed an acceptable reporting solution, they have the new burden to monitor and administer the reports to ensure they’re accurate. Reporting also tends to drive a very passionate response and user base given it’s importance. It’s possible to get an isolated transactional business process perfect but it seems like no one is ever 100% content, much less thrilled, by their reporting options. It’s hard.
Let’s talk about something that will help ensure reporting accuracy and consistency in the Project Systems (PS) module.
Quick Overview of PS-IS and RPSCO
Reporting is so big in PS that SAP refers to it as an ‘Informational System’ (component PS-IS). There are several distinct report types in PS that go far beyond just simple list reports:
- Line item reports: As with most other ERP modules, there are line item reports that analysis individual postings based on different criteria. There are PS line item reports for actual costs (CJI3 and CJI3N) but also plan (CJI4), budget (CJI1 and CJI2), and commitment (CJI5) postings as well. Everyone loves these reports because they provide direct access to all of the original source accounting documents.
- Cost element reports: SAP provides these reports so you can evaluate project values, quantities, or SKFs by cost element. Several of the CO plan/budget reports fall into this category.
- Hierarchy reports: The hierarchy reports show project costs, revenues, and payments for a project hierarchy. The values are summarized by value categories.
- Structure reports: The structure reports are used to evaluate the master data structure and logistical aspects of a project. They show all related objects to a given project (or range of projects) in their full hierarchical structure, allowing you to evaluate the project objects based on their relationships and key attributes. While the structure reports display basic summarized cost values, their primary purpose is master data related, which makes them different from the other three reports. These reports are based on the logical database PSJ, which provides access to the most important PS tables.
Generally speaking, the cost element and line item reports are more detailed and granular compared to the other two. They can also suffer from performance problems because of the (potentially) vast amount of data that can be queried and shown in the result set.
To combat this problem for reporting requirements that don’t need detailed data, PS uses a summary table to provide aggregated data as the source for the hierarchy and structure reports. This table is RPSCO. There is a sister table that tracks quantities called RPSQT.
This approach to a summary table that is reporting focused isn’t new. It’s used in many other ERP modules and does solve an old problem around report performance. However, it creates a new problem regarding reconciliation. In this case, the reconciliation isn’t a financial one but a technical concern. For reporting accuracy, it’s critical that the summary/aggregate tables total to the underlying line items stored elsewhere.
Reconstructing the PS Information System
Since RPSCO is the source for PS value reporting in the hierarchy and structure reports, it is updated whenever someone posts to a project. To ensure that RPSCO is consistent and that the reports are accurate, SAP delivers a program that rebuilds the database, though they chose to call it reconstruction in this case.
As with most rebuild-type processes, this program is useful in ensuring that the reporting database is correct based on some anomaly that might corrupt it and therefore negatively affect project reporting. It is also required based on certain changes in configuration that may be transported into the productive instance.
The program is accessed via transaction code CJEN. The selection screen is straightforward and easy to understand.
- You can execute the program for a multiple projects or networks. Also note that this is impacted by the chosen DB profile… if you want to run this by cost center hierarchy, profit center, investment program (IM) hierarchy, or a custom one hierarchy (ex. based on user fields), you can.
- Most of the processing options are straightforward and self-explanatory… test run, background processing, etc. Also, the F1 help is sufficient if you need more information. However, the following need more detail:
- The [Delete] option deletes the entries in the database for the selected project. It is very rare to have to use this option. One example is if there are reporting entries related to budget values. If the budget values are subsequently zeroed out and the budget status is reset, then the reporting entries are deleted by transaction CJEN. In particular, you have to be careful in considering if the entries that will be deleted can in fact be rebuilt. If the answer is no, then you should strongly consider not using this option. In general, leave this inactive unless you specifically want to delete the existing entries.
- You can choose from two output lists: Object list and Detail list. The Object list option only outputs the list of project objects (e.g., WBS elements and network activities) that are included in the program’s execution. This might be useful in confirming that all objects for a given project, or range of projects, were in fact updated. The Detail list option is much more informative in that it outputs the list of objects as well as the RPSCO entries/values. My preference is to have the [Detail List] active but that’s because most of the time I have to troubleshoot an issue and want to know what the values are that are being changed. However, if I’m just running the program as part of a larger process and just want to be sure that the values are correct, then I’ll leave both off or just active [Object List]. In those cases I’m not looking for the ‘why’, just confirming that the values are fine so that I can move on to the next step in my process.
What happens next?
The first thing transaction CJEN does is delete the contents of RPSCO and RPSQT. It then rebuilds them by analyzing the existing configuration for value categories and from the source data in the following tables. These tables store the plan, budget, and actual values in summarized forms for projects and their associated objects such as orders and network activities. By doing so, the SAP system is able to provide a single summarized table to support PS value reporting.
- BPGE: Totals Record For Overall Plan/Budget Values
- BPJA: Totals Record For Annual Plan/Budget Values
- BPPE: Totals Record For Period Values
- COSS: CO Cost Totals For Internal Postings
- COSP: CO Cost Totals For External Postings
- COSPP: CO Cost Totals For External Postings For Projects
- COSSP: CO Cost Totals For Internal Postings For Projects
- COSB: CO Total Variances And Results Analyses
- COSR: CO Totals For SKF
- FMSU: FI-FM Totals Records
- FMSP: FI-FM Totals Records For Projects
Once the program is complete, a list of the RPSCO entries is displayed for the projects that were updated. Note that the entries track several prominent fields related to project reporting, such as the object type and ID, budget/planning ledger, value types, value category, year, version, and budget type.
If the program was executed in update mode (i.e., the [Test Run] indicator was inactive) then the entries displayed above are now reflected in the database and should also show up in any PS structure or hierarchy report.
Activating the Extended Log
The problem with the current report output is that it shows the most current and accurate reporting entries generated by transaction CJEN. Without viewing the entries directly in transaction SE16N or via RKACGRID, you can’t tell what entries proposed by transaction CJEN have been changed, deleted, or added to table RPSCO. Another way to interpret the result is that CJEN is displaying the new entries… but you don’t know if they’re identical to the existing entries. It’s not showing you the delta, just the correct data as determined by fetching the data from the underlying tables listed earlier.
To remedy this, SAP has released a hidden OK Code that changes the output log of the report, thus increasing the functionality of the report’s data. To use it, go to the initial selection screen of transaction CJEN and enter the selection criteria and processing options as you normally would. Then enter the word COMPARE in the command field (i.e., the transaction code box) and press [Enter]. No message or confirmation is issued, so you might not initially know what has happened. Press F8 to execute the program as you normally would.
When the report output is displayed, you see that a column has been inserted at the end of the key of the table. The final column “In (indicator)” contains a series of icons that provide information about the entry. The icons used are:
- Green check mark: The entry proposed by transaction CJEN is the same as in RPSCO. There are no changes to the entry and it was already a correct and valid entry.
- Trash can: The entry has been deleted.
- Pencil: The entry has been changed. This could be a change in the entries’ amounts or any of the characteristic values.
- White document: The entry has been created and did not previously exist in RPSCO
In the screenshot below… which is the same project at the top of the earlier screenshot… I can now see that each entry is being deleted and then replaced by an identical entry except that the new entries have a value category “CAPINT”. This makes sense because I remember making a change to my value categories for a capitalized interest example (used in the blog How to Track Project Capitalized Interest in SAP (Part 1)) that was done after I made the postings and when RPSCO was initially updated.
Here is an example where the entries are identical to the ones already in RPSCO. I usually interpret it as a good sign because it means that my configuration and transports haven’t caused any issues. Or, that I’ve been diligent about running CJEN and this latest run confirms that my data and the reports that use it are all correct.
Here’s another example where some of the entries are correct but two are being deleted and two similar entries are being updated.
Note: The extended log remains active until you either enter COMPARE again (to deactivate it manually) or leave transaction CJEN. It does not have to be entered again if you back out to the selection screen and just want to change your selection criteria and re-execute the program. The extended log is useful for highlighting the types of changes being made or confirming that the entries in the database were already correct.
Recommendation
Consider running this program during the month-end close process. Because the program supports variants, it is relatively easy to logically break up the project data based on the project mask and schedule the execution of the program.
I’d recommend that you create variants for different project types based on the project mask. I usually do this so that no more than 20,000 to 30,000 objects are executed at any time, but this is just a guide.
Also, if you’re reading this blog and it’s the first time you’ve heard about CJEN (!!!!) then I’ll double recommend that you break this up into small chunks. The reason is that you may be impacting a large number of project objects or have to rebuild project data over several years. That way the program won’t time out.
Lastly, it’s important to note that the PS availability control (AVAC) function is also based on the same RPSCO table. SAP provides a similar transaction to reconstruct AVAC, but it uses RPSCO as its source so RPSCO has to be fixed/rebuilt first. A lot of customers will rebuild AVAC without running CJEN first which means that their data is still incomplete.
Next Blog: Reconstructing PS Availability Control for Easier Cost Control With CJBN
