SRM 4.0 (EBP 5.0) - Line Item SC approval, Completion required for new Line
Mark Pyc
mark.pyc at gmail.com
Wed Jul 19 10:01:22 EDT 2006
Thanks Miguel, although not what I wanted to hear really. It is possible to
add incomplete items to a cart in process, so I guess I'll have to prevent
it via BBP_DOC_CHECK_BADI.
On a side note has anyone made use of the BAdI *BBP_WFL_EMPL_WI_BADI*? It
doesn't come with any doco and I can't find a reference to it anywhere (WUG,
SDN, OSS, Google). It does however seem to answer my original question about
how to send all changes back to the Requestor.
Have fun,
Mark
On 7/19/06, Adao-Cruz, Miguel <miguel.adao-cruz at capgemini.com> wrote:
>
> Hi All,
>
> Mark, OSS is right in saying it shouldn't, at least according to their
> design. Business/process side it could be disputed but SAP cannot provide
> scenarios for all options (it is already quite complicated this way ;-).
> In my last two implementations I used the shopping cart Line Item approval
> workflow. You could try to make it work this way but I can already
> garantee
> you weeks of pain!
> Because:
> - The line item workflow is hard coded in the SAP standard code.
> - Sometimes it is directly triggered by a WAPI function.
> -->That's why it is not possible to create a Z copy of this template and
> used it (-->deadlines cannot be created the standard way)
> - I don't have a system to check, but I dont' think that while in approval
> process the system will allow you to add incomplete items --> you would
> need
> to at least use BADI for the check function
> - I don't think you can start a completion workflow for a shopping cart in
> approval process because of the internal status management (I don't even
> think about trying to change this!)
> - The approval preview pane would be a mess with a shopping cart going for
> completion, then approval, then completion again, then approval again!!
> - Your time from shopping cart creation to PO output could become weeks.
> - ....
>
> I heard that others implementations (not done by me) in some clients, to
> comply with EU directives about tenders, run the completion workflow
> (again?) after the approval. But, I never investigated it and anyway
> that's
> maybe not good for your client neither.
>
> I would simply recommend:
> - Approver to reject/delete shopping cart with a note to the creator
> explaining why and the creator to recreate a new shopping cart with the
> additional incomplete line(s) (copying from the initial shopping cart).
> - The approver to create another shopping cart with the additional
> incomplete items (or ask the creator to create it) while the first
> shopping
> cart follows its approval process.
>
> Hope it will help.
>
> Cheers
>
>
> ___________________________________________________________________________
> Miguel Adao-Cruz | Capgemini | London
> Technology Services
> SAP Application Architect
>
> T.+44-870-238-2927 | Int.700 2927 | www.capgemini.com
> <
> file:///C:\Documents%20and%20Settings\madaocru\Application%20Data\Microsoft
> \Signatures\www.capgemini.com>
>
> Join the Collaborative Business Experience
>
> ___________________________________________________________________________
>
> ________________________________
>
> From: sap-wug-bounces at mit.edu on behalf of Mark Pyc
> Sent: Wed 19/07/2006 09:01
> To: SAP Workflow Users' Group
> Subject: SRM 4.0 (EBP 5.0) - Line Item SC approval,Completion required for
> new Line
>
>
> G'day all,
>
> Firstly thanks Miguel for your response. I've been distracted for a while
> and have since been testing alternative concepts. I agree with you that
> using standard completion (well modified std as you've described) does
> seem
> the best option and I've gone through some redesign with the business to
> make this a possible solution.
>
> However now comes the next hurdle....
>
> Can anyone confirm if they are using the Completion Workflow WS14000044
> (or
> modified copy) and the Line Item approval Workflow WS14500015? (Miguel I
> wasn't sure if from the answer below you were using Line Item or just the
> BAdI cart level).
>
> When an incomplete item is added to the cart during line item approval
> does
> the Completion WF get invoked again?
>
> I believe it should. OSS are telling me it shouldn't.
>
> Thanks,
> Mark
>
>
>
>
> On 6/6/06, Adao-Cruz, Miguel <miguel.adao-cruz at capgemini.com> wrote:
>
> Hi Mark,
>
> My solution works the way you describe it (all users with level 2).
> It is
> standard.
> Depending on BBP_WFL_SECURITY value the main workflow is restarted
> or not (I
> think it as well check starts conditions) if shopping cart
> "changed",
> "Changed" here means, changes according to SRM (I believe)
> hard-coded
> criterias which are more or less related to line item values. Main
> workflow
> restarted means re-processing previously processed approval levels.
> It
> doesn't directly influence if shopping cart is sent to requester
> and
> which
> type of changes should send it to requestor to accept changes.
> If you are planning to use first approval level for completion it
> means that
> the price and/or the vendor will be missing (standard understanding
> of SRM
> for incomplete shopping carts). Adding the price will send the SC
> to
> the
> requester. The problem will be that adding a vendor does not send
> SC
> to
> requester (pay attention to the distention between "vendor" and
> "preferred
> vendor", usually approvers cannot add "vendors").
> I would have a look at shopping cart change documents settings:
> maybe it
> influences the way SRM sees a shopping cart being changed.
> You could maybe increase the value of the line item by one cent if
> the
> vendor is changed/added, via a BADI and then remove it. (I already
> regret
> what I have just writen!!)
> You could maybe use the BADI for BBP_WFL_SECURITY, and change it's
> value
> depending on the user role and approval index.
> etc...
> But before going this way you could maybe explain what are your
> client
> requirements that make the standard completion workflow not usable.
>
> Cheers.
>
>
>
> ___________________________________________________________________________
> Miguel Adao-Cruz | Capgemini | London
> Technology Services
> SAP Application Architect
>
> T.+44-870-238-2927 | Int.700 2927 | www.capgemini.com
> <http://www.capgemini.com/>
> <
>
> file:///C:\Documents%20and%20Settings\madaocru\Application%20Data\Microsoft
>
> <file:///,DanaInfo=owa+C:\Documents%20and%20Settings\madaocru\Application%20
> Data\Microsoft>
> \Signatures\www.capgemini.com,DanaInfo=OWA.UKI.CAPGEMINI.COM+>
>
> Join the Collaborative Business Experience
>
>
> ___________________________________________________________________________
>
> ________________________________
>
> From: sap-wug-bounces at mit.edu on behalf of Mark Pyc
> Sent: Mon 05/06/2006 18:08
> To: WUG
> Subject: SRM 4.0 (EBP 5.0) - Logic of LIA BADI so requestor
> approves
>
> allchanges
>
>
> G'day all,
>
> More questions from me on the line-item approval of Shopping carts
> I'm
> afraid.
>
> Within my required solution the first level approvers needs the
> ability to
> change carts but the requester should be given the opportunity to
> review
> these changes.
>
> Access to change the cart is controlled via Personalisation Level
> BBP_WFL_SECURITY. I figured that a value of 2 would be appropriate
> as this
> is described as "Low - Workflow is always restarted when changes
> are
> made".
> However with this setting if the Approver actually
> "Accepts/Approves" a line
> and changes it, the only time the requester is informed is if the
> value of
> the item changes. At this point the requester receives a Workitem
> based on
> TS14508045 (from within WS14500013) to accept.
>
> No other changes produce this behaviour. Rather the changes are
> simply made
> and the cart approval continues. Changes to Free Text description
> (in the
> case of Describe Requirement items), Prod.Cat, UoM, Delivery Date,
> Delivery
> Address, Price & Qty (such that the value of the item doesn't
> change) or
> even changing the name of the cart do not seemed to be considered
> 'significant' as the requester is not informed. Only if the value
> of
> the
> item changes.
>
> What I'd like is for any and all of these changes to result in the
> Cart
> being sent back to the requester. It seems very strange that the
> value of
> the item is the only important change. The requester doesn't
> necessarily
> care if the value changes as long as it's approved, but a change to
> the text
> of a free text item has to be considered crucial!?!
>
> As an alternate concept I thought about simply using the BAdI to
> set
> the
> requester as an approver for any changed items, but they would then
> need to
> reject any items they weren't happy with and then accept their own
> rejections (not very nice at all). Moving in this direction I set
> the
> Approvers value for BBP_WFL_SECURITY to 4 (which is described as
> "High -
> workflow is never restarted when changes are made" but this seemed
> to be no
> different to a value of 2. Changes that change the line item value
> are sent
> back for Requester review. This is messy as it means that my
> concept
> of
> Requester as Approver will not be consistent as value changes will
> result in
> the TS14508045 Workitems.
>
>
> Is there a way to force any and all changes back to the Requester
> for
> review?
>
> I have read note 777133 about handling restarts, but as best I can
> tell this
> restarts the approvals, but does not invoke a Requester review.
>
> In reading the archives I saw a posting by Miguel Adao-Cruz that
> included
> the statement:
> > I am not using "restart based on history tables" as my client
> wants
> rejections to be approved by requestors.
>
> It sounds like you were doing what I'm hoping for Miguel. Can you
> provide
> any insight? I'm hoping to use the first level of approval as a
> means of
> line-item based completion (thanks for your previous responses).
>
> I hope someone can help.
>
> Have fun,
> Mark
>
> _______________________________________________
> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20060719/046a48a2/attachment.htm
More information about the SAP-WUG
mailing list