<div>Hello Sue</div>
<div>This is an interesting lesson to learn... thank you for sharing. </div>
<div>We are in the Concept Intiation phase of a technical upgrade from </div>
<div>R/3 4.6 ---> ECC 6 </div>
<div>eBP 3.0 ---> SRM 5.0 (Self Serve scenario) </div>
<div> </div>
<div>We have 12 customised workflow for :</div>
<div>SC Self Approval</div>
<div>SC multi-level Approval </div>
<div>SC on and Internal Order</div>
<div>Vendor Confirmation Approval </div>
<div>Internal Confirmation Approval </div>
<div>P-Card Approval </div>
<div> </div>
<div>Are there any other heads up, lesson learned or pointers that you could share that with us to help with the above endeavour. </div>
<div> </div>
<div>Thanks</div>
<div>Shals</div><br><br>
<div><span class="gmail_quote">On 10/16/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">All,<br><br>We are on SRM 5.0, developing custom workflows,but based on the N-step<br>BADI workflows as a model. We had copied the N-step BADI workflows to
<br>customer versions, and then applied changes as necessary to incorporate<br>all our own routing requirements.<br><br>In the PO workflow, we noticed that on one level of approval, even if<br>one of the selected agents processed the PO, the workflow log showed the
<br>workitem as 'forwarded'... and the workitem was still awaiting<br>processing. Some hours and hours of debugging followed, to little, or<br>no avail. Various tricks, such as using BBP_WFL_TRACE provided<br>interesting, but basically useless, information.
<br><br>Long story short, we overlooked a feature in the N-Step BADI workflows.<br>At the workflow definition header-level, where the container elements<br>are defined, the SAP-delivered workflows have a container element
<br>'Subworkflow Number', with an initial value set (for example,<br>WS14000145). When we copied the workflows over, these initial values<br>came along. When we deleted this initial value, the workflow no longer<br>mis-behaved.
<br><br>I am sure someone with a deeper knowledge of SRM/WF can explain why this<br>is so. For now, I am just happy that the issue is resolved.<br><br>Happy WF-ing.<br>Sue<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>