We are going to explain here how to handle backorder in Purchase Orders. The same approach applies to Sales Order or Internet Orders.
Let us suppose that a company wants to place an order with 100 order lines. The ordering process in ERP5 always goes through different states: draft, planned, ordered confirmed. Once a Purchase Order has been placed and confirmed by the supplier, users should set its state to confirmed. The Purchase Order then becomes a read-only document. The underlying idea is for keeping a Purchase Order read-only is the same as the logic of archiving a signed contract. Once it is signed, it can never be changed. It is kept in an archive as a reference which is referred to during the contract execution. Changing a signed contract (or a confirmed Purchase Order) always go through a new contract (or a new Purchase Order).
Once a Purchase Order is confirmed, a Purchase Packing List document is generated by ERP5 in confirmed state. This Purchase Packing List contains exactly the same information as the Purchase Order. However, unlike the Purchase Order, it can be modified. The purpose of the Purchase Packing List is to track the execution of the Purchase Order, in the same way as one would track the execution of a contract.
As soon as a Purchase Packing List is shipped by the supplier, its state should be set to shipped (started for ERP5 developers).
As soon as a Purchase Packing List is received by the recipient, its state should be set to received (stopped for ERP5 developers).
Whenever a Purchase Packing List has been inspected and all goods are fined, its state should be set to delivered (delivered for ERP5 developers).
Through this notion of states, it is very easy to know the purchase order backlog, which consists of: Purchase Packing Lists in confirmed state.
ERP5 provides fast access to both types of backlog orders using a a worklist: Purchase Packing Lists to ship.
Sometimes, items in a Purchase Order are not all delivered or not delivered at the same time. The approach of ERP5 to handle this situation consists of tracking precisely:
If a product of Purchase Packing List line is not going to be shipped by the supplier it is considered in ERP5 as being received with a quantity of 0.
The role of users in charge of purchase is thus, as soon as a supplier notifies them of a shipment, to look at the Purchase Packing List in confirmed state which is going to be shipped and then:
If only 95 lines out of 100 are going to be shipped, 5 lines need their quantity to be set to zero. If only 30 lines out of 100 are going to be shipped, 70 lines need their quantity to be set to zero.
Once the exact shipped quantity is set, ERP5 will ask user to solve so-called divergence. The user must take a decision for each Purchase Packing List Line, such as:
If the user selects "Split and Defer", a new Purchase Packing Lists is created in confirmed state. This new Purchase Packing List contains all lines which are not going to be delivered in the next shipment confirmed by the supplier. This is consistent with the general approach of ERP5: the purchase order backlog consists of Purchase Packing List in confirmed state.
By using "Split and Defer", a user can specify which products will be delivered in the next shipment and which are still in the backlog.
The worklist "Purchase Packing Lists to ship" tells the user the current state of the backlog.
This backlog is presented as a list of documents. It can be filtered by suppliers, by purchase orders, etc.
If you need to prepare a report out from this backlog list, after filtering the backlog list, you can click on import/export icon in the tool bar, to export the filtered list to spreadsheet format file.