High- Level Specification

Functional Overview

Scope and Objectives

As part of the SyWay program, it was decided to re-introduce an FI-AR invoicing process for exceptional (sundry) customer invoicing scenarios where the use of the regular sales processes via the Sales and Distribution (SD) module is not feasible due to master data, accounting requirements and/or process design constraints. To bypass the complexities and in terms of configuration and master data dependencies, the FI-AR sundry invoicing process is meant for non-recurring or urgent sales scenarios only that can't be managed adequately in the upstream Sales and Distribution module. To safeguard that the process is only used in exception scenarios, various controls are implemented. One of the endorsed controls is a park/post workflow approval process to ensure that all sundry invoices posted via the direct FI-AR route are validated by authorized reviewers and approvers.

The park and post approval process will use customized workflow templates to enable the electronic flow of initially parked documents through to the appropriate reviewers and approvers.

This document explains the triggers, routing requirements and processing requirements for the park/post approval workflow implemented as part of this process. 

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 G/L journals shall only be possible out of SAP Fiori application ‘My Inbox’. 

Security, Integrity and Controls

Accounts Receivable Processes shall be given authorizations for the following tasks as part of the invoice entry process:

• Park AR invoice document
• Set status of parked documents to ‘Saved as Completed’
• Delete parked AR invoice document
• Display parked AR invoice document

AR Invoice Approvers shall be granted authorizations to:

• Display parked AR invoice document
• Release/reject parked invoice document

Special Requirements

No special requirements identified at the time of writing.

Design Rationale

Functional Requirements

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

• Custom field in document header table for parked document (VBKPF):

To ensure that segregation of duties between invoice requester/preparer and invoice approver is achieved in all cases a new field needs to be created at document header level (table VBKPF) where the users can specify the user ID of the journal requester. This must be a mandatory input field in transaction FV50. 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.

The workflow logic will check whether the user ID of the requester and the user ID of the approver are matching. In case there is a match, the user doesn’t qualify as an approving agent as it would violate the segregation of duties principle. In such a case the user must be de-selected as possible approving agent. If there are no other approving agents available for this level, it should be routed to the next higher level of approver.

• 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 approving authority. 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 included in the subject line/work item body texts. The required variables are:

• Document number: <VBKPF-BELNR>
• Company Code: <VBKPF-BUKRS>
• Fiscal Year: <VBKPF-GJAHR>
• Amount: <VBSEGS-WRBTR>
• Document Currency: <VBKPF- WAERS>
• Document Header Text: <VBKPF-BKTXT>
• Profit Center: <VBSEGS-PRCTR>
• Profit Center Description: <CEPC-KTEXT>

If multiple Profit Centers are used in one journal, the Profit Center from the line item with the highest LC2 value shall be selected.

• Agent determination logic:

Details on the agent determination logic can be found in section 9.1 Agent determination.

An additional custom check needs to be implemented to ensure that journal requester and journal approver are not one and the same person as specified above.

• Notifications to journal requester:

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

</Start CR1727>

• 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: Journal <BELNR><BUKRS> contains errors – Action required

Body Text:

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 journal for approval.

</End CR1727>

• Approval/Rejection via Fiori application ‘MyInbox’

SAP standard Fiori application ‘MyInbox’ will be the user interface used for approving/rejecting parked G/L journals. An additional enhancement may be required to enable usage of MyInbox for this park/post workflow.

</Start CR1727>

• 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 required for subsequent processes such as document reversals where the requestor must gain visibility of the journal approver easily.

Configuration Requirements

Specify the configuration requirements for this object.

SAP Standard Workflow

Workflow developments are typically based on an existing, standard Workflow. If such a Workflow is known, then name it here. E.g. WS 03100019 - General Notification Process.

Triggers and Start Conditions

What Transactions and Batch Programs trigger the workflow? Are Start Conditions required? E.g. ‘Purchase Order workflow should trigger only for PO Types XYZ'.

Process Overview

The flow below is the standard process flow for approval of parked documents in SAP:

Note: Mail in this context refers to the workflow notification sent to the ‘My Inbox’ application of the approver. It will not trigger emails to the approvers.

1.) Business Scenario for regular journals/invoices:

• G/L Accountant or AR Processor (initiator) parks the document
• Workflow is triggered on ‘Completed’ event (document must be showing status ‘Saved as Completed’ to trigger workflow)
• A SAP Inbox notification will be sent to the approver
• Journal gets either approved or rejected by the approver.
• When rejected, the document flows back to the requester for further adjustment and re-submission
• When approved, the document shall be posted in the background. A notification shall be sent out to the requester's inbox in SAP that the document has been approved and posted.

 2.) Business Scenario for Argentina e-Invoicing: 

• AR Processor (initiator) parks the document.
• Workflow is triggered on ‘Save as Completed’ event (document must be showing status ‘Saved as Completed’ to trigger workflow)
• SAP Inbox notification will be sent to the approver
• If Company is not an Argentina Entity, either approved or rejected by the approver.
• If Company is an Argentina Entity, e-document XML is sent to Argentina government for validation.
• When rejected, or when government returns failed validation result, the document flows back to the AR processor for further adjustment and re-submission
• When approved and government validation result is successful, the document shall be posted in the background. A notification shall be sent out to the AR processor's (VBKPF-USNAM) inbox in SAP that the document has been approved and posted.

Workflow Steps

Step XXX (to be specified for each step in the workflow)

i. Decisions and Actions (e.g. if approved then post, if reject then route work item back to requester)

ii. Agent Determination

iii. Alerts, Notifications and Messages (Subject Line & Body Text)

iv. Other Requirements (e.g. Review Comments, Attachments, Email)

Error Handling

Define the error handling process

Deadline Monitoring

Describe deadline monitoring requirements

Substitution/Forwarding/Reserving

Do we allow Substitution, Forwarding or Task Reservation

Dependencies & Constraints

Indicate any dependencies or constraints that may impact development, in terms of requirements from internal or external applications or teams, limited access to legacy systems, time constraints or data restrictions. Also, please specify schedule dependencies e.g. interface or batch jobs that must run prior to execution.

Volumetrics

Provide volumetrics details for the workflow

Testing

How to Test

Please provide some guidance and/or test data to help the developer unit test the workflow. This can be included here or in a separate document.

The developer will need to test repeatedly, so where appropriate provide instructions to reverse the actions performed so the test may be run again or explain how to create new input data to the test. The developer will need logons for test users representing the various roles within the approval process.

In particular, the developer will need logons for test users representing the various roles within the approval process.

Test Conditions and Expected Results

Test Considerations/Dependencies

List any considerations essential for application test planning (e.g. test this before ABC along with DEF separate from GHI). If the development encompasses a user interface, explain how to test it. List any insights as to how this component could be tested the most efficiently.

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