High- Level Specification

Functional Overview

A receipt is an acknowledgment of the goods that have arrived. The receiving process starts when an order has been sent to a supplier and the supplier ships goods in exchange. When the shipment arrives, the person who receives those items, submits a receipt to acknowledge that the items have indeed arrived.

Negative receipt can also be created in Ariba Buying to reverse some received quantity because of incorrect shipment or manual errors.

This document describes S/4HANA System inbound interface for sending goods receipt information from Ariba Buying to S/4HANA System for POs received in Ariba Guided Buying. Goods receipt data from Ariba Guided Buying will be exported to S/4HANA System via web service and loaded in S/4HANA as GR material document. 

Buyers using the Ariba Guided Buying integrated with S/4HANA System can create receipts using a standard SAP delivered Business Application Programming Interface (BAPI).

The following steps explain how a receipt export integration event works:

1. When Buyer creates a receipt in Ariba Guided Buying, the receipt object instance is auto approved.
2. When the receipt is auto approved one copy transmits to Ariba Network and S/4HANA System via CIG and the respective Receipt status is then sent back to Ariba Guided Buying.
3. The RFC returns a receipt line number and any error information to Ariba Guided Buying.

The format of the messages that are sent through the web services from Ariba Buying to S/4HANA System and the format of the expected responses from S/4HANA System are defined in WSDL files (Web Service Description Language). These files furthermore contain details about the web service end points like URLs and port numbers.

The export of data through web services is always initiated by Ariba Buying. Once a transaction has been completed in Ariba Buying, it immediately sends out a SOAP message to the configured web service end point.

The CIG transforms that SOAP message and passes the data from that message in the right format to the S/4HANA System backend. The S/4HANA System then returns either a success or error message (including error details) to the CIG. This reply from the S/4HANA System is finally sent back to Ariba Guided Buying as SOAP message through web services.

Ariba web services are only used for exporting transactional data from the Ariba Guided Buying and sending it (via CIG) to the corresponding S/4HANA System.

Scope and Objectives

. The following Receipt web service integration events will be used:

• Export Receipts Asynchronously

There will be no scheduled task of data transmission as data is transferred in real-time.  Each submission of transactional data from Ariba Buying to the S/4HANA System requires a response from the receiving S/4HANA system that the data was successfully received and imported, or details about the error that occurred during the import. The receipts are being exported to S/4HANA with this event and the CIG document type is- ReceiptExportRequest.

• Import Receipts from an External Application Asynchronously

For web services, this success/failure notification is sent in real time as web service response to the original request. With this real time event, the status is sent back to Ariba Buying and the CIG document type for this event is- ReceiptAsyncImportPullRequest.

Service Entry Sheet / Service Sheet (SES)

A service item is an item on an order that represents a service to be performed by a supplier.

Service procurement (or procurement of service items) is a set of features that allows buyers and suppliers to manage orders for service items starting from requisitioning, ordering, tracking, to invoicing in a collaborative way.

SES are documents that describe the goods and services that suppliers deliver to fulfil a service procurement.

SES can be created in the following way:

• Suppliers create SES with reference to a service order on Ariba Network using the SES wizard.

Those SES are then validated and must be approved in Ariba Buying.  When SES is fully approved, the service sheet is transmitted to S/4HANA System 

• Requester can create SES with reference to a service order in Ariba Guided Buying and then the SES is transmitted to S/4HANA System via CIG 

Once SES is created and copied to S/4HANA system, a user with Field Service Administrator group authorization can Force Reject service sheet that is already processed. Once SES is force rejected, status of it is changed to Rejected.

The following SES web service integration events will be used:

• Export Service Sheets Asynchronously

There will be no scheduled task of data transmission as data is transferred in real-time.  The SES are being exported to S/4HANA System with this event and the CIG document type is- ServiceSheetExportRequest.

• Import Service Sheet Approval Statuses

For web services, this success/failure notification is sent in real time as web service response to the original request. With this real time event, the status is sent back to Ariba Guided Buying and the CIG document type for this event is- ServiceSheetAsyncResponsePullRequest.

• Import Service Sheet Status Response Asynchronously

Use the Import Service Sheet Status Response Asynchronously web service to receive service sheet status response asynchronously from external systems to SAP Ariba solutions.

• Export Service Sheet Status Asynchronously

Use the Export Service Sheet Status Asynchronously web service to send service sheet status asynchronously from SAP Ariba solutions to external systems

• Import Service Sheet Response Asynchronously

Use the Import Service Sheet Response Asynchronously web service to asynchronously receive the response about the creation of the service sheet.

• Export Service Sheet Response to External System Asynchronously

Exports service sheet creation information and response asynchronously to an external application.

Process Flow Diagram

Assumptions

• Ariba Guided Buying is utilized for integration of Goods Receipts and SES with S/4HANA System.
• Ariba tolerance settings for under and over-receiving are synchronized 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.
• Receiving feature is enabled in Ariba Guided Buying.
• Receiving parameters have been configured in Ariba Guided Buying.
• Master data loaded in Ariba Guided Buying is synchronized with S/4HANA System.
• Users need to be part of Field Service Administration group to force reject already processed Service Entry Sheet.

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

Ariba Configuration

Ariba Web Services enables exchange of data between Ariba Guided Buying and other systems, such as S/4HANA System, for real-time data integration.

Ariba Web Services provide integration tasks that send and receive SOAP messages for web services. An integration task requires an end point for the logical communication channel used by the web service. An end point consists of the URL and authentication information that controls access to the end point. There are two types of end points: inbound and outbound. Inbound end points are used when the task is initiated by the S/4HANA system. Outbound end points are used when the task is initiated by the Ariba Guided Buying.

Here, the Web Services channel provides real-time integration of Ariba Buying with S/4HANA system using Cloud Integration Gateway (CIG).

The following table lists operations for the integration tasks and end point types needed:

Special Requirements

Specify any special requirements or considerations that may impact the interface based on specific locations, regulatory compliance or system limitations. Clearly outline requirements e.g. localization rules for countries like China

If the interface interacts with third-party systems such as Icertis, describe any additional integration, security or authentication considerations that must be taken into account.

Design Rationale

This template may be used to specify workflow design.

Data Structure

Source Structure

The following fields will be used to provide the required information for this interface:

Target Structure

The following fields will be used to provide the required information for this interface:

Mapping and Calculation

Populate the table below to list the target / source data field mapping between the Source system and Target system

Processing Logic

Processing within Source

Describe the processing requirement from Source System

Processing within Middleware

Describe the processing requirement within Middleware Layer

Processing within Target

Describe the processing requirement from Target System

Interface Dependency

Please describe any dependency to other interfaces, e.g. messages of interface x need to be processed before message processing of interface y can start.

Interface Constraints

Please describe any limitations on source and targets. i.e. target system can only accept maximum 100mb files, first-in-first-out, etc.

Delivery Requirements

Please describe delivery requirements driven by business. i.e. real time, batch, scheduled, synchronous, triggering requirement, push or pull, etc.

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

Interface Reporting

Please describe any reporting requirement that is expected to be provided in support of this interface

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.

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

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

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

Workflow history