The SAP S/4HANA Supply Chain for secondary distribution solution enables you to map all business

processes required in the petroleum trade with end customers, wholesalers, resellers, or service
stations. It comprises the purchase, storage, transportation, and sale of fuels and lubricants. It
contains the following functional areas:

● Tele Sales (TS)

● Continuous Product Replenishment (CPR)

● Retail Fuel Network Operations (RFNO)

● Data Collation (DC)

● Interfaces (IF)

● Integrated Dispatch Management (S4IDM)

Implementation Considerations SAP S/4HANA Supply Chain for secondary distribution is an SAP Oil &
Gas add-on that uses functions from ISOil Downstream. Integration with the industry solution Oil &
Gas is guaranteed. You cannot implement SAP S/4HANA Supply Chain for secondary distribution on
its own. It must be implemented in conjunction with IS-Oil Downstream (for example, functions for
oil quantity conversion) and SAP ERP (for example, Sales and Distribution functions).

You can use this business function to activate the functions of Oil & Gas Secondary
Distribution (OGSD). With OGSD you can manage all business processes required
in the petroleum trade with end customers, wholesalers, resellers, or service
stations. The component comprises the purchase, storage, transportation, and sale
of fuels and lubricants.

Prerequisites
 You have installed the following components as of the version mentioned:

Type of Component Component Required for the Following Features Only

Software S4SCSD
Component

Features
Tele Sales

Tele Sales helps you to create sales documents by providing a number of

background data about your customer. You have direct access to financial data,
order history and customer specific notes.

Data Collation

Data Collation helps you to post complex logistics business processes especially for
Oil and Gas Downstream by entering only reference data (e.g. reference document,
business partner) and after-the-fact data like changed quantities for loading, sales,
and unloading. Data Collation then makes the necessary adjustments in existing
logistics documents and creates all required follow-up documents.

Interfaces

Interfaces helps you to integrate external data from partners such as depots and
haulers received via ALE or flat files. Interfaces can verify and convert received data
and then feeds it to Data Collation. By combining Interfaces and Data Collation a
high grade of automation in logistics processes can be achieved.

Continuous Product Replenishment

This process provides your customers with a steady supply of products based on
their requirements by continuously calculating and monitoring the expected material
consumption.

SCSD Configuration Guide

Contents
1. Introduction.....................................................................................................................................
2. Data Collation (DC-PAT)...................................................................................................................
2.1. PAT-DC Data Structures...........................................................................................................
2.2. PAT-DC IMG.............................................................................................................................
2.2.1. Process Automation Toolset (PAT).......................................................................................
2.2.2. General Settings...................................................................................................................
2.2.3. Data Collation Documents...................................................................................................
3. SCSD Interface...............................................................................................................................
3.1. General Settings.....................................................................................................................
3.2. Interface Control....................................................................................................................
3.2.1. Define Segment Conversion Rules.....................................................................................
3.2.2. Define Conversion Groups.................................................................................................
3.2.3. Define Interface.................................................................................................................
4. SCSD Ticket Processing..................................................................................................................
4.1. SCSD Ticket Processor definition............................................................................................
4.2. SCSD Item Category Set.........................................................................................................
4.3. SCSD Field Group...................................................................................................................
 4.4. SCSD Cross Reference Types Definition.................................................................................
4.5. SCSD Business Process ID.......................................................................................................
4.6. SCSD Interface Sales Return order type mapping..................................................................
4.7. SCSD Global Control Panel Process Button Definition............................................................
5. STVARV variant maintenance........................................................................................................

1. Introduction
SCSD PAT Data Collation is the solution being used for BOL handling at Ticket. The solution comprises
of the standard Data Collation solution for automating the posting of BOL documents and a Ticket
Processing solution that is responsible for bringing the interface data and converting it to PAT reports
based on the PIN in the BOL.

2. Data Collation (DC-PAT)

