Is Oil PDF

&KDSWHU
([FKDQJHV(;*DVSDUWRI

,62LO'RZQVWUHDP
+LJK/HYHO6XPPDU\
The objective of the Exchanges function category within R/3 IS-Oil Downstream
is to build on the functionality within the Core SAP R/3 product to enable the
processing and management of exchange agreements between oil companies
involved in downstream activities.
The IS-Oil System provides:
q Support for a company using SAP-System R/3 to exchange products
with another company to their mutual benefit.
q Capability for maintenance of exchange inventory positions. It is possible
to monitor the exchange position for a product, agreement or exchange
partner. It is possible to view the balance to-date for each agreement and
to view the movement details that have affected that balance.
q Pricing is enhanced to handle exchange fees and to allow fees to be
maintained or revalued at all stages in the sales or purchasing process
flows.
q Capability to have invoicing at specified intervals and to net those A/R
and A/P invoices for:
m Exchange fees
m Product value
m Excise taxes and VAT
q Management of global quantities and prices on an annual contract while
allowing monitoring of exchange position and volumes on a periodic
(e.g. monthly) basis.
q Exchanges and swaps for like and unlike products and location.
q Integration into the Transportation and Distribution functionality as of
release 1.0D.
q Checks and controls over product lifting entitlements.
q Capability to produce an exchange statement detailing the exchange
activity for a period.
q Capability to assign a base product to individual items (subproducts) in
an exchange to allow the exchange to be monitored at the base product
level.

([FKDQJHV(;*DVSDUWRI,62LO'RZQVWUHDP
.H\)XQFWLRQ%HQHILWV
The integration of Exchanges functionality within the Core SAP System
allows the oil company to manage exchange balances on a timely and
accurate basis by ensuring data integrity, through one time data entry,
between Exchanges and Inventory Management, Financial Accounting,
Order and Delivery Tracking and Invoicing.
The specific benefits of the Exchanges functionality are:
,PSURYHG,QYHQWRU\ Online tracking of Logical Inventory Balances for pure exchanges - by
0DQDJHPHQW automatically updating the logical inventory balance whenever a movement
is posted against an exchange and providing online transactional display,
the system allows the user to view and manage exchange positions from a
quantity viewpoint.
%HWWHU3URILWDELOLW\ Online automation and integration of exchange accounting provides the
0DQDJHPHQW foundation for allowing the oil company to monitor and manage the
profitability of its exchange business on a timely basis.
$FFXUDWH&UHGLW([SRVXrH Lifting controls at the sales and purchase outline agreement level within an
$QDO\VLV exchange contract allow the credit exposure to a particular exchange partner
to be accurately managed. These controls are in addition to the financial
credit limit checks which could also be enforced.
,PSURYHG0DUNHW By providing flexibility in terms of the range of types of fees and differentials
5HVSRQVLYHQHVV through the use of price condition techniques and by providing current
exchange balances, the system allows the oil company to be responsive to
market forces in terms of the deals it can negotiate and manage with exchange
partners.
5HGXFHG)LQDQFLDO Valuation and revaluation of logical inventory enables the system to
$GPLQLVWUDWLRQ(IIRUW automatically manage the financial accounting aspects of “pure” exchanges.
The system is therefore able to account for “Logical Inventory Adjustments”,
logical inventory clearances and to capture the financial implication, loss or
gain, associated with these transactions.

.H\,62LO)XQFWLRQV6XSSRUWHGE\WKH
5,62LO'RZQVWUHDP(;*&RPSRQHQW
An exchange agreement is represented within IS-Oil Downstream by the
assignment of SAP R/3 sales and purchase outline agreements under an
exchange header. This is illustrated in the figure below.
)LJ([FKDQJH
Note that:
q Oil company 1 is a SAP IS-Oil user with an exchange partner; oil
company 2
q It has entitlement to lift product at the oil company 2 location Y
The following Exchange functionality is provided by the Exchanges category
within R/3 IS-Oil Downstream System:
&UHDWLRQ0DLQWHQDQFHRI([FKDQJH$JUHHPHQWV
Within the oil industry an exchange is an agreement between oil companies to
allow lifting of product at one time and location in exchange for entitlement to
lift product at another time and location.

)LJ'HILQLWLRQRIDQ([FKDQJH$JUHHPHQW
R/3 IS-Oil Downstream supports the linking of entitlements to lift product
from an exchange partner (purchase agreement) and entitlements of the
exchange partner to lift product from the oil company (sales agreements)
under an exchange agreement.
It is possible to define lifting and receipt entitlements at multiple locations
within the same exchange agreement. It is also possible to define multiple
agreements at the same physical location. For this reason, R/3 IS-Oil
Downstream offers the possibility to explicitly state, or to select via a pop up
window, which purchase agreement should be used to supply product to an
external customer.
+DQGOLQJDQG'HILQLWLRQRI)HHVDQG'LIIHUHQWLDOV
)LJ$VVLJQPHQWRI)HHVDQG'LIIHUHQWLDOVWR([FKDQJH$JUHHPHQWV
Definition of fee types and rates - Within Exchanges, many different types
of fees are encountered. The R/3 IS-Oil Downstream component incorporates
price condition techniques into the definition of fee types. This allows the
user, or system configurer, to define the combination of circumstances (e.g.
method of delivery, location, exchange type etc.) upon which the fee rate
will depend for a particular fee type.

The system also allows the user to define the fee rate for each combination of
circumstances encountered and provides the option to propose new values
for fees, based on up-to-date condition record values. The effective date
range for each fee is user definable.
Assignment of fees to exchange agreements - The fees are assigned to the
individual entitlements to lift product, i.e. within the line items of the
individual sales and purchase agreements assigned to the exchange contract.
This level of granularity allows maximum flexibility in terms of fee assignment
within an exchange contract.
/LIWLQJ&RQWUROVDQG&KHFNV
Controls by contract - Within a particular exchange agreement, it is common
to schedule the volumetric entitlement to lift product, especially on the
exchange partner side, into periodic quantities.
For this reason, a Quantity Schedule is created at the level of the line items
within the sales and purchase agreements. This enables the user to schedule
the entitlement quantity into freely definable periods (usually monthly) over
the length of the agreement.
This control is invoked when attempting to create call-offs (nominations)
against the purchase or sales agreement.
4XDQWLWDWLYH7UDFNLQJRI([FKDQJH%DODQFH
R/3 IS-Oil Downstream tracks exchange balances by product, exchange
receipts minus exchange deliveries, at the individual exchange agreement
level. The exchange balance is updated real-time and is available on-line.
This functionality is integrated with the standard SAP R/3 System material
movement transactions and is therefore seamless to the user.
)LJ4XDQWLWDWLYH7UDFNLQJDWWKH([FKDQJH$JUHHPHQW/HYHO

)LQDQFLDO0DQDJHPHQWRI([FKDQJH$JUHHPHQW
Accounting for Fees - The user can specify by exchange type whether fees
should be invoiced, or netted, independently of how the material price should
be treated. In the oil industry, it is common to invoice for fees and not to
invoice for material cost, i.e. a “pure” exchange where fees are invoiced.
When invoice matching for purchase agreements, the system allows the user
to match fees both at the summary level and at the individual fee line item
level and automatically posts any matching differences back to the
appropriate account as gains or losses.
Accounting for Materials - As with fee accounting, the user can specify by
exchange type whether the material cost should be invoiced, netted, or
neither (a pure exchange). In the case of non-invoiced exchanges, the
exchange balance is treated as “logical” inventory.
Accounting for Taxes - It is common practice in the oil industry to invoice
and be invoiced for excise taxes receivable and payable due to movements
against exchange agreements even in the case of pure exchanges where the
material cost is not invoiced. R/3 IS-Oil Downstream therefore allows the
user to define for pure exchanges whether the excise duty payable or
receivable will be invoiced.
/RDG%DODQFLQJ
As of release 1.0D the R/3 IS-Oil Downstream component allows the user to
assign a purchase contract or call-off for the supply of product against a
customer order. The purchase contract or call-off can be explicitly assigned
when the delivery note is scheduled (as described above).
)LJ$VVLJQPHQWRI3XUFKDVH&RQWUDFWWR&XVWRPHU'HOLYHU\

If the contract is not explicitly assigned, then the system displays a list of
available contracts when the delivery note is loaded (issued to the customer).
This transaction automatically ensures that the quantity called-off and
received against the selected purchase contract is equal to the quantity
issued against the customer delivery.
)LJ)XQFWLRQRIWKH/RDG%DODQFLQJ
([FKDQJH$JUHHPHQW1HWWLQJ
It is common for oil companies not to invoice an exchange partner after each
individual movement against a particular exchange. Such exchange types
may be netted, i.e settled periodically. R/3 IS-Oil Downstream allows the
user to define for an exchange type whether or not the exchange should be
netted.
Periodically the payables and receivables can then be netted and only the net
balance posted to the exchange partner account. This can then be invoiced or
paid as required.
)LJ1HWWLQJ3URFHVV

9DOXDWLRQRI/RJLFDO,QYHQWRU\
When exchange balances are built up against “pure” exchanges, it is usual to
value the assets and liabilities associated with the goods movements as if
they were actual inventory for financial accounting purposes. The reasoning
behind this is that the payable or receivable in the case of pure exchanges is
a quantity of product and not a financial amount.
Under R/3 IS-Oil Downstream the system records and tracks the value of
logical inventory at the prevailing inventory carrying price when the material
movement was created. The system ensures that the integrity between the
quantity balance owed or owing, i.e. the quantity of logical inventory, and the
financial value of the logical inventory is always maintained.
If no own inventory is carried at a location, the receivable and payable
volumes can be valued at the current value at a “reference plant”, which is
normally a nearby plant at which you hold inventory.
The system supports both standard priced and moving average priced
inventory valuation strategies.
5HYDOXDWLRQRI/RJLFDO,QYHQWRU\
Oil companies often value physical inventory using a standard cost that
represents the calculated production cost. However, this production cost is
recalculated on some periodic basis. It is therefore a requirement that the oil
company can change the inventory carrying price of their physical
inventory.
If logical inventory is to be valued as if it were physical inventory, then the
carrying cost of the logical inventory may also need to be changed. IS-Oil
functionality allows the user to change the inventory carrying value of the
logical inventory and automatically records the loss/or gain from revaluation
to P&L.
/RJLFDO,QYHQWRU\$GMXVWPHQWV
Oil companies manage their logical inventory balances by periodically
posting exchanges of a quantity of product owed for a quantity of product
owing. A negotiated payment or receivable may or may not be included in
the transaction. It is also possible to balance an exchange in which different
products have been exchanged against different volumes, e.g. 100,000
barrels of regular unleaded for 80,000 barrels of premium unleaded.
The system supports this type of transaction both at the exchange agreement
level and across exchange agreements for an exchange partner. The system
automatically updates the logical inventory balance and captures the
resulting loss/or gain on the transaction.

)LJ)XQFWLRQVRIWKH/,$7UDQVDFWLRQ
6XE3URGXFW%DVH3URGXFW)XQFWLRQV
A base product can be assigned to each delivered product (sub product)
within an exchange agreement. In this case the exchange balance is updated
for the base product, and the base product price is used for the logical
inventory posting as well.
5HSRUWLQJDJDLQVW([FKDQJHV
The following reporting capabilities are included within the exchanges
functionality under R/3 IS-Oil Downstream:
Exchange Statement - The exchange statement is a document that can be
generated and sent to the oil company’s exchange partner. It summarizes the
exchange activity for a period, listing movements, financial transactions and
exchange adjustments. It is a tool to aid in the reconciliation of an exchange
with the partner.
Exchange Balance - The user is able to report total liftings, receipts and
balances against exchange agreements and to summarize this data by
material, exchange type, exchange partner, exchange number and location.
This functionality is mainly used across pure exchange types where it
enables the user to track the logical inventory balance real-time and on-line.
Exchange Movements - The system allows the user to display all physical
movements of product against exchange agreements for a particular
material. The list of movements displayed may be selected by several
parameters including location, exchange type, exchange partner and method
of delivery.
Exchange Entitlement - Entitlement to lift product is defined as the open
quantity against an exchange nomination, i.e. the open purchase call-off

quantity for purchase agreements assigned to exchange contracts. The

system allows the user to narrow the search of exchange entitlements for a
particular product by location, exchange partner, method of delivery and
exchange type.
Matchcodes - Several matchcodes have been provided that can be used to
select based on exchange related criteria, for instance:
q Purchasing/Sales contracts
q Purchasing/Sales call-offs
q Netting documents
q Delivery and goods movements
.H\,62LO)XQFWLRQV6HUYHGE\WKH&RUH56\VWHP
This section summarizes the relevant functionality supported by the Core
R/3 System.
q Creation of Exchange Partners
An exchange partner is represented by the linking of a customer and
vendor account.
q Creation of Contract Outline Agreements
The creation of sales and purchase outline agreements is a capability of the
standard system. This functionality is enhanced to allow the inclusion of
fees, differentials and lifting controls.
In addition to the basic outline agreement and order handling functionality,
the Core R/3 System has the following capabilities within the exchanges
area:
q Incorporation of Price Condition Techniques within Purchasing
The inclusion of price condition techniques within both purchasing and
sales allows R/3 IS-Oil Downstream to use these techniques to define
fees, and differentials, within exchange agreements. This base capability
is enhanced to allow the user to specify the fee types to use within the
line items of the purchase or sales outline agreement.
Repricing functionality has been enhanced, particularly on the purchasing
side, to allow fee values to be recalculated at each stage in the delivery/
receipt process.

'HWDLOHG'HVFULSWLRQRI%XVLQHVV)XQFWLRQV6XSSRUWHG
E\WKH5,62LO'RZQVWUHDP(;*&RPSRQHQW
2YHUYLHZRI([FKDQJH+DQGOLQJ
This section describes the overall conceptual framework for the proposed 2YHUYLHZRI([FKDQJH
R/3 IS-Oil Downstream component for handling exchange agreements. The +DQGOLQJ
section builds on the simple exchange business scenario introduced in the
previous section and intends to set the functionality identified in this section
in the wider context of the system functions as used in exchange handling.
The section then describes the specific exchange functionality introduced in
the previous section in greater detail.
Exchange agreements are represented and handled by the assignment of
sales and purchase outline agreements, allowing management of exchange
deliveries and exchange receipts respectively to an exchange header.
00 ([FKDQJHDJUHHPHQW 6'
6XE%DVH
)HHV 3XUFKDVHFRQWUDFW 6DOHVFRQWUDFW )HHV
4W\VFKHG 4W\VFKHG
4W\VFKHG 3XUFKDVHFDOORII 6DOHVFDOORII
/RDG%DODQFLQJ 5HSRUWLQJ 4W\VFKHG
([FKDQJHEDODQFH
'HOLYHU\
*RRGVUHFHLSW
*RRGVLVVXH
/RJLFDOLQYHQWRU\
(56
/,$ %LOOGXHOLVW
5HSULFLQJ ,QYRLFHYHULILFDWLRQ %LOOLQJ
6SOLWLQYRLFLQJ
6SOLWLQYRLFHYHULILF
3D\PHQW 1HWWLQJ &ROOHFWLRQ

), SURFHVVLQJ SURFHVVLQJ ),
([FKDQJHVWDWHPHQW
)LJ%XVLQHVV3URFHVV([FKDQJHV
The system functions (see figure 1-9) that form a typical exchanges business
cycle are:
q Create Exchange Agreement Header
In system terms, an exchange agreement header is a document linking
one or more purchase contracts with one or more sales contracts. The
process of exchange header creation is detailed in the section “Create
Exchange Agreement Header”.

q Create Contracts (Outline Agreements)

Create Sales Contacts - Agreements to supply specified amount(s) of
product(s) within a specified delivery schedule. When an exchange
related sales contract is created, the following can also be specified:
m Fees and differentials that apply to exchange deliveries (see also
“Handling and Definition of Fees and Differentials”).
m Lifting controls that apply to the exchange deliveries at the contract
level
(see also “Lifting Controls and Checks”).
Create Purchase Contracts - Agreements to receive specified amount(s)
of product(s) within a specified schedule.
m Define fees and differentials that apply to exchange receipts (see
section
“Handling and Definition of Fees and Differentials”)
m Define lifting controls that apply to the exchange receipts (see section
“Lifting Controls and Checks”).
q Create Call-offs
Create Sales Call-off - This is the process of creating an actual sales
order against the sales outline agreement (sales contract). The fees and
differentials applying to the call-off are copied from the contract.
In order to schedule the deliveries into periodic quantities, it is possible
at this stage to create further lifting controls for the deliveries against
this call-off.
Create Purchase Call-off - This is the process of creating an actual purchase
order against the purchase outline agreement (purchase contract). The fees
and differentials applying to the call-off are defaulted from the contract.
In order to schedule the deliveries into periodic quantities, it is possible
at this stage to create further lifting controls for the deliveries against
this call-off.
q Sales Flow
Create delivery notes. The delivery note indicates to the system:
m Order item/product to be delivered
m Date to be delivered
m Location from which the delivery is made, i.e. the SAP delivering
plant/
store location
m Quantity to be delivered - at this point quantities are checked to see
that
they do not violate contract or scheduled quantities.

Post confirmed delivered quantity/create goods issue.

m Change the delivery note quantity to the confirmed delivered
quantity.
m Create goods issue for the delivery note. This generates the required
inventory accounting entries automatically.
Accounting for exchanges is detailed in the section “Financial
Management of Exchange Agreement”.
Create invoice (for invoiced partners). This process posts the invoice to
the customer account and generates an entry in a file ready for printing.
When using a billing due list, additional exchange-specific selection
criteria are available to specify the range of documents relevant for
invoicing.
q Purchase Flow
Receive Goods - The following two scenarios are relevant to exchanges
in this area:
1. Post Goods Receipt - In the simple case where oil company 1 takes
ownership of the goods at the exchange partner location.
2. Perform load balancing - Where the purchase call-off is used to fill a
sales delivery (to one of oil company 1’s customers) from the
exchange partner location (as of Release 1.0D).
Post Invoice Receipt (for invoicing partners) - This process posts the
payable to the partners’ vendor accounts ready for standard system
payments processing. At this time, the accrual generated at the time of
posting a goods receipt is cleared.
For automatic creation of invoice verification documents, the Evaluated
Receipt Settlement (ERS) process has been enhanced to handle exchange-
related transactions. ERS with Exchanges includes:
m Handling fees and repricing those fees
m Selecting goods receipt documents by exchange number or a range
of exchange numbers
m Collecting invoice items by exchange number
m Split invoice verification
q Netting
Where an exchange is flagged for netting, all the sales and purchasing
invoices will be flagged as blocked for payment.
The netting process allows those payables and receivables to be reviewed,
selected or deselected and then cleared. The difference between the sum of
values of the payables and the sum of the values of the receivables is
posted as a single entry to either payables or receivables as appropriate.
In movements-based netting, the system uses goods movements which
reference the exchange agreement as the selection method for collecting
receivables and payables.

&UHDWH([FKDQJH$JUHHPHQW+HDGHU
&UHDWH([FKDQJH$JUHHPHQW The exchange agreement header provides a framework to link one or more
+HDGHU sales contracts with one or more purchase contracts (see figure above). When
creating the exchange header the user must specify the type of exchange
agreement that is being created. The system holds default parameters for the
exchange type but these may be overridden by the user when the exchange
header is created. The parameters identified at this stage are:
q The posting rules for the material - This is explained in the section
“Financial Management of Exchange Agreement”
q The posting rules for the fees - see section “Financial Management of
Exchange Agreement”
q The posting rules for the taxes
q Whether or not netting is performed and the Netting cycle - see section
“Netting”
q The breakdown proposal for the quantity schedule
q Sub product to base product edit rules
q VAT on internally posted movements indicator
q Partner reference
q General purpose text
q Base location (for example specifying a point on a pipeline from which
exchange differentials are calculated)
The posting rules for fees and materials determine how to accrue for
payables on goods receipt and how to account for receivables on goods
issue. The reason for this flexibility is that it is anticipated that an installation
would use different accounting entries depending on whether the exchange
movement is expected to be invoiced or merely carried forward as in a pure
exchange. The separate posting rules for fees and materials allow them to be
treated differently for accounting purposes where for example fees are
expected to be invoiced and materials carried forward.
In order to allow exchange header creation, a new transaction has been
created. During creation of the exchange, the above entries are specified. The
exchange agreement number may be numbered by the system (internally
numbered), or numbered by the user (externally numbered).
It is possible to assign sales and purchase contracts to an exchange header in
two ways:
q Branch directly to the create sales and purchase contract transactions
from the create/maintain exchange header transaction.
q Assign existing contracts to the exchange header from the maintain sales
and purchase contracts transactions.
In either case, the system cross references the sales and purchase agreements
to the exchange header by copying the exchange number and type into the

sales and purchase agreements and prompts the user to specify any
additional data required by an exchange.
Moreover, it is possible to create an exchange agreement with reference to an
already existing one. Sales and purchase contracts assigned to the referenced
exchange agreement can also be selected for copying.
)LJ5HVXOWRI&UHDWLQJDQ([FKDQJH$JUHHPHQW
+DQGOLQJDQG'HILQLWLRQRI)HHVDQG'LIIHUHQWLDOV
IS-Oil supports the payment or collection of fees and differentials in addition +DQGOLQJDQG'HILQLWLRQRI
to the value or quantity of product identified in the exchange. )HHVDQG'LIIHUHQWLDOV
Definition of Fee Categories
A fee category is defined by the creation of a price condition record type.
This enables the parameters upon which the fee rate depends to be defined
when configuring the system.
The existing Core System capabilities surrounding pricing condition records
are retained. These are not detailed here but may be summarized as:
q Condition tables - Key structures for access of the fee condition records
may be defined during configuration.
For example, it is possible to configure by specifying a price condition
structure with these parameters in the key, a fee type that depends upon:
m Delivering location
m Exchange type
m Method of delivery

q Access sequences - If required, the oil company may define that a fee
category has more than one key structure. In this case, it is necessary to
define which should be used in preference.
For example, an individual fee may be defined within a key structure of:
Location/Method of delivery/Exchange type
However, if the rate for this key is not found, then the company may
wish to define that a generic rate for location/method of delivery should
be used.
Definition of Fee Rates
Within a fee type, the user is able to create condition records that specify the
fee rate for the determining parameters and data range. This is illustrated by
the figure below:
)LJ$VVLJQPHQWRI)HH5DWH
Accounting for Fees
Accounting for fees is explained in greater detail in the section “Financial
Management of Exchange Agreements”.
Sales Side
On the sales side it is necessary to specify the fee revenue account to be used
when invoicing or netting for the fees following exchange pickups by our
exchange partner.
It is possible to specify the fee revenue account to be used at the fee type
level.
Purchasing side
On the purchasing side, it is necessary to define whether a particular fee
type is expensed or included in inventory on goods receipt. This is explained
in more detail in the accounting section.
It is possible to specify the accounting policy whether to expense or include
the fee amount in inventory and the account to be used, if the fee is to be
expensed, at the fee type level.

Assigning Fees and Differentials to Exchange Agreements

The fees and differentials to be used are specified within the line items of the
sales and purchase contracts that are assigned to a particular exchange
agreement. This is illustrated by the figure below. When creating or assigning
a sales or purchase outline agreement under an exchange agreement, the user
is taken into a fee definition screen. The fees and differentials to be invoked
when posting movements against the outline agreement must be specified.
The system displays the currently applicable rates. Depending on configuration
options the rates will be copied into subsequent documents with or without
repricing. Again, depending on configuration options, the user may have the
option to override these rates manually.
IS-Oil supports the payment or collection of fees and differentials in addition
to the value or quantity of product identified in the exchange. A series of
indicators, called invoicing cycles, makes it possible to allocate different
payment terms to the various pricing conditions (taxes, fees, etc.).
)LJ$VVLJQPHQWRI)HHVDQG'LIIHUHQWLDOVWR([FKDQJH$JUHHPHQWV
/LIWLQJ&RQWUROVDQG&KHFNV
Lifting Controls by Contract
The standard purchase and sales contract creation and amendment transactions /LIWLQJ&RQWUROVE\&RQWUDFW
were enhanced to allow the user to enter a “Quantity Schedule” whenever a
contract is assigned to an exchange. The result of a typical sales contract creation
transaction is shown in the figure above.
The Quantity Schedule allows the user to schedule the sales or purchase
outline agreement into periodic (usually monthly) parts. The breakdown is
proposed from the exchange type but this default may be overridden by the
user. In addition, the user may modify the scheduling periods manually as
required. System calculated breakdown indicators are:
q Daily
q Weekly
q Monthly
If any of these parameters are chosen, then the system pro-rates the contract
item quantity across the proposed periods. The system allows the user to

amend the scheduled quantities for each period for the validity of the
contract. The system performs various checks when a quantity schedule is
created:
q Check that the total scheduled quantity is not greater than the contract
quantity
q If the scheduled quantity is less than the contract quantity, then the user
is warned
q The scheduling periods must fall within the validity period of the
contract
The scheduled quantity in any period is the maximum permissible call-off
quantity for the contract in the period. If the user attempts to call-off more
than the permitted quantity in any scheduling period, then the system issues
a warning message. However, the call-off may still be created.
In addition to the quantity schedule checks, it is possible to specify whether
it is permitted to over call-off against the contract item total quantity.
Update of the Contract Quantity Schedule
The contract quantity schedules are updated whenever a call-off is created.
The call-off quantity schedule is updated automatically when a delivery note
or a goods receipt is posted.
Lifting Controls in the Call-off
In similar fashion to that created in the contract, it is also possible to create a
quantity schedule to schedule a call-off quantity into periodic quantities. The
creation and validation are the same as for the creation of a quantity
schedule within the contract. However, the call-off quantity schedule is
validated to ensure that it falls wholly within a contract scheduling period,
i.e. it is not possible to create a call-off schedule that crosses more than one
contract scheduling control period.
Clearly then, the delivery schedule for the call-off has to use a smaller period
than the corresponding contract schedule. It is possible in the contract
schedule to specify a proposed breakdown indicator for the call-off(s) (i.e.
daily, weekly, monthly). If this has been specified, then the system
automatically proposes a call-off schedule broken down into periods of this
length and falling within the validity period of the relevant contract line.
This can be overridden by the user if required.
Update of the Call-off
The sales call-off quantity schedule is updated when a delivery note is
created against the call-off. If the delivery note quantity is subsequently
changed, the system does not update the call off quantity schedule.
The purchase call-off quantity schedule is updated when the goods receipt is
created.
In addition, for purchase call-offs, the intended (from delivery note) field is
updated when the call-off is assigned to the supply of a delivery note (see
“Load Balancing/Rescheduling”). The quantity is transferred to the received
field when a goods receipt is created against the purchase call-offs.

Schedule Checking
The entitlement checking and schedule updating process relevant to delivery
note creation is shown in the figure below. Clearly schedule checking only
applies to call-offs where a quantity schedule is created.
The system locates the call-off scheduling period corresponding to the
requested delivery date and verifies that the requested delivery quantity is
less than or equal to the available quantity for the period. If the requested
quantity is greater than that available for the period then:
The system will react in the way the user customized the quantity schedule
message. There can be either no reaction, a warning or an error. The
possibility to customize the System’s reaction applies to all respective
messages of the quantity schedule for sales and purchase.
Please see the update of the QS in the following figure. That is as well when
the System checks the quantity of the QS.
)LJ/LIWLQJ&RQWUROVLQD6DOHV&DOORII
4XDQWLWDWLYH7UDFNLQJRI([FKDQJH%DODQFH
The system keeps track of the exchange balance within a specific database 4XDQWLWDWLYH7UDFNLQJRI
(S036) that is updated whenever one of the following system events occurs: ([FKDQJH%DODQFH
q Goods receipt against an exchange agreement - for the actual received
quantity
q Goods issue against an exchange agreement - for the confirmed
delivered quantity
q Posting of a Logical Inventory Adjustment transaction
The system therefore only updates the exchange balance when the physical
movement of goods has occurred and the confirmed movement quantity is
known, or when the logical inventory balance is updated within the Logical
Inventory Adjustment transaction.

The key to this database segment, which defines the lowest level at which
the exchange balance is tracked, is:
Client/Period/Material Group/Material/Plant/Exchange Partner/Exchange
Type/Exchange Agreement Number/Base Product
This allows the user to view the exchange balance at any higher level by
summarizing the information held at this level (see “Reporting against
Exchanges”).
The update of S036 following goods issue is illustrated by the figure below.
)LJ8SGDWHRI4XDQWLWDWLYH%DODQFH)ROORZLQJ*RRGV,VVXH
)LQDQFLDO0DQDJHPHQWRI([FKDQJH$JUHHPHQW
)LQDQFLDO0DQDJHPHQWRI For each exchange agreement created in R/3 IS-OIL Downstream, financial
([FKDQJH$JUHHPHQW accounting is governed by the posting rules defined for the fees, materials
and taxes. These rules determine how to accrue for payables on goods
receipt and how to account for receivables on goods issue.
There are four key factors that can affect the type of postings that are made
for an exchange:
1. Material posting rules - Internal/External
2. Fee posting rules - Internal/External
3. Fee accounting policy
4. Excise duty posting rules
The default account processing with respect to the above is determined for
each exchange type, but may be overridden by the user at the time of
exchange header creation.

q The posting rules for the fees and material indicate whether to use the
standard accounts for posting the receipts and deliveries of product (and
therefore invoicing the exchange partner and being invoiced), or whether
to use internal payables/internal receivables accounts. In this case it is a
Borrow/Loan exchange agreement, so invoices are not created.
q The separate posting rules for fees and materials allow them to be treated
differently for accounting purposes. For example, in the oil industry it is
common for fees to be invoiced (posted externally) and materials carried
forward (posted internally) as in the case of a pure exchange.
q If material is posted internally the excise duty posting rules can be either
specified as posted externally (Invoice for Excise Duty is created) or
internally (no invoice is created for Excise Duty).
q The accounting policy for fees defined against purchase agreements
within an exchange allows the user to define whether the fee should be
expensed or included in inventory at the time of posting the goods receipt.
In the figure below a business scenario is shown for the following posting rules:
q Material internal
q Fees external
q Excise Duty external
)LJ3XUH([FKDQJH3RVWLQJV

Accounting for Material

The user can specify in an exchange agreement whether material cost should
be invoiced, or posted internally (not invoiced). In the case of non invoiced
materials the exchange balance (quantity which is moved between the
exchange partners) is treated as logical inventory and posted on internal
accounts receivables and internal accounts payables.
Sales Agreement (Goods Issue)
The goods issue automatically creates financial accounting entries to record
the diminution of stock.
1. The product is expected to be invoiced - Standard accounting entries are
posted.
2. The product is expected not to be invoiced - the internal receivables
accounts is used as offset to the inventory account.
3. The product is expected to be netted.
Create Financial Accounting Entries
The financial postings that occur in the goods issue stage for each of the
above scenarios is indicated below. The key points to note are:
q The postings to the internal receivables account are not cleared by
invoice issue or netting. The balance on the internal receivables account
may be cleared down by, for example, a Logical Inventory Adjustment
posting.
q Where invoicing is expected to occur, the goods issue merely transfers
the stock value from the inventory account (balance sheet) to the
consumption account (P&L). No posting is made at this stage to
recognize the exchange partner liability. This posting is made by the
invoice processing function.
Financial Postings
q Product to be invoiced
m Credit - Stock (inventory account)
m Debit - Cost of Goods Sold
q Product not to be invoiced
m Credit - Stock (inventory account)
m Debit - Internal Receivables account
Purchasing Agreement (Goods receipt)
The accounting entries on goods receipt:
1. To reflect the increase in inventory
2. To accrue for the liability to the supplier


The receipt of goods automatically triggers the required general ledger
postings, however it is important to note the following:
q The inventory account for a particular material is automatically inferred
from the material master details.
q Material to be invoiced (externally posted)
m Debit - Inventory account
m Credit - GR/NI (Goods received/not invoiced) material clearing
account (to be cleared by invoice receipt processing)
q Material not to be invoiced (internally posted)
m Credit - Material Internal Payables account
Accounting for Fees
Within an exchange agreement, the user specifies whether fees should be
invoiced or posted internally. These fee posting rules are independent of
accounting for materials.
The user can specify by fee type whether fees should be expensed or
included in inventory for the purchase side and which revenue account is
applicable in the sales side.
Sales Agreement (Goods Issue)
The purpose of posting the goods issue is to record the actual quantity of
product delivered to the customer. This process automatically triggers the
required general ledger postings to reflect the issue of stock.
Create Financial Accounting entries
The key points to note about posting fees during a goods issue are:
q There are no fee postings on goods issue unless the fees are internally
posted, i.e. are not invoiced. If the fees are internally posted, then the
system generates a fee posting to the fee internal receivables account and
an offset to the appropriate fee revenue accounts.
q The postings to the fee internal receivables account are not cleared by
invoice issuing or netting.
q The fee revenue account may be specified for each fee type.
Financial postings
Under R/3 IS-Oil Downstream, there are three scenarios to reflect the
posting of fees during a goods issue:
q Fees to be invoiced (externally posted)
m Nothing done at time of goods issue, fee revenue account is posted
by invoice processing
q Fees not to be invoiced (internally posted)
m Credit - Fee Revenue accounts
m Debit - Fee Internal Receivable account

Purchasing Agreement (Goods receipt)

The purpose of posting the goods receipt is to record the actual value of
product received from the supplier. This process automatically triggers the
required general ledger postings to reflect the receipt of stock.
The fee accounting policy is determined for each type and determines
whether the fee is to be expensed or included in stock at time of posting the
goods receipt. Note that the system therefore allows, within the same
purchase order line item, that some fees should be expensed and some
included in the inventory carrying cost.
Create Financial Accounting entries
Under R/3 IS-Oil Downstream, these are the postings of fees during a goods
receipt:
q Fee to be invoiced (externally posted)
m Debit - Stock or Fee expense account (depends on whether fee is to
be expensed or included in stock at time of posting the goods
receipt)
m Credit - Fee clearing account (fees to be cleared by invoice receipt
processing)
q Fee not to be invoiced (internally posted)
m Debit - Stock or fee expense (depends on whether fee is to be
expensed or included in stock at time of posting the goods receipt).
m Credit - Fee Internal Payables account.
Invoice Verification
During invoice verification the system allows the user to edit fees both at the
summary level and at the individual fee line item level and automatically
posts any matching differences back to the appropriate account as gains or
losses.
When an invoice is received (detailing fees) and the fees don’t match the
posted fees receivable (fees clearing account) then the user is able to specify
the clearing amount against each fee in the line item.
Accounting for Taxes (In a Pure Exchange)
It is common practice in the oil industry, in the case of pure exchanges
where the material cost will not be invoiced for the excise duty taxes due to
movements against exchange agreements to be invoiced since they have to
be given to the government. R/3 IS-Oil Downstream allows the user to
define, for pure exchanges, whether excise duty is invoiced or (like the
material costs) posted internally. See the chapter on TDP for more detail on
excise duty handling.


The receipt and issue of goods automatically triggers the required general
ledger postings to account for the above scenarios as follows:
q Internally posted duty on goods receipt (on pure exchange where
material is also posted internally)
m Debit - Excise Duty Inventory
m Credit - Material Internal Payables (material amount + excise duty
amount)
q Externally posted duty on goods receipt
m Debit - Excise Duty
m Credit - GR/NI (excise duty value)
m Credit - Material Internal Payables account (material amount)
q Internally posted duty on goods issue
m Credit - Inventory
m Credit - Excise Duty Inventory
m Debit - Material Internal Receivables (material amount + excise duty
amount)
q Externally posted duty on goods issue
m Credit - Stock
m Credit - Excise Duty Inventory
m Debit - Excise Duty Cost of Goods Sold (excise duty amount)
m Debit - Material Internal Receivables (material amount)
Invoice/Invoice verification for excise duty
Where excise duty is externally posted the following accounting entries are
made:
Invoice issue:
q Credit - Excise Duty Revenue
q Debit - Exchange partner account
Invoice receipt:
q Debit - GR/NI
q Credit - Exchange partner account

/RDG%DODQFLQJ
/RDG%DODQFLQJ The purpose of load balancing is to cope with the business scenario where it
is desired to use an existing purchase contract/call-off to fulfill a customer
order. The business scenario is illustrated below:
)LJ([FKDQJH/RDGLQJ%XVLQHVV6FHQDULRDQG6\VWHP5HSUHVHQWDWLRQ
Two variations of the illustrated scenario are envisaged:
q IS-Oil Transportation and Distribution functionality is used. Typically
this is where the delivery is carried by a truck that is under our control
e.g. one of our own or an independent carrier employed by us. Exchange
loading integrates the exchange functionality into the delivery creation,
the shipment scheduling and the load confirmation processes, so that
what is loaded onto the vehicle is the quantity receipted under the
exchange.
q Without IS-Oil Transportation and Distribution functionality (i.e. using
standard Core Delivery processing). Typically this is where the delivery is
carried out by a vehicle that is not under our control, for example the
customer picks up the product. Exchange loading integrates the exchange
functionality into the delivery creation and the goods issue processes, so
that what is issued to the customer is the quantity receipted under the
exchange.
The details of transportation processing are discussed more fully in the
chapter on Transportation and Distribution.

Assignment of Exchange Contract

The exchange can be assigned to the customer delivery note in two places:
q When creating or changing the delivery note an assignment of one or
more exchange contracts/call-offs can be made to the delivery item. This
assignment causes the quantity schedule of the contract/call-off to be
updated with the intended delivery quantity. This ensures that the
required quantity of product is reserved against the total available for
call-off against the purchase contract/call-off.
q When scheduling a delivery to a shipment (TD only) an assignment can
be made or modified. This updates the quantity schedule in the same
manner as per creating or changing the delivery note directly.
There are two methods of assigning the exchange:
q A user exit will allow user written code to automatically choose the
exchange depending on criteria from the delivery note item. If the IS-Oil
user has specific strategies for determining which exchange is relevant in
certain circumstances (for example Exchange call-off 12345 is only to be
used for product issued from plant ABCD during June 1997) than this
can be programmed.
q The exchange contract/call-off can be explicitly specified via a popup
window. If no user exit exists or no applicable strategy can be determined
then the exchange can be manually specified or changed.
The system will check that there is sufficient availability against the exchange
quantity schedule which ever method is used.
Loading or Goods Issue
At load confirmation (TD relevant) or goods issue (non-TD) the quantity that
is loaded onto the vehicle or issued out to the customer is confirmed.
However before this happens that quantity needs to be received from the
exchange partner. To do this the system performs the following functions:
q Checks the exchange assignment. If the date of the delivery has changed
or the quantity has increased the exchange assignment may no longer be
valid.
q Amends the delivery note quantity to the entered loading/goods issue
quantity.
q If a purchasing contract has been assigned then a call-off is created.
q Updates the quantity schedule of both the purchase call-off and the
contract as appropriate.
q Posts the goods receipt against the purchase call-off.
q Posts the loaded quantity into in-transit (TD relevant) or against the
delivery note for invoicing (non-TD).

6SOLW,QYRLFLQJ
6SOLW,QYRLFLQJ6' IS-Oil functionality allows multiple invoices to be generated from a single
delivery for different pricing components. For example fees can be invoiced
separately from taxes, and importantly the fee invoices can have different
payment terms than the tax invoices.
This functionality is not restricted to exchanges but is available for all sales
transactions.
An invoicing cycle can be assigned to pricing conditions and a billing type
can be assigned to process one or more invoicing cycles. So for example all
exchange fee condition types can be assigned invoice cycle 1 and all tax
condition types assigned to invoice cycle 2.
At the customer material level or on the sales documents the payment term
can be set for each invoicing cycle. In addition user exits allow user written
code to set the payment term if specific criteria exist, such as the rules for US
taxes, and also allow the netting cycle indicator to be set, so for example fee
invoices could be netted but tax invoices billed.
The flow of processing for split invoicing is:
q (Customisation of condition types and billing types to set invoicing
cycles.)
q Order taking: Payment terms for each invoicing cycle may default in
from Customer Material Info records or may be manually set. Invoicing
cycle on price conditions may be manually overridden.
q Delivery processing (no change).
q First invoicing run: Only the pricing conditions with the invoicing
cycle(s) matching those on the billing type used for the invoicing are
processed. The other pricing conditions are calculated but set to
“statistical”.
q Profitability (COPA) updated with full invoice item quantity but only
value for first cycles.
q Delivery status and document flow refelct the cycles processed.
q For subsequent invoicing runs, the processing is the same except
profitability is only updated for value (and not quantity).
q When all invoicing cycles have been run the delivery status is then set to
“complete”.
6SOLW,QYRLFH9HULILFDWLRQ00 Split invoice verification is also supported on the MM-side as of Release
1.0D. With split invoice verification, you can calculate the freight costs and
excise duties separate from the material value and the fees for a goods
receipt, and you can provide different terms of payment each time.

1HWWLQJ
Netting functionality allows payables and receivables for an exchange 1HWWLQJ
partner to be summed up and subtracted from each other. So instead of
invoicing the exchange partner for each outward movement and receiving
an invoice from them for each inward movement and then processing all
those payments, only one either payable or receivable open posting need to
be processed.
The user specifies when creating an exchange agreement whether sales and
purchases with the exchange partner are to be netted or invoiced. The
netting functionality consists of four areas of functionality:
q Financial Netting Process - Periodic clearing of the payables/receivables
(netting) to generate a single open item for the balance
q Specification of netting criteria
q Blocking the invoices for automatic payment
q Selecting the payable/receivable items for netting
Specification of Netting Criteria
The payment blocking indicator is used to block invoices for payment and
enhanced by IS-Oil to indicate that these invoices are to be netted. Different
values can be used as blocking indicators to specifiy different netting
criteria. This is flexible and can be specified by exchange partner. For
example blocking indicator “A” may be used to specifiy that all B/L
exchange type transactions dated between the 16 th of the previous month
and the 15 th of the current month are netted together for exchange partner
ABCD.
Blocking the Invoices for Automatic Payments
The netting indicator (or payment blocking indicator) is set in the exchange
header and defaults into the sales and in the exchange header and defaults
into the sales and purchasing documents. Depending on customising, it may
be changed or removed in these documents, if required. Within the split
invoicing functionality there is a user exit that also allows the indicator to be
set depending on criteria relevant to the invoicing cycle. For example, this
allows fees to be netted but taxes to be invoiced/paid.
Selecting the Payable/Receivable Items for Netting
Before the payable and receivable items are netted it is possible to review the
documents and deselect anything that is not to be netted in this run. This
allows items that are in dispute (i.e. not agreed with your exchange partner)
to be netted later or manually processed.
Netting of Payables and Receivables
The result of the financial netting process is shown in the figure below. The
purpose of this functionality is to periodically, e.g. monthly, net off the
payables and receivables for an exchange partner and post a single document
to represent the difference.

The key aspects of the financial netting functionality are:

q The netting process reads the netting relevant payables and receivables
for the exchange partner.
q This balancing document can be processed as a normal payable or
receivable, i.e. by payment/collection processing, or left on the account
to be carried forward and netted off against future transactions.
)LJ1HWWLQJ3URFHVV
0RYHPHQWV%DVHG1HWWLQJ
0RYHPHQWV%DVHG1HWWLQJ As of Release 1.0D, the collection of receivables and payables in an exchange
for netting can be carried out based on the actual exchange-related goods
movements which took place.
Instead of financial documents being selected, the financial values that are to
be offset against each other are derived from goods movements which have
been selected by the exchange partners to be included in netting.

*, *5 /,$ ,QYRLFH 1HJ

1HJ
%LOOLQJ 5HFHLSW 3D\PHQW
ERRN
0RYHPHQWV )LQDQFLDO
'DWDEDVH 'DWDEDVH
1HWWLQJVHOHFWLRQ
1HWWLQJ3URSRVDO
6XPPDU\ 'HWDLO 'HOLYHULHV
5HSRUW 5HSRUW
5HFHLSWV
1HWWLQJ
3XUH)LQDQFLDOV
1HWWLQJ3ULQW %7&,
%RRN5HFHLSWV
5HTXHVW %RRN'HOLYHULHV
)LJ0RYHPHQWVEDVHG1HWWLQJ
9DOXDWLRQRI/RJLFDO,QYHQWRU\
Logical inventory balances are updated whenever one of the following system 9DOXDWLRQRI/RJLFDO,QYHQWRU\
events occurs:
q Goods receipt against a pure exchange agreement - for the actual
received quantity
q Goods issue against a pure exchange agreement - for the confirmed
delivered quantity
q Posting of a Logical Inventory Adjustment transaction
The financial value of the logical inventory balance is held in a new database
(OIA7) which is keyed by Company Code/Plant/Material and contains the
quantity, value and moving average price of the logical inventory.
q Material internal receivables - For physical goods issues, the quantity of
logical inventory owed to us by our exchange partner is valued at the
prevailing physical inventory carrying price, regardless of any pricing
details in the exchange sales contract.
q Material internal payables - For physical goods receipts, again the
quantity of logical inventory owed by us to our exchange partner is
valued at the prevailing physical inventory carrying price or at the price of
the material at a specified reference plant (a reference plant is commonly
used when no inventory is normally held at the receiving plant).
This valuation strategy recognizes that logical inventory represents a quantity
of product, and not a financial amount, owed or owing and therefore should
be valued as if it were physical inventory.

Moving Average Price

The system tracks the moving average price of the logical inventory balances
at the company, plant, product level. This strategy is illustrated by the figure
below and ensures that the integrity between the system held logical
inventory quantity balance and the logical inventory financial balance is
always maintained, i.e. if all of the quantity balance were cleared, then the
system held financial value would be zero. The strategy ensures that IS-Oil
can handle both standard priced and moving average priced physical
inventory valuation strategies.
)LJ0RYLQJDYHUDJHSULFHRIORJLFDOLQYHQWRU\
Revaluation of Logical Inventory

5HYDOXDWLRQRI/RJLFDO IS-Oil functionality incorporates an enhanced price change transaction that
,QYHQWRU\ can be invoked as required to post a new inventory carrying price for logical
inventory within a particular plant.
The effect of posting a revaluation of logical inventory is illustrated by figure
20. In the above example, the logical inventory carrying price is changed to
1.00 USD/lt. The difference between the logical inventory value at the old
carrying price and that at the new carrying price is calculated by the system
and posted to a P&L account.
In this case the difference is:
(Old price x quantity) - (New price x quantity) = 3,062 - 2,800 = 262
This is recorded as a loss on revaluation.
Sub/Base Product Handling
IS-Oil functionality offers the flexibility of creating an exchange agreement
containing multiple products referencing a single base product. This is used
for example with exchanges of gasolines with different octane levels but for
ease of monitoring, reconciliation and valuation all transactions are based
upon a mid grade gasoline.

When sub/base product functionality is used the logical inventory is

updated in terms of the base product. For example if an exchange contract
contains the following products:
- UN87H0 87 octane gasoline
all referencing UN90H0 as a base, an issue or receipt for either UN87H0 or
UN93H0 will update the logical inventory for UN90H0.
The value posted to logical inventory will be based upon the inventory carrying
price for UN90H0 and the difference between that and the material’s normal
inventory carrying price is posted as a loss/gain. All reporting is centered upon
the base product with the sub product generally only being reported as
additional information.
/RJLFDO,QYHQWRU\$GMXVWPHQWV
The Logical Inventory Adjustment transaction allows the oil company to /RJLFDO,QYHQWRU\$GMXVWPHQWV
adjust the logical inventory they have recorded against an exchange partner.
Typically this is to record the swap of the ownership of a specified quantity of
one product for the ownership of a specified quantity of another product or to
correct a movement that was incorrectly posted against an exchange, or to
transfer the balance from an expired exchange agreement to a new exchange
agreement. The adjustment may or may not include a monetary payment. No
physical product movement is involved in the settlement only a logical
inventory movement.
The product(s) to be balanced result from unequal or incorrect call-offs on
sales and purchase contracts, assigned to pure exchanges only, at one or
more locations. This means the internal payables and receivables logical
inventory accounts are used for the exchange contracts to control valuation
of product logical inventory.
The three components of a Logical Inventory Adjustment are:
q A specified quantity of an over-received product(s) to be swapped in
q A specified quantity of an over-delivered product(s) to be swapped out
q A monetary payment (issue or receipt)
Usually, at least two of the three components would be defined for a Logical
Inventory Adjustment, although the system allows any combination of the
above.
The logical inventory effect of posting a Logical Inventory Adjustment is
illustrated by the figure below.

)LJ(IIHFWRQ/RJLFDO,QYHQWRU\%DODQFHRI3RVWLQJD/RJLFDO,QYHQWRU\
$GMXVWPHQW
Specifications to be Made in the Logical Inventory
Adjustment Transaction
The user specifies the exchange partner with whom the Logical Inventory
Adjustment is being made on entry to the Logical Inventory Adjustment
transaction. For each over-received product to be swapped out and each
over-delivered product to be swapped in, the user must specify:
q The location at which the posting should be made
q The exchange type against which the Logical Inventory Adjustment
should be posted
q The product to be swapped
q The quantity to be swapped
In addition, the user has the option of specifying the exchange agreement
number against which the Logical Inventory Adjustment clearance should
be posted. If this is not specified, then the Logical Inventory Adjustment
clearance is posted at the summary level for the exchange partner.

Quantity Posting Made By the Logical Inventory Adjustment Transaction

When entry is complete the exchange product quantity balances are updated.
This is illustrated by the figure below. The entry for an over-delivered product
has the effect of reducing the delivered quantity rather than increasing the
received quantity. Conversely the entry for an over-received product has the
effect of reducing the received quantity rather than increasing the delivered
quantity.
If the user attempts to swap in more product than has been received or swap
out more than has been delivered, the system issues a warning. The user may
choose to ignore this warning and post the Logical Inventory Adjustment in
any case.
Financial Postings Made By the Logical Inventory Adjustment Transaction
The financial postings made by the Logical Inventory Adjustment transaction
are illustrated by the figure below. The logical stock valuation is updated on
each product’s valuation record (see section “Valuation of Logical Inventory”).
For over-delivered products the internal receivable account is credited. For
over-received products the internal payable account is debited. The offset is
to a P&L account called “Exchange Balance” representing the gain/loss on
the Logical Inventory Adjustment.
The negotiated payment details, if entered, causes an invoice posting either
to payables or receivables, in order to request a payment by ourselves or the
exchange partner. For an invoiced payment request to the exchange partner
the customer account is debited. For an invoiced payment request from the
exchange partner the vendor account is credited. In either case the offset
account is again the P&L “Exchange Balance” account.
If the negotiated payment is a receivable an invoice document can be generated
that contains details of the adjustments made and the value that is owed by the
exchange partner. This document can then be sent to the exchange partner.
)LJ4XDQWLW\3RVWLQJV*HQHUDWHGE\WKH/,$7UDQVDFWLRQV

)LJ)LQFDQFLDO3RVWLQJV*HQHUDWHGE\WKH/,$7UDQVDFWLRQV
([FKDQJH6WDWHPHQW
([FKDQJH6WDWHPHQW The exchange statement is a document or series of documents used to report
the activities of an exchange over a certain period. Typically the exchange
statement is sent to the exchange partner and forms the basis for the periodic
reconciliation of the exchange. It will contain information such as:
q the details of the movements (issues and receipts): material, plant,
quantity, data, document no., etc.
q the financial information relevant to the exchange partner for these
movements: fees, differentials, etc.
q adjustments: LIAs
q opening and closing balances
q net amount owed or owing for the period
It is highly customisable so that the amount of information sent to the
exchange partner can be controlled and formatted as required. For the same
data different formats and levels of information can be output. So it is
possible to send a summarised version of the exchange statement to the
exchange partner but generated a detailed version for internal use.
5HSRUWLQJ$JDLQVW([FKDQJHV
Display Exchange Balance
5HSRUWLQJ$JDLQVW([FKDQJHV The system strategy for quantitative tracking of exchange balances is
explained in the section “Quantitative Tracking of Exchange Balance”. The

exchange balance display transaction enables the user to display the S036
segments held at the exchange agreement level and therefore to summarize
up to higher levels of detail.
The key to this database segment, which defines the lowest level at which
the exchange balance is tracked, is:
Client/Period/Material Group/Material/Plant/Exchange Partner/ Exchange
Type/ Exchange Agreement Number/Base Product
This allows the user to view the exchange balance at any higher level by
summarizing the information held at this level.
The Logistics Information System (LIS) is used for reporting purposes. This
is a flexible, customisable reporting system that allows the exchange balance
details (i.e. lifts, receipts and balances) to be reported and summarised by
any combination of the key fields.
Display Exchange Movements
The display exchange movements transaction allows the user to display all
exchange related movements. In SAP terms, the deal related movements are:
q Goods Issue
q Goods Receipt
q Logical Inventory Adjustment
The user is able to narrow the range of selected movements by specification
of one or more of the following selection criteria:
q Material Number (or matchcode)
q Plant
q Exchange type
q Movement type
q Range of posting dates
q Exchange Partner
Display Exchange Entitlement
The exchange entitlement transaction supports the IS-Oil user in finding
open entitlements. An entitlement to lift product from an exchange partner
is represented by the open quantity against a purchase call-off. For each call-
off, the open entitlement is defined by:
Exchange entitlement = Scheduled quantity - Intended quantity - Received
Quantity
where,
Scheduled Quantity = Maximum quantity available in any scheduling
control period
(see section “Lifting Controls and Checks”)
Intended Quantity = The quantity reserved due to assignment of the call-off
to a customer order
(see section “Load Balancing”)

Received Quantity = The quantity already received against the call-off
)LJ([FKDQJH(QWLWOHPHQW
The user can narrow the range of the call-offs selected by entering one or
more of the following selection criteria:
q Product
q Plant
q Exchange Partner
q Exchange type
q Method of delivery
The system displays the open entitlement on all exchange related purchase
call-offs that meet the entered selection criteria. It is also possible to drill
down on a particular call-off to display the underlying scheduling quantity
schedules (see section “Lifting Controls and Checks”).
)LJ'LVSOD\([FKDQJH(QWLWOHPHQW7UDQVDFWLRQ

*ORVVDU\RI([FKDQJH6SHFLILF7HUPV
3XUH([FKDQJH
A pure exchange is one where the liability incurred due to a receipt of
product from an exchange partner, or the asset acquired due to the delivery
of product to an exchange partner, is a quantity of product owed or owing
and not a financial amount. The assumption is that over time the quantities
owed and owing balance although periodic or ad hoc settlements against
this type of exchange are possible. The implication is that “pure” exchanges
are managed with respect to the quantity of product owed or owing due to
physical or logical movements against the exchange agreement.
1RQ3XUH([FKDQJH
A non pure exchange is one where the financial amount owed or owing due
to an exchange receipt or delivery is to be paid or netted. For this reason, the
quantity balance against this type of exchange is not be cleared down over
time. The implication is that non “pure” exchanges are managed with
respect to the financial value owed or owing due to physical movements
against the exchange agreement. This type of exchange may be netted or
invoiced.
1HWWHG([FKDQJH
A netted exchange is a non pure exchange within which an oil company
periodically invoices only the net balance owed or owing due to the movements
against the exchange as opposed to invoicing for each individual movement.
%RUURZ/RDQ([FKDQJH
In a borrow/loan exchange, materials are only posted internally, they are
not invoiced to the partner. A logical inventory is set up. Excise duty and
fees incurring with the material movements will generally be invoiced. A
borrow/loan exchange is also known as a “pure” exchange.
)HH&DWHJRU\
This is a broad grouping of similar types of fees. The fee category corresponds
to an SAP price condition record type and therefore allows the user to define
the key parameters on which the fee rate should depend, e.g. individual fees
depends upon method of delivery, exchange type, and delivery location.

)HH7\SH
This identifies the type of fee within a fee category, e.g. types of individual
fees are wharfage, truck filling and demurrage.
/RJLFDO,QYHQWRU\
This is represented as exchange balances owed or owing against pure
exchanges. The inventory is valued, and revalued, as if it were physical
inventory but is tracked against a separate balance sheet account for
balances owed (due to exchange deliveries) and balances owing (due to
exchange receipts).

&KDSWHU
+\GURFDUERQ3URGXFW0DQDJHPHQW+30
DVSDUWRI,62LO'RZQVWUHDP
+LJK/HYHO6XPPDU\
The SAP R/3 Logistics modules, Materials Management (MM) and Sales and
Distribution (SD), provide a comprehensive information system for the
effective and efficient management of all standard activities within the
supply chain. The objective of the Inventory and Hydrocarbon Product
Management (HPM) functionality within the R/3 IS-Oil Downstream
component is to enable these Core modules to address certain specific oil
industry requirements.
With regard to general hydrocarbon inventory management, IS-Oil amends
existing Core SAP functionality in order to:
q Incorporate ASTM/API petroleum measurement standards. These
standards are used to convert volume quantities and product densities
at ambient temperatures to volume quantities and densities at well
defined standard temperatures for material movements and measure-
ments.
q Provide additional quantity fields enabling stock balances to be stored in
multiple units of measure (for example volume at ambient temperature,
corrected volume based on standard temperature and apparent mass).
q Allow stock balances to become negative as the result of a movement,
and handling the financial impact of such a movement.
q Provide a tracking function to link material movements from one plant
to another in order to calculate and post gains and losses (two-step
transfer).
.H\)XQFWLRQ%HQHILWV
The key function benefits are outlined below:
HPM’s functionality can be viewed as a tool for creating business benefits in (IIHFWLYH3URGXFW
other design categories within IS-Oil. Principally, it allows oil companies to 0DQDJHPHQW
effectively manage their supply chain of continuous and discrete product to
minimize costs and maximize the reliability and quality of service provided
to the customers.

+\GURFDUERQ3URGXFW0DQDJHPHQW+30DVSDUWRI,62LO'RZQVWUHDP
$XWRPDWLF4XDQWLW\ The ASTM/API calculation function enables highly accurate automatic

&RQYHUVLRQDQG0DWHULDO conversions between alternative units of measure, based on internationally
7UDFNLQJ accepted petroleum measurement standards (ISO 91-1), which are
performed within the SAP R/3 System. Thus, the company gains savings in
terms of time and effort by not having to perform these calculations outside
the system.
As there is no limit to the number of units of measure that can be calculated
for a material, the system provides complete flexibility for tracking and
reporting material quantities.
,QWHJUDWLRQRI The ability to calculate material quantities using the ASTM/API conversions
6\VWHP0RGXOHV in HPM provides a high level of integration with the other modules. This
enables the company to view the product in the particular unit of measure
(UoM) desired.
)LJ6\VWHP0RGXOH,QWHJUDWLRQ
7LPHOLQHVVRI'DWD The ability to convert units of measure and to post movements of material
simultaneously provides the company with accurate quantity levels of
material in real time.
6KLSPHQW3URFHVV)DFLOLWDWLRQ The weight ( i.e. apparent mass) and volume of a product required for
shipment is calculated and saved to aid in the delivery and shipping process.
3ODQWWRSODQW7UDQVIHUVDQG Issues and receipts for plant-to-plant transfers are linked by R/3 IS-Oil
+DQGOLQJRI*DLQV/RVVHV Downstream functionality.
The enhancement to the intra-company movement (plant-to-plant transfer)
functionality enables an issue quantity from one plant and a receipt quantity
at a second plant to be reconciled, and the resulting gain/loss associated
with the movement to be automatically calculated and posted.

,62LO'RZQVWUHDP+30&RPSRQHQW
The following HPM enhancements are provided within the R/3 IS-Oil
Downstream component:
9ROXPH&RUUHFWLRQV$FFRUGLQJWR$PHULFDQ6RFLHW\IRU7HVWLQJ
DQG0DWHULDOV$PHULFDQ3HWUROHXP,QVWLWXWH6WDQGDUGV$670$3,
IS-Oil incorporates an interface to ASTM/API c-code routines to convert
volume quantities and product densities at ambient temperatures to volume
quantities and densities at standard temperatures for material movements
and inventory measurements. The system supports the standard ASTM
Tables 53 and 54, including the German rounding rules, ASTM Tables 23
and 24 for relative densities and ASTM Tables 5 and 6 for API gravity
calculations. The calculation is performed on goods movements relating to
“oil materials”, with the ability to calculate specific units of measure. The
user can configure whether the calculations are performed in display mode,
or in the background, and whether the values calculated can be overwritten
by manual entry or not. The system also provides an ASTM/API desk top
calculator to perform quantity conversions when no goods movement has
occurred.
,QYHQWRU\$GGLWLRQDO8R0
Storing of multiple units of measure is made available through additional
appendix tables to the material master for each material, thereby providing
additional information for ABAP reporting capability.
3ODQWWRSODQW7UDQVIHUVDQG+DQGOLQJRI*DLQV/RVVHV
Issues and receipts for plant-to-plant transfers are linked by R/3 IS-Oil
Downstream functionality. The enhancement to the intra-company movement
(plant-to-plant transfer) functionality enables an issue quantity from one plant
and a receipt quantity at a second plant to be reconciled and the resulting
gain/loss associated with the movement to be automatically calculated and
posted.
Material movements can occur between plants belonging to the same company,
or between storage locations within a single plant. These movements can be
monitored in the R/3 IS-Oil Downstream system.

A transaction exists in R/3 IS-Oil Downstream in which the issue from the
first plant is linked by a transfer tracking number to the receipt of the
second. Thus, the tracking number allows for the calculation of gains and
losses associated with a company movement, as well as tracking the status
of the material movement. The corresponding excise duty gain/loss is also
calculated.
1HJDWLYH,QYHQWRU\
Negative inventory allows for stock balances to become negative as a result
of a goods movement. This allows an issue of a material to be made even
though there is insufficient stock available in the system to complete the
issue.
For example, if a hydrocarbon movement occurs over several days, certain
transactions will be booked several days after the initial part of the movement.
This could result in a shortage of inventory, from a system perspective, if a
goods issue is made.
The following features in the Core R/3 System are particulary applicable to
the oil and gas industry.
%OHQGLQJDQG5HEUDQGLQJ
The ability to change the material code of a product when two different
products are mixed together, creating a new product, or to change the
description of one product to another.
3K\VLFDO,QYHQWRU\
Post to physical inventory balancing is simplified in R/3 by the detail stored
in the inventory. All movements and physical counts are retained by the
system, which provides for numerous ABAP reports to be developed for
inventory reconciliation. R/3 also provides the flexibility of a company
defined grouping of products that enable the company to create custom
ABAP reports.

6SHFLDO6WRFNV
Consignment and subcontract stocks are easily accounted for and tracked in
the standard R/3 System, regardless of their actual physical location (for
example, stocks at customer or vendor sites). Functionality available for
special stocks is similar to that of normal inventory stocks, which includes
physical counts, stock reservations, and pricing.
)LJ)XQFWLRQDOLW\IRU6SHFLDO6WRFNV
/,)2),)2,QYHQWRU\9DOXDWLRQ0HWKRGVIRU$FFRXQWLQJDQG5HSRUWLQJ
LIFO/FIFO valuation is provided by R/3 IS-Oil as part of the Core System.

E\WKH,62LO'RZQVWUHDP+30&RPSRQHQW
/RFDWLRQ+LHUDUFK\
/RFDWLRQ+LHUDUFK\ Within the SAP R/3 System, much of the master data information is
structured within a common hierarchy. This hierarchy consists of four levels:
client, company, plant and storage location. All information in the hierarchy
applies equally to all lower levels. Thus, the hierarchical structure ensures
that data redundancy is kept to a minimum.
)LJ/RFDWLRQ+LHUDUFK\
The common hierarchy is applied to several different master file structures,
one of which is the location structure.
Clients and Companies

For any given organization, there may be a variety of ways that the location
structure could be represented within the SAP R/3 System. This is done by
mirroring current or desired organizational structures of the business. The
decision is driven primarily by how corporate information is gathered,
aggregated and reported.

An oil company (the SAP client) may have divided its organization into
business functions. Thus, the SAP companies would be the independent
business units of the oil company, as illustrated in the figure below.
)LJ2UJDQL]DWLRQ'LYLGHGLQWR%XVLQHVV)XQFWLRQV
Alternatively, separate SAP companies could be used to represent each
national subsidiary of a multi-national organization (the SAP client).
Plant
A plant is a strategic business unit. The plant is the highest level in the
hierarchy where inventory balances are stored, so the assignment of plants
will determine how an organization’s inventory position can be reflected.
The plant field is a four digit alphanumeric field. For an oil company, typical
uses of the plant entity in SAP might be to define:
q Crude storage terminals
q Finished product marketing terminals
q Refineries and manufacturing complexes
q Pipelines, or pipeline segments
In addition to these “physical” sites, where an organization’s inventory is
maintained and reported, it is possible to define so called “logical” plants.
An oil company might use logical plants:
q To store and report inventory in a summarized manner
q To represent third party inventory sites, for example exchange partner
locations
q To store in-transit inventory, possibly by mode of transport

)LJ3K\VLFDODQG/RJLFDO3ODQWV
Storage Location
A storage location is a subdivision within a plant, enabling inventory to be
managed at a more detailed level. Each plant must contain at least one
storage location. The storage location field is a four digit alphanumeric field.
Storage locations enable the management of inventory in smaller units.
Within a “physical” plant, an oil company might use storage locations:
q To track and report volumes of individual product, for example establish
individual or groups of tanks at a terminal (plant) as storage locations.
Within a “logical” plant, an oil company might use storage locations:
q To define individual third party sites (within a summary third party
plant)
q To define stock being transported by different modes of transport
(within an in-transit plant)
The assignment of a company’s physical and logical inventory sites as plants
or storage locations is completely flexible within the SAP R/3 System. An oil
company would assign entities as plants or storage locations dependent on
factors such as:
q The number of inventory sites to be defined in the SAP R/3 System
q The level of inventory tracking and reporting required at the inventory
site

)LJ3ODQWVDQG6WRUDJH/RFDWLRQV
3URGXFW+LHUDUFK\
This is another area to which the common hierarchy is applied in the 3URGXFW+LHUDUFK\
material master record.
Client
The Client level is the highest level at which material information can be
maintained. Information maintained at this level includes:
q Material number and description
q Stockkeeping unit of measure
q Material type
q Industry sector
q Quantity calculation method
The stockkeeping unit of measure is the base unit of measure, or the unit in
which the stock is managed. The standard system converts all quantities
entered in other units to this unit. In R/3 IS-Oil Downstream, for “oil
materials”, these conversions can be performed using ASTM/API conversion
routines (see the section “Quantity Conversions Incorporating ASTM/API
Procedures”). All implicit financial transactions (material valuations, accounts
payable updates, etc.) associated with a goods movement are performed
based on the quantity in the stockkeeping UoM.
The material type provides one method for grouping materials together in
the SAP R/3 System. Examples of material types are raw materials, trading
goods and finished products. The material type defines certain features of

the material and has important control functions. For example, the material
type determines which department-specific data the user can enter for the
material.
Company
In the oil industry, a requirement exists to hold material information at the
company level, since some information, for example, that pertaining to tax
and excise duty, is country-specific. R/3 IS-Oil Downstream provides the
following information at that level:
q Additional units of measure for maintaining inventory quantities in
master files and reports
q Conversion group
The units of measure that are calculated automatically for a material (in
addition to the stockkeeping unit) when a material movement occurs, are
defined at this level.
It is possible to group individual units of measure, by a key, simplifying the
assignment of the units of measure to a country code. The units of measure
that are reported in the standard stock reports (see the section entitled
“Inventory Information and Reporting”) are also defined at this level.
The R/3 IS-Oil Downstream System provides a number of methods for
converting between the different units of measure defined for a material (see
the section “Quantity Conversions Incorporating ASTM/API Procedures”).
The conversion group defines which set of formulas will be used in the
conversion calculations.
Plant
The plant level is the highest level in the SAP hierarchy where stock balances
are stored in the SAP R/3 System. Material information held at this level
includes:
q Stock balances, in stockkeeping unit of measure, for different types of
material quantity
q Stock balances in additional unit of measure for total stock and valuated
stock with unrestricted use
At plant level, stock balances in the stockkeeping unit of measure are held for
a number of different types of stock. These include total stock, unrestricted
use stock, stock in transfer, consignment stock and reserved stock.
In addition to these quantities held in the stockkeeping unit of measure, the
total stock and valuated stock with unrestricted use are held in the
additional UoM and are available for reporting.
The batch managed indicator is maintained at plant level. If this indicator is
set, then a material is managed in batches.

Storage Location
Information maintained for a material at this level in the R/3 IS-Oil
Downstream system includes:
q Stock balances in stockkeeping UoM for different types of material
quantity
q Stock balances in additional UoM for total stock and valuated stock with
unrestricted use.
Batches
Storage location stock can be subdivided into batches in order to facilitate
the management and valuation of inventory at a more detailed level.
Special Stocks
SAP R/3 provides functionality to manage stock owned by third parties, or
stocks stored at third party locations. Special stocks are typically stored in
the system as “logical” plants and storage locations, as described in the
section entitled “Location Hierarchy”. Some examples of special stocks
include:
q Vendor Consignment Stock - Stock owned by a vendor, but stored at
your site
q Subcontract Stock - Stock owned by your company, but stored at a site
belonging to a supplier
q Customer Consignment Stock - Stock owned by your company, but
stored at a site belonging to a customer
q Supplier’s and Customer’s packaging to be returned
q Project Stock - Stocks allocated to projects defined in the SAP R/3
project system
One example of the way special stocks could be used by an oil company is as
follows: customer consignment stock could be used to keep track of
inventory quantities at certain dealer-operated retail stations. After delivery
of the product, it is still owned by the delivering company until it is finally
sold. Inventory at retail stations can be tracked in the system using customer
consignment stock.

4XDQWLW\&RQYHUVLRQV,QFRUSRUDWLQJ$670$3,3URFHGXUHV
4XDQWLW\&RQYHUVLRQV In the oil industry, it is a requirement to be able to hold material quantities
,QFRUSRUDWLQJ$670$3, in multiple units of measure (UoM). The volume quantities and densities of
3URFHGXUHV oil materials are temperature-dependent; Raising the temperature of a liquid
or gaseous material increases the material’s volume and thus decreases its
density. In order to compare one volume quantity of material to another
volume quantity of the same material, the comparison must be made at a
common temperature.
)LJ4XDQWLW\&RQYHUVLRQV
Thus, it is usual (and a legal requirement for excise duty calculations) to

maintain inventory balances in a UoM at a fixed temperature (for example
liters at 15° Celsius, L15). However, most goods movements occur at ambient
temperature, with the temperature at which the movement occurred being
measured along with the density of material moved. The quantity correction
functionality provided by R/3 IS-Oil Downstream system enables conversion
between volumes measured at different temperatures into UoM at a standard
temperature, for inventory management and reporting. It is also possible to
calculate the weight of a material. All UoMs relevant to a material can be
defined and calculated automatically when a movement of the material takes
place.
Functions Utilizing Different Units of Measure

A particular UoM may be required in order to calculate the excise duty. The
TDP functionality uses the conversion routines to calculate and report
inventory balances in the required UoM.
A company’s marketing department might require various UoMs, due to
pricing procedures for different customers in international markets.
The pricing functionality in MAP can use any of the UoMs as the basis for
pricing.

Since all UoMs defined for a material are calculated for every movement
type, the Exchanges functionality is able to track exchange balances in
multiple UoMs.
Quantity Calculation Method

The following description of the quantity conversion routines applies to “oil
materials”. These are defined by assigning a conversion group to the
material master record of the material. If this group is set to indicate an oil
material, then the quantity conversion routines will be performed for the
material.
Quantity Determination
There are two possibilities for entering quantities in the R/3 IS-Oil
Downstream system:
The first is to enter the movement quantity along with the density and
temperature of the material when the movement occurred. Automatic
internal conversion routines then convert this quantity into all the UoM
maintained for that material.
The alternative is to enter all quantities required, with associated
temperature and density information, directly in the system. This procedure
is used if the quantities are calculated outside of the SAP R/3 System. The
system checks all mandatory fields for a manual entry of that kind.
Quantity Conversion
The automatic conversion of one UoM to another UoM can be performed in
one of two ways:
The R/3 IS-Oil Downstream system contains ASTM/API conversion
routines. This functionality performs conversions based on the rules and
formulas defined by the American Petroleum Institute (API), based on the
descriptions created by the American Society for Testing and Materials
(ASTM). The system supports the standard ASTM Tables 53 and 54,
including the German rounding rules, the ASTM Tables 23 and 24 for
relative densities and ASTM Tables 5 and 6 for gravities. The conversion
calculations use formulas based on these standard tables.
The alternative is to perform the calculations by an external customer
function module.
An external interface to the SAP R/3 System allows conversions that are not
supported by the ASTM/API routines, as described above.
The two methods are illustrated in the following diagram.

)LJ&RQYHUVLRQRIRQH8R0WR$QRWKHU
Units of Measure Available

The standard UoM for a material is the stockkeeping unit defined at client
level in the material master record. This is the base UoM for storing and
reporting inventory balances. R/3 IS-Oil Downstream enables an unrestricted
additional number of UoMs to be defined for each material. The system
automatically converts transaction quantities to these UoM for each goods
movement of the material. Quantity balances are maintained for the material
in all of these additional UoMs, as described below.
The total stock and available stock balances are held in the additional UoM
at the following levels:
q Plant
q Storage location
q Batch level
q Special stock
The transaction quantity in the following transaction types are converted to
the additional UoM:
q Material movements: goods receipts, goods issues, . . .
q Deliveries
q Physical inventory documents

Material-Specific Information Used in the Quantity Conversion Calculations

The quantity conversion routines require the material density and temperature
to perform their calculations. This information may be obtained from the
conversion routines in one of the following ways:
q The values for density and standard temperature can be stored at, and
defaulted from, plant, storage location and batch-level. This information
can be updated at those hierarchical levels, based on the date.
q For each individual goods movement, it is possible to manually enter the
temperature and material density associated with the transaction.
Carrying out the Quantity Conversion Calculations

For some transactions, it is a requirement to be able to enter temperature and
density measurements made at the time of the goods movement. The R/3 IS-
Oil Downstream system provides this capability. Dependent on transaction
type, it is possible to configure the R/3 IS-Oil Downstream system to perform
the quantity conversion calculations by one of four different methods:
)LJ0HWKRGVWRSHUIRUPWKHTXDQWLW\FRQYHUVLRQFDOFXODWLRQV
Automatic Conversion Calculation
The system uses default values for density and temperature. The quantity
conversions are performed in background calculations, based on the
transaction quantity and associated UoM.
Semi-Automatic Conversion Calculation

The system uses default values for density and temperature. The quantity
conversions are performed in background calculations, based on the
transaction quantity and associated UoM. The results of the calculations are
displayed to the user and can be changed manually before being posted.

Manual Conversion Calculation

The system uses default values for density and temperature. The system
displays these values to the user, and may be changed by manual input. It is
also possible to manually input values for the transaction quantity in any of
the alternative UoMs. The system then performs conversion calculations to
the UoM that have not been manually input. The results of the calculations
are redisplayed and can be changed by the user.
Semi-Manual Conversion Calculation

The system uses default values for density and temperature and allows only
these values to be changed. The system performs the volume conversions in
the background, based on the transaction quantity and associated UoM.
Calculation of Gross/Net Weights and Volumes

The R/3 IS-Oil Downstream system performs automatic ASTM/API
calculations of weights and volume in the shipment process.
Base Sediment and Water Calculation

Base Sediment and Water (BS&W) is a percentage of the total quantity that is
non-oil material. This value is to be subtracted from the ASTM-corrected
quantity and is applied to volumes when activated. Activation takes place
by product type specified in a table. The BS&W is an integral part of all
material movements. The meter calibration factor is applied to all target
volumes, when BS&W is activated.
Gain/Loss Handling with Plant-to-Plant Transfers

The two-step plant-to-plant transfer functionality has been enhanced to
enable the reconciliation of individual goods issues and goods receipts
associated with a physical shipment.
Performing Quantity Conversion Calculations When No Goods

Movement Has Occurred
The R/3 IS-Oil Downstream system provides the functions for performing
quantity conversions when no goods movement has occurred. A “desk top
calculator” is provided to perform stand-alone calculations, using either
ASTM/API or customer conversion function modules.
)LJ'HVNWRS&DOFXODWRUIRU6WDQGDORQH&DOFXODWLRQV

Checking the Results of Quantity Conversion Calculations

Functionality is provided to be used for checking the results of system
calculations, performed either using the ASTM/API or the customer
function modules. The result is a report that compares the system calculation
with values in the standard ASTM/API tables.
The following table illustrates the use of the R/3 IS-Oil Downstream
quantity conversion functionality. In this example, a material has a
stockkeeping UoM of barrels at 60 degrees Fahrenheit (B60), while goods
movements of the material are recorded in barrels at ambient temperature
(BBL). The material has an API gravity of 40 and the initial stock of the
product is 500 B60. The table shows the changes in quantity for the following
scenario:
A supplier delivers 950 BBL of the material. The temperature measured at
the time of delivery is 50 degrees Fahrenheit. Subsequently, 500 BBL of the
material is issued to a retail station. The temperature measured at the time of
issue is 70 degrees Fahrenheit.
)LJ,OOXVWUDWLRQRI4XDQWLW\&RQYHUVLRQ)XQFWLRQDOLW\
,QYHQWRU\,QIRUPDWLRQDQG5HSRUWLQJ
Standard Inventory Information Available ,QYHQWRU\,QIRUPDWLRQ
The R/3 IS-Oil Downstream component provides extensive functionality for DQG5HSRUWLQJ
storing and reporting inventory information. The inventory information
stored at the different levels of the common hierarchy were discussed in the
section entitled “Product Hierarchy”. Other inventory management functions
and the reporting capabilities of the system will now be considered.
Physical Inventory
The real-time nature of SAP inventory functionality assumes that transactions
are entered into the SAP R/3 System as they occur.
When a goods movement occurs, the corresponding posting should be made
immediately, to ensure that the system reflects an accurate view of the true
inventory position. Thus, all transactions for a given location must be
entered into the system before a physical inventory count is performed at
that location. The physical inventory count consists of the following steps:

q Select the materials and locations to be included in the count

q Perform the physical inventory count and record the results in the
physical inventory document
q Enter the physical inventory measurements in the system. These can be
entered either manually, from the physical inventory document, or using
an interface to the SAP R/3 System. The quantity conversion routines,
discussed in the section “Quantity Conversions Incorporating ASTM/API
Procedures” are used to calculate measured quantities into the UoM
defined for the material
q Create a „post to physical inventory difference list“
q If possible, correct the physical inventory measurements, for example if
differences can be traced to input errors
q Post the differences. This involves adjusting the book inventory to reflect
the physical inventory measured and the generation of the associated
financial adjustments.
All physical inventory results are stored in a physical inventory document
file. The document file can be displayed online, covering multiple years.
Inventory information is stored in the storage location, batch and special
stock segments of the material master.
Inventory Balancing
Each material movement is posted in the SAP R/3 System as a document,
and stored in a movements history file. Material movements are categorized
by movement type. The movement type defines the nature of the movement,
for example goods issue to production or plant-to-plant transfer.
Inventory balances are updated in real-time, as each transaction is recorded
in the system. This ensures that the risk of reconciliation errors is small. It is
assumed that any errors will ultimately be identified during physical
inventory counting.
The user can reconcile transactions and physical balances using the
movements history file and the physical inventory history file. Customized
ABAP reports could be produced to display information from these files if
required, for example, for estimating production and consumption, storage
losses and gains or trend analysis.
Inventory Reporting
The inventory balances that are held at each level of the location hierarchy
were discussed in the section “Product Hierarchy”. These balances can be
displayed through the location structure using the stock overview
transaction. This transaction provides an inventory on-line report, for a
single material number, at all, or selected, levels of the hierarchy.
The user can “drill-down” in the hierarchy to see all of the product inventory
for the company, plants and storage locations within a plant. Individual
batches at a storage location are also displayed by this transaction.
In R/3 IS-Oil Downstream, this transaction enables the additional, oil-
specific information recorded in the system to be displayed. The transaction

enables inventory balances in additional UoM, as well as the stockkeeping

UoM, to be reported.
The SAP R/3 System provides several capabilities for assigning a material to a
user-defined product grouping, for example material group. This functionality
allows the user to create his or her own product hierarchy. Customized ABAP
reports can then be produced to report material balances within the user-
defined hierarchy.
%OHQGLQJDQG5HEUDQGLQJ
Blending is a common transaction in the oil industry. Product blending %OHQGLQJDQG5HEUDQGLQJ
includes:
q The mixing of two different materials to obtain a new material
)LJ0L[LQJ'LIIHUHQW0DWHULDOV
q The mixing of similar materials

)LJ0L[LQJ6LPLODU0DWHULDOV
Rebranding is available as a function of the Standard SAP R/3 System.
The blending (mixing) of products is supported by a bill of materials with
sub-items for a given delivery of a product. The density for the new material
is recalculated based on the sub-item densities.
The rebranding is provided by a material-to-material transfer posting. In
order to perform a material-to-material transfer posting in R/3, it is
necessary that both materials be managed in the same stockkeeping unit.
ASTM/API quantity conversions are provided for both functions.

&KDSWHU
0DUNHWLQJ$FFRXQWLQJDQG3ULFLQJ0$3
+LJK/HYHO6XPPDU\
The objectives of MAP within IS-Oil Downstream are to enhance the basic
Marketing, Accounting and Pricing (MAP) functionality within the Core
SAP R/3 System. The Core R/3 pricing functionality is flexible enough to
support many business scenarios. However, the MAP enhancements sup-
port functionality specifically required by the downstream oil industry.
q The ability to define the pricing date as any one of a range of dates
within the sales cycle, i.e. it is possible to price sales deliveries based on
order, invoice, goods issue, delivery note posting, loading, delivery note
confirmation or invoice creation dates.
q Ability to set and obtain prices by date in combination with time as well
as day of the week in combination with time.
q The abillity to determine whether a customer’s price is to be based on
local pricing or the customer’s head office pricing rules.
q Ability to base pricing on geographical elements linked to the delivery
location. These elements are part of a location code which is stored in the
customer master.
q Ability to have contract-specific pricing.
q The ability to calculate and store customer specific material lists,
including pre-defined quantities usually ordered and generate a price
list out of this.
q The ability to determine whether a price condition is to apply to gross or
to net volumes.
q Ability to print temperature, density and volume in all the units of
measure which are used for pricing.
q Capability to utilize average value calculations or user-defined formula
& average pricing for products which can be based on external price
quotations (e.g. Platts, Reuters, ...). Possibility to recalculate formula
prices at month-end for invoicing purposes.
q Exclusion techniques enhanced to choose highest price.
q Capability to properly bill or exempt U.S. Federal and State Excise Taxes.

0DUNHWLQJ$FFRXQWLQJDQG3ULFLQJ0$3DVSDUWRI,62LO'RZQVWUHDP
.H\)XQFWLRQ%HQHILWV
Enhancements to the degree of pricing sophistication allow the oil company,
supported by IS-Oil, to tailor its pricing strategy, policy, and tactics to suit its
cost base and its individual customers’ circumstances very precisely. This
feature of the system enables the sales organization to maximize the quantity
and quality of revenue generated. The specific benefits are detailed below:
7LPH)OH[LEOH3ULFLQJ By allowing a variety of pricing dates at invoice creation and the ability to
set prices related to a time as well as a date, the system allows a more
flexible approach to price setting. The nature of the oil products market is
such that the price of products can vary by relatively significant amounts
over the period between order placement and delivery. This flexibility
allows the supplier to guard against making a loss on the trade or the
customer being charged an uncompetitive price (and thus prejudicing
further sales).
+HDG2IILFH%UDQFK/HYHO The head office/branch level pricing functionality improves the flexibility of
3ULFLQJ$JUHHPHQWV the pricing process and allows pricing to be based on head office level rather
than defaulting to specific prices and procedures set for the branch level.
/RFDWLRQ)OH[LEOH3ULFLQJ The inclusion of the location-specific Differential Reference Code (DRC)
allows prices, discounts, surcharges and taxes to be calculated based on an
accurate description of the location of where the goods are delivered.
&XVWRPHU6SHFLILF3ULFH/LVWV The use of customer-specific price lists eases the process of informing
customers of the applicable prices for a list of regularly ordered products.
The provision of this facility speeds up the time taken to answer customer
inquiries, thereby improving customer service and reducing business costs.
)RUPXOD $YHUDJH9DOXH The provision of formula & average value-based pricing allows greater
EDVHG3ULFLQJ flexibility in price setting. When discussing pricing with a customer, the
ability to set prices based on market averages is an added benefit which
assists in the selling process.
&RQWUDFW6SHFLILF3ULFLQJ The contract-specific pricing allows the oil company to identify, target and
tailor the service it provides to specific high priority customers according to
the sales strategy it is pursuing. Negotiating medium to long term contracts
with key target customers can ensure mutually beneficial continuity of
business. By attaching a pricing element to the contract this business
requirement can be fulfilled.

,62LO'RZQVWUHDP0$3&RPSRQHQW
$OWHUQDWLYH3ULFLQJ'DWHV 7LPH3ULFLQJ
The following MAP enhancements are provided within the IS-Oil Downstream
System:
The Core R/3 System currently proposes order pricing with the default
invoice pricing date. If required, this date can be manually overwritten with
a value entered by the user. If the user chooses to change the pricing date,
the system recalculates pricing for the invoice.
In the oil business, the order cycle from posting the order through to order
delivery could take several days during which the price could change
substantially. Hence, functionality is required to allow a variety of dates to
be chosen for calculating the price when the invoice is created. These default
dates include the order date, the goods issue date, the date of loading,
delivery date and invoice date. In addition, the user can set prices during the
sales cycle based on the date and time, or based on the day of the week and
time.
'DWH7LPH
'D\RI:HHN7LPH
)LJ3ULFH)OXFWXDWLRQVIURP2UGHUWR,QYRLFH
+HDG2IILFH%UDQFK/HYHO3ULFLQJ$JUHHPHQWV
Some organizations choose to make pricing arrangements at their head
office and at the branch office level. Therefore, when making a sale to a
customer who has a headoffice, it is necessary to define whether to use the
pricing arrangements negotiated with the head office, or those negotiated
with the branch.

The pricing arrangements can be broken down into two components:

q Pricing procedure
q Customer-specific prices
The head office and the branch customer may be assigned different pricing
procedures and the customer-specific prices may also be different.
IS-Oil delivers the tools for using the head office prices and/or pricing
procedure when selling to the branch.
+HDGRIILFHOHYHO
ÃSULFHV
ÃSURFHGXUHV
%UDQFKOHYHO %UDQFKOHYHO
ÃSULFHV ÃSULFHV
%UDQFKOHYHO
ÃSURFHGXUHV ÃSURFHGXUHV
ÃSULFHV
ÃSURFHGXUHV
&XVWRPHUPDVWHUGDWD
)LJ+HDG2IILFH%UDQFK/HYHO3ULFLQJ$JUHHPHQW
/RFDWLRQ6SHFLILF3ULFLQJXVLQJWKH'LIIHUHQWLDO5HIHUHQFH&RGH'5&
The location-specific pricing functionality (technically implemented using
the Differenctial Reference Code - DRC) allows a more accurate definition of
the location of each sale. This enables pricing to take into account other
geographical factors than those that are standard in the customer master.
This functionality allows pricing conditions to be based upon the DRC code
itself, or upon one of the location grouping attributes of the DRC. For
example, a wide area pricing zone could be used to determine surcharges or
discounts applicable to deliveries in that area. The DRC has six different
attributes. They are:
q Country
q Region/State
q Metropolitan Indicator for specific city or region
q Wide area pricing zone: groups DRCs together, for example for pricing
of discounts

q State license fee zone: groups DRCs together, for example for pricing of
taxes
q Pricing DRC: for referring one DRC to another DRC
2LO&RPSDQ\ &XVWRPHUORFDWLRQ$
3ULFH$
&XVWRPHUORFDWLRQ%
3ULFH%
&XVWRPHUORFDWLRQ&
3ULFH&
)LJ3URGXFW3ULFHV9DU\LQJZLWK&XVWRPHU/RFDWLRQV
&RQWUDFW6SHFLILF3ULFLQJ
Contract specific pricing allows pricing conditions to be set for a customer
and then to be applied to all call-offs from that contract. This ensures that
when pricing is done (at order or invoice creation), the correct contract-
specific price is used.
3UH'HILQHG&XVWRPHU6SHFLILF3ULFH/LVWV
The customer price list allows net prices to be calculated for a pre-defined
list of products. The price list contains the quantity usually ordered by a
customer, along with the unit of measure.
The price list is not part of an order transaction; it is created for customer
information purposes only. The list does, however, use the pricing
functionality in the same way as the order or invoice creation transaction.
The materials and quantities are defined as master data, and cannot be
changed at the time that the customer price list transaction is run.
When the price list transaction is executed, the user has to specify pricing
relevant data like customer, sales area, order type and pricing date and time.
3ULFLQJ%DVHGRQ*URVVRU1HW9ROXPHV
The ability to invoice customers based on either gross or net volume
delivered is required by oil companies in some countries for either
marketing or legal reasons. Gross volume is for example ambient liters and
net volume is for example liters corrected to 15C.

The key factor is generally the country and region where the ownership of
the product changes. However, some customers have a special arrangement
which may override the general rule.
The IS-Oil Downstream enhancement allows the maintenance of a single
condition record in either a gross or net unit of measure. The system then
uses criteria, defined by configuration, to determine whether the gross or net
volume is used during pricing when calculating the condition value.
The print program for invoices has been enhanced to enable you to display
HPM data. This allows the temperature and density information from the
delivery to be displayed on the invoice.
)RUPXOD $YHUDJH9DOXH%DVHG3ULFH&DOFXODWLRQV
IS-Oil Downstream functionality includes pricing based on the (average)
value of externally quoted materials over a defined period of time.
External price quotations from organizations such as Platts, Reuters, etc. can
be interfaced to the SAP system. This is achieved by means of a configurable
routine delivered by IS-Oil. The quotations are then referenced in the
creation of pricing formulas.
3ULFH
5
7KHOHVVHURI
5
7LPH
5HXWHUV81GD\DYHUDJH
DQG 3ULFH
3ULFH
3ODWWV81GD\DYHUDJH 7LPH
DQG
3OXV'0/
)LJ)RUPXOD $YHUDJH3ULFLQJ
The formula pricing functionality is integrated into the creation of price

