How would one start when a development related to triggering of release strategies comes up?
Checking documents available via Google, investigating SAP notes, looking into the configuration and functionality coaching would be the first steps per me. For Purchase Order(PO) release strategies, SAP notes could be a very useful source of information to start with but could also be little confusing at the beginning.
Before starting with the development, it is good to get well familiarized with creation, change, approval, rejection, re-triggering of approval scenarios of a PO, version management of the PO. It is also good to know any existing customized process used for PO creation or change process.
SAP Note 365604 – FAQ: Release strategies in purchasing should be read and understood for a good start. It contains many relevant other SAP notes. Looking at the description of exit M06E0004, it says Changes to communication structure for release purch. doc. Structure CEKKO is referred as communication structure.
While starting with the change, a doubt could very well arise as to how do this communication structure control triggering of PO release strategy. Answer lies in the way release strategies are configured.
Taking a look at the configuration of release strategies by following the path: SPRO->Materials Management->Purchasing->Purchase Order->Release procedure for Purchase Orders->Define Release Procedure for Purchase Orders
Reading documentation available for Release Procedure provides a real great deal of information. In fact, while dealing with PO related development, I am impressed with detailed SAP documentation available at many steps.
Clicking on the release strategies opens up the screen of release strategies configured in the system. I am taking an example of dummy strategy created for the purpose of this documentation.
Clicking on Classification tab would show the criteria’s or characteristic values which needs to be satisfied to let this strategy trigger when PO is created or changed.
Since the intention of document is not to focus on configuration of rel. strategy, I am taking only few values. So, with the values above, it depicts that K3 would be triggered when PO order type, net order value, company code, user field numeric for release matches with the values given here.
Now, let’s go to transaction CL03 and enter the appropriate values.
Selecting the characteristic and clicking on display button at the bottom of the screen displays the basic data of characteristic.
Clicking on Addnl data tab:
It is at this place that communication structure gets linked to PO characteristics.
To know the allowed values (in case any) Values tab on the above screen could be clicked. This would be useful especially in case of fields USRC1, USRC2, USRN1 and USRN2.
I have found at least one document on SCN detailing configuration of these characteristics:
http://scn.sap.com/docs/DOC-46564
Going back to documentation of exit M06E0004
It is usually the values of these four fields which get set in the exit for triggering of release strategies. The other field values of structure CEKKO is already populated when the exit gets called. One needs to be careful with setting values of the four fields when same field gets used to trigger more than one release strategy.
After doing the necessary development one common issue that could be faced is that the release strategy does not get triggered at all or the correct one does not get triggered. It should be noted that Release Strategy tab on PO screen appears only if there is a release strategy triggered else it does not appear.
Release strategy was not getting triggered for instance in my case was because the default value of the field CEKKO-USNRN1 was passed as 0 whereas the release strategy had a blank value in the characteristic configuration. Another way to find if there is any discrepancy in configuration of rel. strategy is to check via transaction CL30N. At any point of time, there should be one rel. strategy triggered for one set of input conditions and criteria’s. I had found a relevant discussion thread which highlighted this but cannot locate now.
To check the rel. strategy triggered in debugging mode, breakpoint could be placed when the subroutine STRATEGIE_CEKKO is called in program SAPLMEPO under Include MM06EF0S_STRATEGIE_ERMITTELN. It’s the function module ME_REL_STRATEGIE_EKKO (called just after the above subroutine) which returns the triggered rel. strategy, rel. group, rel. indicator, rel. status and if the PO has been completely released. Understanding this FM would greatly help in understanding the Purchase document rel. strategies. A good documentation of this FM by SAP too would have been great.
I would try to explain the working of FM ME_REL_STRATEGIE_EKKO to some extent. Understanding Release Indicators and changeability of purchasing document during or after release is an important aspect for rel. strategy trigger. Let’s consider a scenario when the PO gets changed while being in the approval process e.g. a PO had to be rejected and had to be corrected to be submitted for re-approval while in the approval (release codes) hierarchy. This FM gets called and checks if the changed PO calls for a trigger of a different rel. strategy and if that’s the case a different strategy gets triggered and the PO has to be re-approved. Changes done to the PO could be seen from the PO screen (ME23N, ME22N, ME29N for example) by selecting the Option Environment->Header changes in the MENU bar. Change documents are created for this.
The next scenario could be the PO gets completely approved and hence released and then the PO net value gets changed. In this case also, there is check in this FM that if the changeability factor associated with the rel. indicator of triggered strategy is 4 or 6, if the conditionsatisfies and the value change is greater than the tolerance %age maintained the strategy gets re-triggered for approval process.
The same understanding is clear by looking at the description of changeability and tolerance indicators.
However, understanding the same from the function module made it more concrete. Other challenge faced in understanding this FM is all the comments are written in German.
Last check that happens inside this FM is that if the PO is approved and already outputted (as is done via configured output types) then only if the changeability factor associated with rel. indicator is 5 or 6, the re-trigger of same or trigger of a different strategy is allowed. The same understanding could be obtained by looking at description of the changeability indicators in the screenshot above.
Some general observations:
When does the PO get released?
When the last release code configured in the strategy gets approved (as could be seen by clicking Release prerequisites button on release strategy configuration screen), the PO gets released and the rel. indicator gets changed from Blocked to the indicator configured in the strategy.
Going back to the dummy strategy created and clicking on Release statuses button:
The same could be visualized by clicking on Release simulation button.
BAPI that helps in release is: BAPI_PO_RELEASE which takes the purchase doc. Number and release code as mandatory parameters. Likewise to revoke the release, BAPI_PO_RESET_RELEASE could be used. The documentation of these BAPI’s explains the functionality beautifully.
Another useful BAPI that provides release information about a PO is BAPI_PO_GETRELINFO.
Authorization Checks
This is very important aspect of PO release procedure and should be understood. Authorization object M_EINK_FRG is used extensively and also in all the BAPIs related with PO release.
The documentation of this authorization object provides a great deal of information and should be read. Any user can approve or reject a PO only if she has the required release code role attached to the user’s profile.
Rejection of PO
The approver has the option of rejecting PO with the reject button available on the screen. However, there is no BAPI or function module provided for direct rejection of a PO. There could be workarounds. On deep diving to see what does the standard coding do to reject the PO, I could see that EKKO-PROCSTAT gets set to ‘08’ (rejected) and then gets updated ensuring data integrity and consistency.
There are many other aspects related with PO release and obviously all have not been covered as part of this document. The most explicit one is role resolution.
In case anyone thinks, something more should be added, do leave a comment and I would add it.
- SAP Managed Tags:
17 Comments