Data Collation is the PAT (Process Automation Toolset) based solution that automates the posting of
SAP documents like Sales Order, Deliveries, Goods Issue, Stock Transfers, Goods receipts, etc. A DC-
PAT report typically consists of multiple items and the documents that will be posted by an item are
controlled by the ‘Item Category’ of that item. At Ticket, we use a type of PAT Data Collation report
called as ‘Standard’ PAT report. It is a WebDynpro transaction and is launched in a browser.

Transaction code: /PAT/DC_ST

1. Business Processes

1.1 Design Principle

The iDOC is translated into PAT documents which will create the document flow in SAP. Based on
the PIN the system tries to find a customer cross reference in the area of Rack and Terminalling.
When successful it creates a ticket and PAT report for each of the two CR Types.

The cross reference defines the Item Category Set to be posted. An Item Category Set consists of
one or more Business Process IDs which translate to an item category which than defines the
sequence of SAP transactions to be posted.

The following picture illustrates the dependencies.

 One or many Posting Rules – SAP Transaction creating a document – are combined by a PAT Item
Category. These Item Categories are assigned to Business Process IDs. Where an Item Category
can be assigned multiple times using a different BP ID. These Business Process IDs are combined
to form the Item Category Set.

This Item Category Set is assigned to a Customer Cross Reference record.

Business Process IDs

There is a set of postings identified by their Business Process ID. These BP IDs map 1>1 to PAT
Item Categories. The BP ID is used to identify a different business process also the PAT Item
category is be the same.

The following table shows the business process IDs defined with their corresponding PAT item
categories:

Business PAT Item

Business Process Description Item Category Description
Process ID Category
BBP Sell-Buy-Sell Purchase SPC Supply with Purchasing Contract
BBS Sell-Buy-Sell Sale CSC Customer Sales: with Contract
DBK RFNO Dip Book update DBK Create RFNO Dip Book entry
PCR Purchase with Contract reference SPC Supply with Purchasing Contract
PNR Purchase w/o Documents SPN Supply without Documents
RGD Regrade to Service Station Product CLP Carrier Supply: Own Storage
RSC Regular Sale with Contract ref. CSC Customer Sales: w/o Documents
 RSN Regular Sale - w/o Documents CSN Customer Sales: w/o Documents
STC Sale to Customer CSN Customer Sales: w/o Documents
STO Stock Transfer STN Stock Transp. Order w/o Documents
STR Stock Transfer w. Reference STC Stock Transport Order with Contract
TFE Terminalling Fee SPC Supply with Purchasing Contract
TRF Truck Freight Purchase SPC Supply with Purchasing Contract

These business process IDs are used to put together a chain of these processes, called Item
Category Sets.

Item Category Sets

The following table shows the Item Category Sets of PINs using the specific ItemCatSet. This is a
snapshot only. These numbers will vary but gives a good overview of the processes used.

Item Cat Set Description # of PINs

RS Regular Sale – no contract ref 11,972
3PTD Third Party Terminalling - Delivery 9,662
STP STO Plant to Plant 2,104
EXRS Exchange Receipt>Sale 428
BCSN 3rd Party Buy with contract ref > Regular Sale no contract ref 288
SC Sale with contract reference 257
3PTR Third Party Terminalling - Receipt 241
STCRS STO with contract ref > Regular Sale no contract ref 128
SBS Sell >Buy > Regular sale 116
BCST 3rd Party Buy with contract ref > STO to Retail Site 96
SBST Sell >Buy > STO to Retail Site 85
EXRST Exchange Receipt>STO To Retail site 37
EXR Exchange Receipt 21
3PTT Third Party Terminalling - Transfers 14
STCST STO with contract ref > STO to Retail Site 1
BCSC 3rd Party Buy with contract ref > Regular Sale with contract ref 0
EXD Exchange Delivery 0
EXRSC Exchange Receipt > Sale with contract ref 0
STRS STO Plant > Regular Sale no contract ref 0
STSC STO Plant > Regular Sale with contract ref 0
STSC2 STO Plant > Regular Sale with contract ref (repeat Sec. Cost) 0

The following chapters showing each process flow separately. They are sorted in the sequence of
how often they have been used for customer PINs.

