Every line of a client's request, followed to its invoice.

The client is an engineering group that builds rolling mills, the plants that turn steel billets into bars and wire rod. Over a mill’s life its owner needs replacement spares and consumables. The group’s spares business buys these from vendors and supplies them to the mills, from one warehouse.

How it ran before

There was no central system. A client’s request arrived by email or WhatsApp, as an Excel sheet, a PDF or a handwritten slip the team calls a chitthi. The items were typed out again by hand, and the client’s wording rarely matched the names used inside.

Each quotation was its own Excel file, renamed by hand for each version. Proforma invoice numbers were assigned by hand, and the status of each one was a free-text remark in a sheet. Who had been asked to buy what was agreed aloud or on WhatsApp. One person kept the shared register of goods received. A partial delivery became a dated note in a remarks cell. Goods sent straight from a vendor to a client left no record.

What we built

Jetbro built the engineering group’s spares operations system on Phlo. It carries an order from the client’s request through the quotation, the proforma invoice (PI), the purchase order (PO), the goods receipt (GRN) and the sales invoice, with stock and reports read from the same record.

The unit it follows is the PI line: one item, for one client order. Technical offers for new mills are assembled in a separate system, built for another part of the same group.

How an order moves through it

1. Request. The ops member picks the customer and uploads the request file: Excel, PDF or a photo. AI reads the lines from it. A person confirms every line before anything is saved.
2. Quotation. Each line is mapped to an item. The system suggests a match, and the ops member accepts or overrides it. Lines are assigned to purchase workers, who enter the vendor and rate for each.
3. Send and lock. Finalising gives the quotation its number. It can be locked only after it is sent.
4. Proforma invoice. The PI is created from the locked quotation. It is locked when the client’s own order arrives, with that order’s number and dates.
5. Work allocation. Locking produces a work allocation sheet. Confirming it puts jobs in each purchase worker’s list.
6. Purchase order. A worker selects jobs and the system creates one PO per vendor. Each PO waits for the purchase approver.
7. Goods receipt. The supervisor picks the PO and records quantity, location, packaging, weights and the vendor’s challan. Received goods are reserved for the PI line they were bought for.
8. Dispatch. From the pending dispatch list the ops member selects lines, and a sales invoice is created.

What the build described

Building a system is where an operation gets written down: the things it tracks, what can happen to each of them, and the cases that do not fit. For a spares trade, the description turns on one line of one order.

The things the business tracks:

• An item. A spare or consumable in the item master, with its narrations and the vendors and rates recorded against it.
• A quotation and its lines. A draft built from the client’s request, numbered when it is finalised, with a version for each revision.
• A PI and its lines. The confirmed order. Each line carries its own quantities and its own state.
• A job. One PI line assigned to one purchase worker, created when the work allocation is confirmed.
• A PO. What one vendor has been asked to supply, possibly for several orders.
• A GRN. One receipt of goods against a PO, with location, packaging and weights.
• Stock. Goods in the warehouse at a location, reserved for a PI line or free.
• A sales invoice. What left for the client, and against which lines.

What can happen to them, in the system’s own words:

• To a quotation: created, line mapped, worker assigned, exchange rate set, line rate set, confirmed, sent, revised, locked.
• To a PI: created, sent, revised, locked, work allocation confirmed, cancelled.
• To a PO: created, approved, revised, cancelled.
• To goods: GRN created, goods received, direct shipment recorded, stock reserved, stock released, stock moved, stock adjusted.
• To a sales invoice: created, cancelled.
• To the accounting hand-over: export generated, file downloaded, sync marked.

The cases that used to live in a remarks cell were modelled, not worked around:

• The client’s own wording. Each item carries narrations: the ways clients describe it. Matching uses them, so a description already recorded against an item can be matched.
• Part deliveries. Each PI line carries what was ordered, what is on a PO, what has been received and what has been dispatched. Part quantities no longer live in a remarks cell.
• Vendor ships to the customer. On the GRN, each line is routed into the warehouse or marked as shipped direct to the customer. The direct shipment is recorded either way.
• Made in-house. A line that the group manufactures itself becomes a work request for the shop, never a PO.
• One PO, several orders. A worker can select jobs across several PIs, and the system still creates one PO per vendor.
• Sold from stock. Stock can be invoiced with no PI behind it.
• A quotation in another currency. The exchange rate is set on the quotation and recorded as an event of its own.
• The order that finishes in parts. A PI closes by itself once every one of its lines is delivered, however many receipts and invoices that took.

The rules it holds

Raising a PO and approving it are separate permissions. A revised PO needs approval again. A purchase order rate that departs from the rate the deal was priced on is blocked unless the user holds a special permission.

A locked quotation can be revised into a new draft version until a PI exists. A GRN cannot be edited once created. A sales invoice cannot be edited, only cancelled. PI numbers come from the system and restart each April.

Each role sees its own part of the order. Ops members build quotations and dispatch, purchase workers enter vendors and rates and raise POs, the approver approves them, and the supervisor receives goods. Access per role is itself changed by a recorded event.

What the record makes possible

Every PI line moves through four states: Open, PO Raised, Procured, Delivered. The reports are that record read in different ways: PI and PO status, PO tracking, inward and packing, pending dispatch. Each role’s dashboard lists the work waiting on it, oldest first.

The documents are generated from the same record, and the client’s copies leave out the internal columns.

The accounts are kept in Tally. There is no live link. The admin downloads items, vendors, customers, POs and GRNs as files in Tally’s own XML format, imports them into Tally, and marks them as synced. Only approved POs are exported. A PO revised after it was synced is flagged.

What the foundation carries forward

The description above is the lasting part of the build. The item, the PI line, the PO and the receipt are defined, with the events that move each one. The roles and the approval step exist. Every quotation, order, receipt and dispatch entered in the system is on the record, in order.

A further process for a trade like this would start from that, not from an empty page. A step added before the request or after the invoice would hang from the same PI line, use the same items and vendors, and add its own events to the same history.