SRM 4.0 (EBP 5.0) - Line Item SC approval, Completion required for new Line
Mark Pyc
mark.pyc at gmail.com
Mon Nov 20 09:36:14 EST 2006
G'day Sue,
It is indeed. OSS some times seems to choke a bit, and it may well turn up
again tomorrow.
See below for the limited detail it offers.
Also heard an interesting rumour on the grapevine yesterday. In the next
version of SRM ( 6.0 ) they are getting rid of n-step BAdI entirely with no
upgrade path. Apparently it will all be configurable. Sounds too good to be
true and I bet it is.
Have fun,
Mark
Symptom
Only after changes are made to the price and the quantity does the requester
receive a work item to accept the changes.
Other terms
WS14500015 LIA, line item based, RESTARTAPPROVALSTEP, TS14508045
Reason and Prerequisites
The line item-based approval workflow is used. The requester is checked only
if an approver has changed the value of the shopping cart.
For changes that do not affect the value, a work item is not created for the
requester. A workflow restart is not requested as described in Note 777133,
but the requester in the current workflow is asked to accept.
Solution
Implement the BBP_WFL_EMPL_WI_BADI BAdI.
- The BAdI is not provided in the IMG, but if it is activated it is
successfully called.
Implement the BAdI using Transactions SE18, SE19.
- In the CHECK_REQUESTER_WI method you can set the following
parameters:
SEND_TO_REQUESTER creates work item for requester
OVERWRITE_SYST_BEHAVIOUR activates change to the standard
behavior
On 11/20/06, Susan R. Keohan <keohan at ll.mit.edu> wrote:
>
> Hi Mark, Miguel,
>
> Can you confirm that the OSS note you refer to here is 838575 ? I am
> searching OSS for docu on the BADI BBP_WFL_EMPL_WI_BADI and can't find
> anything. This note appears to have gone into hiding.
>
> On the other hand, if anyone even has the German docu for this BADI, can
> you please send it along ? My German is good enough that I can usually
> decipher the big words.
>
> Thanks!
> Sue
>
> Mark Pyc wrote:
> > Thanks again Miguel.
> >
> > That's amazing! That note answers my question from a month ago exactly
> > and I was stunned that I hadn't found it, but it doesn't like to be
> > found. I just tried searching OSS for both "WS14500015" and
> > "BBP_WFL_EMPL_WI_BADI" and in neither case is it returned despite the
> > fact that both terms appear in the note. I wonder how often that happens
>
> > and useful notes choose not to be found. Strange.
> >
> > Have fun,
> > Mark
> >
> >
> > On 7/20/06, *Adao-Cruz, Miguel* <miguel.adao-cruz at capgemini.com
> > <mailto:miguel.adao-cruz at capgemini.com>> wrote:
> >
> > Hi,
> >
> > I once used this BADI. See OSS note 838575.
> >
> > Code:
> > method IF_EX_BBP_WFL_EMPL_WI_BADI~CHECK_REQUESTER_WI.
> >
> > send_to_requester = 'X'.
> >
> > overwrite_syst_behaviour = ' '.
> >
> > endmethod
> >
> > Not sure that's really necessary.
> >
> > 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
> > \Signatures\www.capgemini.com>
> >
> > Join the Collaborative Business Experience
> >
> ___________________________________________________________________________
> >
> >
> > ________________________________
> >
> > From: sap-wug-bounces at mit.edu <mailto:sap-wug-bounces at mit.edu> on
> > behalf of Mark Pyc
> > Sent: Wed 19/07/2006 15:01
> > To: SAP Workflow Users' Group
> > Subject: Re: SRM 4.0 (EBP 5.0) - Line Item SC approval,Completion
> > required
> > for new Line
> >
> >
> > 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
> > <mailto: 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
> > < http://www.capgemini.com>
> > <http://www.capgemini.com/>
> > <
> >
> file:///C:\Documents%20and%20Settings\madaocru\Application%20Data\Microsoft
> > <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>
> >
> > Join the Collaborative Business Experience
> >
> >
> ___________________________________________________________________________
> >
> >
> > ________________________________
> >
> > From: sap-wug-bounces at mit.edu
> > <mailto: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
> > <mailto: 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>
> > <http://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>
> >
> >
> <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
> > <mailto: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 <mailto:SAP-WUG at mit.edu>
> > http://mailman.mit.edu/mailman/listinfo/sap-wug
> > <http://mailman.mit.edu/mailman/listinfo/sap-wug >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > SAP-WUG mailing list
> > SAP-WUG at mit.edu <mailto:SAP-WUG at mit.edu>
> > http://mailman.mit.edu/mailman/listinfo/sap-wug
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > SAP-WUG mailing list
> > SAP-WUG at mit.edu <mailto: 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
>
> --
> Susan R. Keohan
> SAP Workflow Developer
> MIT Lincoln Laboratory
> 244 Wood Street
> LI-200
> Lexington, MA. 02420
> Phone: 781-981-3561
> Fax: 781-981-1607
> 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/20061120/f0785401/attachment.htm
More information about the SAP-WUG
mailing list