SAP IS OIL MAP

&KDSWHU �

��

0DUNHWLQJ�$FFRXQWLQJ�DQG�3ULFLQJ��0$3�DV�SDUW�RI�,6�2LO�'RZQVWUHDP

+LJK�/HYHO�6XPPDU\The objectives of MAP within IS-Oil Downstream are to enhance the basicMarketing, Accounting and Pricing (MAP) functionality within the CoreSAP R/3 System. The Core R/3 pricing functionality is flexible enough tosupport 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 dateswithin the sales cycle, i.e. it is possible to price sales deliveries based onorder, invoice, goods issue, delivery note posting, loading, delivery noteconfirmation or invoice creation dates.

q Ability to set and obtain prices by date in combination with time as wellas day of the week in combination with time.

q The abillity to determine whether a customer’s price is to be based onlocal pricing or the customer’s head office pricing rules.

q Ability to base pricing on geographical elements linked to the deliverylocation. These elements are part of a location code which is stored in thecustomer 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 pricelist out of this.

q The ability to determine whether a price condition is to apply to gross orto net volumes.

q Ability to print temperature, density and volume in all the units ofmeasure 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 pricequotations (e.g. Platts, Reuters, ...). Possibility to recalculate formulaprices 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�$FFRXQWLQJ�DQG�3ULFLQJ��0$3��DV�SDUW�RI�,6�2LO�'RZQVWUHDP

��

.H\�)XQFWLRQ�%HQHILWVEnhancements to the degree of pricing sophistication allow the oil company,supported by IS-Oil, to tailor its pricing strategy, policy, and tactics to suit itscost base and its individual customers’ circumstances very precisely. Thisfeature of the system enables the sales organization to maximize the quantityand quality of revenue generated. The specific benefits are detailed below:

By allowing a variety of pricing dates at invoice creation and the ability toset prices related to a time as well as a date, the system allows a moreflexible approach to price setting. The nature of the oil products market issuch that the price of products can vary by relatively significant amountsover the period between order placement and delivery. This flexibilityallows the supplier to guard against making a loss on the trade or thecustomer being charged an uncompetitive price (and thus prejudicingfurther sales).

The head office/branch level pricing functionality improves the flexibility ofthe pricing process and allows pricing to be based on head office level ratherthan defaulting to specific prices and procedures set for the branch level.

The inclusion of the location-specific Differential Reference Code (DRC)allows prices, discounts, surcharges and taxes to be calculated based on anaccurate description of the location of where the goods are delivered.

The use of customer-specific price lists eases the process of informingcustomers of the applicable prices for a list of regularly ordered products.The provision of this facility speeds up the time taken to answer customerinquiries, thereby improving customer service and reducing business costs.

The provision of formula & average value-based pricing allows greaterflexibility in price setting. When discussing pricing with a customer, theability to set prices based on market averages is an added benefit whichassists in the selling process.

The contract-specific pricing allows the oil company to identify, target andtailor the service it provides to specific high priority customers according tothe sales strategy it is pursuing. Negotiating medium to long term contractswith key target customers can ensure mutually beneficial continuity ofbusiness. By attaching a pricing element to the contract this businessrequirement can be fulfilled.

7LPH�)OH[LEOH�3ULFLQJ

+HDG�2IILFH�%UDQFK�/HYHO3ULFLQJ�$JUHHPHQWV

/RFDWLRQ�)OH[LEOH�3ULFLQJ

&XVWRPHU�6SHFLILF�3ULFH�/LVWV

)RUPXOD��$YHUDJH�9DOXHEDVHG�3ULFLQJ

&RQWUDFW�6SHFLILF�3ULFLQJ

0DUNHWLQJ�$FFRXQWLQJ�DQG�3ULFLQJ��0$3��DV�SDUW�RI�,6�2LO�'RZQVWUHDP �

��

.H\�,6�2LO�)XQFWLRQV�6XSSRUWHG�E\�WKH,6�2LO�'RZQVWUHDP�0$3�&RPSRQHQW

$OWHUQDWLYH�3ULFLQJ�'DWHV��7LPH�3ULFLQJ

The following MAP enhancements are provided within the IS-Oil DownstreamSystem:

The Core R/3 System currently proposes order pricing with the defaultinvoice pricing date. If required, this date can be manually overwritten witha 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 orderdelivery could take several days during which the price could changesubstantially. Hence, functionality is required to allow a variety of dates tobe chosen for calculating the price when the invoice is created. These defaultdates 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 thesales cycle based on the date and time, or based on the day of the week andtime.

�'DWH�7LPH��'D\�RI�:HHN�7LPH�

)LJ��3ULFH�)OXFWXDWLRQV�IURP�2UGHU�WR�,QYRLFH

+HDG�2IILFH�%UDQFK�/HYHO�3ULFLQJ�$JUHHPHQWV

Some organizations choose to make pricing arrangements at their headoffice and at the branch office level. Therefore, when making a sale to acustomer who has a headoffice, it is necessary to define whether to use thepricing arrangements negotiated with the head office, or those negotiatedwith 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 pricingprocedures and the customer-specific prices may also be different.

IS-Oil delivers the tools for using the head office prices and/or pricingprocedure when selling to the branch.

+HDG�RIILFH�OHYHOÃ��SULFHVSURFHGXUHV�Ã��

%UDQFK�OHYHOÃ�SULFHVÃ�SURFHGXUHV



&XVWRPHU�PDVWHU�GDWD

)LJ��+HDG�2IILFH�%UDQFK�/HYHO�3ULFLQJ�$JUHHPHQW

/RFDWLRQ�6SHFLILF�3ULFLQJ�XVLQJ�WKH�'LIIHUHQWLDO�5HIHUHQFH�&RGH��'5&�

The location-specific pricing functionality (technically implemented usingthe Differenctial Reference Code - DRC) allows a more accurate definition ofthe location of each sale. This enables pricing to take into account othergeographical factors than those that are standard in the customer master.

This functionality allows pricing conditions to be based upon the DRC codeitself, or upon one of the location grouping attributes of the DRC. Forexample, a wide area pricing zone could be used to determine surcharges ordiscounts applicable to deliveries in that area. The DRC has six differentattributes. 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 pricingof discounts


��

q State license fee zone: groups DRCs together, for example for pricing oftaxes

q Pricing DRC: for referring one DRC to another DRC

2LO�&RPSDQ\ &XVWRPHU�ORFDWLRQ�$

&XVWRPHU�ORFDWLRQ�%

&XVWRPHU�ORFDWLRQ�&

3ULFH�$

3ULFH�%

3ULFH�&

)LJ��3URGXFW�3ULFHV�9DU\LQJ�ZLWK�&XVWRPHU�/RFDWLRQV


Contract specific pricing allows pricing conditions to be set for a customerand then to be applied to all call-offs from that contract. This ensures thatwhen pricing is done (at order or invoice creation), the correct contract-specific price is used.

3UH�'HILQHG��&XVWRPHU�6SHFLILF�3ULFH�/LVWV

The customer price list allows net prices to be calculated for a pre-definedlist of products. The price list contains the quantity usually ordered by acustomer, along with the unit of measure.

The price list is not part of an order transaction; it is created for customerinformation purposes only. The list does, however, use the pricingfunctionality in the same way as the order or invoice creation transaction.

The materials and quantities are defined as master data, and cannot bechanged at the time that the customer price list transaction is run.

When the price list transaction is executed, the user has to specify pricingrelevant data like customer, sales area, order type and pricing date and time.

3ULFLQJ�%DVHG�RQ�*URVV�RU�1HW�9ROXPHV

The ability to invoice customers based on either gross or net volumedelivered is required by oil companies in some countries for eithermarketing or legal reasons. Gross volume is for example ambient liters andnet volume is for example liters corrected to 15C.


��

The key factor is generally the country and region where the ownership ofthe product changes. However, some customers have a special arrangementwhich may override the general rule.

The IS-Oil Downstream enhancement allows the maintenance of a singlecondition record in either a gross or net unit of measure. The system thenuses criteria, defined by configuration, to determine whether the gross or netvolume is used during pricing when calculating the condition value.

The print program for invoices has been enhanced to enable you to displayHPM data. This allows the temperature and density information from thedelivery to be displayed on the invoice.

)RUPXOD��$YHUDJH�9DOXH�%DVHG�3ULFH�&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. canbe interfaced to the SAP system. This is achieved by means of a configurableroutine delivered by IS-Oil. The quotations are then referenced in thecreation of pricing formulas.

5

5��

3ULFH� �

7KH�OHVVHU�RI

