Mungapen SAPLOG

Release strategies in purchase orders do not indicate the current level of release and the next level of approval pending, within a single field value that is easily understandable. Within the collective release transaction (ME28) the ‘release code’ can be used to filter PO’s into a queue. However within the many list displays and ‘enjoy’ document overviews the release code isn’t available as an option. Hence it is difficult to manage releases and report on them in a consistent manner. Additionally without workflow it is difficult to monitor how long purchase orders have been waiting at the various steps in the release procedure.

SAP has done this as it allows parallel releases along with sequential releases.  This means that there could possibly be more than one release code valid at any time (hence a single field cannot easily hold that information)

Release Status

To keep the release strategy as configurable and flexible as possible the release code is not stored in any tables related to the purchasing documents. The release code, previous releases and next available releases are calculated programmatically based on a field called release status which is stored in the PO header table (EKKO). This release status key stores the releases in the form of a string of blanks and X’s where the position of the X holds the releases to date. This needs to be decoded against the configuration tables to determine the release codes that have been applied, and those that available to apply next.

For any given release strategy SAP provides a maximum of eight levels of approval. Each of which is associated with a release code. Hence any PO could have a maximum of eight valid release codes. The release status field is an eight character field that stores the releases already affected as X’s in appropriate position in the eight characters. EG for the release strategy below with four release codes

If the requester and buyer have approved then the release status will appear as ‘XX______’ if the requester and the director were the only ones to approve then the status would be ‘X_X_____’.

Basically SAP uses the combination of release group and release strategy to work out the final release combination (the approvals that result in the Po being released). It then looks at the release status to see what has been released already. This can be achieved by reading the relevant tables in the configuration; alternatively SAP has provided a BAPI that performs this function and others ‘BAPI_PO_GETRELINFO’ Understanding how SAP interprets the release code will enable custom reports to be developed either using SAP queries or by developing custom reports.

Utilizing Release Indicator

The simplest way to implement release strategies so that it is clear who has approved and who the next approver is,  by far is if you have a fairly straightforward approval loops it to use the release indicator to indicate where in the loop an item is.

The release indicator is a single digit indicator that by SAP’s default configuration indicates B for blocked and R for released. However it is possible to configure a number of indicators and assign them to the various steps in the approval loop. I.e. you can define release indicators as follows

Or alternatively you can give them more generic descriptions such as

E.g.

This solution immediately gives the following benefits

· A single field in the PO indicates who the approval is waiting on for approval

· A single value in the change tables (CDHDR and CDPOS) indicates when this value was set (and by whom) and hence how long it has been waiting the next approver.

However the release indicator is a single digit alphanumeric field, which means it, can only have thirty six values (maybe more if you use the full ASCII characters that are valid)

This will work well for most approval loops that are purely sequential, (A releases then B then C). However it rapidly breaks down if there are numerous parallel approvals. (A releases then B or C then D or E then F). ECC allows for eight levels of approval within the standard system, hence the worst case scenario of 8 approvers that can all approve at the same time would give 2^8 combinations or 256 possible states of release. To give each of these a unique indicator would not be possible as there are only 36 possibilities. Additionally the descriptions would become confusing very quickly as they would have to indicate the combinations of release options

Therefore with complex parallel approval loops, this solution becomes less useful. However whenever this approach can be used it should be the first choice.

If the release strategies are simple enough to allow the use of the release indicator then the existing document overviews within the enjoy transactions (ME21N/ME22N/ME29N etc) can segregate purchase orders by the release indicator simply by adding a breakdown to the existing reports.

In this example there is a two level release adding release indicator to the document breakdown as a sort field enables the grouping of PO’s by the pending release. In this case if I am a level 2 approver I can look directly in the 2 folder for Po’s pending my release.

Adding the release indicator to the breakdown is achieved by clicking on the breakdown button

Then selecting the release indicator field and making it part of the breakdown.

Then selecting the release indicator field and making it part of the breakdown.