Oracle Retail Merchandising

Catch Weight Overview

September 2020 | Release 14.0+

Copyright © 2020, Oracle and/or its affiliates
Disclaimer
This document in any form, software or printed matter, contains proprietary information that is the exclusive property of
Oracle. Your access to and use of this confidential material is subject to the terms and conditions of your Oracle software
license and service agreement, which has been executed and with which you agree to comply. This document and
information contained herein may not be disclosed, copied, reproduced or distributed to anyone outside Oracle without
prior written consent of Oracle. This document is not part of your license agreement nor can it be incorporated into any
contractual agreement with Oracle or its subsidiaries or affiliates.
This document is for informational purposes only and is intended solely to assist you in planning for the implementation
and upgrade of the product features described. 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 in this document remains at the sole discretion of Oracle.
Due to the nature of the product architecture, it may not be possible to safely include all features described in this document
without risking significant destabilization of the code.
.

1 Catch Weight Overview Release 14.0+

Copyright © 2020, Oracle and/or its affiliates
TABLE OF CONTENTS
Disclaimer 1
Catch Weight 3
Item Data Setup 3
Component Item Setup 3
Setup by Type 5
Pack Setup 5
Setup by Type 7
Inventory Management 7
Inventory Transactions 9
Non-Catch Weight Weighted Items 14
Integrating with RWMS and SIM/SIOCS 14

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

2 Catch Weight Overview Release 14.0+

Copyright © 2020, Oracle and/or its affiliates
Catch Weight
Catch Weight functionality allows for the ordering and management of items that vary by weight from one instance of an
item to the next. Because of this, on receipt of a purchase order the weight of the item is “caught” or captured. Examples of
this are primarily in the grocery industry, where items such as fresh produce, deli, butchery, and prepackaged cheese and
meat, are purchased by weight and may be sold by weight or as individual products (eaches). Catch Weight items are usually
costed by weight and have an average weight maintained for the items, which is used by any transactions involving the
items where a weight is not captured, such as shipments from a store where scales are often not available. Additionally, the
way that catch weight items are purchased and invoiced by suppliers can differ. For some items, payment is based on the
weight ordered and for others payment is based on the weight received.
Merchandising supports four different types of catch weight items, which can be ordered by simple pack or by components.
These different types are outlined in more detail in this document, including how setup for these items differs from other
items in Merchandising, 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 Merchandising 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. Merchandising 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 (for example, a single banana) as well as the assumed simple packs that are created to support ordering
(for example, case of bananas).

Component Item Setup

Catch weight items are set up as regular items in Merchandising 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 attributes 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 Merchandising.

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.

