High- Level Specification

Functional Overview

As part of the SyWay program, it was decided to implement a system-controlled review and approval workflow for high-value G/L journals for 

• better upfront posting control to ensure ledger owners are aware of significant changes to account balances caused by manual journals. This will help to improve the quality of the ledgers at period-end and eliminates the need for subsequent review of high-value journals by the ledger owners after the fact which can lead to complications such as re-opening of closed accounting periods, etc.
• increased SOX compliance by following a 4-eye principle for high-value journals before the actuals get posted in the system.

General Ledger journals are not expenditure-related and do not lead to any cash impact for the organization, as such integration into the overall DoA is not required. A simplified, single-tier approval workflow is requested.

Specific exemptions will also be granted from the mandatory journal review mandate to avoid bottlenecks with reviewers especially during peak periods for manual journals at period-end.

Scope and Objectives

 The approval workflow is required for all high-value journals submitted for review via the below three Fiori applications as sending applications:

• F2547 - Verify General Journal Entries
• F4670A - Verify Currency Adjustment-New Version
• F1598 - Manage Recurring Journal Entries

The main objective is to achieve an increased degree of SOX compliance and increase the degree of upfront visibility and transparency of high-value journals to the ledger owners through enhanced posting control for manual journals.

Assumptions

• Approvers are required to log on to the respective S/4HANA systems to complete the approvals via Fiori application ‘My Inbox'. Approval or rejection of invoices shall only be possible out of SAP Fiori application ‘My Inbox’. 
• This functional specification is written based on the assumption that SAP does not provide new applications in future releases until go-live for verification of accounting documents. If more favorable options become available (e.g. AI-powered verifications), this custom development may require further adaptations or extensions to additional Fiori applications or becomes obsolete and can therefore be removed from the systems.

Security, Integrity and Controls

Approvers/Reviewers shall not be given editing rights to the documents under reivew. Any changes to the document must be performed by the journal processor to achieve clear segregation of duties.

Process controls for the respective L4 the custom development is designed for ('09.05.04.01. Process General Journal Entries').

Special Requirements

Work item messages as well as custom error messages generated by the workflow need to be translated into the four core logon languages (English, French, Italian, Mandarin) defined for the SyWay program as endorsed in 'KDD055 - Multi-Language Support'.

Design Rationale

Functional Requirements

The following enhancements/customizations will be required to cover all business requirements for the workflow development:

• Custom field to capture journal requestor ID:
  

Processing manual journals are the responsibility of the shared service centres. Journal entry requests are therefore predominantly processed by the responsible teams within the shared service centres. In standard SAP, only the user ID of the journal processor is captured in the document header. To be able to differentiate between journal requestor and journal processor a new field needs to be created at document header level (table VBKPF) where the invoice processors are required to specify the user ID of the journal requestor. This must be a mandatory input field in the respective Fiori app used for manual journals (F2547A, F4670A and F1598) and must be available as mandatory input field in the Excel upload templates used for Fiori app F2547A . The inputs in this field shall be validated against table USR01. A match-code search function shall be made available to search for the respective user IDs based on user’s first and last name. This requirement will be covered and implemented via development request 'ERP-1749 Custom Field for AR and G/L Journal Workflow'.

The workflow logic needs to check whether the user ID of the requestor and the user ID of the approver are matching. In case there is a match, the document should be automatically released/approved and subsequently posted. 

This field shall be used by the processing logic of the workflow to enable workflow exemptions.

• Lock document after submission for approval:

Once a document has been submitted for approval it shall no longer be editable until it gets approved or rejected by the reviewers/approvers. In case there are any changes required to the document, the document needs to be rejected by the approver to flow back to the processor to make the necessary changes.

• Add variables to workflow container and include them in the subject line/work item body text:

Some variables need to be added to the workflow container and eventually included in the subject line/work item body texts. The required variables are:

• Document Number: <VBKPF-BELNR>
• Invoice Number: <VBKPF-XBLNR>
• Company Code: <VBKPF-BUKRS>
• Fiscal Year: <VBKPF-GJAHR>
• Amount: <VBSEGS-WRBTR>
• Document Currency: <VBKPF- WAERS>
• Document Header Text: <VBKPF-BKTXT>
• GBU: Derive from profit center standard hierarchy via profit center used in highest-value line item.
• Profit Center: <VBSEGS-PRCTR>
• Profit Center Description: <CEPC-LTEXT>

If multiple profit centers are used in one journal, the profit center from the line item with the highest LC2 (VBSEGS-DMBE2) value shall be selected.

• Approval levels and agent determination logic

