Workflow Configuration

The description below is for the standard workflow and configuration set up. Many customers have plugins to give additional or more complex workflow routing scenarios and then this description may not be relevant.

The standard decision tree is /PROMENTA/WSFI_JP005_APP_RULES

Decision Tree Structure

The decision tree is split into sections – some control the config and some control the actual process flow of the workflow

Groups : Defines grouping of lineitem data to be used in workflow routing (eg groups of GLs)

Value levels : Defines the approval thresholds to be used

Phase List  : Defines the phases of workflow approval (pre-approval , main approval and post approval)

Workflow Groupings

Groupings are master data items which can be grouped together to enable the wporkflow to make routing decisions.

Business Example :

You may define a group of GL accounts that are classed as “expense” accounts. You may define another group of GL accounts as “income” accounts.

Then you can define workflow routing such that all journal request containing “expense” accounts can be sent to one team and all income accounts sent to another team.

Available master Data objects

You can create a group based on : GL accounts [HKONT], Cost centres [KOSTL] or profit centres [PRCTR]. 

A group definition is split into the group basic data (its type = GL, cost centre etc) and its values

Config Example :

Account Group id GL1 – is defined as GL account [HKONT] with a range of values : X110000 and between 200000 and 400000

Routing Usage

Use in routing node is formatted as follows :

Parameter DATAKEY        Value :  GROUP_<id of group>=FOUND

Example 

Showing routing for group GL1

Journal Value

The journal value is the calculated amount that is used to define the “Value” for workflow routing.

Tree : /PROMENTA/WSFI_JP005 

Node : Config –> Workflow Config –>WF Additional control settings

APPR_AMOUNT_CALC=TOTAL

This calculates the total debits/credits for the journal. This is the default behaviour if nothing is specified

APPR_AMOUNT_CALC=HIGH_1

This extracts the highest single lineitem and uses that as the approval amount

In the case of multiple journals in the same sheet the following additional settings can be made. It is recommended to align with the single-sheet settings above

MULTI_WF_MODE=FIRST

Use the first found sheet result as the routing value. This is the default behaviour to align with legacy applications

MULTI_WF_MODE=HIGHTOT

Use the highest total value across all sheets. This is sued in conjunction with APPR_AMOUNT_CALC=TOTAL

MULTI_WF_MODE=HIGH_1

Use the highest single lineitem value across all sheets. This is used in conjunction with APPR_AMOUNT_CALC=HIGH_1

Value Ranges

Value ranges are used to categorise the request according to its journal value (see above).  The value range is converted into the Approval currency first so that all requests can be categorised in the same way.

Value ranges can differ by process code and also by company code.

Config example

In the example below the range for “non-recurring” journals has 3 levels.

  • Level 0 = between 0 and 99,999
  • Level 1 = between 100,000 and 499,999
  • Level 2 = between 500,000 and maximum 

Routing – Overview

Routing rules define how the workflow actually directs the requests based on the values in the request and the parameters defined above (groupings, value levels etc)

Values are iterated until the top for each request. So if a journal has value level 2 – it will go for approval at level 0 and then level 1 before it goes to level 2.

Routing can be broken into 3 phases for added flexibility. Each phase can contain multiple approvals and use all of the values and parameters available.

Phase 1 : Pre-approval.

Use this when you need to first route a request to a team for validation or other activity before it can go into the “main” approval flow

Phase 2 : Main approval

This is the main approval where the business approvers are determined and routed to.

Phase 3 : Post-approval

Use this when you need to route to a team after all business approvals are received. This team may perform additional technical activities such as checking on impact to period close etc.

Posting

Posting only occurs after all approvals across all 3 phases are completed.

Close-plus days

Some organisations need to route and control their workflow based on the number of days after period close the request is as this can have an impact on the closing process. Promenta can determine the number of days after the close period (close-plus days) CP Number.

This information can then be used in workflow routing to achieve additional approvals or prevent submission.

