Oracle® Retail Merchandising

System

Catch Weight Overview

Release 14.0

December 2013
Note: 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 Oracle’s products
remains at the sole discretion of Oracle.
 Contents
Contents ............................................................................................................................. ii 
1 Catch Weight Items ........................................................................................................ 1 
Item Data Setup ....................................................................................................................... 1 
Component Item Setup ................................................................................................... 1 
Pack Setup ......................................................................................................................... 4 
Inventory Management .......................................................................................................... 6 
Non-Catch Weight Weighted Items ................................................................................... 15 
Integrating with RWMS and SIM ....................................................................................... 15 
A Appendix: Examples by Type .................................................................................... 17 
Type 1 – Order by Fixed Weight/Sales by Loose Weight ........................................ 17 
Type 2 – Order by Variable Weight/Sell by Loose Weight ..................................... 18 
Type 3 – Order by Fixed Weight/Sell by Variable Weight Eaches ......................... 19 
Type 4 – Order by Variable Weight/Sell by Variable Weight Eaches .................... 20 
 1
Catch Weight Items
Catch Weight functionality allows for the ordering and management of items that vary
by weight from one instance of an item to the next. Examples of this are primarily in the
grocery industry, where items such as fresh produce, deli, butchery and prepackaged
cheese and meat, are often purchased by weight and may be sold by weight or as
individual products (eaches). Catch Weight items can have a varying cost by unit of
measure (UOM) and have an average weight maintained for the items, which is used by
any transactions involving the items where a weight is not captured. From an ordering
perspective, Oracle Retail Merchandising System (RMS) was built primarily to support
ordering of catch weight items using simple packs. However, the ordering of catch
weight items without using simple packs is also supported.
RMS supports four different types of catch weight items, which are outlined in more
detail in this document, including how setup for these items differs from other items in
RMS, as well as the different ways that catch weight items impact inventory functions,
such as purchasing, receiving and cost maintenance.

Item Data Setup

Catch weight items in RMS are indicated by a flag at the item level, as well as some
specific item attributes. Only regular items and simple packs can be designated as catch
weight. RMS supports four different types of catch weight items and packs, which are
categorized by the way they are ordered (by a fixed weight or variable weight) and the
way they are sold (loose weight or variable weight). This section outlines the key
attributes that are set for both the component item (such as a single banana) as well as the
assumed simple packs that are created to support ordering (such as a case of bananas).

Component Item Setup

Catch weight items are set up as regular items in RMS that are sellable, orderable and
inventoried. They are differentiated from other regular items by a flag on the item master
that indicates an item is catch weight. Once this flag is checked, there are several other
key item attributes that also need to be set.

Item Level Attributes

These are attributes that are set at the item level for component items that have been
flagged as ‘catch weight’. These are held on the ITEM_MASTER table in RMS.

Order Type
Accessed from the Grocery Attributes pop-up screen, the Order Type selected for the
component item is only used to control options as part of the item setup process, but is
not really used in the ordering process. Order types can be either Fixed Weight or
Variable Weight.

Catch Weight Items 1

Item Data Setup

Sale Type
Also set on the Grocery Attributes pop-up screen, the Sale Type is determined by the
type of item being maintained. Items sold by varying weights (such as bananas or deli
meat) should be set up with ‘Loose Weight’ to indicate that they are sold by weight,
while items sold as eaches (such as pre-packaged cheese or steak) should be set up as
‘Variable Weight Eaches. In the latter case, the actual retail price charged to the consumer
will vary by the weight but the inventory for the item is maintained by units (eaches).

Standard UOM
For catch weight items, Standard UOM (SUOM) is determined based on the type of the
catch weight item being maintained. For example, items inventoried and sold by variable
weight (such as bananas, deli meat) should have a standard UOM equal to a weight, such
as lbs. or kg. Items designated as variable weight eaches (such as pre-packaged cheese
and sirloin steak) should have a standard UOM equal to ‘EA’ since the items are
inventoried and sold by the each regardless of the weight of an ‘each’.

Note: It is possible to set up items in RMS that have a UOM

other than ‘EA’ that are not flagged as ‘catch weight’. See the
section on Non-Catch Weight Weighted Items below.

Catch Weight UOM

For catch weight items, if the standard UOM is eaches, then this value is systematically
updated with the weight unit of measure based on the case level dimensions entered at
the item/supplier/country level. For example, if the catch weight item being set up is a
pre-packaged steak, then the SUOM is set to eaches and the case dimensions defined for
the item will be in terms of weight (such as one case is 50 lbs or 50 kg). This UOM would
be systematically set to the same UOM as defined in those case dimensions (such as lbs
or kg). See also the Case Level Dimensions section below. This field is not displayed in
RMS, but is used for processing of catch weight items.

UOM Conversion Factor

If the Standard UOM is defined as something other than eaches, then the UOM
conversion factor must be defined at the item level. RMS uses this anytime a transaction
is performed that requires eaches, such as if selling UOM is eaches, but standard UOM is
weight. This is true for non-catch weight items created with a standard UOM other than
EA as well.
The UOM conversion factor defines how many eaches equate to one unit of measure. For
example, if the item is apples, the SUOM is lbs., and the UOM conversion factor is 2, then
it means that two apples equate to 1 lb. So, to determine the assumed weight of one
apple, the calculation would be 1/UOM conversion factor, or 1/2 = .5, for this example.

Catch Weight Type

The Catch Weight Type is a field held in the database for the item, but not displayed
online. It corresponds to the types discussed in this document (based on the order and
sale type selected), but is only populated and used for simple packs.

Item Supplier Country Attributes

For the component item, the following are key attributes or attributes that act differently
for non-catch weight items at the item/supplier/country of sourcing level. These
attributes are held on either the ITEM_SUPPLIER_COUNTRY or
ITEM_SUPPLIER_COUNTRY_DIM table.

2 Oracle Retail Merchandising System Catch Weight Overview

 Item Data Setup

Unit Cost/Cost UOM

The unit of measure for unit cost for all catch weight component items is required to be
in terms of weight. Cost information for the component item, when ordering using
simple packs, is not used, however it is still required and is used for margin calculations.

Case Pack Size

Regardless of whether ordering by simple packs or not, it is recommended that this be set
to the case size in terms of either weight (for types 1 and 2, see below for the definition of
the various types) or in terms of assumed eaches (for types 3 and 4), based on its use in
selling calculations, as well as ordering calculations (for non-simple pack ordering).

Case Pack Dimensions

Net weight for the case should be defined for all catch weight items, although
systematically it is only required for Type 3 and 4 items. Net weight is considered the
nominal weight of a case of the product and is used to calculate the number of eaches for
items that are inventoried in eaches, but ordered using weight. Gross weight and net
weight are defined at the item/supplier/country level.

Note: RMS uses only those dimensions defined against the

dimension object ‘Case’. In situations where the dimensions
for a single unit (EA) are required, the case-level dimensions
will be divided by the defined case pack size.

Item Zone Pricing

Selling UOM
Zone-level retails are defined in terms of the selling UOM. For purposes of this paper, for
catch weight items, it is assumed that the Selling UOM will always be in terms of weight,
regardless of whether they are pre-packaged or loose. However, catch weight items can
be created with a Selling UOM of eaches as well. This is set in RMS at the item/zone level
when the component item is initially created and then maintained in RPM thereafter.

Catch Weight Items 3

Item Data Setup

Setup by Type

Catch Weight Catch Weight Catch Weight Catch Weight

Type 1 Type 2 Type 3 Type 4

Order type Fixed Weight Variable Fixed Weight Variable

Weight Weight

Sales type Loose weight Loose Weight Variable Variable

Weight EA Weight EA

Standard UOM Weight Weight EA EA

Cost UOM Weight Weight Weight Weight

Selling UOM Weight Weight Weight Weight

Case Pack Case Weight Case Weight Case Qty Case Qty

Set Case Dimensions? Optional, but Optional, but Required Required

recommended recommended

Examples Bananas Deli Pre-packaged Pre-packaged

Meat/Cheese Cheese Meat

Pack Setup
Simple packs are pack items that contain a single component item. For catch weight
items, simple packs are assumed to be created for every component item and used for
ordering from the vendor, although it is not required. The usage of these packs in the
ordering process differs by the type of item and is described in more detail below. Some
key attributes that need to be set for catch weight simple packs are as follows:

Pack Level Attributes

These are attributes that are set at the item level for simple packs that have been flagged
as ‘catch weight’. These are held on the ITEM_MASTER table in RMS.

Order Type
The options for this attribute are ‘Fixed Weight’ and ‘Variable Weight’. Fixed Weight is
selected when the pack weight is not relevant to the received cost of the pack. In other
words, the retailer and the supplier have an agreed-upon cost per case based on an
assumed fixed weight. Variable Weight is selected when the cost charged by the supplier
will be dependent upon the actual received weight of the inventory.

Sale Type
This is only set if the pack itself is considered sellable. The options for this are either
Loose Weight or Variable Weight, similar to component items.

Note: For purposes of this document, it is assumed that

simple packs are not sellable.

4 Oracle Retail Merchandising System Catch Weight Overview

 Item Data Setup

Standard UOM
Standard UOM is always ‘EA’ for simple packs and cannot be changed.

Catch Weight Type

The Catch Weight Type is a field held in the database for an item, but not displayed
online. It corresponds to the types discussed in this document (based on the order and
sale type selected), but is only populated for simple packs. This attribute is used by ReIM
as part of the invoice matching process to determine how to handle costs and quantities
sent for matching.

Component Quantity
The simple pack component quantity represents how many of the component item exists
in the pack, represented in terms of the component item’s standard UOM. For items such
as bananas or deli meat that are inventoried by weight, this would represent the weight
of the item in a case. For items that are inventoried in eaches, such as prepackaged meat
or cheese, this number represents the number of packages within a case. This information
is held on the PACKITEM table in RMS.

Item Supplier Country Attributes

For simple pack items, the following are key attributes or attributes that act differently
from non-catch weight items at the item/supplier/country of sourcing level. These
attributes are held on either the ITEM_SUPPLIER_COUNTRY or
ITEM_SUPPLIER_COUNTRY_DIM table.

Unit Cost/Cost UOM

For simple pack unit cost, the assumed unit of measure will be related to the order type.
If it is ordered as variable weight, the cost UOM would be based on weight. Conversely,
if it is ordered as a fixed weight, then the cost UOM would also be EA. However, it is
possible for fixed weight packs to be created with a cost UOM based on weight as well.

Case Pack Size

It is recommended that for simple packs, this always be set to 1, as it is assumed that the
simple pack represents a case.

Case Dimensions
Net Weight for the simple pack item represents the nominal weight for the item and is
used, along with case pack size, to calculate the number of eaches. When the Order Type
is ‘Fixed Weight’ this represents the assumed fixed weight of the case. Net weight is
defined at the item/supplier/country level.

Note: RMS uses only those dimensions defined against the

dimension object ‘Case’. In situations where the dimensions
for a single pack unit (EA) are required, the case-level
dimensions will be divided by the defined case pack size.

Catch Weight Items 5

Inventory Management

Tolerances
When the order type for the simple pack is set as Variable Weight, tolerances must also
be defined for the simple pack. Tolerances exist for validation purposes only, to
determine if the received weight is within the defined tolerance values for a given case
(such as a case contains between 14 kg and 16 kg). In RMS, this is informational only and
is not used for validation during the shipping and receiving processes. However, RMS
does publish this information for use in external systems.

Setup by Type

Catch Weight Catch Weight Catch Weight Catch Weight

Type 1 Type 2 Type 3 Type 4

Order Type Fixed Weight Variable Fixed Weight Variable Weight

Weight

Sales type NA NA NA NA

Standard UOM EA EA EA EA

Cost UOM EA Weight EA Weight

Simple Pack Item Weight Weight EA EA

Quantity

Case Pack 1 1 1 1

Set Case Dimensions? Optional Required Required Required

Tolerance Required? N Y N Y

Examples Bananas Deli Pre-packaged Pre-packaged

Meat/Cheese Cheese Meat

Inventory Management
This section outlines how inventory management differs from that of other items.

Average Weight
One of the biggest differences is the maintenance of an average weight for simple packs
and for component items that have a SUOM of EA. This value impacts weighted average
cost and perpetual inventory.
Average weight is held at the item/location level and is used on certain transactions
involving variable weight items where the actual weight is not captured on the
transaction. Average weight is calculated for all catch weight items with a SUOM of
eaches, which includes the simple pack level for all catch weight types and at the
component item level for types 3 and 4.

6 Oracle Retail Merchandising System Catch Weight Overview

 Inventory Management

Average weight is calculated as:

(A * B) + C
(A + D)

A = existing stock on hand before delivery

B = existing average weight before delivery
C = total weight received in new delivery
D = total units in new delivery

Note: The nominal weight for a simple pack is always to be

used when ordering. The nominal weight is defined during
the simple pack setup as the Net Weight of the simple pack.

Weighted Average Cos

When ordering by simple pack, the weighted average cost (WAC) for catch weight
component items may be impacted by the actual weight of the simple pack that is
recorded for various inventory transactions, as well as the pack’s order type. WAC is not
calculated for pack items of any type in RMS. WAC will continue to be held in terms of
the component item’s standard UOM, not cost UOM, as it pertains to the value of owned
inventory.
For Type 1 items (such as bananas) received as simple packs, WAC is updated on receipt
as follows:

