Order Processing¶
One of OrderFlow’s most fundamental functions is Order Processing, which includes the pick, pack and despatch of orders.
OrderFlow can process orders from multiple organisations and multiple sales channels within organisations. It can restrict a user’s access to certain organisations and channels, so that users can only see the orders that are relevant to them.
Additionally, OrderFlow is a multi-site system, which means that it supports the fulfilment of orders across multiple warehouses and all that this entails.
This chapter tracks a typical order as it is processed through the OrderFlow System. This is a simple example for illustration purposes only. See the Further Reading section, below, to find out more about the depth of OrderFlow’s capabilities.
Terminology¶
Orders and Shipments¶
Throughout this chapter, reference will be made to orders, order lines, shipments and items. The relationship between these is as follows:
- An order is made up of one or more order lines, to be despatched to an end user at a residential or business address.
- An order line is a product being ordered, in the quantity required.
- Order lines from the same order can be despatched in one or more shipments. The usual case is that an order will be despatched in just one shipment. (Shipments are despatched via a courier.)
- A shipment with only one order line is called a single-line shipment. A shipment with more than one order line is called a multi-line shipment.
- Items are the individual products within an order line.
The diagram below shows a multi-shipment order 123456780, which contains three shipments. Shipment 123456780-2 is a single-line shipment, whereas the others are multi-line shipments.
States¶
OrderFlow uses states to monitor and control an order’s progress through the system workflow. Orders, shipments and order lines can have various states, and a shipment can have additional states that signify its progression with its courier.
As an example, when an order is imported into the system, by default the order is validated, the order lines have a state of created and the shipment is ready. When all items in an order have been shipped, the order lines have a state of packed, while the shipment(s) and order are despatched.
There are many states that can be used for shipments as they progress through OrderFlow. Some environments may also use custom states. The transition between states is configurable, so there is no definitive state transition diagram that can be presented. However, a typical shipment state transition is shown below, alongside a typical shipment courier state transition:
Note that some states of the states are terminal states. For example, the despatched and cancelled shipment states are terminal, as there is typically no further work to do on a shipment when it reaches this state. Shipments, orders and other entities that are not in a terminal state are considered open.
An Order Processing Example¶
For an order to progress through a typical despatch workflow, various things need to happen to it. Firstly, the required stock needs to be allocated to its order lines, then the specific items in specific locations need to be assigned to these order lines.
Once specific stock has been assigned, that stock can be picked by a warehouse operator. This can be directed by a paper report, generated by OrderFlow, or by a handheld device that the warehouse operator (called a ‘picker’ in this case) carries around with them.
Once a picker has picked all the items for the order’s shipment(s) (or more typically, a batch of shipments at a time), they can present the stock they have picked to a packer. The packer’s responsibility is to check the items are correct, in the right quantities, and pack them using the required packaging, ready for despatch. The packer will also usually include a despatch note, which details the items in the shipment, for the recipient to read and check.
At some point during this process, OrderFlow will determine which courier should be used to despatch the shipment, based on scripted configuration. It will also print a courier-specific despatch label to attach to the shipment. It may interact with the courier’s system at this point, to inform it of the details of the shipment, and to get a despatch reference in real-time.
Once the courier turns up and takes all the packed shipments away for delivery, they can be marked as despatched in OrderFlow.
In the next sections, some of these steps are described in a bit more detail.
Order Receipt¶
Orders which have been imported (i.e. have been transformed and validated - see the Advanced section for more details), can be viewed on the Orders Dashboard which is accessed from the ‘Despatch’ tab.
For most users, the Orders Dashboard will be used only to view and search for Orders, as most orders are automatically imported and validated by OrderFlow. However there are some cases which may require manual validation, for example, orders for different countries, orders which exceed a certain value, etc.
OrderFlow has to decide how many shipments will be required to fulfil the order. This decision will be based upon various factors, including where (in a multi-site environment) the stock resides for the order lines, since some products may only be stocked in some warehouses. Other factors when deciding whether to split an order into multiple shipments may include product lead time, product weight, or any special carriage requirements (e.g. an out-sized product).
The normal case is for an order to have just one shipment.
The next stage is to allocate the order lines with stock. Only order lines that belong to an order in the validated state can be allocated stock.
Stock Allocation and Assignment¶
OrderFlow is capable of using two types of fulfilment model - the Stock-based Fulfilment model or the Just-in-time (JIT) model.
In the majority of cases, OrderFlow automatically allocates stock using the the stock-based fulfilment model, which is described here. For details of the Just-in Time (JIT) fulfilment model, see the Just-in Time Fulfilment section, below.
When using the Stock-based Fulfilment model, OrderFlow employs a two-stage process for identifying the stock that can be used to despatch orders.
Stock allocation is the process for identifying whether there is stock present in the warehouse to fulfil the order lines in a shipment. Stock assigment is the mechanism by which stock in specific locations are reserved for picking the stock required for these order lines.
These are discussed in turn below.
Stock Allocation¶
Stock allocation is performed on a line by line basis for orders that are waiting to be despatched. Based on the priority of the outstanding shipments, and other criteria, OrderFlow determines, for each order line, whether there is sufficient stock in the warehouse to meet the order line’s stock requirement.
If there is sufficient stock, the order line is given a state of allocated. If there is a shortfall, the order line is given a state of out of stock.
The state of each order line can be viewed from the ‘Lines’ dashboard, which is accessed from the ‘Despatch’ tab.
A shipment’s state can be automatically updated, based on the state of its order lines. For example, if all order lines for a shipment have a state of allocated, the shipment is progressed to a state of released.
If one or more order lines for a shipment have a state of out of stock, the shipment is given a state of out of stock.
The state of each shipment can be viewed from the ‘shipments’ dashboard, which is accessed from the ‘Despatch’ tab.
The next stage is to assign specific picking locations for a shipment’s order lines. Only shipments that have a status of released can have their order lines assigned.
Stock Assignment¶
In the majority of cases, the OrderFlow system automatically assigns stock.
Stock assignment is the process of reserving specific stock in the warehouse to fulfil the order lines in a shipment. OrderFlow attempts to identify picking locations and quantities that match the stock requirement for the order lines concerned. If a picking location can be found for an order line, the order line is given a state of pickable.
If all order lines for a shipment have a state of pickable, the shipment is given a state of pickable.
In some cases, picking locations cannot be found for certain order lines. Typically, this means that additional warehouse operations are required before certain order lines can be picked. For example, some of the stock required may only be present in non-pickable locations, such as bulk storage or incoming locations. In this case, it must be moved to the correct location before it can be picked. In these cases, order lines and shipments are given a state of move pending.
The next stage is to physically pick the stock. Only shipments that have a state of pickable can be picked.
Shipment Picking¶
OrderFlow provides many options for physically picking stock. These options can be broadly categorised into paper-based picking and handheld-driven picking.
Paper-based picking involves grouping pickable shipments into batches, and printing out a picking list (for each batch) that contains all the information needed for a ‘picker’ to go to the correct warehouse locations and pick the correct quantities of stock for all the shipments in the batch. For more details of batch picking, see the Batches section, below.
Handheld-driven picking requires OrderFlow to direct a ‘picker’ to each picking location via the handheld interface. At each location, OrderFlow instructs the picker how many units of which product to pick. One of the advantages of this method of picking is that the picking can be dynamically controlled, with the most optimal picking route determined ‘on the fly’. Another advantage of this method is that the real stock position is reflected in real time in OrderFlow.
The picking state and picking locations of each shipment can be viewed from the Picking dashboard which is accessed from the ‘Despatch’ tab.
Once a shipment is picked using whatever option OrderFlow is configured to use, it is usually given a state of packable.
The next stage is to pack the stock. Only shipments that have a state of packable can be packed.
Batches¶
A Batch is a grouping of shipments that are picked together. Organising shipments into batches can fulfil a number of purposes.
- related shipments can be grouped together to support a simpler or more efficient picking operation. For example, single-line shipments can be picked more efficiently than multi-line shipments, so it makes sense to pick them together. Also, it can often be more efficient to pick together shipments that share the same priority or courier.
- for paper-based picking processes, a consolidated picking list can be printed for all of the shipments in the batch. It also makes sense in some cases to also print all of the customer paperwork (despatch notes or invoices) as part of a batch print operation. This can greatly save on time that would otherwise be required for per-shipment print jobs. This requires the use of high-end, fast printers, but allows for the preparation of paperwork in bulk as part of a background task.
- batches can also be used to support particular workflow processes. The obvious example is picking, either with the help of paper reports or handheld terminals. In some cases, other batch operations can be supported, such as marking all shipments in a batch as packed or despatched.
Shipment Packing¶
OrderFlow supports many different ways to pack shipments.
The most simple way is to simply mark all shipments in a batch as ‘packed’. This is effective if the batch is paper-based and the shipment paperwork (including integrated courier labels) was already generated and printed before the batch is picked. In this case, a ‘packer’ would simply place the correct stock in the correct shipment packaging, and inform OrderFlow that all the batch’s shipments have been packed. OrderFlow would have to trust the packer to put the correct stock in the correct packaging. (Note that this may constitute several packages.)
Some organisations want tighter control over packing, i.e. they want to be sure that no mistakes are made during the packing process, which would result in the wrong goods being despatched. This may be the case if they stock many different products, or if products are very similar and can’t easily be distinguished by eye.
In this case, OrderFlow can be configured to require the packer to scan the items in a shipment before it can be marked as packed. (This process is known in OrderFlow as packing consolidation.) This unambiguously identifies the products and immediately flags any unexpected products (and indeed any incorrect quantities) to the packer. Only when all the correct products in the correct quantities have been scanned can a shipment be marked as packed. This is achieved from the ‘packing screen’ in OrderFlow.
Another reason that OrderFlow may require the packer to access the ‘packing screen’ for a shipment is that the courier label may need to be printed separately from any customer paperwork. (This is especially the case if a desktop courier system is being used - see the Courier Integration Guide for more details.) In this case, the courier label would typically be printed on a thermal printer local to the packer’s ‘packing station’ (i.e. PC).
The packing operations on OrderFlow can all be controlled from the menus under the ‘Packing’ dashboard:
As part of the ‘packing consolidation’ process, OrderFlow supports other refinements, such as requiring the packer to scan a product’s batch code, or to supply a quantity instead of scanning every product.
Typically, once a shipment is packed, the stock is debited from the warehouse. OrderFlow can be configured to perform this action later on, at shipment despatch time, if required.
Once a shipment is packed it is given a state of packed.
Courier Selection¶
In parallel with getting the stock ready for each shipment’s despatch, OrderFlow progresses the selection of an appropriate courier for the shipment, to facilitate the actual shipping of ordered items directly to an end user’s address. The ‘Carriage and Delivery Dashboard’ provides information relating to this:
A courier can be selected in two ways:
- manually: the user explicitly chooses a carrier and service from one of the available choices, or
- automatically: via the application of a ‘Courier Selection’ script at some point in the shipment’s progression through the workflow.
A courier for a shipment can be selected at any time from the Receive Order to Pick shipment stages. When a courier can be selected in the process is configurable.
Automatic selection via script can use any of the shipment or order’s attributes to determine which courier, service and options to use. For example, the shipment’s destination and weight, and the priority of the order may influence this selection.
If no courier selection has been made at the point of packing, the user will typically be redirected to a manual courier selection screen before being allowed to proceed to the packing screen. An example of this screen is shown below. Depending upon the courier and service selected, there may be additional validation that needs to be performed, which may involve real-time communication with a courier’s system.
The ‘courier state’ of a shipment is progressed separately to the shipment state.
Just-in Time Fulfilment¶
The objective that underpins JIT fulfilment is to minimise the necessity to hold and double-handle stock and, where possible, to fulfil outstanding orders directly from stock received through incoming deliveries.
There are significant differences between the way that OrderFlow applies JIT fulfilment for single-line versus multi-line shipments.
- for single-line shipments, it is normally possible to send received stock directly to the packing area as soon as they come in. So no storage of these products is required at all.
- for multi-line shipments, temporary storage of the incoming stock is required. This is because the stock for the different order lines will be received at different times, possibly through separate deliveries and from separate suppliers.
Therefore for multi-line shipments, a pure JIT approach is not possible, because order lines for multiple products must be consolidated before the shipment can be shipped. OrderFlow achieves this through a JIT consolidation process. Items received are held in shipment-specific temporary storage locations in a consolidation area. These are normally close to the incoming and packing areas of the warehouse. Once all of the stock for all of the lines in a multi-line shipment have been consolidated in the single location, the shipment can be picked and packed. For more details of the consolidation process, see the Consolidation section, below.
One variation of the JIT model for multi-line shipments involves fulfilling items partly from stored stock. For example, if some stock for out-of-stock multi-line shipments is present in the warehouse, it is possible to consolidate the shipment order lines partly from incoming stock via the JIT process, and partly from stored stock.
Consolidation¶
Consolidation in OrderFlow refers to the process of the temporary storage of some of the stock for a multi-line shipment, usually in the absence of all of the stock.
Typically, an OrderFlow warehouse that supports this process will have a ‘consolidation area’, which will contain many consolidation locations. Depending upon the size of the products, a consolidation location may be a pallet, a shelf or a ‘pigeon hole’. Each consolidation location will be associated with at most one shipment at a time.
Stock for a multi-line shipment will get directed to the specific consolidation location for that shipment, as it becomes available. (This could be as a result of an incoming delivery, or because of a stock move from bulk storage.)
Once all the stock for a shipment is present in the consolidation location, the shipment is considered to be ‘consolidated’. OrderFlow then marks it as pickable, which means it can then be picked and presented to a ‘packer’.
When a consolidated shipment is picked from a consolidation location, the location is empty and can then be re-used for another consolidating shipment.
The ‘Consolidation’ dashboard shows the state of consolidating shipments in OrderFlow. The ‘Consolidation Locations’ screen below shows the consolidation locations in use.
