Masar Ongp FSD Int000005 V2.0

Project: Masar
Functional Specification Design (FSD)
Stream ONGP
RICEFW Number INT000005
BBP Reference
PD.01 - PD.04
Number
Trading System (ASPECT) Integration
FSD Description -Vessel Nomination from ASPECT to
SAP
Version V2.0
Classification: ENOC Public

Functional Specification Document
Document Control
Change History
Version Date Author Description of Change
0.1 09/05/2020 Gopal Sharma Initial version of Functional Specification
0.9 18/05/2020 Nishant Abichandani Version for business review
1.0 18/05/2020 Nishant Abichandani Accepted FSD
2.0 15/04/2023 Shashwat Sinha Book to book changes
Contact Parties:
Role / Organization Unit Name Description
Functional Consultant Shashwat Sinha
Developer TBD
Development Lead Shashank Subhash
ENOC Reviewed
Name Designation Sign-off date Signature
ENOC Endorsed
ENOC Signed Off

1
MASAR_ONGP_FSD_INT00005__V2.0

Table of contents
1. Functional Description.................................................................................................................................3
1.1 Business Requirement..........................................................................................................................3
2. System Scope...............................................................................................................................................4
3. Constraints, Dependencies, Prerequisites & Assumptions..........................................................................5
3.1 Constraints and Dependencies..............................................................................................................5
3.2 Pre-requisites........................................................................................................................................5
3.3 Assumptions.........................................................................................................................................5
4. Development Type (s)..................................................................................................................................6
4.1 Report...................................................................................................................................................6
4.2 Interface................................................................................................................................................7
4.3 Form......................................................................................................................................................8
4.4 Application (Enhancement / Workflow / Conversion).........................................................................9
5. Input / Import Requirements......................................................................................................................10
5.1 Input / Import Variables / Parameters.................................................................................................10
6. Processing Logic........................................................................................................................................11
6.1 Functional Process Logic....................................................................................................................11
6.2 Technical Process Logic.....................................................................................................................14
6.3 Functional Process Flow.....................................................................................................................16
6.4 Data Requirements..............................................................................................................................16
6.5 Authorization Requirements...............................................................................................................16
6.5.1 Authorization Objects for Programs..............................................................................................16
6.5.2 Authorization Groups for Tables....................................................................................................17
6.6 Language Dependencies.....................................................................................................................17
6.7 Error Management..............................................................................................................................17
6.8 Additional Functions..........................................................................................................................17
7. Output Requirements.................................................................................................................................18
7.1 Output Variables / Parameters.............................................................................................................18
7.2 Special Printing Options.....................................................................................................................18
7.3 Example Outputs / Forms...................................................................................................................18
8. IMG Structure for Custom Developments.................................................................................................19
9. Custom Transaction Details.......................................................................................................................20
10. Testing........................................................................................................................................................21
10.1 Input Data...........................................................................................................................................21
10.2 Test Scenario.......................................................................................................................................21
2

1. Functional Description
1.1 Business Requirement
Currently, scheduling & Actual information is replicated from the trading system, ASPECT, to IRS system & Back
from IRS to ASPECT via a manual process (Email). This can result in the two systems becoming misaligned and
the process is effort intensive. The aim of SAP-ASPECT integration (SAi) project is to generate scheduling data
in both systems from a single point of entry without manual intervention.
While ASPECT is creating nomination and parcel details, in SAP this nomination is used for scheduling,
inventory planning, terminal instructions and instruction to other third party service providers. Hence
nomination in SAP is the Key to all subsequent events as well as inventory updates.
Business requirement is to copy nomination details from Aspect and expand this nomination further for all the
above purposes. Mode of Transport considered is Vessel & Pipeline.
3

2. System Scope
S/4 HANA
ARIBA
IBP
BI
BPC
RETAIL
CPI
PI/PO
FIORI
BO/Lumira
HYBRIS – C4C
HYBRIS – MKT. CLOUD
HYBRIS - COMMERCE
SUCESSFACTORS
MII
LUMIRA
QCI
GRC
Others
4

3. Constraints, Dependencies, Prerequisites & Assumptions
3.1 Constraints and Dependencies

 The master data in the two systems needs to be mapped and that mapping maintained so that the
message from the trading system can be interpreted by the supply system.
3.2 Pre-requisites
 To c