((Total Packs Received * Nominal Weight) * Cost per Cost UOM) + (Current Owned Weight *
Current WAC)
Total Weight Received + Current Owned Weight

For Type 2 items (such as deli meat) received as simple packs, WAC is updated on
receipt as follows:

(Total Weight Received * Cost per Cost UOM) + (Current Owned Weight *
Current WAC)
Total Weight Received + Current Owned Weight

For Type 3 items (such as pre-packaged cheese) received as simple packs, WAC is
updated on receipt as follows:

((Total Packs Received * Nominal Weight) * Cost per Cost UOM) + (Current Owned Eaches *
Current WAC)
Total Eaches Received + Current Owned Eaches

Catch Weight Items 7

Inventory Management

For Type 4 items (such as pre-packaged meat) received as simple packs, WAC is updated
on receipt as follows:

(Total Weight Received * Cost per Cost UOM) + (Current Owned Eaches *
Current WAC)
Total Eaches Received + Current Owned Eaches

Type 1 Example:
At a particular warehouse, there is a total weight of 20 lbs and a current WAC of $1.25. If
a PO is placed for 10 cases of bananas, with a nominal weight of 10 lbs per case, and a
cost of $1 per pound, then if the PO is received with a total weight of 101 lbs, the WAC
would be updated as follows:
(((10 * 10) * $1) + (20 * $1.25))/(101 + 20) = ($100 + $25)/121 = $1.0331

Type 4 Example:
At a particular warehouse, there are 20 cases of ground beef in inventory, with an
average weight of 20 lbs. Each case contains a total of 20 packages ready for sale, which
equates to an average weight of 1 lb. per package. If the current WAC for the component
items is $1.25 per pound and a simple pack is received with a weight of 22 lbs on a PO
with a unit cost of $1 per pound, the WAC would be updated as follows:
((22 * $1) + ((20 * 20) * $1.25))/(20+(20 * 20)) = ($22+$500)/420 = $1.2428

If ordering for component items, then WAC is calculated a bit differently for the various
item types. For type 1 and 2 items, WAC is updated on receipt using the same calculation
as is described above for type 2 items. For types 3 and 4 items, WAC should be updated
the same whether it is ordered as the component or the pack.

Inventory Transactions
The table below outlines the expected behavior in RMS for each of the different inventory
transaction types noted. This is based on the items being created as recommended above.
The Component Item column describes what should happen if the component item is put
on the transaction. The Simple Pack column describes what should happen if the simple
pack is put on the transaction.
For inventory transactions, although there are some exceptions, here are some guiding
principles of how inventory is updated:
ƒ Actual weight should always be used if it is sent with a transaction. If actual weight
is not sent, then average weight should be used. Purchase order receipts are one
exception to this rule, as nominal weight is used if actual weight is not sent, instead
of average weight. Another is transfer receipts, where the weight that was shipped is
always used.
ƒ When transferring in simple packs or at the component level for type 3 and 4 items,
the shipped weight is used as the assumed received weight. This assumption is
primarily due to the assumption that most stores do not weigh on receipt. Therefore,
any weight sent in the receipt of a transfer is ignored by RMS.
ƒ Average weight should be recalculated for every inventory transaction.

8 Oracle Retail Merchandising System Catch Weight Overview

 Inventory Management

ƒ When transfers or returns to vendor (RTV) are created and approved, nominal
weight should be used to ‘reserve’ the inventory, rather than average weight, as
average weight could change between the time the transaction was created and
approved and the time it is shipped.
ƒ Similar to regular items, WAC is not recalculated for outbound shipments, with the
exception of RTVs, if a cost other than WAC is specified on the RTV.

Component Item Simple Pack

Order Management

All If a component item is ordered, the order
Types quantity can be entered in terms of
weight, cases or pallets. The order
quantity must be rounded to multiples of
the case pack size defined for the
component item, however. The cost on the
order is defaulted based on the unit cost
based on the cost UOM defined for the
component item/supplier/country.
Catch weight simple packs will always be
ordered in eaches, regardless of type. So, the
quantity on the order equates to how many
cases are being ordered. The cost for all
simple pack ordering is defaulted based on
the item/supplier/country unit cost for the
pack.

PO Receiving

Type For Type 1, on hand is updated based on
1 what is sent to RMS in the quantity field
on the receipt – if weight is included, it is
ignored. WAC is updated based on the
quantity received, which in this case
would be weight.
With this type of ordering/receiving, the
vendor cost is based on actual received
weight, not a fixed weight, regardless of
the order type selected for the component
item.
Pack on hand is updated based on the
number of packs received. Average weight
should also be updated based on either the
actual weight or the nominal weight.
The component item’s SOH will be updated
based on either actual received weight or
nominal weight. WAC will also be updated
based on both receipt and nominal weight
(see calculation above). No average weight is
maintained for type 1 component items.
Vendor cost is based on the nominal weight
ordered, not on actual weight.

Type For Type 2, on hand is updated based on Pack on hand is updated based on the
2 what is sent to RMS in the quantity field number of packs received. Average weight
on the receipt – if weight is included, it is should also be updated based on either the
ignored. WAC is updated based on the actual weight or nominal weight.
quantity received, similar to regular items, The component item’s SOH will be updated
which in this case would be weight. based on actual received weight or nominal
With this type of ordering/receiving, the weight. WAC will also be updated by the
vendor is paid based on the cost of the receipt weight (see calculation above).
actual received weight, not a fixed weight. Vendor cost is based on the total received
weight, which may be more or less what was
ordered.

Catch Weight Items 9

Inventory Management
Type For Type 3, on hand is updated based on
3 what is sent to RMS in the quantity field
on the receipt. If weight is included in the
receipt, then it should be used to update
the average weight of the item. If not, then
the nominal weight should be used to
update average weight. WAC is updated
as described above, based on nominal
weight, not actual received weight, since
this is a fixed order type item.
Also, for this type of item, the vendor is
paid based on the cost of the nominal
weight.
Type For Type 4, on hand is updated based on
4 what is sent to RMS in the quantity field
on the receipt. If weight is included in the
receipt, then it should be used to update
the average weight of the item. If not, then
the nominal weight should be used to
update average weight. WAC is updated
as described above, based on received
weight since this is a variable order type
item.
Also, for this type of item, the vendor is
paid based on the cost of the received
weight, not a fixed weight.
Invoicing
Type With this type of ordering/receiving, the
1 invoice matching is based on actual
received weight, not a fixed weight,
regardless of the order type selected for
the component item. This is because the
quantity on the order is assumed to be the
weight received, not the nominal or fixed
weight.
Type With this type of ordering/receiving, the
2 invoice matching is based on actual
received weight, not a fixed weight,
regardless of the order type selected for
the component item. This is because the
quantity on the order is assumed to be the
weight received, not the nominal weight.
Type For this type of item, since the items are
3 assumed to be a fixed weight, the vendor
is paid based on the cost of the nominal
weight of the item, not the actual received
weight. Therefore, it is treated much like a
non-catch weight item in ReIM.
10 Oracle Retail Merchandising System Catch Weight Overview
Pack on hand is updated based on the
number of packs received. Average weight
should also be updated based on either the
actual weight or nominal weight received.
The component item’s SOH will be updated
based on the number of packs received * pack
component quantity. The average weight for
the component item is also updated based on
the actual or nominal weight received. WAC
will be updated by the ordered weight and
the quantity received (see calculation above).
Vendor cost is based on the nominal weight
ordered, not on actual weight.
Pack on hand is updated based on the
number of packs received. Average weight
should also be updated based on either the
actual weight or nominal weight received.
The component item’s SOH will be updated
based on the number of packs received * pack
component quantity. The average weight for
the component item is also updated based on
the actual or nominal weight received. WAC
will be updated by the weight received and
the quantity received (see calculation above).
Vendor cost is based on the total received
weight, which may be more or less what was
ordered.
For this type of catch weight item, since the
vendor cost is based on the nominal weight
ordered, not on actual weight, the cost and
quantity of the simple pack received can be
used in ReIM much like for non-catch weight
items.
Vendor cost is based on the total received
weight, which may be more or less what was
ordered. However, since ReIM only has the
concept of quantity and cost in eaches, a
conversion is done for the cost for this type of
item based on the weight received, pack
quantity and cost UOM to derive the cost in
terms of the pack eaches received.
For this type of catch weight item, since the
vendor cost is based on the nominal weight
ordered, not on actual weight, the cost and
quantity of the simple pack received can be
used in ReIM much like for non-catch weight
items.

Also, for this type of item, the vendor is
paid based on the cost of the received
weight, not a fixed weight.
Type
4 conversion is done for the cost for this type of
Transfers
When transferring type 1 component
items, the weight is ignored, because it is
assumed that the quantity sent is the
weight. When the transfer is created,
inventory is reserved based on the
quantity on the transfer. When shipped,
in-transit is updated based on quantity
shipped. And on receipt, quantity is
Type updated based on received amount. If a
1 transfer of this type is weighed at the
shipping location and not at the receiving
location (or vice versa) resulting in a
discrepancy on receipt, it will be resolved
like all other transfer discrepancies, based
on the setting of various system options in
RMS.
When transferring type 2 component
items, the weight is ignored, as it is
assumed that the quantity sent is the
weight. When the transfer is created,
inventory is reserved based on the
quantity on the transfer. When shipped,
in-transit is updated based on quantity
Type shipped. And on receipt, quantity is
2 updated based on received amount. If a
transfer of this type is weighed at the
shipping location and not at the receiving
location (or vice versa) resulting in a
discrepancy on receipt, it will be resolved
like all other transfer discrepancies, based
on the setting of various system options in
RMS.
Inventory Management
Vendor cost is based on the total received
weight, which may be more or less what was
ordered. However, since ReIM only has the
concept of quantity and cost in eaches, a
item based on the weight received, pack
quantity and cost UOM to derive the cost in
terms of the pack eaches received.
When the transfer is created and approved,
reserved quantity for the component item
should be updated based on the nominal
weight of the pack.
Upon shipment, if a weight is included in the
outbound shipment, then in-transit for the
component item is updated based on actual
weight shipped and average weight should
also be updated. If no weight is included in
the shipment, then the current average
weight for the shipping location should be
used. If the receiving location is a warehouse,
then average weight for the pack is also
updated based on the weight included.
Upon receipt, if a weight is included, it is
ignored by RMS. The shipped weight is
always used to prevent discrepancies.
When the transfer is created and approved,
reserved and expected quantities for the pack
and component item are updated based on
the nominal weight of the pack.
Upon shipment, if a weight is included in the
outbound shipment, then in-transit for the
component item is updated based on that
weight. This would also result in an
adjustment to average weight at the shipping
location. If the receiving location for the
transfer is a warehouse, then the average
weight of the pack at the receiving location
would also be updated upon shipment.
Upon receipt, on hand at the receiving
location is updated based on the shipped
weight.
Catch Weight Items 11
Inventory Management
When creating transfers for type 3
component items, inventory is reserved
based on the quantity on the transfer only.
When shipped, in-transit is updated based
on quantity shipped and average weight
is updated for both the shipping and
receiving locations. If no weight is
included on the outbound shipment, then
average weight is used. On receipt,
Type quantity is updated based on received
3 quantity, with the weight on receipt
assumed to be the shipped weight.
When creating transfers for type 4
component items, inventory is reserved
based on the quantity on the transfer only.
When shipped, in-transit is updated based
on quantity shipped and average weight
is updated for both the shipping and
receiving locations. If no weight is
included on the outbound shipment, then
average weight is used.On receipt,
Type quantity is updated based on received
4 quantity, with the weight on receipt
assumed to be the shipped weight.
RTVs
When based on component level
information, RTVs for type 1 catch weight
items work similar to non-catch weight
items, in the sense that the weight
represents the quantity. The cost value is
Type weight * component WAC, unless a
1 specific RTV cost has been designated.
12 Oracle Retail Merchandising System Catch Weight Overview
When the transfer is created and approved,
reserved quantity for the component item
should be updated based on the pack
component quantity.
Upon shipment, the pack component quantity
is used to update in transit (also pack
quantity if shipment is to a warehouse). If a
weight is included in the outbound shipment,
then average weight is also updated for the
component item at both shipping and
receiving locations. If not, then average
weight is used for the updates. If the
receiving location is a warehouse, then
average weight for the pack is also updated
based on transfer weight.
Upon receipt, on hands are updated based on
quantity received. If a weight is included, it is
ignored by RMS. The shipped weight is
always used to prevent discrepancies.
When the transfer is created and approved,
reserved quantity for the component item
should be updated based on the pack
component quantity.
Upon shipment, the pack component quantity
is used to update in transit (also pack
quantity if shipment is to a warehouse). If a
weight is included in the outbound shipment,
then average weight is also updated for the
component item at both shipping and
receiving locations. If not, then average
weight is used for the updates. If the
receiving location is a warehouse, then
average weight for the pack is also updated
based on transfer weight.
Upon receipt, on hands are updated based on
quantity received. If a weight is included, it is
ignored by RMS. The shipped weight is
always used to prevent discrepancies.
For the pack item, on hand is updated based
on the number of packs shipped and average
weight should also be recalculated if actual
weight is included for the RTV.
For an RTV created in RMS, RTV quantity for
the component item is updated based on the
nominal weight of the pack. Then, when the
RTV is shipped, inventory is removed based
on actual weight or average weight, if no
weight included in the file. It is assumed that
the cost of this transaction is based on WAC,
unless overridden on the RTV transaction.

When based on component level
information, RTVs for type 2 catch weight
items work similar to non-catch weight
items, in the sense that the weight
represents the quantity. The cost value is
Type weight * component WAC, unless a
2 specific RTV cost has been designated.
When based on component level
information, RTVs for type 3 catch weight
items work similar to non-catch weight
items, in the sense that quantity is
updated based on shipment. However,
Type unlike non-catch weight items, the
3 average weight for this type of item is also
updated, if an actual weight is included
with the shipment information. The cost
value is quantity * component WAC,
unless a specific RTV cost has been
designated.
When based on component level
information, RTVs for type 4 catch weight
items work similar to non-catch weight
items, in the sense that quantity is
updated based on shipment. However,
Type unlike non-catch weight items, the
4 average weight for this type of item is also
updated, if an actual weight is included
with the shipment information. The cost
value is quantity * component WAC,
unless a specific RTV cost has been
designated.
Inventory Adjustments
For adjustments made at the item level,
the quantity of the adjustment is assumed
to be in terms of weight. The cost value is
weight * component WAC.
There should not be an update to WAC
for an inventory adjustment transaction.
Type
1
Inventory Management
For the pack item, on hand is updated based
on the number of packs shipped and average
weight should also be recalculated if actual
weight is included for the RTV.
For an RTV created in RMS, RTV quantity for
the component item is updated based on the
nominal weight of the pack. Then, when the
RTV is shipped, inventory is removed based
on actual weight or average weight, if no
weight included in the file. It is assumed that
the cost of this transaction is based on WAC,
unless overridden on the RTV transaction.
For the pack item, on hand is updated based
on the number of packs shipped and average
weight should also be recalculated if actual
weight is included for the RTV.
For the component item, inventory is
removed based on quantity shipped and
average weight is updated, if an actual
weight is included with the shipment. It is
assumed that the cost of this transaction is
based on WAC, unless overridden on the
RTV transaction.
For the pack item, on hand is updated based
on the number of packs shipped and average
weight should also be recalculated if actual
weight is included for the RTV.
For the component item, inventory is
removed based on quantity shipped and
average weight is updated, if an actual
weight is included with the shipment. It is
assumed that the cost of this transaction is
based on WAC, unless overridden on the
RTV transaction.
For adjustments made to the pack, the
inventory for the pack is adjusted based on
the quantity entered for the adjustment. If an
actual weight is passed with the transaction,
it should be used to update the average
weight of the pack item as well.
The component inventory adjustment
quantity is based on the number of packs *
actual weight (if sent) or average weight of
the pack. The cost value is the component
adjustment quantity * component WAC.
There should not be an update to WAC for an
inventory adjustment transaction.
Catch Weight Items 13
Inventory Management
For adjustments made at the item level,
the quantity of the adjustment is assumed
to be in terms of weight. The cost value is
weight * component WAC.
There should not be an update to WAC
for an inventory adjustment transaction.
Type
2
For adjustments made at the item level,
the quantity of the adjustment is used to
update stock on hand and, if a weight is
included with the adjustment, may also
update average weight. The cost value is
quantity * component WAC.
There should not be an update to WAC
Type
for an inventory adjustment transaction.
3
For adjustments made at the item level,
the quantity of the adjustment is used to
update stock on hand and, if a weight is
included with the adjustment, may also
update average weight. The cost value is
quantity * component WAC.
There should not be an update to WAC
Type
for an inventory adjustment transaction.
4
Sales
Sales and returns for type 1 items will be
Type in terms of actual weight. It is assumed
1 the weight sold is populated in the
quantity field on the sales file sent to RMS.
If the weight field is populated, it is
ignored. The cost of sale is calculated as
the weight of the sale * current WAC.
Type
2
14 Oracle Retail Merchandising System Catch Weight Overview
For adjustments made to the pack, the
inventory for the pack is adjusted based on
the quantity entered for the adjustment. If an
actual weight is passed with the transaction,
it should be used to update the average
weight of the pack item as well.
The component inventory adjustment
quantity is based on the number of packs *
actual weight (if sent) or average weight of
the pack. The cost value is the component
adjustment quantity * component WAC.
There should not be an update to WAC for an
inventory adjustment transaction.
For adjustments made to the pack, the
inventory for the pack is adjusted based on
the quantity entered for the adjustment. If an
actual weight is passed with the transaction,
it should be used to update the average
weight of the pack item as well.
The component inventory adjustment
quantity is pack quantity adjusted *
component quantity. If a weight is sent, then
it is also used to update the average weight of
the component item. The cost value is the
component adjustment quantity * component
WAC.
There should not be an update to WAC for an
inventory adjustment transaction.
For adjustments made to the pack, the
inventory for the pack is adjusted based on
the quantity entered for the adjustment. If an
actual weight is passed with the transaction,
it should be used to update the average
weight of the pack item as well.
The component inventory adjustment
quantity is pack quantity adjusted *
component quantity. If a weight is sent, then
it is also used to update the average weight of
the component item. The cost value is the
component adjustment quantity * component
WAC.
There should not be an update to WAC for an
inventory adjustment transaction.
Although it is possible to set up a catch
weight pack as sellable, for purposes of this
document, it is assumed that catch weight
simple packs are not sellable.
 Non-Catch Weight Weighted Items

For Type 3 items, a sale is expected to be

Type in terms of both eaches and actual weight,
3 if the actual weight is provided.
Otherwise, average weight for the
component item will be used. Therefore, a
sale will reduce the SOH for the item sold
and also adjust the average weight of the
Type component (if actual weight provided).
4 Cost of sales will be based on either actual
or average weight * component WAC.

Non-Catch Weight Weighted Items

It is possible to create an item in RMS with a standard UOM of a weight that is not
classified as a catch weight item. Examples of when this might be used are for items such
as bulk candy or nuts, which are often ordered and sold by weight, but usually don’t
require weighing on receipt, due to the minute variations in weight. Therefore the
vendor is always paid based on the assumed weight received. This is very similar to
catch weight type 1, but for items setup as catch weight type 1, it is assumed that there
may be variation in weight, which is significant enough to warrant recording the impact
on WAC and the retail value of inventory. For non-catch weight items, an average weight
is not maintained.

Integrating with RWMS and SIM

As noted above, RMS is dependent on receiving weight information from external
systems for inventory related transactions. To support this, the indicators described
above are published from RMS to Oracle Retail Warehouse Management System
(RWMS) and Oracle Retail Store Inventory Management (SIM) to assist in identifying the
expected behavior of the various item types.

RWMS Processing of Catch Weight Items