5HXWHUV�81��GD\�DYHUDJHDQG

3ODWWV�81��GD\�DYHUDJHDQG

3OXV��'0�/��

3ULFH

7LPH

3ULFH

7LPH

)LJ��)RUPXOD��$YHUDJH�3ULFLQJ

The formula pricing functionality is integrated into the creation of pricecondition records using the core condition technique. Formula and averagepricing 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 allowsdefinition of a formula rather than a rate when creating a condition recordfor this condition type. Once a formula based price condition record exists inthe system, it is possible to retrieve the formula using the conditiontechnique during transactions in the Core System.


��

The formula and average condition type can be included in pricingprocedures in the same way as standard condition types. At the time that thepricing takes place, the “formula pricing engine“ evaluates the formuladefined for each formula based condition type to give the rate which is thendisplayed on the pricing screen.

As in the daily business practices of a company, the average period may notbe over at the time of order/invoice creation so that the price calculated canbe a provisional price rather than the final price. The status of the formulaevaluation, i.e. final price or provisional price is indicated by a statusindicator, which is held on the formula value display screen in thedocument.

There is additional functionality to define provisional calculation rules,which allows the user to specify a different average period for calculatingthe provisional price if this is required. It is possible to create a differentialinvoice in SD, which debits/credits the difference between the provisionaland final prices.

A pricing formula is made up of two parts: the formula definition, whichdefines a reference to the quotations and the calculation rules, which definethe average period.

Formula Definition

The formula consists of two “terms“: the A term and the B term. Both containan unlimited number of component lines.

An external quotation may be referenced within each component line. Asurcharge 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 formulaterm. This is a core field and is customizable in the IMG global settings. Acurrency exchange rate type represents a source of information on currencyexchange rates. The exchange rate type is used to convert both the quotationand the surcharges.

The total price for each term is determined by adding the value of thecomponent lines together. The value of the component line may be positiveor negative, thus allowing for differential calculations.

Finally, a rule defines how to determine the overall value of the formulabased on the value of the A term and the value of the B term. For exampleusing 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 ofthe quotations in the formula is calculated and define the currencyconversion 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, whichconsists of one day before the delivery date, the delivery date and one dayafter the delivery date.

)RUPXOD�'HILQLWLRQ

&DOFXODWLRQ�5XOHV


��

For currency conversion, either the daily exchange rates or an averageexchange rate can be used. For average exchange rate calculation, theaverage period can be defined in the same way as the quotation averageperiod. For example, for the above three day average quotation period onecan specify to use the average exchange rate of the working days of themonth prior to delivery.

