ERP for Distribution & Trading

How the work flows, document by document

In distribution and trading, the chain starts when a customer rings the sales desk. The salesman raises a quotation in the system; the document is called a QTN. Once the customer accepts, the QTN becomes a sales order (SO). The SO is visible in the live order book, split by warehouse and by salesman.

On the supplier side, a purchase requisition (PR) is raised when the stock ledger dips below re-order level. The PR becomes a purchase order (PO) once the buyer confirms price and delivery. When the lorry arrives, the gate clerk prints a goods receipt note (GRN) from the PO. The GRN triggers the incoming QC inspection; if the batch passes, the GRN is posted and stock appears in the ledger.

Outbound, the warehouse picks against the SO and prints a delivery challan (DC). The DC travels with the goods; when the customer signs, the DC is converted to an invoice (INV). The INV posts to the customer ledger and the stock ledger simultaneously, so the trial balance always ties.

The batch problem: why recording it changes the numbers

Terry towels trade in batches, not pieces. A single consignment can contain 500 kg of 400 gsm white towels, split across three pallets. If the batch is not recorded at GRN, the system treats the whole consignment as one homogenous lump. When a customer orders 200 kg, the warehouse picks from any pallet; the remaining 300 kg on the other pallets is still shown as available, but in practice it is stranded because no single pallet has 200 kg left. The result is phantom stock: the ledger says 300 kg, but the warehouse cannot fulfil a 200 kg order.

Recording the batch at GRN splits the consignment into pallets. Each pallet becomes a sub-batch with its own weight, GSM and location. When the warehouse picks, the system allocates from the pallet that has enough stock. The ledger now shows only the stock that can actually be picked, so the sales desk stops promising what the warehouse cannot deliver.

Costing: landed cost per consignment

Landed cost includes the supplier invoice, freight, duty, port charges and any demurrage. These costs are not spread evenly; a 20-foot container might carry 12 tonnes, while a 40-foot container carries 25 tonnes. If the system spreads the freight equally, the cost per kilo is wrong for every consignment.

Instead, the system captures the actual freight and duty paid for each container. The costs are allocated to the consignment that travelled in that container. Below is a worked illustration for two consignments that arrived in the same week.

The illustration shows that consignment A costs 29% more per kilo than consignment B. If the system had spread the freight equally, both consignments would have shown £1.16 per kg, and the margin on consignment A would have been overstated.

The controls that matter

Approvals. A PO above £10,000 needs two signatures: the buyer and the finance manager. The system enforces this in the API, not just in the menu. If the buyer tries to post without the second signature, the API rejects the document and the stock ledger does not update.

Roles. The gate clerk can create a GRN but cannot edit the PO. The warehouse manager can allocate stock to a sales order but cannot create a new customer. These rights are set per role and enforced on every screen and every API call.

Traceability. Every document carries a unique number and a timestamp. The GRN shows which PO it came from, which container it travelled in, and which QC inspection it passed. If a customer complains about a batch, the system can trace the batch back to the supplier invoice and the original container number.

Audit. The system logs every login, every document created, edited or deleted, and every screen viewed. The log is immutable; it cannot be edited or deleted. If a user changes a PO after approval, the system records the old value, the new value, the user ID and the timestamp.

What a rollout touches first, and what can wait

Most plants start with the stock ledger. They load the opening balances for each warehouse, each batch and each rack. Once the ledger is live, the sales desk can see real stock and the warehouse can pick against sales orders. Next comes the order book: quotations, sales orders, delivery challans and invoices. These two modules give the plant a single view of stock and orders, so the sales desk stops promising what the warehouse cannot deliver.

After that, the plant adds purchase orders, GRNs and supplier bills. This closes the loop: the stock ledger now updates from both sales and purchases. Finance and costing usually follow; the system posts the invoices and GRNs to the trial balance automatically, so the accountant does not have to re-key them.

HR, payroll and production planning can wait. These modules touch fewer people and do not affect the daily stock position or the order book. They can be added in the second phase, once the plant is comfortable with the core modules.

Where the system would need custom work

The system is built for manufacturing, not trading. The stock ledger assumes that every item has a bill of materials and a production route. In trading, the item is bought and sold as-is, so the bill of materials is empty. The system can handle this, but the screens still show fields for weaving, dyeing and stitching. These fields are not used, but they clutter the screen and confuse the users. A small customisation would hide these fields for trading items, so the screens are cleaner and the users see only what they need.