RWMS only has a concept of two types of items – those that need a weight captured on
receipt and those that do not. This is set as an item level attribute in RWMS. Although it
is assumed that all catch weight items would be setup as weighed items, it is not
systematically enforced.
For all items created as weighed items, if the transaction is for a simple pack, then RWMS
will send a quantity in the quantity field on the transaction and a weight in the weight
field. If it is processing a component item, then it will send weight in both the quantity
and weight fields. The weight used may be either actual weight, if the product is
weighed as part of the transaction, or a calculated weight based on RWMS rules.

Note: It is assumed that in a warehouse, inventory is always

in cases and never broken down to eaches.

Catch Weight Items 15

Integrating with RWMS and SIM

Known issues
ƒ Today the catch weight indicator sent by RMS is not used to set the indicator in
RWMS used to determine whether it should be weighed or not.
ƒ The calculated weight used by RWMS in cases where a transaction is not weighed is
not based on the average weight of the item in the warehouse as calculated by RMS.
This will result in a decreased accuracy of the average weight calculation in RMS,
which impacts the cost and retail value of inventory in the warehouse. The
calculation of weight in RWMS needs to be rationalized with RMS average weight
functionality.
ƒ Both RMS and RWMS have a concept of tolerances, but they are defined differently.
RMS tolerances are defined as described above and published to RWMS. However,
these are not utilized by RWMS, which defines maximum tolerances only for items. If
defined, a receipt that exceeds maximum tolerances would stop the receiving process
in RWMS. Another difference is that tolerances are defined at the item/supplier level
in RWMS, not item/supplier/country like in RMS.
ƒ RWMS can currently support only one unit of measure for weight versus RMS which
can differ by item.
ƒ Many vendors are able to utilize EAN128 bar codes to send weight information on
ASNs. While RWMS supports getting receipt weight via EAN128 bar codes, it does
not yet utilize the weights supplied on ASNs for receiving.

SIM Processing of Catch Weight Items

Because most stores do not have scales that are used when receiving product, SIM does
not currently support the ability to send both a quantity and a weight when processing
inventory transactions. This means that for any inventory transaction where RMS is
looking for both a quantity and a weight – which is all catch weight items, except Types 1
and 2 at component level – only a quantity will be sent and RMS will use the rules
defined above to determine the weight to be associated with the transaction. For type 1
and 2 component level processing, the weight is expected by RMS in the quantity field.
So, SIM users will be required to input some type of weight. It is assumed to be a
business process defined by the retailer to determine how this weight is derived in the
store.

Known issues:
ƒ Because SIM cannot send both a weight and quantity, direct store delivery (DSD) for
Type 2 and 4 items ordered at the simple pack level will always be received using the
nominal weight of the pack, which leads to invoice matching issues, as this is not
how vendors invoice for these types of products.
ƒ For Type 1 and 3 items ordered using simple packs, RMS will also use nominal
weight for DSD receipts sent from SIM, which may result in inventory valuation
being off due to weight fluctuation of the pack, which would impact margin, but
would not cause a mismatch on invoicing with the vendor.
ƒ Many vendors are able to utilize EAN128 bar codes to send weight information on
ASNs. While SIM does not yet utilize the weights supplied on ASNs for receiving.

16 Oracle Retail Merchandising System Catch Weight Overview

 A
Appendix: Examples by Type
The following sections show similar examples for receiving a PO and shipping a transfer
for each of the four catch weight types using both a simple pack and component level
item as examples. These examples illustrate how the application is intended to work for
each of these examples.

Type 1 – Order by Fixed Weight/Sales by Loose Weight

This type of catch weight item is what is assumed would be used for fresh produce, such
as bananas, as this type of product is typically purchased for an assumed fixed weight
case (such as 50 kg) for a specific cost. But, when sold to a customer, is typically sold by
weight. For example, a customer may buy .46 KG of bananas for $1.00.

Simple Pack Ordering

Com ponent Assum ptions: - Standard UOM = LBS
- Cost and Selling UOM = LBS
- Net Weight per Case = 40 LBS
- Case Quantity = 40 LBS
- Unit Cost = $1 per LB
Pack Assum ptions: - Standard UOM = EA
- Cost UOM = EA
- Net Weight per Case = 40 LBS
-Pack Quantity = 40 LBS
- Unit Cost = $40

Warehouse Store
Com ponent Item Pack Item Com ponent Item
On Order + Reserved + Expected +
SOH + Pack Pack On Pack Pack
Transaction SOH Order Reserved Avg Weight Avg Cost SOH On Order Reserved Avg Weight Avg Cost SOH Expected In Transit Avg Weight Avg Cost
PO created for 10 packs @ $40/case to WH 0.0 400.0 0.0 $ 1.0000 0.0 10.0 0.0 40.00 0.0 0.0 0.0 $ 1.0000
Shipment for 10 packs received at WH for 403 LBS 403.0 0.0 0.0 $ 0.9926 10.0 0.0 0.0 40.30 0.0 0.0 0.0 $ 1.0000

PO created for 10 packs @ $40/case to WH 403.0 400.0 0.0 $ 0.9926 0.0 10.0 0.0 40.30 0.0 0.0 0.0 $ 1.0000
Shipment for 10 packs received at WH w ithout w eight 803.0 0.0 0.0 $ 0.9963 20.0 0.0 0.0 40.15 0.0 0.0 0.0 $ 1.0000

Transfer created to ship 2 cases to store 803.0 0.0 80.0 $ 0.9963 20.0 0.0 2.0 40.15 0.0 80.0 0.0 $ 1.0000
Transfer shipped from WH to store w ith w eight of 80.1 LBS 722.9 0.0 0.0 $ 0.9963 18.0 0.0 0.0 40.16 0.0 0.0 80.1 $ 0.9963
Transfer received at store, no w eight on receipt 722.9 0.0 0.0 $ 0.9963 18.0 0.0 0.0 40.16 80.1 0.0 0.0 $ 0.9963

Non-Simple Pack Ordering

Assum ptions: - Standard UOM = LBS
- Cost and Selling UOM = LBS
- Net Weight per Case = 40 LBS
- Case Quantity = 40 LBS
- Unit Cost = $1 per LB

Warehouse Store
Com ponent Item Com ponent Item
On Order + Reserved +
SOH + Pack Pack On Pack
Transaction SOH Order Reserved Avg Weight Avg Cost SOH Expected In Transit Avg Weight Avg Cost
PO created for 10 cases of component item @ $40 per case 0.0 400.0 0.0 $ 1.00 0.0 0.0 0.0 $ 1.00
Shipment for 10 cases received at WH for 403 LBS 403.0 0.0 0.0 $ 1.00 0.0 0.0 0.0 $ 1.00

PO created for 10 cases @ $40/case to WH 403.0 400.0 0.0 $ 1.00 0.0 0.0 0.0 $ 1.00
Shipment for 10 cases received at WH w ithout w eight 803.0 0.0 0.0 $ 1.00 0.0 0.0 0.0 $ 1.00