3.3 Assumptions
 All the data needed to create a nomination is entered into the trading systems or can be derived from
data that is present in the trading system.
 All the data entered in the trading system is accurate enough to support subsequent nomination activities
in SAP.
 All the deals made by trading are entered into the system.
 Transfer (between terminals and tank-to-tank) will be created in SAP system.
 Data mapping will be done in SAP.
 Grade codes will be at the right level of detail in both systems.
 ASPECT counter-parties will be mapped to both a vendor and a customer in SAP.
 In Tank Transfer for Sales & Purchase
5

4. Development Type (s)
REPORT
INTERFACE
CONVERSION
ENHANCEMENT
FORMS
WORKFLOW
FIORI
4.1 Report
NA
Execution Mode Batch Online
Report Painter Report Writer BW/BI

Report Creation
with
ABAP Program Fiori Other:
Drill Down Print Sort

Needed
Characteristics
Slice & Dice Other:
Data Volume
Daily Weekly Bi-Weekly

Frequency of
Use
Monthly Other:
6

4.2 Interface
Web service RFC
ABAP/Batch ABAP/Proxy
Interface Type File MII
Web Service PI/PO
CPI Other:
EDI/ALE
Configuration Yes No
Required
Direction (With Others (Please

Inbound Outbound
Respect to SAP) Specify)
Connected
Systems/Partner
System
Sender System
Receiver System
Interface Format <<<e.g. .txt, .xml>>><Attach Sample file>
Primary Protocol
<<<e.g.…SOAP/REST/JDBC/MAIL/ODATA etc.…>>><
Used
Data Volume
Authentication
Basic Certificates Others
Mechanism

Frequency of
Use
Monthly Other:
7

4.3 Form
NA
Output Receiver:
In-House/Third In-House Only Third Party
Party
Special Printing
Form selection based on the surveyor company
Options
Adobe Form Smart Forms
Type
SAP Script Third Party Service
Output Volume

Frequency of
Use
Monthly Other:
Multilingual Yes No
Optical Archiving
Required Yes No
8

4.4 Application (Enhancement / Workflow / Conversion)
Execution Mode Batch Online
Modification User Exit BAPI
BADI Module pool Fiori
Application Type Transaction Enh. Spot Workflow
WebDynpro ABAP
Other: Function modules mentioned in section 6.2 will be modified.
Data Volume

Frequency of
Use
Monthly Other:
9

5. Input / Import Requirements
5.1 Input / Import Variables / Parameters

NA
10

6. Processing Logic
6.1 Functional Process Logic

The interface consists of three elements:
1. Trading System (ASPECT)
Aspect will be the single point of entry and will act as the source system for the data to be transferred.
The operation team will schedule nomination in Aspect system.
2. Middle ware
For the mapping and transformation of data it is assumed that SAP PI is the preferred system. SAP PI will
check the incoming data for certain criteria and performs any required calculations, conversions and
formatting of the data. The results will be recorded in S/4 HANA compatible format.
3. SAP S/4 HANA
SAP receives the data to be processed. When the data is successfully processed, all nomination details
with relevant line items can be examined in the systems and schedulers working in the Trading and
Scheduling Workbench (TSW) can reference this data.
An interface can be viewed as consisting of three stages – source, middleware and recipient systems. The main
steps to an interface are extract, calculate, convert, format, map and load.
First step : extract, calculate

Trading System
Extract the necessary data relating to all the nominations involving

supply and trade deals from the trading front office system. This Data file
information must be captured and uploaded to the middleware system.
Responsibility: ASPECT
Second step : calculate, convert, format and map

Middleware
The file as received from the source system will be mapped by the
middleware into web service and transmitted to SAP. The
middleware will do all necessary data conversion, translation and Mapping
calculation as far as possible.
Responsibility : SAP PI
11

Third step : load

SAP
The web service is received by SAP. Web service processing function

modules read the web service and nominations are created in TSW by
Web
SAP standard RFC function modules populated from the web service. Service
Responsibility : SAP
Data Requirements (Header)

The data that is expected in the SAP system to create a nomination is now provided beneath.
Nomination Type:
Default nomination type ZEGC.
Mode of Transport (Mandatory)

