PO Workflow

[Mark Pyc]

G'day Monique,

Firstly, 'only a functional person'??  Come now, big up yourself. Most
of us are only WF people.

I'm looking at the same thing currently. I'll have a crack at numbers
1 & 3, but as I'm only a WF person I'm not sure what a 'charge source'
is so will leave 2 for someone else.

1. You can't have the Release strategy kick in only on change, but you
can have a WF which will automatically release in the background on
first creation. That way when the Approved cart is brought across as a
PO it will block and then be automatically released by WF. Any future
changes (depending on your Release Strategy config around tolerances
etc) will cause the Release Strategy to kick in again. At that point
you can have an approval WF.

3. Before you offer the approval step you could store in a container
the current value of the header notes and have validation in the tail
end of the method to ensure that it had changed before completing the
Workitem. Developer stuff, but not difficult.

Have fun,
Mark

On 10/03/06, Stephens, Monique S L <moniques at bcm.tmc.edu> wrote:
> Hello fellow workflowers!  I had posed this question before but cannot find
> the response I received.  But, the criteria has changed a bit and I need
> some input.  I am not an expert at workflow.  I am only a functional person.
>  We have another person here that actually does the technical aspects of
> workflow.  Therefore, please give me good details as to what needs to be
> done if it is possible or not.
>
>
> Prior to SRM, our users created PO's that would then route through workflow
> for approvals at several levels (department, Environmental Safety, Grants,
> Finance, then Purchasing).  We have most of this set up in configuration
> with the different release levels, codes, and indicators, as well as within
> the workflow logic.
>
> Once we went live with SRM, users were creating shopping carts that would
> route through workflow.  The PO would be created automatically on the R3
> side for catalog orders or converted into a PO by our Purchasing department
> for non-catalog orders.  These PO's are not set up to go through any
> workflow.  Users are not allowed to make changes to these particular PO's.
> Obviously, that has been a BIG issue with our departments that were used to
> making valid changes (different charge source, remove commitments, add
> header notes, etc.).  We have therefore decided to implement a workflow that
> will encompass our pre-SRM PO workflow as well as the SRM PO's.  This is
> where the questions begin.
>
> 1.  For the SRM PO's, they do not currently have a release status since they
> have not gone into workflow before.  How do you tell the system that
> workflow should only begin for these PO's if certain criteria are met?  Is
> this something that can be done in configuration with the other release
> steps?  Once a release status is given, it should follow the workflow we
> already have in place.
>
> 2.  If a charge source is changed, is that something done in configuration
> or the workflow logic?
>
> 3.  If a PO is changed, how can we ask the users to put something in the
> header notes explaining what was changed as part of a validation?
>
>
> Monique Stephens
> SAP Analyst
> Baylor College of Medicine
> 713-798-1349
> 713-798-1326 (FAX)
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>
>
>