Transfer created to ship 2 cases to store 803.0 0.0 80.0 $ 1.00 0.0 80.0 0.0 $ 1.00
Transfer shipped from WH to store w ith w eight of 80.1 LBS 722.9 0.0 0.0 $ 1.00 0.0 0.0 80.1 $ 1.00
Transfer received at store, receipt based on box label w eight** 722.9 0.0 0.0 $ 1.00 80.0 0.0 0.1 $ 1.00

**For the transfer discrepancy in the non-simple pack transfer example above, this may
be automatically resolved based on the setting of system parameters (such as Transfer
Auto Close – Store). This example assumes manual reconciliation of the transfer for
illustrative purposes.

Appendix: Examples by Type 17

 Integrating with RWMS and SIM

Type 2 – Order by Variable Weight/Sell by Loose Weight

This type of catch weight item is what is assumed would be used for product, such as
meat or cheese purchased at the deli counter in a store, where the product is both
purchased from the vendor and sold to end consumers based on varying weight. For
example, a ham may be ordered from a vendor for 20 lbs., but the actual ham received is
+/- 1 pound. For sales, the ham would be sliced up for sale to the end consumer based on
the consumer’s requested amount.

Simple Pack Ordering

Com ponent Assum ptions: - Standard UOM = LBS
- Cost and Selling UOM = LBS
- Net Weight per Case = 40 LBS
- Case Quantity = 40 LBS
- Unit Cost = $1 per LB
Pack Assum ptions: - Standard UOM = EA
- Cost UOM = LBS
- Net Weight per Case = 40 LBS
- Pack Quantity = 40 LBS
- Unit Cost = $1 per LB

Warehouse Store
Com ponent Item Pack Item Com ponent Item
Expected +
Pack
Transaction SOH On Order Reserved Avg Weight Avg Cost SOH On Order Reserved Avg Weight Avg Cost SOH Expected In Transit Avg Weight Avg Cost
PO created for 10 packs @ $40/case to WH 0.0 400.0 0.0 $ 1.00 0.0 10.0 0.0 40.00 0.0 0.0 0.0 $ 1.0000
Shipment for 10 packs received at WH for 403 LBS 403.0 0.0 0.0 $ 1.00 10.0 0.0 0.0 40.30 0.0 0.0 0.0 $ 1.0000

PO created for 10 packs @ $40/case to WH 403.0 400.0 0.0 $ 1.00 10.0 10.0 0.0 40.30 0.0 0.0 0.0 $ 1.0000
Shipment for 10 packs received at WH w ithout w eight 803.0 0.0 0.0 $ 1.00 20.0 0.0 0.0 40.15 0.0 0.0 0.0 $ 1.0000

Transfer created to ship 2 cases to store 803.0 0.0 80.0 $ 1.00 20.0 0.0 2.0 40.15 0.0 80.0 0.0 $ 1.00
Transfer shipped from WH to store w ith w eight of 80.1 LBS 722.9 0.0 0.0 $ 1.00 18.0 0.0 0.0 40.16 0.0 0.0 80.1 $ 1.00
Transfer received at store, no w eight on receipt 722.9 0.0 0.0 $ 1.00 18.0 0.0 0.0 40.16 80.1 0.0 0.0 $ 1.00

Non-Simple Pack Ordering

Assum ptions: - Standard UOM = LBS
- Cost and Selling UOM = LBS
- Net Weight per Case = 40 LBS
- Case Quantity = 40 LBS
- Unit Cost = $1 per LB

Warehouse Store
Com ponent Item Com ponent Item

Transaction SOH On Order Reserved Avg Weight Avg Cost SOH On Order In Transit Avg Weight Avg Cost
PO created for 10 cases of component item @ $40 per case 0.0 400.0 0.0 $ 1.00 0.0 0.0 0.0 $ 1.00
Shipment for 10 cases received at WH for 403 LBS 403.0 0.0 0.0 $ 1.00 0.0 0.0 0.0 $ 1.00

PO created for 10 cases @ $40/case to WH 403.0 400.0 0.0 $ 1.00 0.0 0.0 0.0 $ 1.00
Shipment for 10 cases received at WH w ithout w eight 803.0 0.0 0.0 $ 1.00 0.0 0.0 0.0 $ 1.00

Transfer created to ship 2 cases to store 803.0 0.0 80.0 $ 1.00 0.0 80.0 0.0 $ 1.00
Transfer shipped from WH to store w ith w eight of 80.1 LBS 722.9 0.0 0.0 $ 1.00 0.0 0.0 80.1 $ 1.00
Transfer received at store, receipt based on box label w eight** 722.9 0.0 0.0 $ 1.00 80.0 0.0 0.1 $ 1.00

18 Oracle Retail Merchandising System Catch Weight Overview

 Integrating with RWMS and SIM

Type 3 – Order by Fixed Weight/Sell by Variable Weight Eaches

This type of catch weight product is what is assumed would be used for something like
pre-packaged cheese, where product is typically purchased in a fixed weight case from
the vendor and where inside the case is individually packaged ‘eaches’ at varying
weights. For example, a 25 kg case of brie may be purchased from the vendor, and inside
the case are 50 individually wrapped wedges of brie ready for sale to the end consumer
all at approximately .5 kg in size.

Simple Pack Ordering

Com ponent Assum ptions: - Standard UOM = EA Pack Assum ptions: - Standard UOM = EA
- Cost and Selling UOM = LBS - Cost UOM = EA
- Net Weight per Case = 80 LBS - Net Weight per Case = 80 LBS
- Case Quantity = 40 eaches - Pack Quantity = 40 eaches
- Unit Cost = $1 per LB - Unit Cost = $80

Warehouse Store
Com ponent Item Pack Item Com ponent Item
Expected +
Pack
Transaction SOH On Order Reserved Avg Weight Avg Cost SOH On Order Reserved Avg Weight Avg Cost SOH Expected In Transit Avg Weight Avg Cost
PO created for 10 packs @ $80/case to WH 0.0 400.0 0.0 2.0000 $ 2.00 0.0 10.0 0.0 80.0000 0.0 0.0 0.0 2.0 $ 2.00
Shipment for 10 packs received at WH for 803 LBS 400.0 0.0 0.0 2.0075 $ 2.00 10.0 0.0 0.0 80.3000 0.0 0.0 0.0 2.0 $ 2.00

PO created for 10 packs @ $80/case to WH 400.0 400.0 0.0 2.0075 $ 2.00 10.0 10.0 0.0 80.3000 0.0 0.0 0.0 2.0 $ 2.00
Shipment for 10 packs received at WH w ithout w eight 800.0 0.0 0.0 2.0038 $ 2.00 20.0 0.0 0.0 80.1500 0.0 0.0 0.0 2.0 $ 2.00

