Warehouse Operations

Warehouse Operations

This chapter describes how incoming stock is received into the warehouse and how customer orders are processed. It also covers other supporting processes usually found in an eCommerce warehouse, some of which are crucial to the smooth running of the fulfilment operation.

Goods-In

The 'Goods-in' operation involves a Delivery of stock into the warehouse.

Deliveries are usually planned and expected. An organisation will place a Purchase Order with a supplier, detailing exactly what items and quantities are required. Supplier purchase orders can be imported into OrderFlow and used to check-in the associated delivery.

If no purchase order has been imported into OrderFlow, it is still possible to describe the contents of a delivery before it is received by using an Advanced Shipping Notification (ASN). An ASN can be used to specify what is thought to be in a delivery before it arrives.

The difference between a purchase order and an advanced shipping note within OrderFlow is that a supplier purchase order can be associated with multiple deliveries while an advanced shipping note is always used to describe a single delivery.

The OrderFlow Goods-In process will reconcile the details of what received with the associated purchase order or ASN and produce a discrepancy report where there are differences between what was expected and what was received.

It is also possible to create a delivery on OrderFlow 'on spec', without it be related to either a purchase order or an advanced shipping note. Where this is done no discrepancy report can be produced.

This section details how OrderFlow supports the Goods-in process.

Purchase Order Creation

Purchase orders cannot be created within OrderFlow but are typically created within the accounts environment or by dedicated purchasing systems. Supplier purchase orders can be imported into OrderFlow using its import framework. This framework allows supplier purchase order documents, typically in XML, spreadsheet or comma-separated value (CSV) format, to be imported into OrderFlow. (More details of this framework can be found in the Importing Guide.)

The import of purchase orders can be driven by a file-based integration with an accounting or Enterprise Resource Planning (ERP) system, or they can be transferred via FTP to a file location readable by OrderFlow. Additionally, the desktop interface to OrderFlow allows a user to submit a file (or the contents of a file) as a purchase order.

In OrderFlow, the result will be a Purchase Order entity, attached to which will be one or more Purchase Order Line entities. These can be seen under Warehouse --> Purchase Orders in the desktop interface. The Purchase Order Detail page shows various attributes of the purchase order, such as the supplier and the reference they use to identify the purchase order. It also shows the lines within the purchase order, any associated deliveries that have already been received against it, and the delivery receipts at a line-level:

A Purchase Order can be of the following types:

• Supplier - placed against one of the organisation's suppliers.
• Bulk Transfer - transfer of stock from another warehouse, within the same organisation.

A Purchase Order Line holds an expected quantity against a referenced product, plus the outstanding quantity of units not yet delivered. It can additionally hold an external reference, typically supplied by an external system.

Advanced Shipping Note Creation

As with purchase orders, Advanced Shipping Notes (ASNs) can be imported into OrderFlow using the import framework, in XML, spreadsheet or CSV format.

Additionally, ASNs can be created using the desktop user interface (under Warehouse --> ASNs --> New).

In OrderFlow, the result will be an Advanced Shipping Note entity, containing one or more Advanced Shipping Note Line entities.

These can be seen under Warehouse --> ASNs in the desktop interface. The Advanced Shipping Note Detail page shows various attributes of the ASN, such as the supplier and the number of lines it contains. It also shows the lines within the ASN, any associated delivery, and any discrepancies between the ASN and the actual delivery:

An Advanced Shipping Note can be of the following types:

• Stock - all items in the ASN must be stock items, i.e. when delivered they will be put away into stock locations.
• Container-to-stock - items are delivered against the ASN in containers, whose contents are not confirmed, so will need to be scanned before being put away into stock locations.
• Order - all items in this ASN are intended to be matched with pending orders as part of the Goods-In process, the incoming items will be packed and despatched rather than being put away into stock locations.
• Unrestricted - the delivery for this type of ASN is not restricted to any particular type.

An Advanced Shipping Note Line holds a quantity against a referenced product, and may also hold a (container) location reference or an order reference, depending upon the ASN type.

Delivery Creation

When a lorry makes a delivery at the warehouse door, OrderFlow expects a user to create a Delivery entity. How they go about creating a Delivery entity depends on whether the user can identify the associated supplier purchase order or ASN.

