SAP Purchase-to-Pay

• Process description
  • KPIs Specification
• Extraction
  • System configuration
  • Extraction tool configuration
• Input data
  • Input types
  • Input tables & fields
• Configuring transformations
  • Dbt variables
• Design specifications
  • Objects
  • Activities
  • Design details

Process description

Purchase-to-Pay is the process from a buyer's perspective of buying, receiving, paying and accounting for goods. The process starts with a purchase request and ends with the payment of the invoice and includes all confirmation and checking steps in between. It is one of the core processes in an organization and is typically performed by multiple departments. The most important artifacts of the Purchase-to-Pay process are purchase orders, receipt of the goods and the invoice. Purchase-to-Pay is also known as Procure-to-Pay.

Purchase-to-Pay covers the following main processes in the procurement lifecycle.

• Buying;
• Delivery;
• Payment.

Note that the Delivery and (parts of the) Payment processes are usually done in parallel.

Buying The process starts with a buyer from the company who wants to buy some goods. The buyer requests the purchase, using a purchase requisition. Procurement is involved to get the best deal. This could mean negotiation for a new contract or adapting to an already available contract. Procurement converts the requisition to a purchase order and makes sure the missing information is filled where needed. Procurement approves the purchase order (PO), which is then sent to the vendor.

Delivery The warehouse department (if available) waits for the goods to be received. When goods arrive, the inventory is checked and updated. The goods are received by the initial buyer, who accepts the goods.

Payment The finance department awaits the invoice to be received. When the invoice arrives, it is administrated. The invoice is paid by accounts payable. Accounting administrates the payment.

With the SAP Purchase-to-Pay app template you can create process apps that give insight in how your Purchase-to-Pay process actually performs. For example, how long it takes for a purchase request to become an actual Purchase Order, how long it takes to process the Purchase Orders, and most important to what extent are you paying in time. For all steps in the process, Purchase-to-Pay provides insights into the throughput times.

KPIs Specification

The following table describes the KPIs defined in SAP Purchase-to-Pay app template and presented in different dahboards:

Extraction

System configuration

The data extraction is developed for SAP.

Extraction tool configuration

The data extraction is developed for SAP and is using Theobald Xtract Universal. In general, you should follow the steps as described in Loading Data Using Theobald Xtract Universal (Automation Cloud) to set up data loading using Theobald Xtract Universal. Note: If you are using Automation Suite, make sure to select AUTOMATION SUITE as the DELIVERY option on the documentation page. In addition, select the Automation Suite version you are using to open the appropriate Loading Data Using Theobald Xtract Universal page.

Importing the template extractions

1. Download the XU_template_extractions.zip file with template extractions for Automation Cloud or the XU_template_extractions_as.zip file with template extractions for Automation Suite.
2. This file contains the folders destinations, extractions, and sources. Copy the folders from the downloaded zip file to the config folder of Xtract Universal. The location of this folder is [XU_installation_path]/config.
3. Open Xtract Universal Designer and click on the refresh button to load all extractions.

Configuring the extraction script

1. Download the extract_theobald.zip file to load data for Automation Cloud or extract_theobald_as.zip to load data for Automation Suite.
2. This file contains the extract_theobald.ps1 script and the config.json file. Unzip the content on the server where Theobald Xtract Universal is installed.
3. Configure the variables for the script.

Input data

Input types

The following table provides an overview of the different field types and their default format settings.

Input tables & fields

The following tables are extracted from the source system:

Purchase requisition tables

EBAN

Stores Purchase Requisition Data.

Filtering: BSTYP = 'B', Date: BADAT

Purchasing document tables

EKKO

Stores Purchasing Document Header Data.

Filtering: BSTYP = 'F', Date: AEDAT

EKPO

Stores Purchasing Document Item Data.

Filtering:BSTYP = 'F'

EKBE

Stores History per Purchasing Document Data.

