SRM 4.0 (EBP 5.0) - Line Item SC approval, Completion required for new Line
Adao-Cruz, Miguel
miguel.adao-cruz at capgemini.com
Wed Jul 19 06:58:55 EDT 2006
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 12895 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/sap-wug/attachments/20060719/c636a239/attachment.bin
-------------- next part --------------
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
More information about the SAP-WUG
mailing list