Sale Type
In addition, 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 setup 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 setup 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 (for example, bananas, deli meat) should have a standard UOM
equal to a weight, such as lbs. or kg. Items designated as variable weight eaches (for example, 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 that have a UOM other than EA that are not flagged as
Catch Weight. See the section on Non-Catch weight Weighted Items below.

3 Catch Weight Overview Release 14.0+

Copyright © 2020, Oracle and/or its affiliates
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 (for example, one case is 50 lbs or 50 kg). This UOM would be systematically set to the same UOM as
defined in those case dimensions (for example, lbs or kg). See also the Case Level Dimensions section below. This field is not
displayed in Merchandising 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. Merchandising 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.

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 & 2, see below for the definition of the various types) or in terms of assumed eaches (for types 3 & 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: Merchandising uses only those dimensions defined against the dimension object Case.
In situations where the dimension for a single unit (EA) are required, the case-level
dimensions will be divided by the defined case pack size.

4 Catch Weight Overview Release 14.0+

Copyright © 2020, Oracle and/or its affiliates
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 at the item/zone level when the
component item is initially created and then maintained in Pricing thereafter.

Setup by Type
CATCH WEIGHT CATCH WEIGHT CATCH WEIGHT CATCH WEIGHT
TYPE 1 TYPE 2 TYPE 3 TYPE 4

Order Type Fixed Weight Variable Weight Fixed Weight Variable Weight

Sales Type Loose Weight Loose Weight Variable Weight EA Variable 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 Meat/Cheese Pre-packaged Cheese Pre-packaged 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 attributes are set at the item level for simple packs that have been flagged as catch weight. These are held on the
ITEM_MASTER table.

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.

5 Catch Weight Overview Release 14.0+

Copyright © 2020, Oracle and/or its affiliates
 Note: For purposes of this document, it is assumed that simple packs are not sellable.

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 Invoice Matching 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.

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: Merchandising uses only those dimension 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.

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 (for example, a case contains between 14 kg and 16 kg). In Merchandising this is informational only and is not
used for validation during the shipping and receiving processes. However, Merchandising does publish this information for
use in external systems.

6 Catch Weight Overview Release 14.0+

Copyright © 2020, Oracle and/or its affiliates
Setup by Type
CATCH WEIGHT CATCH WEIGHT CATCH WEIGHT CATCH WEIGHT
TYPE 1 TYPE 2 TYPE 3 TYPE 4

Order Type Fixed Weight Variable Weight Fixed Weight Variable Weight

Sales type n/a n/a n/a n/a

Standard UOM EA EA EA EA

Cost UOM EA Weight EA Weight

Simple Pack Item Quantity Weight Weight EA EA

Case Pack 1 1 1 1

Set Case Dimensions? Optional Required Required Required

Tolerance Required? N Y N Y

Examples Bananas Deli Meat/Cheese Pre-packaged Pre-packaged Meat

Cheese

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
EA, which includes the simple pack level for all catch weight types and at the component item level for types 3 and 4.
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 will always be used when ordering. The nominal
weight is defined during the simple pack setup as the net weight of the simple pack.

7 Catch Weight Overview Release 14.0+

Copyright © 2020, Oracle and/or its affiliates
Weighted Average Cost
Like other types of items, receipts into a location can impact the weighted average cost (WAC). When ordering by simple
pack, the WAC for catch weight component items is impacted by the actual weight of the simple pack that is recorded for
various inventory transactions, as well as the pack’s order type, since WAC is not calculated for pack items in Merchandising.
WAC is always held in terms of the component item’s standard UOM, not cost UOM, as it pertains to the value of owned
inventory. However, the cost used to update WAC varies based on the type of transaction. For example, a PO receipt will use
the Cost UOM to value the receipt, whereas a transfer receipt will use the WAC of the shipping location. The below examples
show how WAC is updated for each type for PO receipts.
For Type 1 items (for example, bananas), WAC is updated on receipt as follows:
(Total Weight Ordered1 * Cost per Cost UOM) + (Current Owned Weight * Current WAC)
Total Weight Received + Current Owned Weight

For Type 2 items (e.g. 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 (e.g. pre-packaged cheese) received as simple packs, WAC is updated on receipt as follows:
(Total Weight Ordered * Cost per Cost UOM) + (Current Owned Eaches * Current WAC)
Total Eaches Received + Current Owned Eaches

For Type 4 items (e.g. 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 the warehouse, prior to a receipt, there is a total weight of 20 lbs and a current WAC of $1.25. 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. On receipt of 101 lbs of total weight, the
WAC would be updated as follows:
 Cost of total weight ordered = 10 cases * 10 lbs * $1 = $100
 Cost of current weight owned = 20 lbs * $1.25 = $25
 New weighted average cost = ($100 + $25)/(101 lbs + 20 lbs) = $1.0331 per pound
Type 4 Example:
At the warehouse, prior to receipt, there are 10 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. The current
WAC for the component items is $1.25 per pound. If one pack (20 EA) 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:
 Cost of total weight received = 22 lbs * $1 = $22
 Cost of current weight owned = 10 cases * 20 lbs * $1.25 = $250
 New weighted average cost = ($22 + $250)/(20 EA + 200 EA) = $1.2364 per EA

1
Based on nominal weight

8 Catch Weight Overview Release 14.0+

Copyright © 2020, Oracle and/or its affiliates
Inventory Transactions
The table below outlines the expected behavior in Merchandising 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. There are two exceptions to this:
 Purchase order receipts, as nominal weight is used if actual weight is not included in the receipt details.
 Transfer receipts for simple packs and components of type 3 or 4, as the weight that was shipped is always
used. This is due to the assumption that most stores do not weigh on receipt, so any weight sent with the
receipt is ignored.
 Average weight should be recalculated for every inventory transaction, where applicable. Type 1 and 2 items do not
have an average weight maintained at the component item level – only for the pack.
 When transfers or RTVs are created and approved, nominal weight is used to reserve the inventory, rather than
average weight, as average weight could change between the time the transaction is 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.

Purchase Orders

COMPONENT ITEM SIMPLE PACK

All Types If a component item is ordered, the order quantity
can be entered in terms of standard UOM (weight or
EA), 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 in terms of the
cost and cost UOM defined for the component
item’s 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 on the order is defaulted in terms of the cost
and cost UOM defined for the pack item’s
supplier/country.

PO Receiving

COMPONENT ITEM SIMPLE PACK

Type 1 Stock on hand is updated based on what is sent in the
quantity field on the receipt, as this is assumed to be
the actual weight received. If weight is included in
the receipt details in a separate field, it is ignored.
There is no average weight maintained for type 1
component items.
WAC is calculated using the nominal weight to derive
the cost of the receipt, but the actual weight received
is used as the divisor.
Pack on hand is updated based on the quantity of
packs received. The component item’s stock on
hand is updated based on the actual weight
received (or nominal weight, if a weight is not
provided).
Average weight for the pack is also updated based
on the actual weight received (or nominal weight, if
a weight is not provided). The component item’s
average weight is not maintained for this type.
WAC is calculated for the component item using
the nominal weight to derive the cost of the
receipt, but the actual weight received is used as
the divisor.

9 Catch Weight Overview Release 14.0+

Copyright © 2020, Oracle and/or its affiliates
 COMPONENT ITEM SIMPLE PACK

Type 2 Stock on hand is updated based on what is sent in the Pack on hand is updated based on the quantity of
quantity field on the receipt, as this is assumed to be packs received. The component item’s stock on
the actual weight received. If weight is included in hand is updated based on the actual weight
the receipt details in a separate field, it is ignored. received (or nominal weight, if a weight is not
provided).
There is no average weight maintained for type 2
component items. Average weight for the pack is also updated based
on the actual weight received (or nominal weight, if
WAC is calculated using the received weight to derive
a weight is not provided). The component item’s
the cost of the receipt and as the divisor.
average weight is not maintained for this type.
WAC is calculated for the component item using
the received weight to derive the cost of the
receipt and as the divisor.

Type 3 Stock on hand is updated based on what is sent in the Pack on hand is updated based on the quantity of
quantity field on the receipt in terms of eaches.
Average weight for the component item is also
updated based on the actual weight received (or
nominal weight, if a weight is not provided).
WAC is calculated using the nominal weight to derive
the cost of the receipt, with the eaches received used
as the divisor.
packs received. The component item’s stock on
hand is also updated based on the quantity
received * the quantity of the item in the pack.
Average weight for the pack and component item
are both updated based on the actual weight
received (or nominal weight, if a weight is not
provided).
WAC is calculated for the component item using
the nominal weight to derive the cost of the
receipt, with the eaches received used as the
divisor.

Type 4 Stock on hand is updated based on what is sent in the Pack on hand is updated based on the quantity of
quantity field on the receipt in terms of eaches.
Average weight for the component item is also
updated based on the actual weight received (or
nominal weight, if a weight is not provided).
WAC is calculated using the received weight to derive
the cost of the receipt, with the eaches received used
as the divisor.
packs received. The component item’s stock on
hand is also updated based on the quantity
received * the quantity of the item in the pack.
Average weight for the pack and component item
are both updated based on the actual weight
received (or nominal weight, if a weight is not
provided).
WAC is calculated for the component item using
the received weight to derive the cost of the
receipt, with the eaches received used as the
divisor.

Invoicing
Invoice Matching does all processing based on the UOM on the order. So, for variable weight packs and variable weight
component items (type 2 and 4), a conversion is done for the cost based on the weight received, pack quantity and cost
UOM to derive the cost in terms of the pack eaches received. For fixed weight packs, invoicing is done like for non-catch
weight items, based on the order quantity and cost only without the need for conversion.

COMPONENT ITEM SIMPLE PACK

Type 1 Invoicing is based on the nominal weight ordered, not Since invoicing is based on the nominal weight
the received weight, because for this type of item, the ordered, not the received weight, for this type of
item, the retailer is paying the supplier based on a

10 Catch Weight Overview Release 14.0+

Copyright © 2020, Oracle and/or its affiliates
 COMPONENT ITEM
retailer is paying the supplier based on a fixed
weight.
Type 2 Invoicing is based on the actual received weight,
which might be more or less than ordered, because
for this type of item, the retailer is paying the supplier
based on a variable weight.
Type 3 Invoicing is based on the nominal weight ordered, not
the received weight, because for this type of item, the
retailer is paying the supplier based on a fixed
weight.
Type 4 Invoicing is based on the actual received weight,
which might be more or less than ordered, because
for this type of item, the retailer is paying the supplier
based on a variable weight.
Transfers
COMPONENT ITEM
Type 1 and 2 When the transfer is approved, reserved quantity will
be updated based on nominal weight. In transit
updates, as well as updates to stock on hand at both
locations, will consider the actual weight shipped. For
this type of item, the weight is assumed to be sent in
the quantity field for integrations, as that is the
standard UOM. The separate weight field will be
ignored.
There is no average weight maintained for type 1
and 2 component items.
WAC is calculated using the shipped weight to derive
the cost of the receipt and as the divisor.
2 If the receiving location is a warehouse. Pack on hand is not managed for stores .
11 Catch Weight Overview Release 14.0+
Copyright © 2020, Oracle and/or its affiliates
SIMPLE PACK
fixed weight of the pack and weight is not
considered.
Invoicing is based on the actual received weight,
which might be more or less than ordered, because
for this type of item, the retailer is paying the
supplier based on a variable weight.
Invoicing is based on the nominal weight ordered,
not the received weight, because for this type of
item, the retailer is paying the supplier based on a
fixed weight.
Invoicing is based on the actual received weight,
which might be more or less than ordered, because
for this type of item, the retailer is paying the
supplier based on a variable weight.
SIMPLE PACK
When the transfer is approved, reserved quantity
for the component item will be updated based on
the nominal weight of the pack. In transit updates
for the component item, as well as updates to stock
on hand for both locations, will consider the actual
weight shipped, if provided. If not provided, the
average weight for the pack at the shipping
location is used. Upon receipt, if a weight is
included, it is ignored; the shipped weight is always
used to prevent discrepancies.
Pack on hand is updated based on the quantity of
packs shipped and received at both locations2.
Average weight for the pack is updated on
shipment for both locations, based on either the
actual shipped weight, or the shipping location’s
average weight, if a weight is not provided. If a
weight is included on receipt, it is ignored. The
component item’s average weight is not
maintained for this type.
WAC is calculated for the component item at the
receiving location using the shipped (or average)
weight to derive the cost of the receipt and as the
divisor. The WAC at the shipping location is not
updated.
 COMPONENT ITEM
Type 3 and Reserved, expected, in transit, and stock on hand for
4 the component item will be updated based on the
quantity only.
Average weight is updated on shipment for both
locations based on either the actual shipped weight,
or the shipping location’s average weight, if a weight
is not provided. If a weight is included on receipt, it is
ignored.
WAC is recalculated using the shipped quantity to
derive the cost of the receipt.
Type 1 and 2 When the transfer is approved, reserved quantity will
be updated based on nominal weight. In transit
updates, as well as updates to stock on hand at both
locations, will consider the actual weight shipped. For
this type of item, the weight is assumed to be sent in
the quantity field for integrations, as that is the
standard UOM. The separate weight field will be
ignored.
There is no average weight maintained for type 1
and 2 component items.
WAC is calculated using the shipped weight to derive
the cost of the receipt and as the divisor.
Type 3 and Reserved, expected, in transit, and stock on hand for
4 the component item will be updated based on the
quantity only.
Average weight is updated on shipment for both
locations based on either the actual shipped weight,
or the shipping location’s average weight, if a weight
is not provided. If a weight is included on receipt, it is
ignored.
WAC is recalculated using the shipped quantity to
derive the cost of the receipt.
12 Catch Weight Overview Release 14.0+
Copyright © 2020, Oracle and/or its affiliates
SIMPLE PACK
Reserved, expected, in transit, and stock on hand
for the pack and component item will be updated
based on the transfer quantity only.
Average weight for the pack and the component
item are updated on shipment for both locations,
based on either the actual shipped weight, or the
shipping location’s average weight, if a weight is
not provided. If a weight is included on receipt, it is
ignored.
WAC is recalculated for the component item using
the shipped quantity to derive the cost of the
receipt.
When the transfer is approved, reserved quantity
for the component item will be updated based on
the nominal weight of the pack. In transit updates
for the component item, as well as updates to stock
on hand for both locations, will consider the actual
weight shipped, if provided. If not provided, the
average weight for the pack at the shipping
location is used. Upon receipt, if a weight is
included, it is ignored; the shipped weight is always
used to prevent discrepancies.
Pack on hand is updated based on the quantity of
packs shipped and received at both locations
Average weight for the pack is updated on
shipment for both locations, based on either the
actual shipped weight, or the shipping location’s
average weight, if a weight is not provided. If a
weight is included on receipt, it is ignored. The
component item’s average weight is not
maintained for this type.
WAC is calculated for the component item at the
receiving location using the shipped (or average)
weight to derive the cost of the receipt and as the
divisor. The WAC at the shipping location is not
updated.
Reserved, expected, in transit, and stock on hand
for the pack and component item will be updated
based on the transfer quantity only.
Average weight for the pack and the component
item are updated on shipment for both locations,
based on either the actual shipped weight, or the
shipping location’s average weight, if a weight is
not provided. If a weight is included on receipt, it is
ignored.
WAC is recalculated for the component item using
the shipped quantity to derive the cost of the
receipt.
Inventory Adjustments
COMPONENT ITEM
Type 1 and 2 For adjustments made at the component item level,
the adjustment is assumed to be in terms of weight.
Type 3 and For adjustments made at the component item level,
4 the adjustment is made in terms of quantity.
Average weight for is updated if an actual weight is
included.
Return to Vendor
COMPONENT ITEM
Type 1 and 2 When the RTV is approved, RTV quantity will be
updated based on nominal weight. Shipment
updates will consider the actual weight shipped. For
this type of item, the weight is assumed to be sent in
the quantity field for integrations, as that is the
standard UOM. The separate weight field will be
ignored.
There is no average weight maintained for type 1
and 2 component items.
The value of the shipment is based on the location’s
WAC and the shipped weight, unless a specific RTV
cost has been designated.
Type 3 and RTV Reserved and stock on hand updates for the
4 component item will be based on quantity only.
Average weight for is updated on shipment based
on either the actual shipped weight, if included in the
shipment.
The value of the shipment is based on the location’s
WAC and the shipped quantity, unless a specific RTV
cost has been designated.
13 Catch Weight Overview Release 14.0+
Copyright © 2020, Oracle and/or its affiliates
SIMPLE PACK
For adjustments made to the pack, the inventory
for the pack is adjusted based on the quantity
indicated for the adjustment.
For the component item, inventory is updated
based on the actual weight, if provided. Otherwise,
the update is calculated based on average weight
for the pack.
Average weight for the pack is also updated based
on either the actual adjusted weight, if provided.
The component item’s average weight is not
maintained for this type.
For adjustments made at both the pack and
component item level, the adjustment is made in
terms of quantity.
Average weight for both the pack and component
items are updated if an actual weight is included.
SIMPLE PACK
For the pack item, on hand is updated based on the
quantity of packs shipped.
For the component item, the initial RTV reservation
will be based on nominal weight, but on shipment
stock on hand is updated based on actual shipped
weight if provided. If a weight is not included, then
average weight for the pack is used.
Average weight for the pack is also updated on
shipment based on the actual shipped weight, if
provided. The component item’s average weight is
not maintained for this type.
The value of the shipment for the component item
is based on the location’s WAC and the shipped
weight, unless a specific RTV cost has been
designated.
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.
Sales

COMPONENT ITEM SIMPLE PACK3

Type 1 and 2 Type 1 and 2 Sales and returns will be in terms of actual weight
as the quantity on the transaction. If the weight
field is populated, it is ignored.
Cost of sales will be calculated as the actual
(average) weight * current WAC.

Type 3 and Type 3 and 4 Sales and returns are expected to be in terms of
4 both eaches and actual weight. If a weight is not
included, then the location’s average weight will be
used. Average weight for is updated if an actual
weight is included.Cost of sales will be based on
quantity sold * component WAC.

Non-Catch Weight Weighted Items

It is possible to create an item 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 like bulk candy or nuts, which are often ordered and sold by weight, but usually do not
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/SIOCS

As noted above, Merchandising is dependent on receiving weight information from external systems for inventory related
transactions. To support this, the indicators described above are published from Merchandising to RWMS and SIM/SIOCS 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.

3Although 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.

14 Catch Weight Overview Release 14.0+

Copyright © 2020, Oracle and/or its affiliates
Known issues
 Today the catch weight indicator sent by Merchandising 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 Merchandising. This will result in a decreased accuracy of the
average weight calculation in Merchandising, which impacts the cost and retail value of inventory in the warehouse.
The calculation of weight in RWMS needs to be rationalized with Merchandising average weight functionality.
 Both Merchandising and RWMS have a concept of tolerances, but they are defined differently. Merchandising
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 Merchandising.
 WMS can currently support only one unit of measure for weight versus Merchandising 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/SIOCS Processing of Catch Weight Items

Because most stores don not have scales that are used when receiving product, SIM/SIOCS 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 Merchandising is looking for both a quantity and a weight – which is all catch weight items, except Types 1
& 2 at component level – only a quantity will be sent and Merchandising will use the rules defined above to determine the
weight to be associated with the transaction. For type 1 & 2 component level processing, the weight is expected by
Merchandising in the quantity field. So, SIM/SIOCS users will be required to input some type of weight. It is assumed this
business process be defined by the retailer to determine how this weight is derived in the store.

Known issues:
 Because SIM/SIOCS 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, Merchandising will also use nominal weight for DSD receipts
sent from SIM/SIOCS, 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/SIOCS does not
yet utilize the weights supplied on ASNs for receiving.

15 Catch Weight Overview Release 14.0+

Copyright © 2020, Oracle and/or its affiliates
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 (for example, 50 kg) for a specific cost. However, when sold to a customer, is typically sold by weight. For example, a customer may buy .46 KG of bananas
for $1.00.

Order by Simple Pack

Order by Component Item

17 Catch Weight Overview Release 14.0+

Copyright © 2020, Oracle and/or its affiliates
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.

Order by Simple Pack

Order by Component Item

18 Catch Weight Overview Release 14.0+

Copyright © 2020, Oracle and/or its affiliates
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 cheese 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.

Order by Simple Pack

Order by Component Item

19 Catch Weight Overview Release 14.0+

Copyright © 2020, Oracle and/or its affiliates
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

Non-Simple Pack Ordering

20 Catch Weight Overview Release 14.0+

Copyright © 2020, Oracle and/or its affiliates
CONNECT WITH US
Call +1.800.Oracle1 or visit oracle.com
Outside North America, find your local office at oracle.com/contact

blogs.oracle.com facebook.com/oracle twitter.com/oracle

Copyright © 2020, 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. 0120