SAP Oil Chapter 1

C|ctet 1
11
Ixt|cages (II6) cs ctt eI
|S0|| 0ewasttecm
h|g| Ieve| Semmcty
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.
1 Ixt|cages (II6) cs ctt eI |S0|| 0ewasttecm
12
key |eatt|ea BeaeI|ts
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:
Online tracking of Logical Inventory Balances for pure exchanges - by
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.
Online automation and integration of exchange accounting provides the
foundation for allowing the oil company to monitor and manage the
profitability of its exchange business on a timely basis.
Lifting controls at the sales and purchase outline agreement level within an
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.
By providing flexibility in terms of the range of types of fees and differentials
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.
Valuation and revaluation of logical inventory enables the system to
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.
|mteve1 |aveatety
Ncacgemeat
Bettet PteI|tc||||ty
Ncacgemeat
kttetcte Cte1|t Ixesere
kac|ys|s
|mteve1 Nctket
keseas|veaess
ke1ete1 ||acat|c|
k1m|a|sttct|ea IIIett
Ixt|cages (II6) cs ctt eI |S0|| 0ewasttecm 1
13
key |S0|| |eatt|eas Seette1 |y t|e
kJ3 |S0|| 0ewasttecm II6 Cemeaeat
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.
Fig. 1-1: Exchange
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:
Ctect|eaJNc|ateacate eI Ixt|cage kgteemeats
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.
11
Fig. 1-2: Definition of an Exchange Agreement
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.
hca1||ag ca1 0eI|a|t|ea eI |ees ca1 0|IIeteat|c|s
Fig. 1-3: Assignment of Fees and Differentials to Exchange Agreements
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.
15
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.
I|It|ag Ceatte|s ca1 C|etks
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.
0ecat|tct|ve tctk|ag eI Ixt|cage Bc|cate
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.
Fig. 1-4: Quantitative Tracking at the Exchange Agreement Level
16
||acat|c| Ncacgemeat eI Ixt|cage kgteemeat
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.
Iec1 Bc|cat|ag
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).
Fig. 1-5: Assignment of Purchase Contract to Customer Delivery
1
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.
Fig. 1-6: Function of the Load Balancing
Ixt|cage kgteemeat hett|ag
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.
Fig. 1-7: Netting Process
18
c|ect|ea eI Ieg|tc| |aveatety
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.
kevc|ect|ea eI Ieg|tc| |aveatety
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.
Ieg|tc| |aveatety k1jestmeats
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.
19
Fig. 1-8: Functions of the LIA Transaction
Se| Pte1ettJBcse Pte1ett |eatt|eas
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.
keett|ag cgc|ast Ixt|cages
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 companys 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
110
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
key |S0|| |eatt|eas Setve1 |y t|e Cete kJ3 System
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.
111
0etc||e1 0estt|t|ea eI Bes|aess |eatt|eas Seette1
|y t|e kJ3 |S0|| 0ewasttecm II6 Cemeaeat
0vetv|ew eI Ixt|cage hca1||ag
This section describes the overall conceptual framework for the proposed
R/3 IS-Oil Downstream component for handling exchange agreements. The
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.
B|||. 1ee ||st
Iec1Bc|cat|ag
0ty. st|e1.
|ees
0ty. st|e1.
|ees
0ty. st|e1.
Pett|cse teattctt Sc|es teattctt Pett|cse teattctt Sc|es teattctt
6ee1s tete|t
Pcymeat
tetess|ag
Ce||ett|ea
tetess|ag
Ixt|cage stctemeat
hett|ag
Ixt|cage |c|cate
I|k
Ieg|tc| |aveatety
Ixt|cage cgteemeat
NN S0
|| ||
0ty. st|e1.
Sc|es tc||eII Pett|cse tc||eII
keett|ag
0e||vety 8
6ee1s |ssee
Se|Bcse
IkS
|ave|te vet|I|tct|ea ket|t|ag
S||t |ave|t|ag
B||||ag
S||t |ave|te vet|I|t.
Fig. 1-9: Business Process - Exchanges
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.
0vetv|ew eI Ixt|cage
hca1||ag
112
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.
113
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 1s 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.
111
Ctecte Ixt|cage kgteemeat hec1et
The exchange agreement header provides a framework to link one or more
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
Ctecte Ixt|cage kgteemeat
hec1et
115
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.
Fig. 1-10: Result of Creating an Exchange Agreement
hca1||ag ca1 0eI|a|t|ea eI |ees ca1 0|IIeteat|c|s
IS-Oil supports the payment or collection of fees and differentials in addition
to the value or quantity of product identified in the exchange.
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
hca1||ag ca1 0eI|a|t|ea eI
|ees ca1 0|IIeteat|c|s
116
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:
Fig. 1-11: Assignment of Fee Rate
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.
11
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.).
Fig. 1-12: Assignment of Fees and Differentials to Exchange Agreements
I|It|ag Ceatte|s ca1 C|etks
Lifting Controls by Contract
The standard purchase and sales contract creation and amendment transactions
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
I|It|ag CeaWte|s |y &eattctt
118
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.
119
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 Systems 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.
Fig. 1-13: Lifting Controls in a Sales Call-off
0ecat|tct|ve tctk|ag eI Ixt|cage Bc|cate
The system keeps track of the exchange balance within a specific database
(S036) that is updated whenever one of the following system events occurs:
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.
0ecat|tct|ve tctk|ag eI
Ixt|cage Bc|cate
120
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.
Fig. 1-14: Update of Quantitative Balance Following Goods Issue
||acat|c| Ncacgemeat eI Ixt|cage kgteemeat
For each exchange agreement created in R/3 IS-OIL Downstream, financial
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.
||acat|c| Ncacgemeat eI
Ixt|cage kgteemeat
121
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
Fig. 1-15: Pure Exchange Postings
122
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
123
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
121
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 dont 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.
125
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
126
Iec1 Bc|cat|ag
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:
Fig. 1-16: Exchange Loading Business Scenario and System Representation
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.
Iec1 Bc|cat|ag
12
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).
128
S||t |ave|t|ag
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.
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.
S||t |ave|t|ag (S0)
S||t |ave|te et|I|tct|ea (NN)
129
hett|ag
Netting functionality allows payables and receivables for an exchange
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.
hett|ag
130
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.
Fig. 1-17: Netting Process
NevemeatsBcse1 hett|ag
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.
NevemeatsBcse1 hett|ag
131
0etc||
keett
hett|ag Pt|at
keqeest
6k 6| I|k
|eek
hett|ag se|ett|ea
Nevemeats
0ctc|cse
B||||ag
||acat|c|
0ctc|cse
hett|ag Pteesc|
0e||vet|es
kete|ts
Pete ||acat|c|s
Beek kete|ts
Beek 0e||vet|es
hett|ag
BC|
Semmcty
keett
|ave|te
kete|t
1HJ 1HJ
3D\PHQW 3D\PHQW
Fig. 1-18: Movements-based Netting
Logical inventory balances are updated whenever one of the following system
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.
132
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.
Fig. 1-19: Moving average price of logical inventory
Revaluation of Logical Inventory
IS-Oil functionality incorporates an enhanced price change transaction that
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.
kevc|ect|ea eI Ieg|tc|
|aveatety
133
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 materials 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.
The Logical Inventory Adjustment transaction allows the oil company to
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.
131
Fig. 1-20: Effect on Logical Inventory Balance of Posting a Logical Inventory
Adjustment
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.
135
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 products 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.
Fig. 1-21: Quantity Postings Generated by the LIA Transactions
136
Fig. 1-22: Fincancial Postings Generated by the LIA Transactions
Ixt|cage Stctemeat
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.
keett|ag kgc|ast Ixt|cages
Display Exchange Balance
The system strategy for quantitative tracking of exchange balances is
explained in the section Quantitative Tracking of Exchange Balance. The
Ixt|cage Stctemeat
keett|ag kgc|ast Ixt|cages
13
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)
138
Received Quantity = The quantity already received against the call-off
Fig. 1-23: Exchange Entitlement
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).
Fig. 1-24: Display Exchange Entitlement Transaction
139
6|esscty eI Ixt|cage Set|I|t etms
Pete Ixt|cage
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.
hea Pete Ixt|cage
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.
hette1 Ixt|cage
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.
BettewJIeca Ixt|cage
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.
|ee Cctegety
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.
110
|ee ye
This identifies the type of fee within a fee category, e.g. types of individual
fees are wharfage, truck filling and demurrage.
Ieg|tc| |aveatety
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).

SAP Oil Chapter 1

Uploaded by

Copyright:

Available Formats

SAP Oil Chapter 1

Uploaded by

Document Information

Original Description:

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

SAP Oil Chapter 1

Uploaded by

Copyright:

Available Formats

C|ctet 1

You might also like