The following modes of transport are defined:
Marine and
Pipeline
Vehicle Identifier
Identifier of the Vessel, or Pipeline in SAP
Transportation System
Identifier for the pipeline, route or other system by which the hydrocarbon is moved.
Trading System Reference

The trading system deal number (e.g. Trading Deal Sheet reference no.)
Unit of Measure
The unit of measure in which the shipment will be measured.
In Transit Plant
This in transit plant will be holding the inventory while it is in transit from the load port to disport journey
Data Requirements (Line)
Location ID
This is the plant or physical location to which the line item refers. For example, a load line would see the field
referenced as a load plant.
Schedule Type
This identifier references whether the line is a load or a discharge.
Scheduled Material
This is the grade that is being moved. In case of Blended Nomination, Product will be final product.
Scheduled Quantity
12

This is the amount of a certain grade being moved.
Unit of Measure
This is the unit to which the quantity above refers.
Scheduled Date
This is the date the line action is due to happen. In case of Load Line it is Loading schedule date & in case of
discharge line item it is discharge schedule date.
Reference Document Indicator

This is the type of reference document that is being referenced, eg Sales Contract
Reference Document
This is the document number that is being referenced.
Parcel ID
This is the Document which contains secondary Code
Cost Type
This is the type of secondary cost.
Cost Rate
This is the Amount of secondary cost.
Cost Currency
This the currency of the cost of Secondary expense
Deal System ID
System ID of the Deal to which the mentioned parcels belong
Service Counter Party ID

This is Service Provider Code for Cost Type
13

6.2 Technical Process Logic
The web service will trigger processing at using the Function module ‘ONGP_NOM_PROCESS’.
Function ‘ONGP_NOM_PROCESS’
This function will receive the web service and perform the following actions.
 Loading and discharge line items in the nomination will be connected using pegging type carrier
nomination (CN)
 The interface needs to determine if the message is to create or change. If there is an entry in OIJNOMI
table pointing to a valid nomination and this nomination line is holding the same ASPECT parcel ID
(Get SO/PO based on Parcel ID from EKKO/EKPO Table & Compare Ref doc Number of OIJNOMI Table)
then we can be certain that this is a change message. At this stage the interface needs to determine
whether there is the correct information in the message to create a change message for the
nomination.
 During Change message we need to check the parcel sent in the inbound message & active parcel
available in Nomination Item Table & act as below.
 New Parcel was linked to shipment in Aspect: Message will have more Parcel then
Nomination Item Table. In this case create nomination item for this parcel.
 Existing Parcel was removed from shipment: Message will have less number of Parcel then
Nomination Item Table. In this case line item with parcel which is not in inbound payload
should be marked as deleted. Check the Parcel ID attached to the Pegged Line Item
 If no nomination lines exist for this Parcel ID (Get the PO/SO from EKKO or VBAK table based on Parcel
System ID) and no current entry is maintained in the OIJNMI table then the action should be
considered create. If the action is a ‘Create’ then all the fields needed to create a message should be
there. If any fields are missing then the web service needs to be set to an error status with the
message ‘Mandatory fields for nomination creation are missing from the web service’.
 If the quantity in the message is a zero quantity/deletion indicator then this means that the web
service message is a cancellation and the logic from the cancellation scenarios below needs to be
implemented.
Scenario Purchase Logic Sales Logic

Cancel before actuals. Delete Nomination lines Delete Nomination lines
Change of Location Data to a FOB/CIF Load Location Load Location

shipment prior to actualisation. Change to Load Location on Nom Load Delete and insert Nom Load Line
Line
Discharge Location
Delete and Insert Nom Disc Line
Change of Location Data to a DES deal Discharge Location Load Location

prior to actualisation. Delete and Insert Nom Line Delete and Insert Nom Load Line
Discharge Location
Change to Nom Disc Line
Change of Counterparty prior to Full Deletion of nomination. Full Deletion of nomination.

actualisation.
Change of Grade prior to actualisation. Change Nomination Line(s) Change nomination line (s).
Change to Dates, Volumes etc. Change Nomination item Change Nomination item
Changes after actualisation Manual Process to Investigate Manual Process to Investigate
14

 Get schedule material from EKPO/VBAP based on Parcel ID system id.

 Map the ASPECT location to a SAP plant by querying table ONGP_MT_LMAP to get SAP mapping for