All manual G/L journals recorded in the system shall be subjected to the below approval levels and agent determination logic:

• All manual G/L journals exceeding the defined thresholds are subject to a mandatory review by a nominated approver.
• AS HR position IDs may vary across systems, the decision table shall remain editable in each system of the S/4 HANA system landscape. Any changes to the decision table must be initiated via service requests. 

Note:

• The threshold amounts are maintained in the company's group currency for all company codes. The processing logic should compare the amounts in the agent determination table against the group currency amounts specified in the manual G/L journals.
• Columns Key/Non-Key Legal Entity, Region, Country and Company Code should be optional. Wildcard entries (*) should be possible for all three columns.
• All columns should be considered key fields. Multiple HR positions or bands may be assigned to a specific combination of row attributes.
• The dimensions Key or Non-Key Legal Entity/Region/Country/Company code shall be considered from most specific to least specific by the determination logic. The following order shall be followed (from most specific to least specific):
  
  1.) Company Code
  2.) Country
  3.) Region
  4.) Key/Non-Key Legal Entity

          Example:

• • In the decision table, an entry is maintained at level 2 for country BE (Belgium) and amount >=1,000.00 EUR assigned to HR position 'S01'. Another entry is maintained for company code 1000, which is an entity operating in Belgium, and amount >=500,000.00 EUR and assigned to HR position 'S02'. If an invoice gets parked in the system for entity 1000 with an amount of 600,000 EUR, the approver determined at level 2 should be the user assigned to position 'S02' not 'S01'. 

• The distinction between key and non-key legal entities can be made via a global parameter maintained for each company code. Query field T001Z-ZENTTYP for the company code to retrieve the categorization of the company code as key or non-key legal entity.
• Region and country should be determined based on the country of the legal entity (T001-LAND1) in which the journal gets raised.
• The approver positions specified in the decision tables are members of the regional GBS teams. It is not expected to have region-specific or even country-specific positions in the future organization chart design so identifying the correct reviewers/approvers for a particular company code based on the HR position alone may not be sufficient. It may be required to look up the approver's regional or country responsibilities based on attributes defined in the authorization roles or user profiles. Legal entity responsibilities in GBS can spread across multiple countries within a region so the company code maintained in the employee master record of the approver may not be indicative enough of the actual legal entity responsibilities within GBS.
• It may also be required in some cases to define bands instead of HR positions in the decision table if certain positions are not available in a specific region/country/company code.
• Exemptions:

  • An additional custom check needs to be implemented to ensure that journals requested by an authorized approver shall be auto-approved and posted immediately.

  • Journals requested by superiors of the nominated approvers (based on the organizational structure) shall be auto-approved and posted immediately.

  • Journals requested by Controllers (look-up job/position of journal requestor) shall be auto-approved and posted immediately.

  • Journals raised for the non-leading ledgers only (BKPF-LDGRP <> 'blank' or '0L') shall be auto-approved and posted immediately.

• The agent determination and approval level checks shall be implemented using SAP Business Rules Framework plus (BRF+), allowing the decision tables to be maintained independently in each system of the S/4 HANA landscape without requiring transports.                     
• Notifications to journal requestor:

Notifications shall be sent out to the journal requestor and journal processor once requested journal have been approved and posted in the system.

Subject Line: 'G/L Journal <BELNR>/<BUKRS> requested by you was posted successfully'.

Body Text:

‘G/L journal <BELNR>/<BUKRS> requested by you was posted successfully. Journal entry details are as follows:

• • Document number: <VBKPF-BELNR>
  • Company Code: <VBKPF-BUKRS>
  • Fiscal Year: <VBKPF-GJAHR>
  • Amount: <VBSEGD-WRBTR>
  • Document Currency: <VBKPF- WAERS>
  • GBU: Derive from profit center standard hierarchy via profit center used in highest-value line item.
  • Profit Centre: <VBSEGS-PRCTR>
  • Profit Center Description: <CEPC-LTEXT>
  • Document Header Text: <VBKPF-BKTXT>

• Notifications to journal processor:

The work item shall be routed back to the journal processor in case errors are encountered during background processing of the journal after initial approval of the document by the journal approver. The following message shall be output:

Subject line: 'G/L Journal <BELNR><BUKRS> contains errors – action required.'

Body Text:

'G/L Journal <BELNR><BUKRS> raised by you contains errors. The following errors were encountered:

<Error Message 1>

<Error Message 2>

Perform the necessary corrections and re-submit the G/L journal for approval.'

• Approval/Rejection via Fiori application ‘My Inbox’