RS - Regular Sale – no contract ref

 This process is posted on TRMC side. The process steps potentially posted are:

Item Cat Posting Rule Description

CSN GOODSTRANS Material transfer posting
- only if BOM table maintained or components delivered
SORDERCRE Create sale order
OUTBDLVCRE Create outbound delivery
GOODSISSUE Create goods issue
BILLINGCRE Create billing document - no PAT invoices at Specific requirement
SPC PORDERCRE Create purchase order
- Purchase of freight service from carrier
GOODSRCPT Create goods receipt
SPC PORDERCRE Create purchase order
- Purchase of terminalling service from terminal operator
GOODSRCPT Create goods receipt
3PTD - Third Party Terminalling – Delivery

This process is posted on TLLP side. The process enables the inventory tracking and terminalling
fee determination. It is not for selling the product. The SD pricing setup is just for calculating
fees.

The process steps potentially posted are:

Item Cat Posting Rule Description

CSC GOODSTRANS Material transfer posting
- only if BOM table maintained or components delivered
LIACREATE Create logical inventory adjustment
- only necessary for blended products
The logical inventory for a material means the material quantity,
which, due to exchange movements that took place, exists as
payables or receivables with respect to the exchange partner.
Logical inventory can be settled using an LIA, in which settlement
is in material quantities.
SORDERCRE Create sale order
OUTBDLVCRE Create outbound delivery
GOODSISSUE Create goods issue
BILLINGCRE Create billing document - no PAT invoices at Specific requirement
 1.1.1 STP - STO Plant to Plant

This process is posted on TRMC side. The process steps potentially posted are:

Item Cat Posting Rule Description

STN GOODSTRANS Material transfer posting
- only if BOM table maintained or components delivered
PORDERCRE Create stock transfer order (PO)
OUTBDLVCRE Create replenishment delivery
GOODSISSUE Create goods issue / goods receipt
BILLINGCRE Create billing document - no PAT invoices at Specific requirement
CLP GOODSTRANS Material transfer posting from branded fuel to generic service
station material
SPC PORDERCRE Create purchase order
- Purchase of freight service from carrier
GOODSRCPT Create goods receipt
SPC PORDERCRE Create purchase order
- Purchase of terminalling service from terminal operator
GOODSRCPT Create goods receipt

2.1. PAT-DC Data Structures

Data Collation has the following major database tables where the report data is stored:

1. /PAT/METADOCS – Holds the PAT report status, creation and change record and other
meta-data associated with the document.
2. /PAT/DC_HEAD – Header data
a. /PAT/DC_HITEM – Head Item data. PAT Item category and other to be generated
document header level data (e.g. Sales Order types, Customer, Vendor, etc) are
stored here.
i. /PAT/DC_ITEM – Sub-item data. Document item level data like Material
number, volumes, plant, etc is stored at this level.
1. /PAT/DC_RBMAT – Material transfer item components for blending
are stored in this table.
ii. /PAT/DC_SDDOCS- Sub-item sales document data. All the referenced and
posted sales documents like Contract, orders, deliveries, etc are stored in
this table.
iii. /PAT/DC_MMDOCS- Sub-item Purchase document data. All the referenced
and posted MM documents like Contract, orders, etc are stored in this table.
iv. /PAT/DC_PARTNER – Header and item level partner data are saved here.
v. /PAT/DC_EXTDTL – All the item is-oil external details data are stored here.
vi. /PAT/DC_DCDOCS – The reference PAT reports for reversal are stored in
this table.

2.2. PAT-DC IMG

The Customizing node for Data Collation can be accessed via the following path: IMG-> IS-Oil
(Downstream) -> S4SCSD -> Data Collation (DC)

2.2.1. Process Automation Toolset (PAT)

IMG: S4SCSD->Data Collation->PAT

1. General Settings -> Edit Event Methods of the PAT:

All custom methods related to Process flow, Dialog control and Postings are defined
under this node
2. General Settings -> Mapping: All the mapping activities related to passing data to
PAT reports from reference document and passing of data from the PAT report to
the documents being created from PAT are defined here.
o Determine Permitted Source and Target Objects for Mapping: The tables
and data structures to be used for mapping should be predefined under this
node. Application ‘DC’ is the one used for all data collation related activities.
o Define Mapping Group and Field Assignment: Mapping groups and the
actual field mapping is defined under this activity. It provides many options
to control how the data is actually transferred from source to target like: ‘Do
not overwrite’ which prevents target data to be overwritten if it is not empty
and ‘No empty values’ which makes sure if the source is empty, it will not
get transferred to the target. Field processing method can also be used to
perform the mapping. At Ticket, we use custom method 9510 to determine
the ‘Pricing Type’ that is passed to the sales order based on the type set up
in the configuration

o Define the Mapping Schema and Assign the Mapping Groups: Mapping
Schema is defined here and one or more mapping groups can be assigned to
it.

3. Process -> General -> Define Incompleteness Schemas: Custom Incompleteness

checks can be defined under this activity. These checks are performed on releasing
the PAT report before it can be posted. For ticket processing, these checks are
performed in the background through the interface. To create custom
incompleteness checks, either a new Incompleteness schema should be defined or
add incompleteness check methods to existing schemas. A custom method has been
added for Ticket which checks the posting date on the PAT lines and sets it to first
day of the current open period if posting date was in closed period. The schemas
should be assigned to the item types to be active.

4. Process -> General -> Define Item Types: The process controlling item types are
defined here. Item types are formal elements to which one or more process
schemas are assigned. Whether an item type can be used for reversal also needs to
be specified here.

5. Process -> General -> Define Document Types and Assign Item Types: The PAT report
document types are defined in this activity. We use document type ‘Standard’ at
Ticket. The item types and the corresponding cancellation item types are also
assigned to the document type in this activity.

6. Process -> General -> Define Reference Objects: In this Customizing activity, you
create reference object types and define fields in the document pricing procedure,
which can contain reference objects. If the assigned fields are filled, the PAT
 document will be completed with data from the reference object. In addition, you
can define the processing sequence for the reference documents. E.g: Sales Contract
is the reference object for Item category CSC.

7. Process -> Posting

o Define Process Rules: A process rules defines the most granular posting step
of a PAT posting process. A method is assigned to every Process rule that
performs the posting of SAP document (like creation of orders, deliveries,
goods movements, etc). A mapping schema can also be assigned to a posting
rule to source how field values need to be supplied to a document. For
custom posting requirements, the standard posting method can be copied
and adjusted as per requirement.

General Settings -> Edit Event Methods of the PAT:

The underlying posting class can be inherited to a custom class and only
certain required methods can be redefined to write custom code:

Like for Sales order creation step, we redefined the SUBMIT method to use
BAPI_SALESDOCUMENT_COPY for creating the return order.

o Define Process Schemas: A Process Schema is a collection of Process Rules

put together in a sequence. Condition methods can be assigned to steps
within a schema to check for certain conditions to determine if a process
rule should be executed or skipped. For example, the SALES Process Schema
consists of rules from order creation and all the way up to billing document
creation.
o Define the Posting Profile: Posting Profile is collection of Process Schemas
put together in a sequence. It also has the option of assign condition
methods to skip certain Process Schema execution. The combination of
Posting Profiles and Posting Schemas provides a modular approach to put
together processing blocks.
o Assign Posting Profile to Item Type: In this activity, Posting Profile gets
assigned to the Item Type forming the posting engine of the item.

The diagram below explains the relationship between the components that form
the posting backbone of PAT:
 8. Dialog-> Define Item Categories: In this activity, the PAT item categories we see in
the dialog are mapped to the Item types.

2.2.2. General Settings

IMG: S4SCSD->Data Collation->General Settings

1. Process Event Methods of Data Collation: Use this activity to define event methods
that are specific to Data Collation. A custom routine is defined for Ticket to
determine the return order type here:

The return order type is read from the customizing table /ITPC/SOTYPE_MAP in this
method.
 2.2.3. Data Collation Documents
