RMS Stock Ledger White Paper-14.1.x

Oracle Retail Merchandising
System
Stock Ledger Whitepaper
Release 14.1.x
January 2015
The following is intended to outline our general

product direction. It is intended for information purposes
only, and may not be incorporated into any contract. It is not
a commitment to deliver any material, code, or functionality,
and should not be relied upon in making purchasing
decisions. The development, release, and timing of any
features or functionality described for Oracles products
remains at the sole discretion of Oracle.
Note:
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
Deals Income (Sales) (Tran Code 06) ............................................................................... 32

Deals Income (Purchases) (Tran Code 07) ...................................................................... 32
Fixed Income Accrual (Tran Code 08) ............................................................................. 33
Weight Variance (Tran Code 10) ...................................................................................... 33
Markup (Tran Code 11) ..................................................................................................... 33
Price Changes ................................................................................................................. 34
Pack Component Sales .................................................................................................. 34
Transfers.......................................................................................................................... 35
Markup Cancel (Tran Code 12) ........................................................................................ 35
Permanent Markdown (Tran Code 13) ........................................................................... 36
Price Change ................................................................................................................... 36
Pack Component Sales .................................................................................................. 37
Transfers.......................................................................................................................... 37
Markdown Cancel (Tran Code 14) .................................................................................. 37
Promotional Markdown (Tran Code 15)......................................................................... 38
Promotional Price Change ............................................................................................ 39
Price Changes at the Time of Sales .............................................................................. 39
Clearance Markdown (Tran Code 16) ............................................................................. 39
Intercompany Markup (Tran Code 17) ........................................................................... 40
Intercompany Markdown (Tran Code 18)...................................................................... 40
Purchases (Tran Code 20) ................................................................................................. 41
Stock Adjustment (Tran Code 22) .................................................................................... 43
Stock Adjustment COGS (Tran Code 23) ..................................................................... 43
Return to Vendor (Tran Code 24) .................................................................................... 44
Unavailable Inventory Transfer (Tran Code 25) ............................................................ 44
Freight Cost (Tran Code 26) ............................................................................................. 45
Return to Vendor from QC (Tran Code 27) .................................................................... 45
Profit Up Charge (Tran Code 28) ..................................................................................... 45
Expense Up Charge (Tran Code 29) ................................................................................ 46
Transfer In (Tran Code 30) ................................................................................................ 46
Book Transfer In (Tran Code 31) ...................................................................................... 47
Transfer Out (Tran Code 32)............................................................................................. 47
Book Transfer Out (Tran Code 33)................................................................................... 48
Reclassifications In (Tran Code 34).................................................................................. 49
Reclassifications Out (Tran Code 36) .............................................................................. 49
Intercompany Transfer In (Tran Code 37) ...................................................................... 50
Intercompany Transfer Out (Tran Code 38) ................................................................... 50
Retail Analytics Stock Ledger Adjustment (Tran Code 41).......................................... 51
Retail Analytics Inbound Transfer Receipt (Tran Code 44) ......................................... 52
Employee Discount (Tran Code 60)................................................................................. 52
Freight Claim (Tran Code 62) ........................................................................................... 52
Work Order Activity Cost Update Inventory (Tran Code 63) .................................. 53
Work Order Activity Cost Post to Financials (Tran Code 64) ................................... 53
iii
Restocking Fee (Tran Code 65) ......................................................................................... 54

Cost Variance (Tran Code 70)........................................................................................... 54
Cost Variance Retail Accounting (Tran Code 71) ....................................................... 55
Cost Variance Cost Accounting (Tran Code 72) ......................................................... 55
Cost Variance Receiver Cost Adjustment FIFO (Tran Code 73) ............................... 56
Workroom / Other Cost of Sales (Tran Code 80) .......................................................... 56
Cash Discount (Tran Code 81) ......................................................................................... 56
Franchise Sales (Tran Code 82) ........................................................................................ 56
Franchise Returns (Tran Code 83) ................................................................................... 57
Franchise Markups (Tran Code 84) ................................................................................. 57
Franchise Markdowns (Tran Code 85) ............................................................................ 58
Franchise Restocking Fee (Tran Code 86) ....................................................................... 58
VAT In Cost (Tran Code 87) ............................................................................................. 58
VAT Out Retail (Tran Code 88) ........................................................................................ 59
General Ledger Mapping Transaction Codes ................................................................... 59
Intercompany Margin (Tran Code 39) ............................................................................ 60
Open Stock (Tran Code 50) ............................................................................................... 60
Budgeted Shrink (Tran Code 51) ..................................................................................... 60
Close Stock (Tran Code 52) ............................................................................................... 60
Gross Margin (Tran Code 53) ........................................................................................... 60
HTD GAFS (Tran Code 54) ............................................................................................... 61
Inter Stocktake Sales Amount (Tran Code 55) ............................................................... 61
Inter Stocktake Shrink Amount (Tran Code 56) ............................................................ 61
Stocktake MTD Sales Amount (Tran Code 57) .............................................................. 61
Stocktake MTD Shrink Amount (Tran Code 58)............................................................ 61
Stocktake Book Stock Cost (Tran Code 59) ..................................................................... 61
Stocktake Actual Stock Cost/Retail (Tran Code 61)...................................................... 61
Transaction Data Stock Ledger Impact ........................................................................... 62
Transaction Data Data Elements ...................................................................................... 64
5 Stock Ledger Process Consolidation and Batch Processing ............................ 67
Stock Ledger Budgets ........................................................................................................... 67
Stock Ledger Tables .............................................................................................................. 67
TRAN_DATA (A&B) ..................................................................................................... 67
IF_TRAN_DATA ........................................................................................................... 68
TRAN_DATA_HISTORY ............................................................................................. 68
DAILY_DATA ................................................................................................................ 68
WEEK_DATA ................................................................................................................. 68
MONTH_DATA............................................................................................................. 69
HALF_DATA ................................................................................................................. 69
MONTH_DATA_BUDGET .......................................................................................... 69
HALF_DATA_BUDGET ............................................................................................... 70
Stock Ledger Batch Process ................................................................................................. 71
iv
Stock Ledger Batch Description ................................................................................... 72

General Ledger Cross Reference .................................................................................. 75
General Ledger Batch Description............................................................................... 76
7 Stock Ledger Online Forms and Functional Views ................................................ 79
Transaction Data Form ......................................................................................................... 79
Stock Ledger View Form...................................................................................................... 80
Stock Ledger Cost Summary View ........................................................................... 80
Stock Ledger Cost This Year/Last Year View ........................................................ 81
Stock Ledger Retail Summary View......................................................................... 81
Stock Ledger Merchandise Handled View .............................................................. 82
Stock Ledger Retail Reductions View ...................................................................... 82
Stock Ledger Retail This Year/Last Year View ...................................................... 83
Stock Ledger Inventory Report View ....................................................................... 83
Stock Ledger Markdown Report View .................................................................... 84
Stock Ledger Franchise View .................................................................................... 84
Stock Ledger Intercompany Transfer View ............................................................ 85
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:
Stock ledger attributes
Accounting methods
Budgeted shrink
Transaction data
What impacts the stock ledger
Stock ledger processes

Note: This document is not intended to give a detailed look
at the interfaces that Oracle Retail Merchandising System

(RMS) provides or the financial packages themselves.
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.
Stock Ledger Organization

The Stock Ledger can broadly be divided into two major elements: Transaction Data and
Roll Ups.
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.
Transaction Data API

The Transaction Data API is a batch process that can be used to load financial
transactions into the RMS TRAN_DATA table to adjust the stock ledger value. The
upload batch uses a SQL loader to stage data, perform business and technical validations,
and upload it to the RMS TRAN_DATA tables. Users have the option to upload
transactions at an Item level or Subclass level. When uploading at the item level, and
using the WAC method of inventory valuation, you can also indicate whether the
transactions should update WAC.
Transactions loaded through this API will not impact units in any way, regardless of
whether a unit value is included or not. These transactions will only be rolled up into the
RMS Stock Ledger Overview 3
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.
Stock Ledger Roll Ups

Stock Ledger roll ups are created when the individual transactions from the transaction
data are aggregated at the subclass/location level for days, weeks, and months, based on
the calendar settings in the system.
As mentioned previously, at the time of the roll up of the transaction data to the daily,
weekly, and monthly level, records are kept in the local currency and also converted to
the primary currency. This processing helps retailers who have locations dealing in
different currencies by facilitating corporate reporting in the primary currency, while
providing flexibility to give visibility to the local currency at the location level.
Stock Ledger and Merchandising Transactions

Purchase Order
Receipts
Transfer Order
Perpetual
Inventory
Sales/Returns
Stock Count
Inventory
Adjustment
Transaction Data
Return to Vendor
Shipments
Transfer Order
4 Oracle Retail Merchandising System
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:
Transactions involving receipt of merchandise
Transactions involving shipping out the merchandise
Transactions only affecting the inventory position.
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.
RMS Stock Ledger Overview 5
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.
Budgeted Shrink Indicator

The Budgeted Shrink Indicator (BUD_SHRINK_IND) designates whether actual
shrinkage amounts are calculated based on inventory adjustments and cyclical counts, or
based on budgeted shrinkage percent in the period ending inventory calculations in the
stock ledger.
If this field is set to Y, budgeted shrinkage is used in the calculation of period ending
inventory. If this field is set to N, the stock adjustments are used instead of budgeted
shrinkage.
Budgeted shrinkage is calculated using budgeted shrinkage percent (stored on the
HALF_DATA_BUDGET table as the SHRINKAGE_PCT field) at the department/store
level for a financial half multiplied by sales at retail or at cost, depending on whether the
retail or cost accounting method is used. This number is applicable to all the subclasses
within that department. Budgeted shrink percentage can be applied only to stores and
not warehouses because stores have sales and warehouses do not. For warehouses, actual
shrink is always used.
The objective behind calculating an estimated value each month is to spread the effect of
shrinkage over the whole year rather than merely the months when the stock count
happens or actual shrinkage occurs. The estimated/budgeted shrinkage is adjusted to
actual when a unit/value stock count is posted.
The different scenarios that can occur for shrinkage calculation are described below.
RMS Stock Ledger Attributes 7
System Options
Shrinkage Calculation
Budgeted Shrink Indicator =
Y
Budgeted Shrink Indicator =

N
No Unit & Value stock count

has occurred during the period
Net sales * Budgeted shrink

rate
- 1 * Stock adjustments
Unit & Value stock count has

occurred during the period
Shrinkage amount from the

beginning of the period to the
date of the count (calculated in
the stock count process)
Actual shrinkage from the

stock take
+ (-1 * Stock adjustments)
+ Actual shrinkage from the

count
+ Net sales from stock take to
the end of the month *
Budgeted shrink Rate
Note: Refer to the Oracle Retail Merchandising System Stock
Counts Overview white paper (1536804.1) for further details

on this section.
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.
Start of Half Month

This indicator (START_OF_HALF_MONTH) specifies the month number of the first
month of the first half of any year. The month number must be from -12 to 12, excluding
0 and -1. A negative number indicates that the first half of a year starts in the previous
calendar year with -2 = February, -3 = March, and so on. A positive number corresponds
to the normal calendar month number.
Consolidated Exchange Rate

The Consolidation Exchange Rate indicator (CONSOLIDATION_IND) determines
whether a consolidation or operational exchange rate is used for currency conversion and
thereby whether Oracle Retail supports the addition, maintenance, and viewing for the
consolidation exchange rate in the Pending Exchange Rate Maintenance process.
If this field contains Y, then the consolidation exchange rate maintenance is supported,
and consolidation exchange rate is used as the default for all currency conversion within
Oracle Retail. If this field is N, then the operational exchange rate is used as the default
for all currency conversion within Oracle Retail.
Oracle Retail only uses one set of exchange rates in all currency conversions, either
consolidation or operational, depending on how this parameter is defined.
In addition to C consolidation and O Operational, RMS also allows P Purchase
Order exchange rate types to be set up in the database.
If an exchange rate of P Purchase Order type does not exist, the system uses the
default of either Operational or Consolidated. As an example, if a P rate type exists in the
system, the Purchase Order (PO) process uses this rate, but if one does not exist, the PO
process uses the Operational or Consolidated rate type.
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.
Default Tax Type

The parameter DEFAULT_TAX_TYPE determines what type of taxation is used in RMS.
The possible options are Simple VAT (SVAT), Sales Tax (SALES), and Global Tax
(GTAX).
In the case of SVAT, RMS uses internal VAT functionality. In the case of SALES, RMS
supports US sales taxation through geo-codes. In the case of GTAX, RMS is expected to
source the tax information and calculation from an external application. At this point,
GTAX is only supported for Brazil.
Estimated Landed Cost

