Engineering to Procurement

The Technical Structure is not just a design document — it is the bridge between engineering and procurement. This page explains how data flows from the tree of Nodes to purchase orders, and ultimately to goods installed in the field.

The hand-off story

During the Definition and Planning phases of a project, engineers build out the Technical Structure: they add Nodes for every system and component, attach Required Materials with spec constraints, and — as the design firms up — replace or supplement those with specific Required Goods pointing to exact product variants.

Once those requirements exist on the Technical Structure, procurement has everything it needs to plan purchases:

• Which goods are needed (the Required Goods by variant and quantity).
• Which categories of goods are needed (the Required Materials by Good Type).
• What technical constraints apply (the Required Specs on each material).
• Where in the plant each item will be installed (the Node it is attached to).

For Engineers

Populate the Technical Structure early — ideally before the first purchase orders are raised. Every Required Good or Required Material you add gives procurement a concrete target. Leaving the tree empty means purchasing decisions float free, with no link back to the asset design.

Procurement Requests and traceability

When a buyer creates a Procurement Request (good_procurement_request), they can reference a specific Required Good (technical_structure_good) directly on the request. This single link is what creates traceability: the purchase order knows which Node it is fulfilling, which means you can later ask “what did we buy for the inverter cabinet on Array A?” and get a precise answer.

The chain looks like this:

Technical Structure Node
  └── Required Good (technical_structure_good)
        └── Procurement Request (good_procurement_request)
              └── Purchase order / delivery

For Finance

Every purchase tied to a Procurement Request that references a Required Good can be traced back through the tree to a specific node in the physical asset. This gives you project-level cost allocation down to the component level, without any manual tagging.

Good Usage and audit

When a field technician records that goods were consumed on a Task (a Good Usage entry), they can also reference the Technical Structure Node where those goods were installed. This closes the loop:

• Engineering specified the need on a Node.
• Procurement ordered against that Node.
• Field recorded the installation against that same Node.

The result is a complete record of what was installed where — useful for warranty tracking, asset registers, and post-project audits.

Each Good Usage entry also records its own consumed quantity (starting at 1 by default) — independent of the quantity planned on the Required Good it links to, so a single Required Good can be split across several Good Usage entries over time.

Both a Node and a Required Good have an Allocation tab listing every Good Usage recorded against them — which Task consumed the material and when — so engineering and procurement can see “where was this installed” without opening the Task itself.

More than one Good can fulfil a Required Material

A Required Material is not limited to a single Required Good. If, for example, a design changes and a replacement Good is placed alongside the original, both can point to the same Required Material at once — its Assigned Data tab lists all of them.

Deleting a Required Good checks this automatically:

• If it was the only Good fulfilling that Required Material, the Required Material reopens (status goes back to open) so it shows up as needing an assignment again.
• If other Required Goods still fulfil it, the Required Material’s status is left untouched.

Note

The Technical Structure sits alongside the work plan (Segments and Tasks) as a separate view of the same project — neither is part of the other. See Two Views of a Project for the broader picture.

Summary of the data flow

Stage	Who acts	What happens
Definition / Planning	Engineers	Build the Node tree; add Required Materials and Required Goods
Procurement planning	Buyers	Read the Node tree; create Procurement Requests referencing Required Goods
Delivery	Warehouse	Receive goods against Procurement Requests
Installation	Field / technicians	Record Good Usage on Tasks, referencing the Node where goods are installed
Audit / finance	Finance / management	Trace any purchase or usage event back to the Node and the project