IMG: S4SCSD->Data Collation->Data Collation Documents

1. Specify Document Type: The Data Collation document type is defined under this
node. We are using ‘Standard’ document type at Ticket.

2. Specify Item Type: The item types specified here represent the posting engine for
the Item Category used on the PAT report for Data Collation application. The
following Item types are being used at Ticket:
o SALES – Sales
o RSALES – Return (Reversal of Sales)
o XSALES – Cancellation of Sale
o STGESUPPLY - Storage Supply (Purchase)
o XSTGESUPPL – Reversal of Storage Supply (Cancellation of Purchase)
o STOSUPPLY – Stock Transport Orders
o XSTOSUPPLY – Reversal of Stock Transport Orders
o CARRLOADO – Own Storage supply (used for re-grading to Service Station
material)
o XCARRLOADO – Reversal of Own Storage supply (cancellation of re-grade to
Service Station material)

3. Set Cancellation Function: The cancellation item category to be used is defined in

this node. The main item category is mapped to a cancellation item category directly
or via a customizable method. For the sales item categories, we have a method
(9001) configured where the determination is made to use a reversal or cancellation
item category based on whether the sales delivery is already invoiced or not.

4. Multireference: Using the activities under this node, we can pass reference
documents to the multi-reference tab in the sales order. At Ticket, we use this
function to pass the blending material document number to the sales order that has
the final finished product. The material document is used in the sales order to do
calculate excise taxes based on the component products.
Below is an example:

During posting, PAT posts the blending material document first and then creates the
sales order and attaches the blending document to the order as a multireference.

o Define Multireference Document Categories: The multi-reference document

category ‘BL’ is defined here for blending document.
o Define Reference Document Schema: The reference document schema is
defined under this node. The document ‘BL’ is assigned to existing schema
‘TPY’.
 o Assign Reference Document Schema to Item Type: As a last step, the schema
needs to be assigned to the item type. TPY is assigned to item types ‘SALES’
and the reversal/cancellation item types.

3. SCSD Interface
3.1. General Settings
IMG: S4SCSD -> Interfaces (IF) -> General Settings

1. Define Event Methods for IF: In this Customizing activity, you create methods that
control the behavior of the interface during different events such as Read Source data,
Save Data, etc.
The following interface methods are used for Ticket Processing:

2. Assign Document Tables to the Applications: In this activity, the tables that are used to
store the interface data are defined. The ticket tables store the interface data for the
ticket interface:

3. Define Document Schema: The interface data schematic (Ticket data for Ticket
Interface) is defined in this activity.
 3.2. Interface Control
IMG: S4SCSD -> Interfaces (IF) -> Interface Control

3.2.1. Define Segment Conversion Rules

In this Customizing activity, you define conversion rules for segments of the inbound data in
records of the interface document. We have defined the conversion of Ticket Idoc data (Basic
type /ITPC/BOL) to the Ticket data (defined in the Document Schema above). We have
conversion rule for the header and item data:

Here we can control how the data gets transferred from idoc to ticket (E.g: perform data
formatting, data conversion/lookup using custom methods, preconditions):

3.2.2. Define Conversion Groups

Conversion groups create a document and represent a logical unit for 1 to n conversion rules
which normally refer either to segments, lines, of an IDoc or possibly to lines of a source file
which are to be processed. We have the below Conversion Group defined for the Ticket
interface:

The conversion rules that are defined in the step above are assigned to the conversion group:
 3.2.3. Define Interface
In this Customizing activity, you define an interface. It determines which inbound files will be
processed and by which conversion rules the processing will be conducted. We have created
the below interface for Ticket processing:

We assign the conversion group defined above to the Interface:

Other attributes like the number range for the tickets to be created from idoc data, the
document schema, log object etc are also defined here.

Multiple message types can be defined here if Ticket chooses to add more messages in the
future for this interface.

4. SCSD Ticket Processing

