| Status | |
|---|---|
| Owner | The person responsible for driving this decision and documenting it. Type @ to mention people by name |
| Stakeholders | The business stakeholders involved in making, reviewing, and endorsing this decision. Type @ to mention people by name |
| Jira Request ID | |
| Jira Development ID |
High- Level Specification
| Implementing System | S/4 Hana |
|---|---|
| Application System (Source) | S/4 Hana |
| Application System (Target) | Ariba Guided Buying |
| Business Process Reference | 03.04.05.01. Manage Indirect Receipts |
Functional Overview
Reply messages are sent to Ariba Guided Buying after successful processing - in the technical terms - of the Receipt message received from Ariba Guided Buying. Reply message can contain either way positive reply after the message from Ariba Guided Buying haven't raise any validation issue or the details of the error message. Due to the asynchronous nature of the Receipt create interface, reply message for these events is sent as a dedicated separate message and it's not part of the Receipt interface.
- In a case of a successful processing in S/4 Hana, reply message contains ARIBA_GR_NO - the unique reference of the Receipt Created in Ariba Guided Buying and MAT_DOC_NO - stored in the ERPReceiptNumber - the Receipt ID assigned in S/4 Hana
- In a case of validation errors occurring in S/4 Hana, reply message contains ARIBA_GR_NO and the list of error messages generated by S/4 Hana validation logic
Message is initiated within CIG Addon, mediated by the CIG where it's translated into SOAP message to be received by Ariba Guided Buying
Scope and Objectives
This document describes S/4 Hana sending outbound message sent after the processing of Receipt Create inbound message. This is a specific message type for Receipts only, as opposite to the generic message used by other transactional documents, for example Purchase Order.
Integration event Import Receipt Status Asynchronously must be enabled in Ariba Guided Buying.
Process Flow Diagram
Process flow is identical with ERP-68 - functional specification describing PO Create / Change and Cancel
Assumptions
- Ariba Guided Buying is utilized for integration of Purchase Orders and Receipt with S/4HANA System.
- Ariba source object and S/4HANA System target field mappings, including custom fields, will be updated based on mapping requirements in S/4HANA System
Dependencies
- All configurations should already be implemented before the interface is deployed.
- Ariba Buying packages have been successfully installed and configured in S/4HANA System.
- The connection information for Web-Services based integration have been successfully configured in Ariba Buying.
- Receipt parameters have been configured in Ariba Guided Buying.
- Master data loaded in Ariba Guided Buying is synchronized with S/4HANA System.
Security, Integrity and Controls
The following are the Security and Authorization considerations for this interface:
- Define a Web Services Security certificate and/or the shared secret key to use to secure the End Point connection.
- Access to interface parameters in Ariba Guided Buying are being addressed by Ariba standard security controls. Only authorized person with Ariba administrator’s role can access/ change interface parameters.
- Web service security configuration allows secure communications protocol provides a means for applying security to Web services.
Configuration Requirements
Prerequisite for this interface is the configuration from ERP-68 Functional Specification. On top of this
Ariba Configuration
Integration event Import Receipt Status Asynchronously must be enabled
CIG Addon Configuration
Parameter ENABLE_FEH must be set to X in order to for S/4 Validation errors to be sent back to Ariba Guided Buying
Special Requirements
Not Applicable
Design Rationale
Not Applicable
API Use
Not Applicable
Data Structure
The following fields will be used to provide the required data structure of the interface:
| Parent | Field | Description | Mandatory (Y/N) | Data Type |
|---|---|---|---|---|
Calculation and Validation
Populate the table below to list the calculation and validation rules per field. Can be deleted if not needed.
| Parent | Field | Rule Type | Rule Instruction |
|---|---|---|---|
eDocument mapping
Populate the table below to list the mapping for edocument implementations. Can be deleted if not needed.
| General | Syensqo XML (Target) | SAP eDoc Standard Mapping (Source) | Custom Mapping (Source) | ||||||
|---|---|---|---|---|---|---|---|---|---|
| S-NR | Flow (SD/FI/MM/ALL) | Field Details | Condition | Syensqo XML Node | Syensqo XML Field | SAP eDoc Standard Node | SAP eDoc Standard Field | Fixed Value | Custom Logic |
| Conditional / Mandatory | Header / Header Tax / Header Value / Header Extension / Sender / Sender Extension / Receiver / Receiver Extension / Item / Item Tax / Item Value / Item Extension | ||||||||
Processing Logic
Describe the processing requirement in the System
Delta or Full Load Requirements
Please describe change tracking requirements, i.e. transferring only delta, or always full load
Interface Alert & Monitoring
Please describe any alert & monitoring requirement for business users and support organization, i.e. AIF
Language Requirements
Specify multi language requirements
User Interface Requirements
Capture the requirements for the user interface (UI) associated with the interface. It should provide a clear description of how users will interact with the interface and how information will be presented to ensure usability and accuracy.
Sequencing
Please describe delivery requirements driven by message sequencing, i.e. specific order, impact of disruption of sequence, are duplicates allowed, etc.
Volumetrics
Provide volumetrics details: Initial load volumes, Number of Records, Expected Frequency, Expected Long term Growth)
Performance Consideration
Specify if there are any specific performance factors that need to be taken into consideration during development i.e. interface must be able to handle 100 posting per-hour, etc.
Error Handling
Detail how errors will be handled: Notification, Restart/ Recovery and Re-Processing Procedures
Testing
How to Test
Please provide some guidance and/or test data to help the developer unit test the interface. Please include both positive and negative testing (to validate error situations handling)
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. In particular, the developer will need logons for test users representing the various roles within the approval process.
Test Conditions and Expected Results
| ID | Condition | 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
| Package Name | Parent Package |
|---|---|
Other Development Objects
| Object Type | Object Name | Purpose/High Level Logic | Design Rationale Reference |
|---|---|---|---|
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.