Filtering: BEWTP = 'E' AND SHKZG = 'S' Date: CPUDT

EKET

Stores Scheduling Agreement Schedule Lines Data.

EKKN

Stores Account Assignment in Purchasing Document Data.

Invoice tables

RBKP

Stores Document Header Invoice Receipt Data.

Filtering: Date: CPUDT

RSEG

Stores Document Item Incoming Invoice Data.

Accounting tables

BKPF

Stores Accounting Document Header Data.

Filtering: Date: CPUDT

BSIK

Stores Accounting Secondary Index for Vendors Data.

Filtering: BUZEI = 001 Date: CPUDT

BSAK

Stores Accounting Secondary Index for Vendors (Cleared Items) Data.

Filtering: BUZEI = 001 Date: CPUDT

BSE_CLR

Stores Additional Data for Document Segment Clearing Information Data.

Filtering: BUZEI = 001 AND (CLRIN = '' or CLRIN = 2)

Change log tables

CDHDR

Stores Change Document Header Data.

FIltering: OBJECTCLAS in ["BANF", "EINKBELEG", "INCOMINGINVOICE", "BELEG"] Date: UDATE

CDPOS

Stores Change Document Item Cluster Data.

Filtering: FNAME in ["KEY", "BANPR", "PROCSTAT", "FRGZU", "LOEKZ", "ABSKZ", "NETPR", "ZLSPR", "ZTERM", "ZFBDT", "ZUONR", "BVTYP", "HBKID", "AUGBL"] AND TABNAME in ["EBAN", "EKKO", "EKPO", "RBKP", "RSEG", "BSEG", "BSEGR"] AND CHANGENR >= '<value>' AND CHANGENR <= '<value>' (For example, AND CHANGENR >= '0001299707' AND CHANGENR <= '0001507899')

User master data tables

USR21

Stores User Name/Address Key Assignment Data

ADRP

Stores Persons (Business Address Services) Data

Filtering: NATION = '' or NATION = 'I'

ADCP

Stores Person/Address Assignment (Business Address Services) Data

Filtering: NATION = '' or NATION = 'I'

USR02

Stores Logon Data

Supplier master data tables

LFA1

Stores General Vendor Master Data

T005T

Stores Country Names Data

Filtering: SPRAS = 'Language'

T005U

Stores Taxes Region Key Texts Data

Filtering: SPRAS = 'Language'

Customer master data tables

KNA1

Stores General Vendor Master Data

Material master data tables

MAKT

Stores Material Descriptions Data

Filtering: SPRAS = 'Language'

T023T

Stores Material Group Descriptions Data

Filtering: SPRAS = 'Language'

T001L

Stores Storage Locations Data

T006A

Stores Assign Internal to Language-Dependent Unit Table and Data

Filtering: SPRAS = 'Language'

Organizational structure master data tables

CSKT

Stores Cost Center Texts Data

Filtering: SPRAS = 'Language' AND DATBI = "99991231"

T001

Stores Company Codes Data

T001W

Stores Plants/Branches Data

T024

Stores Purchasing Groups Data

T024E

Stores Purchasing Organizations Data

TGSBT

Stores Business Area Names Data

Filtering: SPRAS = 'Language'

Purchasing document master data tables

T161T

Stores Texts for Purchasing Document Types Data

Filtering: SPRAS = 'Language'

Block & Cancellation reasons master data tables

T008T

Stores Blocking Reason Names in Automatic Payment Transactional Data

Filtering: SPRAS = 'Language'

Currency master data tables

TCURR

Stores Exchange Rates Data

Filtering: KURST = 'Exchange rate type'

TCURF

Stores Conversion Factors Data

Filtering: KURST = 'Exchange rate type'

TCURX

Stores Decimal Places in Currencies data

Configuring transformations

Dbt variables

Note that while there is a date format that can be configured in the dbt variables, there is no time format defined. The time format is implemented via a custom macro. This is done because SQL server does not support converting the 6 digits time format to time data type.