To access the SCSD Ticket processing customizing tree, go to Transaction code SIMGH and search
for IMG structure ‘SCSD Inbound Ticket Processing’. It can be added to favorites for easy future
access:
 4.1. SCSD Ticket Processor definition

4.2. SCSD Item Category Set

An Item Category set defines the individual processes that have to be posted for a ticket. It
consists of PAT Data Collation Item categories in a specific sequence and the data fields required
for those item categories.

The Item Category Set should be defined along with the applicable cross reference type (CR
Type) and the processing class. The ICSet header consists of the PAT document type to be used
and the field group definition of the header fields available on the Cross Reference document to
be created for this ICSet. The mapping method to transfer the header level fields to the PAT
creation BAPI and the method to Save and Post the PAT BAPIs is defined here, as well.

The ICSet Item data that consists of the applicable Business Process Id and the sequence in which
they should be accessed should be defined here. The field group applicable for the BP Id and the
corresponding item level mapping method should also be defined here
To create a new Item Category set, we need to follow the below steps:

 Click ‘New’ and enter the creation mode

 Enter the Header level details for the IC set. We define the PAT report type to be used
and the method to define the header field mapping and the method to save and post
the PAT report. One Item Category set can create more than one PAT report by adding
more header data count. At Ticket, all the configured ICsets only create one PAT report

 Under each header data, we assign the items. At the item level we define the sequence
of business process that should be posted by an Item Category Set. The field groups and
the mapping method for each business process step are also to be assigned here.

/ITPC/CL_TICKET_INTF_HANDLER is the main class for processing the ticket. It is a custom

created class and more methods can be added to it as required.

Note: When creating new methods, always copy from existing methods to keep the required
interface for the methods

4.3. SCSD Field Group

The field group definition controls the allowed and mandatory fields for IC-Set header as well as
the items of the set.

Define the field groups to be used for Header and Items of the Item Category sets. The table
being used as a field source should be assigned here. The control can be set at individual fields of
the catalog to allow enablement of the field, if the field can be edited in the cross reference and
if the field is mandatory.

New field groups can be created in future for new item category sets.

4.4. SCSD Cross Reference Types Definition

Cross Reference Type is required to define multiple cross reference documents that can be
looked up against each ticket. We have defined cross reference types R and T at Ticket:

4.5. SCSD Business Process ID

The Business Process ID attaches a business process identity to each PAT Item Category in an
Item Category Set. The following Business Process ids have been defined at Ticket:

New Business Processes can be defined here as required in the future.

4.6. SCSD Interface Sales Return order type mapping

In this activity we can map the Original order type to the Return Order type be used for creating
the return order through PAT. It is called from the method defined under ‘Process Event Methods
of Data Collation’.
 4.7. SCSD Global Control Panel Process Button Definition
This activity can be used to control the processing buttons that are enabled on the Global Control
Panel for the combination of Ticket Type of Overall Status of the BOL item

The button code should be set based on the process that can be executed for the combination of
Ticket Type and Overall status. The button codes are defined as a sum of values of individual
buttons represented in binary progression as explained in the attachment below.

5. STVARV variant maintenance

To control various ticket processes, we have the following TVARV parameters defined:

 ZTLLP_SOURCES - TLLP sources for the interface

 ZGCP_ENABLE_LOGGING - Enable logging of GCP status changes to table
/ITPC/GCP_STATC. Set to ‘X’ to enable logging.
 ZHSC_OGSD_SRVMAT_FRT - Service materials to be looked up from Freight contracts
 ZHSC_OGSD_SRVMAT - Service materials to be looked up from Terminalling
contracts
 ZPAT_POST - Control flag to post PAT through interface or just save it(no
posting)
 GCP_CO_CN_RT_RP_DH_DI_DT_SC_SR – Control which buttons on the Global Control Panel
should be Visible (Position Value = ‘V’) or Hidden (Position Value = ‘H’).
CO – Continue CN- Cancel RT- Reverse RP-Reprocess DH-Deactivate Header DI-Deactivate
Item DT-Deactivate Ticket SC-Cancellation of Partially Posted PAT SR- Reversal of Partially
Posted PAT