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