A sent offer never changes. The next one is a new version.

The client is an engineering group that builds rolling mills and billet plants. A rolling mill is the plant that turns steel billets into bars and wire rod. Before a customer buys one, the group sends a technical offer: a document of 40 to 200 pages that sets out the plant, the equipment and who is responsible for what.

The operation, and what it has to control

An offer has two kinds of page. Some are written for the project: the introduction, the technical parameters, the basic data, the production table, the scope of supply, the terms and the exclusions. The rest are ready-made equipment pages, the drawings and specifications for each machine, taken from a central catalogue.

An offer is not always sent once. The customer asks for a change, and a revision goes out. What the operation has to control is therefore the document itself: which text and which equipment pages went into it, and which version the customer holds.

The documents describing the earlier process are thin, so this page says only what they record. Offers were revised and sent again under revision codes. The production chart was prepared in Excel. The finished offer went to the customer by email. Terms differed slightly from one offer to the next. The specification set three aims for the new system: no copying between Word files, no numbering pages by hand, and no risk of overwriting version one.

What we built

Jetbro built the engineering group’s technical offer system on Phlo. It holds the equipment catalogue and the standard text, assembles an offer from them section by section, and produces the finished PDF on the group’s letterhead with every page numbered.

It holds no prices. A technical offer says what will be supplied and by whom. Spares and consumables for mills already running are handled in a separate system, which is live.

How an offer moves through it

1. Catalogue, once. The admin loads each equipment item: its name, description and category, a PDF of drawings and specifications, and its default scope of supply rows. The admin also keeps the default introduction, terms and preferred makes, and a list of exclusion clauses.
2. Create. A builder enters a project code, a quotation code and a date. Version 1 opens as a draft, already filled with the default text. A duplicate pair of codes is refused.
3. Fill the sections. The editor has nine tabs in the order of the document, from the introduction to the exclusions. Each tab saves on its own.
4. Upload the production chart. The builder uploads the Excel file. The system reads it into the production table: the design parameters, the production grid and the summary figures.
5. Pick the equipment. The builder ticks items in the catalogue. The scope of supply grid fills itself from the ticked items.
6. Adjust the scope. The builder changes who is responsible for a cell, and edits quantities. The descriptions stay as the catalogue has them.
7. Preview and lock. A preview shows the assembled document, and a draft PDF can be downloaded. Locking generates the final PDF, stores it and makes the version read-only.
8. Send. The builder downloads the PDF, emails it outside the system, and marks the version as sent.
9. Revise. From a locked or sent version, a new version copies everything into a fresh draft with the next number. Earlier versions stay downloadable.

What the build described

Building the system meant writing down what a technical offer is made of, what can happen to it, and where the tidy process breaks. That is the model of this operation.

• The things tracked. The offer, identified by its project code and quotation code. The version, which is the unit that gets edited, locked and sent. The catalogue item, with its equipment PDF and its default scope rows. The scope row, which names one sub-component. The exclusion clause, and the preset that groups clauses. The three default texts: introduction, terms and preferred makes.
• What can happen to an offer. It is created. A version is created, updated, locked and sent. Those five events are the whole life of an offer, and each carries the person and the time.
• What can happen to the catalogue. An item, a clause or a preset is created, updated, deactivated or reactivated. A default text is updated. An item that is no longer offered is deactivated, and the record of it stays.
• Exception: the scope of supply is a grid, not a paragraph. Each row has seven columns, from basic data and design through supply to erection and commissioning. Each cell says who is responsible: the supplier, meaning the engineering group, or the customer.
• Exception: the equipment changes late. When the selection changes, the grid refills from the catalogue. Rows the builder has already adjusted keep their adjustments.
• Exception: the production chart lives in Excel. The model keeps that habit. The system finds the table by its labels, not by cell position, and shows it read-only. A change is made in Excel and uploaded again.
• Exception: exclusions are part standard, part written for the job. The builder loads a preset group of clauses, adds single clauses, writes custom ones and puts the list in order.
• Exception: the customer asks for a change after the offer has gone. The sent version is not reopened. A new version is created from it.

The rules it holds

A version is a draft, locked or sent. Sent is final. A version cannot be locked until at least one equipment item is selected. Only one draft of an offer can be open at a time.

The equipment pages and clause text in a PDF are the ones current at the moment of locking. After that the stored PDF does not change, whatever happens to the catalogue.

The version history is enforced, not a convention. There is no way to edit a locked or sent version, so the history cannot be skipped by someone in a hurry.

What the record makes possible

Every save, lock and send is an event with a person and a time. The version history of an offer is those events, listed. Each earlier version can still be opened and its PDF downloaded.

So the question of which document the customer received has one answer. It is the version marked as sent, and it cannot have been altered since.

The catalogue is on the same record. A change to an equipment item, a clause or the default text is an event too, with the person who made it and the time.

What the foundation carries forward

A build leaves more behind than its screens. Here it leaves the equipment catalogue as structured data, the scope of supply as a grid that can be read by row and by stage, accounts with roles and permissions, and an event log that covers every offer made in it.

Every Phlo system is built on the same framework. A later system that needed the equipment catalogue or these roles could read them from this record. The group’s spares system is separate and shares no data with this one.