The landed costs functions allow you to define expenses, assessments, up charges, and
combinations in order to track the costs involved in purchasing and moving goods from
the manufacturer to a distribution center or store. Estimated landed cost (ELC) is the
bottom-up cost estimate created by the buying organization. ELC is comprised of cost
components from the supplier, trading partners, item, origin country, and banks which
are brought together during the PO creation in order to develop an estimate of costs
associated with purchasing a particular item on the current PO.
Within RMS, landed cost is defined using computation value bases (CVB), expenses, and
assessments. Expenses and assessments are more generically referred to as cost
components. Computation value bases describe how expenses and assessments are
combined in order to provide a base for the calculation of other expenses and
assessments. Assessments differ from expenses in that they are defined by a government
agency.
The ELC_IND indicator determines if the ELC is used in the system. ELC is primarily
used for estimating the cost of the item as close as possible to the final, actual landed cost
by adding cost components to the PO cost. Note that this functionality is not compatible
with the use of standard cost. While posting transaction records for purchases (tran code
20), the purchase value net of ELC is also recorded in the TOTAL_COST_EXCL_ELC
column.
There are two more system options related to ELC in RMS with regard to company stores
and wholesale/franchise stores:
ELC_INCLUSIVE_IND_COMP_STORE This field allows the system to determine

if pricing cost and acquisition cost should be inclusive of ELC for company stores.
System Options
ELC_INCLUSIVE_IND_WF_STORE This field allows the system to determine if

pricing cost and acquisition costs should be inclusive of ELC for wholesale/franchise
stores.
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.
General Ledger Rollup Level

The system option GL_ROLLUP specifies the roll up level of Oracle Retails general
ledger information when bridged to a financial system. Valid values are: D Department, C - Class, and S - Subclass.
Minimum / Maximum Cumulative Mark-on Percent

Cumulative Mark-on Percent is used to estimate the ending inventory at cost when using
the retail method of accounting in RMS. RMS also gives the flexibility to set a minimum
and maximum cumulative mark-on percentage (MAX_CUM_MARKON_PCT and
MIN_CUM_MARKON_PCT).
The cumulative mark on % is calculated by the weekly stock ledger program (or monthly
if not using weekly accounting). It is calculated using beginning balances and beginning
markon % and then adding transactions from the current week to establish the new
value. Transactions for the following week then use the cumulative markon % for the
transactions (for example, transfers, sales, and so on) that was established at the end of
the previous week (or month).
If the calculated value lies outside the max and min tolerances, then the system uses the
value defined as Budgeted Intake % (BUD_INT). This value is also defined at the
department level. If it lies within the tolerances, the calculated percent is used in
calculating the ending inventory at cost. The use of the MAX_CUM_MARKON_PCT
and the MIN_CUM_MARKON_PCT is optional.
Multiple Set of Books

As the scale of operations of retailers grows, they may have a requirement for multiple
sets of books in their financial system. This requirement especially applies when the
retailer has operations in various countries with different currencies and calendars, or if
the retailer has divided its operations into multiple legal entities. Note that RMS supports
only one calendar, regardless of the number of sets of books.
From version 13.0 onwards, RMS enables multiple set of books in the system. Therefore,
a retailer can create multiple financial books in the general ledger, and the RMS stock
ledger can integrate to these different sets of books.
An inter-company transfer occurs when product is transferred between locations with
different transfer entities or locations with different set of books. RMS gives the flexibility
to determine whether a transfer is an intercompany transfer based on its being between
locations with different set of books or different transfer entities using the
INTERCOMPANY_TRANSFER_BASIS system option.
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.
The indicator NWP_RETENTION_PERIOD indicates the number of years the end of

year inventory data is retained in the system.
System Options
Receiver Cost Adjustment Type

This indicator determines how the receiver cost adjustment is carried out in the system.
The valid values of F (FIFO) or S (Standard) are stored in the CODE_DETAIL table with
code type of RUCA. The FIFO option looks at the number of units currently on hand,
compares to the number of units in the receipt being adjusted, and then determines,
based on a First In First Out flow assumption, whether any units from the receipt being
adjusted are still on hand at the location and can be adjusted. RMS does not have a FIFO
inventory, and this FIFO type calculation is made only for Receiver Cost Adjustments.
The Standard Option looks at the number of units currently on hand and compares it to
the number of units on the receipt being adjusted, as the only determination of whether
there are units on hand that can be adjusted.
Retail Markdown for Transfer

This parameter determines which location takes the markdown hit in the case where a
transfer between locations have different retails at the sending and receiving locations.
There are four indicators for controlling the markdown recording in RMS for different
combinations of To Location and From Location. For each of the following system
options, the user can specify whether sending location S or receiving location R will
get the retail markdown difference:
Store to Store Transfer - TSF_MD_STORE_TO_STORE_SND_RCV
Store to Warehouse Transfer - TSF_MD_STORE_TO_WH_SND_RCV
Warehouse to Store Transfer - TSF_MD_WH_TO_STORE_SND_RCV
Warehouse to Warehouse Transfer - TSF_MD_WH_TO_WH_SND_RCV
Retain Transaction Data

The parameter TRAN_DATA_RETAINED_DAYS_NO specifies the number of days that
transaction-level stock ledger data is kept in the system. Each night the transaction level
records, which were created in the system based on various transactions occurring
during the day or through the nightly batch process, are moved to a transaction data
history table and the original table is purged.
The number of days in this parameter corresponds to the number of days that records
remain in the transaction data history table. Because the number of records in this table
grows quite rapidly each day, it is recommended that the number of days for this
parameter be relatively small.
Stock Count Processing

The indicator CLOSE_MTH_WITH_OPN_CNT_IND is used to determine whether or
not the current fiscal month is allowed to be closed while containing an open Unit and
Value stock count.
If the indicator is No, the fiscal month will not be closed if open Unit and Value stock
counts are found within the current fiscal month. If no open stock counts are found,
processing proceeds as normal.
For more information, see the Oracle Retail Merchandising System Stock Counts
Overview white paper (My Oracle Support Doc ID 1536804.1).
System Options
Stock Ledger Retail VAT Inclusive

The indicator STKLDGR_VAT_INCL_RETL_IND specifies whether retail values in
stock ledger are VAT inclusive or not.
If this field has Y, all retail value in the stock ledger (that is, sales retail, purchase retail,
gross margin, and so on) is VAT inclusive. Both Tran code 01 (VAT Inclusive Sales) and
02 (VAT Exclusive Sales) are posted for sales.
If the STKLDGR_VAT_INCL_RETL_IND = N, only the transaction code 01(Net Sales)
is posted for sales.
This field is only applicable when the default tax type is set up as SVAT in the system
and applicable for both departments that use retail or cost method of accounting. In the
case when default tax type is set up as GTAX, it is assumed that all retail values in the
stock ledger will be inclusive of VAT.
Stock Ledger Location Level

The system option STOCK_LEDGER_LOC_LEVEL_CODE determines the location level
the stock ledger runs at Location or All Locations. The options you can choose are S for
each store and T for a total of all stores.
Note: Oracle Retails Stock Ledger runs at the location level.
It requires a customization to run the stock ledger at an all

locations level. This system option is used in a few programs
to make the customization easier, but it does not mean that
the stock ledger location level can be changed automatically
by switching the value of this option.
Stock Ledger Product Level

The system option STOCK_LEDGER_PROD_LEVEL_CODE determines the product
level the stock ledger runs at SKU (K), Subclass (S), Class (C), or Department (D).
Note: Oracle Retails stock ledger runs at Subclass level. It
requires customization to run stock ledger at any other

product level. This system option is used in a few programs
to make the customization easier, but it does not mean that
the stock ledger product level can be changed automatically
by switching the value of this option.
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.
Retail Accounting Method

The Retail method of accounting is the method by which inventory value is measured
using the retail price amount.
RMS records sales, purchases, return to vendor (RTV), reclassification and transfers at
both cost and retail. Purchases and RTVs are recorded using the actual cost, but the Cost
for Transfers, Reclassifications, Sales, and so on is based on the Cumulative Markon %.
The ending inventory is calculated based on the retail values of the transactions
impacting inventory value. The retail method also takes into account markdowns,
markups, markdown cancellations, and markup cancellations in the inventory
calculations because these adjustments in the retail price affect the value of the inventory.
Under this method, RMS determines ending inventory at cost based on the percentage of
the ending inventorys retail value. For this calculation, the historical ratio of available
inventory at cost to available inventory at retail to value inventory is used. This is known
as the cumulative mark-on percentage (CUM %). RMS computes estimated value for
ending inventory cost and cost of sales based on the value of the inventory at the current
retail price (non promotional) multiplied by the cost complement (1 - CUM%). It uses the
prior weeks Cumulative Mark-on Percentage (or prior months if weekly CUM% is
NULL) for each subclass/location to calculate transfers and reclassifications at cost
(sending store/source subclass).
The estimation of ending inventory at cost is done to provide flexibility in sending
ending inventory at both cost and retail to the G/L. Also, ending inventory is used to
calculate cost of sales and margin in the stock ledger.
Inventory Calculation Retail Accounting Method

Ending Inventory at Retail =
Beginning of Month Inventory at Retail
+ Inventory Addition at Retail
- Inventory Reduction at Retail
Accounting Methods
Ending Inventory at Cost =

Ending Inventory at Retail* (1- (CUM%)/100)
Inventory Addition at Retail
Purchases at Retail (20)
- RTV at Retail (24)
+ Markup at Retail (11)
+ Intercompany Markup (17)
- Markup Cancellation at Retail (12)
+ Transfer in at Retail (30)
+ Book Transfer in at Retail (31)
+ Intercompany Transfer at Retail (37)
- Transfer out at Retail (32)
- Book Transfer out at Retail (33)
+ Reclassification in at Retail (34)
- Reclassification out at Retail (36)
+ Franchise Returns at Retail (83)
+ Franchise Markup at Retail (83)
Inventory Reduction at Retail
Net Sales at Retail (01)
+ Permanent Markdown at Retail (13)
+ Promotional Markdown at Retail (15)
+ Clearance Markdown at Retail (16)
+ Intercompany Markdown (18)
- Markdown Cancellation at Retail (14)
+ Employee Discount at Retail (60)
+ Shrinkage at Retail (calculated value)
+ Freight Claims at Retail (62)
- Stock Adjustment at COGS (23)
+ Transfer Out (Intercompany) at Retail (38)
+ Franchise Sales at Retail (82)
+ Franchise Markdown at Retail (85)
Cumulative Mark-on Percent
((HTD GAFS Retail - HTD GAFS Cost)/(HTD GAFS Retail))*100
HTD GAFS = Half to Date Goods Available for Sale
HTD GAFS Retail
When current period is first month of the Half:
Previous Month Ending Inventory Retail + Inventory Additions Retail
When current period is not first month of the Half:
Previous Month HTD GAFS Retail + Inventory Additions Retail
Accounting Methods
HTD GAFS Cost

When current period is first month of the Half:
Previous Month Ending Inventory Cost + Inventory Additions Cost
When current period is not first month of the Half:
Previous Month HTD GAFS Cost + Inventory Additions Cost
Inventory Additions Cost
Purchases Cost (20)
+ Restocking Fee (65)
- RTV at Cost (24)
+ Fright Cost (26)
+Transfer in Cost (30)
+ Book Transfer in Cost (31)
+ Intercompany Transfer in Cost (37)
- Transfer out Cost (32)
- Book Transfer out Cost (33)
+ Reclassification in Cost (34)
- Reclassification out Cost (36)
+ Up Charges (28, 29)
+ Work order activity Cost (63)
+ Franchise Return Cost (83)
+ Franchise Restocking Fee (86)
Cost of Sales
Beginning of Month Inventory Cost +Inventory additions Cost - Ending Inventory Cost
Gross Margin
If STKLDGR_VAT_INCL_IND = 'N', then
Net Sales Retail (01) - Cost of Sales - Workroom Expenses (80) + Cash Discount Amount (81) +
Franchise Net Sale
If STKLDGR_VAT_INCL_IND = 'Y', then
Net Sales Retail (02) - Cost of Sales - Workroom Expenses (80) + Cash Discount Amount (81) +
Franchise Net Sales
Cost Accounting Method