Design specifications

Objects

The following diagram shows all objects that are used for the process.

Process objects

Master data objects

Activities

Design details

Change log

The Change log, created by joining the CDHDR and CDPOS tables, is not an object on its own, but is used for all objects to generate the corresponding events. By default the Change log contains only changes for the default activities, gained by filtering on the FNAME field from the CDPOS table during data extraction.

For each object its 'change events' are created as follows:

• Retrieve the changes relevant for this particular object by filtering the Change log on the TABNAME field.
• Define the activities using this filtered data, based on the FNAME, VALUE_OLD and VALUE_NEW fields.
• Generate the events by joining the resulting activities to the corresponding object table, based on the TABKEY field, which contains the ID of the object (Sales Order, Invoice, etc.) on which the activity occurred.

Automated events

An event can be labeled as automated. This is dependent on the user_type associated with the event. The user_type stems from the USR02 table. If the value of the field USTYP is B or C, meaning System or Communications Data, respectively, the event is labeled as 'Automated'.

Currency conversion

Price-related information is given in a certain currency. These prices and corresponding currency are stored in the document tables. These currencies vary between items. To be able to analyze all of them in one app template, all prices are converted from their document currency to a single currency, referred to as the reporting currency. The reporting currency is a variable that can be specificed in dbt and unifies all the currencies shown in the App template. The currency conversion is done based on the exchange rate information stored in the TCURR, TCURF, and TCURX tables. In case the exchange rates listed are an indirect rate, they contain a - to indicate this.

Currency conversion is applied on all object values, including purchase requisitions, purchase order items, accounting documents, invoice items and payments. The corresponding SQL files can be found in the folder currency conversion, under the objects folder in the transformations. Except for purchase requisition, all objects require two steps for currency conversion:

• From document currency to local currency;
• and from local currency to reporting currency. The reason for this two step approach is that there is a specific exchange rate reported for these objects in the corresponding SAP tables which might be manually adjusted to a more accurate rate at the time that the document is recorded. Therefore, we will take that exchange rate into account to convert the document currency into the local currency first and then we use the local currency to convert it into the reporting currency. It is important to note that we skip the first conversion step, if the document currency is already the same as the local currency or no valid exchange rate is found for the document currency to local currency conversion. In that case, the document currency will be converted directly into the reporting currency.

The local currency is the currency of the company. This local currency can be found in the company table T001. The conversion to the reporting currency is done based on the exchange rate information stored in the TCURR, TCURF, and TCURX tables. In particular, the TCURX tables is used to determine the number of decimal places for each currency. This is important to get the correct conversion factor from the TCURF table. The TCURF is used to determine the conversion factor between two currencies. For example, if you want to convert from USD to EUR, you need to find the row in TCURF where FCURR = 'USD' and TCURR = 'EUR'. The conversion factor is then calculated as TFACT / FFACT. This factor is particulary important when two currencies have a different number of decimal places. For example, if you want to convert from JPY (0 decimal places) to USD (2 decimal places), you need to take into account that 1 JPY = 0.0091 USD. This is done by using the conversion factor from TCURF. the TCURR table is used to determine the exchange rate between two currencies. For example, if you want to convert from USD to EUR, you need to find the row in TCURR where FCURR = 'USD' and TCURR = 'EUR'. The exchange rate is then given by the UKURS field.

The only exeption in having the two step currrency conversion is purchase requisition where no specific exchange rate is reported in the corresponding SAP tables of this object. Therefore we convert the document currency directly into the reporting one, without the need for local currency conversion step.

Table below gives an overview of the fields used for currency conversion per object. It is important to note that for each object the baseline date for currency conversion is different. This is because the date used for currency conversion should be as close as possible to the date of the transaction. For example, for purchase requisition we use the request date while for purchase order item we use the date of price determination. Each object also has its own value field which is used for currency conversion: