Skip to end of metadata
Go to start of metadata

The Procure to Pay ES bundle provides enterprise services for the procure-to-pay business process, from demand creation up to the invoicing for materials and services received.

This ES bundle allows integration of external solutions in a company's system landscape (application-to-application or A2A integration) as well as collaboration with suppliers (business-to-business or B2B integration). Let's look at these in a bit more detail.

  • A2A. Companies can use enterprise services in this bundle to integrate third-party software within their system landscape with SAP ERP. Using this bundle, external software applications can invoke creation of purchase orders and requests, for example, and/or receive notifications of events in the procure-to-pay process, such as the creation of or changes to procurement-related documents.
  • B2B. Companies can use other enterprise services in this bundle to provide seamless integration of the procure-to-pay process with key suppliers. In this case, services in this ES bundle can be used as a replacement for older B2B technologies such as electronic data interchange (EDI), allowing key documents, from purchase orders to invoices, to flow seamlessly between the ERP systems of organizations without manual intervention.

Procure to Pay (click to enlarge)

Audience

The Procure-to-Pay ES bundle will mainly be used by system administrators who set up the interactions between software applications within a system landscape (A2A) or between a company and its suppliers (B2B). Having said that, the automation provided by such electronic data transfer is of immediate and practical benefit to everyone in the enterprise who deals with procurement documents and who would otherwise be required to enter data from one system into another or receive paper documents from suppliers and enter the data into SAP ERP. Purchasing planners, system administrators and suppliers in any enterprise that sells products or services to customers will find this ES bundle valuable for improving document flow, with an increase in efficiency and a reduction of errors associated with manual data entry.

For details on Service Operations, Business Objects and Process Components, please check the ES Workplace.


How To Use This ES Bundle

Depending on materials or services procured, the procure-to-pay process may be a straight forward requisition to pay process or a lengthy and complex process with many potential variations, exceptional process steps and numerous documents. It starts with demand creation, then source of supply assignment, and finally the creation of a purchase order for an external supplier to procure some material or services. The material is then delivered or services performed, which results in the creation of a service receipt or goods receipt. And finally, the supplier sends an invoice to pay.

The following series of use cases for the Procure-to-Pay ES bundle show how different outcomes can be achieved by using the enterprise services in different combinations. While these examples illustrate a few of the ways that this ES bundle could be used, the intention is to show the flexibility and reusability of these business objects and enterprise service operations so that you will have a clearer understanding of how to best deploy them in your own environment. This wiki is also a space for you to share knowledge and collaborate with others who are implementing the Procure-to-Pay ES bundle.

Table of Contents

 

Use Case 1: Business-to-Business Procure to Pay Process

A major retailer contracts with a digital camera manufacturer for a significant volume of orders and mandates that they be handled electronically. The retailer implements the services in the Procure-to-Pay ES bundle to interact with the manufacturer's Order to Cash ES bundle.

The retailer creates a purchase order for the digital cameras and sends it to the manufacturer by invoking the Request Purchase Order Creation enterprise service. When the manufacturer receives the purchase order, its ERP system triggers the Create Sales Order enterprise service operation, which is part of the Order to Cash ES bundle.

Having created the sales order, the manufacturer's ERP system sends a confirmation back to the retailer; the retailer processes that confirmation using the Change Purchase Order based on Purchase Order Confirmation enterprise service. The manufacturer then processes the order, triggering their ERP system to generate an advanced shipping notification (ASN). The retailer receives the ASN, which invokes Maintain Inbound Delivery based on Despatched Delivery Notification.

Once the retailer receives the shipment, it sends a proof of delivery document back to the manufacturer using the Notify of Received Inbound Delivery enterprise service. When the manufacturer receives the proof of delivery document from the retailer, it invokes the Notify of Customer Invoice enterprise service, which sends the invoice to the retailer. The retailer's system then invokes Create Invoice so that the invoice can be paid according to the agreed upon terms.

This entire process is handled as a series of messages flowing between the backend systems of the retailer and the manufacturer. In the normal course of business, little human intervention is required to manage these documents or post them to the ERP system.
The following table summarizes these steps and the associated enterprise services:

Steps

Enterprise service Invoked

Step 1: The retailer creates a PO for the products and sends it to the manufacturer

Request Purchase Order Creation

Step 2: The manufacturer receives the PO causing its ERP system to create a sales order

Create Sales Order

Step 3: The manufacturer's ERP system sends a confirmation to the retailer where it is processed

Change Purchase Order Based on Purchase Order Confirmation

Step 4: The manufacturer processes the order and upon completion the ERP system is triggered to create an ASN

(No enterprise service is invoked during this step)

Step 5: The retailer receives the ASN and processes it

Maintain Inbound Delivery Based on Despatched Delivery Notification

Step 6: Upon receipt of the products by the retailer a prrof of delivery document is sent to the manufacturer

Notify of Received Inbound Delivery

Step 7: Receiving the delivery confirmation triggers the creation and sending of an invoice

Notify of Customer Invoice

step 8: The retailer's system processes the invoice

Create Invoice

Use Case 2: Notification of Changes to Purchase Contracts

General Appliance Corporation, an appliance manufacturer, has a contract for the electronic components of its washing machines. These contracts help stabilize the price of these components for a period of time. From time to time, changes are made to these contracts and the supplier would like to be notified of all such changes. The system administrator at General Appliance deploys the Procure-to-Pay ES bundle so that the Notify of Purchasing Contract enterprise service is invoked every time a change is made to a purchase contract for these electronic components, ensuring that the supplier has the latest information about the terms and conditions of these contracts.

The following table summarizes these steps and the associated enterprise services:

Step

Enterprise Service Invoked

Step 1: The manufacturer makes changes to a contract with a specific supplier

(No enterprise service is invoked during this step)

Step 2: Upon saving the changes they are replicated to the supplier's system

Notify of Purchasing Contract

Use Case 3: Notification of Supplier Master Data Change

Appliance manufacturer General Appliance sends out RFx documents, such as request for quotations, to see who can supply the highest quality parts at the most competitive price. Many suppliers respond to these RFx requests, but because only one supplier will win the contract, the RFx tool has information on many suppliers that are not stored in SAP ERP. Once a winning supplier is selected, that supplier's master data must be entered into SAP ERP. Once the user saves the supplier's information in SAP ERP, the Notify of Supplier enterprise service operation is triggered. Because the RFx tool has subscribed to that information, it is notified that the supplier has been created in SAP ERP. Any changes to supplier information can be communicated using the same service.

The following table summarizes these steps and the associated enterprise services:

Step

Enterprise Service Invoked

Step 1: A manufacturer publishes an RFx document using an RFx tool that carries information related to suppliers not stored in the ERP system

(No enterprise service is invoked during this step)

Step 2: A winning bid is selected and the supplier's master data is entered into the ERP system

(No enterprise service is invoked during this step)

Step 3: The user saves the information into the ERP system, which updates the RFx system. Subsequent changes can be replicated to either system

Notify of Supplier

Use Case 4: Notification of Changes to Procure to Pay Business Objects

Use cases 2 and 3 cite examples of applications that would like to receive notification of additions or changes to various purchasing documents and master data. But in fact, the number of use cases is almost endless. Any application that wants to receive notification of changes to key business objects can subscribe to this information. The system administrator simply ensures that the appropriate enterprise service is invoked when a purchasing document or, in the case of suppliers, purchasing-related master data is changed. The following table shows the business objects and enterprise services for which notification is available:

Use Case 5: External Request for Purchasing Documents