The Cost method of accounting is the method in which inventory is controlled based on
the cost of the merchandise. It is reliant on accurate perpetual inventories. Under this
method, all purchases, transfers, sales and RTVs are recorded at cost in order to calculate
the value of the inventory.
While the Retail method is still widely used in certain verticals, across much of the retail
industry, the Cost method is generally accepted as a best practice. There are many
different ways that the Cost method can be implemented. Oracle Retail supports two
methods of Cost accounting: Average Cost and Standard Cost.
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
the receiving location when inventory is shipped from the

sending location, as in transit inventory is considered owned
by the receiving location.
The WAC is the value of owned inventory at a location and is used to determine the cost
of sales for an item sold at the location. It is also used as the cost for all transactions that
occur for the location that are written to the transaction-level stock ledger. WAC is
recalculated in the following cases:
Purchase Order is received
Transfer is Shipped (for receiving location only)
Receiver adjustments occur
Transfer Reconciliation (Selected scenarios)
Average cost is stored at item/location level in the table ITEM_LOC_SOH.
Weighted Average Cost Calculation*

WAC after PO Receipts
If average cost accounting method is selected and a PO is received, the WAC is
recalculated for the item for the location where the receipt happens. The WAC is
calculated as follows:
(((SOH Quantity + In-transit Quantity) * Old WAC) + (Receipt Quantity * Receipt Cost)) /
((SOH Quantity + In-transit Quantity) + Receipt Quantity)
In the case of pack items, pack component SOH quantity (PACK_COMP_SOH) and pack
component in-transit quantity (PACK_COMP_INTRAN) is considered. In the case of
simple pack catch weight item, the total cost of the pack is used to derive unit cost
instead of receipt cost.
The WAC calculation formula and treatment may differ based on the SOH of the item at
the location prior to and post receipt of a PO. Different PO receipt scenarios and their
impact on WAC are detailed in the following table:
Accounting Methods
No.
Transaction Description
On
Hand
Before
On
Hand
After
Impact on WAC
WAC is set to the unit cost on the PO
A cost adjustment (Tran Code 70) is written

based on the WAC adjustment.
The calculation for the WAC adjustment is:
PO Receipt
1.
PO Receipt with negative on

hand and on hand becomes
positive
(WAC prior to receipt - new PO Cost) * (SOH

prior to receipt)
2.

hand and on hand becomes
zero


prior to receipt)
3.

hand and on hand remains
negative


prior to receipt)
4.
5.
PO Receipt with positive on

hand
PO Receipt with zero on hand
WAC is recalculated as:
((SOH Quantity * Old WAC) + (Receipt Quantity *

Receipt Cost)) / (SOH Quantity + Receipt
Quantity)
+
WAC is set to PO Cost
Note: The SOH is calculated as (Stock on Hand + In-transit)
+ (Pack component SOH + Pack component In-transit).

WAC after Transfer Shipment (Receiving Location)
If the average cost accounting method is selected, in the case of transfers, average cost is
recalculated for the receiving location every time inventory is shipped from the sending
location, as in transit inventory is considered owned by the receiving location. The WAC
is calculated as follows:
(((SOH Quantity + In-transit Quantity) * Old WAC) + (Quantity Transferred * Transfer Cost))
/ ((SOH Quantity + In-transit Quantity) + Quantity Transferred)
In the case of pack items, pack component SOH quantity (PACK_COMP_SOH) and pack
component in-transit quantity (PACK_COMP_INTRAN) are considered. RMS does not
maintain WAC at the pack level for the pack item but only at the component level.
The WAC calculation formula and treatment may differ based on the SOH of the item at
the location prior to and post shipment of transfer. Different transfer (intercompany/intra-company) scenarios and their impact on WAC are detailed in the
following table:
Accounting Methods
No.
On
Hand
Before
On
Hand
After
Impact on WAC
WAC is set to WAC from sending location
A cost adjustment (Tran Code 70) is written based

on the WAC adjustment.
Intra-company Transfers
1.
Transfer In with negative

on hand and on hand
becomes positive
((WAC prior to Transfer In Cost on Transfer) * SOH

prior to transfer in)
2.

on hand and becomes
zero


3.

on hand and on hand
remains negative
WAC is set to the WAC from the sending location


4.
5.
Transfer In with positive

on hand
Transfer In with zero on

hand
WAC is set to Transfer price.

((SOH Quantity * Old WAC) + (Quantity Transferred *

Transfer Cost)) / (SOH Quantity + Quantity Transferred)
Inter-company Transfers
1.
Intercompany Transfer In
with negative on hand
and on hand becomes
positive
((WAC prior to Transfer In Transfer Price) * SOH prior

to transfer in)
2.
and becomes zero


to transfer in)
3.
and on hand remains
negative


to transfer in)
Accounting Methods
No.
On
Hand
Before
On
Hand
After
Impact on WAC
4.
with positive on hand
with zero on hand
5.
((SOH Quantity * Old WAC) + (Quantity Transferred *

Transfer Cost)) / (SOH Quantity + Quantity Transferred)
+
Note: SOH is calculated as (Stock on Hand + In-transit) +
(Pack component SOH + Pack component In-transit).

WAC after Receiver Adjustment
If the average cost accounting method is selected, every time a receiver unit or cost
adjustment occurs, the average cost is recalculated.
Various scenarios for receiver unit adjustment (RUA) and its impact on the WAC
calculation are in the following table:
No.
On
Hand
Before
On
Hand
After
Impact on WAC

Receiver Unit Adjustment

1.
Receipt Unit Adjustment with

negative on hand and
adjustment is positive on
hand remains negative.
((WAC prior to receipt - new PO Cost) * SOH prior

to receipt)
2.

adjustment is positive. On hand
becomes positive.

((WAC prior to receipt - new PO Cost) * SOH prior

to receipt)
3.

positive on hand and
adjustment is positive.
4.

adjustment is negative. On
hand becomes negative.
WAC is not recalculated and New WAC = Old

WAC.
5.

hand becomes zero.

WAC.
WAC is recalculated as:
((SOH Quantity * Old WAC) + (Adjusted Quantity *

PO Cost)) / (SOH Quantity + Adjusted Quantity)
Accounting Methods
No.
On
Hand
Before
On
Hand
After
Impact on WAC
6.

hand remains positive.
If WAC_RECALC_ADJ_IND = N, WAC is not

recalculated and New WAC = Old WAC
If WAC_RECALC_ADJ_IND = Y then WAC is

recalculated as:
((SOH Quantity * Old WAC) + (Adjusted
Quantity * PO Cost)) / (SOH Quantity +
Adjusted Quantity)
7.

adjustment is negative.

WAC.
(Pack component SOH + Pack component In-transit).

For receiver cost adjustments (RCA), the calculation is more complex. In the case of RCA,
there can be two types, selected through system option RCV_COST_ADJ_TYPE. The first
type can be Standard and the other FIFO. The standard adjustment recalculates WAC
using all units received. The FIFO adjustment calculates layers for the receipts for the PO
and creates an adjustment of WAC for only those units in stock whose receivers have not
been matched.
If the Standard option is selected, since an RCA can occur after the actual receipt, and
the number of units on hand and available to absorb the impact of the adjustment may be
different than when the actual physical receipt took place, an adjustment based on the
full number of units on the receipt that is being adjusted could result in a distorted WAC
value. For example, assume the following scenario:
Purchase Receipt, Transfer Out, and Receiver Cost Adjustment occurring at a Warehouse:
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.
Transfer out to Store: 100 units at WAC $14.17 = $1,417.00
New WAC = ($200.00 + $1,500.00)/(20 + 100) = $14.17

New SOH = 20 Units, WAC $14.17, total cost = $283.40
Receiver Cost Adjustment for PO Receipt above of -$3.00 Unit for a corrected PO
Cost of $12.00 Unit.:
RCA: 100 units at -$3.00 Unit Cost = -$300.00
New WAC = ($283.40 $300.00)/20 Units = -$0.83/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
The following is an example:

SOH prior to Receipt = 0 Units
Receipt#
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
WAC is set equal the New PO cost.

Receiver Cost Adjustment

1.
Receiver cost adjustment with

negative on hand.
((SOH * New WAC) (SOH * Old WAC)) + (Units

Received * (New PO Cost Old PO Cost))
2.

positive on hand.
WAC is recalculated based on the current onhands.
((SOH * Old WAC) + (Received Qty * Change in

Cost)) / SOH
3.

zero on hand.
WAC remains unchanged
(Pack component SOH + Pack component In-transit).WAC

after Transfer Reconciliation
RMS facilitates reconciling the transfers in case there is an over or short receipt of items.
The reconciliation process can attribute the loss/gain to either sending location or
receiving location or adjustments are done in such a way that no location incurs a loss.
Various methods of adjustment are BL (Bill of Lading adjustment), NL (No Loss
Adjustment), RL (Receiving location loss Adjustment), SL (Sending location loss
Adjustment). In all these methods, reconciliation is done either through the reversal of
the transfer or inventory adjustments or a combination of both at the sending and
receiving locations. In a few cases of transfer reconciliation, WAC is also recalculated.
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
Inter-Company Transfers Under Receipt

1.
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.
The average cost of sending location and receiving location will be

recalculated based on the original shipment cost.
Receiving Location WAC = ((SOH Quantity * Old WAC) - (Short

Received Quantity * Original Shipment Cost)) / (SOH Quantity - Short
Received Quantity)
Sending Location WAC = ((SOH Quantity * Old WAC) + (Short
Received Quantity * Original Shipment Cost)) / (SOH Quantity + Short
Received Quantity)
2.
3.
4.
NL (No Loss Adjustment)
RL (Receiving location loss

Adjustment)
SL (Sending location loss

Adjustment)
In this case Inventory Adjustment (Tran code 22) will be written

for both the locations with the difference between received qty and
shipped qty to adjust for the quantity not received. The In Transit
qty will be cleared out for receiving location and the sending
location inventory will be increased by the same quantity.
No impact on WAC.

for receiving location with the difference between received qty and
shipped qty to account for the loss. There will be no impact to
sending locations inventory.
No impact on WAC.
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.