SAP standard Fiori application ‘My Inbox’ shall be the user interface used for approving/rejecting parked documents. 

• Substitution of user ID in document header:

The user ID of the journal approver shall be substituted into the document header (BKPF-USNAM) once the document has been approved and posted successfully. This is needed to enable easy identification of the approvers for follow-ups if audit queries arise.

• Fiori push notifications are required for this workflow:

The following Fiori push notifications shall be sent to by the workflow templates:

• Notification to approver once document got ‘submitted’ for review/approval.
• Notification to requestor once document got rejected by approver.
• Notification to requestor and processor once document got posted by approver.

Configuration Requirements

• Teams and Responsibilities may need to be configured via Fiori app ('F3932') if the technology chosen for this workflow development is leveraging on SAP standard's flexible business workflow.
• Trigger conditions and other settings may need to maintained via Fiori app ('F2720") if the technology chosen for this workflow development is leveraging on SAP standard's flexible business workflow.

SAP Standard Workflow

Two workflow framework options in S/4 HANA were assessed to realise this requirement, with Flexible Business Workflow identified as the recommended technology choice.

a) Classic Workflow Framework (via SWDD):

In the classic workflow administration framework in S/4 HANA, the following SAP standard workflow templates could be leveraged to meet the business and process requirements:

WS10000051 - Main workflow template to release parked documents.

WS10000052 - Sub-workflow template for single-tier approval of parked documents.

Functionally, these standard workflow templates activate a workflow messaging to the approvers once a document has been parked in the system. The standard workflow template does not lock the document once it has been submitted for approval. It can be re-submitted multiple times which leads to data inconsistencies in the approver’s inbox. 

Furthermore, the standard workflow template triggers the workflow notification upon initial parking of a document in the system. At parking stage, the system doesn’t perform thorough data integrity checks hence technically incomplete documents can be routed for approval potentially leading to a high number of rejections and documents in error.

Standard workflow templates also do not notify the requestor once a document has been approved and posted. A notification shall be sent to the requestor of the journal entry once the requested documents have been successfully posted in the system.

As SAP standard workflow templates do not issue error notifications to either the requestor nor the approver, further enhancements are required to enable such (push) notifications.

SAP standard also doesn’t support agent determination based on LC2 amounts (group currency) which is required to simplify the global threshold definitions across all Syensqo entities. It also doesn't support routing of invoices based on the new organizational chart designs introduced as part of the SyWay program.

Subject line and work item text also require additions (e.g. include Profit Center in subject line) which is not foreseen nor supported by SAP standard workflow templates in the classic workflow framework.

b) Flexible business workflows in S/4 HANA (To Be Implemented)

In S/4 HANA a new generation of workflows was introduced under the umbrella term flexible business workflows. Among the available workflow applications provided by SAP in standard is Fiori application 'F2720 - Manage Workflows for Journal Entry Verification - In General Ledger' for defining triggers, start conditions and approval routing paths. Along with this new workflow definition application, a separate Fiori application is provided by SAP to maintain review and approval responsibilities under 'F3932 - Manage Teams and Responsibilities For Journal Entry Verification - In General Ledger'. Individuals or teams can be assigned as responsible reviewers/approvers for the journal entry workflows defined in the system.

While the standard workflow definition application support certain start and trigger conditions that are required for the G/L journal review and approval workflow at Syensqo, not all of the requirements can be covered by standard configurations and enhancements to the standard options are required (e.g. distinction between key and non-key legal entity, exclusion of non-leading ledger journals, etc.).

Team and responsibility structures used by the standard workflow need to be tied to employee business partners. This may not be flexible enough to cater to Syensqo-specific routing requirements based on HR positions, bands and responsibilities within the regional shared service centres. As such, enhancements may also be required to tailor responsibilities and agent assignments for G/L journal reviews to the business needs of Syensqo.

Triggers and Start Conditions

a) Triggers:

The workflow shall be triggered upon clicking the 'Submit' button by the journal processor in Fiori apps F2547A and F4670A and upon clicking button 'Post' in Fiori app F1598. 

b) Start Conditions

Below a list of business objects that can be used for this workflow process:

Process Overview

The simple process flow diagram below illustrates the standard process flow for a single-tier approval workflow implemented via the flexible business workflow framework in S/4 HANA for both journal entry scenarios applicable for this custom development:

 1.) Business Scenario for regular G/L journals submitted for approval:

• Journal Processor (initiator) submits the document for review/approval.
• Workflow gets triggered. Start conditions are checked. If the start conditions are fulfilled, it will proceed to the agent determination and assigns the work item to a processor. If no start conditions are fulfilled, the journal should be posted immediately.
• A SAP Inbox notification and work item will be sent to the reviewer/approver to verify the journal entry.
• Document gets either approved or rejected by the reviewer/approver.
• When rejected, the document flows back to the processor for further adjustment and re-submission.
• When approved, the document shall be posted in the background. A notification shall be sent out to the requestor's and processor's inbox in SAP that the document has been approved and posted.

2.) Business Scenario for regular recurring entry journals submitted for approval:

• Journal Processor (initiator) creates a recurring entry journal template. As it's just a journal entry template that doesn't directly update the books upon creation, no workflow is required at this stage.
• At period-end, the template will be converted into an actual journal entry via a period-end activity performed via Fiori application F1598.
• Workflow gets triggered. Start conditions are checked. If the start conditions are fulfilled, it will proceed to the agent determination and assigns the work item to a processor. If no start conditions are fulfilled, the journal should be posted immediately.
• A SAP Inbox notification and work item will be sent to the reviewer/approver to verify the journal entry.
• Document gets either approved or rejected by the reviewer/approver.
• When rejected, the document flows back to the processor for further adjustment and re-submission.
• When approved, the document shall be posted in the background. A notification shall be sent out to the requestor's and processor's inbox in SAP that the document has been approved and posted.

Workflow Steps

The below step represents a decision-making step that needs to be actioned on:

The below step represents a review step that need not be actioned on, it serves a plain alert function for ledger owners to be aware of high-value journals posted into their books. This notification shall be sent out in parallel to the notification generated for the above decision step. The SAP standard functionality of 'Review Steps' available in the business workflow definitions for General Journal Entries in S/4 HANA shall be leveraged on to fulfill this requirement.

Error Handling

Should there be any errors returned by the workflow processing logics at agent determination stage, a notification should be sent to the workflow administrator to perform follow-up actions. 

The work item shall be routed back to the journal processor in case errors are encountered during background processing of the journal entry after initial approval of the document. At the same the journal should be unlocked to be able to perform the necessary corrections before re-submission.

All error messages generated by or encountered by the workflow during background processing must be easily understandable to facilitate effective trouble-shooting and must be accessible via the workflow logs.

Deadline Monitoring

Deadline monitoring is not active for this workflow development. Backlogs of parked documents in the system which are still awaiting release will be cleared out at the end of every month as part of the period-end closing activities. SAP has standard reports available to monitor outstanding parked documents.

Substitution/Forwarding/Reserving

Forwarding of workflows for the approval of parked documents is permitted. Forwarding should only be possible to approvers of the same HR rank or above. It is the responsibility of the user to forward the work item to a person with sufficient authorizations to post in the company code of the journal entry to be posted.

Substitutions will be used especially in cases where users are on leave. The substitution rules should only allow for routing of the work item to a proxy of the same HR position/rank. The substitution rules should follow the rules and principles defined in the SoD principles introduced as part of the SyWay program.

Dependencies & Constraints

• Usage of the approval functions in ‘My inbox’ on mobile, handheld devices shall follow the overall guidelines of the UI strategy defined for the SyWay program.
• The mentioned functional requirement for a 'Custom field to capture journal requestor ID' has also been stated as a requirement for workflow development ERP-300. Whichever custom development gets implemented first should handle this requirement, the other development shall then utilize on the implemented solution to cover this requirement.

• As part of custom development 'ERP-300 Workflow for FI-AR Sundry Invoices' a feature will be implemented to lock documents while they are being reviewed in the approval workflows. There may be dependencies arising that need to be considered in the build of this custom workflow development.

Volumetrics

The volume of manual journals in S/4 HANA is expected to decrease by a multi-fold due to product innovations and process re-designs introduced as part of the SyWay program.

It is estimated that the future volume of manual journals will decrease to approximately 200-300 entries per month across all S/4 HANA company codes making it a much more manageable number in terms of online review in the system without creating bottlenecks with the reviewers/approvers.

Testing

How to Test

Some temporary assignments in the user decision table will be required for the agent determination.

Consult the functional consultant to receive a sample invoice document that can be used as reference invoice document for mass testing purposes.

Test Conditions and Expected Results

Test Considerations/Dependencies

• All master data and configurations for posting General Ledger journals in the system must be set up in the test system.

Other Information

Development Details

Package

Workflow Implementation

Other Development Objects

Appendix

See also

Insert links and references to other documents which are relevant when trying to understand this decision and its implications. Other decisions are often impacted, so it's good to list them here with links. Attachments are also possible but dangerous as they are static documents and not updated by their authors.

Change log