If the delivery driver supplies paperwork with a purchase order reference with the delivery, then the user should find the purchase order on the system, and create a delivery from this (by using a link on that purchase order's detail page).

Similarly, if the delivery driver supplies paperwork with an advanced shipping note reference with the delivery, then the user should find that ASN on the system, and create a delivery from this (by using a link on that ASN's detail page).

Alternatively the user can search the pending supplier POs and ASNs by supplier and product to find the associated supplier purchase order or ASN.

These actions automatically associate the new delivery with the PO or ASN accordingly. (A user can create a delivery that is independent of any PO or ASN under Warehouse --> Deliveries --> New.)

In OrderFlow, the result will be a Delivery entity, attached to which will be one or more Delivery Line entities. These can be seen under Warehouse --> Deliveries in the desktop interface. The Delivery Detail page shows various attributes of the delivery, such as the supplier and any associated purchase order or ASN. It also shows the lines within the delivery:

In OrderFlow, a delivery can be one of the following 'standard' types:

• Stock (with deferred save) - the default delivery type, where all products and quantities have to be supplied (to create delivery lines) and the delivery applied before stock is credited to the warehouse.
• Stock (with incremental save) - similar to deferred save, but stock can be credited to the warehouse during the check-in process, instead of waiting until all product/quantity combinations have been supplied.
• Quarantine - similar to deferred save, but stock must be credited to a quarantine location; that is, a location whose logical type has the 'quarantine' flag set. This will credit the stock into the warehouse but will not increase the 'available' stock figure for the items received.
• Container to stock - stock is initially credited as 'unconfirmed', then a verification process must be followed before the delivery can be applied.
• From licence plates - creates one or more temporary licence plate locations that can then be used to route the incoming stock into several different warehouse workflows, typically via the handheld user interface.

Or it can be one of the following 'cross-dock' types. ('Cross-docking' is the process of using delivered stock to fulfil orders directly, without putting that stock away to warehouse storage locations and then subsequently picking it.)

• ASN cross-dock - stock is immediately cross-docked from a delivery that was created from an Order-typed Advanced Shipping Note.
• Purchase Order cross-dock - stock is immediately cross-docked to a shipment that has been associated with the same supplier purchase order that the delivery has been associated with. (Shipments can be associated with purchase orders by other means - see the Despatch Operations section for more details.)
• Licence Plate Purchase Order cross-dock - similar to the Purchase Order cross-dock type, but uses a licence plate mechanism to process the stock.
• Out-of-stock cross-dock - incoming stock is immediately cross-docked with existing customer shipments that have the state 'out of stock'. The delivery does not need to be backed by an ASN or a purchase order.
  Instead, 'out of stock' that are out of stock are automatically matched to use the delivered stock most effectively. Incoming stock that is matched with single line shipments can be packed immediately, incoming stock that is matched with multi-line orders will be moved to a consolidation location.

A Delivery has a lifecycle, defined by the following state transition:

Delivery Line entities will ultimately be created and attached to the Delivery entity, but exactly when these are created depends on the Delivery type (as described above).

A Delivery Line holds the received quantity against a referenced product, and also references the location in which the stock will be credited. Instead of a 'type', a delivery line has a variation, that determines how it will be processed. Delivery Line 'variations' are set by choices made during delivery creation, and can take the following values:

• Just-in-time (JIT) - the delivered units will either be cross-docked, or routed to a consolidation location, in order to fulfil an order whose stock has been ordered from a supplier just-in-time (rather than already held in
  the warehouse).
• Damaged - the delivered units will be routed to a location reserved to hold damaged goods.
• Bulk - the delivered units will be routed to bulk storage locations, using a licence plate mechanism.
• Incoming to stock - the delivered units will be put away to stock, after first being credited to an incoming location; that is, a location whose logical type has the 'incoming' flag set.
• Direct to stock - the delivered units will be put away to stock directly, i.e. without first being credited to any other location.

Reconciliation and Discrepancies

Deliveries that reference purchase orders or advanced shipping notes can be reconciled against them, after the delivery has been received.

Reconciliation is the process of checking what was expected against what was actually received. It is an essential process if the discovery of any discrepancies between these values requires further action, such as pursuing a refund from the supplier that sent the delivery.

When a delivery is applied, OrderFlow will automatically reconcile it against any associated ASN, and prominently display any discrepancies to the user. It will do the same with any associated PO, but hold these discrepancies against the PO once it has been applied. (This is because a Purchase Order may be delivered across many deliveries.)

Discrepancies and other delivery metrics can be extracted from the system for management purposes using the reporting framework.

Processing Delivered Stock

Stock that has been checked-in from a delivery will typically be credited to an incoming location, generally within the 'Goods_in' area of the warehouse. In order to efficiently use that stock, it then needs to be moved to somewhere more accessible, and separated according to product. This allows other warehouse staff to pick stock more quickly and easily, without getting in the way of delivery staff (and each other).

Put-away

OrderFlow supports several different strategies for processing delivered stock. The simplest of these is to immediately put the stock away to separate (usually known) stock locations when creating the incoming delivery. This may be appropriate for small deliveries but becomes very inefficient as the number of SKUs in a delivery increases.

As described in the previous section larger deliveries are typically moved to the 'Goods_in' area of the warehouse to await put-away.

Put-away is the process of moving incoming stock from an 'incoming' location to a storage location. The system can create a stock move task to direct a warehouse staff member to move the correct quantities of stock from the delivery's incoming location to the appropriate target locations for each product in the delivery. If there is no known stock location for a product then OrderFlow will automatically select a new one, based on its knowledge of the locations on the system. Such a task can either be created manually, or on a scheduled basis.

To manually create a putaway task, navigate to Warehouse --> Tasks --> New and select the 'Default Putaway' task type. There is a short-cut link to this page on the delivery detail page, once a delivery has been applied:

When a delivery does not use an incoming location, the stock needs to be put away to stock locations while processing the delivery. This can be less efficient as it will not necessarily take advantage of a shortest route through the warehouse, i.e. several trips between the delivery area and the rest of the warehouse may need to be taken.

Sometimes, a delivery may need to be put-away into a quarantine location, so that it needs to undergo a manual check before being transferred to other warehouse locations.

Cross-docking

OrderFlow supports more sophisticated delivery processing options, with the aim of reducing the need to double-handle stock. "Double-handling" of stock means moving it twice, for example moving it once to put away the stock to a stock location, then again to immediately pick the stock to pack a customer shipment. Instead, the stock could be moved straight to the packing desk, if it is known that it will fulfil outgoing shipments. This process is called cross-docking.

Cross-docking is most effective for single-line shipments, the handheld process for receiving the incoming delivery can be configured to match incoming stock with out-of-stock shipments, causing the required items to be passed to a packer instead of being put-away to stock.

Consolidation

For multi-line shipments, and single-line shipments whose order line has a quantity greater than the available stock quantity, if double-handling of stock is to be avoided, then delivered stock can be routed to consolidation locations.

A consolidation location is used for temporary storage of some of the stock for a shipment, until the rest of the stock is sourced. Note that the rest of the stock could already be in the warehouse, so the consolidation process does not always have to involve recently-delivered stock.

OrderFlow supports routing delivered stock to consolidation locations by matching multi-line shipments that have outstanding lines for the delivered stock, and either using their existing consolidation locations, or using new consolidation locations (in the case where the delivered stock is the first stock available in the multi-line shipment).

If the delivery is of type 'From licence plates', OrderFlow routes the correct stock to consolidation locations using its workflow processing function, described in the Workflow Processing section below.

To process such a delivery, a user should navigate to Home --> Receipt --> LP to Incoming on the handheld interface, select the location in which they are working and scan the licence plate that was created as part of the delivery. Selecting the Just In Time option (then scanning the consolidation area or location in which they want to start), they can then start scanning products from the incoming delivery.

If OrderFlow matches products to consolidating shipments, it will direct the user to move the required number of units to the correct consolidation location, as illustrated in the following screenshot (which is suggesting that 3 units of product ipod5 should be moved to consolidation location consolidation_1, and another 3 units should be moved to consolidation location consolidation_11):

Note that the consolidation process can also be used to bring together stock from different area of the warehouse or from different picking processes before all the items required for a shipment are presented to the packer.

OrderFlow drives the cross-docking and consolidation processes using its workflow processing function, described in the Workflow Processing section below.

Workflow Processing

It is quite probable that not all of the delivered stock would fall into one of the pre-defined categories described above, so OrderFlow supports a configurable delivery process that allows the user to route different products to different workflows, i.e. some stock to consolidation, some to packing (cross-docking), some to storage, some to quarantine, and some to a location to hold damaged stock.

After dealing with the stock for consolidation, to reduce the distance that the delivery-processing user has to travel, OrderFlow directs them to place stock for packing, stock for storage, damaged stock and unwanted stock in different footprint locations. These are locations local to the user that can be subsequently processed independently, allowing the user to process the delivery quickly and efficiently. Dealing with the stock needed for consolidation and cross-docking first means that shipments will be despatched sooner.

As described above, to invoke workflow processing, a user should navigate to Home --> Receipt --> LP to Incoming on the handheld interface, select the location in which they are working and scan the licence plate that was created as part of the delivery. Selecting the Just In Time option (then scanning the consolidation area or location in which they want to start), they can then start scanning products from the incoming delivery.

The following screenshot shows a handheld user being directed to move 3 units of product ipod5 to a packing footprint location, and another single unit to a stock (i.e. storage) footprint location:

Note

If the warehouse has many consolidation locations spread over a large area, a user can select where in this area they want to work. This helps reduce congestions when many warehouse staff are accessing consolidation locations concurrently.

Returns

Customers buying goods via e-commerce will usually have the option to return those goods if they are not happy with them for any reason. A returns address will usually be present on the despatch note sent with an outgoing shipment, or if not, customers can find out where to return items to from an organisation's website. Either way, that return address may end up being a warehouse under OrderFlow's control, and as such, OrderFlow provides functionality that supports the receipt of returned goods into the warehouse.

Authorisation

A return can be 'pre-authorised' or not. 'Pre-authorised' means that the return has been planned, usually by a customer services business function, before it is received by the warehouse. The authorisation process often involves the customer being given a "returned merchandise authorisation" or "RMA" which they are asked to quote on paperwork included with the returned items.

A returns authorisation can be created through the OrderFlow desktop interface or by an external system (typically the customer service platform) through the OrderFlow API.

Unplanned returns arrive at the warehouse without warning, possibly because the courier has been unable to find the delivery address or the recipient refused to accept delivery, or simply because the returns policy does not require the customer to notify the business before returning unwanted items.

Organisations may choose to treat pre-authorised and unauthorised returns differently, i.e. they may scrutinise the goods more closely for unauthorised returns. OrderFlow presents two menu options to create pre-authorised and unauthorised returns separately:

Return Creation

To create both pre-authorised and unauthorised returns, the user is required to complete a form that details the following:

• Return type, i.e. authorised / unathorised / unknown
• Organisation
• Channel (if known)
• Order reference
• Return date (if known)
• Any notes, e.g. detailing any discussion with the customer

For pre-authorised returns, a customer service user of OrderFlow will be able to establish these details directly from the customer conversation. Otherwise, a warehouse operator should be able to establish these details from any paperwork accompanying the returned goods.

Once a return has been created, its detail page will look something like this:

Note that there are no return lines at present - these only get created when stock is checked into OrderFlow following actual receipt of the returned goods.

Return Check-in

When the goods arrive at the warehouse door, the user that processes the returned parcel will identify it as a return based on the paperwork that accompanies it. They can then search the existing returns, using the order reference on the paperwork. If this information is missing then the product can be used to search for a pre-authorised return. (If no return is found on OrderFlow, the warehouse user can create one as previously described.)

From the return item detail page, return lines can be added to the return, either by using the links alongside each order line, or by selecting to 'Add' a return line. (This behaviour is controlled by the "Return Lines Linked to Original Order" property.)

While creating a return line, the user can specify the product, quantity, the type of return line (i.e. stock / quarantine / destroy / to supplier), the reason for return (if available from the paperwork), and the condition of the returned item(s). (The return reasons and conditions available are both controlled by application properties.) Additionally, the user may be required to specify whether to proceed with a refund or not (based on configuration), and any notes can be added by the user at this point:

Additionally, an image can be added to a return line, in order to capture the state of the returned item, for example.

Once all the required lines have been added to a return, it can be applied. This credits the returned stock to the appropriate locations in the warehouse. (The default locations for each return type are held in application properties, or supplier-specific locations may be configured.) The stock can then be returned to the correct location as part of a putaway task (see the Put-away section), or returned to the original supplier of the goods.

Return Entities

The result of an applied return process will be a Return Item entity, attached to which will be one or more Return Line entities. These can be seen under Warehouse --> Returns in the desktop interface.