Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
System
Stock Ledger Whitepaper
Release 14.1.x
January 2015
Contents
Contents ............................................................................................................................. ii
1 Introduction .................................................................................................................. 1
2 RMS Stock Ledger Overview ...................................................................................... 3
Stock Ledger Organization .................................................................................................... 3
Transaction Data .............................................................................................................. 3
Transaction Data API ...................................................................................................... 3
Stock Ledger Roll Ups ..................................................................................................... 4
Stock Ledger and Merchandising Transactions........................................................... 4
3 RMS Stock Ledger Attributes ..................................................................................... 7
System Options ....................................................................................................................... 7
Budgeted Shrink Indicator ............................................................................................. 7
Calendar ............................................................................................................................ 8
Consolidated Exchange Rate .......................................................................................... 9
Cost Method ..................................................................................................................... 9
Currency.......................................................................................................................... 10
Default Tax Type............................................................................................................ 10
Estimated Landed Cost ................................................................................................. 10
Financial Integration...................................................................................................... 11
General Ledger Rollup Level ....................................................................................... 11
Minimum / Maximum Cumulative Mark-on Percent ............................................. 11
Multiple Set of Books..................................................................................................... 11
NWP Processing............................................................................................................. 12
Receiver Cost Adjustment Type .................................................................................. 13
Retail Markdown for Transfer ..................................................................................... 13
Retain Transaction Data ................................................................................................ 13
Stock Count Processing ................................................................................................. 13
Stock Ledger Retail VAT Inclusive .............................................................................. 14
Stock Ledger Location Level ........................................................................................ 14
Stock Ledger Product Level.......................................................................................... 14
Time Interval .................................................................................................................. 14
Accounting Methods ............................................................................................................ 15
Retail Accounting Method............................................................................................ 15
Cost Accounting Method .............................................................................................. 17
4 Transaction Data ........................................................................................................ 29
Net Sales (Tran Code 01) ................................................................................................... 29
Net Sales VAT Exclusive (Tran Code 02) ........................................................................ 30
Non-inventory Items Sales/Returns (Tran Code 03) .................................................... 31
Returns (Tran Code 04) ..................................................................................................... 31
Non-inventory VAT Exclusive Sales (Tran Code 05) .................................................... 31
iii
iv
1
Introduction
This document provides an overview of the primary features of Oracle Retail Stock
Ledger functionality. In addition, this document addresses the integration of this module
with the two financial packages with which Oracle Retail has standard interfaces: Oracle
Financials and People Soft Financials.
Use this document to get a detailed overview of the following:
Accounting methods
Budgeted shrink
Transaction data
Introduction 1
2
RMS Stock Ledger Overview
The RMS Stock Ledger records and summarizes the financial results of transactions
taking place in the various merchandising processes, which include buying, selling, price
changes, stock adjustments, and transfers. Through this recording of transactions, the
Stock Ledger keeps track of a retailers inventory volume and value.
After recording is complete, these transactions are rolled up or aggregated to the
subclass/location level for days, weeks, and months, based on how the calendar is
configured in the system. The RMS Stock Ledger uses these aggregated values to
measure inventory units and values, and also merchandise profitability.
The stock ledger is primarily used for reporting purposes; however, there are online
components as well.
The RMS Stock Ledger supports multiple currencies. All transaction-level information is
stored in the local currency of the store, warehouse, or stockholding franchise store
where the transaction occurs. As transaction-level information is rolled up to the
aggregated levels in the system, records are kept in the local currency and also converted
to the primary currency. This functionality allows corporate reporting to be performed in
the primary currency of the company, while at the same time providing visibility by
location to the profitability in the local currency.
The RMS Stock Ledger can reflect either the Cost or Retail method of accounting,
depending on the retailers choice.
Additionally, the RMS Stock Ledger is often used as an interface point to the General
Ledger in a financial system.
Transaction Data
Transaction data consists of the individual transaction records created when various
merchandising processes are completed and recorded in RMS (for example, Sales,
Receipts, Inventory Adjustments, Price Changes, Transfers, and so on).
This data is recorded in the local currency of the location where the transaction took
place and uses the currency precision defined for the local currency.
Stock Ledger valuation. This tool is meant to provide a mechanism for a retailer to adjust
the value of their inventory based on transactions not captured within the standard
merchandising system processes, such as adjusting value based on Loyalty programs, or
other indirect costs that they retailer wants to allocate to the merchandise value.
Receipts
Transfer Order
Perpetual
Inventory
Sales/Returns
Stock Count
Inventory
Adjustment
Transaction Data
Return to Vendor
Shipments
Transfer Order
Stock Ledger
The RMS Stock Ledger is used to record the merchandising transactions taking place in
the retail business. These transactions can broadly be divided into three categories:
All three types of transactions affect both inventory positions and also form a part of the
transactions data set.
Purchase Order Receipt and Transfer In transactions cause an increment of stock on
hand. These can be recorded as part of transaction data and eventually affect the stock
ledger.
Return to Vendor and Transfer Out transactions result in the shipping out of
merchandise and cause reduction in stock on hand. These transactions can be recorded as
part of transaction data and affect the stock ledger.
Transactions, such as Stock Count and Inventory Adjustments, do not result in actual
movement of inventory, but these nonetheless affect the inventory position. In addition,
these form a part of the transaction data set and are written to the stock ledger.
Tran_Data and Stock Ledger are supported for both Company (Retailer) locations, and
also for Stockholding Franchise Locations. As Stock Ledger and Financial Integration are
controlled at a location level, Franchise Location stock ledger information can be
excluded from a Retailers financials or managed separately.
3
RMS Stock Ledger Attributes
The functioning of RMS Stock Ledger is impacted by the configuration of various system
options and department level settings. These settings affect the accounting method,
calculation method, integration, set of books, roll up levels, and so on. Because these are
very fundamental and one time options, these must be decided at the time of initial
system configuration. Changing these during the course of running of the business may
lead to severe data loss.
System Options
The system-level options described below affect the functioning of stock ledger.
System Options
Shrinkage Calculation
Budgeted Shrink Indicator =
Y
- 1 * Stock adjustments
Calendar
The calendar in RMS is very important from the stock ledger point of view. Recording of
sales transactions and, thereby sales history, is based on the RMS calendar. A consistent
calendar or time intervals facilitates proper analysis and time-based performance
comparison.
RMS supports a normal or Gregorian calendar, as well as a standard retail or 4-5-4
calendar. The description of both types of calendars is as follows:
Normal (Gregorian) calendar: This is a normal monthly calendar that can be used in
the system. However because of its intrinsic nature, it results in uneven yearly,
monthly, and weekly comparisons, because calendar dates generally fall on different
days from one year to the next. The number of weekdays differs from one year to the
next. For example: There may be four Saturdays in a month one year, but five
Saturdays the next year. A month may have between 28 and 31 days. Once every
four years, an extra day is added to compensate for a leap year. If the normal
calendar is used in the system, the weekly stock ledger cannot be maintained.
Retail (4-5-4) calendar: To overcome the unevenness of the normal calendar and
better meet the planning and comparisons requirements of retailers, the retail
calendar was developed. In this calendar, each quarter contains 13 full weeks divided
into a 4-5-4 format. That is, the first month of the quarter has four weeks; the second
month has five weeks; and the third month has four weeks. The number of days in
the retail year equals only 364 days. To compensate for the missing day in non-leap
years and two days in a leap year, an extra week is added to the calendar once every
six years. The retail calendar provides consistent inclusion of weekends for yearly
comparisons by month and a consistent day for month-end processing. The format of
the calendar can also be defined in terms of the distribution of weeks in the months
in a quarter. You have the option to choose the 4-5-4, 5-4-4, or 4-4-5 format for the
distribution of weeks in a quarter. Each period can have only four or five weeks, but
a quarter can have two five week periods in order to support the need to add a week
every seven years.
System Options
The indicator for deciding whether normal or retail calendar is going to be used is
CALENDAR_454_IND in the system options.
In addition to weekly and monthly calendars, RMS also facilitates Half Yearly time
periods for which budgeting and reporting can be done in the stock ledger.
Cost Method
The STD_AV_IND parameter indicates whether standard cost or average cost is used for
inventory and gross profit calculations. This processing is applicable to all the
departments, whether configured to use the cost or retail method of accounting.
Valid values are S for standard and A for average.
Oracle Retail calculates average cost, or weighted average cost (WAC), for each
item/location based on inventory transactions. This means that average cost is recalculated each time an item is received into a location either through a purchase order or
a transfer.
WAC = (Quantity Received * Purchase or Transfer Cost + Owned Inventory Quantity * Current
Average Cost) / (Quantity Received + Owned Inventory Quantity)
Owned Inventory Quantity includes stock on hand and in-transit inventory. In the case
of transfers, WAC is recalculated at the time of shipment of the transfer from the sending
location.
Standard cost is simply the current primary supplier cost for the item.
When an item is sold, the cost of sales is equal to either average cost or standard cost, and
gross profit is equal to sales at retail minus either average cost or standard cost,
depending on which method is chosen.
For more details, see the Accounting Methods section in this document.
System Options
Currency
Base Currency
A base currency for the system can be set up through the parameter CURRENCY_CODE.
Values for this field are validated from the table CURRENCIES in RMS. All currency
conversion rates in RMS are defined in terms of the system's base currency.
Multiple Currency
The RMS stock ledger gives you the flexibility to use multiple currencies in a single
instance of RMS. There can be different currencies at the location level and corporate
level. This is to facilitate recording location level transactions in the local currency, but
corporate level reporting in a standard base currency.
The indicator MULTI_CURRENCY_IND indicates whether RMS supports multiple
currencies. The only supported value is Y. However, this does not require that multiple
currencies are used in the system.
System Options
Financial Integration
The RMS stock ledger may or may not be integrated with an external financial system.
The indicator FINANCIAL_IND identifies whether an external financial application is
integrated. Valid values are Y and N.
The indicator FINANCIAL_AP indicates the external financial system being used by the
business. Valid values are O (Oracle EBS Financials), A (PeopleSoft) and NULL (third
party). This setting controls supplier entry and general ledger (GL) cross reference
maintenance.
System Options
A transfer entity is a group of locations that share legal requirements around product
management and are part of the same legal entity.
The indicator INTERCOMPANY_TRANSFER_IND indicates whether or not intercompany transfers are used within RMS. When this indicator is set to Y, each
stockholding location (store, warehouse, and external finisher) is associated with a
transfer entity. When this indicator is set to N, inter-company transfer functionality is not
used.
NWP Processing
NWP refers to Niederstwertprinzip and is a legal German accounting financial
inventory reporting requirement for calculating year-end inventory position based on the
last receipt cost. The NWP Indicator supports this German-specific inventory reporting
requirement. For German customers, this setting needs to be 'Y' to allow for the annual
NWP calculations and processes. This setting is not relevant for customers outside
Germany.
NWP calculates the end of year inventory values in each store as of December 31st of the
previous year. To determine the correct end of year inventory value for this report, the
following process occurs:
A stock count is performed for every store in the early part of the year.
The variance determined in this count is applied to the book stock as of the end of the
year to determine more accurate end of year inventory values.
End of the year stock units are revalued based on the lower of last received cost or
weighted average cost for the items at each location during the previous year.
The end of year value of the inventory, after the stock count adjustments and revaluation
process based on the lower of weighted average cost or last received cost, is the value
that is used to report the end of year inventory for the German NWP report. To
accomplish this processing, RMS uses a table, on which it holds a record for every active
item/location combination for each year. Items on this table are non-pack items held at
the transaction level.
New records are added to this table through several processes:
Each time a receipt is recorded in RMS, the receipt process determines whether there
is currently a record for the item/location combination for the year of the receipt on
the table, and whether there is not, a new record is added to the table.
When the end of year NWP snapshot process runs, the system takes a snapshot of
stock and weighted average cost (WAC) for every item/location combination
currently holding stock. If there is not a record already on the NWP table for an
item/location/year combination in the snapshot, a new record is added for that
item/location/year combination.
When an end of year NWP stock count is processed and variances are posted to the
NWP table, if there is not an item/location/year record on the NWP table for the
variance record, a new record is added to the NWP table for that item/location/year.
The receiver cost adjustment process and receiver unit adjustment process also
update records on this table if the item/PO/shipment record exists on this table.
System Options
System Options
Time Interval
The Time Interval indicator STOCK_LEDGER_TIME_LEVEL_CODE determines the
time periods that are used to run the RMS stock ledger. The valid values for this
parameter are Month (M) and Week (W).
This parameter can be set to either value without requiring modifications to the system.
If a retailer is running on a 4-5-4 calendar, the stock ledger is available to run for both
weekly and monthly levels, which means that inventory and gross margin are available
at both weekly and monthly levels. However, it is not required to run the weekly level
stock ledger, if it is not needed. If a Gregorian calendar is being used, the only option for
this variable is Month.
Accounting Methods
Accounting Methods
Various retailers, either because of legal requirements or their own accounting standards,
may require using either cost or retail methods of accounting, or both. RMS supports this
choice by allowing this to be set at the department level (in the DEPS table). The indicator
PROFIT_CALC_TYPE specifies whether all the subclasses in the department will use
cost method of accounting or retail method of accounting. The valid values for this field
are 1=Cost and 2=Retail.
While not commonly done, the system allows a retailer to operate some departments
using Cost method and other departments using Retail method. In order to provide a
more consistent view and method of determining inventory valuation and profitability,
most retailers choose to use either Cost or Retail, but not both. Some retailers with a more
diverse assortment may elect to use a mixture of methods. Examples of this approach can
include department stores, where fashion departments may use the Retail method, while
hard lines or food departments may use the Cost method.
Under the Cost method, item level margins can be calculated because costs are
determined at the item level. In the Retail method, margins can only be calculated at the
level of the stock ledger (that is, the subclass), as that is the level at which cost is
estimated.
Note that to support visibility to both cost and retail valuation of inventory, regardless of
accounting method, RMS captures both cost and retail for most transactions.
Accounting Methods
Accounting Methods
Accounting Methods
Average Cost
Under the average cost method of cost accounting, the cost of an item at a location is
recalculated every time inventory is received based on quantity and cost of the receipt.
Because of this calculation method, this method is also referred to as the weighted
average cost (WAC) or moving weighted average cost (MWAC).
Note: In the case of transfers, average cost is recalculated for
Accounting Methods
No.
Transaction Description
On
Hand
Before
On
Hand
After
Impact on WAC
PO Receipt
1.
5.
Accounting Methods
No.
Transaction Description
On
Hand
Before
On
Hand
After
Impact on WAC
Intra-company Transfers
1.
5.
Inter-company Transfers
1.
Intercompany Transfer In
with negative on hand
and on hand becomes
positive
Intercompany Transfer In
with negative on hand
and becomes zero
Intercompany Transfer In
with negative on hand
and on hand remains
negative
Accounting Methods
No.
Transaction Description
On
Hand
Before
On
Hand
After
Impact on WAC
4.
Intercompany Transfer In
with positive on hand
Intercompany Transfer In
with zero on hand
5.
Transaction Description
On
Hand
Before
On
Hand
After
Impact on WAC
4.
5.
Accounting Methods
No.
Transaction Description
On
Hand
Before
On
Hand
After
Impact on WAC
6.
7.
SOH prior to Receipt = 20 Units, WAC of $10.00 and Total Cost of $200.00
PO Receipt occurs for 100 Units, Unit Cost of $15.00 and total cost of $1,500.00.
Receiver Cost Adjustment for PO Receipt above of -$3.00 Unit for a corrected PO
Cost of $12.00 Unit.:
If the full impact of all Receiver Cost Adjustments is always applied to WAC and
inventory value, cases such as above where the resulting WAC could be negative, very
low or very high could occur.
If the receiver cost adjustment type is set as FIFO, RMS allocates the current on hand
quantity to recent PO receipts using a FIFO algorithm. So, for the received quantity,
unmatched line items (invc_match_status = 'U') as per the FIFO method are considered.
Accounting Methods
QTY
Unit Cost
100
$10
50
$10
Weighted Average Cost (WAC) = $10 (since there is no change in the unit cost of both the
receipts.)
Say 80 units are allocated and shipped to stores.
So, current stock on hand = 100 + 50 - 80 = 70
Perform RCA for Receipt1 with unit cost adjusted/unit = $1.
In this scenario, the system assumes that the quantity (80) shipped to stores are from
Receipt1. Hence, only 20 units are used for cost adjustment and the remaining 80 units
are posted as tran code 73 (Receiver Cost Adjustment FIFO, see the tran code section
for description). Retailers can then use the information in the tran data table for this
transaction code to determine how to adjust the WAC manually at location where stock
was distributed.
Various scenarios for the RCA and its impact on the WAC calculation are shown in the
following table:
No. Transaction Description
On
Hand
Before
On
Hand
After
Impact on WAC
Accounting Methods
Different scenarios for transfer reconciliation and its impact on stock ledger and WAC
are described in the following table:
No.
Reconciliation Method
Impact on WAC
BL (Bill of Lading
adjustment)
In this case, Transfer In (Tran Code 30) and Transfer Out (Tran
Code 32) entry will be reversed for the difference between received
qty and sent quantity and thereby the SOH for Sending location
and In Transit for Receiving Location will be adjusted.
3.
4.
No impact on WAC.
No impact on WAC.
In this case, Transfer In (Tran Code 30) and Transfer Out (Tran
Code 32) entry will be reversed for the difference between received
qty and thereby the SOH for Sending location and In Transit for
Receiving Location will be adjusted. Additionally, Inventory
adjustment (Tran code 22) will be written for sending location to
account for the loss.
Accounting Methods
No.
Reconciliation Method
Impact on WAC
BL (Bill of Lading
adjustment)
In this case, Transfer In (Tran Code 30) and Transfer Out (Tran
Code 32) entry will be written for the additional difference
between received qty and sent quantity and thereby the SOH for
Sending location will be decreased and Receiving Location will be
increased.
3.
4.
No impact on WAC.
No impact on WAC.
In this case, Transfer In (Tran Code 30) and Transfer Out (Tran
Code 32) entry will be written for the additional difference
between received qty and sent quantity and thereby the SOH for
Sending location will be decreased and Receiving Location will be
increased. Additionally, Inventory adjustment (Tran code 22) will
be written for sending location to account for the additional units.
Accounting Methods
Standard Cost
The second type of Cost accounting that is supported in RMS is the standard cost
method. Standard cost is defined as the last or current primary supplier cost. Under this
method, the inventory is valued using standard cost, rather than the WAC. This costing
method functions in a similar manner as that of WAC, in that the standard cost is the cost
used when updating the transaction-level stock ledger and is also used as the cost of
sales. The biggest difference between the two methods is the way that cost is updated in
the system. The standard cost can only be updated by doing a supplier cost change
within RMS. Changing the primary suppliers cost for an item results in a change in the
value of the inventory for that item at all locations, meaning that a cost variance record is
written to the stock ledger for the difference between the old cost and the new cost
multiplied by the total available stock (On Hand plus In-Transit).
In the standard cost method, if a transaction occurs with a cost different from the
standard cost, a transaction needs to be written to account for the difference. This
difference in cost is recorded as cost variance in the stock ledger.
For example, if the standard cost for an item is $10 and a purchase order for the item is
received at $12, then the purchase will be recorded at $12 with a $2 cost variance. This
difference in the cost can be because of an off-invoice deal with the supplier or any other
reason, the treatment would be similar. The net effect of this transaction will be an
increase in the overall inventory of $10 or the standard cost of the item.
Note: Standard cost is not compatible with the estimated
landed cost functionality in RMS because the assumption is
that cost is the same for all locations within RMS. If retailers
are using the estimated landed cost functionality, then the
retailer will need to use the WAC method or make a
customization to the system.
Accounting Methods
Accounting Methods
4
Transaction Data
To facilitate the calculation of inventory by the stock ledger, RMS records every
transaction involving movement of merchandise with a TRAN_DATA record. For every
transaction, RMS captures its Department, Class, Subclass, Transaction Date, Units, Cost
and Retail. Additionally, RMS also provides two optional reference fields, which can be
used for recording a reason code or event number. The Tran Data Code is a numeric field
with a length of 4 digits. RMS uses specific Tran Data number codes for specific types of
transactions, and the RMS Stock Ledger programs expect these specific codes. Retailers
have the ability to customize and use codes that are not used by the base product if
needed. However, as RMS expands, it will continue to add new Codes that are used by
the system for specific purposes. The codes currently used by the system are detailed
later in this document.
If VAT is being used in the system, the retail value captured in these transactions is VAT
inclusive (with the exception of transaction codes where it is specifically mentioned that
it records VAT exclusive values, based on the system level parameters). A system level
parameter indicates whether or not the VAT amount should be included in the stock
ledger. Each transaction is assigned a transaction code, based on predefined type of
transaction. In case of transactions involving packs, transaction data is recorded for the
component items and not packs. Transaction codes are defined in greater detail in the
subsequent sections.
These transactions are recorded in multiple tables in the system in various stages of
processing. The three tables that are used in combination for the processing of transaction
data are TRAN_DATA, IF_TRAN_DATA, and TRAN_DATA_HISTORY.
Initially, for each type of transaction that occurs in the system involving the movement of
merchandise, a record is written to the transaction data table at the
item/location/transaction level. (Note that there are a set of tables called
TRAN_DATA_A and TRAN_DATA_B that allow for continuous processing of
transactions and recording of TRAN_DATA records in RMS during the batch cycle.
TRAN_DATA is a database view.)
After that processing, but before the end of day processing is run, the records on
TRAN_DATA are removed from the table and are moved to a staging table called
IF_TRAN_DATA. This table is used as an interface point to the G/L and is also used as
the driving table for the end of day processing. Keeping only one day worth of data on
both TRAN_DATA and IF_TRAN_DATA improves the performance of the interface run
and end-of-day processing, as well as the performance of transactions writing to
TRAN_DATA throughout the batch cycle.
After end of day processing, transaction level records are kept historically in the
TRAN_DATA_HISTORY table. Records are written to this table based on the data in the
IF_TRAN_DATA table. This is the table that is used to view transaction-level data on-line
in RMS.
Transaction Data 29
the equivalent of the sale price captured at the POS and not the value in RMS. For
example, it includes any promotional discounts applied to the sale, which may not be
reflected in RMS retail price. Any difference in the unit retail in RMS and actual sales
retail is accounted through specific tran codes for markup/markdown.
The quantity, retail, and cost amounts are positive numbers for sales and negative
numbers for returns. The cost and retail values captured in these records are rolled up to
the subclass/day, subclass/week, and subclass/month levels and are used in the ending
inventory calculations for those periods.
This tran code includes VAT in the value posted in the following scenario:
The default tax type is either SVAT or GTAX (DEFAULT_TAX_TYPE = SVAT or
GTAX)
The Stock Ledger Retail VAT Inclusive is Yes (STKLDGR_VAT_INCL_IND = 'Y').
The VAT rate for an item for a VAT region is stored in the VAT_ITEM table.
The sales upload batch program does not post individual transactions, but transactions
are grouped by certain transaction attributes. The sales upload process posts sale in RMS
by grouping transactions at item/price point/sale type/store/day level. Sale Type
differentiates Regular Store Sales, In Store Customer Order Sales and External Customer
Orders.
The following is an example of how a TRAN_DATA record would look like for this
transaction code:
For more information on the definition of all the column headers in TRAN_DATA table,
see the section Transaction Data Data Elements in this document.
Transaction Data 31
These records are not used for the ending inventory calculations but are rolled up to
subclass/location level for day, week and month in the stock ledger to interface it to the
general ledger.
The following is an example of what a TRAN_DATA record would look like for this
transaction code:
The following is an example of what a TRAN_DATA record would look like for this
transaction code:
Catch Weight Type 3 Items This type of item is purchased in fixed weight simple
packs containing a fixed number of eaches and sold by variable weight eaches (for
example, pre packaged cheese).
Catch Weight Type 4 Items This type of item is purchased in variable weight simple
packs containing a fixed number of eaches and sold by variable weight eaches (for
example, pre-packaged sirloin steak).
These types of catch weight items have a nominal weight defined for them. At the time of
sales, actual weight is captured, which may be different from the nominal weight
defined.
For example: A bag of apples can have nominal weight as 1 kg but actual weight can be
more or less than 1 kg.
This is posted at retail and not used for inventory calculation.
The following is an example of what a TRAN_DATA record would look like for this
transaction code:
Transaction Data 33
Price Changes
When the retail price of an item is increased over its current price because of a permanent
price change, it is recorded as markup under this tran code. However in some cases, a
clearance or promotional markdown can also end up increasing the price. In these
exceptional cases, a markup transaction will also be captured.
Permanent price changes are created in the Oracle Retail Price Management (RPM)
application. Price changes can also occur due to a change in the zone group for an item or
due to a change in the zone in which are stores exist for a particular zone group.
This record is a location specific record, and the unit quantity considered for posting is
the stock on hand for the item in that location, along with the in-transit quantity. The
time for posting this record is the effective date of the price change. That is, this
transaction is posted at the point in time when the new price for that item becomes
effective in RMS. Price changes are inserted in RMS by RPM daily batch.
Example for Price Change:
Item A, Location X
The new price for Item A becomes effective from January 2nd. SOH on that day for item A
at location X is 150 units. The total retail value posted as markup on January 2nd, will be
$450. This is calculated as:
Markup Retail = (SOH*New Retail) (SOH*Old Retail)
Markup Retail = (150*18) (150*15) = $450
Markup Retail = Component Units sold * ((Pack unit retail/No. of components) Per
unit retail of component item)
Markup Retail = 30 * ((300/15) 15) = $150
Transfers
This transaction is written in the case of transfer if the unit retail at the sending location is
less than the receiving locations retail.
The location for which it is posted is per the system option (defined in the System
Options section) for determining markdown location, either the sending or receiving
location. The quantity considered will be the quantity in the shipment, and it will be
posted when the transfer status is moved to shipped. The transfer number is also
captured in the reference number field of this transaction.
Example for Transfer:
Item A regular retail is $10 at location X and $12 at location Y. 10 units are transferred
from location X to location Y. If the system option is set for the receiving location to take
the markup, then the transfer will be valued at $100 ($10*10) and a markup of $20 (($12$10)*10) for the receiving location. If the system option is set for the sending location to
take the markup, then the transfer will be valued at $120 ($12*10) and a markup of $20
($12-$10)*10) is written for the sending location.
In the daily and periodic stock ledger processes, these transactions are rolled up to the
subclass/day, subclass/week, and subclass/month levels. Only a retail value is
associated with a markup, and therefore markups are only included in the ending
inventory calculations for retail.
The following is an example of what a TRAN_DATA record would look like for this
transaction code:
Transaction Data 35
Markup $3
Initial Markon $5
Price Change
When the retail price of an item is reduced below its current price because of a
permanent or regular price change, it is recorded as permanent markdown under this
tran code. Permanent price changes are created in the Oracle Retail Price Management
(RPM) application. They can also happen because of the changing of a zone group for an
item or the changing of the zone in which stores exists for a particular zone group.
This record is location specific and the unit quantity considered for posting is the stock
on hand for the item in that location, along with the in-transit quantity. The time for
posting this record is the effective date of the price change. That is, this transaction will
be posted at the point in time when new price for that item becomes effective. Price
changes are inserted in RMS by the RPM daily batch.
The total retail value is calculated as the difference between the new retail and the old
retail, multiplied by the total unit quantity.
Example of Permanent Markdown in the event of Price Change:
Item A, Location X
Initial Retail $15
Markdown $3
New Retail $12
Initial Markon $5
Initial Cost $10
The new price for Item A is effective from January 2nd. The SOH on that day for item A at
location X is 150 units. The total retail value posted as markdown on January 2nd will be
$450. This is calculated as:
Markdown Retail = (SOH*Old Retail) (SOH*New Retail)
Markdown Retail = (150*15) (150*12) = $450
Transfers
This transaction is written in the case of a transfer, if the unit retail at the sending location
and the receiving location is different.
The location for which it is posted is as per the system options (defined in the System
Options section) for determining markdown location, either the shipping or receiving
location. The quantity considered is the quantity in the shipment, and it will be posted
when transfer status is moved to shipped. The transfer number is also captured in the
reference number field of this tran code.
Example for Transfer:
Item A regular retail is $12 at location X and $10 at location Y. 10 units are transferred
from location X to location Y. If the system option is set for the receiving location to take
the markdown, then the transfer will be valued at $120 ($12*10) and a markdown of $20
(($12-$10)*10) for the receiving location. If the system option is set for the sending
location to take the markdown, then the transfer will be valued at $100 ($10*10) and a
markdown of $20 ($12-$10)*10) will be written for the sending location.
These transactions are rolled up to the subclass/day, subclass/week, and
subclass/month levels. Only a retail value is associated with a markdown, and therefore
these are only included in the ending inventory calculations for retail.
The following is an example of what a TRAN_DATA record would look like for this
transaction code:
Transaction Data 37
Markdown cancels are recorded at the point in time that the new price for the item goes
into effect in RMS (that is, the effective date of the price change). The unit quantity that
makes up the transaction record is the stock on hand for the item at the location, along
with any in-transit quantity. The total retail value is calculated as the difference between
the new retail and the old retail, multiplied by the total unit quantity.
These transactions are inserted by the RPM daily batch when a price change goes into
effect.
The Markdown Cancel transactions are rolled up to the subclass/day, subclass/week,
subclass/month levels and also used in the ending inventory calculations for a particular
period. Only a retail value is associated with a markdown cancel, and therefore
markdown cancels are only included in the ending inventory calculations for retail.
Example for Markdown Cancel:
Item A, Location X
Initial Retail $20
New Retail 2 $17
Markdown $5
Markdown Cancel $2
The new price for Item A becomes effective from January 2nd. SOH on that day for item A
at location X is 150 units. The total retail value posted as markdown cancel on January 2nd
is $300. This is calculated as:
Markdown Cancel Retail = (SOH*New Retail) (SOH*Old Retail)
Markdown Cancel Retail = (150*17) (150*15) = $300
Note: If the new price is set above the Initial Retail, then the
The following is an example of what a TRAN_DATA record would look like for this
transaction code:
Transaction Data 39
The new clearance price for Item A ($15) gets effective from January 2nd (original Retail
$17). SOH on that day for item A at location X is 150 units. The total retail value posted as
clearance markdown on January 2nd will be $300.
This is calculated as:
Clearance Markdown Retail = (SOH*Old Retail) (SOH*New Retail)
Clearance Markdown Retail = (150*17) (150*15) = $300
These transactions are inserted by RPM daily batch.
The Clearance Markdown transactions are rolled up to the subclass/day,
subclass/week, and subclass/month levels and also used in the ending inventory
calculations for a particular period. Only a retail value is associated with a clearance
markdown, and therefore clearance markdowns are only included in the ending
inventory calculations for retail.
The following is an example of what a TRAN_DATA record would resemble for this
transaction code:
Transaction Data 41
Transaction Data 43
Additionally, the inventory status code, which corresponds to the unavailable bucket to
which the stock was moved, is also captured in the second reference column and in the
case of transfer of unavailable inventory, the transfer number is captured in the first
reference column with the transaction for reporting and reference purposes.
The following is an example of what a TRAN_DATA record would look like for this
transaction code:
Transaction Data 45
In this transaction code, Location Up Charge components that have been added to
Transfers or Allocations with an Up Charge Type of Profit are recorded. This record is
inserted for the receiving location as soon as the shipment of the transfer or allocation is
processed by RMS. The transfer or allocation number is recorded in the first reference
field of this tran data record.
These transactions are rolled up to the subclass/day, subclass/week, and
subclass/month levels; and used in the ending inventory calculations at cost only. These
costs are added to the stock ledger cost value of the item and the weighted average cost
at the receiving location.
The following is an example of what a TRAN_DATA record would look like for this
transaction code:
This tran code applies for all transactions that involve inventory moving between two
company owned stockholding locations in the same transfer entity or set of books both
transfers and allocations.
Under this transaction type, number of units, total cost and total retail of the transaction
are captured. The cost and retail is the same as the cost and retail on the accompanying
transfer out transaction (see transaction code 32 for details) for the sending location.
Additionally, the RMS transfer number is captured as part of the transaction record for
reporting and reference purposes.
The Transfer In transactions captured in RMS are rolled up to the subclass/day,
subclass/week and subclass/month levels and used in the ending inventory calculations
for a particular period.
The following is an example of what a TRAN_DATA record would look like for this
transaction code:
Transaction Data 47
Under this transaction type, number of units, total cost and the total retail of the
transaction are captured.
Additionally, the RMS transfer number is captured as part of the transaction record for
reporting and reference purposes.
The Transfer out transactions captured in RMS are rolled up to the subclass/day,
subclass/week and subclass/month levels and used in the ending inventory calculations
for a particular period.
The following is an example of what a TRAN_DATA record would look like for this
transaction code:
Total Cost (cost accounting method): Number of units transferred * Average Cost or
standard cost at sending location
Total Cost (retail accounting method): (Number of units transferred * Unit Retail at
sending location) * (1 Cumulative Mark on %)
The Book Transfer Out transactions captured in RMS are rolled up to the subclass/day,
subclass/week and subclass/month levels and used in the ending inventory calculations
for a particular period. Additionally, the RMS transfer number is captured as part of the
transaction record for reporting and reference purposes.
The following is an example of what a TRAN_DATA record would look like for this
transaction code:
Total Cost (cost accounting method): Number of units on hand * Average Cost or
standard cost at the location
Total Cost (retail accounting method): (Number of units on hand * Unit Retail at the
location) * (1 Cumulative Mark on %)
Transaction Data 49
Total Cost: Number of units transferred * Per Unit agreed upon Selling Price or
average cost or standard cost at the sending location (if no transfer price specified)
Total Retail: Number of units transferred * Per unit current retail at the receiving
location.
Additionally, for reporting and reference purposes, the RMS transfer number is captured
as part of the transaction record in ref_no_1 field, shipment number is captured in
ref_no_2 field and location ID of the sending location in GL_REF_NO field.
The Intercompany Transfer In transactions captured in RMS are rolled up to the
subclass/day, subclass/week and subclass/month levels and used in the ending
inventory calculations for a particular period.
The following is an example of what a TRAN_DATA record would look like for this
transaction code:
Total Cost (cost accounting method): Number of units transferred * Average Cost or
standard cost at sending location
Total Cost (retail accounting method): (Number of units transferred * Unit Retail at
sending location) * (1 Cumulative Mark on %)
Total Retail: Number of units transferred * Agreed upon Selling Price or average
cost/standard cost at the sending location (if no transfer price specified)
Note: Any variance between agreed upon selling price and
Additionally, for reporting and reference purposes, the RMS transfer number is captured
as part of the transaction record in ref_no_1 field; shipment number is captured in
ref_no_2 field and location ID of the receiving location in GL_REF_NO field.
The Intercompany Transfer out transactions captured in RMS are rolled up to the
subclass/day, subclass/week and subclass/month levels and used in the ending
inventory calculations for a particular period.
The following is an example of what a TRAN_DATA record would look like for this
transaction code:
Transaction Data 51
Transaction Data 53
Transaction Data 55
Transaction Data 57
This record captures the units in the transaction and VAT amount at cost. For purchases,
RUAs, RCAs and consignment sales, VAT amount is a positive value and is calculated as
(cost * VAT rate/100). For return to vendor transactions, the VAT amount is a negative
value and calculated as ((cost restocking fee) * VAT rate/100). The VAT rate is retrieved
from VAT_ITEM table. Additionally, the Order Number or RTV Order Number are
recorded in the first reference field. The Tax Code is also recorded in the GL_REF_NO
field. This allows posting to the General Ledger at Tax Code level.
The VAT In Cost transactions captured in RMS are rolled up to the subclass/day,
subclass/week and subclass/month levels for a location and posted to G/L. They are not
included in inventory calculations.
The following is an example of what a TRAN_DATA record would look like for this
transaction code:
Transaction Data 59
These transaction codes are calculated and are stored in the week data or month data
tables. The calculations for these are described in the section Accounting Methods of
this document. Of these, transaction codes, opening stock and closing stock are never
converted to primary currency.
Note: All the transaction codes entered in code detail table
Transaction Data 61
Cost/SL
Retail/SL
01 Sales/Return
04 Customer Returns
10 Weight Variance
11 Markup
12 Markup Cancel
13 Markdown
14 Markdown Cancel
15 Promotional Markdown
16 Clearance Markdown
17 Intercompany Markdown
18 Intercompany Markdown
20 Purchases
22 Stock Adjustments
26 Freight Cost
X
X
28 Up Charge Profit
29 Up Charge Expense
30 Transfer In
31 Book Transfer In
32 Transfer Out
34 Reclassification In
36 Reclassification Out
Tran Codes
Cost/SL
Retail/SL
37 Inter-company Transfer In
50 Open Stock
51 Budgeted Shrink
X
X
52 Close Stock
53 Gross Margin
54 HTD GAFS
60 Employee Discount
62 Freight Claims
65 Restocking Fee
70 Cost Variance
71 Cost Variance
81 Cash Discount
82 Wholesale/Franchise Sales
83 Wholesale/Franchise Returns
85 Wholesale/Franchise Markdowns
87 VAT In Cost
Transaction Data 63
Tran Codes
Cost/SL
Retail/SL
Description
ADJ_CODE
This field indicates the type of adjustment for which this record is written
to correct a previous error. The valid values for this field are: C- Cost
adjustment, U Unit adjustment, A - ALC (Actual Landed Cost)
adjustment. This field is written for Tran codes 20 and 70.
AV_COST
This field contains the average cost for the item from the item/location
table only for the 'Net Sales' transaction record (transaction code - 1) and
held in the local currency of the location.
CLASS
This field contains the class number associated with the item for which
transaction records are posted.
DEPT
This field contains the department number associated with the item for
which transaction records are posted.
GL_REF_NO
ITEM
This field contains unique alphanumeric identifier for the item on the
transaction.
LOCATION
This field contains the unique identifier for the location for which the
transaction is posted. The location is a store if 'Location type' is 'S', a
Warehouse or Internal Finisher if 'Location type' is 'W', and an External
Finisher if 'Location type' is 'E'.
LOC_TYPE
This field contains the type of the location for which the transaction is
posted. Valid Values are: S = Store, W = Warehouse, E = External Finisher.
NEW_UNIT_RETAIL
This field contains the new unit retail of the item because of a change in the
original retail. The change in the original retail takes place because of
markup or markdown activities and is recorded for transaction types 11 to
16. This field is stored in the local currency.
OLD_UNIT_RETAIL
This field contains the old unit retail of the item before a change taking
place because of markup or markdown activities; it is recorded for
transaction types 11 to 16. This field is stored in the local currency.
Description
PACK_IND
This field indicates whether or not the item is a pack item. Since transaction
data records are not posted for pack items, this field is not used anymore
and is defaulted to either 'NULL' or 'N'.
PGM_NAME
This field identifies the Oracle Retail module which inserted the record into
the transaction data table.
REF_NO_1
This field contains the reference number associated with the transaction.
The reference number can be used for indentifying related transactions for
reporting purposes. For example, this field would contain the order
number for a transaction type of 20 related to purchase orders.
REF_NO_2
This field contains the reference number associated with the transaction.
The reference number can be used for indentifying related transactions for
reporting purposes. For example, this field would contain the shipment
number for a transaction type of 20 related to purchase orders.
REF_PACK_NO
This field is used to store pack number for transaction items if it was a part
of a pack.
SALES_TYPE
This field contains the type of sale for an item. The valid values are Regular,
Clearance, and Promotion. Any sale where the price differs from what RMS
expects is recorded as Promotional. This field contains a value for 'Net
Sales' transaction records (transaction code - 01) and Non-Inventory Sales
(transaction code - 03).
SUBCLASS
This field contains the subclass' number associated with the item for which
transaction records are posted.
TIMESTAMP
This field contains the time at which the transaction record was recorded
into the transaction data table.
TOTAL_COST
This field contains the total cost associated of the transaction in the local
currency of the location where the transaction took place.
TOTAL_COST_EXCL_ELC This field contains the transaction cost exclusive of estimate landed cost for
purchases transactions (Transaction Code - 20).
TOTAL_RETAIL
This field contains the total retail value of the transaction in the local
currency of the location where the transaction took place.
TRAN_CODE
TRAN_DATE
UNITS
This field contains the number of units of the item involved in the
transaction.
VAT_RATE
This field contains the VAT rate at the selling store and recorded only for
'Net Sales' transaction records (transaction code -1). For other transaction
records, it remains empty.
Transaction Data 65
5
Stock Ledger Process Consolidation and
Batch Processing
While RMS cannot be considered a planning tool, there are some basic planning features
in the system. One of these features is the existence of two budget tables. Data is loaded
into these tables only through the use of the online dialog in base RMS; no standard
upload program exists to load the data. Additionally, there are no reports in base RMS
that are built upon this information. The purpose of these tables is mostly for reporting.
For example, retailers can build a custom report that compares budget stock ledger
values to actual; therefore, if retailers choose to use these tables, they are likely to create
custom reports to view the information.
code for purchases captures the order number and shipment number in the two reference
fields. Also, for a few transaction codes, the general ledger reference number is also
recorded and can be used for defining the General Ledger account relationship, along
with dept, class, subclass, and location, and so on. For example for Inventory adjustment
transaction code this field contains an Inventory Adjustment Reason Code.
At day end, all transactions on TRAN_DATA table are added to
TRAN_DATA_HISTORY table and TRAN_DATA is then truncated. TRAN_DATA
cannot be viewed on-line in RMS until it is added to TRAN_DATA_HISTORY table.
Keeping only one days worth of data on TRAN_DATA table improves the performance
of the interface run and end-of-day processing, as well as the performance of transactions
writing to TRAN_DATA table throughout the batch cycle.
IF_TRAN_DATA
Before the end of day processing is run, the records in TRAN_DATA are removed from
the table and moved to a staging table called IF_TRAN_DATA. This table mirrors
TRAN_DATA table and is used as an interface point to financial systems and is also used
as the driving table for the end of day processing.
TRAN_DATA_HISTORY
Transaction level records are kept historically on the table TRAN_DATA_HISTORY
table. Records are written to this table based on the data on IF_TRAN_DATA table. This
is the table that is used to view transaction-level data on-line in RMS.
The parameter TRAN_DATA_RETAINED_DAYS_NO specifies the number of days that
transaction-level stock ledger data is kept in the system in the transaction data history
table.
DAILY_DATA
The DAILY_DATA table stores the monetary values of the stock ledger at the
subclass/location/day level. The table is built by running the end of day process, which
rolls up all transaction-level stock ledger records to this level. All fields on this table are
based on the rolled up information from the transaction level; there are no calculated
fields. This is because days in RMS are not really closed in the same ways in which
weeks or months are closed. Days stay open until the month is closed for late
transactions.
This table is also the basis for the creation of Weekly and Monthly stock ledger tables (see
the following two sections). Daily data information is kept in the system for 18 months,
which facilitates this year/last year comparisons over a six month time frame. All records
older than 18 months are automatically purged in the end of half processing run.
DAILY_DATA_TEMP acts as a flag that late posted transactions have been received for
prior weeks in the period.
WEEK_DATA
The WEEK_DATA table stores the monetary values of the stock ledger at the
subclass/location/week level. This table is only created and updated if a retailer chooses
to run their stock ledger at a weekly level and they are running a 454 calendar. The table
is built by running the end of week process, which rolls up day-level stock ledger records
to this level. Most of the fields on this table are based on the rolled up information from
the day level. However, there are also several calculated fields on the table, such as
Opening Stock, Closing Stock, Shrinkage, Gross Margin, Half-to-Date Goods Available
for Sale, and so on.
Even after the end-of-week processing has been run, a week is not necessarily closed.
Weeks in RMS remain open until the month in which the week exists is closed. Until that
time, data continues to be posted to the week as late transactions are received from the
POS, warehouse or other external systems. This allows a retailer to determine a
temporary end of week inventory position for each week, but not finalize the position
until all transactions have been received for the month.
Week Data information is kept in the system for 18 months, which will facilitate this
year/last year comparisons over a six month time frame. All records older than 18
months are automatically purged in the end of half processing run.
MONTH_DATA
The MONTH_DATA table stores the monetary values of the stock ledger at the
subclass/location/month level. The table is built by running the end-of-month process,
which rolls up day-level stock ledger records to this level. Most of the fields on this table
are based on the rolled up information from the day level. However, there are also
several calculated fields on the table, such as Opening Stock, Closing Stock, Shrinkage,
Gross Margin, Half-to-Date Goods Available for Sale, and so on.
After the end-of-month processing has been run, the month is closed and transactions
can no longer be posted to the month. If the transaction for the month is processed after
the month closing, then it will be posted for the current day/month.
Month Data information is kept in the system for 18 months, which will facilitate this
year/last year comparisons over a six month time frame. All records older than 18
months are automatically purged in the end of half processing run.
HALF_DATA
The HALF_DATA table stores values at the subclass/location/half-year level. The table
is built by running the end-of-half process and updated based on end-of-month and cycle
counting processes.
This table contains only three informational fields outside the key: Inter-Stock Take
Shrink, Inter-Stock Take Sales, and Shrinkage Percent.
The Inter-stock Take Sales amount is the cumulative net sales value since the last time a
Unit & Value stock count was taken for a subclass/location. The Inter-Stock Take Shrink
amount is the cumulative estimated (or budgeted) shrinkage value since the last time a
Unit & Value stock count was taken for a subclass/location. These are valued at cost for
the cost department and at retail for the retail department. It is reset to 0 on the date the
count is processed for this subclass/location, after the actual shrinkage has been
calculated. This field is stored in the local currency.
The Shrinkage Percent is calculated as the Inter-Stock Take Shrinkage amount/InterStock Take Sales amount. All of these values are updated in the Stock Count Shrinkage
Update program.
MONTH_DATA_BUDGET
This table holds the month-by-month data for budget forecasting. It can be manually
updated through online forms and mainly used for reporting purposes.
This table contains one row for each department/location/half/month number within
the company. New rows are added to this table when a new location or department is
added to the system or in the end of half processing which adds rows for the new half for
all department/location combinations. Rows are automatically purged by the end of half
processing run when they are over eighteen months old. When this happens, all six
months of the half are purged resulting in twelve months of retained data.
HALF_DATA_BUDGET
The HALF_DATA_BUDGET table is used for holding data required for budgeting and
gross margin forecasting. It contains budgeted percentages for cumulative markon,
markdowns, gross margin and shrinkage.
This table contains one row for each department/location/half within the company and
can be updated online by budget forms. New rows are added to this table when a new
location or department is added to the system or in the end of half processing which
adds rows for the new half for all department/location combinations.
The half data budget table differs from the month data budget table in that it is not used
only for reporting purposes. Shrinkage percent captured on the half data budget table
drives processing in the system, based on the setting of the Budgeted Shrink Indicator.
Rows are automatically purged by the end of half processing run when they are over
eighteen months old. When this happens all six months of the half are purged resulting
in twelve months of retained data.
Tran_Data (A/B)
Salstage.pc
Deal_Pref_
Tran_Data
If_Tran_Data
Salapnd.pc
Saldly.pc
Fifgldn1.pc
Daily_Data_Temp
Daily_Data
Salweek.pc
Salmth.pc
Week_Data
Month_Data
Fifgldn2.pc
Tran_Data_History
Salprg.pc
Fifgldn3.pc
Stg_Fif_GL_Data
Salmaint.pc
Stock_Ledger_
Inserts
Salins.pc
Half_Data
Saleoh.pc
Month_Data_
Budget
Half_Data_Budget
To call this program, the end of day process for the stock ledger would not be completely
correct, however, because a day does not really close in the stock ledger until the month
closes. Each time that the Daily Stock Ledger Processing program runs, all transactionlevel data is processed, whether it is for the current date, a date since the last month
closing or even a date prior to the last month closing. For transactions occurring on the
current date or since the last month close, they are processed by simply summarizing the
date and updating the current information on DAILY_DATA for the date of the
transaction. However, if a transaction occurred prior to the last month that was closed
(for example, the transaction was dated 3/15 and the last end of month date was 3/20),
then that transaction will be dated with the current date and summarized with the
current dates records. Also, in this last case, a warning message will be written to the
batch log that alerts the user to the problem. The message the users receive is *ALERT*
Transactions have been found for previous months.
This program can be run at any time during the month not necessarily just at monthend. Open stock counts from the month may exist based on the system option
(CLOSE_MTH_WITH_OPN_CNT_IND). If this indicator is Y, then retailers are able to
keep a count open across a single month closing in the stock ledger and still close the
month financially. A Unit & Value stock count is considered as open until all variances
(both unit and value) have been reviewed and applied. Special processing exists if it is
allowed and there are open stock counts from the current month. Open stock counts from
previous months however cannot exist regardless of the setting.
Note: Refer to the Oracle Retail Merchandising System Stock
7
Stock Ledger Online Forms and Functional
Views
Transaction Data Form
Use this from to view the transaction history online. It shows the transactions contained
in the TRAN_DATA_HISTORY table.
RMS Start Menu > Finance > Transaction Data View
The detail window on the Transaction Data form allows visibility to more details about
the transaction that created it, such as the transfer number for a Purchase transaction.
The data is displayed based on the search criteria entered. This form is a multi-view form
as well, so there are many options for what is displayed as well as several pre-defined
default views. You can customize this form. Different stock ledger views for departments
using cost method of accounting as well as retail method of accounting are described in
the subsequent sections.
For departments that use the retail method of accounting, the following views are
available:
The following views are common in both the cases where the department is using cost or
retail method of accounting
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
oracle.com
Copyright 2014, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only, and the contents hereof are subject to change
without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied
warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document, and no contractual
obligations are formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic or
mechanical, for any purpose, without our prior written permission.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of
SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered
trademark of The Open Group.