on 01-06-2015 2:59 PM
Good afternoon Experts,
Could you please assist me in finding a suitable solution for the following business case.
In CRM 7 ehp 2 a quotation approval workflow is needed.
Once a quotation is set for approval, the wf should check the quantity, price, and total value of the document against predefined thresholds maintained in a custom table. A responsible manager (local, regional or national) should be decided based on the comparison result.
So, the wf starts once an event is raised by changing the status to "to be approved" and the quantity, price, and total value of the quotation should be compared to the threshold values by using a condition step.
Could you please suggest how I should approach the thresholds table . Should it be a simple/multiline attribute ? Or should I pick the values and use them in container ? If populating a container is the right answer could you please confirm if this is the right direction :
"Initializing a container
You must initialize a container before you use it. This deletes all entries in the internal table. Use the macro following macro instruction:
SWC_CREATE_CONTAINER <Container>.
"
Best regards
Razvan Zainea
Hello,
You don't have to initialize any containers.
You could use a responsibility rule (AC.....) for this if it's relatively simple. If it's not, or if you must use a Z table, then create a method to determine the Approver. Have it copy the contents of the Z table to an internal table in normal ABAP and process it just as you would in ABAP, returning the userid of the Approver.
regards
Rick Bakker
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Good afternoon Rick
This answers my scenario. Thank you very much!
I will be marking your reply as correct.
Strictly from a technical point of view could I ask what would you have chosen if a condition was in order? Would you have went with an attribute or a container ?
Best regards
Razvan Zainea
Whether you should use a container or an attribute - there is no simple answer for that.
I like to think that business object attributes should include the fields/attributes of the actual business entity/object such as document number, document type, amounts, etc - everything that is in the application table(s). From my point of view approver (responsible manager in your case) is not this kind of data. Some developers might disagree about this, and I know that some developers like to have the agents as object attributes.
- When the object gets instantiated (this might happen many times during the life span of the workflow), all the attributes are "calculated". If you had some heavy calculations the populate the attribute, this calculation will happen many times - for example if you just open the workflow log (just put a breakpoint to the code of the business object and you will see). It is not that big deal if you just get the data from some Z-table.
- One annoying thing is also that if you need to take a look to an older case afterwards (mainly take a look to the workflow log), and there has been changes to your Z-table (=there is a new responsible manager), basically the business object in the workflow log will show you wrong approver since it is getting the current data (new approver) from the Z-table
Short answer: I would populate the agent(s) into workflow container. (Of course the best option is to use the rule as Rick already said.)
Kind regards,
Karri
Good afternoon Rick
*This reply is strictly referring to the case where I need to use the z table values in a condition step; the question is the same: how to pick up the z table values in the condition (container vs attribute)
- By container I am referring to the "technical" workflow container which
can be used to hold different values . I was thinking this container could be filled by using a bapi/macro/zprogram and then used in the condition step.
- By attribute I am referring strictly to the object attribute as seen in swo1. (so a new attribute would be created with the value of the z table and then used in the condition step)
Rick, you mentioned a method container, were you thinking about reading the z
table via a method in a separate step and then passing the values to the condition
step?
*All the information received on this post is very useful.
*Regarding this scenario I also understood from Karri's reply that making an attribute wouldn't be that hard but the workflow log could suffer.
Thank you for your patience.
Best regards
Razvan Zainea
Really the options to "get data" into workflow (or its container) is using either attributes of a business object (or a class) or container elements (eventually its the same thing since the business object is in a container element). Now in your case you are interested of filling the container element(s). As Rick said you can do this by adding a step into the workflow. The step should return the needed fields/values to your container.
> I was thinking this container could be filled by using a bapi/macro/zprogram and then used in the condition step.
Whatever you do, don't try to fill the container from outside the workflow (zprogram, bapi or whatever). Basically this is possible e.g. with SAP_WAPI_WRITE_CONTAINER function, but you should have a really good reason to do this.
One option might be that if you have access to the code from where the workflow gets started, you could possibly deliver the needed values to the container already from that phase. For example if the workflow was started with an event, you could deliver data to the workflow container as event parameter.
Regards,
Karri
User | Count |
---|---|
83 | |
23 | |
11 | |
9 | |
8 | |
5 | |
5 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.