condition records using the core condition technique. Formula and average
pricing functionality is available within the Sales & Distribution (SD)
Module, and is integrated with Core pricing in the Material Management
(MM) Module and exchange fees.
A condition type can be configured as “formula based”, which then allows
definition of a formula rather than a rate when creating a condition record
for this condition type. Once a formula based price condition record exists in
the system, it is possible to retrieve the formula using the condition
technique during transactions in the Core System.

The formula and average condition type can be included in pricing

procedures in the same way as standard condition types. At the time that the
pricing takes place, the “formula pricing engine“ evaluates the formula
defined for each formula based condition type to give the rate which is then
displayed on the pricing screen.
As in the daily business practices of a company, the average period may not
be over at the time of order/invoice creation so that the price calculated can
be a provisional price rather than the final price. The status of the formula
evaluation, i.e. final price or provisional price is indicated by a status
indicator, which is held on the formula value display screen in the
document.
There is additional functionality to define provisional calculation rules,
which allows the user to specify a different average period for calculating
the provisional price if this is required. It is possible to create a differential
invoice in SD, which debits/credits the difference between the provisional
and final prices.
A pricing formula is made up of two parts: the formula definition, which
defines a reference to the quotations and the calculation rules, which define
the average period.
Formula Definition
The formula consists of two “terms“: the A term and the B term. Both contain )RUPXOD'HILQLWLRQ
an unlimited number of component lines.
An external quotation may be referenced within each component line. A
surcharge may be added within each or as an individual component line,
possibly with a different currency and UoM from the quotation.
A currency exchange rate type is assigned to each line item of the formula
term. This is a core field and is customizable in the IMG global settings. A
currency exchange rate type represents a source of information on currency
exchange rates. The exchange rate type is used to convert both the quotation
and the surcharges.
The total price for each term is determined by adding the value of the
component lines together. The value of the component line may be positive
or negative, thus allowing for differential calculations.
Finally, a rule defines how to determine the overall value of the formula
based on the value of the A term and the value of the B term. For example
using the higher of the A term and the B term as the formula value.
Calculation Rules
The calculation rules define the time period over which the average value of &DOFXODWLRQ5XOHV
the quotations in the formula is calculated and define the currency
conversion method.
The average period can be defined using fixed dates or using “variables”
around a key date in the transaction, for example a three day average, which
consists of one day before the delivery date, the delivery date and one day
after the delivery date.

For currency conversion, either the daily exchange rates or an average

exchange rate can be used. For average exchange rate calculation, the
average period can be defined in the same way as the quotation average
period. For example, for the above three day average quotation period one
can specify to use the average exchange rate of the working days of the
month prior to delivery.
&RQGLWLRQ([FOXVLRQ7HFKQLTXH+LJKHVW3ULFH
This is an enhancement of the standard SAP condition exclusion technique
which allows the user to define rules that specify which condition records
are and are not included. For example, should multiple discounts apply to
customer/material, the system can be configured to use the highest discount
and omit the other applicable discounts.
The IS-Oil enhancement allows selection of the highest price (worst price for
the customer), whereas the Core R/3 System only allows selection of the
best price for the customer.
1RUWK$PHULFDQ([FLVH7D[+DQGOLQJ
Several enhancements have been made to allow accurate invoicing of U.S.
state and federal excise taxes:
New fields for origin and destination and new condition types have been
created to facilitate proper tax calculation for taxes due at either the origin or
destination of the delivery.
Routines have been developed to identify when a customer has a federal or
state excise tax exemption certificate.
Prices as well as taxes can generally be entered with six decimal places.
For further information, refer to the chapter on TDP.
The basic pricing functionality is provided by Core R/3. In summary, this
includes the following:
q User-definable condition types
q Condition types can be set for gross prices, discounts and surcharges
q Order level and item level pricing
q Gross prices can be defined by a variety of parameters including:
material, customer/material and currency/price list type/material
q Discounts can be set for a given time period or applied continuously
q Discounts and surcharges can be set at an item or order level
q Discounts and surcharges can be set manually, if required
q Any combination of fields in the sales document can be used as the
search key for the appropriate pricing condition records

q The access sequence by which the search for valid records is made can
be defined by the user
q Calculation types can be defined, for example whether a discount is an
absolute amount or a percentage
q Pricing conditions can be defined as statistical, i.e. they are used for
statistical analysis, not for setting prices
q Multiple valid pricing records can be used and rules are set to determine
the correct record(s) using the condition exclusion technique.
q Pricing based on Different Units of Measure (UOM)
Core R/3 supports the requirement that an order can be made in
different UOMs than the condition record, and pricing can still occur.
The system converts the quantity ordered into the UOM of the pricing
condition record and price accordingly. This price is displayed to the
user. The UOM on the order does not change. The condition type’s UOM
can be selected from a pre-defined list. The volumes in various UOMs
can be printed on the invoice in an IS-Oil enhancement.
E\WKH,62LO'RZQVWUHDP0$3&RPSRQHQW
$OWHUQDWLYH3ULFLQJ'DWHVDW,QYRLFH&UHDWLRQ
This area of functionality includes the pricing of a sale according to the date $OWHUQDWLYH3ULFLQJ'DWHVDW
of a specified event in the sales order cycle. The life cycle of an order can ,QYRLFH&UHDWLRQ
encompass several days or pricing cycles. The sales order, delivery note,
goods issue, and invoice are all likely to occur on different dates. Since
different dates may be set up with different pricing condition records, the
choice of which pricing date to use at invoice creation directly affects the
calculated net price.
During user customization, each invoice type is defined with a specific
default pricing date to be used during invoice creation. In the IS-Oil
Downstream System, the following alternative pricing dates are available:
q Order date/time
q Invoice date/time
q Actual goods issue date (from the delivery document)
q Loading date (from the delivery document)
q Delivery date (from the delivery document)
If a manual pricing date and time is entered at invoice creation, the logic for
defining alternative pricing dates is not processed, and the system accepts
the manually-entered date for pricing without further validations, except if
the date entered is in the past. In this particular case, a warning message is
issued.

In addition, the IS-Oil Downstream time pricing functionality offers the

possibility of creating pricing conditions whose scale is either date and time
dependent or day of the week and time-dependent. The scale which can be
applied to standard price conditions is defined in the configuration of the
condition type.
An example of the pricing date procedure is shown in Figure 3.1. In the
example, an order for 10,000 liters was recorded on the first of July. The
delivery note was processed on the third of July, the goods issue on the fifth
of July, and the invoice processed on the seventh of July. All four document
dates have different prices in the associated pricing table. The selection of
which date to use for pricing directly affects the final price for the sales order
to the customer.
([HPSOH3ULFLQJ6WUXFWXUH
)RUWKHPRQWKRI-XO\8QOHDGHG
'DWH 3ULFH
-XO\-XO\ /LWHU
-XO\-XO\ /LWHU
-XO\-XO\ /LWHU
-XO\-XO\ /LWHU
-XO\-XO\ /LWHU
6DOHV2UGHU 6DOHV2UGHU
-XO\
/LWHUV 'HOLYHU\1RWH 'HOLYHU\1RWH )LQDO3ULFH

-XO\ $FFRUGLQJWR
2UGHUHG
*RRGV,VVXH *RRGV,VVXH 'DWH
-XO\
,QYRLFH ,QYRLFH
-XO\
)LJ3ULFLQJ'DWH3URFHGXUH
+HDG2IILFH%UDQFK/HYHO$JUHHPHQWV
+HDG2IILFH%UDQFK/HYHO Core R/3 pricing uses the pricing procedure defined in the sold-to partner
$JUHHPHQWV and the sold-to customer specific prices if defined. IS-Oil delivers the tools to
use the head office prices and/or pricing when selling to the branch.
A head office/branch indicator can be set on the branch customer master to
show whether the head office or branch pricing procedure should be
applied.
The indicator can only receive input if a head office is defined in the account
management data for the branch. In addition, two new requirements
programs (403 and 404) have been developed for use within accesses for any
condition type. When allocated to an access sequence, 404 accesses pricing
condition records defined for the customer, while 403 accesses pricing
records defined for the head office of the customer (if head office is defined).

With the Core functionalities, the access sequence and the exclusion
technique, it is then possible to define the circumstances in which each price
is used, e.g. always use branch price if one is defined, or use the lowest
price.
/RFDWLRQ6SHFLILF3ULFLQJ8VLQJWKH'5&
For pricing purposes, the location-specific pricing functionality (using the /RFDWLRQ6SHFLILF3ULFLQJ
Differential Reference Code - DRC) represents a geographical region that can 8VLQJWKH'5&
be used for setting prices, discounts, surcharges and taxes. A standard order
can have multiple customers (business partners) associated with it: the
actual purchasing customer (sold-to party), the consignee (ship-to party), the
billing-party and the payer, although they may all be the same customer.
The ship-to is the customer who takes actual receipt of the ordered material.
The DRC is defaulted from the customer master of the ship-to party to the
order header and the item
and can be overwritten. If a DRC is changed in the order, the order is
repriced to account for this change. If the ship-to party is changed in the
order header/item, the DRC is redetermined and the order is repriced.
The DRC has six different attributes which all can be used individually for
pricing. The DRC itself can also be used for pricing. They are:
q Country
q Region/State
q Metropolitan Indicator
q Wide area pricing zone
q State license fee zone
q Pricing DRC
The country and region fields have the same possible values as the Core R/3
country and region. The MI, WAP and SLF fields are DRC-specific fields and
must be defined in the configuration tables before they can be defined as
attributes.
The Pricing DRC allows a number of DRCs to point to the same DRC for
generic pricing purposes for example, while freight surcharge conditions
may be set at a DRC-specific level, discounts for certain types of customers
may be at a group of DRC levels. So while neighbouring DRCs 1,2,3, and 4
may all have specific freight surcharges, the discount for a certain type of
customer may be based on DRC 1 and DRC 2,3 and 4 point to 1.
An example of the Differential Reference Code table is shown in the figure
below. An order was created where the ship-to partner is located in Boston,
Massachusetts. For this region of the United States, certain price conditions
exist. The region code for Massachusetts has a specific tax rate which also
includes the Boston metropolitan area, and the wide area pricing region of
the Eastern half of the state. Through the DRC, all three pricing indicators
are combined under one indicator, which is linked to the customer master.

When the order item is displayed, the DRC of 12345 is defaulted. If the
default DRC is not valid (for example, the goods are not delivered to Boston,
but to another final destination, a different Metropolitan code is needed), the
operator can manually change the DRC to the correct value.
([DPSOH
)LJ'LIIHUHQWLDO5HIHUHQFH&RGH7DEOH
&RQWUDFW6SHFLILF3ULFLQJ
&RQWUDFW6SHFLILF3ULFLQJ The Core R/3 System allows the user to manually enter a contract price at
contract creation. However, the result of such a manual price is that
whenever the function “new pricing” is carried out during call-off or invoice
creation, the manual price will be lost and would thus have to be re-entered.
The IS-Oil enhancement offers the basis for contract-specific pricing, by
copying the contract number into all subsequent documents, i.e. call-off,
delivery and invoice. This field is included in the SD Pricing Field Catalog. A
condition record can then be created which includes the contract/item
number as one of its key fields in the access sequence.
There is an enhanced matchcode on contract call-off, enabling the selection
of contract numbers by sold-to party. This is available on contract pricing
condition record maintenance screens.

&RQWUDFW &DOORII 'HOLYHU\ ,QYRLFH

RUGHU
LQFKDQJH
PRGH
&RQWUDFW
6SHFLILF
3ULFLQJ
)LJ&RQWUDFW6SHFLILF3ULFLQJ
The above graphic shows a representation of the document flow with regard
to contract-specific pricing. Contract-specific pricing occurs at the contract
(order entry) and invoice level of the document flow.
3UH'HILQHG&XVWRPHU3ULFH/LVWV
Pricing based on a pre-defined list of products is a feature of the IS-Oil 3UH'HILQHG&XVWRPHU3ULFH
Downstream component. The functionality allows lists of products (and /LVWV
associated quantities) to be defined for each customer. The list may contain
materials of different material types.
This functionality is used for customers who regularly order the same
products and same quantities. In such cases, the ordered products may
always be the same but the prices may change frequently. Every time the
pricing list is accessed, the prices are recalculated using pricing condition
records valid for the specified pricing date and time.
The IS-Oil MAP enhancement allows the list of products to call the pricing
functions and the list to be priced. This pricing operation is not part of an
order transaction. The pricing of the list can be carried out for differing dates
or differing condition records depending on the needs of the customer. This
functionality simplifies and quickens the process for informing customers of
the current prices for regularly ordered products and quantities.
Each customer can have more than one price list. Each customer may have
several, but different, lists of regularly ordered products and quantities, and
each list can be priced separately as required.
The IS-Oil MAP enhancement includes a table which can be used to define
the list of products and quantities. A transaction has been created which
uses this table. This transaction calls the standard R/3 pricing procedures.
The pricing procedure selected for the pricing depends on the order type

(entered when selecting a list for pricing). The standard R/3 pricing
procedure has not been altered. The price list functionality operates
independently of the order process.
3ULFLQJ%DVHGRQ*URVVRU1HW9ROXPHV
3ULFLQJ%DVHGRQ*URVVRU1HW In Core R/3 the system uses the volume measured in the condition record
9ROXPHV unit of measure to calculate the condition value. Conversion factors are
defined by the user. The ASTM functionality is used, where applicable.
The IS-Oil enhancement in this area provides the ability to maintain a single
condition record and use either gross or net volume for pricing, based on
user defined criteria. This functionality only applies to the SD Module.
These criteria can be defined in two places:
q Gross/net pricing indicator - condition type
q Gross/net pricing rule - document line item
The gross/net pricing indicator, has been added to the condition type. This
indicator defines whether the value of the condition type should always be
calculated using the gross or net volume, or whether the gross/net rule on
the line item should be examined. If the value is blank, then normal Core
R/3 processing will occur.
The gross/net rule for the line item provides the user with a user-exit
capability to define a means by which to determine whether to price based
on gross or net volume.
The line item rule is determined using a table. Keys in the table are the
country and the region in which the title of ownership passes. This location
is determined by using the Incoterms.
Where special rules apply to a customer, the customer number can be
entered in this table.
Formula & Average Value-Based Price Calculations
)RUPXOD $YHUDJH9DOXH%DVHG3ULFH&DOFXODWLRQV
Formula & average value-based pricing functionality allows the calculation
of prices based on the value of externally-quoted materials over an average
period. This functionality is fully integrated with Core R/3 pricing using the
Core condition technique. The key configuration feature of formula-based
price condition types is that the calculation type is Q (formula and average
condition). This allows you to define a formula rather than a rate when
creating the condition record. In the formula, the reference to the external
quotation(s) is defined together with the average period.
Every time pricing is called, the formula is evaluated and the pricing
condition rate is calculated and then displayed on the pricing screen. The
start and end dates of the average period are determined from the
calculation rules (final and provisional) in the formula definition. Some or all
of the required quoted prices for the average value calculation may be in the
future with respect to the system date on the day that the condition is

evaluated. In this case the system calculates the “best price” using the period
up to the system date.
The formula evaluation status indicator which is held on the formula value
display screen shows the status of the formula, for example the formula was
evaluated using the provisional rules.
External quotations are held in a table. The key of this table is the source (for
example Platts, Reuters), type (for example high, low) the quotation
reference (for example Platts quote NWE/PREUNL/C/FOB) and the date.
The possible values of the keys and quotation check data are defined in the
configuration tables. A user exit routine exists which interfaces the formula
with the external quotation source using either the IS-Oil Quotation table,
another user-defined table or an interface directly to an external data
repository.
([WHUQDO4XRWDWLRQV
[
[
[
[
0DQXDORU
HOHFWURQLF
XSGDWH
)LJ6WRULQJ([WHUQDO4XRWDWLRQVLQ5,62LO'RZQVWUHDP
Formula Definition & Maintenance

The formula definition screens are common to condition maintenance and to
the pricing screens within sales and purchasing documents. Authorization
objects are provided to control maintenance in the documents.
There are two main data entry screens:
q Formula term entry screen
q Calculation rules screen
The Formula Term Screen

You define the quotations, surcharges and the two weighting factors which
create the price on the Formula Term Entry screen. The formula consists of
two “terms“, the A term and the B term. Both contain an unlimited number
of component lines. The total price for each term is determined by adding
the value of the component lines together. The value of the component line
may be positive or negative, thus allowing for differential calculations.

An external quotation may be referenced within each component line. The

quotation is identified by the source of the data (for example Platts), the
quotation type (for example Low, Mid or High) and the quotation number.
The quotation description is displayed for reference.
A surcharge may be added within each component line, possibly with a
currency and UoM different from that of the quotation. It is possible to enter
a surcharge on a component line which does not reference a quotation (for
example the quotation fields are blank for the component line).
A currency exchange rate type is assigned to each line item of the formula
term. This is a Core field, customizable in the global settings of the IMG. A
currency exchange rate type represents a source of information on currency
exchange rates. The exchange rate type is used to convert both the quotation
and surcharges into the formula rate display currency (also defined on this
screen). If this field is blank, then all values are converted to the document
currency by the formula pricing engine within pricing transactions (for
example by default rate currency = document currency).
A rule is assigned to each item on the screen, which decides how the value
of the line is calculated. For example, multiply the sum of the quotation and
the surcharge field by the product of the two factors.
Finally, a rule defines how to determine the overall value of the formula
based on the value of the A term and the value of the B term. For example,
take the higher of the A term and the B term as the formula value.
There are two buttons at the bottom of each term which lead to the screens
where the calculation rules are defined.
The Calculation Rules Screen
The calculation rules define the time period over which the average value of
the quotations in the formula are calculated. There are two main areas to
define:
q the means by which the price quotations are averaged
q the way that the currency exchange rate is determined
Defining the Averaging of the Price Quotations
There are two possible means of defining the start and end dates of the
average period. The first method is to define a fixed “date from“ and “date
to“ for the quotation average period. The second method is more involved
and works as follows:
1. The starting point is to identify a key date in the transaction concerned,
for example the pricing date or the delivery date. This key date is the
“reference date“. Some examples are delivered with the IS-Oil
Downstream component, and you can add further possibilities by
customizing the “reference date“ user exit
2. An “offset“ is then applied to this reference date in order to arrive at the
“event date“ (also referred to as the “offset reference date“). For
example, offset the reference date to the Monday of the previous week.
Again, some examples are delivered with the IS-Oil system, and the

user can add further possibilities by customizing the “reference date

offset“ user exit.
3. The next step is to define the period before the event date and the period
after the event date over which the average value is calculated. The
fields “period before“ and “period after“ are used for this definition
together with the “Time Unit of Measure“ routine, which is specified.
The “Time Unit of Measure” routine determines the start date and the
end date of the average period based on the values entered in the
“period before“, “period after“ and “exclude event date“ fields.
m If the quotation factory calendar defines that day as a non-working
day, then the system uses the weekend rule to decide which price
to use for that day. An example is delivered with the system: for
Saturday, use Friday’s price, for Sunday use Monday’s price. You
can add further possibilities by customizing the “weekend rule“
user exit.
m If the quotation factory calendar defines that day as a holiday, then

the system uses the non-posted day rule to decide which price to
use for that day. Again, you may customize non-posted day rules,
as the field is defined as a user-exit.
m Finally, you have to define the way that the system responds when
a quotation is simply missing, i.e. when, according to the quotation
factory calendar it should exist. In this case, the system uses the
customizable “No-quotation exists“ routine.
Defining the Currency Conversion for the Average Value Calculation

In principle, there are two methods of converting currencies within the
average value calculation: using daily exchange rates or using average
values of exchange rates. There are two fields in the calculation rules screen
which allow you to define which of these techniques is to be employed. The
possible values of these fields are defined by creating user exit routines for
the “daily currency rule“ and the “average currency rule“.
q In daily currency conversion routines, the price for a quoted material on
a certain date in the required currency is determined by multiplying the
quotation price for that day by a currency exchange rate for the same
day. This exchange rate converts the price from the quotation currency
to the required currency. The IS-Oil System delivers one example of this
routine, where the quotation is multiplied by the valid currency
exchange rate for the same day.
q In average currency exchange rate routines, the pricing calculation
engine determines an average value of the currency exchange rate over a
period of time defined by the currency exchange calculation rules (such
as currency time UoM, currency period before, currency period after,
etc.) which are defined on the same screen of the formula. This average
exchange rate is then used for all currency conversions for that term of
the formula.

External Price Integrity Check Program

A factory calendar is used to define on which days quotes are expected or
not expected. The external price integrity check program checks for incorrect
external price quotations using the factory calendar as defined in the
quotation check table. The integrity check program can be used to search for
price quotations that are not necessary or for quotations which are incorrect.
The program searches for the following quotes:
q Quotes that diverge from the previous value by a specific percentage or

amount
q Missing quotes
q Quotes that were not quoted (entries with a No Quote indicator)
q Quotes that are not necessary
The external price integrity check program generates reports using the
following selection criteria:
q Source
q Type
q Quote
q Date
q Percentage
Second Level Price Analysis

You can use the second-level analysis to display the quotations and
exchange rates which were used to calculate the value of a formula, of a
formula term, or of a formula item.
Second level price analysis is accessed from the existing first level analysis.
Second level price analysis generates a report which displays a detailed
analysis of the data used in the formula evaluation calculations. The analysis
can be performed for the entire formula, for either term, or for one term
item. IS-Oil provides default routines and the default report ROICANAL.
To use second level price analysis instead of the default routines, the
following activities are required:
q Maintain a report to define output and the analysis report data
q Define the format for the item section output
q Define report names and other routines (header and item format, error
handling, data capture) in the condition configuration

Master Repository
It is possible to define a formula master in which formulas are stored. You can
create, change and display formulas using the formula repository. Every
formula has a unique numeric or alphanumeric identifier. When maintaining
condition records, you can copy formulas in the formula repository or in
purchase documents or sales documents
The formula master record contains the following predefined search fields:
q Customer
q Material
q Plant
q Material group
q Vendor
The predefined search fields in the formula master can be redefined. During
formula maintenance, it is possible to retrieve a predefined formula from the
formula master. In addition, you can determine your own selection criteria,
which help identify a formula.
Authorization on Formula Maintenance

Access is restricted to formula maintenance in SD and MM documents and the
formula master, using the core R/3 authorization technique. Additional
authorization is provided to apply restrictions to sales documents, billing
documents, purchase documents, and information records. The authorization
concept also applies to formula and average based fees.
Repricing at MM Invoice Verification

The proposed value for an invoice item can be recalculated based on the
formula. Invoice verification is performed according to the recalculation.
MM Purchasing Documents
It is possible to use formula-based price conditions with contract, order,
invoice receipt, and goods receipt purchasing documents.
'LIIHUHQWLDO,QYRLFH
The differential invoice function creates an invoice in SD which debits or
credits the difference between the preliminary and final prices, when the
final price is known. Customizing settings make it possible to individually
define the circumstances in which a differential invoice is to be created. For
example, when the final price is not yet known. The differential invoice is
independent of invoice cycles and invoices any outstanding cycles.

A differential invoice itemizes the differential amounts at the condition type

level, that is, the differential amount for each condition record in the pricing
procedure of the differential invoice is calculated. If the system is unable to
calculate the differential amount at the condition type level, error handling
can be specified or customized by the user at the invoice type level. IS-Oil
provides an error-handling exit to cancel the existing billing documents and
rebill at the new price.
*ORVVDU\RI0$36SHFLILF7HUPV
&XVWRPHU3ULFH/LVW
A customer price list allows net prices to be calculated for a predefined list
of products. The price list contains the quantity usually ordered by a
customer along with the unit of measure.
'LIIHUHQWLDO5HIHUHQFH&RGH
The Differential Reference Code (DRC) represents a physical geographic
specification used for calculating location specific prices, discounts and
surcharges. The DRC allows prices paid by customers to reflect supplier’s
costs and permits areas with the same taxes or prices to be grouped together.
Crucially, the DRC is used to set prices based on the destination of a
delivery, for example on the location of the ship-to-party, however this can
be manually overridden in the sales document. The geographical elements
of the DRC are:
q Region/State
q Metropolitan Indicator (MI)
q Wide Area Pricing Zone (WAP)
q Pricing DRC (combines several DRCs for pricing)
q Country Code
q State License Fee Zone (SLF)
0HWURSROLWDQ,QGLFDWRU
One of the geographic elements within the Differential Reference Code
(DRC). It may be used to assign pricing conditions according to the city
code.
3ULFLQJ'LIIHUHQWLDO5HIHUHQFH&RGH
One of the geographic elements within the DRC (Differential Reference
Code). As a company may have hundreds of DRCs defined in their system,
it sometimes makes practical sense to group together some of these DRCs
which have the same pricing rules.

6WDWH/LFHQVH)HH=RQH
One of the geographical elements within the geographical reference zone. It
is used to establish tax or pricing conditions for a group of customers which
have been entered in the system as coming from the same gegraphical area.
7LPH3ULFLQJ
Allows pricing based on the time of the day in conjunction with the pricing
date or with the day of the week.
:LGH$UHD3ULFLQJ=RQH
The wide area pricing zone is one of the geographic elements within the
differential reference code (DRC). It may be used to create pricing
conditions.

&KDSWHU
0DUNHWLQJ&RQWUDFWVDQG2UGHU(QWU\
0&2(DVSDUWRI,62LO'RZQVWUHDP
+LJK/HYHO6XPPDU\
The objective of MCOE is to enhance the Marketing Contracts and Order
Entry functionality in the Core R/3 System. The enhancements provide
specific functionality required by the downstream oil industry.
Part of the required MCOE functionality is already supported in the Core
R/3 System; the remainder is implemented in the IS-Oil Downstream MCOE
enhancement.
q A streamlined, fast order-entry process, with various defaults such as
preferred supply plant for each order item, sales area from the customer,
sold-to party for ordering ship-to
q Ability to indicate final delivery against a call-off and reflect the actual
delivered quantity in the contract in the contract UoM
q Ability to specify restrictions in the contract which apply to call-off
details, e.g. product, quantity, ship-to party
q Ability to specify multiple ship-to parties in a contract and selection of
one at call-off entry time
q Ability to check the sold-to/ship-to relationship defined in the customer
master
.H\)XQFWLRQ%HQHILWV
The key function benefits are as follows:
The order-entry process is enhanced to speed up the process of order taking. )DVW2UGHU(QWU\
Due to the high transaction volumes, large number of customers, large
number of products and variety of delivery locations and methods, the
process can be sped up by the automatic determination of data. This
improves the speed and accuracy of the order-entry process.
The key benefit within a tele-sales environment is that the customer need only
specify his customer number, material and quantity in order to place an order.
The system automatically determines the supply plant, storage location and
sales area without any required input from the user. The IS-Oil order also
accepts a ship-to customer and links it automatically to the sold-to customer.

0DUNHWLQJ&RQWUDFWVDQG2UGHU(QWU\0&2(DVSDUWRI,62LO'RZQVWUHDP
These benefits result in a higher degree of customer satisfaction by requiring

less customer time necessary for placing an order. It also reduces costs by
allowing a higher order throughput.
The system can be adapted to interface to an automated telephone ordering
system. By keeping the information required to a minimum, the customer
can enter an order via telephone without needing an operator to accept it.
$FFXUDWH5HFRUGRI The quantity correction when calling off orders ensures that the system has a
'HOLYHU\4XDQWLW\ more accurate record of what has been delivered to the customers. This
ensures that the contract data is more accurate.
)OH[LEOH8R0+DQGOLQJ The modifications to pricing improve customer service by allowing changes
to the ordered UoM to be made while taking the order. This also allows the
customer to be advised of what his order will be in various UoMs without
actually changing the order UoM. Enhanced customer service is a key
competitive advantage in a commodity market and this enhancement helps
make the company more competitive.
$GKHUHQFHWR Checking the call-off order for adherence to contract terms ensures that
&RQWUDFW7HUPV agreed terms will be observed.
,62LO'RZQVWUHDP0&2(&RPSRQHQW
The following MCOE enhancements are provided in the IS-Oil Downstream
system:
)DVW2UGHU(QWU\
Within a downstream oil company, considerable business benefit is realized
by the ability to take orders quickly - for example, in response to telephone
orders. In this process, the manual determination of data is minimized as far
as possible in favor of having the system automatically determine fields for
the order. For instance, the selection of supply plant and storage location
can be automatically determined and the sales area can be defaulted from
the customer. The order-taker is no longer required to enter the sales
organization, distribution channel and division on the initial order entry
screen. The ship-to party can be entered as the ordering party and the
system finds the appropriate sold-to party automatically.

)LJ)DVW2UGHU(QWU\
4XDQWLW\&RUUHFWLRQIRU&RQWUDFW&DOO2IIV
The functionality concerning calling off orders from a contract is enhanced
with respect to differing units of measure (UoM). The functionality is also
enhanced to support those cases when the delivered quantities differ from the
ordered quantities: the delivered quantity is subtracted from the available
contract volume.
)LJ4XDQWLW\&RUUHFWLRQEDVHGRQ&DOO2IIV
3ULFLQJ
The basic system of pricing agreements based on contracts is enhanced in IS-
Oil Downstream so that sales documents created with reference to the
contract include the contract number. Contract specific pricing allows
specific pricing conditions to be set up for a customer and then to be applied

to all call-offs from that contract. This ensures that when pricing is carried
out (during order or invoice creation), the correct contract-specific pricing is
used. For more details, see chapter on MAP.
$GKHUHQFHWR&RQWUDFW7HUPV
Functionality to add validation to certain fields in the call-off to ensure that
the values entered do not exceed/differ from the terms agreed in the
corresponding contract.
+DQGOLQJ6KLSWR3DUWLHVLQ&RQWUDFW
Functionality to enter multiple ship-to partners in the contract header to
indicate that all contract items are applicable to those ship-to parties. When
calling off an order against a contract with multiple ship-to partners defined,
a selection screen appears so that the user can choose the ship-to for this call-
off.
'HOLYHU\'RFXPHQW
New fields in the delivery document to allow entry of more detailed external
information (for example bill of lading number) and possibility to indicate
that no further deliveries will take place for a call-off. The latter will be
reflected in the call-off and contract.
6ROGWR6KLSWR5HODWLRQVKLS
Functionality to prevent assignment of the same ship-to party to multiple
sold-to parties and report the sold-to/ship-to relationship.
The Core R/3 System covers only some functions required by the
downstream oil industry. IS-Oil Downstream meets this requirement with
functionality which adds to the Core functionality.
2UGHU(QWU\
The existing R/3 order entry process supports some of the requirements of the
IS-Oil fast order entry enhancements, e.g. some customer data is already
provided within the order entry transaction. Another example is availability
checking: this is already in R/3 but is enhanced further in IS-Oil Downstream,
including proposal of alternate sources of supply at the order item level.

The R/3 System currently supports orders where the called-off order UoM
differs from the contract UoM.
E\WKH,62LO'RZQVWUHDP0&2(&RPSRQHQW
)DVW2UGHU(QWU\
The order-entry department at a downstream oil company is faced with the
following challenges:
q High transaction volumes
q Large number of customers
q Large number of products
q Large number of possible delivery locations
q Wide range of possible delivery methods
Therefore, the order entry process needs to be as quick as possible with
automatic determination of data, where possible.
The Core order entry process within R/3 allows a significant amount of data
relating to the order to be available and automatically determined when the
order is taken. This data is available via the various pull-down menus within
sales order-entry processing.
In IS-Oil Downstream, no separate “fast order” entry path can be created.
Rather, the existing order entry process is enhanced to meet the requirements
of the oil industry.
The following details show the functional enhancements to the current order
entry process.
Automatic Allocation of Order Type, Supply Plant and Storage Location

The Core R/3 System automatically defaults the last order type used. The $XWRPDWLFDOORFDWLRQRI
user can override the order type defaulted if desired. The exception to this is 2UGHU7\SH6XSSO\3ODQW
the first time the transaction is used in a session, the user must select the DQG6WRUDJH/RFDWLRQ
order type (i.e. there is no initial automatic default).
The Core R/3 System selects a default supply plant. This selection is
determined from the customer master record of the ship-to party or the
material master record. The selection is automatic, but can be manually
overridden. In IS-Oil Downstream, the supply plant selection is enhanced to
include full availability checking across all the preferred and alternative
plants.

Sales Area Defaulting

6DOHV$UHD'HIDXOWLQJ In Core R/3, the sales area needs to be entered on the order entry screen.
On the IS-Oil entry screen, after a customer has been entered, the system
searches for the corresponding sales areas to which it is assigned. If only one
sales area is found, then it is automatically defaulted in the Sales Area fields.
If several sales areas are found for the customer, then a popup appears,
prompting you to choose one of the sales areas. The entry selected is then
copied into the sales area fields.
There is also a pushbutton that can be used to trigger the sales area
defaulting functionality on request. The popup shows all the valid sales
areas for a particular customer, if it is assigned to several sales areas. This
option is only possible if there are no line items on the order.
Fast Order Entry Fields

)DVW2UGHU(QWU\)LHOGV The following fields are mandatory in the fast order-entry transaction:
q Order type (one-time)
q Sold-to or Ship-to party
q Material
q Order quantity
q Customer purchase order number (depending on configuration)
The following fields can be defaulted:
q Sold-to party (if ship-to is entered as ordering party)
q Sales organization
q Distribution channel
q Division
q Handling type
q Item category
q Plant
q Contact details
Speed and accuracy are optimized by limiting the number of mandatory
input fields and maximizing the number of defaulted fields.
Core R/3 allows the order-taker to select and copy the last order from the
sold-to party. IS-Oil enhances this function to allow the order-taker to select
and copy the last orders from a combination of sold-to and ship-to customers.
Line Item Functionality
/LQH,WHP)XQFWLRQDOLW\ Within Core R/3, some data is displayed in the header during this process.
Further information on the customer is quickly available via the specific
function buttons or pull-down menus (within the order entry transaction).
The Core System carries out validation checks on the data entered in the line
item fields. In addition, enhanced availability checking is carried out in the
IS-Oil Downstream System.
The system is enhanced to allow the handling type to be displayed at the line
item level. This code establishes how a material that is subject to excise duty

will be used by the customer. In the IS-Oil Downstream System, the handling
type is used to determine the excise duty status of the material/customer
combination (see TDP).
The system defaults a handling type. This comes from either the customer
master record or the customer/material information. Both these areas are
enhanced to include handling type fields. The default handling type can be
manually overridden with a value entered by the user. The user selects from
a pre-defined list of handling types. The system is enhanced to provide a list
of handling types.
Availability Checking
The IS-Oil Downstream enhancements in the MCOE area are based on the $YDLODELOLW\&KHFNLQJ
availability check functionality in the Core R/3 System.
Within Core R/3, availability checking is carried out by using the default
supply plant in the line item. The default supply plant comes from the
customer master record or the material master record. When creating or
changing an order, this default plant can be manually overridden (selected
from a list of possible supply plants) by the user. The availability check is
then carried out against the selected plant. Within the Core R/3 System, this
check runs only against that one plant.
The IS-Oil Downstream MCOE enhancement allows for the creation of a list
of alternative plants for availability checking. If the default plant does not
have sufficient availability, then the first alternative plant is checked. The
system then searches down the pre-defined list of alternative plants until a
plant with availability is found. A total of 4 alternative plants can be
specified. These are manually set by the user prior to order-entry.
The availability checking functions which are carried out on each alternative
plant are the Core R/3 functions, for example static checks (based on the
total available quantity at a plant) or dynamic checks (taking into account all
planned receipts and deliveries) can be configured; replenishment lead time
(RLT) can be included or excluded from the calculations.
)LJ,62LO3ODQW'HWHUPLQDWLRQ

In IS-Oil Downstream , if no plant has the required availability, the system

defaults back to the initial plant and warns the user of the shortage. This
“warning” is the Core R/3 window: “Standard Order: Availability Control”.
This allows the user the normal options of choosing partial delivery,
rescheduling the delivery date, or accepting a lower, confirmed order
quantity. This applies to the initial default plant.
Line Item Category
/LQH,WHP&DWHJRU\ The Core R/3 System supports the allocation of item categories to the line
items on an order or any other sales document. This is used to determine the
requirements on the line item (for example a text line would have the item
category of “text” and would not be part of any pricing calculation). The
item category controls pricing, billing, delivery processing, stock postings
and the transfer of requirements. For each document type, certain item
categories are permitted. The way each line item category is processed is
controlled by control elements. The system automatically allocates the line
item category to each item on the order based on the sales document type
and material. The user has the option of manually overriding the item
category, if required.
The Core R/3 System’s automatic allocation of item category is enhanced to
allocate each line item with an item category determined by the customer
/material combination. The customer is identified by a customer classifi-
cation. The Core R/3 System currently supports this customer classification
code. The material is identified by the material group which the R/3 System
currently supports. The customer classification/material group thus defines
the item category. In IS-Oil Downstream, this is defined in a new table. The
item category found by this search overrides that set by the document type.
Thus, for example, if a customer group has a material normally delivered
from consignment stock, then the relevant table entries might be:
The business situation addressed by this functionality concerns call-offs
from contracts. Typically, a contract is set up for a customer and then
various sales orders are created, which call-off from the contract. Core R/3
functionality supports this process.
The contract specifies various materials and associated quantities and units
of measure (UoM). The total price of these materials is then determined.
The order call-off need not be in the same UoM as the contract. The Core
R/3 System supports this and converts the called-off UoM to the contract
UoM in order to update the contract accordingly. The UoM on the order
remains unchanged.
The enhancements to this process are as follows:
Correction for Final Delivery Quantity
The situation this addresses is one in which the actual final delivery quantity
against the call-off does not equal the original quantity in the call-off. The
Core System did not update the contract with the actual final delivery

quantity. It only updated the contract with the original quantities in the sales
order. The enhancement indicates when the final delivery has been made
from the call-off and then updates the contract accordingly with the actual
delivered quantity. In addition, the UoM of the delivered quantity need not
be the same as on the contract, as the system converts it to the contract UoM
and updates the contract accordingly. Depending on the UoMs used, this
conversion may require the use of ASTM (American Society for Testing &
Materials) conversion functionality.
The user indicates when a final delivery has been made by using the final
delivery indicator in the delivery document. When the final delivery is
made, the system does the following:
q Calculates the total quantity called off in the order UoM
q Calculates the total call-off quantity in contract units of measure (this
may utilize ASTM functionality)
q Updates the contract called-off quantity (released quantity)
q Sets call-off status to “completed”
3ULFLQJEDVHGRQ&RQWUDFWV
It is sometimes necessary to have price agreements that are related to a
specific contract. It is therefore necessary to price call-offs based on the
original contract. The IS-Oil enhancements offer the basis for this functionality
by copying the contract number into the call-off and any subsequent
documents.
$GKHUHQFHWR&RQWUDFW7HUPV
When call-off orders are entered against a contract, the system proposes
those contract items which have not been fully delivered and which have not
been set to “completed”.
Call-off quantity and other item data, like unit of measure, ship-to party and
payment terms are defaulted from the contract. The Core R/3 System allows
those details to be changed during the call-off, as well as entry of additional
items which were not specified in the contract.
The IS-Oil enhancement provides the possibility of setting restrictions at the
contract level which apply to the orders called off against the contract. These
restrictions can apply to products, quantities, units of measure, validity
periods, payment terms and allowable ship-to parties. The new functionality
checks the details of the call-off against the restriction and prompts the user
with a message, if the details are different. The type of message (error,
warning or information) is specified when the restriction is set in the
contract.
A call-off may be referenced to multiple contracts, all of which may have
restrictions set. In this case, the type of message for each respective restriction
is applied.

+DQGOLQJ6KLSWR3DUWLHVLQWKH&RQWUDFW
In the Core R/3 System, only one ship-to party can be entered in the contract
header/item level. In the oil industry, one contract often covers delivery to
multiple locations (ship-to parties). In the Core R/3 System, this business
requirement would result in a manual adjustment of the ship-to party during
entry of each call-off. The IS-Oil enhancement allows the specification of
multiple ship-to parties in the contract header to indicate that the entire
contract is applicable to those ship-to parties. In contract create mode, all the
ship-to parties in the sold-to party customer master are proposed for selection
as alternative ship-to partners. This selection screen is reached by a new
pushbutton in the header partner screen.
When calling off an order from a contract with multiple ship-to partners
defined, a selection window is displayed so that the user can choose the
ship-to partner for the call-off.
This functionality is integrated with the call-off restriction functionality
described above, so that the assignment of ship-to parties can be restricted to
those specified in the contract.
'HOLYHU\'RFXPHQW
The delivery document has been enhanced with new fields to allow the user
to specify more detailed external information and to indicate that no further
deliveries will take place for a call-off, which is reflected in the contract.
The delivery document contains a new external details button in the header
and in the details screens. This button causes a popup screen to be displayed,
showing the external bill of lading number, miscellaneous delivery number,
origin/destination information and other miscellaneous information. The
external bill of lading number and miscellaneous delivery number can be
accessed with a new matchcode. The external details popup is also available in
the contract and call-off.
6ROGWR6KLSWR5HODWLRQVKLS
In the Core R/3 System there is no check on the ship-to/sold-to party
relationship which is defined in the customer master. It is possible to assign
the same ship-to party to several sold-to parties. The IS-Oil enhancement
performs a check on this relationship during customer master maintenance.
The check, which is optional, and the outcome (error, warning, information
message) are defined at sales organization level. Reporting functions are
available to show sold-to/ship-to party assignment and vice versa.

&KDSWHU
0DUNHWLQJ5HWDLO1HWZRUN051
+LJK/HYHO6XPPDU\
The objective of the IS-Oil Downstream MRN application is to optimize the
business location handling support capabilities of the R/3 System.
The first step towards achieving that objective is to define the business
location in a way that is neutral and does not contain information specific to
a single business view.
The second step is to provide the capability to define links from the business
location to other, business function specific views of the location.
The next step towards optimization is achieved by building a mechanism to
link the business location to business partners of the system owner. The
links are recorded in terms of the type of activity or role that the partner has
with respect to the location.
The final step is concerned with the generation of performance reports about
the business location. The statistical information used to report on the
business location is collected from processes that take place with respect to
standard system objects to which the location has been linked.
The application is intended to meet two distinct user requirements:
q Dialog support for a head office view of the business location and its
associated data
q Reporting of performance of physical locations or sites in terms of the
multiple business events that occur at these sites
6\VWHP2YHUYLHZDQG2EMHFWLYHV
Commercial organizations exist to sell company products or services in some
kind of marketplace. It is common to bring the product or service to a place
where it is convenient for the purchaser to obtain or make use of the product
or service. In the retail business, particularly, commercial organizations or
companies depend on convenient customer access to their products.
To reach the retail customer, they may use business locations (for example
stores, service stations) which try to provide the best possible environment
for the customer to obtain company products or services.
In the search for improved profitability it is important to attract the
maximum number of consumers to every business location. This is often
achieved through the provision of a variety of support services, which may
be provided by other organizations or individuals operating at the business

0DUNHWLQJ5HWDLO1HWZRUN051DVSDUWRI,62LO'RZQVWUHDP
location. For example, a large service station may, in addition to its main
business of fuel sales, sub-let forecourt area to smaller businesses providing
specialist services such as a fast-food restaurant, service bay, newspaper and
magazine sales and even overnight accomodation.
)LJ $EXVLQHVVORFDWLRQPD\SURYLGHDQXPEHURIVHUYLFHVZKLFKPD\EHKDQGOHG
RQEHKDOIRIWKHORFDWLRQRZQLQJRUJDQL]DWLRQE\GLIIHUHQWEXVLQHVVSDUWQHUV
A commercial business location may be the basis for a wide range of
business activities, including:
q Sales to the consumer of company-owned stock by company employees
q Sales to the consumer of company-owned stock by a commission
charging business partner or dealer
q Sales to the consumer of dealer-owned stock by company employees
q Sales to the consumer of dealer-owned stock by the dealer
q Sales to the dealer of company stock
q Sales to the dealer of company services such as maintenance or
equipment leasing
q Leasing of sales floor space by a dealer in connection with selling
company owned or dealer owned stock or both (sometimes referred to
as a concession)
q Leasing of company branding and/or franchise agreements
Any combination of the above is also possible, not just simultaneously but
also over time.
It follows that a company’s view of business can be strongly centered on the
locations where that business takes place, particularly if that company is
concerned with retailing or property management. It follows that reports,
analyses and comparisons which take place with reference to the location
must recognize the business location as a discrete and permanent object, a

separate entity from the business partners active at that location. This separation
must also be recognized by the systems which provide this information.
This document discusses a component application of the IS-Oil Solution
which supports the independent definition of a business location in the R/3
System. The primary objective of this application is to provide support for
the management of service stations and other oil-industry specific business
locations.
A guiding principle of the design team has been to keep the design open, so
that the application can also be used for commercial locations which are not
oil-industry specific.
The name of this IS-Oil application is “Marketing: Retail Network” or
“MRN”, so called because “retail network” is the term used to describe the
retail network interests of the downstream oil business.
The introduction of an independent business location to the R/3 System
arises from two distinct user requirements:
q Support for the head office view of the business location and its
definition according to one or more R/3 applications
q Performance tracking of physical locations or sites in terms of the
multiple business events that occur at those sites
The business events or transactions which occur at a business location actually
take place with reference to business partners an/or accounting and logistical
objects. For example, sales or purchasing processes occur with reference to
customer or vendor business partners, operational overheads can be settled
against a generic cost collector and an internal goods movement to or from a
location can be recorded in the material ledger.
The figure below gives an overall view of the positioning of the IS-Oil
business location with respect to other objects within the system.
)LJ 7KH,62LO051YLUWXDODSSOLFDWLRQDFFHVVHVGLDORJVDQGPDNHVRWKHU
UHIHUHQFHVWRH[LVWLQJDSSOLFDWLRQVDSSOLFDWLRQ7UDQVDFWLRQSRVWLQJVDUH
UHFRUGHGE\ORFDWLRQPDQDJHPHQWVSHFLILFVWUXFWXUHVLQ6,6DQGORFDWLRQDV
FKDUDFWHULVWLFLQ&23$

2XWORRN
This document describes functionality which is provided in the IS-Oil
product. The functionality is largely stand alone, using independent
program, function and dictionary objects with read-only access to other
objects within the R/3 System. The independent development of IS-Oil
MRN was a deliberate development strategy, intended to minimize the
software maintenance overhead during successive upgrades of the standard
R/3 product, on which IS-Oil is based.
.H\)XQFWLRQ%HQHILWV
The key function benefits provided by the IS-Oil MRN application are as
follows:
2SWLPL]HG%XVLQHVV/RFDWLRQ The facility to define the business location in a way that is neutral and does
+DQGOLQJ not contain information specific to a single business view, as well as the
capability to define links from the business location to other, business
function specific views of the location and navigate to those views.
0RGHO5HODWLRQVKLSV%HWZHHQ The provision of a mechanism to link the business location to business
3DUWQHUV /RFDWLRQV partners of the system owner. The links are recorded in terms of the type of
activity or role that the partner has with respect to the location
/RFDWLRQ5HSRUWLQJ The generation of performance reports about the business location using
statistical information collected from standard processes related to that
location.
,62LO'RZQVWUHDP051&RPSRQHQW
The following is a summary of the IS-Oil functions provided by the IS-Oil
Downstream MRN application.
&HQWUDOL]HG0DLQWHQDQFHRI%XVLQHVV/RFDWLRQ
The central building block of the IS-Oil MRN application is the business
location. The business location master data object is used to register a
physical location in which the system owner has some kind of economic
interest.
2WKHU$SSOLFDWLRQ9LHZVRIWKH%XVLQHVV/RFDWLRQ
The business location object persists in the system throughout the life of the
actual physical location which it is depicting. The business location is linked
to other economic objects within the system which are used in turn to depict
the physical location according to the various application modules of the

R/3 System. These links are supported by the object link facility provided in
the business location maintenance transactions.
'HILQLWLRQRI/RFDWLRQ3DUWQHU5ROHV
A mechanism is provided to link the business location to business partners
defined in the system, where those business partners are transacting some
kind of business with respect to that location. The link between the business
location and the business partner is made in terms of both a location partner
role type and validity period. Thus the duration of a business partner’s
responsibilities or activities can be recorded, as well as the activities
themselves.
5HWDLO1HWZRUN&RQWUDFW+DQGOLQJ
An extra screen is provided in the standard SD sales contract to support the
entry of retail network-specific data. In addition, a new contract index is
populated to enable fast access of contracts by business location rather than
business partner.
3HUIRUPDQFH5HSRUWLQJDW/RFDWLRQ/HYHO
When links have been established between the business location and other
objects or business partners in the system, it is possible to populate statistical
information structures with performance data which is specific to individual
locations.
A new information structure is provided within the Sales Information
System (SIS) to record sales activity at the location level.
The business location is made available as a fixed characteristic in the
Controlling-Profitability Analysis reporting tool (CO-PA) and can be
incorporated in an operating concern reporting structure accordingly.
*HQHUDO1RWH
IS-Oil Downstream MRN is a virtual application, because it contains no
complex master or transaction data objects (although there are some simple
master data objects). Instead, it references master and transaction data
objects which are provided by existing R/3 applications.
It follows that the full range of business processes which are necessary for
the management of business locations are available within the R/3 System
itself. All these key IS-Oil Downstream functions are accessible from the
MRN business location transaction. This approach is explained in more
detail in the section discussing object links and navigation.

051DV9LUWXDO$SSOLFDWLRQ
Virtual applications must be built in an open and flexible way so that
enhancements made to R/3 applications referenced by the virtual applications
do not fundamentally change the operation of the virtual application.
An important consideration with regard to a virtual application is the extent
to which it requires configuration of reference applications before it becomes
viable. In the case of MRN reporting, especially in the area of profitability
analysis, the accuracy of the information being recorded about the business
location is dependent on the complete definition of business location
activities in the standard system.
'HWDLOHG'HVFULSWLRQRI%XVLQHVV)XQFWLRQV6HUYHG
E\WKH,62LO'RZQVWUHDP051&RPSRQHQW
&HQWUDO0DLQWHQDQFHRI/RFDWLRQ'DWD
&HQWUDO0DLQWHQDQFHRI The central building block of the IS-Oil MRN application is the business
/RFDWLRQ'DWD location. A complete set of maintenance dialogs are provided to enable the
user to register the business location in the R/3 System.
The registration of the business location in the system is supported by a range of
standard R/3 System services, such as classification, text element processing
(using SAPscript or WINWORD), change document processing, central address
management and archiving. In addition, the MRN functionality interfaces with
the ABAP Extension (enhancement) tool to support the definition of customer
installation data elements in the business location master table.
,QGHSHQGHQW/RFDWLRQ0DVWHU
,QGHSHQGHQW/RFDWLRQ0DVWHU A new transparent table is provided which is used as an “anchor” point for
information entered in the system about a specific business location. The
table contains no application data itself, other than data defined by fields
added via APPEND structures by user installations, rather it is the check
table for a number of dependent tables used by MRN sub-applications. The
following groups of technical data are recorded in the business location
master:
q Business location type
q Address number for the central address maintenance system
q Blocking and deletion indicators
q Create and change dates, times and responsible users

/RFDWLRQ7\SLQJ
All business location master records must be assigned a location type during /RFDWLRQ7\SLQJ
the creation phase. This may be changed later using a dedicated type change
dialog.
Location typing is used to define the business purpose of the location.
Examples of location typing would therefore be “depot”, “department
store”, “service station” or “development plot”. The typing of a business
location is not expected to change frequently during the lifetime of a site.
Possible reasons for change might be the conversion of a development plot
or investment site into an operational location. It is probable, however, that
the eventual purpose of the site would be known at the time it is entered
into the system as a master record, even if it remains a vacant business plot
for some time.
From a technical perspective, business location typing is used to support:
q Identification of location master data via search facilities such as
matchcodes
q Control of number range allocation, i.e. internal or external and
applicable ranges
q Control of access to master data according to type via authorization
profiles
q Field selection, some fields may be not be valid for some types
q Control of links to other application objects used to depict the business
location
q Control of partner role types available to define links to business
partners involved with the business location.
Because there are a number of application dependencies on the type
assignment of a business location, a special dialog is provided which validates
technical dependencies before permitting a type change to be posted.
The type change dialog will only support changes to the location type, if the
following is true:
q The location ID of the business location falls within the number range
defined for the new location type or the location ID of the business
location does not fall within the number range defined for the new
location type but the “Mismatched number range OK” flag is set “on” in
the “MRN System Control - General and Top Level” step within the
MRN IMG.
q All populated object link field groups in the business location are
permissible for the new location type - if an object link field group which
is supported for the original location type but is not supported for the
new location type contains no values, the location type change is
supported.

q No partner role assignments exist for the business location which are not
permissible for the new location type - if a partner role assignment is
detected which was permissible for the original location type but is not
permissible for the new location type, the change will be rejected until
that partner role assignment is deleted.
/LQNWR&HQWUDO$GGUHVV0DLQWHQDQFH
/LQNWR&HQWUDO$GGUHVV The central address maintenance system is used to record all address-based
0DLQWHQDQFH information which is relevant to the business location.
The link to the central address maintenance system is made at the direct
address no. level. “Address valid from” and “International version no.”,
which form part of the key of the central address file are supported at the
database level, but not at the dialog level. As of the current release it is
therefore only possible to specify one address per location.
7H[W(OHPHQW3URFHVVLQJ
7H[W(OHPHQW3URFHVVLQJ A link is provided from the business location to the R/3 long text handling
utility. The link supports the centralized storage of text-based information
for each business location. The long texts can be stored in the following
formats:
q SAPScript
q WINWORD
Other text formats compatible with OLE enabled PC editors may be
available in future. The text formats for each text type can be set by your
technical support group.
Texts for the business location can be entered in “Create” or “Change”
modes of the business location maintenance transaction.
/LQNWR&ODVVLILFDWLRQ
/LQNWR&ODVVLILFDWLRQ A link is provided from the business location maintenance transaction to
standard dialogs of the classification system. For technical reasons, the
classification maintenance screen is only available via a specific dialog call
and not as part of the standard business location maintenance transaction
screen sequence. Within the business location allocation screen and
characteristic value assignment screen, exactly the same functions are
supported as in the allocation functions from the classification menu.
A class type has been created in the classification system for the MRN
business location. This is class type “800”.
When a specific business location has been allocated to one or more classes
within the classification system, it can be accessed using the powerful search
tools available within this powerful application. The classification system
can also be used to apply additional characteristics to business location

master data. In this way it can be used as an alternative to the MRN

APPEND Maintenance Concept discussed below.
&KDQJH'RFXPHQW3URFHVVLQJ
Using the change document listing feature of MRN, it is possible to display &KDQJH'RFXPHQW3URFHVVLQJ
all changes which have been made in a business location master record and
all dependent structures such as location partner roles. The changes are
recorded by the central R/3 change document processing facility.
There are five selection fields through which the parameters can be set for
the list of change documents that the system generates:
q Business location ID
q Document number
q From date
q From time
q Last changed by
Generic specification is possible for all of them except the date and time
fields, using the “*” as a wild card symbol.
User-defined fields in the business location table are also recorded by the
change document processor, from the moment that the table is regenerated
after the addition of the new fields.
$UFKLYLQJ
MRN data archiving removes business location data which is no longer $UFKLYLQJ
required in the system, but which must be retained off-line in a way that is
readily accessible.
Data in the R/3 database can only be archived via archiving objects, which
describe the data structure. For the MRN business location all master and
dependent data is archived via the archiving object IS_OIFSPBL. This
consists of the location master, assignment records, partner role assignment
records, change documents, SAPscript texts and information system records.
In addition, any business location entries which have been written to
business partner master records are deleted and the business partner master
records correspondingly updated. The business partner master records are
not archived at this time. The application archiving objects are pre-defined
in the system.

The archiving procedure comprises two main steps:

q Creating archive files: the data to be archived is first written sequentially
into a newly-created file. These archive files can, for example be passed
to an archive system via ArchiveLink.
q Executing delete program: the data in the archive files is removed from
the database by the delete program.
The archiving programs are scheduled as background jobs, but can also run
during online processing. The system need not be shut down during archive
processing.
Routines are also provided to reload business location data from archive
files.
8VHU'HILQHG)LHOGV
8VHU'HILQHG)LHOGV The application of user-defined fields to the business location object is
managed through the MRN APPEND Maintenance Concept (MRN AMC).
The MRN AMC uses the ABAP Workbench Enhancement Manager. This
enables the user to control the implementation of the MRN AMC
functionality. User customization is supported in terms of both the addition
of custom defined data fields and maintenance of those data fields by means
of screen dialogs.
The MRN AMC approach is necessary because research has shown that
there is little commonality between the business location management
requirements of the users with respect to data fields. MRN AMC enables
each user installation to define only those data fields that they wish to
maintain as part of the MRN Business Location table.
The components of the MRN AMC are:
q APPEND structure maintenance provided by the ABAP Dictionary
q An enhancement containing two CUSTOMER-FUNCTION calls for data
transfer
q The SUBSCREEN concept from the ABAP Screen Painter
q The table customizing facility provided by the R/3 IMG
All user development of customized data element extensions to the MRN

business location table can be achieved using these four building blocks.
The approach of the MRN AMC to the incorporation of maintenance dialogs
which are developed by the user is to use the concept of the “subscreen”
provided by the ABAP Workbench Screen Painter. In this, a dialog main
screen uses the “CALL SUBSCREEN” command to call a dialog subscreen to
fill a pre-defined area of the main screen.
The installation defined subscreen is defined as a dynpro belonging to a
customer work area (also known as “module pool” or “program”), not the
MRN business location work area, SAPMOIFA. This means that the business
location master data structure (including the installation’s own fields,
defined via the APPEND structure) must be passed to the customer work

area before it can be processed and returned to the MRN work area after
processing. This is achieved by the use of a pair of user exits which can be
enabled by the installation.
)LJ&XVWRPHUHQDEOHGIXQFWLRQVWUDQVIHUGDWDWRWKHFXVWRPHUZRUNDUHD
/RFDWLRQ2EMHFW/LQNVDQG1DYLJDWLRQ
This section deals with the component of the MRN application which /RFDWLRQ2EMHFW/LQNV
supports the creation of links from the business location to other objects in DQG1DYLJDWLRQ
the R/3 System which can be used to depict the business location.
As a virtual application, MRN works by providing a primary object in the
system to represent the business location, which holds only minimal data
about the business location. Other objects in the system are used for this
purpose. These objects are referred to as secondary depictions of the business
location. When these objects are created using application modules in the
standard R/3 System, the MRN object link and navigation component can
provide a link to existing transactions which are used to display or maintain
data within those application areas.
Links are possible to eight different link objects. These are shown in the
figure below.

)LJ 'LDJUDPVKRZLQJWKHREMHFWVWRZKLFKOLQNVDUHVXSSRUWHGIURPWKH051
EXVLQHVVORFDWLRQ
The permissible link definitions which can be made for a specific business
location are determined by the location type for that location. For each
location type defined in the MRN IMG, it is necessary to identify which of
the object links are supported for that type.
The entry of the object link data is made using a fullscreen dialog within the
business location master data maintenance transaction.
In cases where all or nearly all object links are definable for the business
location (as determined by the type of that location) the screen will contain a
large number of input fields requiring the user to use the scroll function. To
avoid this it is possible to invoke a second object link definition screen. This
is done by allocating some assignment boxes to the second screen when
defining the permissible object links by location type.
&RQILJXUDEOH2EMHFW/LQN1DYLJDWLRQ
&RQILJXUDEOH2EMHFW/LQN A configurable navigation tool is provided in connection with the link object
1DYLJDWLRQ definitions which can be defined within the business location maintenance
transaction. The tool enables user installations to specify the dialog trans-
actions to which the system provides links when the navigation function is
used.
The range of dialog transactions to which links are supported are
customizable via a step in the MRN IMG. Using this customizing facility, it
is possible to define the permissible range of dialog transactions to which
links can be supported for each object link type.

Additionally, for each “object link type/dialog transaction” combination it

will be possible to:
q Optionally specify a short text to describe the link (if no entry is made,
the target dialog transaction text is defaulted from the TSTCT)
q Indicate which SET/GET parameters will be activated for each
transaction link
q Indicate if the transaction is to be called with/without a “skip first
screen”
Users will need to take care when defining these entries. However, MRN
processing is designed to ignore incorrect SET/GET parameters. Inappropriate
“skip first screen” entries are handled by the dialog transaction itself, i.e. if the
first screen cannot be skipped due to a missing entry the system displays the
first screen with an error message.
If no entry is made in the IMG for the dialog control of a particular link
object, the system calls a default dialog. Normally, this is the display master
data dialog transaction for that object link.
If one control entry is made for a particular link object, the system calls the
specified dialog transaction. If multiple entries are made for a link object, the
system calls a modal dialog box or “popup window”. The purpose of this
popup is to allow the user to choose which link dialog he or she wants to
access whenever more than one possible link is defined for the link object.
Radio buttons are used to indicate to the user that a single access path is to
be chosen. A “Double-click” selection is also supported.
The diagram below shows how the configurable popup window might look
for the asset master link object with three possible choices:
)LJ *UDSKLFWRVKRZWKHGHIDXOWOD\RXWRIWKHOLQNREMHFWGHILQLWLRQVFUHHQZLWKLQ
WKHEXVLQHVVORFDWLRQPDLQWHQDQFHGLDORJ,QGLYLGXDOILHOGVIRUHDFKDUHDDUH
QRWVKRZQ
The number of selection choices is dependent on the number of entries made
in the IMG. Three choices are shown in the illustration above.

/LQNWR&RVW&HQWHU
/LQNWR&RVW&HQWHU A link is provided from the business location to the CO cost center master
data object. The link enables the cost and overhead processing for the
business location to be determined. As of the current release, the link is
specified on three levels:
q Controlling area
q Cost center ID
q Valid-to date
The diagram below shows how the link between the business location and
the cost center is modelled in terms of entity relationships, using an SAP
Entity Relationship Model.
)LJ )RUHDFKEXVLQHVVORFDWLRQIRUZKLFKDOLQNWRFRVWFHQWHULVHQDEOHGLWLV
SRVVLEOHWRGHILQHRQHFRPELQDWLRQRIFRQWUROOLQJDUHDDQGFRVWFHQWHU
DVVLJQPHQWLQWLPH
Capabilities exist in the underlying architecture of the business location
maintenance dialog for the handling of non-time-dependent cost center
assignments to the location. This facility is not enabled at this time, but
would allow automatic roll-over of the link to the cost center record valid for
the actual time slot. Currently, a reassignment is required, after cost center
period-end has occurred.

/LQNWR3URILW&HQWHU
With the incorporation of the controlling area as a profit center differentiator /LQNWR3URILW&HQWHU
in
R/3 3.0D and later, the definition of the link from the business location to
the EC-PCA profit center master data object is similar to the link to the CO
cost center described above. The profit center is used to depict the business
location typically as a strategic business unit within the organization. As of
the current release, the link is specified on three levels:
q Controlling area
q Profit center ID
q Valid-to date
the cost center is modelled.
)LJ )RUHDFKEXVLQHVVORFDWLRQIRUZKLFKDOLQNWRSURILWFHQWHULVHQDEOHGLWLV
SRVVLEOHWRGHILQHRQHFRPELQDWLRQRIFRQWUROOLQJDUHDDQGSURILWFHQWHU
DVVLJQPHQWLQWLPH
As with cost centers, the capability exists in the underlying architecture of
the business location maintenance dialog for the handling of non-time-
dependent profit center assignments to the location. This function is not
enabled at this time, but would allow automatic roll-over of the link to the
profit center record valid for the actual time slot. Currently, a reassignment
is required, after profit center period-end rollover has taken place.

/LQNWR$VVHW
/LQNWR$VVHW A link is provided from the business location to either the FI-AA asset
master data object or the FI-AA group asset object. The link supports the
identification of one or more assets which together define the asset value of
the business location. As of the current release, the link is specified on three
levels:
q Asset main number
q Asset sub-number
q Company code
the asset master is modelled.
)LJ )RUHDFKEXVLQHVVORFDWLRQIRUZKLFKDOLQNWRDPDLQRUJURXSDVVHWLV
HQDEOHGLWLVSRVVLEOHWRGHILQHRQHFRPELQDWLRQRIFRPSDQ\DVVHWDQG
VXEDVVHW
The capability exists in the underlying architecture of the business location
maintenance dialog for the handling of multiple asset assignments to the
location, should this be necessary. This function is not enabled at this time,
because by using a group asset for the location to asset assignment, a flexible
solution is provided to the requirement for multiple asset allocation to a
particular business location. Again, it should be understood that MRN is a
virtual application and therefore asset management functionality is provided
only by the FI-AA application, not by MRN.
The MRN dialog is able to determine if the asset number entered is a main-
/sub-asset number or a group asset. If a group asset is assigned to the
business location, this is indicated by a checkbox in the Asset Assignment
screen box.

/LQNWR)XQFWLRQDO/RFDWLRQ
A link is provided from the business location to the PM Functional Location /LQNWR)XQFWLRQDO/RFDWLRQ
master data object. In this way the maintenance status of the business
location can be determined. As of the current release, the link is specified on
top level functional location ID only.
the functional location is modelled.
)LJ )RUHDFKEXVLQHVVORFDWLRQIRUZKLFKDOLQNWRDIXQFWLRQDOORFDWLRQLVHQDEOHG
LWLVSRVVLEOHWRGHILQHRQHIXQFWLRQDOORFDWLRQDVVLJQPHQW
The capability exists in the underlying architecture of the business location
maintenance dialog for the handling of multiple functional location
assignments to the location, should this be necessary. This facility is not
enabled at this time, because by optimal structuring of the functional
location code using the structure indicator, it is possible to model the
breakdown of a business location functional location within the PM system.
This provides a flexible solution to the requirement for multiple functional
location allocation to a specific business location. It is important that plant
maintenance functionality is provided only by the PM application, not by
the MRN virtual application.

/LQNWR3ODQW
/LQNWR3ODQW A link is provided from the business location to the plant object for reference
purposes in connection with inventory management processes.
the plant is modelled.
)LJ )RUHDFKEXVLQHVVORFDWLRQIRUZKLFKDOLQNWRDSODQWLVHQDEOHGLWLVSRVVLEOH
WRGHILQHRQHSODQWDVVLJQPHQW
As of the current design release, multiple plant assignments for a specific
business location are not supported.
Note that it is also possible to define a link between the business location
and a storage location for inventory managment purposes. This is because it
may be appropriate to evaluate business location inventory at storage
location level rather than plant level. It is not envisioned that both object link
assignments will be definable at the same time for a business location of a
given location type.

/LQNWR6WRUDJH/RFDWLRQ
A link is provided from the business location to the storage location object /LQNWR6WRUDJH/RFDWLRQ
for reference in connection with inventory management processes.
the storage location is modelled.
)LJ )RUHDFKEXVLQHVVORFDWLRQIRUZKLFKDOLQNWRDVWRUDJHORFDWLRQLVHQDEOHG
LWLVSRVVLEOHWRGHILQHRQHVWRUDJHORFDWLRQDVVLJQPHQW
As of the current design release, multiple storage location assignments for a
specific business location are not supported.
Note that it is also possible to define a link between the business location
and a plant for inventory managment purposes. This is because it may be
appropriate to evaluate business location inventory at plant level rather than
at storage location level. It is not envisioned that both object link
assignments will be definable at the same time for a business location of a
given location type.
/LQNWR3URMHFWV:%6V
A link is provided from the business location to one or more PS project /LQNWR3URMHFWV:%6V
definition records and/or project Work Breakdown Structures (WBSs). In
this way, the status of any number of projects active at the business location,
e.g. sales floor refurbishment, can be determined. As of the current release,
for project definitions the link is specified on project definition ID; for a
specific project WBS, the link is specified on a combination of project
definition ID and WBS ID. In the second case, the user need enter only the

WBS ID, the system determines the appropriate project definition ID and
populates the project definition ID field accordingly.
the project definition/WBS combination is modelled.
)LJ )RUHDFKEXVLQHVVORFDWLRQIRUZKLFKDOLQNWRSURMHFWVDQGRU:%6VLV
HQDEOHGLWLVSRVVLEOHWRGHILQHPDQ\SURMHFW:%6DVVLJQPHQWV
The user may wish to use one standard project definition to handle similar
activities which take place at all business locations. In this case, each location
will have its own WBS defined within that standard project definition. For
example, an organization maintains an open project for roof refurbishment.
For each explicit roof refurbishment activity at a business location, it can
define one WBS.
Alternatively, the user may wish to define a project definition for each
business location under which each discrete business activity is managed via
WBSs.
/LQNWR&22UGHUV
/LQNWR&22UGHUV Where a CO order has been created to capture overhead postings for a
specific business location, a link can be made between the MRN business
location and that order.
A link can be defined from the business location to one or more CO orders,
and only the CO order number is entered.

the CO order is modelled.
)LJ )RUHDFKEXVLQHVVORFDWLRQIRUZKLFKDOLQNWR&2RUGHUVLVHQDEOHG
LWLVSRVVLEOHWRGHILQHPDQ\&2RUGHUDVVLJQPHQWV
The user may wish to use one CO order to handle action-oriented planning,
as well as monitoring and allocation of costs. Alternatively, different
operational areas within the business location could be handled using
different CO orders.
/RFDWLRQ3DUWQHU5ROHV
The MRN location partner role module records data about the type and /RFDWLRQ3DUWQHU5ROHV
status of relationships that exist between business partners of the system
owning organization (system client) and the business locations (or business
entities) in which that organization has an interest. This information is
provided to support administrative procedures, direct links to transactions
accessing data about business partners and the provision of a mechanism to
facilitate recognition of the business location by reporting tools which exist
in the standard R/3 System.
The design of the location partner role module is intended to recognize the
varied relationships which exist in location networks. In particular, it takes
into account the multiple involvement of business partners, which can occur
at a single business location.
The MRN Location Partner Role data model graphic below shows the way in
which the multiple relationships between business partners and business
locations are depicted and characterized. The model also illustrates the

overall arrangement of technical objects required to support this MRN

functionality in the R/3 System.
)LJ 6$36(50LOOXVWUDWLQJWKHUHODWLRQVKLSEHWZHHQGDWDHQWLWLHV
LQWKH051EXVLQHVVSDUWQHUUROHVDSSOLFDWLRQDUHD
In the figure, the business location (or business entity) can be seen in the
lower left-hand corner, while the object depicting the “partner role”
assignment between business location and business partner can be seen in
the lower right-hand corner.
The partner role assignment has an aggregated dependency on the business
location and partner role. This means that the business location record and
the partner role entry must exist before the partner role assignment can be
created.
The partner role assignment has a referential dependency on the business
partner record. The partner role assignment is shown as a time-dependent
object, because it describes a specific period of time; this means, in effect,
that a partner role assignment is only “valid” for a specific period of time.
The top half of the diagram shows the business partner object and the
different kinds of subtyping for that object. The first major subtype
distinction is between the business partner as debitor object and business
partner as creditor object. Each of these subtypes is broken down into
second level subtypes. The debitor/customer types of fuels agent, C-store
agent and service customer, and the creditor/vendor types of leasor and
maintenance supplier are illustrated in the diagram.

A reference is shown between the debitor/creditor subtypes and the

location partner role technical category object. This is because the partner
role technical category specifies the object type used within the MRN
scheme (and generally) to distinguish between debitor and creditor objects.
The way to resolve these multiple relationships is through the use of a set of
tables in which the relation between the business location and the business
partner who is active at the business location is recorded.
The tables record the characteristics that make up the relation between a
business location and a business partner in some unique way. The location
partner role design classifies these characteristics in the following way:
q Technical characteristics - used to classify the role according to technical
requirements of the system; for example, the database table used to
record information about a particular type of business partner (necessary
because different database tables are used in the R/3 System to depict
business partners)
q Functional characteristics - used to classify the role according to the
functional requirements of the system; for example, the role of the
business partner
q Time characteristics - used to define the validity of the role according to
date and time (timestamp)
3DUWQHU5ROH7\SHV
The MRN location partner role type is used to classify the activity of a 3DUWQHU5ROH7\SHV
business partner of the company with respect to the business location.
The location partner role type is a four-character code which is freely
configurable by the user installation by means of the MRN IMG. Before it is
available for uses, the location partner role must be assigned to at least one
partner role technical category (see below). The technical category identifies
what kind of business partners can be assigned to a particular role.
One business partner may perform a number of different MRN partner roles at
a specific business location or the same role at a number of different locations or
a combination of these. This arrangement is shown schematically in the diagram
below.
)LJ (DFKEXVLQHVVORFDWLRQPD\VXSSRUWWKHDFWLYLWLHVRIDQXPEHURIEXVLQHVV
SDUWQHUVVRPHRIZKLFKLQWXUQZLOOEHDFWLYHDWPRUHWKDQRQHEXVLQHVVORFDWLRQ

Business events concerned with the business partner are recorded in the R/3
System in the normal way using established processes in the logistics and
financial modules. The location partner role may support the generation of a
link to the business partner identified by each role assignment. In this case
the partner specific business events may also be used to report on the
location.
3DUWQHU5ROH7HFKQLFDO&DWHJRULHV
3DUWQHU5ROH7HFKQLFDO The partner role technical category is the medium used to establish the rules
&DWHJRULHV by which a business partner object can be validated by the system.
It is possible to define the technical categories to be used to identify a specific
type of business partner within the R/3 System by means of a configuration
step in the MRN IMG. Each technical category provides the possibility of
defining up to three process determining technical characteristics.
The primary technical characteristic of the business partner is the name of
the database table containing the business partner. A basic distinction is
therefore made between business partners defined in the KNA1 table, which
are customers, and those defined in the LFA1 table, which are vendors.
The secondary technical characteristic of the business partner is the account
group. The customer and vendor account groups are used to determine the
processing associated with customer and vendor objects, respectively,
within the system. The customer account group in particular may define the
processing associated with a customer object in a way which is of central
importance to the business location reporting model.
The third technical characteristic of the business partner is only relevant to
customer business partners. This is the SD partner function. In cases where
the customer account group alone is not sufficient to identify the functions
of a business partner, it is necessary to define the self-referencing partner
function that a partner must carry in order to meet the requirements of the
partner role technical category.
/RFDWLRQ3DUWQHU5ROH0DLQWHQDQFH
/RFDWLRQ3DUWQHU5ROH The Location Partner Role maintenance screen sequence provides the user
0DLQWHQDQFH with an effective tool to create, change, display and list location partner role
assignments for any given location.
The “entry” screen to location partner role functionality is a dialog within
the MRN business location maintenance transaction. Within that dialog, the
Location Partner Role listing screen is always the first screen to be presented
to the user.
The user can create a new location partner role assignment from the listing
screen by calling the “Create business partner role” function. This function is
available in create and change modes of the business location maintenance
dialog.
The user can change any existing location partner role assignment from the
listing screen by calling the “Change business partner role” function. This

function is also available in create and change modes of the business location
maintenance dialog. The partner role assignment detail screen will be
presented in local change mode.
The user can display an existing business partner role entry from the listing
screen by calling the “Display business partner role” function. This function
is available in all modes of the maintenance dialog.
The partner role assignment listing screen is the access point to all
maintenance processing for partner role assignments for a specific business
location.
The standard location detail header sub-screen is displayed in all business
location maintenance dialog screens as a standard screen header, giving the
ID, name and type of the business location being maintained.
The partner role assignment listing is presented in one of three list modes:
q Active - showing only roles active for the current or specified time
q All - showing all role assignments for the location
q Selection - showing roles active within a specified period
Each list mode uses a different selection control subscreen, which are shown
below. The list mode can be changed by direct overtyping, selection using
<F4> or by using a pushbutton on the toolbar.
The location partner role assignment detail screen contains a subscreen
which is set according to the primary technical characteristic specified by the
partner role technical category entered.
For example, if the business partner is identified as a customer partner (i.e.
primary technical characteristic = “KNA1”) the sub-screen will contain
customer name, account group, the general address and other details. The
following BPR detail sub-screens are provided in the current release:
&RQILJXUDEOH3DUWQHU1DYLJDWLRQ
A configurable navigation tool is provided in connection with the business &RQILJXUDEOH3DUWQHU
partner role assignments, which can be defined within the business location 1DYLJDWLRQ
maintenance transaction. The tool enables user installations to specify the
dialog transactions to which the system will provide links when the navigate
function is used.
The range of dialog transactions to which links are supported are customizable
using a step in the MRN IMG. It is possible to define the permissible range of
dialog transactions to which links can be supported for partner role technical
category, using this customizing function.

Additionally, for each “partner role technical category/dialog transaction”

combination it will be possible to:
q Optionally specify a short text to describe the link (if no entry is made
the target dialog transaction text will be defaulted from TSTCT)
q Indicate which SET/GET parameters will be activated for each transaction
link
q Indicate if the transaction is to be called with/without “skip first screen”
The processing works in a similar way to that provided for the configurable
object link navigation. As with that processing, if no entry is made in the
IMG for the dialog control of a particular link object, the system calls a
default dialog. Normally, this will be the display master data dialog
transaction for the type of partner identified by the partner role technical
category.
/RFDWLRQ(QWU\*HQHUDWLRQ
/RFDWLRQ(QWU\*HQHUDWLRQ In order to support business location reporting via business partner activity,
it is necessary to write the business location ID to the business partner
master record of the business partner which has been linked to the location.
The generation of the location ID in the business partner master data record
is achieved through the use of a function which is initiated from within the
business location maintenance transaction. This function is triggered
whenever the system detects a partner role assignment with a „technical
category“ which has been specified as a location category in Customizing.
/RFDWLRQ5HSRUWLQJ
/RFDWLRQ5HSRUWLQJ When links have been established between the business location and other
objects or business partners in the system, it is possible to populate statistical
information structures with performance data which is specific to individual
locations.
A new information structure is provided within the Sales Information
System (SIS) to record sales activity at the location level.
/LQNVWR6,6
/LQNVWR6,6 A link to the Sales Information System is provided to support sales reporting
by location as opposed to the standard reporting via ordering party. The link
is dependent on the generation of the business location ID in a valid
business partner with reference to which a sales document is created.
The ID of the business location associated with the “Ship-to” party specified
in the sales document is carried in the “Ship-to” partner function segment at
header or line item level.
This information is made available to the LIS entry point in the form of both
changed and original data. The MRN business location ID is thus available
at line item level as both the original assignment for the line item and the

new assignment. To enable the user to confirm the allocation of the MRN
business location, a subscreen is provided in the sales document business
data screen. A subscreen is used to minimize the impact of the modification.
If an installation does not use MRN, no business location information will
appear on this screen.
Various additional move lines are added to sales document processing to
copy the business location ID to the correct transfer structures.
/LQNVWR&23$
Reporting of business location profitability is enabled by the availability of /LQNVWR&23$
the business location and location partner role as fixed characteristics in the
Controlling-Profitability Analysis reporting tool (CO-PA).
With these new fixed characteristics, it is possible to define both location and
location partner role fields in an operating concern reporting structure. From
structures in which both location and location partner role data is summa-
rized, it is possible to generate reports about location or partner role
profitability segments or combinations of these.
*ORVVDU\
%XVLQHVV/RFDWLRQ
A master data object in the IS-Oil System. The business location is a physical
location which cannot change in space or time, about which the process
owning organization would like to record information. The business location
roughly equates to a physical address. The location is not transferrable with
respect to physical address in normal circumstances.
%XVLQHVV/RFDWLRQ7\SH
Normally, the basic business purpose of a business location. The business
location type allows the process-owning organisation to categorize the
business location for operational and technical purposes.
2EMHFW/LQN
The only example of a connection between the business location and another
business object in the R/3 System which is used to depict the location in
terms of a specific or set of specific business processes.

3DUWQHU5ROH
The role or function in an IS-Oil system which a business partner performs
with respect to a specific business location. This is in contrast to an SD or FI
“partner function”, which defines the function of the business partner with
respect to the process-owning organization. One business partner may
perform a number of business partner roles with respect to the same
location.
The business partner role must be assigned to one or more partner role
technical categories in order to be usable.
3DUWQHU5ROH7HFKQLFDO$VVLJQPHQW
The single instance of a specific partner role at a particular business location
for a specified period of time.
3DUWQHU5ROH7HFKQLFDO&DWHJRU\
The underlying technical specification of the partner role in an IS-Oil system.
In effect, the partner role technical category allows the process-owning
organization to define types of business partner in terms of business partner
account group and, where applicable, SD partner function.
The types of business partner thus defined can then act as the basis for rules
governing the validation of business partner links when creating a partner
role assignment.
The business partner role technical category may support integration with
R/3 processes such as sales order processing and LIS, or it may be purely
informational.
9LUWXDO$SSOLFDWLRQ
An application which has no functionality of its own, but which provides an
optimized business view of existing functionality within a system.

&KDSWHU
7UDQVSRUWDQG'LVWULEXWLRQ7'
+LJK/HYHO6XPPDU\
The Transport and Distribution (TD) application area supports requirements
specific to distribution in the downstream oil business with enhancements
made to Core SAP R/3 functions. The TD functional enhancements support
the following business processes associated with downstream oil distribution:
q Definition of the means of transport (vehicle) to be used in distribution
q Processes to control the delivery of oil products (scheduling, load
confirmation and delivery confirmation)
q Processes to control the transfer of product between two company-
owned locations
q Transport of purchased product from vendor
q Change of stock ownership in line with oil industry practice
q Shipment cost calculation
q Integration with other IS-Oil Downstream application areas (HPM, TDP,
Exchanges) during the TD process
)XQFWLRQ2YHUYLHZDQG2EMHFWLYHV
The TD application area provides functions to support three separate shipment
processes - scheduling, loading confirmation, and delivery confirmation. The
following oil distribution requirements are carried out across these processes:
q Scheduling of shipments on specified vehicles based on underlying
documents
q Confirmation of the actual quantity loaded on the vehicle
q Confirmation of the actual delivered quantity
q Tracking of product during transport to customers

7UDQVSRUWDQG'LVWULEXWLRQ7'DVSDUWRI,62LO'RZQVWUHDP
Underlying documents (shipping notifications, reservations, or deliveries)

form the basis of any TD shipment across the TD shipment processes.
Schematically, the function flow looks as shown in the figure 6-1.
500,62LO 56',62LO
3XUFKDVH2UGHU 7UDQVIHU 6DOHV2UGHU

3URFHVVLQJ 3URFHVVLQJ 3URFHVVLQJ
6KLSSLQJ 5HVHUYDWLRQ 'HOLYHU\

1RWLILFDWLRQ
6FKHGXOLQJ
/RDGLQJ&RQILUPDWLRQ
'HOLYHU\&RQILUPDWLRQ
*RRGV 7UDQVIHU *RRGV

5HFHLSW ,VVXH
7'
)LJ7UDQVSRUWDQG'LVWULEXWLRQ'RFXPHQW)ORZ
.H\)XQFWLRQ%HQHILWV
,PSURYHG&XVWRPHU6HUYLFH The integration of TD with the Core SAP R/3 System enables an oil
company to manage shipments in a timely and accurate manner. TD
provides for the accurate processing and tracking of high volumes of orders
and bulk shipments.
,PSURYHG(IILFLHQF\WKURXJK The scheduling, loading confirmation, and delivery confirmation transactions
$XWRPDWLRQDQG,QWHJUDWLRQRI provide a consistent framework for processing and tracking high volumes of
.H\)XQFWLRQV bulk material shipments. These three transactions are suited for the frequent
changes that occur in the bulk oil distribution business.
,PSURYHG,QYHQWRU\ The scheduling, loading confirmation, and delivery confirmation transactions
0DQDJHPHQW were designed to interface with automated systems such as, “Dispatch
Optimizers“ and “Automated Loading Systems“.

Through the use of an “intransit storage location or intransit plant“ it is

possible to closely track stock quantities in the distribution process. In-
transit quantities are counted once by the system, without the necessity of
manual reconciliation.
The TD application area uses compartment planning to provide better ,PSURYHG(IILFLHQF\LQ
support for the administration of oil products that are being transported. 6FKHGXOLQJ6KLSPHQWV
Through the use of shift and trip functions the TD application area provides
a more detailed scheduling of shipments.
Through integration with the equipment master record from the Plant ,PSURYHG'DWD,QWHJUDWLRQ
Maintenance component, it is possible to link many of the master data
entities such as, vehicles and transport units to equipment master records.
The equipment master record can be used both for maintenance planning
and execution.
,62LO'RZQVWUHDP7'&RPSRQHQW
The following TD functions are provided within the R/3 IS-Oil Downstream
component:
0HDQVRI7UDQVSRUW
The TD application area provides functions to define a means of transport
(vehicle) as master data. These master data definitions enable the following:
q Matching the product with vehicle characteristics
q Matching the customer with vehicle characteristics
q Checking the availability of the vehicle
q Checking for overloading of the vehicle
TD provides functions to define the following as master data:
q Vehicles
q Transport units and compartments
q Drivers
q Vehicle meters
q Rack meters
q Compatibilities

%XON6KLSPHQW7\SH
The bulk shipment type contains settings used by TD to determine how a
shipment is processed. A bulk shipment type must be selected when
scheduling a shipment, and cannot be changed once a shipment has been
saved. The following functions are enabled by the bulk shipment type:
q Vehicle mode of transport: When assigning a vehicle to a shipment, the
vehicle mode within the bulk shipment type is checked against the
vehicle mode of transport defined in the vehicle type. If the two are
different, for example the shipment type requires a truck and the
scheduler attempts to schedule a train, the system rejects the assignment.
q Compartment load indicator: During scheduling it is possible to
combine deliveries and materials for the same compartment. The
compartment load indicator in the bulk shipment type determines
whether the compartment is to accept only one material of one
document, or combinations of documents with the same material or
multiple materials.
q Intransit Posting Group: The intransit posting group determines how
excise duty is processed for a product during shipment. It is also used to
determine which intransit storage location is used to hold the intransit
stock. The intransit posting group determines the valuation types and
handling types used in material movements triggered by TD.
q Confirm balance load indicator: The Confirm balance load indicator
determines how balance loading is carried out. Balance loading is the
process of assigning discharge documents to loaded quantities. It is
particularly relevant when the actual loaded quantity is different from
the scheduled quantity. The balance load indicator determines if and
how discharge quantities are processed.
q Partial Delivery Confirmation: This function is used during the delivery
confirmation transaction. When selected, the system posts a goods issue
against deliveries for which discharge quantities have been recorded.
This allows inventory to be updated after the first delivery is discharged
without requiring all discharge quantities to be recorded.
q Shipment Cost Relevance: It is possible to specify the scope of the
shipment cost calculation through a series of parameters defined in the
bulk shipment type.
q Exchange assignment: Exchange asssignment data entered in the bulk
shipment type determines how exchange-relevant deliveries are processed.
6FKHGXOLQJ7UDQVDFWLRQ
A transaction is provided to schedule underlying documents (shipping
notifications, reservations, or deliveries) into shipments of bulk products.
The scheduling process supports the assignment of specific vehicles to
shipments.

During the scheduling process the following information is necessary:

q Date of the shipment
q Vehicle used for the shipment
q Compartment into which product is scheduled
/RDGLQJ&RQILUPDWLRQ7UDQVDFWLRQ
A transaction is provided to support the loading activity. The oil industry
requires the flexibility to determine the actual quantity loaded, and the plant
and store location from which the product is loaded. It is common for the
actual quantity loaded to change from the quantity originally scheduled. The
system allows loading from different plants in one shipment.
The loading transaction provides the capability to control and manage the
following:
q Loading date and time
q Actual quantity of product loaded
q Store location and batch from which the product is loaded
q Compartment into which product is loaded
(if compartment planning is used)
q Unplanned rebranding of the product, that is, shipping a replacement
product
q Assignment of quantities left on the vehicle from a previous shipment.
q Loading of the components of a sales material (Bill of Material) and the
posting of sales material
It is possible that the quantity of product delivered deviates from what was
loaded. It may also occur that planned shipments do not take place (for
example when there is insufficient tank capacity at the receiving station). In
such a case, the product is either returned on the truck or is delivered to
another customer. The delivery confirmation transaction enables the user to
reflect these unplanned changes in the delivery, as well as, confirm the
actual quantity of product that is delivered to the customer.
The following activities are supported by the delivery confirmation
transaction:
q Specifying delivery date and time
q Establishing actual quantity shipped
q Handling non-delivered product - either to be returned to the plant or
left on the vehicle
q Handling of gains and losses during transport
q Changing the shipment in order to handle unplanned deliveries
q Flexible status handling to allow changes between processes

2UJDQL]DWLRQ6WUXFWXUHRIWKH7'&RPSRQHQW
The organization structure for the transportation function is shown below:
)LJ&RPSDQ\6WUXFWXUHZLWK6HSDUDWH,QWUDQVLW6WRUDJH/RFDWLRQV
3ODQW
In the case of deliveries, the delivering plant must be entered in the sales
order. This is used to define the shipping point which is required before the
delivery can be created. In the case of a shipping notification, the receiving
plant must be entered in the purchase order. For a reservation a supplying
and receiving plant is entered.
7UDQVSRUW3ODQQLQJ3RLQW
This is the organizational entity used to plan transportation functions. The
transport planning point represents a group of employees responsible for
planning transportation. A transport planning point can cover one or many
shipping points. In fact, transportation planning points are independent
units and are not related to the other organisational units in Logistics.
,QWUDQVLW6WRUDJH/RFDWLRQ
A major function of TD is to keep track of bulk products in respect to both
quantity and value. For the oil industry a special storage location is required
to track product as it is transported.
,QWUDQVLW6WRUDJH/RFDWLRQLQWKH6DOHV&\FOH
In the standard document flow for sale of product in the Sales and
Distribution (SD) module, the products change ownership from the
delivering company to the customer when they are goods issued at the end
of the delivery process. Goods issue is the point when the goods leave the
company’s site. In such a case, the customer takes ownership of the stock as
soon as it leaves the delivering plant on execution of the goods issue.

In order to track the stock at the point it leaves the delivering plant, and
prior to arrival at the customer, TD introduces the concept of the intransit
storage location. The product(s) remain on the delivering company’s books
until delivery is confirmed at the customer. This is achieved in TD by the
delivery confirmation process triggering the core goods issue process. In this
case, a transfer is used to move the stock from the delivering plant to the
vehicle during load confirmation. The stock loaded on the vehicle then exists
in the intransit storage location. This can be viewed in the Stock Overview
report.
When the products are loaded on the vehicle they are moved from a normal
stock location to an in-transit store location, with a store-to-store movement.
Similarly, when the products are delivered to the customer a goods issue is
posted from the in-transit store location to the customer. To achieve this the
original delivery document is updated with the intransit storage location in
the delivery confirmation process before the goods issue is posted. Every
transaction in the TD area which includes a goods movement associated
with the vehicle (or change of responsibility in case of returns to another
plant, for example) causes a quantity update to the intransit storage location.
,QWUDQVLW6WRUDJH/RFDWLRQLQWKH3XUFKDVLQJ&\FOH
In the standard Purchasing process for the Material Management (MM)

module, a purchase order is created, after which a shipping notification can
be created to control the shipment of the goods. When the goods are
received, a goods receipt is posted in the receiving plant.
With TD, the goods receipt is posted in the intransit storage location which
represents the stock of the vehicle that is loaded. The stock remains in the
intransit storage location until a transfer to the actual receiving plant is
initiated during the delivery confirmation process.
,QWUDQVLW3ODQW
When shipping large quantities of product of long distances, such as
pipeline and marine shipments, it can be necessary to maintain a segregated
overview of the intransit stock. In the TD application area this can be
accomplished by representing the vehicle as a separate plant, known as an
intransit plant. It is possible to allocate all vehicles (for example, barges) to a
single intransit plant, or alternatively, to set up a separate intransit plant for
each vehicle (for example, pipeline).
The intransit plant can consist of multiple storage locations for product
tracking purposes as the product moves along the route. The allocation of
the intransit plant is specified in the underlying documents that are assigned
to the shipment.

9HKLFOHVDQG5HODWHG0DVWHU'DWD
A vehicle is a key entity in the transportation of goods. Within TD a vehicle
is defined as master data. This is done for the following reasons:
q Each vehicle is unique and is made up of a fixed number of transport
units
q Each transport unit is unique and is made up of a fixed number of
compartments
q Each compartment is unique and can be used as an intransit storage
location during shipment
Although the following figure shows a truck as a means of transport, TD
supports all of the following means of transport:
q Trucks (Road transport)
q Trains (Rail transport)
q Ships (Sea transport)
q Barges (Inland water transport)
q Pipelines
The figure below shows the possible composition of a vehicle, in this case a
truck with two trailers.
)LJ([DPSOHRID9HKLFOH6WUXFWXUH
The vehicle master data is created through a three layer hierarchy. The
layers of master data are:
q Vehicle
The highest level for a means of transport is a vehicle. The complete
vehicle is defined in vehicle master data. A transaction is provided to
support the creation, change, and display of vehicle master data.

q Transport unit
A vehicle is made up of at least one transport unit. In the example shown
in the figure, the transport units would be the mover and the two
trailers. As with the vehicle master data, a transaction is provided to
support the creation, change, and display of transport unit master data.
There is a one to many relationship between the vehicle and the
transport units . For example a train can be defined with one tractor and
many rail wagons. There is also a one to many relationship between
transport unit and vehicles, where a transport unit can be assigned to
several vehicles.
Validation checks ensure that a transport unit is not concurrently
scheduled to more than one vehicle in the same shipment.
q Compartment
A transport unit consists of one or many compartments. A compartment
is a fixed part of the transport unit. The same transaction used to create a
transport unit is also used to create the compartments for the transport
unit.
Since vehicle and transport unit are considered generic terms and there
is no limitation on the number of transport units in one vehicle, the
master data can be used to define many forms of transportation (for
example rail, marine, pipeline). The following paragraphs provide
further details on the fucntions supported at the master data level.
9HKLFOH
A vehicle is a collection of one or more transport units. Vehicle master data
has a header with information stored on the vehicle level and the transport
units assigned to the vehicle. Transport units are assigned to the vehicle as
vehicle items. The vehicle header has the following data:
q Vehicle identification: The vehicle code is used throughout the system
to refer to the vehicle. The numbering of vehicles can either be externally
or internally based. The vehicle master data is additionally supported by
matchcode search strategies.
q Vehicle type: A vehicle type is used to define the basic characteristics of
the vehicle. The type can be used to define whether the vehicle is used
for road, rail, marine (sea or inland), or pipeline transportation. The
vehicle type also defines what the units of measure are for volume and
weight.
q Vehicle compatibility: A vehicle can be allocated to a compatibility
group, which has been created previously with certain characteristics.
The compatibility definition is checked during Scheduling to determine
whether the selected vehicle meets the customer requirements specified
in the customer master data.

q License type and number: The license requirements for a vehicle are
defined through the assignment of license types. Possible license types
are defined in a separate table. When creating a vehicle, a license type is
selected to determine the requirements for the vehicle. A license number
is entered for a vehicle in the vehicle master data.
q Transport unit number: identifies the transport units assigned to a
vehicle.
q Carrier: Represents an external vendor responsible for the vehicle. A
carrier is created as a vendor in Purchasing (MM) and can be used for
shipment costing.
q Route: The route can be used to define various points along which the
shipment is transported. If the route is created in the vehicle master data
record, then it is defaulted into the shipment using that vehicle.
q Status: The status controls whether the vehicle can be selected during
scheduling.
The vehicle master data is represented in the figure below:
)LJ9HKLFOH0DVWHU'DWD6WUXFWXUH
7UDQVSRUW8QLW
As stated previously, a vehicle consists of at least one transport unit. The
transport unit id’s must be individually assigned to the vehicle in the vehicle
master data. The master data for each transport unit must therefore exist
before being assigned to a vehicle.
A transport unit is an independent entity forming part of a vehicle. It can be
individually described as a means of transport. Examples of a transport unit
are:
q Truck trailer
q Train tractor
q Train wagon

q Barge
q Pipeline
The figure below shows how the master data for a transport unit is structured.
)LJ7UDQVSRUW8QLW0DVWHU'DWD6WUXFWXUH
The transport unit master data includes the following:
q Transport unit number: The transport unit number is the unique
identifier for a transport unit. The number is freely definable by the user.
The user can also use internal number ranges generated by the system.
q Transport unit type: A transport unit type is used to define the basic
characteristics of the transport unit. The type can be used to define
whether the transport unit is used for road, rail, marine (sea or inland) or
pipeline transportation. The transport unit type also determines whether
the transport unit is a mover such as a train locomotive, or a trailer.
q Dimensions of the unit and unladen and maximum weight.
q Availability checking of the unit. The status of the transport unit can be
either available, not available, or marked for deletion. For example, the
transport unit status can be set to unavailable when the transport unit is
being serviced or temporarily out of service. A status of marked for
deletion means the transport unit should no longer be used for future
shipments and will be deleted from the system when the next
reorganization program is run (provided there are no active shipments
using that transport unit).
q Meters per transport unit: Metered transport units (for example trailers)
use meter readings to determine the unloaded quantity. In order to use
the meter readings of a transport unit, the meters are defined in the
system as master data. The predefined meters are assigned to one
transport unit.

q Compartments: A transport unit can consist of as many compartments

as necessary. It is mandatory to define at least one compartment for a
transport unit. A compartment is the lowest level in the definition of a
means of transport. Information about the quantities of material carried
on the vehicle is stored at the compartment level. The following data is
linked to compartments:
m Minimum/Maximum volume: The system allows the definition of
the minimum and maximum volume that a compartment can store.
The unit of measure used is defined at a transport unit level. The
maximum weight and volume are checked during the scheduling
transaction. Whenever the dispatcher overloads a compartment with
a particular product, the system issues an error message.
m Product compatibility: A compatibility group can be defined for
each compartment. Various characteristics are selected for each
compatibility group from a list defined in customizing. During
scheduling, the system checks that the product to be loaded into the
compartment is compatible with that compartment by checking that
the characteristics correspond.
)LJ9HKLFOH6WUXFWXUH6XPPDU\
5DFNDQG9HKLFOH0HWHUV
TD supports two types of meters: rack meters and vehicle meters. Rack
meters are defined as master data and are tied to a plant and store location.
The store location assignment can be changed. Vehicle meters are defined as
part of the vehicle master data. The meters can be used during loading
confirmation and delivery confirmation. By entering the meter readings, the
loaded and unloaded quantity is recorded. If TD is interfaced to a Terminal
Automation System or in-cab computer system, the meter readings can be
captured automatically.
If such systems are not in use, the meter readings can be manually entered.
To provide an audit trail of meter readings, a meter reading reconciliation
function is provided. The reconciliation report lists all material movements

that have passed through the meters during the specified time period.
Movements include the loading of vehicles, in addition to other incidentals,
such as flushings and meter recalibration. Each meter is listed with the
corresponding shipment number, and the start and end readings for each
movement. Meter adjustment factors can also be entered.
'ULYHUV
A driver is master data and is maintained through a separate transaction.
The driver table contains the following data:
q Driver number: Used to uniquely identify the driver in the system. The
driver code can use either externally or internally defined number
ranges. The driver master data is supported by matchcode search
strategies.
q Driver name
q Personnel number: An external personnel number can be entered, this is
not linked into the Core Human Resources Module of SAP R/3 System.
q License type: Can specify the types, identification and period the license
is valid for.
q Carrier: A driver can be assigned to an external carrier.
q Availability: The status of a driver specifies whether a driver is available
for assignment to a vehicle during scheduling.
.H\,62LO)XQFWLRQV6HUYHGE\(QKDQFHPHQWV
WRWKH&RUH56\VWHP
q Material Master
The Transportation view is available in the product master. In this view,
a product compatibility group can be defined. An error or warning
message is issued whenever a product is scheduled into a compartment
where the characteristics do not match. Whether an error or warning
message appears, is configured in Customizing.
q Customer Master
The transportation view is available for TD functions in the customer
master. In this view a vehicle compatibility group can be defined.
During scheduling an error or warning message is issued whenever a
vehicle does not match the required characteristics to carry out a
delivery to the customer. Whether an error or warning message appears,
is configured in Customizing.

3URFHVV)ORZ,Q7'
The TD process flow is based on the assignment of documents to shipments
during scheduling. The TD process flow supports inbound purchases,
outbound sales, and product transfers by integrating with the relevant R/3
process flows. The underlying documents that can be assigned to and
processed as bulk shipments are reservations, shipping notifications, and
deliveries.
The following figure shows the relationship of these documents to the bulk
shipment process and the relevant R/3 processes.
3XUFKDVLQJ 7UDQVIHU 6DOHV
3XUFKDVH2UGHU 6DOHV2UGHU
6KLSSLQJ1RWLI 5HVHUYDWLRQ 'HOLYHU\
7'%XON6KLSPHQW 7'%XON6KLSPHQW 7'%XON6KLSPHQW
*RRGV5HFLHSW 0DWHULDO7UDQVIHU *RRGV,VVXH
9HQGRU,QYRLFH &XVWRPHU,QYRLFH
)LJ7UDQVSRUWDQG'LVWULEXWLRQ3URFHVV)ORZ
A shipment moves from the scheduling process where the underlying
documents and vehicles are assigned to shipments, to the loading and
delivery confirmation processes. The shipment status determines if and
when a shipment can move from one TD process step to the next. During
loading, product is loaded onto vehicles from the schedules. During the
delivery confirmation process, the delivery of the shipment is recorded.
Within TD it is possible to change quantities during the scheduling, loading
and delivery confirmation processes. The scheduled quantity is proposed
during the loading step, but can be changed. Also, product left on the
vehicle from a previous shipment can be added to the current shipment
during loading. If at the delivery confirmation, the actual quantity shipped
differs from the underlying document, the underlying document is updated.

,QWHJUDWLRQ:LWK2WKHU,62LO'RZQVWUHDP&RPSRQHQWV
9ROXPHWULF&DOFXODWLRQVLQ+30+\GURFDUERQ3URGXFW0DQDJHPHQW
Oil product inventories are normally held at a standard temperature (for
example 15° Celcius or 60° Fahrenheit). In order to calculate these inventories
and movements at a standard temperature, it is necessary to know the
temperature and density, as well as the measured volume of the product. As a
single shipment is transported, the measured temperature and density may
change. The American Petroleum Institute (API) has published formulae and
programs to calculate volumes at standard or any temperature, based on
measured temperature and density. These programs are generically referred
to as the American Society for Testing Materials (ASTM) calculations. The
calculation of other units of measure is also supported. For instance, for
different purposes, a material might be measured in tons, pounds, 60° gallons
and 60° barrels. The material can be defined so that the system simultaneously
tracks a material’s movements and inventories in all these units of measure.
The HPM application area of R/3 IS-Oil Downstream supports the entry of
temperature in TD, and supports calculation of standard volumes using
input or default temperatures and densities. TD and HPM are integrated so
that TD seamlessly offers support for multiple units of measure within the
same transaction. Temperature and density are important to the loading and
delivery confirmation processes.
Scheduling
During the scheduling step, underlying documents are grouped together to
form shipments. Because only planned quantities are used at this stage, no
ASTM calculations are carried out in scheduling. If any changes to the
underlying document quantities are made during scheduling, then the
underlying documents are updated.
Loading Confirmation
During the loading confirmation step, the quantities actually loaded on the
vehicle can differ from the quantities in the underlying document and the
scheduled quantity. The loaded quantity per product is captured at loading
confirmation and assigned to the underlying documents. The updated
quantities are posted to the original document item. Entry of ASTM
parameters is supported during loading. These parameters are maintained at
the item level in the underlying document.
Delivery Confirmation
During the delivery confirmation step, the quantities actually delivered may
differ from the loaded quantities. The actual delivered quantity per product
is captured through the delivery confirmation transaction and posted to the
original document item. Entry of ASTM parameters is supported during
delivery confirmation as the temperature may have changed since the
vehicle was loaded.

7DULIIV'XWLHVDQG3HUPLWV
In the IS-Oil Downstream component, a valuation record and/or batch is used
to represent the tax status of a material. This is structured so that tax-relevant
materials are always batch controlled. Either, the batch management function
is used or ”dummy“ batches are used based on two types of valuation
records, “taxed“ or “untaxed“.
When goods are physically moved from one storage location to another
storage location or to a customer, the excise duty status can change. In TD a
vehicle is associated with an intransit storage location and thus can have a
different tax status than both the customer and the delivering stock location.
When a goods movement in TD results in a change of tax status, the
financial postings accompanying the goods movement take account of any
duty or tariff implications.
Store Location/Batch
It is a requirement for TD to be able to change the storage location and batch
up to the point of loading. The rescheduling function for storage location and
batch is supported in the loading confirmation transaction. When executing
the rescheduling function the new store location and batch number are
updated in the underlying document. For this to be possible, no batch number
should have been entered in the underying document when it was created.
([FKDQJHV
Using TD application area, it is possible to schedule deliveries in cases
where the product is supplied from or to an Exchange partner.
([FKDQJH/RDGLQJ%XVLQHVV6FHQDULR )XQFWLRQVZLWKLQ([FKDQJH/RDGLQJ
$VVLJQ([FKDQJH
32,WHPWR
([FKDQJH 'HOLYHU\,WHP
$JUHHPHQW
3XUFKDVH
&KDQJH'HOLYHU\,WHP
2LO&R &RQWUDFW 2LO&R 4XDQWLW\WR/RDGHG
,62LO8VHU ([J 3DUWQHU 4XDQWLW\
6DOHV
&RQWUDFW
&UHDWH*RRGV
*RRGV)ORZ 5HFLHSWDJDLQVW 2LO&R
3XUFKDVH&DOORII ([J 3DUWQHU
2LO&R
6DOHV2UGHU &XVWRPHU
,QYRLFH
&UHDWH*RRGV,VVXH
DJDLQVW 2LO&R
&XVWRPHU
'HOLYHU\QRWH

)LJ([FKDQJHV,QWHJUDWLRQ%XVLQHVV6FHQDULR

6FKHGXOLQJ
The main objectives of the scheduling function are as follows:
q Group underlying documents (deliveries, shipping notifications, or
reservations) into shipments
q Assign shipments to appropriate vehicles
q Allocate products and quantities to the vehicle compartments
q Optionally assign a drivers to the vehicles
q Change the quantity of product to be shipped
q Plan transport-related activities using the event handling function
The result of the scheduling process is one or more shipment documents.
Each shipment document is assigned a number and forms the basis for the
loading and delivery confirmation processes. After a shipment is confirmed,
the loading document can be printed.
The schedule that has been created is only a proposal for the loading process
and can be changed, for example, if it is discovered that there is not enough
product. An important result of the scheduling process is that the underlying
documents which have been assigned to a shipment are blocked so that they
cannot be simultaneously assigned to other shipments. The figure below
shows the place of scheduling in the TD process flow.
6FKHGXOLQJ /RDGLQJ 'HOLYHU\

FRQILUPDWLRQ FRQILUPDWLRQ
$VVLJQ /RDGYHKLFOHV 5HFRUG

'HOLYHULHV
6KLSSLQJ XQGHUO\LQJ IURP GHOLYHU\RI
QRWLILFDWLRQVRU GRFXPHQWVWR VFKHGXOHV VKLSPHQW
5HVHUYDWLRQV
YHKLFKOHV
The TD component of IS-Oil supports two options for scheduling. The first
approach involves an interface to a third party software product or “point
solution“, known as a dispatch optimizer. The second approach uses an IS-
Oil TD transaction to perform the scheduling tasks.
The process of scheduling a shipment requires that a vehicle and and
underlying document (delivery , shipping notification, or reservation) be
assigned to the shipment. Checks exist to ensure that deliveries, shipping
notifications, and reservations can be used for a shipment. These checks
ensure, for example, that they are not already in use by another shipment or
other system process.

9HKLFOH2YHUYLHZ
The vehicle overview is used during the scheduling process to assign one or
more vehicles to a shipment. When scheduling a vehicle, the system checks
the mode of transport against the vehicle mode defined for the bulk
shipment type. When assigning a vehicle the system prevents the same
transport unit from being assigned simultaneously to several vehicles.
After a vehicle has been assigned to a shipment, it is still possible to make
changes to the vehicle details. Within the shipment there is a view of the
vehicle master data where changes can be made to the vehicle information
such as, equipment, identifier, unladen and maximum weight for the
transport unit, and the compartment volumes. Changes made to vehicle data
from the shipment view are only valid for the shipment, and are not
reflected in the actual vehicle master data.
'RFXPHQW2YHUYLHZ
The document overview transaction is used during scheduling to assign the
underlying documents to a shipment. Each underlying document is
assigned exclusively to a shipment, meaning that the document is blocked
from use by other shipments and updates from other transactions. If known
the document numbers can be entered in the document overview.
Alternatively, a document selection report can be used to find documents to
assign. The document selection report generates a list of documents that
meet the specified selection criteria.
&RPSDUWPHQW3ODQQLQJ
After the underlying document and vehicles have been assigned to a
shipment, it is necessary to schedule how the product is to be loaded on the
vehicle. Product is assigned to the compartments of the vehicles assigned to
the shipment. If a vehicle, such as a pipeline, is defined with only one
compartment, the compartment planning is done automatically.
A number of checks are performed during compartment planning, including
the following:
q Product compatibility
q Customer compatibility
q Overloading of the compartment
These checks ensure that the compartment is appropriate to transport the
product, and that the vehicle has the correct characteristics to deliver to the
customer. The overloading check ensures that the product quantity does not
exceed the weight and volume capacity of the transport unit and
compartment.

6KLSPHQW2YHUYLHZ5HSRUW
The shipment overview report provides an up-to-date view of all movements
(both planned and actual) for a shipment. When a shipment is scheduled but
not yet loaded, all quantities in the shipment overview report are planned
quantities. No actual quantities are displayed at this stage. When a shipment
item is loaded, the actual quantity is updated to reflect the loaded quantity.
(YHQWV+DQGOLQJ
During scheduling events handling is available to maintain information on a
wide range of transport-related services such as, an inspection at loading or
cleaning services for a ship. Event default groups can be set up for the bulk
shipment type. Event default groups automatically propose event types and
event text that have been defined for the bulk shipment type. This could be
used to ensure, for example, that compartment cleaning is always proposed
for marine shipments.
It is possible to enter the document number of a document related to the
event such as, a service order. A link is then established to the document so
that it can be viewed directly from events handling.
6KLS1RWLIV
5HVHUYDWLRQV
'HOLYHULHV
9HKLFOHV
6FKHGXOLQJ
'ULYHUV
3URFHVV
6KLSPHQWV
(;*
&RVWV
)UHLJKW
&DOFXODWLRQ
)LJ2YHUYLHZ6FKHGXOLQJ6\VWHP
6KLSPHQW&UHDWLRQ
During the creation of a shipment, the following information is specified in
the shipment document:
q Transportation Planning Point
q Bulk Shipment Type

q Date of the shipment

q Vehicles
q Documents assigned to the shipment
Transportation Planning Point
The transportation planning point is a group of employees responsible for
the planning of transportation. It is an independent unit and is not related in
any way to any other organisational units in Logistics (i.e. plants, shipment
points etc ).
Bulk shipment Type
This is used to group the different types of shipments that can be created
and to define the basic parameters for processing them. Some of the
parameters that can be set via the bulk shipment type are:
q Allocation of shipment numbers
q Definition of mode of transport (vehicle, train, etc.)
q Whether balanced loading is required
q Units of measure of the shipment
q Compartment loading gives an indication of how products can be loaded
into compartments. As with product compatibility, the compartment load
IDs assist the dispatch department in planning the products for a vehicle,
that is assignment to compartments. Possible compartment load ID
indicators are:
1. One document item in a compartment
2. Multiple document items of one material in a compartment
3. Multiple materials per compartment (normally used for the case
where the whole vehicle is defined with one compartment and no
processing is done at a compartment level)
q What sort of compatibility checking should take place (this can occur
between products and compartments and customers and vehicles)
q Intransit posting group (which is used in the calculation of any duty or
tax implications when the product is moved through the TD processing
cycle)
q Exchange settings

Shipment Dates
Several dates are included in the shipment, planned date for the load start
and end, actual date for the load start and end, planned date for the delivery
confirmation start and end, actual date for the delivery confirmation start
and end.
Vehicles
One or more vehicles can be assigned to a shipment. For every vehicle it is
also possible to add a shift and trip. If a trip number is entered then a check
is carried out that the vehicle/shift/trip combination is unique. It is also
possible to assign a carrier and route to the vehicle.
Selection routines exist to help in the selection of vehicles. Whole vehicles
must be selected - it is not possible to select individual transport units or
compartments for a shipment.
Drivers
One or more drivers can be entered against a shipment - although the entry
of a driver is not mandatory in the shipment. The matchcode facility can be
used to select the driver.
Underlying Documents
One or more documents can be allocated to a shipment. Once a document is
allocated to a shipment, it cannot be changed outside the shipment.
The TD component supports the following methods of assigning documents:
q Entry of an explicit document number
q Selection of deliveries using the Document Selection Report. The report
can be used to select documents based upon the following criteria:
m Delivery details
m Shipping notification details
m Reservation details
$VVLJQLQJ3URGXFWV'RFXPHQW,WHPVWR&RPSDUWPHQWV
After selection of both documents and vehicles used for the shipment, a plan
must be made showing how the vehicle will be loaded. At this time the
important level of assignment is the compartment level. Compartment
planning is used to assign document items to each compartment of the
selected vehicles (transport units and compartments).
The assignment of products to compartments is processed as follows. First,
the dispatcher selects a vehicle allocated to the shipment. The shipment
contains a list of items to be transported along with a series of check boxes
for the compartments. The dispatcher selects which material goes into which
compartment by setting the check box. The system then automatically
assigns volumes to the compartment. The assignment can be entered or
modified on another screen. A number of checks are performed at this point
including the following:

q Product Compatibility
That the compartment is compatible with the product that is due to be
loaded into it.
q Customer Compatibility
That the vehicle has the correct characteristics to deliver to that
customer.
After successful assignment of all document items, the shipment can be
posted.
If the quantities of a document do not fit in a compartment, the system will
only automatically assign the quantity that fits in the compartment. The
outstanding quantity can then be allocated to another compartment ( but not
necessarily on the same vehicle in the shipment ). The shipment cannot be
posted if compartment allocation has not been carried out. It is possible to
change the document item quantities from the Document Quantity screen in
the scheduling transaction. When appropriate, the system displays and
updates the following data:
q Actual weight and volume per vehicle
q Actual volume or weight per compartment
&KDQJLQJ6FKHGXOHG4XDQWLWLHV
Through the shipment it is possible to change the quantity of product to be
transported. This allows the scheduler a certain degree of flexibility to
determine the quantity of product actually shipped. The scheduler may wish
to make adjustments, in order to optimize the use of the vehicle. The
scheduler can make a judgment on balancing customer service (deliver as
ordered) and cost control (efficient transportation). The system allows the
following functions with respect to changing quantities:
q Changing quantities of allocated products
q Automatic calculation of unallocated quantities by subtracting the
allocated quantities from the document item quantities
q Automatic document update at shipment posting
When the scheduler chooses to change the quantity of a shipment item (i.e.
product) both the availability and credit limit checking functions are
performed as set up for a specific product or customer. This occurs when the
quantity of product is increased. The delivery process with respect to
overdelivery and underdelivery tolerances continues to be supported in the
scheduling function.

3RVWLQJ6FKHGXOHG6KLSPHQW
Posting the scheduling transaction causes a shipment document to be
created recording all the information described above. The document status
is updated to “scheduled“ at this point.
Following the creation of a shipment, changes are made to the underlying
document if the quantity to be shipped has changed during scheduling. This
is an automated process.
%LOOVRI0DWHULDO
The scheduling transaction, along with loading and delivery confirmation,
will support the use of bills of material. The scheduling process will take
place at the level of the header material in the BOM.
3ULQWLQJ
The scheduling transaction supports the printing of the loading document at
a printer determined by using the core output determination process.
&KDQJLQJ'LVSOD\LQJ6KLSPHQW
The system provides both Change and Display transactions. The capability
to change the shipment will depend on the status of the document. For
example, after scheduling almost any field can be changed. However, after
loading confirmation it is not possible to change the vehicle.
Matchcodes
Matchcode(s) are defined to support the search strategies for the selection of
shipments. Selection criteria for this matchcode are shipment type, status,
user etc.
/RDGLQJ&RQILUPDWLRQ
The loading transaction starts when a shipment is loaded on to a vehicle.
The prerequisite for loading is scheduling. A shipment can not be loaded if it
is not scheduled. A status handling function controls the sequence between
TD processes. Status handling is flexible, so that changes can be made to a
shipment even after the shipment has moved to the loading or delivery
processes. However, changes cannot be made to the vehicles or documents,
when these have been load or delivery confirmed. The main functions of
loading are to record the actual loaded quantities and to update all of the
dependent data (shipment, delivery, order, stocks, tax liability, etc.). The
place of the loading process within TD is shown below:


'HOLYHULHV $VVLJQ /RDGYHKLFOHV 5HFRUG

QRWLILFDWLRQVRU
5HVHUYDWLRQV GRFXPHQWVWR VFKHGXOHV VKLSPHQW
YHKLFKOHV
The loading process is the same regardless of whether a Terminal
Automation System (TAS) is in use or not for a particular terminal. When
such a system is used, the data is transferred from the TAS system to SAP
R/3 System using the same transactions as when no automatic system is in
place.
/RDGLQJ%XON3URGXFWV
The process of load confirmation is completed for each vehicle/plant
combination. Each vehicle and plant maintains a separate status. After
posting the loading confirmation for one vehicle/plant the shipment is given
the status “partially loaded“. If the loading confirmation has been posted for
all vehicles/plants in the shipment, the shipment is given the status “fully
loaded“. For every loading confirmation of a shipment it is possible to
identify the loading date and time.
Bulk Product Quantities
Several important processes occur within the loading confirmation step, the
most important being the entry of actual loaded quantities. Quantities in
scheduling are planned quantities which are proposed at the loading
confirmation stage.
For bulk products the loaded quantity can be entered in two ways:
q Activate proposal (accept the products and quantities proposed from
scheduling)
q Enter loaded quantities directly, if different from scheduling proposal
q Meters (single or multiple meters can be used to enter the quantities for
each line item)
q Prior-to-load quantities can be entered, if product was left on the vehicle
from a previous shipment
The entry of product quantities has to be accompanied by the store location
number and the batch number (or valuation record) indicating the origin of
the product. The temperature and density of the product must be entered at
this stage, via a popup window, so that the ASTM calculation can be done
and quantities in other units of measure calculated.

TD offers the capability to define meters for store locations (tanks) from
which the quantities are read. The meters are maintained as master data and
are identified uniquely by a meter code. Based on the meter readings, the
loaded quantities are determined. If a differing unit of measure is used for
loading than that employed by the meter, the system performs an
appropriate conversion either based on ASTM routines or “simple“
conversion factors. For example, if the meter is defined in kiloliters (ambient
liters) and loading is done in liters (ambient) one click of the meter is
converted into 1,000 liters. It is a requirement (mandatory) to assign a meter
to a specific plant. On entering a meter code, a check is made to ensure the
meter is defined within the loading plant.
Manufactures/Planned Rebrands
Manufactures or rebrands are a common practice in the oil business. It can
happen that two products are mixed to produce a new product during
loading onto the vehicle. This is common in the case where additives are
added at the loading racks of depots to a base product to produce an
enhanced sales product to be delivered to the customer. In the SAP R/3
System, a sales Bill of Material (BoM) is used to support this activity. The
bills of materials that is, sales products are used during scheduling without
being exploded. However, during loading the sales product is exploded into
its constituent components, and the quantities for these components can be
entered. Although the bill of material proposes the quantities of the
components to be loaded to make the sales product, it is possible to enter the
actual loaded quantities of all components such as, the base product and the
additive.
This is illustrated in the following example:
)LJ%LOOVRI0DWHULDO6WUXFWXUH
The quantity of the sales product is calculated by adding the loaded
quantities of the components and using a weighted average calculation for
the temperature and density. The same process also applies to “Planned
Rebrands“. In the oil business this is used when different product names are
used for stock keeping and sales purposes. The sales product number is
entered in the order, delivery and the schedule. For accurate stock keeping it
is possible to enter the loaded quantities of the actual stock keeping product.

/HIWRQ9HKLFOH4XDQWLW\
When delivering products to a customer it can occur that the complete loaded
quantity is not actually delivered. A certain quantity of a product may remain
on the vehicle and come back to the depot. This is referred to as the “left-on-
vehicle” quantity. The driver reports the left-on-vehicle quantities when he
returns to the depot. The system functions surrounding processing of left-on-
vehicle quantity are discussed in the section “Delivery Confirmation“.
If the vehicle contains a quantity of bulk product from a previous shipment
this is indicated at loading confirmation as the “prior-to-load“ quantity. The
quantity left on the vehicle in a previous shipment can be entered or pulled
into the current shipment by activating the prior-to-load quantity. This
amount together with the newly loaded quantity is then combined into the
current shipment.
A report can be used to reconcile left-on-vehicle and prior-to-load quantities
for a specified period of time. The report displays quantities which have
been left on the vehicle and not assigned to any subsequent shipments
during loading confirmation.
&RPSDUWPHQW$OORFDWLRQ
The loaded quantity of a bulk product is allocated at compartment level on
the vehicle during the scheduling step. At loading confirmation the user
assigns the actual quantity of product loaded onto the individual
compartments in the transport units.
%DODQFH/RDGLQJ
During loading, a balance load function is available to ensure that the
underlying document quantity is equal to the loaded quantity. If the balance
load indicator is set in Customizing, the material quantities which have been
loaded must be assigned to the underlying documents. During balance
loading, the loaded quantity is proposed as the discharge quantity in the
delivery confirmation process. Balance loading is also a prerequisite for
other processes, such as Rapid Delivery Confirmation.
Two types of balance loading exist, and the method used depends on how
the compartments have been loaded, which in turn is determined by the
compartment load indicator. However, when balance loading is required,
only the relevant method is used.

%DODQFH'RFXPHQWV
When the compartment load indicator is set to allow only one delivery per
compartment, the process of balancing documents must be carried out. The
process of balancing documents assigns delivery documents to the loaded
quantities. The materials and quantities are allocated to delivery documents
at the compartment level.
%DODQFH4XDQWLWLHV
When multiple deliveries or multiple materials are allowed for the

shipment, the process of balancing quantities must be carried out before
loading can be confirmed. Unlike the balance documents process, within
balance quantities the quantities allocated to a particular delivery or delivery
item may be changed or split between several compartments.
At the balance loading stage, it is also possible to allocate or deallocate
documents.
8QSODQQHG5HEUDQGLQJDW/RDGLQJ
An example of unplanned rebranding is a case where the ordered product is
“Unleaded Regular“. At loading the driver finds that the product is not
available. It is then decided to provide the customer with “Unleaded Super“
for the price of “Unleaded Regular“. It is possible to indicate that this type of
unplanned rebranding has taken place. The pricing and all the printed
documents for the customer refer to the originally ordered product. The
goods movements which are generated in the background are based on the
actual shipped product.
0XOWLSOH0HWHUV
In some oil companies it is common practice to load product using more
than one meter. The multiple meter function allows more than one meter to
be used in loading the vehicle compartment.
&DSWXUHRI0HDVXUHPHQW'DWD
Within the loading confirmation process it is possible to capture an
unlimited number of measurement readings for the same product
movement. All of the readings are stored in the shipment document for
future reference, but are not posted against inventory and are not used to
update underlying documents. Measurements that are to be used as the
basis for inventory purposes must be selected for that purpose.
When loading confirmation is completed, the postings must reflect the
correct intransit stock position for the shipment. If there are no differences
between the measurements, or the sender and receiver agree on a
measurement, only one material movement is necessary to move stock to the
intransit plant.

If there is a difference between the measurements, and the first measurement

has already been used for the intransit posting, a correction of the loaded
quantity is required. How the correction is handled depends on a decision
between the sender and the receiver as to where the difference in quantity
should be posted. If the receiver accepts the difference, the intransit stock is
corrected by posting a gain or a loss. If the sender accepts the difference, the
necessary postings depend on the underlying documents used for the
shipment.
6KLSPHQW6WRFN$GPLQLVWUDWLRQ
During the loading confirmation process it is possible to correct quantities
for shipments which have been completely loaded. Changing the quantities
for a completely loaded shipment results in correction postings. What type
of posting is made depends on the underlying document used for the
shipment.
For example, when loading against a shipping notification, a goods receipt is
normally posted. If the quantity is increased as the result of shipment stock
administration, then an additional goods receipt is posted for the additional
quantity. A decrease in quantity results in a reversal of the goods receipt
posting.
&RUUHFWLRQVDW'HOLYHU\&RQILUPDWLRQ
When a shipment is partially delivery confirmed and the underlying document

is a shipping notification or reservation, it is possible to:
q Change onboard stock movements
m Between intransit storage locations
q Between vehicles
q Post gains/losses during transport
q Rebrand intransit stock
q Change tax status of intransit stock
0RYHPHQWRQ%RDUG
It is possible to change information about loaded stock for shipments that

have a status up to “partially confirmed“. The changes are made from the
delivery confirmation process. Using the movement on board function, it is
possible to change the following information about a loaded shipment:
q Vehicle
q Compartment
q Intransit plant
q Intransit storage location
q Batch

q Material
q Quantity
3ULQWLQJ/RDGLQJ3DSHUV
TD provides the capability to automatically print documents after loading
the shipment. The printed documents are flexible in layout and content. An
example of a bill of lading is supplied with the system. TD also uses the core
output condition technique to allow flexible output definition for the
document (print, fax, email, etc.).
3RVWLQJ/RDGLQJ&RQILUPDWLRQ
Status of Shipment Document
Posting the loading confirmation results in an update of the shipment
document. The status after loading confirmation can be one of the following:
q Partial loading - loading is finished for one or more vehicle/plant
combinations, but still has to be done for other vehicle/plant combinations
before the shipment has been completely loaded.
q Completely loaded - loading has been done for all vehicle/plant
combinations in the shipment.
Material Movements
At the loading confirmation posting the product moves from normal stock to
a vehicle. The vehicle is represented as an “intransit storage location“.
([FKDQJHV
When products are loaded at the depot of an exchange partner, the loading
confirmation is processed differently. This process is shown in the figure 6-13.
)LJ3K\VLFDODQG$GPLQLVWUDWLYH3URGXFW)ORZLQ([FKDQJHV

When a product is loaded from an exchange partner, the system performs

the posting of a goods receipt to a purchase order (call-off). The goods
receipt is the process of recording the actual quantity received in stock and
generating the required inventory accounting entries. The product is
received in the “normal“ storage location and is then moved to the intransit
storage location.
7DULIIV'XWLHVDQG3HUPLWV
The handling of account postings for tax purposes is described in the chapter
on Tariffs, Duties, and Permits (TDP). In short, when products are physically
moved they have a “from“ and a “to“ tax status. Both can be “ED-free“ or
“ED-paid“. This terminology is extensively discussed in the TDP concept. For
TD purposes it is important to note that there are physical movements of
products and thus the tax status definition has to be supported.
The “From“ status is derived from the batch where the product is loaded. The
“To“ status is defined by the intransit storage location, using customizing
tables related to the bulk shipment type.
The final step in the distribution cycle is the confirmation of the delivery.
This the final processing stage of the products which were loaded on the
vehicle. The place of delivery confirmation within the TD process flow is
shown in the figure below:

'HOLYHULHV
'HOLYHULHV $VVLJQ /RDGYHKLFOHV 5HFRUG
6KLSSLQJ
QRWLILFDWLRQVRU
QRWLILFDWLRQV
5HVHUYDWLRQV GRFXPHQWVWR VFKHGXOHV VKLSPHQW
RU YHKLFKOHV
5HVHUYDWLRQV
At delivery confirmation, four alternatives can take place with a given
product quantity:
q Product was delivered to a customer (or to another plant in the case of a
transfer)
q Product is left on the vehicle for the next shipment
q Product is returned to a plant
q Product is lost or gained
Delivery confirmation must be completed for each vehicle in a shipment. A
shipment is completed when all assigned shipments are confirmed. The
processing of left-on-vehicle quantities, return quantities or gains and losses

can only be executed when all shipments are confirmed. A status handling
function controls the sequence between TD processes. Status handling is
flexible, so that changes can be made to a shipment even after the shipment
has moved to the loading or delivery processes. However, changes cannot be
made to the vehicles or documents, when these have been load or delivery
confirmed.
Within the delivery confirmation process, there are several methods of
confirming the delivery, depending on the accuracy required for the
information, and the amount of time available for processing the shipment.
Rapid delivery confirmation does not require that the quanities delivered be
reviewed, and can be performed for one specific delivery or all deliveries
with the shipment. Fast delivery confirmation makes it possible to change
the quantities delivered from those which are proposed.
The delivery confirmation process includes functions for handling unplanned
deliveries, and several options for dealing with undelivered product. It is
possible to enter delivered quantities manually or by using vehicle meters
during delivery confirmation.
The delivery confirmation transaction supports three main business scenarios:
q Complete shipment is delivered to the customers as loaded. In this case
no gains or losses, no left-on-vehicle quantities and no return to store
location postings occur (rapid confirmation).
q Some deliveries from the shipment are delivered to the customers and
are confirmed (partial delivery confirmation). If one chooses not to
change quantities for the selected discharge-relevant documents, the
same postings apply as in the first scenario.
q Some or all discharge-relevant documents are selected and the user
changes the quantities actually delivered to the customers. In this case,
the user determines how the difference between the loaded quantity and
delivered quantity of a product is managed (lost, gained, left-on-vehicle,
or returned to stock).
In the figure below, the subsequent steps and functions are schematically
presented. The remainder of this section describes the Delivery Confirmation
functions.

)LJ'HOLYHU\&RQILUPDWLRQ6HOHFWLRQ6HTXHQFH
5DSLG'HOLYHU\&RQILUPDWLRQ
Rapid delivery confirmation can be used to confirm one or all of the
deliveries within the shipment. This is an especially useful process when
gains and losses do not exist. Rapid delivery confirmation can also be useful
when it is intended to deliver as loaded and there are no gains and losses to
be taken into account.
The quantities confirmed for delivery using rapid confirmation are the same
quantities that were confirmed during the loading confirmation process. To
use rapid confirmation, balance loading must have already been carried out
for the shipment.
It is possible to select individual deliveries to be confirmed (partial delivery).
For individually selected documents it is also possible to perform a rapid
confirmation. This means that for the selected documents the shipped
quantities equal the loaded quantities.

)DVW'HOLYHU\&RQILUPDWLRQ
The fast delivery confirmation transaction displays all the data necessary to
amend and confirm quantities that were delivered. This information
includes the meter data entries, receiving plants (for stock transfers), reason
codes. This method of delivery confirmation has the advantage that all
deliveries for a given vehicle are displayed on one screen.
6HOHFWLRQRI'LVFKDUJH5HOHYDQW'RFXPHQWV3DUWLDO'HOLYHU\
Unplanned Deliveries
If a delivery cannot be made to the expected customer and, rather than
bringing the load back to the depot, it is decided that the product on the
vehicle will be delivered to another customer, then the original document in
the shipment is modified to show that no delivery, or if appropriate, a partial
delivery occurred and a new document is added to the shipment for the new
customer. This is possible because of the flexible status handling in TD.
New delivery documents can be added to the shipment. However, a
delivery can only be added to the shipment if the delivery exists and is not
currently „scheduled“ to another shipment.
$PRXQWRI3URGXFW'HOLYHUHGSHU&XVWRPHU
It is possible to specify the delivered quantity for each delivered item. By
manual entry of the quantities, or by entering meter readings, it is possible
to specify exactly the quantity of each product delivered to the customer.
ASTM Parameters
The ASTM parameters are entered and stored at loading confirmation. These
parameters can be updated during delivery confirmation (for example due
to a temperature change at delivery). A pop-up window for ASTM
conversion can be called to specify the new delivery parameters. The ASTM
corrected quantities are calculated based on these values and updated in the
underlying document, and will subsequently be used for postings.
Left-On-Vehicle
An important aspect of the delivery confirmation is the accounting for any
left-on-vehicle quantity, which will be left in the intransit storage location
with the ASTM parameters taken during the delivery confirmation. Extra
processing will be required when the truck is next loaded to take account of
this stock in the new shipment.
Return to Plant
If not all the product was delivered, some of it can be unloaded at a company
plant - either the original plant or another one. The return quantity can also be
rebranded as a new product. For example, if the product is returned because it
is contaminated, it could be returned under a different product name. Any
value differences would be posted as a gain or loss financially.

Gains and Losses

If the user posts a different quantity during delivery confirmation, the
system considers the difference to be a gain or a loss. If a return plant is not
specified the system will prompt the user to specify one. This plant is then
made responsible for the gains or loss. The system can also be customized to
use specific tolerance values for gains and losses. If the gains or loss exceeds
the tolerance value the user is required to specify a reason code for the gain
or loss. The reason codes are freely definable codes. The codes and their
explanation are defined in a customizing table. A user specific report can
then be built to analyze the gains and losses.
Meters
Meter readings can be used to capture the delivery quantity. Meter data is
stored each time a transaction passes through the delivery confirmation. A
meter history file captures the information for use in the meter reconciliation
function.
Two-Step Transfers
TD also supports the transportation function for stock movements from one
plant to another. In the Core SAP R/3 System, this function is supported by
using different purchase order types. A transfer order type is used to
manage the movement of stock from one plant to another plant within the
same company. When using these order types in TD, the additional
functions are reflected in the loading and delivery confirmation transactions.
The system generates both a goods issue (from the delivering plant) at
loading and a goods receipt (for the receiving plant) at delivery
confirmation. To enable these documents to be produced the user is required
to specify both the storage location and the batch number of the product.
Excise Duty Handling
As discussed during the loading step the products receive a tax status in the
intransit stock. When the products are delivered to the customer they receive
a new tax status. The new tax status is based on the customer master. For
tax posting purposes, a “from“ tax status exists (as discussed in loading
confirmation) and a “to“ status exists as retrieved from the customer master
during delivery confirmation. When a return, gains or loss or goods receipt
is posted, the “to“ tax status is retrieved from the receiving batch. The effect
of these changes to the tax status are reflected in the financial postings
accompanying all the goods movements.
3RVWLQJ
When posting the loading or delivery confirmation, the system updates the
status of the shipment document. The following table shows the different
posting possibilities dependent on the underlying documents and their load
or discharge relevance.

Document Load Disch. Action Movements Comments

Rel. Rel.
Delivery X X L 311 Delivering Plant/StLc to
Intransit StLc
D 601 Intransit StLc to Customer
X D 601 Intransit StLc to Customer
X Not allowed at
scheduling
Shipping X L 101 Goods Receipt to Intransit
Notification Plant/StLc
X X L 101 Goods Receipt to Intransit
Plant/StLc
D 301 Transfer Receiving Not planned
Plant/StLc during scheduling
X Not allowed at
scheduling
Reservation X L 301 Delivering Plant to
Intransit Plant
X D 301 Intransit Plant to
Delivering Plant
X X L 301 Delivering Plant to
Intransit Plant
D 301 Intransit Plant to Not planned
Receiving Plant during scheduling
Two-step X X L 311 Delivering Plant + 641
Transfer Goods Issue
D 101 Goods Receipt
X D 641 GI to Intransit of No Goods Receipt
Receiving Plant osting for receiving
plant
X Not allowed
6KLSPHQW&RVW3URFHVVLQJ
Shipment cost processing is used to carry out the calculation and settlement
of shipment costs with a service agent. The shipment cost process
involves several activities within TD:
q Prepare shipments for shipment cost processing
m Maintain routes in shipment
m Maintain partners (service providers) in shipment

m Assign loading and discharge points
m Assign loaded and discharged quantities
q Create shipment cost documents

and other shipment costs
q Settle shipment costs with service provider
The following functions are provided in shipment cost processing:
q Entry and management of master data for shipment agreements, rates,
and other shipment costs
q Calculation of shipment costs for each stage of a shipment
q Settlement of costs for each service agent
q Transfer of shipment costs to Financial Accounting and Controlling
'RFXPHQW6WDJH$VVLJQPHQW
Shipment stages (legs, load transfer points, and border crossing points) are
used to record the geographical aspects of a shipment. The assignment of the
underlying documents of a shipment to the stages within a route is required
for the document item quantity assignment, and therefore, also necessary for
the creation of a shipment cost document and the settlement of costs with a
service agent.
A shipment can consist of several points of departure and several destinations.
The shipment can require various modes of transport and involve various
service agents. The connections between the locations, modes of transport,
and service agents are all recorded in TD through the use of stages. To settle
costs with a service agent the shipment cost process requires the asignment of
underlying documents to the stages of a route. The shipment cost is based on
the quantity of product transported over the specified stages.
Using the optional auto stage assignment function, stage reference information
(from associated tranportation connection points) can be used to make an
automatic stage assignment. For example a plant, storage location, customer, or
vendor information can be used.
3DUWQHU$VVLJQPHQW
Partner data is used to represent service agents in TD. Multiple partners can
be assigned to a shipment. The shipment cost process uses the partner
assignments to settle all costs of the shipment, such as costs based on the
quantity of product transported over specified stages.
Partner data can be maintained on the shipment header level (insurance
partner), on the vehicle level (carrier), or on the stage level.

'RFXPHQW,WHP4XDQWLW\$VVLJQPHQW
Document item quantity assignment is the assignment of load-relevant
document items to discharge-relevant document items for the selected
vehicle based on the material information. This is necessary for shipment
cost processing, because of the flexibility required to support pipeline and
marine shipments. This flexibility is reflected in the following TD functions:
q Separate documents for loading and discharge of a certain quantity
within a shipment
q Splitting of quantities from load-relevant documents to multiple
discharg-relevant documents or vice versa
Quantity assigment is carried out for each vehicle along the vehicle route,
based on the First In First Out (FIFO) principle. The process is triggered by
the creation of a shipment cost document for a shipment, or can be carried
out in a separate step where the document and quantity assignments can be
modified.
6KLSPHQW&RVW'RFXPHQW6WUXFWXUH
The shipment cost document contains data that is important for processing a
shipment. This data represents the physical flow of a shipment. It can, however,
be important to redefine a shipment from the view of shipment cost calculation.
This can be important for example, when it is necessary to determine shipment
costs according to the method “most expensive main leg“.
This method is not yet implemented for IS-Oil Downstream release 1.0D, but it
is an example of why a separate document is required for the shipment costs.
'(/ &XVW
&XVW
'(/
&XVW
W V
LOHV LOH
P (/ P
W ' LOHV
H
)UHLJKWFDOFXODWLRQPRVWH[SHQVLYHOHJ
JK P
: FH ' (/ VWQF 6WDJH6KSJSQW&XVW
WQ ' FH / )UHLJKW
'V / Q '(
'( 'VW ( / 'LVFRXQW
' 7RWDO

'(/
8QORDGLQJSRLQWV
&XVW 6XUFKDUJH
&XVW 6XUFKDUJH
7RWDO
6XUFKDUJH
6KLSSLQJSRLQW
)LJ6KLSPHQW&RVW&DOFXODWLRQ$FFRUGLQJWRÄ0RVW([SHQVLYH0DLQ/HJ³
In the example above, the actual shipment flow plays a subordinate role in
shipment cost calculation. The main legs are the most important information

for shipment cost settlement. It is still necessary to calculate several shipments

together. This is particularly the case when the insurance for a transportation
chain is based on a percentage rate of the total transportation costs.
The shipment cost document in the above example requires an appropriate
reference to the shipment components for which you have to have separate
shipment cost calculation (stages, shipment header).
The above example shows a function of shipment cost processing which will
be available after Release 1.0D. The shipment cost document which is
available in Release 1.0D contains the following information:
q Cost view
m Overview of items with display of calculated costs
m Representation of costs for each document item
q Document view
m Overview of underlying documents that are a part of the shipment
costs
q Stages
m Overview of stages that are part of these shipment costs
q Document flow
m The shipment cost document is integrated into the SD document
flow
m It is possible to call up the document flow from the document
q Status management
6KLSPHQW&RVW&DOFXODWLRQ
Shipment costs are calculated using the condition technique in standard R/3
pricing. The standard pricing function is based on:
q Pricing procedure
q Condition types
q Access sequence
q Conditions
The pricing procedure is determined by the following:
q Transportation planning point
q Shipment cost group
q Carrier group
q Shipping type group
The actual shipment cost calculation is carried out either on the basis of the
shipment stages, vehicle, or shipment header. The data can be taken from

different sources such as, the shipment header, the vehicle, the shipment
stages, or the underlying documents. The basis calculation can be one of the
following:
q Underlying documents
q Items from the underlying documents
q Assigned quantities
q Vehicle
q Shipment cost document item
$FFRXQW$VVLJQPHQWDQG&2$VVLJQPHQW
How shipment costs are allocated, and how the GL accounts and CO objects
are determined is based on the shipment and the underlying (discharge-
relevant) documents, as well as parameters set in Customizing for the
shipment cost item category. Parameters for account determination include:
q Information from the shipment
m Company code
q Information from Customizing

m Plant
m Valuation class
m Account assignment category
q Document type of the underying document (optional)

Account determination based on the document type of the underlying
document is only possible if costs are allocated per document or document
item. This allows the costs for inbound and outbound movements within the
same shipment or shipment stage to be separated into different GL accounts.
The CO objects can be determined based on the GL account or from the
underlying documents (sales order, delivery, purchase order, or shipping
notification). CO objects include:
q Cost center
q Profit center
q CO order
q CO/PA object
The GL accounts as well as the CO objects determined by the system are
only proposals and can be modified.

6KLSPHQW&RVW6HWWOHPHQW
A function to settle shipment costs with a service agent (partner) is provided,
and supports manual invoicing and automatic invoicing.
6KLSPHQWFDOFXODWLRQ 6KLSPHQWFRVW
GRFXPHQW
W WOHPHQW
6WDUWVH
6HUYLFHHQWU\ 5HOHDVH )LQDQFLDO

VKHHW $FFRXQWLQJ
,QYRLFHFUHDWLRQ
(56RUPDQXDO $FFUXDOV&RVWDFFRXQWLQJ
)LQDQFLDO
,QYRLFH $FFRXQWLQJ
3D\DEOHV+DQGOLQJYDULDQFHV
)LJ2YHUYLHZRI6KLSPHQW&RVW6HWWOHPHQW
Shipment cost settlement includes the following functions:
q Manual and automatic release of shipment cost documents for
settlement
q Creation of external service orders and entry of services provided
q Automatic settlement (ERS procedure)
q Transmission of shipment costs to accounting system
q Self billing (information for the service agent with respective information
from shipments and shipment cost documents)

&KDSWHU
7DULIIV'XWLHVDQG3HUPLWV7'3
+LJK/HYHO6XPPDU\
The objective of TDP within R/3 IS-Oil Downstream is to incorporate
functions specific to the oil industry for the handling, calculation, and
posting of excise duty values in the R/3 System.
The IS-Oil System provides:
q Excise duty (ED) handling from order entry through to invoice
generation. Calculation of excise duty liabilities and receivables are
made on each movement of dutiable product. Duties can be calculated
based on multiple units of measure, including temperature-corrected
quantities.
q Maintenance of the dutiable status of materials. Changes in the quantity
of taxable inventory are calculated on each movement of dutiable
product. The ED-paid inventory values of dutiable products are held
separately from the book value of the inventory.
q Functionality for maintaining and using different tax rates for the same
product, depending on the intended use of that product. It is possible to
handle duty calculations for material moved between different plants
with different tax rates.
q Licenses, exemptions, and allowances are taken into account in duty
calculations.
.H\)XQFWLRQ%HQHILWV
By integrating excise duty handling in Purchasing, Materials Management,
and Sales the R/3 IS-Oil Downstream component helps oil companies to
calculate their excise duty liabilities correctly, and avoid fines or penalties
that might result from incorrect calculations for the payment of taxes.
The key function benefits are as follows:
Specifically, the TDP application area ensures that both the functional and legal &RQVLVWHQW([FLVH'XW\
requirements governing excise duty are met. TDP covers the identification and +DQGOLQJLQ
calculation of excise duty liabilities and claims, which occur whenever there are 3XUFKDVLQJ0DWHULDOV
movements of dutiable materials between ED-paid and ED-unpaid locations or
vice versa. ED-paid represents undbonded/tax product where the excise duty
0DQDJHPHQWDQG6DOHV
tax is paid. Ed-unpaid represents bonded/untax product where the excise duty
tax is not yet paid.

7DULIIV'XWLHVDQG3HUPLWV7'3DVSDUWRI,62LO'RZQVWUHDP
&RVW(IIHFWLYH/HJDO The TDP application area integrates excise duty handling techniques in
&RPSOLDQFHIRU7D[ Materials Management, Sales and Distribution, and Financial applications
DQG'XW\/LDELOLWLHV thereby leading to consistency in the handling of excise duties.
$XWRPDWLF'HIDXOWDQG This functionality automatically proposes certain excise duty parameters
7UDQVIHURI([FLVH'XW\ and transfers these parameters among applications, thereby reducing the
3DUDPHWHUV data input effort required by users and reducing the risk of data
transcription errors.
,PSURYHG&DVK)ORZ TDP enables each unit of oil material to be identified as either ED-paid or
ED-unpaid stock. This enables a business to track changes in ED-paid stock
separately from ED-unpaid stock, and to select stock for issue based on its
duty status. This gives companies flexibility in managing their exposure to
excise duty tax and hence the flexibility to manage their cash flows
accordingly. This is critical in countries where the value of the excise duty in
inventory is greater than the value of the material itself.
,62LO'RZQVWUHDP7'3&RPSRQHQW
The following TDP oil industry-specific functionality is provided within the
R/3 IS-Oil Downstream System:
&DOFXODWLRQDQG3RVWLQJRI([FLVH'XW\
Within the downstream oil industry there is a requirement to be able to
calculate and report on excise duty values whenever a movement of dutiable
material occurs from a ED-unpaid to an ED-paid location or vice versa. In
addition, it is necessary to capture the financial implications of material
movements between ED-paid locations. Material movements between ED-
unpaid locations have no financial implications with regard to excise duty
identification.
)LJ3RVWLQJRI([FLVH'XW\
The TDP application area builds on Core R/3 by defining the rules necessary
for excise duty calculations, and by providing the mechanism to calculate and
post these excise duty values in real time.
Examples of some of the posting rules that are provided by TDP include:

q Tax liability postings for movements of dutiable material from an ED-

unpaid to an ED-paid location
q Tax claim postings for movements of dutiable material from an ED-paid
to an ED-unpaid location
q Excise duty value of stock to be calculated separately from the material
value and to be posted to a separate balance sheet account
q On consumption of dutiable materials, the excise duty value of a stock to
be calculated separately from the material value and to be posted to a
separate consumption account. Relief against inventory is posted against
the excise duty value in the stock account
q Excise duty value differences to be calculated and posted whenever
movements of dutiable materials occur, where two excise duty rates may
apply
$670$3,%DVHG([FLVH'XW\+DQGOLQJ
The Core R/3 System provides the function for holding stock in one unit of
measure (the “base” unit of measure). The R/3 IS Oil Downstream
Hydrocarbon Product Management (HPM) application area enables users to
hold stock in additional units of measure based on ASTM/API conversions
from the base unit of measure. There are multiple standard unit of measure
views for a given material to cover different requirements for purchasing,
pricing, stockkeeping, etc. In addition, quantities are also provided in the
excise duty unit of measure. These units of measure are user-definable (for
further information, see the chapter on HPM).
The TDP application area utilizes these extra quantity units of measure to
provide users with the ability to specify which of the various units of
measure are used to calculate excise duty values on relevant material
movements.
([FLVH'XW\+DQGOLQJIRU3URGXFW([FKDQJHV
TDP integrates excise duty handling techniques with the specialized invoice
processing functions developed for oil product exchanges in the R/3 IS-Oil
Downstream Exchanges (EXG) application area. This enables the invoicing
of excise duty values, even where material and/or fee amounts are not
invoiced.
$GMXVWPHQWVIRU&KDQJHVLQ([FLVH'XW\5DWHV
It is possible to capture the difference in excise duty values resulting from
changes in duty rates between accruing the liability and invoicing the
customer, and then to record the financial implications of such differences in
an appropriate manner.
TDP enables users to specify how differences in excise duty values between
the accrual of the liability and the invoicing of cost to the customer are

handled. Differences can be handled as a windfall gain or loss which is

posted to the income statement, or handled as an additional excise duty
liability or claim and posted to the balance sheet.
$XWRPDWLF7UDQVIHURI([FLVH'XW\3DUDPHWHUV
IRU3XUFKDVH6DOHVDQG3URGXFWLRQ2UGHU3URFHVVLQJ
The Core R/3 System provides the framework to automate data transfer
within and between the different functional modules such as Materials
Management, Sales and Distribution and Financials. The TDP application
area extends this functionality by providing for the automatic proposal
(default) and transfer of excise duty parameters within purchase, sales, and
production orders. A separate process then uses those parameters to
calculate the excise duty values, and posts the relevant financial documents
on a real-time basis.
A basic framework upon which functionality for the handling, calculation
and posting of excise duty values can be built, is provided by the R/3 Core
System, for example, the ability to split valuated materials. Enhancements
provided by IS-Oil TDP include the identification of the excise duty status of
a material.
Within the downstream oil industry there is a requirement to be able to track
dutiable material as either ED-unpaid stock or ED-paid stock. This is
necessary to enable ED-unpaid and ED-paid stock to be separately
controlled and valuated, and also to provide the ability to select stock for
issue based on its excise duty status.
6SHFLILF)XQFWLRQDOLW\IRU1RUWK$PHULFD
Certain functions have been identified which are relevant to the North
American market. A customer can be exempt from certain taxes depending
upon a variety of factors such as material, material group, customer,
customer group, mode of transportation, origin, destination, and type of tax.
The customer has to present his exemption license and the number must be
entered into the system. When the exemption license expires, the customer
must pay the excise tax until a new license is provided.
Condition types have been created for federal, state, county, and city excise
tax rates. An interstate excise tax table defines tax rates for movements
between states. Taxes can be charged either by the state of origin or
destination.

E\WKH,62LO'RZQVWUHDP7'3&RPSRQHQW
This section describes in further detail how TDP handles excise duties. The
excise duty values calculated and posted within R/3 IS-Oil Downstream can
be summarized as:
q Liabilities to pay excise duty to the tax authority of a specific country
q Tax Claims for returns from the tax authority
q Excise duty value associated with the quantity of ED-paid inventory
held in ED-paid locations
q The costs of excise duty associated with the consumption of duty-paid
inventory
q Excise duty accounting differences generated by specific circumstances
q Excise duty postings associated with gains and losses of product during
a two-step transfer
The business parameters which control how excise duty values are posted
include the following:
q The excise duty status of the material being moved; whether the material
is held or moved to an ED-unpaid or an ED-paid location
q To which excise duty tax group the material belongs
q The mineral oil content of a particular material, that is, the percentage of
the product deemed liable for duty
q For what the material will be used, such as for a process of manufacture
or for use as a fuel
q The locations involved in a movement; certain locations within a country
may apply excise duty at reduced rates
q The defined purpose of the movement itself, such as a goods issue to
scrap the material
q The date on which the movement takes place
In the following subsections, the business functions within the downstream
oil industry which determine how excise duty values are calculated are
described together with the TDP functionality which are provided to
calculate these values. Examples of the postings which may result from the
TDP functionality are also given as appropriate.

%DVLF3ULQFLSOHVRI([FLVH'XW\+DQGOLQJ
Excise Duty Status
([FLVH'XW\6WDWXV The excise duty status of a dutiable material (ED-unpaid or ED-paid stock)
and the nature of the tax movement determine the nature of the accounts to
which postings are made. For example:
q Whenever oil-based material is moved internally from a ED-unpaid
location to an ED-paid location, it is necessary to pay excise duties to the
authorities and an excise liability is incurred.
q When oil-based material is supplied from an ED-paid location by a
vendor and becomes part of the company inventory at an ED-paid
location, the company must record an increase in the excise duty
inventory value associated with its ED-paid stocks.
A license number can be stored for each storage location, where ED-unpaid
stock is held. This license can be printed on delivery documents involving
ED-unpaid stock.
It is important that oil material can be identified as either ED-unpaid or ED-
paid stock. This enables a business to track changes in ED-paid stock
separately from ED-unpaid stock and to select stock for issue on the basis of
its dutiable status. It is also critical that the excise duty value of inventory be
held separately from the underlying value of inventory. To make this
possible each material is associated with at least two “valuation types”
(valuation records). A valuation type is a sub-record for the material which
holds the total inventory value and quantity for the material of that type.
Either a batch number or a valuation type must be given for every material
movement to allow the system to update the physical and financial balances
for ED-unpaid and ED-paid materials. The update of the physical stock
balance, the financial balances for the material cost of inventory, and for the
ED value of inventory occur online and real time.
The material master record requires the following information for an excise
duty material:
q The excise duty tax group to which the material belongs. This is a user-
definable value and allows materials to be treated in the same way for
excise duty purposes. The excise duty group to which a material belongs
partially determines the excise duty rate which applies to a movement of
the material.
q The mineral oil content of the material. This determines what
percentage of the quantity of the moved material is deemed liable to
excise duty.
The excise duty status of a particular quantity of inventory is defined in the
valuation record.
Total stock on hand at each “plant“ (which could represent a tank farm,
refinery, etc. in R/3 IS-Oil Downstream) is held in multiple units of measure
in the material master record. In the valuation record, the total quantity of
ED-paid inventory is stored in the excise duty rate unit of measure.

The unit of measure used for the excise duty rate is defined for the excise
duty rate in the Excise Duty Rates table.
Excise Duty Postings ([FLVH'XW\3RVWLQJV

Tax Liabilities
Tax liability postings can be specified according to:
q The nature of the material: Materials with different tax groups may be
treated differently.
q The business function of the movement: The R/3 System represents the
business function of a movement by using an internal transaction/event
type (goods receipt, issue, transfer, etc.) and a movement type specified
by the user for each movement of material in the system. A movement
type can distinguish an issue for scrapping material from an issue of
materials for use in production, for example.
The following general accounting rules are followed by the TDP
functionality when determining the type of financial posting that is to be
made:
q An excise duty liability is generally posted for material movements from
Tax Status “ED-unpaid“ to Tax Status “ED-paid“ ,that is, from an ED-
unpaid to an ED-paid location.
q An excise duty claim is generally posted for material movements from
the Tax Status “ED-paid“ to the Tax Status “ED-unpaid“, that is, from an
ED-paid location to an ED-unpaid location.
It is possible to specify that excise duty claims be posted to a separate
account from that used for excise duty liabilities.
Tax Inventory
When dutiable material is received into valuated inventory, a debit posting
is made to an account representing the “excise duty of inventory“. When
dutiable material is issued from valuated inventory, a credit posting is made
to an account representing the “excise duty of inventory“.
All postings to inventory accounts representing the value of stock are made
without excise duty, online, at the time the material movement occurs.
Although the “excise duty liabilities“ account may have postings made to it
with a reduced rate of excise duty, the “excise duty of inventory“ account
always has postings made to it with the full rate of excise duty for the
material. This ensures that a meaningful revaluation of the excise duty value
of inventory can be conducted whenever there is a change in the applicable
excise duty rate.
Excise Duty Value at Consumption

For all material received as ED-paid product directly to consumption, the
excise duty value is posted to a separate cost account in the system. The
same is true where ED-paid inventory is issued to a department of the
company for consumption.

Excise Duty “Accounting Differences“

There are several circumstances where, due to the nature of the downstream
oil business, excise duty accounting differences may require the excise duty
calculation and posting process to calculate and post balancing financial
entries. The following are some examples:
q Movements where a relief/reduction in excise duty applies. Such as,
when oil is sold to a customer from ED-paid stock with a reduced excise
duty rate.
)LJ([FLVH'XW\³$FFRXQWLQJ'LIIHUHQFHV´
In the example, 10,000 liters of oil product are sold to a customer with a
reduced excise duty rate. A reduction in rate is specified using a special code
- the handling type - during the transaction. The system determines that a
handling type of “03” implies a reduced excise duty rate of 500.00 DM per
1,000 liters at 15 degrees Celsius (ASTM calculations are ignored). This
occurs during the processing of the material document for this transaction.
The excise liability which is posted as “excise duty cost of goods sold”
reflects the reduced rate. However, the reduction in excise duty inventory is
posted with the full rate of excise duty for the material. The full rate of excise
duty is found by reading the excise duty rates table with a masked handling
type - i.e. “XX“.
The difference between the “excise duty cost of goods sold“ and the excise
duty value of inventory posting is posted to a “relief/reduction“ account.
This difference may be treated as a liability in some countries, or as a
loss/gain in others. The financial account which is used to post this
difference is controlled via a company-level parameter, which can be
configured by users as appropriate.

q Internal “plant-to-plant“ transfers of material. For example, oil product

is sent from a refinery to a depot for storage prior to sale.
In this case, several differences may arise:
m Excise duty rates at each plant may be different (possible in
countries, such as Italy, where preferential rates of duty are applied
in certain districts). Also in certain countries, a movement of duty-
paid stock from one location to another location with a higher excise
duty rate is treated as a liability.
m During a two-step transfer (where material is issued from one plant
and held as “intransit“ until received at the second plant), excise
duty rates at the receiving plant may change during the course of the
transfer. In some countries, such differences may be regarded as
liabilities.
m Differences between excise duty liabilities booked and excise duty
billed may occur both on the procurement side and on the sales side.
For example, a company may book liabilities based on the quantity
of oil product loaded on a truck measured in liters at 15 degrees
Celsius. However, it is acceptable to bill customers for excise duty
measured in ambient liters. In such a situation, a difference will
arise between the excise duty liability recorded and the excise duty
billed to the customer.
m Similar differences could arise on the purchasing side if a duty-
inclusive price is quoted to a buyer based on a different rate than
that used by the company to value its duty-paid inventory.
Excise Duty Associated with Product Loss or Gain

During transfer of oil product between locations, the quantity of oil product
issued may differ from the quantity of product received. There may be a
physical loss or gain. A physical loss may be due to measurement, spillage,
leakage, etc.
Excise duty postings which are made for transfers where quantities are
monitored at issue and receipt (the two-step transfers) cater to both the
scenarios described above. An “excise duty loss or gain“ is posted for the
dutiable quantity lost or gained.
Excise Duty Rate Determination
Within R/3 IS-Oil Downstream, it is possible to control the excise duty rate ([FLVH'XW\5DWH
applied to a movement of material based on a set of parameters, such as: 'HWHUPLQDWLRQ
q According to the physical location (refinery, depot, tank farm, tank, ship,
truck etc.) from which dutiable material is issued, or according to the
location at which material is received.
q By the nature of the material
Different material groups may be given different rate structures within
R/3 IS-Oil Downstream.

q With respect to the end use of the product

A handling type associated with a movement of material can be used to
denote the intended use of the material. In such cases, excise duty rates
vary according to the handling type used for a particular movement.
)LJ([FLVH'XW\5DWH'HWHUPLQLDWLRQ$FFRUGLQJWR+DQGOLQJ7\SH
q The date from which the excise duty rate is valid.
The calculation process selects historic excise duty rates - from entries
within the excise duty rates table - based on the posting date of the
goods movement document within the system.
q According to the end use of the product. It is possible for users to define,
whether a specific movement of material is to be made with a handling
type (a code which defines the end-use of an oil material). Handling
types are, in turn, used to specify the excise duty status from which a
material is bought, or the status to which it is sold. License numbers (to
document relief or exemption from duty) may also be required for
certain handling types.
)LJ5DWHVLQ([FLVH'XW\7DEOHYDOLGIURP

Posting of Excise Duty

It is possible to control whether an excise duty liability or excise duty claim 3RVWLQJRI([FLVH'XW\
is posted for a particular materials movement.
Defaults of Excise Duty Parameters

One of the aims of TDP is to reduce unnecessary data entry by proposing 'HIDXOWVRI([FLVH
key excise duty parameters for purchase orders and sales orders. Other key 'XW\3DUDPHWHUV
functions within the R/3 System, for example, the control of production
processes using “production orders“ also use the default excise duty
parameters.
([FLVH'XW\+DQGOLQJIRUWKH3XUFKDVLQJ)XQFWLRQ
Standard Purchase Orders
TDP functionality allows the control of excise duty liability postings by 6WDQGDUG3XUFKDVH2UGHUV
company/purchase order type. Different purchase order types within the
R/3 System have different identification codes. These codes can be used to
help modify the tax movements allowable within the R/3 System. Thus a
goods receipt to a standard purchase order (type NB) within the R/3 System
for a ED-unpaid to ED-paid movement may be configured to provide excise
liability postings, whereas a goods receipt to a specialized purchase order
may result in no liability posting being recorded.
The key data required for excise duty within the purchase order is defaulted
into the order from master records and tables.
The handling type from the company/purchase order type is superseded by
defaults held in the purchasing information record (the purchasing
information record holds data concerning the purchase of a specific material
from a supplier). The Handling type is mandatory for purchase order items
for dutiable material.
The excise duty status from which the material is bought, or to which it is
sold (from an ED-unpaid location or from an ED-paid location), is defaulted
from the handling type.
The excise duty status of the stock when it is received is determined by the
valuation type which it is given when it is moved into stock. The valuation
type is a label which determines the dutiable status of material and is carried
with the material through every material movement.

Purchase Prices Inclusive of Excise Duty

3XUFKDVH3ULFHV,QFOXVLYH Where purchases of taxable material include excise duty, it is possible to
RI([FLVH'XW\ define purchase order prices so that the system calculates a valid price for
the material net of excise duty liabilities. This net price is used to valuate the
material on entry to stock or on consumption. It is important to hold the net
price in these circumstances so that the material purchase price history can
be maintained. Incoming invoices can be split to separate excise taxes from
materials to reflect different terms of payment.
)LJ,QYRLFH6SOLWWLQJ
An additional condition in the purchase order item defines the excise duty
rate to be used to calculate the excise duty portion of the gross price. Two
main types of conditions are allowed:
q External excise duty rates: These select an excise duty rate automatically
by reading the Excise Duty Rates table in the system using excise duty
parameters within the purchase order item.
q Internal excise duty rates: These allow the user to specify the rate of
excise duty applicable within the gross price using price condition
records. The user can then accept the price proposed by the system or
enter a price manually.
The system deducts the excise duty portion from the gross (duty-inclusive)
price to give a valid net price for the material. At the time the goods receipt
is posted, the system posts the net material cost to inventory (or expense).
The excise duty portion is calculated and posted to an excise duty value of
inventory (or excise duty expense) account.

The offset financial entry to the above financial entries is the accrual for the
payable (net material cost or excise duty) and is posted to the “goods
receipt/invoice verification“ clearing account. This account is cleared in the
invoice verification process, when the invoice for the total cost (material plus
excise duty) is recorded. It is possible to clear excise duty values separately
from the material values.
When the invoice is received for the purchased material, the system
proposes the total value of the accrued material and excise duty cost for
matching. The quantity of material for which the value is matched is also
displayed. However, quantities are only displayed in the purchase order
unit of measure, which may not be the excise duty tax rate unit of measure.
The excise duty rate used for the accrual calculation is not displayed.
Receipts of Dutiable Material Free of Charge

In certain circumstances, oil product may be delivered free of charge while 5HFHLSWVRI'XWLDEOH
excise duty is still payable on the delivery. Note that pure exchanges of 0DWHULDO)UHHRI&KDUJH
material are not covered by this scenario: the process of accounting for
materials and fees in exchanges is covered in depth in the chapter on
Exchanges.
For example, a supplier may deliver gasoline from an ED-unpaid location to
an ED-unpaid tank. On receipt, the product is found to be contaminated and
is returned. The supplier offers a replacement product, but has to provide
the material from a ED-paid stock. The product is purchased “free of
charge“ but excise duty is still payable. If a purchase order is raised for the
replacement supply, it is possible to define a net price of zero and a gross
price which reflects the excise duty cost per unit of material. Conditions,
used to define the excise duty rate, are used as in the example in the section
“Purchase Prices Inclusive of Excise Duty”. This provides a workable
solution for free-of-charge deliveries which incur excise duty. The postings
would be as follows:
)LJ3RVWLQJVIRU)UHHRI&KDUJH'HOLYHULHV,QFOXVLYHRI([FLVH'XW\

Subcontracted Purchase Orders

6XEFRQWUDFWHG Within the R/3 System it is possible to specify that material be provided to a
3XUFKDVH2UGHUV third-party (contractor) who will use the material to create a separate, final
product. This business process is handled within SAP R/3 System through
the use of “subcontracted orders“. In the standard system, these provide the
ability to track material components at the supplier’s premises during the
production process. Subcontracted orders are also used to automatically
calculate the inventory (or consumption) value of the final material based on
the net values of the component materials provided and the cost of
“manufacture“ of the final product. When material is issued to the
subcontractor, it is treated as company-owned stock at a new location (i.e.
materials supplied to vendors). In R/3, this stock is managed at a plant level,
because the stock is not stored on the company’s premises but rather at the
vendor’s site. Component materials are deemed consumed at the point that
the finished material is received as part of company-owned stock.
)LJ7\SLFDO6XEFRQWUDFWLQJ6FHQDULR
Such orders might, for example, be used in the oil industry to monitor and
account for issues of material to a third-party refinery with the aim that a
final blended product be returned.
TDP provides a mechanism for calculating and controlling excise duty
postings during the process of third party “manufacture“ at a subcontractor.

The excise duty postings made at the time of issue of material to a subcontracted
order, and at the time of receipt of the finished product, are entirely user-
definable. The figure below gives one example of how the system can be
configured for subcontracted orders.
)LJ([DPSOHRI&RQILJXUDWLRQIRU6XEFRQWUDFWHG2UGHUV
Materials provided to a subcontractor are issued to him. For goods issues,
the valuation type from which the materials are issued provides the excise
duty “from“ status of the materials. No financial postings of excise duty
liability or excise duty inventory occur for this transaction. In the figure
above, the following material movements would take place:
q Material “A” is issued: ED-unpaid ½ ED-paid
No excise duty liability posted. Material is moved from unrestricted
stock in the issuing plant, and the stock of material provided to vendor
at the plant level is increased.
q Material “B” is issued: ED-paid ½ ED-paid
No excise duty liability posted. Material is moved from unrestricted
stock in the issuing plant, and the stock of material provided to vendor
at the plant level is increased. The net effect on excise duty inventory is
zero.
When the finished material is received into stock, all excise duty entries are
posted for this material transaction. Materials consumed in the production
process are considered as follows:
The excise duty status “from“ of the component material comes from the
valuation type associated with the material at goods issue to the subcontracted
order.

The excise duty status “to“ for the consumption posting is derived from the
Tax Status “from” defined in the purchase order (i.e. the Tax Status of the
vendor). In the above figure, postings for consumption of materials
provided are as follows:
q Material “A” is consumed: ED-unpaid ½ ED-paid
From row 3 of the sample table set up in the figure “Example of
Configuration for Subcontracted Orders”, it can be seen that no excise
duty claim is posted for the consumption of ED-unpaid material. No
reduction of excise duty inventory occurs.
q Material “B” is consumed: ED-paid ½ ED-paid
From row 4 of the sample table set up in the figure “Example of
Configuration for Subcontracted Orders”, it can be seen that an excise
duty claim is posted for the quantity of material consumed. A reduction
in excise duty inventory is posted.
A separate excise duty calculation is made for the receipt of the finished
product:
q Material “C” is received into stock: ED-unpaid ½ ED-paid
From row 5 of the sample table set up in Figure 13, it can be seen that an
excise duty liability is posted for the quantity of finished material
received into stock. An increase in excise duty inventory is recorded.
The difference between the excise duty liability posted for the receipt of
material into ED-paid stock and the excise duty claims posted for
consumption of duty-paid material represents the net liability to the excise
duty authorities.
Third Party Orders

7KLUG3DUW\2UGHUV It may be necessary to buy oil products for delivery:
q To a third party manufacturer
q To a customer
Special order types or item categories are used for such purchases. In the
standard system, no goods receipt is recorded, as materials do not pass
through the company’s inventory. In order to post excise duty liabilities for
purchased material, it is necessary to record a valuated goods receipt for the
material. This results in the accrual of excise duty liabilities for the goods
receipt, but will not result in an update to inventory accounts. The figure
below depicts a typical third party order scenario.

)LJ7KLUG3DUW\2UGHU6FHQDULR
Supplier´s Consignment Stock Held at Company Premises
The R/3 IS-Oil Downstream Exchanges application area deals with complex 6XSSOLHU·V&RQVLJQPHQW6WRFN
scenarios where agreements exist to lift product from other companies’ +HOGDW&RPSDQ\3UHPLVHV
stock. For details of this functionality, see the chapter on Exchanges.
However, it is also possible that our company may wish to make a straight
purchase from a supplier on a consignment basis. Supplier’s consignment
stock is defined as stock which remains the supplier’s property while on our
premises, but which will become our company’s stock at the moment we lift
the product. We are assumed to have an unlimited right to draw off as much
oil product from the consignment stock as is available in the tank.

TDP provides the following solution for processing excise duties.
)LJ3URFHVVLQJRI([FLVH'XWLHV
Material can be received at the company’s premises (as supplier’s stock)
with the same excise duty status with which the material was issued. The
system only allows receipts to ED-unpaid consignment stock from an ED-
unpaid location at the supplier’s premises, or receipts to ED-paid
consignment stock from an ED-paid location at the supplier’s premises.
Receipts from Purchase Orders

5HFHLSWVIURP3XUFKDVH2UGHUV In line with all material movements, permissible movements for receipts of
oil product (and the resulting financial postings) can be controlled using the
entries in the excise duty/Tax Status table. The financial postings shown
below are examples.
Materials can be received directly to a storage tank (ED-unpaid or ED-paid)
and regarded as available product, or can be received to special “blocked“
stocks where quality inspection may take place. Blocked stocks are treated as
“non-available“ and may not be reserved or issued. Alternatively, oil
products may be purchased for immediate consumption at receipt.

Receipts to inventory: excise duty postings covering a variety of scenarios for

receipts from purchase orders to available inventory might look as follows:
)LJ([FLVH'XW\3RVWLQJV
Receipt to blocked stock: Dutiable material can be held as blocked stock
with an excise duty status. Excise duty postings take place for the situation
in which the material is received to blocked stock. Blocked stock can be
valuated, which means that movements to and from blocked stock can
create the required excise duty postings.
)LJ5HFHLSWWR%ORFNHG6WRFN

Receipts to consumption: If a non-stock oil material is purchased with the

intention that the costs associated with procurement be charged to expense
on receipt, the excise duty portion of the cost is separately expensed. Cost
accounting postings for excise duty values can go to a separate cost center,
and can be distributed among user departments. Postings are as follows:
)LJ&RVW$FFRXQWLQJ3RVWLQJVIRU([FLVH'XW\
Multiple Excise Duty Rates (Tax Elements) for a Purchase
0XOWLSOH([FLVH'XW\ It is possible that a number of excise taxes are applied to a single goods
5DWHVIRUD3XUFKDVH movement of taxable material. For example, in some countries, additional
environmental taxes may be levied on movements of oil product. R/3 IS-Oil
Downstream offers the capability to:
q Specify up to six “tax elements“ relating to a single movement of taxable
material. All tax element excise rates must be based on the same taxable
rate unit of measure and must be based on the same dutiable quantity
for the movement. Likewise, all tax elements must share the same
validity period. Tax elements are defined in the excise duty Rates table.
The cumulative value of excise duties are displayed on the main screen.
q Charge each tax element to a different account.
([FLVH'XW\+DQGOLQJIRU3URGXFWLRQ
Standard Production Processes
6WDQGDUG3URGXFWLRQ3URFHVVHV Oil companies may wish to handle a scenario where materials are combined
in a productive process to produce a new, finished material. A typical oil
scenario might be the blending of oil product at a refinery to produce a new
material.

Materials issued to a production process may be oil materials or non-oil

materials, or a mixture of the two. For oil materials, it is possible to control
whether it is permitted to issue ED-unpaid product to the production
process by the type of the material. When a material with an excise duty
status is used, the user can obtain information about the tax.
The TDP functionality assumes that during production, the process takes
place as either an “ED-unpaid process“ or an “ED-paid process“. In other
words, the production order carries an excise duty status. This is the status
to which raw materials are issued. It is also the excise duty status from
which the final product is received.
The final material created in production may be either an oil product or a
non-oil product. If the material is an oil-product, excise duty liabilities and
excise duty inventory are posted for the receipt of the final material to stock.
To summarize, excise duty postings (excise duty liabilities and adjustments
to excise duty inventory) are made on the basis of the tax movements which
occur:
q For the issue of component materials to the production process
q For the receipt of the final product to inventory
)LJ,VVXHRI*DVRLOIURPD'XW\SDLG6WRFN
In the figure above, it is permitted to issue a gas oil from an ED-paid stock in
the production process. The issue is treated as a “ED-paid to ED-unpaid“
movement and an excise duty claim can be posted. It is also permitted to
issue heavy fuel oil from ED-unpaid stocks for use in production. The issue
is treated as an “ED-unpaid to ED-unpaid“ movement and no excise duty
liabilities are posted. Again, it should be stressed that allowable movements
and excise duty liability postings are completely controlled by the user
through the configuration of key tables.
Once the final product (a light fuel oil) is produced, the receipt to stock
occurs from ED-unpaid production to an ED-paid inventory, excise duty
liabilities are calculated for the final material.

([FLVH'XW\+DQGOLQJLQ,QYHQWRU\0DQDJHPHQW)XQFWLRQ
Overview: Inventory Movements
,QYHQWRU\0RYHPHQWV Dutiable material can be received to inventory, managed within inventory,
and issued from inventory using a series of movement types defined in the
R/3 System. Some of these possible movements have been described above.
As already discussed, it is possible to control allowable excise duty
movements (from ED-unpaid to ED-paid location, etc.) in terms of the
business purpose of the movement. Within the R/3 System, the business
purpose of the movement is defined by a combination of event type (issue,
receipt, transfer etc.) and movement type (receipt to blocked stock, issue to
scrapping etc.).
All control of excise duty status with material movements is set in the Excise
Duty/Tax Status table. Users can freely define the excise duty postings
(liabilities and changes to excise duty inventory) associated with a
movement of material.
In addition to standard movement types, it is possible for users to define
their own movement types within the R/3 Core System.
Standard inventory movements to which excise duty postings can apply
include:
Receipts to inventory:
q From purchase orders
q Without purchase order
q To blocked stock
q From blocked stock to available stock
q Returned material from customers
Examples of postings for receipts from purchase orders are given in the
section “Receipts from Purchase Orders”. The R/3 System also offers
movement types to receive stock without a purchase order. Excise duty is
posted in the same way as for receipts from orders. Postings to blocked stock
are discussed in the section “Receipts from Purchase Orders” and in the
section “Returns of Material by Customers”.
Movements within a single depot or other location, for example:
q Material to material movements (used for re-branding the product)
q Movements of material from unvaluated stocks (e.g. vendor-owned
stock) to valuated stocks
If at any point stock which does not belong to the company (e.g. customer
stock held at the company depot) is transferred to the company‘s ownership,
excise duty postings take place based on the Tax Status the material is
moved from and to (material movements between physical sites).
See section “Movements of Material” for an explanation of alternatives and
excise duty implications.

Issues of material from inventory:

q Issues to consumption
q Issues for scrapping
q Issues to production
q Issues to subcontracted orders
If ED-paid material is issued, the excise portion of the material value is
expensed separately from the net material cost and at a separate time. The
cost accounting posting for excise duty is made to a separate cost center
from which a distribution of the cost may be made.
Issues of ED-paid stock to scrap result in an offset posting to a “scrapped
material“ cost account. For this purpose, the excise duty value is to be
posted to a separate “excise duty scrapped material” account.
Revaluation of Excise Duty Value of Inventory when

Excise Duty Rates Change
Excise Duty Rate Changes 5HYDOXDWLRQRI([FLVH'XW\

A requirement exists in certain countries to revaluate ED-paid inventory 9DOXHRI,QYHQWRU\ZKHQ
when the excise duty rate for the material changes. If excise duty rates ([FLVH'XW\5DWHV&KDQJH
increase, the company may face an additional liability for the increase in
excise duty value of stock. Conversely, if excise duty rates decrease, the
company may be able to request an excise duty claim for the decrease in
excise duty value of stock. Companies can decide whether or not they wish
to conduct a revaluation process for ED-paid inventory.
A change in excise duty rates is initiated when a new entry is added to the
excise duty rates table. Changes to excise duty rates may involve changes to
one of the following:
If ED-paid inventory revaluation is switched “on“ in the control table, and
an additional entry for a plant and material tax group is added to the excise
duty rates table, it is necessary to conduct a tax inventory revaluation. It
must be remembered that ED-paid inventory is always valuated at the full
excise duty rate for the plant and material, whenever the ED-paid material is
moved to or out of stock.
Mechanism for Revaluation

The principal aims in designing a revaluation mechanism are:
q To guarantee the integrity of a tax rate revaluation. A single set of
ASTM parameters is required so that the stock quantity on hand can be
converted to the excise duty rate unit of measure prior to excise duty
revaluation. In order to obtain this set of parameters, and also to provide
an agreed quantity for the revaluation, a stock-taking must take place in
the system. This need not be a physical count, however. Functionality is
provided to allow “logical“ stock counts to be performed, where the
book quantities are proposed as the counted quantities.

q To maximize the ability to post material movements during

revaluation. In order to guarantee the integrity of the quantities to be
revaluated, all material movements for the particular material and stock
segment level combination that is the subject of a count are disallowed in
the time period between the posting of the stock count and the posting
of the stock count difference. For example, if the stock count is related to
a normal material item at a storage location, then material movements
for that particular combination of material and storage location are not
allowed. If on the other hand, the count is related to a special stock, then
material movements involving at the individual material stock segment
level are disallowed.
Assume a “future“ rate is added to the excise duty Rates table for Depot 01
and excise duty Group C4. A movement is posted with a posting date within
the validity period of the new rate. The system updates a future quantity
and a future value field in the valuation record.
Where an historic rate of excise duty applies for the posting date (and a tax
revaluation has taken place), the system posts any liability with the excise
duty rate applicable for the historic rate. However, because inventory
revaluation has taken place, any posting to excise duty value of inventory is
made at the current rate. An excise duty difference is posted.
q To provide a flexible approach: The approach supports the flexibility of
tax rate definition. A more simplistic approach would have limited the
ways in which excise duty rates could be defined. Revaluation of ED-
paid inventory is an optional feature and can be switched on and off at
the plant level, according to legal requirements.
Separate field groups track quantities posted in a period where a “current“
tax rate is in force and of quantities relating to a “future“ rate of taxation.
The process of revaluation rolls all “future“ quantities into the “current“
quantity field. The way in which the process operates may be illustrated in
the following figure:

)LJ3URFHVVRI5HYDOXDWLRQ
Each time a material movement of dutiable material takes place, the posting
date of the material movement is compared to a “check date“ held in the
material valuation record. This determines whether “current“ or “future“
quantities are updated in the valuation record.
Stock-taking transactions have been changed to allow the option of posting
stock-taking with or without the posting of a tax rate change.
If ED-paid inventory is to be revaluated, stock-taking must first take place.
The postings that will arise are as follows:
q Excise duty inventory account (differences from stock-taking only)
q Excise duty losses/gains from stock-taking
q Excise duty differences from the tax rate change
q ED-paid inventory account (differences from tax rate change)
Stock-Taking
ED-paid Product 6WRFN7DNLQJ
It is possible within the R/3 System to adjust the duty-paid inventory
account to reflect any addition to, or reduction from the quantity of duty-
paid inventory recorded as a result of stock-taking. When a revised
inventory count is entered into the SAP R/3 System, the following postings
occur:

)LJ,QFUHDVHLQ('SDLG,QYHQWRU\6WRFNWDNLQJ
)LJ5HGXFWLRQLQ('SDLG,QYHQWRU\6WRFNWDNLQJ
ED-unpaid Product
As a general rule, changes in the recorded quantity of ED-unpaid product as
a result of stock-taking do not result in excise duty postings.
However, some countries (notably Belgium and France) operate a system of
allowances for stock losses. Losses of ED-unpaid product above a certain
allowance result in excise duty liability for the portion above the allowance.
Gains of ED-unpaid product within an allowance may be sold without
liability to excise duty.
TDP deals with the use of allowances for gains/losses of ED-unpaid
product, prior to excise duty claims or liabilities being recorded. These
allowances are defined in a table, which calculates the excise duty values
and creates the postings.
Customer Stock
&XVWRPHU6WRFN Where an oil company acts as the facilities manager for a depot, it may be
the case that other oil companies choose to store product at the same depot.
The facility manager needs to control the quantity of a product which
“customer“ oil companies can lift.
The facility manager is responsible for the payment of excise duty for lifted
quantities of ED-unpaid stock which is to be moved to an ED-paid location,
whether these quantities are the facility manager’s own stock or another oil
company’s stock. The facility manager may be able to bill the excise duty
charge to the company that owns the stock in certain circumstances.
Customer stocks are unvaluated in that stock values are not recorded in the
company’s books, whereas the company‘s own stocks are valuated. When a
third party stock is moved, the customer stock number must be included in
the movement. Excise duty liability postings are still made when a customer
quantity is moved from a ED-unpaid location to an ED-paid location.

0RYHPHQWVRI0DWHULDO
Internal Transfers of Material
Dutiable material may be moved between company-owned locations with ,QWHUQDO7UDQVIHUVRI0DWHULDO
implications for excise duty postings.
The full R/3 IS-Oil Downstream solution for inter- and intra-company
transfer of material is covered by the Transport and Distribution (TD)
application area. TD enables scheduling, loading, delivery confirmation and
load balancing to be handled for all methods of transport. For a full
description of functionality in this area, please refer to the chapter on TD.
Excise duty values are calculated and posted for each relevant material
movement.
However, some companies may not wish to use the TD functionality, or may
wish to interface specialized distribution systems to the R/3 System. For this
reason, TDP functionality ensures that excise duty handling takes into
account standard R/3 System functionality to handle transfers of material
between locations. The technique used by a company to track material in
transit between two locations varies based on the company’s requirements
and the nature of the method of transport, e.g. pipeline versus truck. Three
broad scenarios can be identified:
q One-step transfers: In this scenario, the material movement is recorded
in the system as an “instantaneous“ transfer from one location to
another. There is no provision for intransit stock tracking and no
possibility to record gains or losses. These transfer types are suitable for
“local“ transfers, such as tank to tank, tank to truck, or truck to tank.
q Two-step transfers: In this scenario, material is first moved from one
location to “intransit” storage and thus in a separate movement from
intransit storage to the receiving location. Intransit stock quantities can
be monitored by “tracking number” (equivalent to a shipment) and
gains and losses can be calculated per shipment. This functionality is not
in the standard R/3 System and is developed as part of the HPM
application area as detailed in the chapter on HPM.
q One and two-step transfers against a “transport“ order. This provides
the same basic functionality as described above, but adds the use of a
transport order to record the “sale“ of material from one plant to
another. A delivery note is created for the order and contains projected
loading and delivery dates.

Excise Duty Values for Two-Step Transfers without TD Integration

([FLVH'XW\9DOXHVIRU General Posting Rules for Excise Duty Values
7ZR6WHS7UDQVIHUVZLWKRXW q Excise duty liabilities (arising when taxable material is moved out of or
7',QWHJUDWLRQ to an ED-unpaid area): If the receiving location is ED-unpaid, liabilities
are posted for the goods receipt only. If the receiving location is ED-paid,
liabilities are posted for the goods issue only.
q Excise duty relief/reduction (arising when taxable material is moved
with a reduction in duty): If the receiving location is ED-unpaid,
relief/reduction is posted for the goods receipt only. If the receiving
location is ED-paid, relief/reduction is posted for the goods issue only.
q Excise duty rate differences (arising when the tax rate applicable at the
sending plant is different from the tax rate at the receiving plant): Tax
differences are only posted for the goods issue only. Differences are
only posted where a transfer takes place between two ED-paid locations.
q Excise duty rate changes (arising when a change in tax rate takes place
for the receiving plant between the time the material is issued from the
sending plant and received): Tax changes are only posted for the final
receipt once the gain or loss for the total transfer is known.
q Excise duty gain/loss (associated with a physical gain or loss of duty-
paid product) is posted for the final receipt of all product associated with
a shipment (transport number).
Posting Rules for Material Quantities

Quantities in transit are updated at the plant level. Unrestricted use stock
and total stock quantities are updated at a lower level.
To facilitate the handling of gains and losses, the quantity in-transit may be
negative. The balance of the quantity in transit against a single transport
number must be reduced to zero when the gain and loss postings are
completed.
Examples of Excise Duty Postings

In the examples shown below, the following assumptions have been made:
q Excise duty rates at both plant 01 and plant 02 are the same
q Excise duty rates do not change during the cycle of the plant-to-plant
transfer
q A single issue and a single receipt are made
q The price of material at plant 01 and plant 02 is identical

q Issue unit of measure, stock unit of measure and tax rate unit of measure
are identical
q Issue and receipt take place on the same day: 01.01.97
Changes in quantities are shown below the line in each “T“ account.
)LJ('XQSDLGWR('SDLG0RYHPHQWZLWK/RVV

)LJ('XQSDLGWR('SDLG0RYHPHQWZLWK*DLQ
In the example below, the following assumptions have been made:
q Excise duty rates between plants can vary
q Excise duty rates are assumed to change during the cycle of the transfer
q Reduced rates of excise duty are applicable
q The price of material at plant 01 and plant 02 is identical
q Issue unit of measure, stock unit of measure and tax rate unit of measure
are identical

)LJ([FLVH'XW\5DWHV7DEOHIRUWKH([DPSOH%HORZ
)LJ('XQSDLGWR('SDLG0RYHPHQWZLWK/RVV'LIIHUHQW([FLVH'XW\7D[
5DWHVDW'LIIHUHQW3ODQWV5HOLHI5HGXFWLRQ5DWHRI([FLVH'XW\('7D[5DWH
&KDQJH'XULQJ7UDQVIHU

Handling of Gains and Losses

Excise duty gains or losses are posted for the associated inventory gains and
losses. Gains and losses are attributed to the receiving plant. A periodic
calculation of gains and losses by analysis of transport number is possible.
The transfer cycle would be closed manually after user criteria have been
met (for example that no further movement has taken place against a
transport number in the last ten days). At this point a final goods receipt is
posted with a zero quantity, and the final delivery indicator is set.
([FLVH'XW\+DQGOLQJLQWKH6DOHVDQG'LVWULEXWLRQ
Movements of dutiable materials within the Sales and Distribution need to
be considered for their potential excise duty impact. Examples of the factors
that need to be taken into account include:
q The Tax Status of the product to be sold: This is determined in the
system by the selection of a valuation type or batch, from which material
is deemed to be taken (see section “Excise Duty Status”). This is entered
in the scheduling or load confirmation function of R/3 IS-Oil
Downstream.
q Whether the customer has authorization to buy the product at a
reduced rate of excise duty: Licenses are maintained in master data
tables. During order entry, a license (if required) is defaulted from this
master data, if it satisfies the matching criteria for the order line. To
make sure that the right license type is determined, there must be a
connection between the license type and the condition type in the
pricing procedure.
q The end use that the customer puts the product to and whether this
use requires autorization from the excise authorities: A “handling
type” code signifying the end use of the product sold may be stored in
the customer record, or the sales information record. This information
may also be entered directly in the order.
q The Tax Status of the location where the customer puts the product,
ED-unpaid or ED-paid: The excise duty status at receipt by the customer
is defined by the handling type.
q The date of the material movement: Valid from dates are defined for
excise duty rates.
q The total product cost, if excise duty is included in the total price:
excise duty rates are set out in an excise duty rates table. If the user
wants to specify an excise duty rate which is different from the one used
to record the liabilities, they can do so by using the price condition
records. The standard pricing procedure proposes an excise duty value
for the ordered quantity in all sales quotations and orders. See the
section entitled “Excise Duty Handling in Sales Orders”.

Excise Duty Handling in Sales Orders

The R/3 System offers many forms of “sales order“. It is possible to raise ([FLVH'XW\+DQGOLQJLQ6DOHV
quotations, orders, contracts, scheduling agreements and deliveries in the 2UGHUV
system.
Defaults for excise duty handling are passed to the sales order from
customer records or from sales information records. Data can be taken from
the customer, payee or consignee in the order.
In all sales orders, the excise duty value associated with an order for ED-
paid stock can be calculated and displayed. A standard R/3 System pricing
procedure is used to calculate excise duty within a specific order. Similar to
the functionality provided for purchasing, two types of price condition are
allowed:
q External Excise Duty: These select an excise duty rate automatically by
reading the excise duty rates table in the system using excise duty
parameters within the sales order item.
q Internal Excise Duty: These allow the user to specify the rate of excise
duty applicable within the gross price via price condition records. The
user can then accept the price proposed by the system or enter a price
manually.
The system adds the excise duty portion to the material price to give a valid
gross price for the material. For goods issues, the system posts the net
material cost to inventory (or expense).
This concept means that if users want to use the same excise duty rates in
the billing as was used in the liability posting, one set of reference data for
the duty rates needs to be maintained, namely the excise duty Rates table.
Conversely, if users want to specify alternative rates, they can do so by
creating price condition records. The figure below portrays this scenario.
)LJ3ULFH&RQGLWLRQ5HFRUGV
For the manual price conditions a series of “price condition“ records may be
defined for excise duty rates. Such records indicate an excise duty rate for a
quantity of material. Each price condition record has a user-defined “key“.
Two key structures are provided with the R/3 IS-Oil Downstream System.
The keys in each case are:
Other fields in the condition record are:
q Validity period
q ASTM/API unit of measure (base for excise duty calculation)

q Duty rate (per duty quantity)

q Duty quantity
The condition record mirrors the set-up of the Excise Duty Rates table that is
used for excise duty handling in the R/3 Materials Management function.
During order creation, the system searches for excise duty condition records
with a key structure which matches the data in the order. If found, the excise
duty rate is applied to the material quantity and the calculated value is
added to the total order cost.
Tax Elements
7D[(OHPHQWV It is possible to have several excise duty tax rates associated with a sale of a
material. Additional excise and environmental taxes may be levied on a sale.
This scenario mirrors the one described for the purchasing function. Tax
elements for excise duty calculations in the Sales and Distribution function
are the same as those defined for the Purchasing function, i.e. they are held
in the excise duty rates table. In addition, users can define tax elements in
price condition records, if they do not want to use the same rates as those
used for the liability posting.
Up to six excise duty tax elements can be defined. The set-up of excise duty
tax element price conditions in the Sales and Distribution function should
mirror the set-up of tax elements within the excise duty Rates table.
The standard functionality for condition records ensures that calculated tax
elements for an SD document can be stored as separate condition types. In
addition, it is possible to post each excise duty element separately to the
general ledger.
Excise Duty Handling in Sales Invoices

([FLVH'XW\+DQGOLQJ When creating a sales invoice, it is possible to pull over the prices (and
LQ6DOHV,QYRLFHV excise duties) defined in the order without further revision. However, it is
also possible to “reprice“ in the invoice, a process which reevaluates some or
all of the condition records associated with an order and redefines the price
of the product if conditions have changed. The mechanism for recalculating
excise duty in the invoice is identical to that used in sales orders. However,
certain key criteria in the calculation of excise duty are different:
q The quantity used for the excise duty calculation in the invoice may be
the ordered quantity, the loaded quantity or the confirmed (delivered)
quantity
q The date used for pricing in the invoice (and hence selection of excise
duty rate) may be: the date invoice is entered in the system, the date of
loading, the date of delivery, etc.

Licenses: Relief and Exemption Handling
Overview /LFHQVHV5HOLHIDQG([HPSWLRQ
Authorities responsible for the collection of excise duties will often issue +DQGOLQJ
licenses or permits to traders and require that the license reference numbers
be quoted whenever dutiable material is moved.
In R/3 IS-Oil Downstream, excise licenses can be created, maintained and
displayed. The presence of a license affects the processing during movement
of dutiable product, where license type “rules” are used in the determination
and possible exemption/reduction of the amount of excise duty calculated.
A number of different license types are available in the system (described
below) and it is possible for a user to create new license types with reference
to an existing license type.
The license types indicate a different processing method and the use of a
different selection of the license master data. The major differences in
processing are that:
q Excise duty (Europe) and pre-paid permits (Singapore) deal with both
movement tax and customer invoicing implications
q North American methods are concerned with the tax determination and
licencing issues, at the time of invoicing only
q Vendor licenses are held for record purposes
License Master Data

It is possible to create, change or display licenses.
Excise Duty License Types

Customers who buy dutiable oil products may have an exemption certificate
(for a specific period), which frees them from paying excise duty.
Alternatively, a customer may have an authorization number (again for a
specific period) which reduces the excise duty payable to the supplier.
An excise duty license is always dependent on a customer specification
(customer number or customer group), a material specification (material
number or material group) and the handling type. The license applies for a
specific period.
The entry of a company code is optional, but if used, the license is valid only
for that company code. A maximum quantity may be entered.
In the business transactions like order entry, the system attempts to default a
license if there is one applicable for the transaction data (customer, material,
etc.).

North American License Types:

Federal Excise Tax/State Excise Tax / County Excise Tax / City Excise Tax /
Other NA Tax
These taxes are North American duties which are dependent on a customer
specification (customer number or customer group), a material specification
(material number or material group) and the country. The company code,
the mode of transport and the sales document type are optional. The licenses
apply for a particular location, which is:
q For the Federal Excise Tax, the country
q For the State Excise Tax, the state code or an entry in the alternate
location field
q For the County Excise Tax, the state code and the county code or an
entry in the alternate location field
q For the City Excise Tax, the state code and the city code (county code
optional) or an entry in the alternate location field
q For the Other NA Tax, the state code and the city code or the state code
and the county code or the state code, the county code and the city code
or an entry in the alternate location field
The State Excise Tax in most cases applies only for the destination. In
some states the tax applies for the origin as well. These states are
registered in an interstate table.
The condition types, which identify the different “excise” taxes, are linked in
a separate configuration table to the applicable license types. Multiple
condition types can be linked to one license type.
The customer tax group field in the customer master minimizes the number
of license and condition records required for exempt groups, such as
governmental agencies and schools. An “alternate” material group field is
also available for minimizing the number of licenses.
The Interstate table only requires the entry of specific states or jurisdictions
that require licenses at the origin plant. The Interstate table includes the
condition type, the state, county, or city that requires the appropriate license,
and the valid “from” and “to” dates.
Rather than modifying the supplied “user exits,” users can use the standard
pricing condition access sequences to achieve unique requirements, such as
the following:
q A match on customer specific value using core pricing techniques would
stop the access sequence search, if a condition record was found. The
customer- specific conditions are applicable for FOB (customer pick-up
at company “plant”) transactions, with FOB identified in the “Incoterms
1” field.

q A match on plant-specific situations not covered by the standard tax

exemption determination user exits, applicable for FOB transactions,
would allow the search to continue to the next sequence. Included in this
condition would be the new North Carolina tax rules.
q The final FOB access sequence would check for standard condition type
tax records, followed by the tax exemption determination user exit for
license validation.
A “sales order type” field is included in the license data to satisfy a
Canadian legal requirement to enable specific customers to be tax-exempt on
exchange related transactions, while being non-exempt for normal sales
transactions.
Vendor License
For reporting purposes, it is possible to store vendor licenses in the system.
These licenses have no functionality of their own. The vendor number is
mandatory, the company code is optional.
Pre-Paid Permit
This license type deals with those licenses which are issued for a defined
quantity of dutiable material. The company pays a specified amount for the
license and is entitled to sell an agreed quantity of material from an ED-
unpaid area. The cost of the license is in effect prepaying the tax liability.
The license may apply to a group of materials which have a common rate of
tax. Each time there is a delivery of the defined material, the quantity
balance for the license is reduced until it is exhausted. A follow-on license
may be specified for additional delivery quantities.
Mandatory inputs are a customer specification (customer number or
customer group) and a material specification (material number or material
group). A company code and a country are optional. The license applies for
a specific period.
Duty-Free Permit
The duty-free permit is a license which allows transfers of product between
two ED-unpaid areas or allows the customer to buy duty-free (this would
typically apply to an export customer or to a special-use customer such as
the armed forces).
The permit is dependent on a customer specification (customer number or
customer group) and material specification (material number or material
group). A company code and a country are optional. The license applies for
a specific period.
Control of Reduced Excise Duty Rates

A reduction in excise duty is indicated by a specific handling type in the
Excise Duty Rates table. For each material tax group, it is possible to specify
reduced rates of excise duty associated with specific user-defined handling
types. The relationship between a handling type and the requirement for
excise duty license details is specified in a reference table. The predefined
excise price conditions can also be used to handle reduced rates.

Validation of Exemption Licenses and Authorizations

Licenses are validated in the sales order and invoice.
Returns of Material by Customers

5HWXUQVRI0DWHULDOE\ It is possible that dutiable oil products may be returned by customers,
&XVWRPHUV perhaps because an unacceptable degree of contamination has occurred and
the customer wishes to obtain replacement product. In such cases, it is
necessary to make a special “returns“ order in the R/3 System. This order
has no formal link to the original sales order.
It is also possible to create a credit memo for the customer for the value of
the material returned. Prices and excise duty values are calculated using
price condition records. If the value of the credit memo is based on the date
of return of material to stock, it is theoretically possible that the excise duty
value credited to the customer is different from the original excise duty
charged, if the excise duty rate has changed between goods issue and goods
return. However, the excise duty value can be “overwritten“ in the credit
memo with a manual entry.
At the time of material return, care should be taken that the excise duty
parameters (Tax Status “from“ and “to“ and handling type) reflect those
used in the original sales order.
([FLVH'XW\+DQGOLQJIRU7UDQVSRUWDQG'LVWULEXWLRQ
Key areas that are covered by TDP include:
q It is possible to make excise duty postings based on material movements
with respect to product loading or to unloading at the customer site.
q The process that calculates and posts excise duty can handle cases where
modes of transport (truck, ship, etc.) are deemed to be ED-unpaid or ED-
paid locations in their own right, or with cases where the Tax Status
associated with the customer is used for the product in the truck.
q Excise duty gains and losses are calculated and posted for the material.
Duty Liability versus Duty Billed Discrepancies

'XW\/LDELOLW\YHUVXV'XW\ The broad rule is that excise duty liabilities to the customs authorities
%LOOHG'LVFUHSDQFLHV booked for the selling company should match the excise duty billed to the
customer. This can be achieved by ensuring that the excise duty rates to be
used in the R/3 MM Module (defined in the Excise Duty Rates table) match
the excise duty rates to be used in the R/3 SD Module (defined in price
condition records).
However, users are able to configure the system so that differences between
booked liabilities and billed duty may arise.
For example, in some countries, it is allowable to base excise duty liabilities
on quantities of product measured at a standard temperature, while excise
duty billed to the customer may be based on the quantity of oil product
delivered in ambient liters. Differences between excise duty liabilities

booked and excise duty billed will occur in this case. The TDP process which
calculates the duty postings, includes parameters to enable users to specify
whether excise duty should be balanced, that is, whether additional excise
duty liability/claim postings for the difference will be made.
If excise duty is not to be balanced, the process tracks the excise duty
liability booked against the excise duty billed and accounts for any
differences. Differences are treated as a “windfall profit or loss“ with an
appropriate adjustment to revenue.
Excise duty liabilities may be posted for the material movement representing
the loading (scheduled quantity) or the movement representing the delivery
at the customer location (confirmed quantity). Differences between the
posted liability and the excise duty billed to the customer can be tracked in
the delivery note. The system posts differences for the final goods receipt (if
invoicing is completed before the delivery is recorded) or for the invoice
creation (if delivery is completed before invoicing). Any difference is posted
as a “windfall profit/loss“ against a revenue account.
Excise duty postings associated with a difference between posted excise
liabilities and billed excise duty would look as follows. It should be noted
that values only (and not quantities) are balanced in the difference posting.
)LJ([FLVH'XW\3RVWLQJV$VVRFLDWHGZLWKD'LIIHUHQFHEHWZHHQ3RVWHG([FLVH
/LDELOLWLHV %LOOHG([FLVH'XW\
It is possible to specify whether excise duty balancing is required. In
addition, a further indicator must be set to identify whether vehicles used
for transportation are regarded as ED-unpaid or ED-paid locations in their

own right; or whether the Tax Status of loaded product within a vehicle is
taken from the customer’s intended use of the product.
([FLVH'XW\+DQGOLQJIRU([FKDQJH)XQFWLRQV
Requirements for excise duty handling with respect to processing of oil
product exchanges primarily focus on the integration of standard excise
duty techniques with specialized invoice processing functions required for
oil-product exchanges.
Invoices for exchanges may involve the billing of product costs only, fees
only, excise duties only, or any combination of these. A more detailed
description can be found in the chapter on Exchanges.
Excise duty values continue to be calculated for purchase and sales orders
using standard excise duty techniques:
q Excise duty values in “purchase“ agreements can be specified in the
contract using the price condition technique, if the material price
includes excise duty. For goods receipts, excise duty liabilities are
calculated using the rates in the Excise Duty Rates table.
q Excise duty values in “sales“ agreements can be specified using either
the price condition technique or the Excise Duty Rates table. For goods
issues, excise duty liabilities are calculated using the rates in the Excise
Duty rates table.
Excise Duty for Exchange Invoices
([FLVH'XW\IRU([FKDQJH Invoices for exchanges may include any combination of fees, duties and
,QYRLFHV material costs. It is also possible that all invoiced charges may be “netted“
under the agreement with a periodic settling of accounts.
For product received from exchange partners:
q Pure material exchange - no product costs are invoiced. For goods
receipts, excise duty is charged to the goods received/awaiting invoice
accrual account. For invoice receipts, the excise duty portion is matched
to the entry on the goods received/awaiting invoice accrual account.
Fees are matched separately.
q Exchange with material costs billed. In this case, for goods receipts,
excise duty is added to the material cost and a single posting is made to
the goods received/awaiting invoice accrual account at goods receipt. If
an invoice is received, the material and excise duty portion of the cost is
cleared as a single item. Fees are matched separately.
In the case of invoice netting, all charges under the exchange agreement are
cleared and a net payable or receivable is booked against the vendor or
customer account for the exchange partner, as appropriate. For full details of
the netting process, please see the chapter on Exchanges.

5HSRUWLQJ
The TDP application area provides the FI-Special Ledger (FI-SL) structure
for reporting. A line item table and a summary table structure is provided.
The ledger structures enable users to report excise duty postings based on a
variety of key fields, for example:
q Company code
q Plant
q G/L account
q Valuation type
q Tax Status moved from
q Tax Status moved to
q Handling type
The process which calculates and posts the excise duty values also
“populates” the excise duty Special Ledgers. The figure below shows the
relationship of data held in a source document used for excise duty posting
and the data that can be held within the excise duty special ledgers.
The excise duty Special Ledger collects details from all transactions
involving dutiable materials, including those that do not involve an excise
duty posting, such as ED-unpaid to ED-unpaid transactions and transactions
made at an excise duty rate of zero.
With the excise duty Special Ledgers installed, the standard R/3 Report
Writer or Report Painter can be used to build custom reports.
)LJ'DWD5HODWLRQVKLSV

&KDSWHU
%XON'LVWULEXWLRQ5HTXLUHPHQWV3ODQQLQJ
%'53DVSDUWRI,62LO'RZQVWUHDP
+LJKOHYHOVXPPDU\
One of the building blocks of effective supply chain management in the Oil
& Gas industry is the accurate modelling of controls and constraints which
affect the handling of bulk materials.
The SAP IS-Oil Downstream Bulk Distribution Requirements Planning

application area will provide a range of tools and process optimizations
which are intended to support bulk material supply chain modelling across
the extended enterprise.
The first steps towards this objective is the development of a range of master
data extensions which facilitate the control and definition of objects used by
bulk supply chain management processes.
.H\IXQFWLRQEHQHILWV
A range of key function benefits are provided at the current release of the
SAP IS-Oil Downstream (Bulk Distribution Requirements Planning) Bulk
Replenishment application:
q The site control parameters function benefit allows you to set site
controls in your system.
q The replenishment control parameters function benefit supports the

setting of replenishment control parameters in your system.
q The storage objects function benefit allows you to define objects that
store materials in your system.
q The sales meters function benefit supports the definition of sales meters
in your system.

%XON'LVWULEXWLRQ5HTXLUHPHQWV3ODQQLQJ%'53DVSDUWRI,62LO'RZQVWUHDP
.H\,62LOIXQFWLRQVVXSSRUWHGE\WKH5,62LO
'RZQVWUHDP&RPSRQHQW
The following master data objects exist at the current release of the SAP IS-Oil
Downstream (Bulk Distribution Requirements Planning) Bulk Replenishment
application:
q Site control parameters
q Replenishment control parameters
q Storage objects
q Sales meters
In addition some demonstration Internet transactions are provided to allow

users of IS-Oil BDRP to experiment with some of the processes which will be
fully realised in future releases of the product.
.H\,62LOIXQFWLRQVVXSSRUWHGE\WKHFRUH5V\VWHP
IS-Oil BDRP master data objects always appear in the system as sub-objects
of other master data objects. This means that access to BDRP master data
objects is always via a higher level object. For example, the BDRP master
data object ’storage object’ is stored in the system in one central place, but is
referenced for maintenance purposes by its owning object. Owning objects
in the case of storage objects can be customer ship-to parties or IS-Oil MRN
business locations.
'HWDLOHGGHVFULSWLRQRI%XVLQHVV)XQFWLRQV6XSSRUWHGE\
WKH,62LO'RZQVWUHDP%'53&RPSRQHQW
6LWHFRQWUROSDUDPHWHUV
There is a requirement to record information at the site level which is used to
control or influence bulk logistical processes such as delivery planning,
shipment scheduling and unloading operations. For example, the forecasting
of a replenishment event in terms of quantity and time is dependent on a
number of factors. One of these factors is the link between consumption of
bulk product at a retail site and the opening hours of that site. If a retail site is
not open for business over the weekend period, no product will be sold at the
site and so no consumption will occur.

IS-Oil BDRP Site Control Parameters component can be used to record such
site level information which is specific to bulk material handling processes.
The mechanism provides an additional screen for standard site management
dialogs, in which both a standard set of site control parameters and user
installation defined site characteristics can be maintained.
Initially, the Site Control Parameter maintenance screen will be available
from the SD customer ship-to party maintenance dialog and the IS-Oil MRN
business location maintenance dialog.
3HULRGVZKHQFORVHGIRUVDOHV
'LIIHUHQWVWRFNRXWSRLQW
6DPH526
Fig. 8-1: The effect of sales hours on replenishment calculations.
5HSOHQLVKPHQWFRQWUROSDUDPHWHUV
You can enter parameters to control replenishment at a delivery site using
the IS-Oil BDRP Replenishment Control Parameters screen. An additional
screen is provided within delivery site (e.g. customer ship-to) master data.
In this screen you can define replenishment control parameters for each
replenishable material at the customer site.
An additional function benefit of IS-Oil BDRP Replenishment Control

Parameter component is a structure for recording the stock figures entered
from external system for the delivery site.
&XVWRPHU
&XVWRPHU 0DW*US
0DW*US 0DWHULDO
0DWHULDO 6WRFN
6WRFN 7DUJHW
7DUJHW 5HRUGHU
5HRUGHU 6DIHW\
6DIHW\ 8R0
8R0 5R6
5R6
667
667 81/'
81/'

//

667
667 81/'
81/'

//

667
667 ',(6(/
',(6(/

//

667
667

//

667
667 81/'
81/'

//

667
667 81/'
81/'

//

667
667 ',(6(/
',(6(/

//

667
667

//

//

([SUHVVHGDVUDWHSHU
$FWXDOVWRFNUHRUGHUOHYHO IUHTXHQF\RIDQDO\VLV
Fig. 8-2: Stock report for a delivery site based on external data.

The IS-Oil BDRP Replenishment Control Parameter component is supplied

in prototype form only at the current release. Processes which use the data
contained in this screen are currently being developed. The structure of this
screen and the field definitions on this screen are subject to change, before
these processes are implemented.
6WRUDJHREMHFWV
In connection with bulk material handling processes such as delivery
planning, scheduling and unloading operations there is a requirement to
record information about the tanks, containers or silos which are used to
receive the bulk material.
For example, the available capacity of customer storage for a particular

material should be known before a delivery is scheduled to that customer, in
order to avoid unnecessary returns or even hazardous overflows. In another
case it may be mandatory to confirm the compatibility of the target stock
receiving object with the material to be unloaded, to prevent damage or
contamination.
The IS-Oil BDRP Storage Object Characteristic component provides a

standard technique within the system to define and maintain one or many
storage objects for any given stock holding object within the R/3 system. At
the current release storage objects can be defined for the following stock
holding objects:
q Customer Ship-to
q Business Location.
The Storage Object Characteristic component is used to record information

about storage objects which is specific to bulk material handling processes. For
each storage object, the component provides screens for basic specifications,
maintenance data, assignments and linear/volumetric conversion data.
Individual storage objects are created with reference to storage object types
which are maintained in customizing. Storage object types serve both to type
storage objects and as reference storage objects for specification and
linear/volumetric conversion data.

.:,.),//
6WDWLRQFDQ
EH6KLSWRRU
$FFHVVPRGHLV6KLSWRVHTXHQFHQXPEHUVHT 051%XVLQHVV
QUFDQEHDOORFDWHG /RFDWLRQ
DXWRPDWLFDOO\

RUPDQXDOO\ ,QIRUPDWLRQDOWDQN
JURXSLQJFDQEH
;< ;= DSSOLHGXVLQJ62WR
62DVVLJQPHQWV
7DQNJURXSLQJIRU
UHSOHQLVKPHQWSURFHVVLQJ ',(6(/,62
LVE\PDWHULDODVVLJQPHQWVDOHV
DQGVWRFNOHYHOVDUHDJJUHJDWHGDW6KLSWRPDWHULDOOHYHODW
FXUUHQWVSHFLILFDWLRQVFRSH
Fig. 8-3: The allocation of storage objects to a site object within IS-Oil
A facility is provided within the storage object master data to manage the
conversion of linear dip values to physical volumes. Such conversions are
commonly referred to in the industry as tank strapping conversions.
During a delivery or stock taking cycle the contents of a particular tank/silo

can be evaluated through the use of a dip reading. The dip reading is
normally taken with a calibrated rule inserted into a perforated guide tube.
The guide tube ensures verticality of the rule. The dip reading is used to
measure both depth of product and water in any particular tank or tank
group.
The tank/silo or tank/silo group consist of storage vessels of irregular shape

- typically these shapes will spherical or cylindrical. This means that the
conversion between a linear dip and the volume of product held in the tank
is non-linear. The industry response to this is to define conversion tables
which contain a number of conversion constants. Each conversion constant
consists of two fixed values, one of which represents a linear measure and
the other the volumetric capacity which is contained in the storage object for
a dip of the specified linear value. For a given dip of a specific storage
object, it is possible to ascertain the volume of product contained within the
storage object.
Because the linear and volumetric values of a sequence of conversion

constants do not have to be co-incremental, it is possible to model irregularly
shaped storage objects.

/9&&VHW
&DOFXODWLRQ 8R0/HQ ,QFK
8R09RO *DOORQ
+HDGHU
'HF3OD
'LSUHDGLQJ

9LQSXW

,WHPV

9LQSXW9ORFRQVW 9ORFRQVW

9RXWSXW
9ORFRQVW 9KLFRQVW9ORFRQVW
9KLFRQVW9ORFRQVW 9KLFRQVW
9RXWSXW 86(5(;,72,,&

9RXWSXW
([WHQGHGVWUDSSLQJFDOFXODWLRQ
62&GDWD &DSDFLW\KHLJKWIURRIZHLJKW
0$5$GDWD %DVH8R0
Fig. 8-4: Calculating the volume contained in a tank based on a dip measurement
The IS-Oil BDRP Storage Object Characteristic component supports the

definition of sets of linear/volumetric conversion constants (LVCC sets) for:
q Storage object types, where the conversions apply to all storage objects
of a particular type
q Individual storage objects, where the conversions apply only to a single

storage object
6DOHVPHWHUV
In connection with bulk material handling processes such as delivery
planning, scheduling and unloading operations there is a requirement to
product flow meter data and convert it to product quantities. For example,
the material consumption data of a delivery site is required in order to
calculate replenishment quantities. The data is available in the form of
meter readings. A log is therefore required of each meter installed at the site
along with the assignments of meters to materials at the site. Material
consumption quantities can then be calculated by subtracting the current
reading from the previous reading for each meter, making adjustments
where necessary and aggregating the converted quantities by material.
The IS-Oil BDRP General Meter Management component provides a standard

technique within the system to define and maintain one or many meters for
any given stock holding object within the R/3 system. At the current release
meters can be defined for the following stock holding objects:
q Customer Ship-to

The General Meter Management component is used to record information about

meters which is specific to bulk material handling processes. For each meter,
the component provides screens for basic specifications and maintenance data.
Individual meters are created with reference to meter types.
.:,.),// 6WDWLRQFDQ

EH6KLSWRRU
051%XVLQHVV
/RFDWLRQ
&RPPV
6HTXHQFHQR
DOORFDWLRQDXWRPDWLF OD\HU
81/'

81/'
RUPDQXDOHJVHULDOQR =;
81/'

UNLD95
UNLD98
=;
/,6 &DOFXODWHGHOWDYLDKLVWRU\SURFHVVLQJ
$SSOLFDWLRQ
OD\HU
66DOHV4W\
Fig. 8-5: How the sales meter function benefit will be used to calculate sales
quantities
The IS-Oil BDRP General Meter Management component is supplied in

prototype form only at the current release. Processes which use the data
contained in this screen are currently being developed. The structure of this
screen and the field definitions on this screen are subject to change, before
these processes are implemented.

'HPRQVWUDWLRQLQWHUQHWVFHQDULRV
The BDRP component provides some demonstration Internet transactions to
allow users of IS-Oil BDRP to experiment with some of the processes which
will be fully realised in future releases of the product.
5HWDLOVWDWLRQ +HDG2IILFH
:::
'LSUHDGLQJVSHUWDQN %'537DQNPDWHULDO
7DQNPP
7DQNPP DVVJQPQW
7DQNPP
7DQNPP
4W\VPDWVSHUWDQN
7',(6(//
%'537DQNVWUDSSLQJ
781/'/
781/'/
781/'/
3RVWLQJLQVWUXFWLRQ %'53
6(1' 8SGDWH :537
3RVWLQJFRQILUPDWLRQ :537 6KLSWR
',(6(// FRQILUP VWRFNV
81/'/
81/'/
Fig. 8-6: Process flow of internet scenario which includes determination of

material assignment and use of tank strapping tables.
*ORVVDU\RI%'53VSHFLILFWHUPV
OLQHDUYROXPHWULFFRQYHUVLRQFRQVWDQW
A pair of values which describe a permanent correlation between a linear
quantity and a volumetric quantity. Linear/volumetric conversion constants
form the basis of calculations made to determine the quantity of material in a
storage object for any given measurement of the depth of material in that
storage object.
VWRUDJHREMHFW
Any object in the system for which storage process relevant data need to be
captured. For example, a delivery scheduler needs to know the maximum
capacity of oil tanks at both a plant and a customer business partner.

VWRUDJHREMHFWFKDUDFWHULVWLF
Any variable or descriptive text which describes an object which can be used
to store materials. Some storage object characteristics are entered and
maintained in application specific objects such as plants and storage locations.
Other storage object characteristics can be maintained using the storage object
characteristic maintenance tool.
VWRUDJHREMHFWVHTXHQFHQR
The number of a subordinate storage object in terms of the owning object.
For example a ‘ship-to’ customer may have three storage objects with the
numbers 001, 066 and X74.
VWRUDJHREMHFWW\SH
The technique used to support the definition of common reference data for
storage object characteristic segment instances.
WDQNVWUDSSLQJ
The process whereby the quantity of a material in a storage object can be
determined from the depth of material in that storage object. Accurate tank
strapping requires the maintenance of a large number of linear/volumetric
conversion constants. The system uses these constants to calculate a
volumetric quantity from an input linear measure or tank dip.

Is Oil PDF

Uploaded by

Document Information

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

Is Oil PDF

Uploaded by

Copyright:

Available Formats

&KDSWHU 

([FKDQJHV (;* DVSDUWRI

quantity for purchase agreements assigned to exchange contracts. The

4W\VFKHG 3XUFKDVHFDOORII 6DOHVFDOORII

/RDG%DODQFLQJ 5HSRUWLQJ 4W\VFKHG

3D\PHQW 1HWWLQJ &ROOHFWLRQ

q Create Contracts (Outline Agreements)

Post confirmed delivered quantity/create goods issue.

Assigning Fees and Differentials to Exchange Agreements

Accounting for Material

Create Financial Accounting Entries

Purchasing Agreement (Goods receipt)

Create Financial Accounting Entries

Assignment of Exchange Contract

The key aspects of the financial netting functionality are:

*, *5 /,$ ,QYRLFH 1HJ

Moving Average Price

Revaluation of Logical Inventory

When sub/base product functionality is used the logical inventory is

Quantity Posting Made By the Logical Inventory Adjustment Transaction

Received Quantity = The quantity already received against the call-off

$XWRPDWLF4XDQWLW\ The ASTM/API calculation function enables highly accurate automatic

Clients and Companies

Thus, it is usual (and a legal requirement for excise duty calculations) to

Functions Utilizing Different Units of Measure

Quantity Calculation Method

Units of Measure Available

Material-Specific Information Used in the Quantity Conversion Calculations

Carrying out the Quantity Conversion Calculations

Semi-Automatic Conversion Calculation

Manual Conversion Calculation

Semi-Manual Conversion Calculation

Calculation of Gross/Net Weights and Volumes

Base Sediment and Water Calculation

Gain/Loss Handling with Plant-to-Plant Transfers

Performing Quantity Conversion Calculations When No Goods

Checking the Results of Quantity Conversion Calculations

q Select the materials and locations to be included in the count

enables inventory balances in additional UoM, as well as the stockkeeping

The pricing arrangements can be broken down into two components:

The formula pricing functionality is integrated into the creation of price

The formula and average condition type can be included in pricing

For currency conversion, either the daily exchange rates or an average

In addition, the IS-Oil Downstream time pricing functionality offers the

/LWHUV 'HOLYHU\1RWH 'HOLYHU\1RWH )LQDO3ULFH

&RQWUDFW &DOORII 'HOLYHU\ ,QYRLFH

Formula & Average Value-Based Price Calculations

Formula Definition & Maintenance

The Formula Term Screen

An external quotation may be referenced within each component line. The

user can add further possibilities by customizing the “reference date

m If the quotation factory calendar defines that day as a holiday, then

Defining the Currency Conversion for the Average Value Calculation

External Price Integrity Check Program

q Quotes that diverge from the previous value by a specific percentage or

q Quotes that were not quoted (entries with a No Quote indicator)

q Quotes that are not necessary

Second Level Price Analysis

q Define the format for the item section output

Authorization on Formula Maintenance

Repricing at MM Invoice Verification

A differential invoice itemizes the differential amounts at the condition type

These benefits result in a higher degree of customer satisfaction by requiring

&KDSWHU

([FKDQJHV(;*DVSDUWRI

4W\VFKHG 3XUFKDVHFDOORII 6DOHVFDOORII

/RDG%DODQFLQJ 5HSRUWLQJ 4W\VFKHG

, 5 /,$ ,QYRLFH 1HJ

/LWHUV 'HOLYHU\1RWH 'HOLYHU\1RWH )LQDO3ULFH

&RQWUDFW &DOORII 'HOLYHU\ ,QYRLFH

RRGV 7UDQVIHU RRGV

6KLSSLQJ1RWLI 5HVHUYDWLRQ 'HOLYHU\

RRGV5HFLHSW 0DWHULDO7UDQVIHU RRGV,VVXH

'HOLYHULHV $VVLJQ /RDGYHKLFOHV 5HFRUG