SRM 4.0 SC Completion/Approval sequence & EU directive Article 32

Mark Pyc mark.pyc at gmail.com
Tue Mar 7 14:44:48 EST 2006


G'day Sue,

thanks for the comprehensive response!!

I should have mentioned that at this stage the expectation is they won't be
using Sourcing Cockpit which I think would take away some of my concerns.

Extended Classic would also make the overall design more straight-forward.

Ah well, it'll keep me entertained.

Has anyone used late Buyer Completion as opposed to Soucing Cock-pit?

Thanks,
Mark


On 07/03/06, Susan R. Keohan <keohan at ll.mit.edu> wrote:
>
> Hi Mark,
>
> In our current EBP 3.5  environment, financial approvals are completed in
> EBP on the Shopping Cart
> prior to the transferral to R/3 backend as a requisition.  In R/3, the
> buyer creates the PO from the
> Req, with 'guidelines' to make changes only in the Purchase Order.  By
> urging the buyers to make the
> changes only in the PO, not the requisition, we compare the PO to the req,
> and determine if
> 'significant changes' were made.  If so, we have workflow for monetary
> approvals in R/3 on the PO.
> Not the best possible scenario, but it has worked for 3 years.
>
> Now we are upgrading to SRM 5.0, Extended Classic.  Our intent is to have
> all approvals, financial
> or otherwise, occur on the Cart.  The approved cart goes to the sourcing
> cockpit, as you no doubt
> already know.  At this point, as the buyer is working on the Cart, our
> hope is that if any
> substantial financial changes need to be made, the buyer contacts the
> responsible party before
> creating the PO.  Of course, this is a little fuzzy, and is no more a rule
> than our 'guidelines' in
> the current state. Once the PO gets created in SRM, there will be a
> minimum of approvals (by the
> Purchasing Department).
>
> Subsequent changes to Purchase Orders will also have approvals (financial
> and otherwise) but will
> all take place in the SRM web front-end.  Much nicer for our users.
>
> So, we already do what your client is contemplating, both in our 'as-is'
> and in our 'to-be', except
> for the Extended Classic approach in the brave new world.
>
> Hope this helps,
> Sue
>
> Mark Pyc wrote:
>
> > G'day Wuggers,
> >
> > The general recommendation (and the only way I've seen implemented) is
> > to invoke the Buyer Completion WF for incomplete carts prior to
> > Financial Approval. My current client is contemplating reversing this
> > order so that Financial Approval will be confirmed before the buying
> > group will be involved in completeing the cart.
> >
> > I understand that this will bring in the potential for changes at a
> > late stage which will cause the cart to run back round the Financial
> > Approval loop.
> >
> > Has anyone implemented such a scenario? What comments do you offer?
> >
> > I believe this desire has come as a result from the client previous
> > experience in EBP 3.5 whereby incomplete carts were approved and then
> > sent to the ECC/R3 backend as a requisition. Therefore buyer
> > completion took place in the form of conversion from PReq to PO. In
> > the new solution the intention is to perform buyer completion in SRM
> > so that all carts are transfered as PO's. So although they are
> > implementing a new process the desire is to keep the basic sequence of
> > Approval prior to Buyer Completion.
> >
> > FYI - The intention is to use Classic rather than Extended Classic.
> >
> > Any comments??
> >
> > Somewhat less technically WF, has anyone implemented SRM Purchasing
> > which handles EU Article 32 compliance for Public Purchasing?? This
> > directive requires a mini-tender process where framework orders exist
> > for the same Good or Service with multiple vendors. The proposed
> > solution here is simply to invoke the Buyer Completion WF even though
> > the cart will be technically complete.
> >
> > Again, any comments warmly welcomed.
> >
> > Have fun,
> > Mark
> >
> > _______________________________________________
> > SAP-WUG mailing list
> > SAP-WUG at mit.edu
> > http://mailman.mit.edu/mailman/listinfo/sap-wug
> >
>
> --
> Susan R. Keohan
> SAP Workflow Developer
> MIT Lincoln Laboratory
> 244 Wood Street
> LI-200
> Lexington, MA. 02420
> 781-981-3561
> keohan at ll.mit.edu
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20060307/4e3bd766/attachment.htm


More information about the SAP-WUG mailing list