Kitchens Are Us retail stores carry kitchen appliances from General Appliance (and from other manufacturers as well). Because it is planning a major marketing event, Kitchens Are Us needs to ensure that it has a large number of appliances in stock for immediate delivery. Kitchens Are Us uses a marketing tool that generates purchase requests and purchase orders as part of its demand planning functionality. The marketing department uses the tool to create a purchase request in the ERP system by invoking Create Purchase Request. Once SAP ERP creates the Purchase Request, it invokes Notify of Purchase Request to inform the external marketing tool that the purchase request has been created. If the marketing department wants to directly create a purchase order, because it is sure about details such as quantity and supplier, it can use the marketing tool to invoke Create Purchase Order and, once the purchase order is created in SAP ERP, the marketing tool will receive a notification via Notify of Purchase Order.

The following table summarizes these steps and the associated enterprise services:

Step

Enterprise Service Invoked

Step 1: A retailer recognizes the need to update its stock in preparation for a marketing initiative

(No enterprise service is invoked during this step)

Step 2: The retailer, using a third-party marketing tool, creates a purchase request and replicates it to the ERP system

Create Purchase Request

Step 3: Once SAP ERP creates the purchase request, it notifies the marketing tool that the request has been created

Notify of Purchase Request

Step 4: The marketing department, via its marketing tool, may also create a purchase order directly and replicate iit to SAP ERP

Create Purchase Order

Step 5: SAP ERP 6.0 notifies the marketing tool that a purchase order has been created

Notify of Purchase Order

Use Case 6: Scanning Paper Invoices into ERP

When working with suppliers who submit paper invoices, a company may want to preprocess supplier invoices, scanning them and converting them to electronic format via an external system. The system could invoke Create Supplier Invoice to invoke the creation of the invoice in SAP ERP. After the invoice is successfully created, SAP ERP would invoke Notify of Supplier Invoice to inform the external system that the invoice was successfully entered.

The following table summarizes these steps and the associated enterprise services:

Step

Enterprise Service invoked

Step 1: A supplier submits a paper invoice

(No enterprise service is invoked during this step)

Step 2: The paper invoice is scanned into a third-party system and replicated to the ERP system

Create Supplier Invoice

Step 3: The ERP system then notifies the third-party system that the invoice has been successfully replicated to ERP

Notify of Supplier Invoice

Use Case 7: Physical Movement of Goods via xPHM

The industry composite xPHM enables moving physical goods through, for example, an oil and gas pipeline. Movement of goods in this way requires the creation of accounting documents in SAP ERP, but when an operator is opening and closing pipeline valves, the creation of an audit trail may not be the most important thing on his mind. xPHM invokes services in the Procure to Pay ES bundle to account for the change of ownership that takes place through this type of goods delivery. The pipeline operator simply finds the purchase contract by invoking the Find Purchasing Contract Item Basic Data by Elements enterprise service, which uses the Purchasing Contract business object. The composite application xPHM then invokes a series of enterprise services in succession to account for the movement of goods that has taken place:

If a purchase needs to be corrected, the following services will handle that process:

If the operator realizes that he made a mistake and needs to reverse the sequence of documents, perhaps because the wrong contract was specified, xPHM invokes the following series of enterprise services:

He can then restart the process, ensuring the information is correct this time. The necessary audit trail is automatically generated or modified in SAP ERP as needed.

xPHM, although initially targeted at the oil and gas industry, is a general purpose composite for moving large physical quantities of goods. To read more about xPHM, see the Supply Chain Operations and Execution for Oil and Gas ES bundle, the Industry xApp Physical Movement product overview, and "Flexible and Automated After-the-fact Processing in the Oil&Gas Industry - ERP Integration via xPHM" by Volker Keiner. A demo is available at https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/webcontent/uuid/b0d62f68-63d1-2910-f7b0-a7fdfbd1b089.

The following table summarizes these steps and the associated enterprise services:

Step

Enterprise Service Invoked

Step 1: The operator searches for a purchase contract in ERP via the local xPHM composite application

Find Purchasing Contract Item Basic Data by Elements

