SRM 4.0 (EBP 5.0) - Line Item SC approval, Completion requiredfor new Line
Baunach, Natasha R
natasha.r.baunach at intel.com
Mon Nov 20 13:27:37 EST 2006
I heard the same rumor as well.
-----Original Message-----
From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
Of Susan R. Keohan
Sent: Monday, November 20, 2006 6:56 AM
To: SAP Workflow Users' Group
Subject: Re: SRM 4.0 (EBP 5.0) - Line Item SC approval, Completion
requiredfor new Line
Thanks Mark!
Interesting rumor... Hmmm.
Mark Pyc wrote:
> 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
> <mailto: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>
> > <mailto: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/>
> > <http://www.capgemini.com <http://www.capgemini.com/>>
> > <
> >
>
file:///C:\Documents%20and%20Settings\madaocru\Application%20Data\Micros
oft
>
> > \Signatures\www.capgemini.com>
> >
> > Join the Collaborative Business Experience
> >
>
________________________________________________________________________
___
> >
> >
> > ________________________________
> >
> > From: sap-wug-bounces at mit.edu
> <mailto:sap-wug-bounces at mit.edu> <mailto: 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>
> > <mailto: 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 <http://www.capgemini.com/>>
> > < http://www.capgemini.com/>
> > <
> >
>
file:///C:\Documents%20and%20Settings\madaocru\Application%20Data\Micros
oft
> >
>
<file:///C:\Documents%20and%20Settings\madaocru\Application%20Data\Micro
soft
> >
> >
>
<file:///,DanaInfo=owa+C:\Documents%20and%20Settings\madaocru\Applicatio
n%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>
> > <mailto: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>
> > <mailto: 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/>>
> > < http://www.capgemini.com/>
> > < http://www.capgemini.com/>
> > <
> >
> >
>
file:///C:\Documents%20and%20Settings\madaocru\Application%20Data\Micros
oft
>
> >
>
<file:///,DanaInfo=owa+C:\Documents%20and%20Settings\madaocru\Applicatio
n%20
> > Data\Microsoft>
> >
> >
>
<file:///,DanaInfo=owa+C:\Documents%20and%20Settings\madaocru\Applicatio
n%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>
> > <mailto: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>
> <mailto: 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>
> > <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><mailto: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> <mailto:
> 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
>
> --
> 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 <mailto:keohan at ll.mit.edu>
> _______________________________________________
> 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
More information about the SAP-WUG
mailing list