Transfer created to ship 2 cases to store 800.0 0.0 80.0 2.0038 $ 2.00 20.0 0.0 2.0 80.1500 0.0 80.0 0.0 2.0000 $ 2.00
Transfer shipped from WH to store w ith w eight of 160.2 LBS 720.0 0.0 0.0 2.0039 $ 2.00 18.0 0.0 0.0 80.1556 0.0 0.0 80.0 2.0025 $ 2.00
Transfer received at store, no w eight on receipt 720.0 0.0 0.0 2.0039 $ 2.00 18.0 0.0 0.0 80.1556 80.0 0.0 0.0 2.0025 $ 2.00

Non-Simple Pack Ordering

Assum ptions: - Standard UOM = EA
- Cost and Selling UOM = LBS
- Net Weight per Case = 80 LBS
- Case Quantity = 40 eaches
- Unit Cost = $1 per LB

Warehouse Store
Com ponent Item Com ponent Item

Transaction SOH On Order Reserved Avg Weight Avg Cost SOH Expected In Transit Avg Weight Avg Cost
PO created for 10 cases of component item @ $80 per case 0.0 400.0 0.0 2.0000 $ 2.0000 0.0 0.0 0.0 2.0000 $ 2.0000
Shipment for 10 cases received at WH for 803 LBS 400.0 0.0 0.0 2.0075 $ 2.0000 0.0 0.0 0.0 2.0000 $ 2.0000

PO created for 10 cases @ $80/case to WH 400.0 400.0 0.0 2.0075 $ 2.0000 0.0 0.0 0.0 2.0000 $ 2.0000
Shipment for 10 cases received at WH w ithout w eight 800.0 0.0 0.0 2.0038 $ 2.0000 0.0 0.0 0.0 2.0000 $ 2.0000

Transfer created to ship 2 cases to store 800.0 0.0 80.0 2.0038 $ 2.0000 0.0 80.0 0.0 2.0000 $ 2.0000
Transfer shipped from WH to store w ith w eight of 160.2 LBS 720.0 0.0 0.0 2.0039 $ 2.0000 0.0 0.0 80.0 2.0025 $ 2.0000
Transfer received at store, receipt based on box label w eight** 720.0 0.0 0.0 2.0039 $ 2.0000 80.0 0.0 0.0 2.0025 $ 2.0000

Appendix: Examples by Type 19

 Integrating with RWMS and SIM

Type 4 – Order by Variable Weight/Sell by Variable Weight Eaches

This type of catch weight item is assumed it would be used for something like pre-
packaged sirloin steak, where the product is purchased from the vendor based on
varying weight, but is inventoried as an each (packages of steak) that varies in weight.
For example, a 50 lb. case of steaks may be ordered from a vendor, but the actual weight
received is +/- 1 pound. When sold, the individual packages are sold as eaches, but
priced by weight.

Simple Pack Ordering

Component Assum ptions: - Standard UOM = EA Pack Assum ptions: - Standard UOM = EA
- Cost and Selling UOM = LBS - Cost UOM = LBS
- Net Weight per Case = 80 LBS - Net Weight per Case = 80 LBS
- Case Quantity = 40 eaches - Pack Quantity = 40 eaches
- Unit Cost = $1 per LB - Unit Cost = $80

Warehouse Store
Com ponent Item Pack Item Com ponent Item
Expected +
Pack
Transaction SOH On Order Reserved Avg Weight Avg Cost SOH On Order Reserved Avg Weight Avg Cost SOH Expected In Transit Avg Weight Avg Cost
PO created for 10 packs @ $80/case to WH 0.0 400.0 0.0 2.0000 $ 2.0000 0.0 10.0 0.0 80.0000 0.0 0.0 0.0 2.0000 $ 2.0000
Shipment for 10 packs received at WH for 803 LBS 400.0 0.0 0.0 2.0075 $ 2.0075 10.0 0.0 0.0 80.3000 0.0 0.0 0.0 2.0000 $ 2.0000

PO created for 10 packs @ $80/case to WH 400.0 400.0 0.0 2.0075 $ 2.0075 10.0 10.0 0.0 80.3000 0.0 0.0 0.0 2.0000 $ 2.0000
Shipment for 10 packs received at WH w ithout w eight 800.0 0.0 0.0 2.0038 $ 2.0038 20.0 0.0 0.0 80.1500 0.0 0.0 0.0 2.0000 $ 2.0000

Transfer created to ship 2 cases to store 800.0 0.0 80.0 2.0038 $ 2.0038 20.0 0.0 2.0 80.1500 0.0 80.0 0.0 2.0000 $ 2.0000
Transfer shipped from WH to store w ith w eight of 160.2 LBS 720.0 0.0 0.0 2.0039 $ 2.0038 18.0 0.0 0.0 80.1556 0.0 0.0 80.0 2.0025 $ 2.0038
Transfer received at store, no w eight on receipt 720.0 0.0 0.0 2.0039 $ 2.0038 18.0 0.0 0.0 80.1556 80.0 0.0 0.0 2.0025 $ 2.0038

Non-Simple Pack Ordering

Assum ptions: - Standard UOM = EA
- Cost and Selling UOM = LBS
- Net Weight per Case = 80 LBS
- Case Quantity = 40 eaches
- Unit Cost = $1 per LB

Warehouse Store
Com ponent Item Com ponent Item

Transaction SOH On Order Reserved Avg Weight Avg Cost SOH Expected In Transit Avg Weight Avg Cost
PO created for 10 cases of component item @ $80 per case 0.0 400.0 0.0 2.0000 $ 2.0000 0.0 0.0 0.0 2.0000 2.0000
Shipment for 10 cases received at WH for 803 LBS 400.0 0.0 0.0 2.0075 $ 2.0075 0.0 0.0 0.0 2.0000 2.0000

PO created for 10 cases @ $80/case to WH 400.0 400.0 0.0 2.0075 $ 2.0075 0.0 0.0 0.0 2.0000 2.0000
Shipment for 10 cases received at WH w ithout w eight 800.0 0.0 0.0 2.0038 $ 2.0038 0.0 0.0 0.0 2.0000 2.0000

Transfer created to ship 2 cases to store 800.0 0.0 80.0 2.0038 $ 2.0038 0.0 80.0 0.0 2.0000 2.0000
Transfer shipped from WH to store w ith w eight of 160.2 LBS 720.0 0.0 0.0 2.0039 $ 2.0038 0.0 0.0 80.0 2.0025 2.0038
Transfer received at store, receipt based on box label w eight** 720.0 0.0 0.0 2.0039 $ 2.0038 0.0 0.0 0.0 2.0025 0.0000

20 Oracle Retail Merchandising System Catch Weight Overview

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 © 2013, 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, JD Edwards, PeopleSoft, and Siebel are registered trademarks of Oracle
Corporation and/or its affiliates. Other names may be trademarks
of their respective owners.