SAP-WUG Digest, Vol 100, Issue 8

[David G Cooper]

Hi Kjetil Kilhavn,

You are correct, by custom release procedures; I mean those not defined via
customization, apologies for any confusion.

But still the warning about maintaining the value in both customization
areas is valid in either case.

Kind Regards
David Cooper

-----Original Message-----
From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of
sap-wug-request at mit.edu
Sent: Wednesday, 13 March 2013 7:26 PM
To: sap-wug at mit.edu
Subject: SAP-WUG Digest, Vol 100, Issue 8

Send SAP-WUG mailing list submissions to
	sap-wug at mit.edu

To subscribe or unsubscribe via the World Wide Web, visit
	http://mailman.mit.edu/mailman/listinfo/sap-wug
or, via email, send a message with subject or body 'help' to
	sap-wug-request at mit.edu

You can reach the person managing the list at
	sap-wug-owner at mit.edu

When replying, please edit your Subject line so it is more specific than
"Re: Contents of SAP-WUG digest..."


Today's Topics:

   1. Re: Purchase Requisition Item - Custom Release Procedures
      (Kjetil Kilhavn)


----------------------------------------------------------------------

Message: 1
Date: Wed, 13 Mar 2013 10:04:53 +0100
From: Kjetil Kilhavn <list.sap-wug at vettug.no>
Subject: Re: Purchase Requisition Item - Custom Release Procedures
To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
Message-ID: <1711022.ZQCN9xrsLC at t410-kjetil>
Content-Type: text/plain; charset="us-ascii"

I am responding to this message because I think it is confusing, so I think
a better explanation is necessary to avoid leaving people with the
impression that release procedures do not work very well - or even that you
can not use SAP standard if you want to centralize maintenance of financial
authority.

Onsdag 13. mars 2013 08.38.07 skrev David G Cooper:
> This is just a quick note/warning for workflow developers using the 
> BUS2009 (Purchase Requisition Item) object with a custom release
procedure.

Based on reading your entire e-mail I think it is necessary that you define
what you mean by a custom release procedure. Especially since there are no
standard release procedures. There is however a release framework which can
be customized. When you say "custom release procedure" you could perhaps
mean release procedures which are not customized as release procedures.


> 1)   The following events all have a standard parameter "ReleaseCode"
which
> is checked against table T161E
> a.   Released
> b.   Reset
> c.   Rejected
> d.   ReleaseStepCreated
> e.   SignificantlyChanged
> 
> 2)   ReleaseCodes are maintained as part of configuration in TWO areas,
only
> the first option below updates table T161E
> 
> a.   Materials Management -> Purchasing -> Purchase Requisition -> Release
> Procedure -> Set Up Procedure Without Classification

T161E is the table for release codes defined for release strategies without
classification, so it makes perfect sense that this updates table T161E.


> b.   Materials Management -> Purchasing -> Purchase Requisition -> Release
> Procedure -> Procedure with Classification -> Set Up Procedure with
> Classification

T16FC is the table for release codes defined for release strategies with 
classification (common table for purchase requisitions and EKKO-based 
purchasing documents), so that table will be updated here.


> 3)   If the Release Codes are not entered into table T161E, the raised
event
> will
> a.   Fail, and
> b.   Deactivate the event binding on the workflow

First of all, this is not true without a specific context as the release 
procedures here work very well without any of the release codes in T161E. 
Those release procedures are however defined (with classification).

So this is my problem. Is the context in which this will fail a situation 
where you have defined release codes for release strategies without 
classification, and raise the event manually?

Or perhaps this was just a typing error, and you meant that the raised event

will fail if the release code does not exist in T16FC. That makes a lot more

sense, because it is only those release codes that have an attribute to
define 
them as workflow relevant, which is a prerequisite for the event to be
raised 
when using "standard" release procedures with classification.


> 4)   The workflow cannot be restarted as the standard workflows all have a
> mandatory parameter for the Release Code

Of course they do, because the release code is a very important parameter
for 
the standard workflow when the release agent is to be determined.


> While having a custom release procedure within a custom Z Table is common,
> as businesses like to centralize the management of financial authority.

In my experience this can be achieved within SAP standard. The user exits
for 
classification and agent selection can be used to do all sorts of stuff -
from 
simply reading the agent from a table to determining the agent based on 
account assignments and combining that with organizational hierarchy
climbing 
if the responsible user determined from account assignments is not
authorized 
for the release code in question.


> Please keep in mind that the release codes used need to be entered in BOTH
> configuration areas.

Both? If you mean both for procedures with and without classification I
would 
like to hear why you think this is necessary. I have no experience with 
release procedures without classification, so I know for a fact that the
events 
will work just fine if the release codes exist only in T16FC.
-- 
Kjetil Kilhavn / Vettug AS (http://www.vettug.no)


------------------------------

_______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu
http://mailman.mit.edu/mailman/listinfo/sap-wug


End of SAP-WUG Digest, Vol 100, Issue 8
***************************************