Products

Products are one of the key entities within the OrderFlow database. Products are the items which are received into the warehouse via deliveries, get stored in locations, and get sent out in shipments following the receipt of orders into the warehouse.

Product data includes a range of information, such the SKU, descriptive data, pricing data, an image reference, etc.

In addition to the product data typically received from the shopping cart, an additional set of data may be attached to the data which tends to be specific to warehouse-related operations. This data is stored for each product on a site-specific basis using the warehouse product entity. Data included against this entity includes items such as reorder thresholds, replenishment quantities and primary picking locations. Will be discussed in a bit more detail.

In addition to the warehouse product entity, other entities involved in completing a product definition are listed below.

barcodes: allows multiple barcodes to be stored against a product
product attributes: allows for arbitrary values to be set up against specific products
grouped_products: allows for relationships between products, for example for kitted or bundle products

The main entities relating to products are shown in the diagram below.

Product Entities

Further detail on these entities and how they are used follows in the rest of this section.

Product Detail

In general, OrderFlow does not perform the function of the master product repository, this function is typically performed by ecommerce front end software (or 'shopping cart'), or a dedicated merchandising system for more complex environments. However, it is possible within OrderFlow to hold quite a rich set of product data, including physical data (weights and dimensions), pricing information, other other descriptive or classifying information such as image references, categories and product types (see next section).

OrderFlow supports the ingestion of product data through a number of ways:

import via an API integration, typically from a third party system
import via various file system formats, including CSV, MicroSoft Excel (XLS) and XML
direct input via the OrderFlow GUI

The fields that can be stored directly against the product are covered in the OrderFlow File Import Specification document.

Barcodes

In a warehousing environment a product is typically identified by a barcode that can be scanned, either by a special handheld device or by a USB scanner attached to a desktop PC.

OrderFlow supports multiple barcode entries per product. This allows for example for a single product to be received from different suppliers with different barcodes without having to relabel any incoming products.

The administrator can choose also choose to set a primary product barcode.

Warehouse Products

OrderFlow makes a clear distinction between product-related information which will typically be managed off the system (for example, within an eCommerce front end or merchandising system), and product-related information which is more closely related to warehouse operations.

For the latter information set, OrderFlow supports warehouse products. Unlike the basic product definition, which applies across all sites or warehouses within the system, the warehouse product data is specific to a particular site.

The warehouse product entry stores information for a number of purposes.

The warehouse product record is also very useful for environments where a distinction is drawn between picking locations and bulk storage locations. OrderFlow supports replenishment tasks which allow for stock to be moved from bulk storage to picking locations. The key data items which drive this process include:

the replenishment threshold; if stock for a picking location falls below this quantity, the system will trigger a replenishment operation for this product
the target picking quantity. This influences the number of items that will be moved into picking location(s) as part of the replenishment process

Another feature closely associated with the warehouse product entity is the picking type for a product. A product can be configured to be pickable for products from a single location only. This location is known as the primary picking location. Using a primary picking location has the advantage of making picking operations easy to manage. However, more locations are required for warehouses that use primary location-based picking than for those that use multi-location picking.

For products that use primary picking locations, the relevant location needs to be specified for each product.

The warehouse product entry can also be used to drive reordering processes, through the following values:

the reorder threshold; when the available stock quantity in the warehouse falls below this value, the reorder process can be triggered
the reorder quantity, which can be used to govern the reorder increments

Additional data captured against the warehouse product include

the default (bulk) storage location
the replenishment threshold and target quantity for this location

Additionally, certain warehouse product entries can be used to restrict the system to suggesting only certain location types or areas for product putaway.

Grouped Products

Grouped product entries are set up on the system to capture relationships between products.

Key examples of these are product bundles and kitted products.

Bundles are products which are composed using a combination of other products. The bundle product is not represented by a single underlying SKU. Instead, it is represented by a number of underlying SKUs.

Bundles are used for example to capture special offers (e.g. buy one, get one free), as well as related combinations of products. For example, a golf set might be sold as a bundle; here the underlying skus would be a driver, a set of two woods, a set of nine irons and a putter.

Kitted products are products which are constructed or assembled using combinations of other underlying products. The underlying products may or may not be sellable but in either case are still held within the warehouse as independent skus for stock management purposes.

In both cases, grouped product are used to capture the relationship between the products. In more general terms, products that are created or derived using combinations of other products are called composite products. For each of these, the grouped product entries list the number of constituent or underlying products.

OrderFlow is able to implement different rules or behaviour for different types of grouped product relationships. For each type of relationship, there is a grouped product definition configuration entry which controls this behaviour.

Product Types

In a manner similar to locations, each product belongs to a product type, which captures essential features of the product. For example, it can be used to determine whether

the product is a physical entity which needs to stored
the product is independently sellable
the product is based on composites of other problems on the system.

The product types themselves are themselves based on a composition of underlying attributes. Key product attributes are listed below.

Type	Attribute Description
Stock	The product has a physical form. It can be stored in a location, and has a measurable quantity.
Virtual	The product does not have a physical form, so is not subject to stock management processes. Examples are music downloads, gift experiences, etc.
Composite	The product is formed by composing other products. Examples include bundles (composed by defining a single sellable product from multiple underlying products), and manufactured items (created through a manufacturing process).
Sellable	The product can be independently sold.
Stock Notifiable	Indicates that third party systems may be interested in receiving updates on the stock position of the product.

The individual product types that are listed on the system are in fact just compositions based on the above types. A couple of examples are listed below.

Type	Description
Default	A sellable stock-based product, eligible for stock notifications
Virtual	A virtual product, for which no stock is held, but is sellable. No fulfilment for a product of this type is required.
Bundle	A bundle is sellable product which is composed of underlying (typically) stockbased products. It is also a virtual product in the sense that is no physical representation of the bundle sku, only the underlying constituent products.

routing of incoming stock into consolidation locations through a JIT (just-in-time) process will use an incoming to consolidation task
movement of stock from storage to consolidation may involve various tasks, depending on the process used storage to consolidation