Routing Rules

Routing is determined by evaluating the decision tree multiple times per value level.

The tree structure is flexible but each evaluation must result in an approval group (team of approvers). Over several iterations a complete approval flow for the specific request will be built.

Available parameters to make routing decisions on:

  • Phase (see above)     [ Field PHASE    Value <phase number>]
  • Journal value level (see above)  [ Field LEVEL  Value <level number> ]
  • Workflow groupings (see above) [ See above for usage]
  • Process code [  Field DATAKEY  Value  “PROC_CODE=<selected process code>” ]
  • Multiple docs indicator [Field DATAKEY  Value  “MULTIPLE_DOCS=YES” ]
  • Company code [  Field DATAKEY  Value  “BUKRS=<comp code>” ]
  • Transaction code [  Field DATAKEY  Value  “TCODE=<transaction code>” ]
  • Document Type [  Field DATAKEY  Value  “BLART=<doc type>” ]
  • Close-plus days [  Field DATAKEY  Value  “CP_NUM=<number of days>” ]

Routing example

In the example below the routing rule evaulates : 

For Phase 2 (main) –> for all process codes –> company P100 –> Journal Value level 0 (0 to 99,000) –> Approval group is JP5_LEVEL_0.

Approver user ids can be attached to JP5_LEVEL_0.

Approver Override

Sometimes it is required to allow the requester to select one or more approvers (determined by the workflow rules) instead of routing to an entire team. This feature can be activated but requires addition consultancy from Promenta.

[TECH note : /PROMENTA/WSFI_JP005, WF_CONFIG, SETTINGS, APPR_OVR_STRUC=-IM]

Multi-Document Approval Amount

Since SP34-6 : When a request contains multiple documents workflow approval amount can then be determined via configuration.

This configuration is carried out in tree /PROMENTA/WSFI_JP005 (or override) node –>WF_CONFIG–> SETTINGS

Entry :

MULTI_WF_MODE=HIGHTOT    : Choose the highest individual document total as the approval amount

MULTI_WF_MODE=FIRST   : Choose the first sheet as total. This is the legacy mode.

Rejection Process

Note : Since SP41 / 6.41.0.0 rejection reason list box was added

The standard process for rejection is that when an approver rejects they must supply a reason and then the request is routed back to the original requester for modification and resubmission or cancellation of the request.

Rejection reason – Overview

By default a comments box is provided to allow the reviewer to enter their reason for rejection. By default it is mandatory.

You may also configure a fixed list of rejection reason codes which will appear in a listbox. The codes and texts are configured per customer.

Rejection reason -Configuration

/PROMENTA/WSFI_JP005 (or override) node –> Config –> Rejection Control

Settings :

Textbox :  TEXTBOX_FLDMAINT  = M/D/I  – note this can never be hidden if using any rejections
Listbox : LISTBOX_FLDMAINT  = H/M/D/I 

Listbox reason codes

This node contain simple list of the rejection codes WITHOUT any texts.

Rejection  code texts that correspond tothe codes are maintained in teh translation nmode under Dropdown (listboxes)

Example (codes):

RESULT
RESULT 1 001
RESULT 2 002
RESULT 3 003

Example corresponding texts (Language EN) :

RESULT 2 REJ_REASON_LISTBOX|001=Incorrect posting data
RESULT 3 REJ_REASON_LISTBOX|002=Missing documentation
RESULT 4 REJ_REASON_LISTBOX|003=Other

Rejection technical fields

These fields can be used in reporting

REJ_REASON   : Rejection reason text box – may be multiline

REJ_REASON_LISTBOX : Current rejection reason listbox value. This will be cleared if the request is resubmitted so it is not suitable for reporting.

REJ_REASON_LISTBOX_HIST : Rejection reason listbox value. This value is the last used rejection reason code from the listbox even if the request is resubmitted. This should be used in reporting.

 

 

 

Scroll to Top