&RQGLWLRQ�([FOXVLRQ�7HFKQLTXH��+LJKHVW�3ULFH

This is an enhancement of the standard SAP condition exclusion techniquewhich allows the user to define rules that specify which condition recordsare and are not included. For example, should multiple discounts apply tocustomer/material, the system can be configured to use the highest discountand omit the other applicable discounts.

The IS-Oil enhancement allows selection of the highest price (worst price forthe customer), whereas the Core R/3 System only allows selection of thebest price for the customer.

1RUWK�$PHULFDQ�([FLVH�7D[�+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 beencreated to facilitate proper tax calculation for taxes due at either the origin ordestination of the delivery.

Routines have been developed to identify when a customer has a federal orstate 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.

.H\�,6�2LO�)XQFWLRQV�6HUYHG�E\�WKH�&RUH�5��6\VWHPThe basic pricing functionality is provided by Core R/3. In summary, thisincludes 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 thesearch key for the appropriate pricing condition records


��

q The access sequence by which the search for valid records is made canbe defined by the user

q Calculation types can be defined, for example whether a discount is anabsolute amount or a percentage

q Pricing conditions can be defined as statistical, i.e. they are used forstatistical analysis, not for setting prices

q Multiple valid pricing records can be used and rules are set to determinethe 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 indifferent UOMs than the condition record, and pricing can still occur.The system converts the quantity ordered into the UOM of the pricingcondition record and price accordingly. This price is displayed to theuser. The UOM on the order does not change. The condition type’s UOMcan be selected from a pre-defined list. The volumes in various UOMscan be printed on the invoice in an IS-Oil enhancement.

'HWDLOHG�'HVFULSWLRQ�RI�%XVLQHVV�)XQFWLRQV�6XSSRUWHGE\�WKH�,6�2LO�'RZQVWUHDP�0$3�&RPSRQHQW

$OWHUQDWLYH�3ULFLQJ�'DWHV�DW�,QYRLFH�&UHDWLRQ

This area of functionality includes the pricing of a sale according to the dateof a specified event in the sales order cycle. The life cycle of an order canencompass several days or pricing cycles. The sales order, delivery note,goods issue, and invoice are all likely to occur on different dates. Sincedifferent dates may be set up with different pricing condition records, thechoice of which pricing date to use at invoice creation directly affects thecalculated net price.

During user customization, each invoice type is defined with a specificdefault pricing date to be used during invoice creation. In the IS-OilDownstream 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 fordefining alternative pricing dates is not processed, and the system acceptsthe manually-entered date for pricing without further validations, except ifthe date entered is in the past. In this particular case, a warning message isissued.

$OWHUQDWLYH�3ULFLQJ�'DWHV�DW,QYRLFH�&UHDWLRQ


��

In addition, the IS-Oil Downstream time pricing functionality offers thepossibility of creating pricing conditions whose scale is either date and timedependent or day of the week and time-dependent. The scale which can beapplied to standard price conditions is defined in the configuration of thecondition type.

An example of the pricing date procedure is shown in Figure 3.1. In theexample, an order for 10,000 liters was recorded on the first of July. Thedelivery note was processed on the third of July, the goods issue on the fifthof July, and the invoice processed on the seventh of July. All four documentdates have different prices in the associated pricing table. The selection ofwhich date to use for pricing directly affects the final price for the sales orderto the customer.

��/LWHUV2UGHUHG

)LQDO�3ULFH�$FFRUGLQJ�WR

'DWH

([HPSOH�3ULFLQJ�6WUXFWXUH)RU�WKH�PRQWK�RI�-XO\��8QOHDGHG

'DWH��-XO\��-XO\��-XO\��-XO\��-XO\��-XO\��-XO\��-XO\��-XO\��-XO\

3ULFH��/LWHU��/LWHU��/LWHU��/LWHU��/LWHU

6DOHV�2UGHU��-XO\

6DOHV�2UGHU��

'HOLYHU\�1RWH��

*RRGV�,VVXH��

,QYRLFH��

'HOLYHU\�1RWH��-XO\

*RRGV�,VVXH��-XO\

,QYRLFH��-XO\

)LJ��3ULFLQJ�'DWH�3URFHGXUH

+HDG�2IILFH�%UDQFK�/HYHO�$JUHHPHQWV

Core R/3 pricing uses the pricing procedure defined in the sold-to partnerand the sold-to customer specific prices if defined. IS-Oil delivers the tools touse 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 toshow whether the head office or branch pricing procedure should beapplied.

The indicator can only receive input if a head office is defined in the accountmanagement data for the branch. In addition, two new requirementsprograms (403 and 404) have been developed for use within accesses for anycondition type. When allocated to an access sequence, 404 accesses pricingcondition records defined for the customer, while 403 accesses pricingrecords defined for the head office of the customer (if head office is defined).

+HDG�2IILFH�%UDQFK�/HYHO$JUHHPHQWV


��

With the Core functionalities, the access sequence and the exclusiontechnique, it is then possible to define the circumstances in which each priceis used, e.g. always use branch price if one is defined, or use the lowestprice.

/RFDWLRQ�6SHFLILF�3ULFLQJ�8VLQJ�WKH�'5&

For pricing purposes, the location-specific pricing functionality (using theDifferential Reference Code - DRC) represents a geographical region that canbe used for setting prices, discounts, surcharges and taxes. A standard ordercan have multiple customers (business partners) associated with it: theactual purchasing customer (sold-to party), the consignee (ship-to party), thebilling-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 theorder header and the item

and can be overwritten. If a DRC is changed in the order, the order isrepriced to account for this change. If the ship-to party is changed in theorder header/item, the DRC is redetermined and the order is repriced.

The DRC has six different attributes which all can be used individually forpricing. 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/3country and region. The MI, WAP and SLF fields are DRC-specific fields andmust be defined in the configuration tables before they can be defined asattributes.

The Pricing DRC allows a number of DRCs to point to the same DRC forgeneric pricing purposes for example, while freight surcharge conditionsmay be set at a DRC-specific level, discounts for certain types of customersmay be at a group of DRC levels. So while neighbouring DRCs 1,2,3, and 4may all have specific freight surcharges, the discount for a certain type ofcustomer 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 figurebelow. An order was created where the ship-to partner is located in Boston,Massachusetts. For this region of the United States, certain price conditionsexist. The region code for Massachusetts has a specific tax rate which alsoincludes the Boston metropolitan area, and the wide area pricing region ofthe Eastern half of the state. Through the DRC, all three pricing indicatorsare combined under one indicator, which is linked to the customer master.

/RFDWLRQ�6SHFLILF�3ULFLQJ8VLQJ�WKH�'5&


��

When the order item is displayed, the DRC of 12345 is defaulted. If thedefault DRC is not valid (for example, the goods are not delivered to Boston,but to another final destination, a different Metropolitan code is needed), theoperator can manually change the DRC to the correct value.

([DPSOH�

)LJ��'LIIHUHQWLDO�5HIHUHQFH�&RGH�7DEOH


The Core R/3 System allows the user to manually enter a contract price atcontract creation. However, the result of such a manual price is thatwhenever the function “new pricing” is carried out during call-off or invoicecreation, 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, bycopying the contract number into all subsequent documents, i.e. call-off,delivery and invoice. This field is included in the SD Pricing Field Catalog. Acondition record can then be created which includes the contract/itemnumber as one of its key fields in the access sequence.

There is an enhanced matchcode on contract call-off, enabling the selectionof contract numbers by sold-to party. This is available on contract pricingcondition record maintenance screens.



��

LQ�FKDQJHPRGH

&RQWUDFW 'HOLYHU\ ,QYRLFH&DOO�RIIRUGHU

&RQWUDFW6SHFLILF3ULFLQJ

)LJ��&RQWUDFW�6SHFLILF�3ULFLQJ

The above graphic shows a representation of the document flow with regardto contract-specific pricing. Contract-specific pricing occurs at the contract(order entry) and invoice level of the document flow.

3UH�'HILQHG�&XVWRPHU�3ULFH�/LVWV

Pricing based on a pre-defined list of products is a feature of the IS-OilDownstream component. The functionality allows lists of products (andassociated quantities) to be defined for each customer. The list may containmaterials of different material types.

This functionality is used for customers who regularly order the sameproducts and same quantities. In such cases, the ordered products mayalways be the same but the prices may change frequently. Every time thepricing list is accessed, the prices are recalculated using pricing conditionrecords valid for the specified pricing date and time.

The IS-Oil MAP enhancement allows the list of products to call the pricingfunctions and the list to be priced. This pricing operation is not part of anorder transaction. The pricing of the list can be carried out for differing datesor differing condition records depending on the needs of the customer. Thisfunctionality simplifies and quickens the process for informing customers ofthe current prices for regularly ordered products and quantities.

Each customer can have more than one price list. Each customer may haveseveral, but different, lists of regularly ordered products and quantities, andeach list can be priced separately as required.

The IS-Oil MAP enhancement includes a table which can be used to definethe list of products and quantities. A transaction has been created whichuses this table. This transaction calls the standard R/3 pricing procedures.The pricing procedure selected for the pricing depends on the order type

3UH�'HILQHG�&XVWRPHU�3ULFH/LVWV


��

(entered when selecting a list for pricing). The standard R/3 pricingprocedure has not been altered. The price list functionality operatesindependently of the order process.

3ULFLQJ�%DVHG�RQ�*URVV�RU�1HW�9ROXPHV

In Core R/3 the system uses the volume measured in the condition recordunit of measure to calculate the condition value. Conversion factors aredefined by the user. The ASTM functionality is used, where applicable.

The IS-Oil enhancement in this area provides the ability to maintain a singlecondition record and use either gross or net volume for pricing, based onuser 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. Thisindicator defines whether the value of the condition type should always becalculated using the gross or net volume, or whether the gross/net rule onthe line item should be examined. If the value is blank, then normal CoreR/3 processing will occur.

The gross/net rule for the line item provides the user with a user-exitcapability to define a means by which to determine whether to price basedon gross or net volume.

The line item rule is determined using a table. Keys in the table are thecountry and the region in which the title of ownership passes. This locationis determined by using the Incoterms.

Where special rules apply to a customer, the customer number can beentered in this table.

Formula & Average Value-Based Price Calculations

)RUPXOD��$YHUDJH�9DOXH�%DVHG�3ULFH�&DOFXODWLRQV

Formula & average value-based pricing functionality allows the calculationof prices based on the value of externally-quoted materials over an averageperiod. This functionality is fully integrated with Core R/3 pricing using theCore condition technique. The key configuration feature of formula-basedprice condition types is that the calculation type is Q (formula and averagecondition). This allows you to define a formula rather than a rate whencreating the condition record. In the formula, the reference to the externalquotation(s) is defined together with the average period.

Every time pricing is called, the formula is evaluated and the pricingcondition rate is calculated and then displayed on the pricing screen. Thestart and end dates of the average period are determined from thecalculation rules (final and provisional) in the formula definition. Some or allof the required quoted prices for the average value calculation may be in thefuture with respect to the system date on the day that the condition is

3ULFLQJ�%DVHG�RQ�*URVV�RU�1HW9ROXPHV


��

evaluated. In this case the system calculates the “best price” using the periodup to the system date.

The formula evaluation status indicator which is held on the formula valuedisplay screen shows the status of the formula, for example the formula wasevaluated using the provisional rules.

External quotations are held in a table. The key of this table is the source (forexample Platts, Reuters), type (for example high, low) the quotationreference (for example Platts quote NWE/PREUNL/C/FOB) and the date.The possible values of the keys and quotation check data are defined in theconfiguration tables. A user exit routine exists which interfaces the formulawith the external quotation source using either the IS-Oil Quotation table,another user-defined table or an interface directly to an external datarepository.

([WHUQDO�4XRWDWLRQV

0DQXDO�RUHOHFWURQLFXSGDWH

[

[

[[

)LJ��6WRULQJ�([WHUQDO�4XRWDWLRQV�LQ�5��,6�2LO�'RZQVWUHDP

Formula Definition & Maintenance

The formula definition screens are common to condition maintenance and tothe pricing screens within sales and purchasing documents. Authorizationobjects 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 whichcreate the price on the Formula Term Entry screen. The formula consists oftwo “terms“, the A term and the B term. Both contain an unlimited numberof component lines. The total price for each term is determined by addingthe value of the component lines together. The value of the component linemay be positive or negative, thus allowing for differential calculations.


��

An external quotation may be referenced within each component line. Thequotation is identified by the source of the data (for example Platts), thequotation 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 acurrency and UoM different from that of the quotation. It is possible to entera surcharge on a component line which does not reference a quotation (forexample the quotation fields are blank for the component line).

A currency exchange rate type is assigned to each line item of the formulaterm. This is a Core field, customizable in the global settings of the IMG. Acurrency exchange rate type represents a source of information on currencyexchange rates. The exchange rate type is used to convert both the quotationand surcharges into the formula rate display currency (also defined on thisscreen). If this field is blank, then all values are converted to the documentcurrency by the formula pricing engine within pricing transactions (forexample by default rate currency = document currency).

A rule is assigned to each item on the screen, which decides how the valueof the line is calculated. For example, multiply the sum of the quotation andthe surcharge field by the product of the two factors.

Finally, a rule defines how to determine the overall value of the formulabased 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 screenswhere the calculation rules are defined.

The Calculation Rules Screen

The calculation rules define the time period over which the average value ofthe quotations in the formula are calculated. There are two main areas todefine:

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 theaverage period. The first method is to define a fixed “date from“ and “dateto“ for the quotation average period. The second method is more involvedand 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-OilDownstream component, and you can add further possibilities bycustomizing 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“). Forexample, 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 dateoffset“ user exit.

3. The next step is to define the period before the event date and the periodafter the event date over which the average value is calculated. Thefields “period before“ and “period after“ are used for this definitiontogether with the “Time Unit of Measure“ routine, which is specified.The “Time Unit of Measure” routine determines the start date and theend 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-workingday, then the system uses the weekend rule to decide which priceto use for that day. An example is delivered with the system: forSaturday, use Friday’s price, for Sunday use Monday’s price. Youcan add further possibilities by customizing the “weekend rule“user exit.

m If the quotation factory calendar defines that day as a holiday, thenthe system uses the non-posted day rule to decide which price touse 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 whena quotation is simply missing, i.e. when, according to the quotationfactory calendar it should exist. In this case, the system uses thecustomizable “No-quotation exists“ routine.

Defining the Currency Conversion for the Average Value Calculation

In principle, there are two methods of converting currencies within theaverage value calculation: using daily exchange rates or using averagevalues of exchange rates. There are two fields in the calculation rules screenwhich allow you to define which of these techniques is to be employed. Thepossible values of these fields are defined by creating user exit routines forthe “daily currency rule“ and the “average currency rule“.

q In daily currency conversion routines, the price for a quoted material ona certain date in the required currency is determined by multiplying thequotation price for that day by a currency exchange rate for the sameday. This exchange rate converts the price from the quotation currencyto the required currency. The IS-Oil System delivers one example of thisroutine, where the quotation is multiplied by the valid currencyexchange rate for the same day.

q In average currency exchange rate routines, the pricing calculationengine determines an average value of the currency exchange rate over aperiod of time defined by the currency exchange calculation rules (suchas currency time UoM, currency period before, currency period after,etc.) which are defined on the same screen of the formula. This averageexchange rate is then used for all currency conversions for that term ofthe formula.


��

External Price Integrity Check Program

A factory calendar is used to define on which days quotes are expected ornot expected. The external price integrity check program checks for incorrectexternal price quotations using the factory calendar as defined in thequotation check table. The integrity check program can be used to search forprice 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 oramount

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 thefollowing 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 andexchange rates which were used to calculate the value of a formula, of aformula 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 detailedanalysis of the data used in the formula evaluation calculations. The analysiscan be performed for the entire formula, for either term, or for one termitem. IS-Oil provides default routines and the default report ROICANAL.

To use second level price analysis instead of the default routines, thefollowing 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, errorhandling, data capture) in the condition configuration


��

Master Repository

It is possible to define a formula master in which formulas are stored. You cancreate, change and display formulas using the formula repository. Everyformula has a unique numeric or alphanumeric identifier. When maintainingcondition records, you can copy formulas in the formula repository or inpurchase 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. Duringformula maintenance, it is possible to retrieve a predefined formula from theformula 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 theformula master, using the core R/3 authorization technique. Additionalauthorization is provided to apply restrictions to sales documents, billingdocuments, purchase documents, and information records. The authorizationconcept 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 theformula. 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 orcredits the difference between the preliminary and final prices, when thefinal price is known. Customizing settings make it possible to individuallydefine the circumstances in which a differential invoice is to be created. Forexample, when the final price is not yet known. The differential invoice isindependent of invoice cycles and invoices any outstanding cycles.


��

A differential invoice itemizes the differential amounts at the condition typelevel, that is, the differential amount for each condition record in the pricingprocedure of the differential invoice is calculated. If the system is unable tocalculate the differential amount at the condition type level, error handlingcan be specified or customized by the user at the invoice type level. IS-Oilprovides an error-handling exit to cancel the existing billing documents andrebill at the new price.

*ORVVDU\�RI�0$3�6SHFLILF�7HUPV

&XVWRPHU�3ULFH�/LVW

A customer price list allows net prices to be calculated for a predefined listof products. The price list contains the quantity usually ordered by acustomer along with the unit of measure.

'LIIHUHQWLDO�5HIHUHQFH�&RGH

The Differential Reference Code (DRC) represents a physical geographicspecification used for calculating location specific prices, discounts andsurcharges. The DRC allows prices paid by customers to reflect supplier’scosts 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 adelivery, for example on the location of the ship-to-party, however this canbe manually overridden in the sales document. The geographical elementsof 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 citycode.

3ULFLQJ�'LIIHUHQWLDO�5HIHUHQFH�&RGH

One of the geographic elements within the DRC (Differential ReferenceCode). As a company may have hundreds of DRCs defined in their system,it sometimes makes practical sense to group together some of these DRCswhich have the same pricing rules.


��

6WDWH�/LFHQVH�)HH�=RQH

One of the geographical elements within the geographical reference zone. Itis used to establish tax or pricing conditions for a group of customers whichhave been entered in the system as coming from the same gegraphical area.

7LPH�3ULFLQJ

Allows pricing based on the time of the day in conjunction with the pricingdate or with the day of the week.

:LGH�$UHD�3ULFLQJ�=RQH

The wide area pricing zone is one of the geographic elements within thedifferential reference code (DRC). It may be used to create pricingconditions.

SAP IS OIL MAP

Documents

Transcript of SAP IS OIL MAP