High- Level Specification
| Parameter | Value |
|---|---|
| Application System | S/4 HANA (all systems) |
| Business Process Reference | 09.05.02.02. Post Sundry Debtor Invoices/Credit Memos |
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/practical 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, start conditions routing requirements and processing requirements for the park/post approval workflow implemented as part of this process. It also outlines how the integration with the e-invoicing portal needs to be established as part of the working
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’.
- This functional specification is written based on the assumption that SAP does not provide new applications in future releases until go-live for parking outgoing customer invoices posted via the FI-AR module. The roadmap has been analysed and no related item could be found. Should new Fiori applications be released by SAP for this purpose and Syensqo decides to adopt those in its functional process designs, this functional specification may become obsolete or may require adjustments.
Security, Integrity and Controls
Accounts Receivable Invoice 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
Users must not be given authorizations to directly post a document in Fiori app 'FB70 - Create Outgoing Invoices'.
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 be able to differentiate between invoice requestor and invoice 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 invoice requestor. This must be a mandatory input field in the respective Fiori app used for the outgoing invoice process (Fiori app ID: FB70). 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 needs to check whether the user ID of the requester 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.
- 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-KTEXT>
If multiple profit centers are used in one invoice, the profit center from the line item with the highest LC2 value shall be selected.
- Approval levels and agent determination logic
All FI-AR sundry invoices parked in the system shall be subjected to the below approval levels and agent determination logic:
- All invoices are subject to a mandatory review by the tax team. This is required as the invoice entry application does not have automatic tax code determination capabilities and relies on manual selection by the user which is prone to errors without proper understanding of the tax legislations in the respective countries.
- The second level of review and final approval of the invoice is only required if the invoice exceeds a certain threshold amount. Any invoices below the defined threshold amounts shall be auto-approved and posted immediately.
| Level | Region | Country | Company Code | Amount (EUR) | Approver HR Position |
|---|---|---|---|---|---|
| 1 | * | * | * | - | Tax Accountant or job equivalent |
| 2 | * | BE | * | >=1000.00 | Country Accounting Manager or job equivalent |
Note:
- The threshold amounts are maintained in EUR for all company codes. The processing logic should compare the amounts in the agent determination table against the group currency amounts specified in the invoice document.
- Columns 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 may be assigned to a specific combination of row attributes.
- The dimensions 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
Example:
In the 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 >=1,000.00 EUR and assigned to HR position 'S02'. If an invoice gets parked in the system for entity 1000 with an amount of 1,000.00 EUR, the approver determined at level 2 should be the user assigned to position 'S02' not 'S01'.
- Region and country should be determined based on the country of the legal entity (T001-LAND1).
- The approver positions specified in the decision tables are member 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.
- An additional custom check needs to be implemented to ensure that invoice requested by a final invoice approver are exempted from the 2nd level review.
- Notifications to invoice requestor:
Notifications shall be sent out to the invoice requestor and invoice processor once requested invoices have been approved and posted in the system.
- Notifications to invoice processor:
The work item shall be routed back to the invoice processor in case errors are encountered during background processing of the invoice after initial approval of the document by the invoice approver. The following message shall be output:
Subject line: Sundry Customer Invoice <BELNR><BUKRS> contains errors – action required.
Body Text:
Sundry Customer Invoice <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 invoice for approval.
- Approval/Rejection via Fiori application ‘My Inbox’
SAP standard Fiori application ‘My Inbox’ will be the user interface used for approving/rejecting parked G/L invoices. An additional enhancement may be required to enable usage of 'My Inbox' for this park/post workflow.
- Substitution of user ID in document header:
The user ID of the invoice 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.
- Integration with EDICOM for e-invoicing:
Per regulatory requirement for Argentina (RR-1108), the outgoing FI-AR invoice has to be sent electronically to government before being posted as accounting document. This requires an additional enhancement to the workflow in order to intercept and send it Edicom (e-invoicing service provider) for government validation.
- 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 ‘saved as completed’
- Notification to requester once document got rejected by approver
- Notification to requester once document got posted by approver
Configuration Requirements
The custom workflow template variants shall be copied using a SAP standard workflow template as a reference. A custom workflow variant will provide more flexibility in terms of workflow design and required functionalities.
WS10000051 is the main SAP standard workflow to release parked invoice documents. It shall be used as a reference object to create the required custom workflow template variant.
The activation of the workflow shall be controlled via assignment of a workflow variant to the company code only. No further configuration will be made. Regardless of the document type used for the invoice documents, the workflow should always be triggered upon saving a document as completed.
Decision steps to approve/reject a journal need to be configured for SAP Fiori application ‘My Inbox’. These decision boxes need to be assigned to the custom sub-workflow variant used for the release of the journal and the respective step that constitutes the decision point in the workflow.
SAP Standard Workflow
The following standard workflows will be enhanced to meet business requirements and shall be activated via the necessary configurations:
WS10000051 - Main workflow template to release parked invoice documents.
WS10000053 - Sub-workflow template for two-tier approval of invoice documents.
Functionally these 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.
Standard workflow template also doesn’t notify the requester once a document has been approved and posted. A notification shall be sent to the requester of the journal once requested documents have been successfully posted in the system.
As SAP standard workflow templates do not issue error notifications to either the requestor or the approver, further enhancements are required to the standard templates to enable such (push) notifications.
SAP standard also doesn’t support agent determination based on LC2 amounts (group currency) and 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 supported in SAP standard.
Triggers and Start Conditions
The workflow shall be triggered once a document gets successfully ‘Saved as completed’ by the invoice processor. Users may directly press the ‘Save as completed’ button rather than parking the document first and saving it as completed in a separate step so the workflow shall be triggered upon saving the document as completed regardless of whether it has been parked in a preceding step or not.
Approvers shall not be given editing rights to the source document. Any changes to the document must be performed by the document processor to achieve clear segregation of duties.
Parked documents for outgoing customer invoices will all be created via Fiori application 'FB70 - Create Outgoing Invoices'.
Below a list of business objects that can be used for this workflow process:
Business Object | Event | Condition | Design Rationale Reference |
FIPP | PrelPostingDocument.Completed | Parked document is saved as completed. | This event shall trigger the workflow. |
FIPP_SUBWF02 | Two-Level Amount Release | Parked document relevant for single level approval | |
FIPP | PrelPostingDocument.Created | Parked document is created / changed | This event should not trigger the workflow. |
FIPP | PrelPostingDocument.Deleted | Parked document is deleted |
|
Process Overview
The flow below is the standard process flow for a single-tier approval of parked documents in SAP (the required 2-tier approval workflow requested for this custom workflow will have another review loop compared to the below illustration but conceptually the document flow will be identical):
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 invoices/invoices:
- AR Invoice 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 reviewer/approver.
- Invoice gets either approved or rejected by the 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 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 code is not an Argentina-based entity, either approved or rejected by the approver.
- If company code is an Argentina-based 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 and AR requestor's inbox in SAP that the document has been approved and posted.
Workflow Steps
Step Description | Release/Reject Invoice Document |
Step Type | Decision Step |
Approve / Reject texts and actions (for user decision steps) | Two buttons are required for this decision step: 1. Approve: o Parked document should be posted automatically in the background (same behavior as if it was released via SBWP). o Notify requester that document has been approved and posted. 2. Reject: o Document should be routed back to the invoice processor. o Rejection reason must be entered and attached to work item. o Work item needs to be visible in processor's Fiori inbox. Rejection reason/comments must be available under ‘Comments’ or ‘Attachments’ section in the work item message |
Subject Text | Att. To: <CEPCT- LTEXT> Release Sundry Customer Invoice Document <BELNR><BUKRS> |
Body Text | ATTENTION TO: <CEPCT-LTEXT> (bold letters) ‘Sundry Customer Invoice <document number> raised in company code <company code> requires your action. Please validate the invoice entry, tax details and supporting documents to take the necessary actions.’
|
Possible Approvers (Possible Agents) | The agent determination should follow the logic as outlined in section 'Functional Requirements' of this functional specification. |
Approver Selection (Selected Agents) | The selection of the right approving agent out of the pool of possible approving agents shall be facilitated by checking the In case no approver can be found at the corresponding level for a given position in the approval matrix, the approvers shall be determined from the next level upwards based on the entry level position following the reporting lines defined in organizational chart structures. |
Escalation | Reminders should be sent if no action was taken by the approvers with a span of 24h after the document's initial submission. |
Email Notification | No email notification required. Only internal SAP message to approver’s inbox is required. |
Attachments | The list of attachments shall include the supporting documents attached by the user to the invoice document subject to approval. A link to the parked document shall also be provided to allow the user to review the document in S/4 in document entry view (link to transaction code FV53). |
Error Handling
Should there be any errors returned by the workflow 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 after initial approval of the document by the journal approver.
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 parked document approval workflows. 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 level 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 invoice document.
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
Volumetrics
The expected volume of invoices to be processed by this workflow is low. The primary reason for this is that the sundry customer invoice processing via FI-AR is only resorted to in exception cases. The primary route for customer invoices remains the billing process via the Sales and Distribution module, also in S/4 HANA.
Testing
How to Test
Test Conditions and Expected Results
| ID | Condition | Expected Result |
|---|---|---|
Test Considerations/Dependencies
Other Information
Development Details
Package
| Package Name | Parent Package |
|---|---|
Workflow Implementation
| UI Type | UI Name | Fiori Catalogue | Design Rationale Reference |
|---|---|---|---|
Other Development Objects
| Object Type | Object Name | Purpose/High Level Logic | Design Rationale Reference |
|---|---|---|---|

