workflow

[Former Member]

Hi,

Coukd you share workflow configuration documents or any material or any links?

Help will be rewarded

Cheers

Rami

[Former Member]

This message was moderated.

[Former Member]

This message was moderated.

[Former Member]

Thank you a lot

[Former Member]

Hi Atul,

Yu have any documents in CRM side?

Thanks in advance,

Cheers

Rami

[Former Member]

Hi Rami,

You can use standard Work Flows defined in the system for various business objects.

You have no approval work flow, one step approval work flow, 2- step approval work flow and N-step approval (using a BADI)

You can activate the work flow for a business object using SWB_PROCUREMENT transaction and the agent can be assigned using SWDD (Work Flow Builder) transaction.

You can also use SWE2 (Event linkages) for linking work flows with the events for business objects (like SC, P.O, BID Invitation, Contract, Confirmation etc)

For multiple approvals (At item level,at header level & number of approvals) you can use N-step approval BADI BBP_WFL_APPROV_BADI

You can use the BAdI BBP_WFL_APPROV_BADI in the following three workflow scenarios:

1. Implementing a dynamic n-step approval process for shopping carts

(using the workflow WS14000133 N-step approval of shopping cart [BAdI])

2. The approval workflow WS14000145 N-step approval for PO also uses this BAdI for determining the N-step dynamic approval process for purchase orders (PO) and change versions of purchase orders (PO-CV).

The dynamic parts are the number of levels in the process and the number of approvers for each approval level. The approvers and the requirement for further approval steps are determined before the first approval and after every subsequent approval step. This means that any conditions that change during the approval are taken into account. Therefore, after saving an SC or a PO/PO-CV, there is no longer a rigid predefined approval chain, instead the scope and the structure of the chain are continually adapted.

Note:

Relevant workflows are also available for bid invitation (WS14500028), contract (WS14000148), and bid (WS14500044). These provide identical functionality for these documents.

3. Implementing a dynamic n-step Approval process for shopping carts on an item level

(using the workflow WS14500015 Item-based approval).

Application example for 1.:

a) After a shopping cart is saved, Manager1 is defined as the first approver.

Manager1 rejects the shopping cart.

A second approval by Manager2 is therefore unnecessary (although originally, if Manager1 had approved the cart, Manager2 would also have to approve it).

b) Manager1 adds items to the shopping cart, which increases the value of the cart, so that a second approval step becomes necessary and Manager2 is determined as the approver (although originally only approval by Manager1 would have been necessary).

You can use the method GET_REMAING_APPROVERS to define approvers for any approval step in the approval procedure (you can also define multiple approvers per step).

You can also define how many steps are included in the whole approval procedure.

Example:

The following is a possible example of a business application in which it may be necessary for approvers to be determined according to your own model:

• Total value SC Approval level 1 Approval level 2 Approval level n

... 1.00,- - - -

... 1.000,- Manager 1 Manager 2 -

... 10.000,- Manager 1 Manager 2 Manager n

Total value of SC: Total value of the shopping cart

approver/s 1 to n: Approver/s per approval level

*: according to individual requirements, plant and/or cost center, etc.

You can also specify more than one approver for each approval level.

(In the approval procedure, these must then all approve the step before the next approval step can be processed).

Application example for 3.:

While the approvers determined in 1 always receive the whole shopping cart (all items) for approval, in 3 there is also the option to limit the responsibility of the defined approvers to particular items. The approver can then only change and approve/reject these items. In this case, in addition to the approvers for each approval step, in the method GET_REMAING_APPROVERS you also need to determine for which items in the shopping cart the approvers are responsible.

Items in the shopping cart that are to be approved by the same approver in the approval step are grouped together into "Approval Objects". The approver then only receives one work item for each approval object.

For each approval step, you can also define whether the approver can view the other items, for which he/she is not responsible. (In the BAdI implementation: hide_items_not_responsible = a, if a = 'X', then only the items relevant for approval are visibler, if a = ' ', then all other items are also visible.)

Example:

The following is a possible business application example that is also an SAP example implementation SAP_LIA_BADI_EX_SIMP for this BADI.

In this implementation, two approval steps were planned:

4. Approvers are determined depending on the cost center for which the shopping cart items are being ordered.

5. Approvers are determined depending on the product category.

In this implementation, the approvers are selected from the SAP example table BBPT_WFL_LIA_DEF.

The corresponding customer table for the approvers could be as follows (but do not necessarily have to be)

Approval criterion VALUE Approver

COST_CTR 1000 Manager3

COST_CTR 1000 Manager4

COST_CTR 1200 Manager2

COST_CTR OTHERS Manager6

PROD_CAT QW501 Manager7

PROD_CAT OTHERS Manager10

The values in this table are only examples!

In this example, Manager3 or Manager4 would be responsible for the items ordered for cost center 1000, Manager 2 for cost center 1200, and Manager6 for all other cost centers.

In the 2nd approval step, Manager7 would approve the items in the product category QW501, and Manager10 would approve all other items.

Activities

For the method GET_REMAING_APPROVERS, the following parameters are available:

Import

OBJECT_ID

The object ID is the unique document number.

OBJECT_TYPE

Business process type or Business object type.

For SC: BUS2121

For PO/ PO-CV: BUS2201

GUID

Global Unique Identifier

ACTUAL_APPROVAL_INDEX

Current step in the approval procedure.

(approvers for the subsequent steps are determined.)

APPROVAL_HISTORY_TABLE

List of approvers who have approved up to the current step.

ITEM_APPROVAL_HISTORY_TABLE

Only relevant for item-based approval!

List of the approval objects and the corresponding item(s) in the shopping cart that have been approved up to the current step.

ITEM_DEDUCT_RESET (*)

DELETE_REJECTED_ITEMS (*)

IN_UPDATE (*)

Export/Change

APPROVAL_TABLE

List of all subsequent approvers for each approval step.

APPROVAL_ADMINISTRATORS

List of administrators in case no approver is found, but approval is required.

(also see the Export Parameter NO_FURTHER_APPROVAL_NEEDED!).

ITEM_APPROVAL_TABLE

Only relevant for item-based approval!

List of approval objects and the corresponding items(s) in the shopping cart, that are to be approved in the future.

NO_FURTHER_APPROVAL_NEEDED

Boolean variable.

If true -> no further approval is required

ITEM_APPROVAL_OBJ

Only relevant for item-based approval!

List of approval objects and the corresponding approval criteria.

The approval criteria are used to prevent the system having to determine new GUIDs for the approval objects every time the BAdI is called.

As in the example implementation, use the SAP function module BBP_WFL_DIN_APP_OBJ_GET, to fill this table.

Further notes

BAdI-Implementierung

The standard system contains two example implementations, which return the approvers for the different approval steps based on the table BBPT_WFL_LIA_DEF.

In the simple example SAP_LIA_BADI_EX_SIMP, the system evaluates which approvers are responsible for the different cost centers or product categories.

In the second, more complex BAdI implementation SAP_LIA_BADI_EXMPL_2, there is also the option of determining the different approvers or approver groups based on an additional criterion (the value of the approval groups).

You need to ensure that the call of the function module GET_REMAING_APPROVERS in consecutive BAdI calls uses constant parameters, as long as these have not changed (so they have the same approval criteria). Otherwise, the function module call returns a changed approval object GUID.

If this is not taken into account, the workflow interprets the structure as changed and consequently all manually changes by approvers are discarded.

Note that there must be absolutely no gaps in the approval steps and that approvers must be defined for every step.

This was established in the example implementations, where an entry OTHERS is always available in the table BBPT_WFL_LIA_DEF , which obviously also needs to be evaluated by the BAdI.

(*) Note

See the following SAP Notes 866496 (Item approval: Problems with restart), 784408 (Item approval: Rejected items in BADI) and 826637 (Item approval: Rejection results in problems)!

Hope this will give you some idea about Work Flows.

Award points for helpful answers.

Rgds,

Teja