Receiving Location WAC = ((SOH Quantity * Old WAC) - (Short

Received Quantity)
Sending Location WAC = ((SOH Quantity * Old WAC) + (Short
Received Quantity)
Accounting Methods
No.
Reconciliation Method
Impact on WAC
Inter-Company Transfers Over Receipt

1.
BL (Bill of Lading
adjustment)
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.

Sending Location WAC = ((SOH Quantity * Old WAC) - (Short

Received Quantity)
Receiving Location WAC = ((SOH Quantity * Old WAC) + (Short
Received Quantity)
2.
3.
4.
NL (No Loss Adjustment)
RL (Receiving location loss

Adjustment)
SL (Sending location loss

Adjustment)

for both the locations with the difference between received qty and
shipped qty to adjust for the additional quantity received.
No impact on WAC.

for receiving location with the difference between received qty and
shipped qty to account for the additional units. There will be no
impact to sending locations inventory.
No impact on WAC.
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.

Sending Location WAC = ((SOH Quantity * Old WAC) - (Short

Received Quantity)
Receiving Location WAC = ((SOH Quantity * Old WAC) + (Short
Received Quantity)
Accounting Methods
Manual WAC Adjustments

In addition, the WAC can also be updated on-line in RMS by creating an average cost
adjustment. This updates the WAC at the item/location specified and writes a
transaction-level stock ledger record to record the change in inventory value for the stock
on hand at that location. The transaction is recorded as Cost Variance.
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
Inventory Calculation Cost Accounting Method

Ending Inventory at Cost
Beginning of Month Inventory
+ Purchases (20)
- Return to Vendor at Cost (24)
- Net Sales at Cost (01 or 02)
+Transfer in at Cost (30,31,37)
- Transfer out (32,33,38)
+ Up Charges (28,29)
- Shrinkage at Cost (calculated value)
+ Reclassification in at Cost (34)
- Reclassification out at Cost (36)
- Cost Variance (70)
- Freight Claims (62)
+ Inventory Adjustment at Cost (23)
+ Work Order Activity Updates (63)
- Cost Variance (Cost Accounting) (72)
- Franchise Net Sales (82)
Ending Inventory at Retail
Beginning of Month Inventory
+Purchases at Retail (20)
- Return to Vendor at Retail (24)
+ Markups at Retail (11)
- Markup Cancels (12)
+ Transfer In at Retail (30,31,37)
- Transfer Out at Retail (32,33,38)
- Freight Claims at Retail (62)
+ Inventory Adjustment at Retail (23]=)
+ Inventory Adjustment (if not using budgeted shrink) (22)
- Stocktake Adjustment at Retail ( )
+ Reclassification In at Retail (34)
- Reclassification Out at Retail (36)
- Net Sales at Retail (01)
- Markdowns at Retail (13)
- Promotional Markdowns at Retail(15)
- Clearance Markdowns at Retail (16)
+Markdown Cancels at Retail (14)
- Employee Discounts at Retail (60)
+ Intercompany Markup (17)
- Intercompany Markdown (18)
- Franchise Net Sales at Retail (82)
Accounting Methods
+ Franchise Markup at Retail (84)

- Franchise Markdown at Retail (85)
Gross Margin
Net Sales Retail - Net Sales Cost
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.
Net Sales (Tran Code 01)

Net sales transactions are written in RMS by the sales upload process through the POSU
file. These transactions include both customer sales and returns.
This record captures the units sold (or returned), the retail value of the units, and the cost
of the units (average or standard cost based on system option setting). The retail value is
Transaction Data 29
Net Sales VAT Exclusive (Tran Code 02)
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.
Net Sales VAT Exclusive (Tran Code 02)

This transaction type is similar to Net Sales (Tran Code 01) and written along with tran
code 01 in the cases when tax type selected at the system level is SVAT or GTAX and
Stock Ledger Retail VAT Inclusive = Yes (STKLDGR_VAT_INCL_IND = 'Y'). This
record gives visibility to sales without the VAT value. If VAT is not included in the stock
ledger, records are not written with this transaction code.
These transactions are rolled up to the subclass/day, subclass/week, and
subclass/month levels; however, it is not used in the ending inventory calculations.
The summarization of sales and return transactions is similar as Net Sales (Tran Code
01).
The following is an example of what a TRAN_DATA record would look like for this
transaction code:
Non-inventory Items Sales/Returns (Tran Code 03)
Non-inventory Items Sales/Returns (Tran Code 03)

This type of transaction is also recorded in RMS by the sales upload process, and it
includes all the sales/ return transactions at POS for non-inventory items. These records
are the items for which items inventory indicator (INVENTORY_IND) is N.
For these transactions too, sales are positive records and returns are negative. Retail is the
items sales price, and cost is WAC or standard cost, depending on system option. The
summarization of sales and return transactions is similar as Net Sales (Tran Code 1).
Sales recorded under this tran code is not part of the Net Sales (Tran Code 1).
These records are not used for the ending inventory calculations but rolled up to
subclass/location level for day, week, and month in the stock ledger to interface it to the
general ledger.
transaction code:
Returns (Tran Code 04)

This transaction type is recorded for all customer returns processed through the sales
upload process in RMS. This is the only place in the system in which there is visibility to
customer returns, because customer returns are not written to the sales history tables in
the system. Units returned, total retail, and total cost are captured for each return
transaction. Return transactions are rolled up to the subclass/day, subclass/week and
subclass/month level. However, because customer returns are part of the Net Sales
transaction, Returns are not used in the ending inventory calculations.
Summarization of sales and return transactions is similar as Net Sales (Tran Code 01).
transaction code:
Non-inventory VAT Exclusive Sales (Tran Code 05)

This transaction type is written for the same criteria as the 'Non-inventory Items
Sales/Returns (Tran Code - 03)' transaction described above, if the system parameter is
set that indicates VAT should be included in records written to the stock ledger. When it
is written, it is in conjunction with the Non-inventory Items Sales/Returns record in
order to give visibility to sales without VAT. If VAT is not included in the stock ledger,
then records are not written with this transaction code. This transaction code is similar to
Tran Code 02.
Transaction Data 31
Deals Income (Sales) (Tran Code 06)
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.
transaction code:
Deals Income (Sales) (Tran Code 06)

This transaction code is recorded to post income generated from bill back rebate or
vendor funded promotion types of deals that are calculated based on sales. These are the
deals from which the retailer gets income as certain part of sales. The amount of income
may differ based on predefined threshold sales levels and percentage thereof.
For example, a supplier may give 10% discount on every $10,000 worth of sales and 15%
discount if the sales reaches $20,000.
This transaction is based on sales; thus, the posting is at retail only.
This transaction is created by the daily deal income and sales upload batch programs.
The latter posts deal income transactions only in case of Vendor Funded Promotions. For
these transactions the daily data roll up table is updated by the daily deal income batch
rather than sales daily batch. Additionally, deal ID is also recorded in the reference
number column.
subclass/month levels; however, it is not used in the ending inventory calculations.
transaction code:
Deals Income (Purchases) (Tran Code 07)

This transaction is recorded to post income generated from bill back or bill back rebate
deals that are calculated based on purchases. The income from these deals is dependent
upon the quantity of purchases made by the retailer from the vendor, and deal income
may differ based on predefined threshold levels of purchases.
For example, a supplier may give 10% discount if the purchase of a particular item is
more than $10,000, and if the total purchase in a year reaches $200,000 then extra 2% is
given to the retailer.
These transactions are posted at cost based on the purchase cost.
This transaction is created by the daily deal income batch program. For these
transactions, the daily data roll up table is updated by the daily deal income batch rather
than sales daily batch program. Additionally, deal ID is also recorded in the reference
number column.
subclass/month levels; however it is not used in the ending inventory calculations.
Fixed Income Accrual (Tran Code 08)
transaction code:
Fixed Income Accrual (Tran Code 08)

Income arising from fixed deals is recorded under this transaction code. Fixed deals are a
lump sum deal based on proof of performance.
For example: if retailers highlight a particular product in their weekly sales flyer (and
sends that flyer to the products manufacturer as proof), then the manufacturer gives the
retailer $100. This transaction is recorded at cost.
These transactions are not recorded in TRAN_DATA table. The deal fixed income batch
program writes these transactions to the financial staging table for the general ledger
posting process. It splits deal income over all dept/class/subclass locations on the deal.
This prorated income is written to the general ledger under a suitable cost center
mapping.
Weight Variance (Tran Code 10)

This transaction is used to capture the variance arising from the difference between
nominal weight and actual weight during the sale and inventory adjustment of a catch
weight type 3 or 4 item.
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.
transaction code:
Markup (Tran Code 11)

When the retail price of an item in a transaction is over its current price, this is recorded
as a markup. Markup is recorded in the following cases:
Transaction Data 33
Markup (Tran Code 11)
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
New Retail $18

Markup $3
Initial Retail $15

Initial Markon $5
Initial Cost $10
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
Pack Component Sales

In the case of pack sales, when the retail value of the sale is prorated to the component
items, a markup may be written if the prorated retail is higher than the current retail
price of the item in RMS.
This transaction code is inserted daily by the sales upload batch program to record the
difference.
This record is a location specific record and the unit quantity considered for posting is
quantity sold (pack quantity sold * no. of components in pack) in that transaction. The
time of posting this transaction is when sale is recorded.
Example for Sales:
Item A is a component of Pack X at location Z. Pack X contains 15 units of item A and has
a retail of $300. The unit retail of item A is $15. Store Z sells 2 units of Pack X on January
2nd. The total retail value posted as markup on January 2nd is $150. This is calculated as
follows:
Markup Cancel (Tran Code 12)
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.
transaction code:
Markup Cancel (Tran Code 12)

A markup cancellation is the decreasing of the retail price of an item until the point of its
original retail. In other words, this is cancelling a previous markup in part or full.
Because this transaction can be misused to disguise the markdown, RMS does not
systematically capture this transaction code in the transaction data tables. Instead, it
captures all decreases in price as a markdown. If a retailer wants to automatically record
this in certain cases, it is a customization of the system in order to do so. In order to better
enable retailers that do want to use Markup Cancellations, this tran data code does get
included in the batches that create transaction level data rollups to the subclass/day,
subclass/week, subclass/month levels. Additionally, the markup cancellation buckets on
the stock ledger are included in the ending inventory calculations for each period. Only a
retail value is associated with a markup cancel and therefore markup cancels are only
included in the ending inventory calculations for retail.
Example for Markup Cancel:
Transaction Data 35
Permanent Markdown (Tran Code 13)
New Retail 1 $18

Markup Cancel $2
New Retail 2 $16

Initial Retail $15
Markup $3
Initial Markon $5
Initial Cost $10
Permanent Markdown (Tran Code 13)

When the retail price of an item in a transaction is below its current price, this is recorded
as a Promotional Markdown. When the regular retail of an item changes, and is lowered,
this will also be recorded as a Permanent Markdown. A permanent markdown is
recorded in the following cases:
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
Markdown Cancel (Tran Code 14)
Pack Component Sales

In the case of pack sales, when the retail value of the sale is prorated to the component
items, a permanent markdown may be written if the prorated retail is lower than the
current retail price of the item in RMS.
This transaction code is inserted daily by the Sales upload batch program to record the
difference. This record is location specific, and the unit quantity considered for posting is
quantity sold (pack quantity sold * no. of components in pack) in that transaction. The
time of posting this transaction is when sale is recorded.
Example for Sales:
Item A is a component of Pack X at location Z. Pack X contains 15 units of item A and has
unit retail of $150. Unit retail of item A is $15. Store Z sells 2 Unit of Pack X on January
2nd. The total retail value posted as markdown on January 2nd will be $30. This is
calculated as:
Markdown Retail = Component Units sold * (Per unit retail of component item (Pack
unit retail/No. of components))
Permanent Markdown Retail = 30 * (15 (150/15)) = $150
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.
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.
transaction code:
Markdown Cancel (Tran Code 14)

This transaction is recorded when an item had a price change decreasing it from the
original price and now it is increased over its current retail but below its original retail. It
is basically cancelling the part of a markdown already applied on the price.
A markdown cancel will typically result from a permanent price change.
Transaction Data 37
Promotional Markdown (Tran Code 15)
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
New Retail $15

Initial Cost $10
Initial Markon $10
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
portion above the original retail would be a markup and

portion until the original retail would be markdown cancel.
transaction code:
Promotional Markdown (Tran Code 15)

Promotional Markdown is the result of a temporary reduction in the price of an item for
a limited time period, but is only recorded for actual units sold. This temporary
reduction is recorded through this transaction code in the following cases:
Clearance Markdown (Tran Code 16)
Promotional Price Change

Promotional Markdown is recorded at the time of sales of an item for which a temporary
reduction in the price is created in RPM. This is a planned markdown, and usually it is
for a limited time period for promoting sales.
Promotional markdowns are not taken at the time a promotion goes into effect, but rather
at the time of a sale. This transaction is inserted by the sales upload batch program.
For Example:
A new promotional price of $15 for Item A gets effective from January 2nd (original price
$17). 5 units sold on January 22nd. The total retail value posted as promotional markdown
on January 2nd will be $10. This is calculated as:
Promotional Markdown Retail = (SOH*Old Retail) (SOH*New Retail)
Promotional Markdown Retail = (5*17) (5*15) = $10
Price Changes at the Time of Sales

Promotional markdowns are also recorded when a price of an item is overridden at the
time of actual sales and sold at a higher or lower price but not part of an RMS/RPM
initiated promotional event.
In the case of a price reduction, there is a positive value for this transaction, and in the
case of price increase, there is a negative value recorded equal to the difference between
regular price and new price.
This transaction is inserted by the sales upload batch program.
The unit quantity that makes up the promotional markdown transaction record is the
units sold for the item at the location. The total retail value is calculated as the difference
between the new retail and the old retail, multiplied by the total unit quantity.
The Promotional Markdown 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 promotional markdown,
and therefore promotional markdowns are only included in the ending inventory
calculations for retail.
transaction code:
Clearance Markdown (Tran Code 16)

Clearance Markdown is a permanent decrease in the retail price of an item resulting from
a clearance event created in RPM.
These are recorded at the point in time that the new clearance price for the item goes into
effect in RMS (that is, the effective dates of the clearance markdowns). The unit quantity
that makes up the transaction record is the stock on hand for the item at the location on
the effective date, 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.
For Example:
Transaction Data 39
Intercompany Markup (Tran Code 17)
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:
Intercompany Markup (Tran Code 17)

When goods are transferred between two locations which are under different business
entities then these transfers are known as Intercompany Transfers. (Refer to the Multiple
Set of Books in the system options section for options related to intercompany transfers.)
Intercompany Transfers are treated as a purchase/sale between business entities rather
than just a movement of merchandise. In the case of intercompany transfers, if the
Transfer Price specified on the transfer is more than the retail price of the item at the
sending location, the difference between transfer price and the retail is recorded as
Intercompany Markup.
Because intercompany transfers are treated as sales in the sending location, in the case of
markup, it is recorded for the sending location.
These transaction data records are rolled up to the subclass/day, subclass/week, and
period.
transaction code:
Intercompany Markdown (Tran Code 18)

This transaction is recorded when the price of an Intercompany Transfer is less than the
retail value of the merchandise at the sending location. The difference between the
transfer price and the retail is recorded as Intercompany Markdown.
Purchases (Tran Code 20)
As intercompany transfers are treated as sales in the sending location, in case of a

markdown, it is recorded for the sending location.
This transaction data is rolled up to the subclass/day, subclass/week, and
period.
transaction code:

This transaction is written for purchases of merchandise made by the retailer from a
vendor when RMS processes the receipt of a purchase order. Also, in the case of a
(receiver cost adjustment) RCA or receiver unit adjustment (RUA), this record is written.
This transaction writes the units received, total cost and total retail for all the items on the
receipt. The cost recorded is the cost on the purchase order; that is, the purchase cost for
the particular receipt, plus ELC, minus off invoice deals, if applicable. The retail recorded
is the regular retail or clearance retail (whichever is effective at the time of receiving) of
the item at the receiving location. Purchase order number and shipment number for the
receipt is also recorded for reference in this transaction record. In the case of RCA and
RUA, C and U respectively is recorded under the adjustment code column of this
transaction record.
transaction code:
Record for PO Receipt:
Record for Receiver Unit Adjustment (RUA):
Record for Receiver Cost Adjustment (RCA):
Transaction Data 41
These records 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.
Stock Adjustment (Tran Code 22)
Stock Adjustment (Tran Code 22)

This transaction code is written in three cases: first, when there is an adjustment to the
total stock on hand; secondly, when a unit stock count results in adjustment to total stock
on hand; and thirdly, when spoilage type wastage configured for an item is processed.
In the case of an adjustment to the total stock on hand, the reason code associated with
the adjustment determines the tran code to which the adjustment is written, either 22 or
23. Those that are classified as Cost of Goods Sold adjustments write to tran code 23;
others write to tran code 22. The reason code is captured on the transaction data record
for the reporting purposes in the GL reference number field.
For stock counts, stock adjustment records are written under this tran code only in the
case of a Unit Only count. Unit and Value Counts are recorded under tran code, 41, to
interface to Oracle Retail Analytics. In this case, the stock count number is recorded in the
first reference field.
For both cases, the units adjusted are recorded to the table, along with the cost and retail
extensions.
Total cost = Number of units * Average or Standard Cost (depending on the system
parameter setting)
Total retail = Number of units * Unit Retail.
This transaction code is also inserted when the waste adjustment is processed for items
with a waste type of SP (spoilage). This waste type is used to account for natural
wastage that occurs over the shelf life of the product. The waste adjustment batch
program (wasteadj.pc) writes this transaction. The cost can be weighted average cost
(WAC) or standard cost depending on the options settings, and retail is the regular retail.
Stock adjustments transactions are rolled up to the subclass/day, subclass/week and
subclass/month levels. If a Unit and Value inventory is not performed within the stock
ledger period (month), and budgeted shrink is not used, then the total cost and retail
value of all stock adjustments for the period are summed up and used as the shrinkage
amount in the ending inventory calculations. For details of various scenarios, see the
Budgeted Shrink Indicator section under system options.
transaction code:
Stock Adjustment COGS (Tran Code 23)

This transaction code is used similarly to how the tran code 22 is used for inventory
adjustments. RMS determines which tran code to record based on the reason code for the
inventory adjustment. Those with the COGS indicator = Y will write to this tran code.
Inventory adjustments that are flagged with the COGS indicator = Y, unlike tran code 22,
will always be included in the ending inventory calculation, regardless of the budgeted
shrink indicator.
transaction code:
Transaction Data 43
Return to Vendor (Tran Code 24)
Return to Vendor (Tran Code 24)

Transactions with this code are written when the inventory is returned to vendor from
owned inventory. This record is inserted as soon as the RTV shipment is processed by
RMS.
The RTV transaction is written based on the number of units returned to the vendor and
the cost and retail of the unit on the RTV. When an RTV is created, a cost can be specified
for the item differing from the average or unit cost of the item, representing the amount
of money that the vendor is willing to pay the retailer for the goods. This is the cost that
is used to create the RTV transaction in the stock ledger. If no cost is specified, then the
average cost of the item/location is used as the RTV cost or the last receipt cost based on
the system option (RTV_UNIT_COST_IND) selected. Valid values for this option are R
(last receipt cost), S (standard cost) or A (average cost). In this case, the retailer is using
standard cost as the cost method, this can be only be S or R. Similarly, when using
average cost as cost method, this can be only be A or R.
Additionally, the RTV order number is written to the transactional data record in first
reference column for reporting and reference purposes.
The Return to Vendor 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.
When the RTV cost is different from the inventory cost of the item, then the cost variance
transaction code 71 or 72 is recorded depending on the department uses cost or retail
method of accounting respectively.
transaction code:
Unavailable Inventory Transfer (Tran Code 25)

The Unavailable Inventory Transfer type of record is written when inventory is moved
from regular stock or available status to an unavailable status in RMS or vice versa.
This is inserted immediately upon completion of an inventory adjustment with an
inventory status other than Total Stock On hand.
This is also created when there is an RTV from unavailable inventory or a transfer of
unavailable inventory. In the case of a transfer, this is posted for from location at the
time of shipment and at the time of receipt at the receiving location, if received in
unavailable inventory status.
This transaction is recorded with the associated units, but no cost or retail, because
moving stock to unavailable status does not have a financial impact on the inventory.
This type of transaction is for reporting purposes only and is not used in the ending
inventory calculations.
Freight Cost (Tran Code 26)
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.
transaction code:
Freight Cost (Tran Code 26)

The freight transaction is a cost transaction that is used in the retail method only.
However, data is not currently captured in this transaction type as part of the base RMS
functionality. Freight is included in the ending inventory calculations for retail, so
modifications can be made to the system in order to begin capturing data in this
transaction type, depending on the data that is needed and how it needs to be collected.
Nevertheless, most retailers do not make use of this transaction type because of two
reasons. First, it is often too complicated to try to prorate out freight costs to the
item/location level in order to write it to the stock ledger with any type of accuracy.
Secondly, if freight is being captured in RMS, then it is usually through the landed cost
functionality. If landed cost is being used, freight is being captured as part of the
purchase cost in the Purchases transaction, and is being used to recalculate average cost
for future transactions.
Any freight transactions captured in the system are rolled up to the subclass/day,
subclass/week, and subclass/month levels and used in the ending inventory calculations
for a particular period for the retail method. Retailers using the cost method can still
write to this transaction code, but it will not be included in the ending inventory
calculations without a modification.
Return to Vendor from QC (Tran Code 27)

This transaction was originally written to record return of those goods to the vendor that
fail the quality test at the time of receipt. It is no longer used.
Profit Up Charge (Tran Code 28)

Up charges are miscellaneous charges, for example: transportation costs, which can be
added to the cost of the transfer or allocation. These charges are applied to the receiving
locations transfer cost based on dept/from/to location configuration and transfer type
configuration. These can be specified as either Profit or Expense to facilitate general
ledger posting in different accounts as per retailers preference. While there is no specific
functionality that differs between Profit and Expense type Up Charges, various tran
codes are used to allow for different general ledger treatment. Examples of Profit type Up
Charges could include Warehouse Handling Fees or Storage Fees that a companys
warehouses may charge to help them operate as a profit center. Expense type up charges
would be things such as Freight or Insurance, which are actual internal costs, but are
applied as an estimate with Up Charges.
Transaction Data 45
Expense Up Charge (Tran Code 29)
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.
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.
transaction code:
Expense Up Charge (Tran Code 29)

Up charges are miscellaneous charges, for example: transportation costs, which can be
added to the cost of the transfer. These charges are applied to the receiving locations
transfer cost based on dept/from/to location configuration and transfer type
configuration.
In this transaction code, Location Up Charge components that have been added to
Transfers or Allocations with an Up Charge Type of Expense 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.
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.
transaction code:
Transfer In (Tran Code 30)

This transaction type is used to capture movement of inventory into a location based on
the transfer or allocation of merchandise from another location.
These records are inserted when the transfer is processed by RMS and moves to
Shipped status in conjunction with the Transfer Out record. This is because at the point
the inventory leaves the sending location it is financially owned by the receiving location.
Book Transfer In (Tran Code 31)
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.
transaction code:
Book Transfer In (Tran Code 31)

This transaction type is used to record a transfer with transfer type of Book Transfer for
the receiving location. This transfer is created between virtual locations. This record is
inserted when the transfer status is changed to approved.
This transaction is written along with Book Transfer Out (Transaction Code 33) and
uses the same cost and retail as transaction code 33. See transaction code 33 for details of
the cost and retail calculation.
The Book Transfer In transactions captured in RMS are rolled up to the subclass/day,
for a particular period. Additionally, the RMS transfer number is captured as part of the
transaction record for reporting and reference purposes.
transaction code:
Transfer Out (Tran Code 32)

This transaction type is used to capture movement out of inventory from a location based
on a transfer or allocation of merchandise to another location.
These records are inserted when the transfer is processed by RMS and moves to
Shipped status in conjunction with the Transfer in record. This is because at the point
the inventory leaves the sending location it is financially owned by the receiving location.
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.
Transaction Data 47
Book Transfer Out (Tran Code 33)
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,
for a particular period.
transaction code:
Book Transfer Out (Tran Code 33)

This transaction type is used to record a transfer with transfer type of Book Transfer for
the sending location. This transfer is created between virtual locations. This record is
inserted when the transfer status is changed to approved.
This transaction is written along with Book Transfer In (Transaction Code 31) and uses
the same cost and retail of sending location. The cost and the retail will be calculated as
follows:
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 * Unit Retail at sending location
The Book Transfer Out transactions captured in RMS are rolled up to the subclass/day,
for a particular period. Additionally, the RMS transfer number is captured as part of the
transaction record for reporting and reference purposes.
transaction code:
Reclassifications In (Tran Code 34)
Reclassifications In (Tran Code 34)

Reclassification In transactions are written when an item is moved, or reclassified, from
one department/class/subclass to another, to record the movement of inventory in to
the new subclass. Transaction data records are written for each location in which the item
being reclassified exists in the system based on owned inventory at the location. This
transaction is written when a reclassification event is processed by the batch process
Reclassification of Item (reclsdly). For every Reclassification In transaction for the
location, a Reclassification Out transaction also exists and the two transaction data
records balance one another.
The units recorded in this transaction are calculated based on total stock on hand and intransit for each item/location. The total cost and retail are calculated based on the
extended weighted average cost (or standard cost) and unit retail for the item/location.
The effect is to move the current inventory value of the item from one
department/class/subclass to another. The cost and the retail are calculated as follows:
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 %)
Total Retail: Number of units on hand * Unit Retail at the location
The Reclassification In transactions captured in RMS are rolled up to the subclass/day,

subclass/week and subclass/month levels and are used in the ending inventory
calculations for a particular period.
transaction code:
Reclassifications Out (Tran Code 36)

Reclassification Out transactions are written when an item is moved, or reclassified,
from one department/class/subclass to another, to record the movement of inventory
out from the old subclass. The transaction data records are written for each location in
which the item being reclassified exists in the system based on owned inventory at the
location. This transaction is written when a reclassification event is processed by the
batch process Reclassification of Item (reclsdly). For every Reclassification Out
transaction for the location, a Reclassification In transaction also exists and the two
transaction data records balance each other.
The units recorded in this transaction are calculated based on total stock on hand and intransit for each item/location. The cost and retail are the same as the Reclassification In
transaction (Transaction Code 34).
The Reclassification Out transactions captured in RMS are rolled up to the
subclass/day, subclass/week and subclass/month levels and are used in the ending
inventory calculations for a particular period.
transaction code:
Transaction Data 49
Intercompany Transfer In (Tran Code 37)
Intercompany Transfer In (Tran Code 37)

This transaction code is recorded for the receiving location at the time of shipping of a
Transfer or Allocation out of a location where the receiving location is in a different legal
entity. Because the movement of inventory is between different legal entities, it needs to
be treated as a Purchase transaction rather than an inventory movement, thus the need
for a different transaction code.
This transaction is posted in conjunction with the transaction Intercompany Transfer
Out (Transaction Code 38). Under this transaction type, number of units, total cost and
total retail of the transaction are captured. Total cost and retail are calculated as follows:
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
transaction code:
Intercompany Transfer Out (Tran Code 38)

This transaction code is recorded for the sending location at the time of shipping of a
Transfer or Allocation out of a location where the receiving location is in a different legal
entity. As the movement of inventory is between different legal entities, it needs to be
treated as a Sale transaction rather than an inventory movement, thus the need for a
different transaction code.
Retail Analytics Stock Ledger Adjustment (Tran Code 41)
This transaction is posted in conjunction with the transaction Intercompany Transfer In

(Transaction Code 37). Under this transaction type, number of units, total cost and total
retail of the transaction are captured. Total cost and retail are calculated as follows:
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
regular retail for the sending location triggers the posting of

either a markup or markdown transaction through
transaction code 17 (intercompany markup) or transaction
code18 (intercompany markdown).
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
transaction code:
Retail Analytics Stock Ledger Adjustment (Tran Code 41)

This transaction is for Retail Analytics (RA) and records inventory adjustment for unit
and value counts. This transaction code is required for inventory variance reporting in
RA because RMS does not use a transaction code for these transaction but captures
variance at month level for unit and value counts.
transaction code:
Transaction Data 51
Retail Analytics Inbound Transfer Receipt (Tran Code 44)
Retail Analytics Inbound Transfer Receipt (Tran Code 44)

This transaction is for Retail Analytics (RA). It was created to notify RA that the intransit transfer quantity for the item/location has been received and moved to the total
stock on hand. Because there is no other transaction code is recorded at the time of
receipt of a transfer at a location, this record also serves as an audit record for receipt.
transaction code:
Employee Discount (Tran Code 60)

This transaction code is used for recording employee discounts extended to the
employees of a retailer when he or she makes a purchase of the items that have an
employee discount identified on them. These are inserted through the sales upload
process when a promotional type of Employee Discount is passed in from the point of
sale (POS).
This transaction captures the amount of discount given at the POS based on a sale to an
employee and is therefore a retail only transaction. The transactional stock ledger record
contains the number of units to which the discount applies and the total retail value of
the discount (units * discount amount).
The Employee Discount transactions captured in RMS are rolled up to the
subclass/day, subclass/week and subclass/month levels. These values are then used to
calculate the period ending inventory and margin values for retail.
Freight Claim (Tran Code 62)

This transaction code is used to record the loss when there is difference between expected
quantity and actual received quantity due to freight claims in a transfer. Freight claims
can only be selected as a reconciliation method online in RMS using the Stock Order
Exception Reconciliation functionality in RMS. This is always recorded for receiving
locations and the units and value are the difference between shipped and received.
The Freight Claim transactions captured in RMS are rolled up to the subclass/day,
for a particular period. This is a reduction to ending inventory.
transaction code:
Work Order Activity Cost Update Inventory (Tran Code 63)
Work Order Activity Cost Update Inventory (Tran Code 63)

This transaction code is used to record the cost of work-order activity for an item that
occurs at a finisher location. During transfer, an item can be routed through an internal
or external finisher location for repair or value additions. The costs associated with
activities carried out on merchandise at the finisher location are referred to as work order
activity cost and are defined using the work order cost dialogue in RMS.
Under this transaction code, the work order activity cost that adds value to the inventory
and which are meant to update inventory and thereby recalculate WAC (weighted
average cost) is recorded.
The Work-order Activity Cost Update Inventory transactions captured in RMS are
rolled up to the subclass/day, subclass/week and subclass/month levels. These values
are then used to calculate the period ending inventory values for cost method of
accounting.
transaction code:
Work Order Activity Cost Post to Financials (Tran Code 64)

This transaction code is used to record the cost of work-order activity for an item that
occurs at a finisher location. During a transfer, an item can be routed through an internal
or external finisher location for repair or value additions. The costs associated with
activities carried out on merchandise at the finisher location are referred as a work order
activity cost and are defined using the work order cost dialogue in RMS.
Under this transaction code, work order activity costs that should not be included in the
value of the inventory and which do not recalculate WAC but are directly posted to
financial as expenses are recorded.
The Work-order Activity Cost Post to Financials transactions captured in RMS are
rolled up to the subclass/day, subclass/week and subclass/month levels and posted to
the G/L, but are not used to calculate the period ending inventory values.
transaction code:
Transaction Data 53
Restocking Fee (Tran Code 65)
Restocking Fee (Tran Code 65)

This transaction code is used to record the location restocking fee associated with the
return to vendor transactions. A restocking fee can be defined either as percentage of
return unit cost or particular monetary amount.
The Restocking Fee 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. These values
are treated as inventory additions at cost.
transaction code:
Cost Variance (Tran Code 70)

In the case of standard cost method, this transaction is written each time the cost of the
transaction differs from the standard or base cost that is expected and records the
difference between the standard cost and the transaction cost. This is also written in case
of supplier cost change.
In case an average cost method is being used, this record is written in the case of an
average cost adjustment done in the system. Also, this transaction is written in case of
WAC calculation when the stock on hand is negative. In this case, WAC is not
recalculated but set to PO unit cost in case of PO receipt or Transfer Price in case of
transfer. Refer to the average cost section for more information.
In the case of receiver cost adjustments (RCA), if the Receiver Cost Adjustment Type is
set to 'Standard' in the system options through the indicator RCV_COST_ADJ_TYPE and
stock on hand is less than the receipt, there will be a tran data record for this tran code for
the units no longer available at the receiving location.
For both cases, the values recorded in the transactional record are the number of units
on-hand and in-transit for an item/location and the total cost of the transaction (units *
cost difference). Additionally, depending on the type of transaction the Transfer Order
Number and Shipment or RTV Number are recorded in the reference columns of this
transaction record.
The Cost Variance transactions that are captured in RMS are rolled up to the
calculate the period ending inventory values for cost method of accounting.
transaction code:
Cost Variance Retail Accounting (Tran Code 71)
Cost Variance Retail Accounting (Tran Code 71)

In some scenarios because of a mutual agreement between the retailer and supplier or
between two locations, the cost on the RTV or intra-company transfer respectively can be
different from the sending locations cost.
This transaction code is used for recording this difference between the transaction cost
and sending locations cost for a Return-to-Vendor (RTV) or Intra-Company Transfer to
ensure its proper accounting in case of the department using retail method of accounting.
This transaction is not used in the period ending inventory calculations in stock ledger.
In this case the cost variance would be calculated as the cost difference * (1 CMO %)*
units; where CMO is the Cumulative Mark-On. The cost recorded can be a positive or
negative value.
transaction code:
Cost Variance Cost Accounting (Tran Code 72)

In some scenarios because of a mutual agreement between the retailer and supplier or
between two locations, the cost on the RTV or intra-company transfer respectively can be
different from the sending locations cost.
This transaction code is used for recording this difference between the transaction cost
and sending locations cost for a return-to-vendor (RTV) or intra-company transfer to
ensure its proper accounting in case of the department using cost method of accounting.
The values recorded in the transactional record are the number of units in the
RTV/Transfer transaction and the total cost of the transaction (units * cost difference).
The cost recorded can be a positive or negative value.
The Cost Variance Cost Accounting transactions that are captured in RMS are rolled
up to the subclass/day, subclass/week and subclass/month levels. These values are then
used to calculate the period ending inventory values for cost method of accounting.
transaction code:
Transaction Data 55
Cost Variance Receiver Cost Adjustment FIFO (Tran Code 73)
Cost Variance Receiver Cost Adjustment FIFO (Tran Code 73)

This transaction code is used for Receiver Cost Adjustments (RCA) when the available
inventory units, based on a FIFO method, is less than the number of units included in the
cost adjustment. This is applicable in cases where Receiver Cost Adjustment Type is set
to 'FIFO' in the system options through the indicator RCV_COST_ADJ_TYPE and for
cases where RCA inventory is not available at the time of the adjustment and WAC is not
recalculated.
Retailers can use the information on transaction data for this transaction code to
determine how to manually adjust the WAC at stores where stock was distributed. This
transaction code is not rolled up to the month data for the GL interface.
Workroom / Other Cost of Sales (Tran Code 80)

This transaction is not a part of the base RMS functionality but is provided along with
logic in stock ledger calculations when the department uses the retail method of
accounting.
This transaction is intended for use in capturing all miscellaneous transactions that affect
the cost of sales and therefore the gross margin. Although data for this transaction is not
captured anywhere within the base RMS functionality, this transaction type is taken into
account when calculating gross margin for the stock ledger at the subclass/week and
subclass/month levels. Therefore, a modification could be made to the system to feed
this data in and have it accounted for in the stock ledger.
Cash Discount (Tran Code 81)

This transaction is not a part of the base RMS functionality, but is provided along with
logic in stock ledger calculations when the department uses the retail method of
accounting.
This transaction is intended for use in capturing all cash discount transactions that affect
the cost of sales and therefore the gross margin. Although data for this transaction is not
captured anywhere within the base RMS functionality, this transaction type is taken into
account when calculating gross margin for the stock ledger at the subclass/week and
subclass/month levels. Therefore, a modification could be made to the system to feed
this data in and have it accounted for in the stock ledger.
Franchise Sales (Tran Code 82)

This transaction code is used to record sales made to a franchise entity. When a product
is shipped from the retailers warehouse to a franchise store there is a sales transaction
registered to the warehouse and this transaction is recorded.
This record captures the units sold, the retail value of the units (cost to the franchise), and
the cost of the units (average or standard cost based on system option setting).
Additionally, the second reference column is used for capturing the transfer number.
These transactions captured in RMS are rolled up to the subclass/day, subclass/week
and subclass/month levels. These values are then used to calculate the period ending
inventory values for both cost and retail method of accounting.
transaction code:
Franchise Returns (Tran Code 83)
Franchise Returns (Tran Code 83)

This transaction code is used to record returns made from a franchise entity. When a
product is returned to the retailers warehouse from a franchise store there is a return
transaction registered to the warehouse and this transaction is recorded.
This record captures the units sold, the retail value of the units (cost to the franchise), and
the cost of the units (average or standard cost based on system option setting).
Additionally, the second reference column is used for capturing the transfer number.
These transactions captured in RMS are rolled up to the subclass/day, subclass/week
and subclass/month levels. These values are then used to calculate the period ending
inventory values for both cost and retail method of accounting.
transaction code:
Franchise Markups (Tran Code 84)

When the sale price on a franchise order is greater than the warehouse retail price, it is
considered a markup and the difference is recorded as a Franchise Markup under this
transaction code.
This record captures the units sold and difference between the current regular or
clearance retail and the retail value on the transaction multiplied by number of units as
transaction value. Additionally, second reference column is used for capturing the
transfer number.
The Wholesale/Franchise Markup transactions that are captured in RMS are rolled up to
the subclass/day, subclass/week and subclass/month levels. These values are then used
to calculate the period ending inventory values for both cost and retail method of
accounting.
transaction code:
Transaction Data 57
Franchise Markdowns (Tran Code 85)
Franchise Markdowns (Tran Code 85)

When the sale price on a franchise order is less than the warehouse retail price, it is
considered a markdown and the difference is recorded as Franchise Markdown under
this transaction code.
This record captures the units sold and difference between the current regular or
clearance retail and the retail value on the transaction multiplied by number of units as
transaction value. Additionally, second reference column is used for capturing the
transfer number.
The Franchise Markdown transactions that are captured in RMS are rolled up to the
calculate the period ending inventory values for both cost and retail method of
accounting.
transaction code:
Franchise Restocking Fee (Tran Code 86)

This transaction code is used to record any restocking payments made by franchise
customers to the retailer against the items being returned. This is an optional fee
sometimes charged by the retailer to compensate against the expenses incurred for
restocking the returned merchandise. This would typically be income for the warehouse.
This record captures the units returned and restocking fee at cost. Additionally, the
second reference column is used for capturing the transfer number.
The Franchise Restocking Fee 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 and used in the end of period inventory calculations.
transaction code:
VAT In Cost (Tran Code 87)

If VAT is being used in the system, every purchase transaction will entail Input VAT and
every sales transaction will entail Output VAT. For their proper accounting, all the VAT
values need to be properly calculated and captured.
This transaction code is used for recording Input VAT amount for purchases (tran code
20), RUA and RCA transactions (tran code 20U and 20C), consignment sales (tran code
20) and return to vendor (tran code 24) transactions.
VAT Out Retail (Tran Code 88)
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.
transaction code:
VAT Out Retail (Tran Code 88)

If VAT is being used in the system, every purchase transaction entails Input VAT and
every sales transaction entails Output VAT. For their proper accounting, all the VAT
values need to be properly calculated and captured.
This transaction code is used for recording Output VAT amount for regular sales
transactions (tran code 1 and 3), sales return (tran code 4), franchise sales (tran code
82) and franchise returns (tran code 83).
This record captures the units in the transaction and VAT amount at retail. For sales
transactions, the VAT amount will be a positive value and for return transactions, the
VAT amount will be a negative value. The VAT rate is retrieved from VAT_ITEM table.
Additionally, for franchise transactions, the associated transfer number is captured in the
first reference column. 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 Out Retail 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.
transaction code:
General Ledger Mapping Transaction Codes

The transaction codes below represent stock ledger period rolled up summaries and can
be used to map to the General Ledger if the monthly interface is used. These are not
recorded in the transaction data tables but calculated for monthly posting into the
General Ledger.
Transaction Data 59
Intercompany Margin (Tran Code 39)
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
with code type of GLMT and with the applicable cost/retail

indicator are picked up by the GL interface batch program
for interfacing to the GL.
Intercompany Margin (Tran Code 39)

RMS calculates intercompany margin differently based on whether the department uses
the cost or retail method of accounting.
Inter-company Margin (Cost method): Inter-company Out at Retail Inter-company

Out at Cost
Inter-company Margin (Retail method): Inter-company Out at Retail * (1-CUM%)
Open Stock (Tran Code 50)

This is the beginning of period stock on hand in value terms for a location. This is equal
to the closing stock on hand for the previous period. This is recorded in the month data
and week data tables. Separate values are recorded at cost as well as retail.
Budgeted Shrink (Tran Code 51)

This is the calculated shrinkage value for the period if the Budgeted Shrink Indicator
(BUD_SHRINK_IND) field is set to Y in the system options.
Budgeted shrinkage is calculated using budgeted shrinkage percent (stored on
HALF_DATA_BUDGET table as SHRINKAGE_PCT field) at the department/location
level for a financial half multiplied by sales at retail or at cost, depending on whether
retail or cost accounting method is used, respectively.
Close Stock (Tran Code 52)

This is the end of period stock on hand in value terms for a location. This is a calculated
value and recorded in the month data and week data tables at cost as well as retail. There
are different methods for calculating it under cost and retail methods and can be found in
detail in the Accounting Method section of this document.
Gross Margin (Tran Code 53)

This is a calculated gross margin value earned by the business during the period. This is
recorded in the month data and week data tables at retail. There are different methods
for calculating it under cost and retail methods and can be found in detail in the
Accounting Method section of this document.
HTD GAFS (Tran Code 54)
HTD GAFS (Tran Code 54)

This is Half-to-date Goods Available For Sale. HTD GAFS value is used in the retail
method of accounting for calculating cumulative markon percent which in turn is used in
inventory calculation at cost. This is recorded in the month data and week data tables at
cost as well as retail. The calculation method for this can be found in detail in the
Accounting Method section of this document.
Inter Stocktake Sales Amount (Tran Code 55)

This is the cumulative net sales amount since the previous time a Unit & Value stock
count was taken for a subclass/location. It is valued at cost for a cost department and at
retail for a retail department. It is reset to 0 when the Unit & Value count is processed for
a subclass/location, after the actual shrinkage has been calculated. This is recorded in the
month data and half data tables.
Inter Stocktake Shrink Amount (Tran Code 56)

This is the cumulative estimated (or budgeted) shrinkage amount since the last time a
Unit & Value stock count was taken for a subclass/location. It is valued at cost for the
cost department and at retail for the retail department. It is reset to 0 when the count is
processed for this subclass/location, after the actual shrinkage has been calculated. This
is recorded in the month data and half data tables.
Stocktake MTD Sales Amount (Tran Code 57)

This is Month-to-date net sales amount for a subclass/location. It is valued at cost for the
cost department and at retail for the retail department. It is calculated only when
inventory Unit & Value stock count is taken, as of the date the count is processed. This is
recorded in the month data table.
Stocktake MTD Shrink Amount (Tran Code 58)

This is the month-to-date (MTD) estimated (or budgeted) shrinkage amount for a
subclass/location. It is valued at cost for the cost department and at retail for the retail
department. It is calculated only when inventory Unit & Value stock count is taken, as of
the date the count is processed. This is recorded in the month data table.
Stocktake Book Stock Cost (Tran Code 59)

This is the book stock value at cost for a subclass/location. It is calculated only when
inventory Unit & Value stock count is taken, as of the date the count is processed. This is
recorded in the month data table.
Stocktake Actual Stock Cost/Retail (Tran Code 61)

This is actual stock amount at retail for a subclass/location when the Unit & Value stock
count is taken, as of the date the count is processed. This is recorded in the month data
table at both cost and retail.
Transaction Data 61
Transaction Data Stock Ledger Impact

Tran Codes
Cost/SL
Retail/SL
01 Sales/Return
02 Sales excluding Vat
03 Non-Inventory Items Sales/Returns
04 Customer Returns
05 Non-inventory VAT Exclusive Sales
Not used for

ending inventory
Calculations
06 Deals Income (Sales)
07 Deals Income (Purchases)
08 Fixed Deal Income
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
23 Stock Adjustments (COGS)
24 RTV From Inventory
25 Unavailable Inv. Transfer
26 Freight Cost
X
X
28 Up Charge Profit
29 Up Charge Expense
30 Transfer In
31 Book Transfer In
32 Transfer Out
33 Book Transfer Out
34 Reclassification In
36 Reclassification Out
Tran Codes
Cost/SL
Retail/SL
37 Inter-company Transfer In
38 Inter-Company Transfer Out
39 Inter Company Margin
Not used for

ending inventory
Calculations
41 RDW Stock Count Adj.
44 RDW Inbound Transfer Receipt
50 Open Stock
51 Budgeted Shrink
X
X
52 Close Stock
53 Gross Margin
54 HTD GAFS
55 Inter Stocktake Sales Amt.
56 Inter Stocktake Shrink Amt
57 Stocktake MTD Sales Amt.
58 Stocktake MTD Shrink Amt
59 Stocktake Bookstk Cost
60 Employee Discount
61 Stocktaks Actstk Cost/Retail
62 Freight Claims
63 Work Order Activity Update
64 Work Order Activity Cost
65 Restocking Fee
70 Cost Variance
71 Cost Variance
72 Cost Variance Cost Accounting
73 Receiver Cost Adjustment Variance
80 Work Room cost
81 Cash Discount
82 Wholesale/Franchise Sales
83 Wholesale/Franchise Returns
84 Wholesale Franchise Markups
85 Wholesale/Franchise Markdowns
86 Wholesale/Franchise Restocking fee
87 VAT In Cost
Transaction Data 63
Transaction Data Data Elements
Tran Codes
Cost/SL
88 VAT out Retail
Retail/SL
Not used for

ending inventory
Calculations

Although data elements of a transaction data record vary by transaction code, the
following is a brief description of the elements:
Transaction Data Elements
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
This field contains the reference number associated with certain

transactions, and is used for defining the General Ledger account
relationship, along with dept, class, subclass, and location, etc. For example:
If tran code is 22 or 23 then this field contains Inventory Adj Reason Code.
If tran code is 37 or 38 then this field contains From_loc or To_loc for the
Intercompany Transfer. If tran code is 63 or 64 then this field contains Work
Order Activity ID. If tran code is 87 or 88 then this field contains the Tax
Code ID.
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.
Transaction Data Elements
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
This field contains the unique numerical code to identify different

transaction types.
TRAN_DATE
This field contains the date at which the transaction occurred.
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.
Stock Ledger Budgets

The first budget table stores information at a department/location/month level. This
month data budget table contains columns for each of the columns on the regular month
data table that are used in the ending inventory calculations (for example, Net Sales,
Shrinkage, Purchase, and so on). It is also important to note that in base RMS, the stock
ledger is run at the subclass level, whereas the planning information is entered here at
the department level. This is because most retailers plan at a level higher than subclass
and usually at the department level.
The other budget table stores information at the department/location/half level. This
half data budget table contains budgeted percentages for cumulative markon,
markdowns, gross margin and shrinkage. At the end of each half, if the HALF_DATA
actual shrinkage percent is present, it will be copied to the HALF_DATA_BUDGET
budgeted shrinkage percent for the next half + 1.
This information differs from that captured in the stock ledger - only a calculated
shrinkage percent is stored (with some other stock count calculation fields). Note again
that this information is stored at the department level, whereas the stock ledger is run at
the subclass level.
Stock Ledger Tables

TRAN_DATA (A&B)
For each type of transaction that occurs in the system involving the movement of
merchandise, a record is written to the transaction data table (TRAN_DATA) at the
item/store/transaction (or item/warehouse/transaction) level. TRAN_DATA_A and
TRAN_DATA_B tables are exactly the same in structure and TRAN_DATA is the view.
The reason behind having two different tables is when one of the tables is locked during
data upload to the IF_TRAN_DATA table, the other table is still open to write
transactions.
Each transaction that is recorded is assigned a transaction code, based on the type of
transaction. In general, each record captures the department, class, subclass, transaction
date, units, cost and retail of the transaction, regardless of the transaction code.
Additionally, the table contains two reference fields that may or may not be used for a
given transaction to record a reason code or event number. For example, the transaction
Stock Ledger Process Consolidation and Batch Processing 67
Stock Ledger Tables
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.
Stock Ledger Tables
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.
Stock Ledger Tables
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.
Stock Ledger Batch Process

The following sections describe the stock ledger batch process, as shown in the diagram
below.
RMS Transactions
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
Stock Ledger Batch Description

SALINS.PC (Stock Ledger and Budget Tables Insert)
All of the stock ledger tables within RMS contain shell records for the upcoming half
based on the running of the regular stock ledger processes (for example, end-of-half, endof-month, end-of-week, and so on). These shell records consist of one record for each
subclass/location for WEEK_DATA, MONTH_DATA and HALF_DATA for the
upcoming weeks, month and half, respectively. Also, for budget records, there will be
one shell record for each department/location for the upcoming half for
MONTH_DATA_BUDGET and HALF_DATA_BUDGET.
When new stores, warehouses, departments or subclasses are added to the RMS, records
are written to a table called STOCK_LEDGER_INSERTS. The Stock Ledger and Budget
Table Insert program processes the records on this table, inserting shell records for the
newly added hierarchy elements. If new locations are added then records are inserted
into MONTH_DATA, WEEK_DATA, HALF_DATA, MONTH_DATA_BUDGET and
HALF_DATA_BUDGET. If new subclasses are added, records are inserted into
MONTH_DATA, WEEK_DATA and HALF_DATA. If new departments are added, then
records are inserted into MONTH_DATA_BUDGET and HALF_DATA_BUDGET.
Once the records have been processed on the STOCK_LEDGER_INSERTS table, they are
purged from the system.
SALSTAGE.PC (Stock Ledger Stage)

In order to make the rollup and extraction of the stock ledger transaction data flexible,
this program moves the data on the TRAN_DATA to the IF_TRAN_DATA staging table.
This enables the processes that are writing records to TRAN_DATA to continue in a
seamless manner, whereas the processes that roll the data up to a different level or
extract the data to external systems can work without affecting batch timetables.
This process locks the TRAN_DATA table and moves all of the data to the staging table.
The original TRAN_DATA table is emptied and the lock on the table is released. Before
this processing occurs, the staging table is first emptied to ensure that data is not
processed twice. Because the data on the TRAN_DATA and IF_TRAN_DATA tables is
very transitional, these tables fill up and are truncated at least once a day if not several
times a day.
SALAPND.PC (Stock Ledger Append)

The purpose of this program is to move data from the staging table for transaction data
(IF_TRAN_DATA) into the historical transaction data table (TRAN_DATA_HISTORY).
This requires placing a lock on the staging table to ensure that no new data is added to it
while the movement is occurring (to handle trickling or real-time processing), moving
the data to the historical table, and finally truncating the data from the staging table.
SALDLY.PC (Daily Stock Ledger)

This program is responsible for performing the daily summarization processing in the
stock ledger in which transaction-level records are fetched from the transaction-level
staging table and summed to the subclass/location/day/currency level. Once the
records are summarized, they are written to the DAILY_DATA table.
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.
SALWEEK.PC (Weekly Stock Ledger Processing)

This program is responsible for performing the weekly summarization processing in the
stock ledger. This program processes all weeks that are in the month for which monthend process has not been run, up to the current week. It rolls up data on DAILY_DATA,
DAILY_DATA_TEMP and WEEK_DATA_TEMP to the corresponding
dept/class/subclass/location/half-month/week/currency level and updates the
WEEK_DATA table.
This program processes all weeks that are in the month for which month-end process has
not been run, up to the current week. This program can be run at any time during the
week, not necessarily just at week-end, because it must be run before the Monthly Stock
Ledger Processing, which can be run at any time after the closing of a month.
In addition to the summarization processes done by this program, there are several week
ending calculations performed as well. The closing stock value, half to date goods
available for sale (HTD GAFS), shrinkage and gross margin are calculated by calling a
package function, based on the accounting method designated for the department, cost
or retail. Additionally, the closing stock value for a processed week becomes opening
stock value for the next week. Also, if this program is run at the end of the week, it writes
a shell record for the next week, populating the key fields on the table (subclass,
location, and so on), the opening stock values at cost and retail and the HTD GAFS at
cost and retail.
SALMTH.PC (Monthly Stock Ledger Processing)

The Monthly Stock Ledger Processing program performs the monthly summarization
processing in the stock ledger in which day-level records are fetched from the
transaction-level staging table and summed to the subclass/location/month level. Once
the records are summarized, they are written to the MONTH_DATA table. This program
processes one month for each program run, starting the latest month to be closed. For
example, if it is currently June and both April and May are open, when the program runs,
only then April is closed.
In addition to the summarization processes done by this program, there are several
month ending calculations done as well. The closing stock value, half to date goods
available for sale (HTD GAFS), shrinkage and gross margin are calculated by calling a
package function, based on the accounting method designated for the department cost
or retail. Additionally, the closing stock value for a processed month becomes opening
stock value for the next month. Also, when this program is run, it writes a shell record
for the next month, populating the key fields on the table (subclass, location, and so on),
the opening stock values at cost and retail, the inter-stock take sales and shrinkage
amounts and the HTD GAFS at cost and retail.
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
Counts Overview (1536804.1) for further details.
SALEOH.PC (End of Half Stock Ledger Processing)

The End of Half Stock Ledger Processing is different from many of the other End of
processes in that it is also the program that controls how many months of stock ledger
data remain on the tables, in addition to the updates to the Half Data table. This program
should be run after the end-of-month processing for month 6 has run and before the endof-month processing for month 1 has run.
The first step for this program is to delete records from stock ledger tables that are 18
months or older. Specifically, the tables that are deleted from are DAILY_DATA,
WEEK_DATA, MONTH_DATA, HALF_DATA, MONTH_DATA_BUDGET and
HALF_DATA_BUDGET. The 18-month limit is not a system parameter; it is hard-coded
into the program.
The next step in this program is for new records to be written for HALF_DATA,
MONTH_DATA_BUDGET and HALF_DATA_BUDGET for the next half. It inserts one
row into HALF_DATA for each subclass/location combination for the next half, six rows
(one for every month of the half) into MONTH_DATA_BUDGET for each
department/location for next years half and one row into HALF_DATA_BUDGET for
each department/location for next years half.
This program also rolls up the inter_stocktake_shrink_amt and
inter_stocktake_sales_amt from the HALF_DATA table at the department/location level
for this half and calculates the shrinkage_pct to insert into HALF_DATA_BUDGET for
the next years half.
SALPRG.PC (Purge Stock Ledger Transactions)

This program is used to purge old transaction-level stock ledger records from the
Transaction Data History table (TRAN_DATA_HISTORY). The Retain Transaction Data
system parameter is used to define the days the Transaction Data History records should
be kept in the system. This program runs nightly to remove any records older than the
current date, the Retain Transaction Data days.
WASTEADJ.PC (Wastage Adjustment)

This program reduces inventory of spoilage type wastage items to account for natural
wastage that occurs over the shelf life of the product. This program affects only items
with spoilage type wastage identified on ITEM_MASTER with a waste_type of SP
(spoilage). Sales type wastage is accounted for at the time of sale.
SALMAINT.PC (Stock Ledger Table Maintenance)

This module is run as either salmaint pre or salmaint post. The salmaint pre functionality
adds partitions to the HALF_DATA, DAILY_DATA, WEEK_DATA and MONTH_DATA
tables. The salmaint post functionality drops partitions or purges the above tables (if the
table is not partitioned) for an old half.
NWPPURGE.PC (End of Year Inventory Position Purge)

This program purges the records from the table NWP after a certain amount of years
have passed. The number of years is a configurable parameter setup in
SYSTEM_OPTIONS.nwp_retention_period.
NWPYEAREND.PC (End of Year Inventory Position Snapshot)

This program takes a snapshot of the items stock position and cost at the end of the year.
When the end of year NWP snapshot process runs, it 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.
General Ledger Cross Reference

The following screen in RMS is used for mapping RMS transactions codes at the
department/class/subclass/location level to accounting segments provided by external
financial system. Account information is stored in FIF_GL_ACCT table and when these
are mapped with the RMS transaction codes, the relationship is stored in the
FIF_GL_CROSS_REF table. For mapping transactions at the more granular level than
transaction code, you can also specify the GL ref no (if populated) for the particular
transaction code in the Tran Ref No. field. You can also specify if the transaction codes
are to be posted at retail or cost.
This relationship is used by General Ledger Batches in populating STG_FIF_GL_DATA
table to stage data to GL for daily detail, daily summary, and monthly summary
interfaces.
General Ledger Batch Description

FIFGLDN1.PC (Financial General Ledger Download 1)
This program extracts the detailed stock ledger information for certain transaction types
on a daily basis in order to bridge the information to an interfaced financial application.
The program reads from the IF_TRAN_DATA table for each transaction type/amount
type and posts it to the Oracle Retail general ledger table (STG_FIF_GL_DATA) at the
SKU detail level.
There is a reference key which is generated and attached to the records in
STG_FIF_GL_DATA table by this program. When integrated with PeopleSoft Enterprise
Financials through the Oracle Retail Financial Integration (ORFI), this reference key can
be used for drill back and drill forward operations between PeopleSoft Enterprise
Financials and the Oracle Retail application. EBS does not have drill back functionality
and this reference key is not used there.

This program summarizes stock ledger data from the transaction staging table
(IF_TRAN_DATA) based on the level of information required and writes it to the
financial general ledger staging table. The transactions extracted are determined by the
code_type GLRT (general ledger rolled transactions). The written information can then
be extracted by the financial applications for general ledger purposes. Stock ledger
information may be rolled-up at department, class or subclass level. The level at which
information is rolled-up to is determined by the gl_rollup field on the
SYSTEM_OPTIONS table.
There is a reference key which is generated and attached to the records in

STG_FIF_GL_DATA table by this program. When integrated with PeopleSoft Enterprise
Financials through the Oracle Retail Financial Integration (ORFI), this reference key can
be used for drill back and drill forward operations between PeopleSoft Enterprise
Financials and the Oracle Retail application. EBS does not have drill back functionality
and this reference key is not used there.

This program summarizes stock ledger data from the monthly stock ledger table
(MONTH_DATA) based on the level of information required and writes it to the
financial general ledger staging table. The transactions extracted are determined by the
code_type GLRT (general ledger rolled transactions). Written information is then sent to
the financial applications for general ledger purposes. Stock ledger information may be
rolled-up at department, class or subclass level. The level at which information is rolledup to is determined by the gl_rollup field on the SYSTEM_OPTIONS table.
DEALFINC.PC (Deal Fixed Income)

This module writes to the STG_FIF_GL_DATA financial staging table to perform stock
ledger processing for fixed deals. It splits deal income over all dept/class/subclass
locations on the deal. This prorated income is written to the general ledger under a
suitable cost center mapping. Each merchandise level/location on the deal has an
associated contrib_ratio to determine how much of the total amount will be apportioned
to items in that merchant/location. Because the user could have entered any fraction of 1
into these fields, the contrib_ratios probably does not add up to 1. Therefore, the ratios
are prorated across all locations so they add up to 1. This value is then apportioned
between all subclasses for the general ledger.
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.
Stock Ledger Online Forms and Functional Views 79
Stock Ledger View Form

The Stock Ledger View form has an initial window where search criteria are entered to
determine how the stock ledger is viewed. From this form, the location, department, class
and subclass is chosen, along with the time period in which to view the data. The choices
for time are all months in a particular half, all weeks in a particular month or all days in a
particular week.
RMS Start Menu > Finance > Stock Ledger View
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.
Stock Ledger Cost Summary View

This view summarizes the value of opening stock, purchases, RTVs, and net transfers by
month, week, or day for the current year for the departments using cost method of
accounting. Shrinkage percentage appears.
Stock Ledger Cost This Year/Last Year View

This view summarizes the value of opening stock, purchases, and net sales by month or
week for the current year and previous year for the departments using cost method of
accounting.
For departments that use the retail method of accounting, the following views are
available:
Stock Ledger Retail Summary View

This view summarizes the value of opening stock, cost and retail additions, and
reductions by month or week for the current year. Cumulative markon and gross profit
margin percentages appear.
Stock Ledger Merchandise Handled View

This view summarizes the value of purchases, return to vendor (cost and retail), net
transfers (cost and retail) and Net Markup by month, week, or day for the current year.
Stock Ledger Retail Reductions View

This view summarizes the value of net sales, net markdown, employee discount, and
weight variance by month, week, or day for the current year.
Stock Ledger Retail This Year/Last Year View

This view summarizes the value of opening stock, net sales, and markdowns by month or
week for the current year and previous year. The gross profit margin percentages appear.
Stock Ledger Inventory Report View

This view displays percentages for cumulative markon, markdown, shrinkage, and gross
profit margin by month or week for the current year and previous year.
Stock Ledger Markdown Report View

This view summarizes the value of markups, cancelled markups, various types of
markdowns, cancelled markdowns, and net sales by month or week for the current year.
The following views are common in both the cases where the department is using cost or
retail method of accounting
Stock Ledger Franchise View

This view summarizes the sales made at the warehouse to franchise stores by month,
week, or day for the current year.
Stock Ledger Intercompany Transfer View

This view summarizes the value of intercompany transfers by month or week for the
current year and previous year.
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.

RMS Stock Ledger White Paper-14.1.x

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RMS Stock Ledger White Paper-14.1.x

Uploaded by

Copyright:

Available Formats

Oracle Retail Merchandising

The following is intended to outline our general

Deals Income (Sales) (Tran Code 06) ............................................................................... 32

Restocking Fee (Tran Code 65) ......................................................................................... 54

Stock Ledger Batch Description ................................................................................... 72

Stock ledger attributes

What impacts the stock ledger

Stock ledger processes

at the interfaces that Oracle Retail Merchandising System

Stock Ledger Organization

Transaction Data API

RMS Stock Ledger Overview 3

Stock Ledger Organization

Stock Ledger Roll Ups

Stock Ledger and Merchandising Transactions

4 Oracle Retail Merchandising System

Stock Ledger Organization

Transactions involving receipt of merchandise

Transactions involving shipping out the merchandise

Transactions only affecting the inventory position.

RMS Stock Ledger Overview 5

Budgeted Shrink Indicator

RMS Stock Ledger Attributes 7

Budgeted Shrink Indicator =

No Unit & Value stock count

Net sales * Budgeted shrink

Unit & Value stock count has

Shrinkage amount from the

Actual shrinkage from the

+ Actual shrinkage from the

Note: Refer to the Oracle Retail Merchandising System Stock

Counts Overview white paper (1536804.1) for further details

8 Oracle Retail Merchandising System

Start of Half Month

Consolidated Exchange Rate

RMS Stock Ledger Attributes 9

Default Tax Type

Estimated Landed Cost

ELC_INCLUSIVE_IND_COMP_STORE This field allows the system to determine

10 Oracle Retail Merchandising System

ELC_INCLUSIVE_IND_WF_STORE This field allows the system to determine if

General Ledger Rollup Level

Minimum / Maximum Cumulative Mark-on Percent

Multiple Set of Books

RMS Stock Ledger Attributes 11

The indicator NWP_RETENTION_PERIOD indicates the number of years the end of

12 Oracle Retail Merchandising System

Receiver Cost Adjustment Type

Retail Markdown for Transfer

Store to Store Transfer - TSF_MD_STORE_TO_STORE_SND_RCV

Store to Warehouse Transfer - TSF_MD_STORE_TO_WH_SND_RCV

Warehouse to Store Transfer - TSF_MD_WH_TO_STORE_SND_RCV

Warehouse to Warehouse Transfer - TSF_MD_WH_TO_WH_SND_RCV

Retain Transaction Data

Stock Count Processing

RMS Stock Ledger Attributes 13

Stock Ledger Retail VAT Inclusive

Stock Ledger Location Level

It requires a customization to run the stock ledger at an all

Stock Ledger Product Level

requires customization to run stock ledger at any other

14 Oracle Retail Merchandising System

Retail Accounting Method

Inventory Calculation Retail Accounting Method