ASPECT. - ONGP_MT_LMAP
 Map the ASPECT location to a SAP TSW Location by querying table ONGP_MT_TSLOC to get SAP
mapping for ASPECT.
 To know the correct location type to refer to use this logic beneath.
Load Line Discharge Line Ship From Ship To
Purchase (FOB/CIF) O-P TSW Location (O-Line) SAP Plant (D-Line)
Purchase (DES) D-P TSW Location
Sale ( FOB/CIF) O-S TSW Location
Sale (DES) O-X D-S TSW Location
ISTO (FOB/CIF) OI-P D-X TSW Location SAP Plant
ISTO (DES) O-X DI-P TSW Location SAP Plant
 Map the ASPECT vessel to a SAP vessel by querying Vessel Master Table with Vessel System ID.
 Get MOT from TSW Details tab of PO/SO based on Parcel System ID.
 Ascertain whether the movement relates to a purchase, sales Order or ISTO (also based on deal type).
The web service contains a buy/sell/ISTO indicator. If the field is showing a buy then the movement
relates to a purchase order and if the field is showing a sell then the movement relates to a sales
order. The Parcel ID can be used to tie the nomination lines that are being created back to a SAP order
reference.
 If the movement is ISTO, check whether Intercompany STO can be found in the system. If this is the
case then it means that this movement is a back to back sale between 2 supply locations using
Trading.
 Default the nomination type to ZEGC. (Get it from Param Table)
 Map the ASPECT company code, mode of transport and loading location by querying the Company
Code table mentioned in FS INF00003.
 The RFC BAPI ‘RFC_TSW_NOM_CREATEFROMDATA’ then needs to be populated as per the
appendices or in the case of changes and product creations then the RFC BAPI
‘RFC_TSW_NOM_CHANGEFROMDATA’ needs to be populated.
 Event Data has to be mapped on Nomination. To get the SAP Event Type query to Event Mapping
Table mentioned in FS INF00003 with Event System ID.
 Transport System to be determined from mapping table
 Regarding the scheduled dates to be entered, the following logic should be applied but in short load
lines should take the BL Date from the web service, discharge lines should take the ETA Date unless in
tank transfer when the ETA date should be the same as the BL Date anyway.
Load Line Discharge Line

Purchase (FOB/CIF) BL Date ETA Date
Purchase (DES) ETA Date
Sale ( FOB/CIF) BL Date
Sale (DES) BL Date ETA Date
ISTO (FOB/CIF) BL Date BL Date
ISTO (DES) BL Date BL Date
Back to Back Deal BL Date ETA Date
The another scenarios to focus on the movements whereby goods are procured by trader for immediate re-
sale on to another company. These are most often represented by OP – DS nomination.
Details relate to parcel linked to Shipment needs to be sent with Shipment Details.
Secondary Cost with be static condition types mapped in SO/PO.
Parcel ID
15

Get Cost related details from SO/PO (Database Table related details mentioned in the respective FS
documents) & update below table
2 New Fields to be added in OIJNOMI Table to store Parcel Number & Parcel System ID.
Table: OIJNOMI
Field Name Primary Key Type Length Description
Shipment _ID Char 15 Aspect Shipment ID, Should be available in Item of

Nomination & should be always non editable
Shipment_system_id Char 30 Aspect Shipment System Id, Should be available in Item

of Nomination & should be always non editable
Vessel System ID to be added in Vehicle Master Table.

Field Name Primary Key Type Length Description
VES_SYS_ID Char 30 Vessel System ID
Vessel Master Header Screen to be enhanced with above system id field.
*** WO0000000028404 – Book to book changes ***
Addition of new nomination activity type “BTB” to create plant to plant transfer nomination using an
STO.
Interface modified to create plant to plant transfer nomination with reference of an STO. Scenario
type OT and DT mapped in custom tables using which the nomination will be created.
********************************************
16

a)
6.3 Functional Process Flow

NA
6.4 Data Requirements

NA
6.5 Authorization Requirements

NA
6.5.1 Authorization Objects for Programs
NA
Authorization for Organization Unit(s)
Activity
All / Create / Change / Display / Delete
Program Organization Unit (List of activities in the table TACT)
Please specify all single activities (i.e. 01,02,03,
etc.)
<PROGRAM Operating Concern
NAME>
Controlling Area
Company Code
Functional Area
Credit Control
Plant
Purchasing Organization
Warehouse
Storage Location
Shipping Point
Transportation Planning
Point
Sales Organization
Distribution Channel
Division
17

