Release Strategy
Hi,
Please tell me what is the use of the fields USRC1, USRC2, USRN1, USRN2 in release procedure? Can you show me how this field could help us in the setup CEBAN and CEKKO.
Thanks.
Hi,
These fields are used when you are implementing the release strategy with workflow.
Cheers,
HT
_________________
Moderator:
Hi Ha Tran,
Thanks. I am asking this question because we have a release procedure requirement for PO where material type, cost center, PO account assignment and the PO total amount is a condition for release. I know that PO release is done at the header level and the first 3 parameter lies at the PO item, so is this particular criteria possibe to define a release? Can you please let me know how... if its possible.
Thanks.
Hi,
I would think that if these item-based criteria have been selected for your PO release strategy, it is of high potential risk that some of your PO will not be subject to release strategy especially, when the value being entered by your end users (purchasing staff) will not be the same. As a result, you should be careful in selecting how the release strategy structure should look like to meet your company's business requirements.
Cheers,
HT
_________________
Moderator:
Many thanks Ha Tran. Hope you don't mind me asking one more related to this. Another peculiarity is that our level of (level 1) release is purchasing, (level 2) management team (with about 8 members) and (level 3) final approver. The peculiarity is that after the purchasing release the PO (level 1), any of the member of management team can release it next (level 2), the last release level is to me a tricky one. The last (level 3) can be released also by any of the management team except the one who release it at level 2.
Is this scenario possible? Thanks again.
Hi,
First of all, I would be afraid that the existing setting in terms of second-and-third-level release structure is not appropriately determined business-wise as in this case there will be many authorizers of the same level who can use the same release code to release PRs. How could we differentiate these authorizers by using only one release code? How could you make sure that the PR will be released on time as if I were one of these authorizers, I would not feel responsible for making the prompt release of all related PRs with the assumption that someone else will do it on my behalf. Anyhow, if this is what you have decided to go with, then the solution for your question will be the implementation of the User Exit in combination of the Z Table. This Z Table will at least contain the name of all authorizers at level 2 and 3 together with the release code. So once the PR is released at the second level and is subject to the third level release, the User Exit will be triggered which will seek in the aforesaid table and determine who should not be releasing the respective PR at the third level.
Cheers,
HT
_________________
Moderator:
HT has a valid point.
If you want to have multiple approvers to approve the same dollar limit on the PO. You always have the option of creating a different Release Code within the same Release Group to ensure that you don't lose the reporting trail (e.g. who approved what document). With this solution it would require a little more master data maintenance up front, but you will definitely be able to report cleanly on the purchasing document approval.
Rob