Purchase Order Approval:Organizational Unit

Mike Pokraka wug at workflowconnections.com
Thu Feb 27 10:44:43 EST 2014 

Hi Michael,

Very nice explanation, I'm almost a little reluctant to voice my
disagreement:
It can be done, quite elegantly even. BUT (there's always one), it needs a
bit of thought and good knowledge of HR OM.

You can either customize/extend the org unit infotype or create your own
infotype. Then you can just edit it using standard tools (PPOME etc.), and
make the infotype value an attribute of the relevant ZCL_EMPLOYEE or
ZEMPLOYEE object. Done it and works well.

A big question to answer is whether Org unit is the right place. Should
EVERYONE in the org unit have ability to approve?
What about staff movements?
If a manager with a 200k approval limit gets replaced, should her
replacement automatically inherit the same limit? (Usually not). Same
solution above can thus be applied to positions, persons, org units...

Lots of business input needed and an preferably an someone with good
technical HR skills if not well versed in this.

Regards,
Mike


On Thu, February 27, 2014 2:58 pm, michael.mcley at daimler.com wrote:
> Swathi,
>
> I think any solution you choose where you are maintaining amount limits in
> the org structure will be at best a kludge.  If you or your customer are
> dead-set on using the org structure for maintaining price splits in the
> workflow you could:
>
> 1. Maintain the values in the short description fields of the positions -
> we do something like this for some workflows and while it works, for a
> variety of reasons, it stinks.
> 2. You could maintain a job code or task with an infotype that has the
> value buried in it somewhere, then assign the job/task to each position or
> org unit.
> 3. You could maintain 3 different root org structures for each release
> level, put the values in a hijacked field (maybe again the short
> description) and choose the org structure based on the value.
> 4. Create a separate org unit with sub org units that simply hold the
> values in one of their unused fields, create a task that pulls in the org
> unit and loads container values based on the org unit data...
> 5. etc...
>
> There are a number of things you can do.  None of them is a very good
> idea.  You will be lucky to be able to do it without some custom code.  In
> this case it is particularly unfortunate because SAP provides you with,
> really, standard methods to accomplish this.  It just doesn't involve the
> org structure.  Just remember, if your experience is anything like mine,
> the customer will blame you for a bad solution even if they demanded it
> ;-)
>
> Michael McLey
> MBUSI - IT Parts & Administration
> Mercedes-Benz US International, Inc.
> 1 Mercedes Drive
> Vance, AL 35490
> PHONE:  (205) 462 - 5239
> EMAIL:   michael.mcley at daimler.com
>
>
> -----Original Message-----
> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
> Of Swathi Devireddy
> Sent: Wednesday, February 26, 2014 11:41 PM
> To: SAP Workflow Users' Group
> Subject: RE: Purchase Order Approval:Organizational Unit
>
> Hi,
> Is there a possibility to maintail these amounts in the Org Unit so its
> easy to maintain.
>
> Regards,
> Swathi
>
> -----Original Message-----
> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
> Of gs ko
> Sent: Thursday, February 27, 2014 11:01 AM
> To: SAP Workflow Users' Group
> Subject: RE: Purchase Order Approval:Organizational Unit
>
> That's good approach. If you are usning custom workflow, you could create
> customer rule as well.
>
> Thanks,
> Gowrishankar.
> --------------------------------------------
> On Wed, 2/26/14, michael.mcley at daimler.com <michael.mcley at daimler.com>
> wrote:
>
>  Subject: RE: Purchase Order Approval:Organizational Unit
>  To: sap-wug at mit.edu
>  Date: Wednesday, February 26, 2014, 10:57 AM
>
>  Swathi,
>
>  If you are using the "standard" SAP PO workflow approval,  you can use
> classification and maintain the levels in a  characteristic.  We use a
> characteristic of type  CEBAN-GFWRT.
>
>  Michael McLey
>  MBUSI - IT Parts & Administration
>  Mercedes-Benz US International, Inc.
>  1 Mercedes Drive
>  Vance, AL 35490
>  PHONE:  (205) 462 - 5239
>  EMAIL:   michael.mcley at daimler.com
>
>
>  -----Original Message-----
>  From: sap-wug-bounces at mit.edu
>  [mailto:sap-wug-bounces at mit.edu]
>  On Behalf Of Swathi Devireddy
>  Sent: Wednesday, February 26, 2014 12:35 PM
>  To: sap-wug at mit.edu
>  Subject: Purchase Order Approval:Organizational Unit
>
>  Hi,
>
>  We have a simple Purchase Order Approval Scenario. We have  different
> Business Units (E.g Manufacturing/Finance).
>  Based on the Amount of the PO it should goto the person for  approval.
>  E,g
>       0
>     -  5000$ --
>
>       - Manager
>
>     >5000$
>    -10000$ -
>
>     - Director
>
>  >10000$
>     -
>
>
>     -Senior Director
>
>  If amount is greater than 5000$ its 2 level approval
>
>  We want to maintain an Org Unit for this approval process.
>  How can we maintain the amounts in Org Units.
>  Suppose amount is 6000$ it will go directly to Director.Also  want to
> avoid Z table creation as much as possible.
>
>  I have created Org Units for Each Business Unit and defined  the
> hierarchy. Any idea where I can maintain this amounts  also to control
> the flow.
>
>
>  Regards,
>  Swathi
>
>  **************** CAUTION - Disclaimer ***************** This  e-mail
> contains PRIVILEGED AND CONFIDENTIAL INFORMATION  intended solely for the
> use of the addressee(s). If you are  not the intended recipient, please
> notify the sender by  e-mail and delete the original message. Further,
> you are not  to copy, disclose, or distribute this e-mail or its contents
>  to any other person and any such actions are unlawful. This  e-mail may
> contain viruses. Infosys has taken every  reasonable precaution to
> minimize this risk, but is not  liable for any damage you may sustain as
> a result of any  virus in this e-mail. You should carry out your own
> virus  checks before opening the e-mail or attachment. Infosys  reserves
> the right to monitor and review the content of all  messages sent to or
> from this e-mail address. Messages sent  to or from this e-mail address
> may be stored on the Infosys  e-mail system.
>  ***INFOSYS******** End of Disclaimer ********INFOSYS***
>
>  _______________________________________________
>  SAP-WUG mailing list
>  SAP-WUG at mit.edu
>  http://mailman.mit.edu/mailman/listinfo/sap-wug
>
>  If you are not the addressee, please inform us immediately  that you have
> received this e-mail by mistake, and delete  it. We thank you for your
> support.
>
>
>  _______________________________________________
>  SAP-WUG mailing list
>  SAP-WUG at mit.edu
>  http://mailman.mit.edu/mailman/listinfo/sap-wug
>
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>
> If you are not the addressee, please inform us immediately that you have
> received this e-mail by mistake, and delete it. We thank you for your
> support.
>
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>

More information about the SAP-WUG mailing list