Step 2: The xPHM composite application then processes the movement of goods and replicates the information to the ERP system

Create Purchase Order/Create Goods Movement with Reference

Step 3: An error is noticed and the operator makes a correction. The operator first cancels the goods movement, makes changes to the purchase order, and then saves the changes

Cancel Goods Movement/Change Purchase Order/Create Goods Movement with Reference

Step 4: A mistake in the process of the goods movement can be corrected by canceling the goods movement and then making necessary changes to the purchase order

Cancel Goods Movement/Change Purchase Order

Step 5: The operator then restarts the process

(No enterprise service is invoked during this step)

Use Case 8: Clinical Trial Management - Investigator Payments (added with Ehp4)

This use case describes how a Life Sciences company could use the Procure to Pay ES in the context of clinical trials to facilitate the communication with investigators (physicians) or CROs (clinical research organizations).

In the course of the clinical trial, the clinical trial sponsor works with a multitude of investigators that need to qualify for a clinical study. The sponsor needs to negotiate contracts with investigators to determine what services an investigator is supposed to perform during a clinical trial at what price (patient examination, x-ray, blood tests etc).  This information could be captured on a purchase order.

Once an investigator has treated patients, the ERP system could be notified about this via a CTM (clinical trial management) or EDC (electronic data capture) system that receives input from the sponsor's monitors, the CRO or the clinical site directly. The rendered services are stored in ERP as goods receipt.

Based on the payment terms listed on the purchase order, the sponsor could create the invoice for the investigator automatically, reducing work load for the investigator, so that he can focus on the medical work and reducing work load on the sponsor side by eliminating the sponsor invoice correctness check. The payments can then be issued from the ERP system without any additional / double data entry.

This entire process could be handled automatically by connecting a CTM and ERP system, thereby reducing error rate and manual data entry effort on the sponsor side and maintaining good investigator relations through accurate and punctual payments.
The following table summarizes these steps and the associated enterprise services:

Step

Enterprise Service Invoked

Step 1: The clinical trial sponsor qualifies the investigator and creates a business partner

Create Supplier

Step 2: The sponsor has negotiated the prices and payment terms with the investigator and creates a PO

Create Purchase Order

Step 3: The investigator has treated patients and he or a CRO reports this to the sponsor via a clinical trial management system, which creates a goods/service receipt

Create_Goods_And_Service_Acknowledgement

Step 4: The sponsor can automatically create the invoice for the investigator

Create Invoice

Step 5: The sponsor pays the investigator for his services rendered during the course of a clinical trial

(No enterprise service is invoked during this step)

Step 6 (optional): If the investigator contract changes (prices or payment terms or the type of services that should be rendered) the clinical trial management system will change the PO

Change Purchase Order

Sometimes investigators still submit paper invoices. Then instead of the create invoice ES, the sponsor could scan the paper investigator invoice and convert it to electronic format via an external system. The system could invoke Create Supplier Invoice to invoke the creation of the invoice in SAP ERP. After the invoice is successfully created, SAP ERP would invoke Notify of Supplier Invoice to inform the external system that the invoice was successfully entered.

The following table summarizes these steps and the associated enterprise services:

Step

Enterprise Service Invoked

Step 1: An investigator submits a paper invoice

(No enterprise service is invoked during this step)

Step 2: The paper invoice is scanned into a CTM (clinical trial management) system and replicated to the ERP system

Create Supplier Invoice

Step 3: The ERP system then notifies the CTM system that the invoice has been successfully replicated to ERP

Notify of Supplier Invoice

Future Directions

Additional enterprise services are planned for development to allow the creation of composites based on this ES bundle.

System Requirements

Success Stories

  • Read about the Keter Plastic success story about how they simplified sand streamlined IT procurement using SOA and the Procure to Pay enterprise services (choose your preferred page format: US / A4)

Related ES Bundles

End-to-end Processes Where This ES Bundle Is Used