When you are working in the Project Systems (PS) module, the identification and numbering of the PS master data is important. Unlike virtually all other modules in ERP, the master data in PS can be flexibly defined and structured. This also means that more thought must be put into the design of the coding mask used for this data.
As you probably know, the WBS ID from the system perspective is the object number (technical: OBJNR). That is a purely technical system coding with a prefix and some internal numbering but is used in all of the PS master data tables. For the business users the WBS ID is a different field that has a logical structure where each segment reflects specific meaning. This structure is often (if not always) one of the most important elements to ensure accurate cost account assignment because it translates quite a lot of information about the WBS element. While the object number is a unique ID that users have no access to, the WBS ID is a label that can be changed in the standard system on different phases of WBS lifecycle. Sometime that creates undesired situations when many people are working in the system at the same time.
Here is an example. One business user can create a PR or a PO and assign it to a particular WBS. Another user, maybe someone who created this WBS, will realize that the coding of the WBS ID is incorrect and will change it to correct value. Physically, it is the same object number (OBJNR has not changed), but from the reporting perspective (business logic) it will be a completely new and different WBS element. Looking back at the PR/PO, the commitment will remain on the previous WBS element and therefore show up on the wrong WBS from a reporting perspective. Similar situations can happen with the actual cost account assignment. This situation should be avoided.
It is possible to limit changing of the WBS number but a key consideration is the timing of this restriction. Disallowing the change from happening completely is probably not practical. After all, the business user might have made a typo and should be able to get it corrected. An appropriate time to limit the change is based on the status of WBS; Released status is a good turning point. Please note that WBS elements in Created status also can be used as account assignments in PR/PO, so that risk still remains. It can be addressed using the same approach if needed.
If you take a look in the system and pick up any WBS in the Released (REL) status, browse to the Business Processes (also called transactions) overview screen as shown below. There is a business transaction called [Change WBS number] that should be permitted while the WBS is in status REL (Released).
It is important to note that this specific business transaction concerns only WBS elements. Whenever you are in doubt please take additional time to investigate.
The ultimate goal is to transform it into the situation where the same business transaction (we do not know its code yet) will show up as not available as shown in the sample below:
The standard solution that I recommend is by using a user status within a User Status Profile.
For the illustration purpose I have created a sample profile called ZPSWBS02:
This profile has a single user status REL that is not initial. Double-click on the status line to set up dependencies on business transactions:
As you can see on the above picture the first line makes sure the WBS number cannot be changed.
The second line makes sure the status is set automatically once respective WBS-element is Released.
You can run a simple test in the system for the proof of concept:
You can see that my user status mirror the system status REL.
A second method that SAP does not recommend, but can be used in exceptional cases (taking all the associated risks) is the change of the System status.
To find the business transaction code ID you can browse a table TJ01T and, for example, use *WBS* as a text search criteria:
From the matching results I can find that the code is PSNC as shown below:
I will use transaction code BS22 to maintain System Status. Note that only the first column is the key field in this table view, while the Status like REL (for example) is not the unique match. Pay attention to the package as well as double check the status you are after only through the technical ID like I0002 for example.
NOTE: You need to be careful with this transaction and have complete confidence of what are doing and what are possible impacts. Making widespread changes to system statuses can have far reaching affects since Status Management is a cross application tool used by many different modules in SAP. Also, SAP AG will most likely not support any technical issues that you have if they trace it back to a change in this transaction.
Double-click on the status line to browse into business transactions:
They are sorted by the technical ID in alphabetical order but it is possible to navigate directly to the target line using the search field at the bottom of the screen along with the code we found earlier (PSNC). Next, change the transaction control for PSNC from Allowed to Forbidden:
After this change you can note that the WBS element code in the Released status gets "greyed out" which means that it is now processed as read only.
Implementing the change using the user status in the user status profile is the better solution. Sometime it can be challenging when you deal with a Live system that already actively use a user status management. If you realize and have under control risks you are taking by changing the standard system it is acceptable, but still not recommended. Youmight require a special care during system upgrades to reproduce all such changes (as well as keeping a documented history of all such changes to be able to roll-back).
Thank you for reading.
- SAP Managed Tags:
9 Comments