Sales Office
Others Nomination Type
6.5.2 Authorization Groups for Tables

NA
6.6 Language Dependencies

NA
6.7 Error Management

NA
6.8 Additional Functions

NA
18

7. Output Requirements
7.1 Output Variables / Parameters

NA
7.2 Special Printing Options

NA
7.3 Example Outputs / Forms

NA
19

8. IMG Structure for Custom Developments

NA
20

9. Custom Transaction Details

NA
21

10. Testing
10.1 Input Data

NA
10.2 Test Scenario

Positive testing Scenario
 Test the creation of Nomination
 Test the Change of Nomination
 Test the Deletion of Nomination
Negative testing scenarios

 Test the creation of Nomination with not populating some required fields in the Nomination Item
data/ Test some of the mandatory fields are missing in the web service
1) Positive Unit Test
Step T-Code Step Description Expected Results

Scenario#1 O4NCN/O4TEN Create nomination through Nomination is created
nomination interface automatically
Scenario#2 O4NM Update nomination through Nomination is updated

nomination interface successfully.
Scenario#3 O4NM Delete nomination through Nomination is deleted

nomination interface successfully.
Scenario#4 O4NM New Parcel was added to the Nomination should be

Shipment in Aspect appended with line items
related to new parcel
Scenario#4 O4NM Existing Parcel was deleted from Nomination line items
Shipment in Aspect related to deleted parcels
to be deleted.
2) Negative Unit Test
Step T-Code Step Description Expected Results

1 O4NCN Create nomination through nomination interface Nomination is not created
Condition: Few required fields are mossing in the and web service status is in
nomination error.
22

Masar Ongp FSD Int000005 V2.0

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Masar Ongp FSD Int000005 V2.0

Uploaded by

Copyright:

Available Formats

Project: Masar

Functional Specification Design (FSD)

Classification: ENOC Public

ENOC Signed Off

Classification: ENOC Public

Classification: ENOC Public

1.1 Business Requirement

Classification: ENOC Public

Classification: ENOC Public

3. Constraints, Dependencies, Prerequisites & Assumptions

3.1 Constraints and Dependencies

Classification: ENOC Public

4. Development Type (s)

Report Painter Report Writer BW/BI

Drill Down Print Sort

Daily Weekly Bi-Weekly

Classification: ENOC Public

Web service RFC

Interface Type File MII

Web Service PI/PO

Direction (With Others (Please

Interface Format <<<e.g. .txt, .xml>>><Attach Sample file>

Daily Weekly Bi-Weekly

Classification: ENOC Public

Daily Weekly Bi-Weekly

Classification: ENOC Public

4.4 Application (Enhancement / Workflow / Conversion)

Execution Mode Batch Online

Modification User Exit BAPI

BADI Module pool Fiori

Application Type Transaction Enh. Spot Workflow

Other: Function modules mentioned in section 6.2 will be modified.

Daily Weekly Bi-Weekly

Classification: ENOC Public

5. Input / Import Requirements

5.1 Input / Import Variables / Parameters

Classification: ENOC Public

6.1 Functional Process Logic

1. Trading System (ASPECT)

3. SAP S/4 HANA

First step : extract, calculate

Extract the necessary data relating to all the nominations involving

Second step : calculate, convert, format and map

Classification: ENOC Public

Third step : load

The web service is received by SAP. Web service processing function

Data Requirements (Header)

Mode of Transport (Mandatory)

Trading System Reference

The unit of measure in which the shipment will be measured.

Data Requirements (Line)

Classification: ENOC Public

This is the amount of a certain grade being moved.

Reference Document Indicator

Service Counter Party ID

Classification: ENOC Public

6.2 Technical Process Logic

Scenario Purchase Logic Sales Logic

Change of Location Data to a FOB/CIF Load Location Load Location

Change of Location Data to a DES deal Discharge Location Load Location

Change of Counterparty prior to Full Deletion of nomination. Full Deletion of nomination.

Classification: ENOC Public

* WO0000000028404 – Book to book changes *