How to turn an MTO into a clean steel procurement list

A project MTO is often written for engineering, construction or quantity control—not for efficient steel sourcing.

One line may say:

PIPE SMLS 273 x 10 S355J2H 6M 24 PCS

another:

CHS OD323.9 WT12.5 / EN10210 / S355J2H / 48m

and another may put the standard, test requirement and coating in separate notes.

Before sending the list to suppliers, convert it into a normalized procurement table.

Preserve the original item first

Never start by deleting or merging source lines.

Keep:

• original line/item number;
• original description;
• original quantity;
• original unit.

These fields provide the audit trail back to the client MTO.

Then create normalized fields beside them.

Core normalized fields

For most steel procurement lists, useful columns include:

• item number;
• product type;
• dimensions;
• grade;
• standard;
• delivery condition;
• length;
• quantity;
• quantity unit;
• calculated unit weight;
• calculated total weight;
• certificate type;
• supplementary requirements;
• remarks.

Product-specific dimensions should also be separated where useful.

Pipe/tube

• OD;
• WT;
• length;
• quantity.

Plate

• thickness;
• width;
• length;
• number of plates.

Sections

• profile designation;
• length;
• pieces/weight.

Keep source values separate from calculated values

If the MTO provides a weight, keep it as a source weight.

If you calculate weight independently, label it as calculated weight.

Do not silently replace the project quantity with your own calculation because nominal masses, tolerances, density assumptions and project rules can differ.

A good table can contain:

This catches parsing or dimensional errors without destroying the source record.

Do not merge duplicates too early

Two rows that appear identical can represent:

• different project systems;
• different tags;
• different delivery dates;
• different certification;
• different testing;
• different coatings;
• different lengths;
• separate procurement packages.

Keep line items separate until you have confirmed they can be commercially combined.

You can later create an aggregated sourcing view while preserving a line-to-line mapping back to the MTO.

Normalize terminology

Common examples:

• SEAMLESS, SMLS → SMLS pipe/tube;
• RECT HOLLOW, RHS → RHS;
• SQUARE HOLLOW, SHS → SHS;
• H-BEAM HEB300 → HEB 300;
• PL, PLATE → Plate.

Normalization helps supplier comparison, but never use it to change the technical meaning.

For example, do not convert pipe to EN 10210 CHS unless the standard/product identity is actually stated or technically established.

Split grade and standard

A description such as:

S355J2H EN10210-1

should become separate fields:

• Grade: S355J2H
• Standard: EN 10210-1

Do the same for delivery conditions, e.g. +N, +M, +AR.

This makes missing information visible.

Capture supplementary requirements explicitly

Technical notes are often the most valuable information in an MTO/specification package.

Create separate columns or a structured requirements field for items such as:

• Charpy temperature/energy;
• CEV;
• Pcm;
• UT;
• Z25/Z35;
• hardness;
• CTOD;
• NACE/ISO 15156;
• DNV/ABS/class approval;
• 3.1/3.2;
• PMI;
• coating/preservation;
• marking.

Do not bury them in a generic remarks column if they affect sourcing.

Flag ambiguity instead of inventing values

If the MTO says 6" SCH 80 but does not state the dimensional standard, do not silently assume the wrong table.

If it says S355 without a complete suffix, do not invent S355J2.

Useful status fields include:

• Complete
• Clarification required
• Assumed for calculation only
• Conflicting documents

The procurement list should reveal uncertainty rather than hide it.

Derive counts carefully

Sometimes the MTO gives only total metres or total weight.

A procurement list may need pieces.

For fixed length:

Piece count = total ordered length ÷ ordered piece length

But only treat the result as a firm count when the division is exact and the project intent is clear.

If 690 m is required in 2.0 m pieces, 345 pieces is straightforward.

If 690 m is required in "approx. 6 m" stock lengths, the sourcing logic is different.

Build two views

For larger enquiries, maintain:

Engineering traceability view

One row per original MTO line.

Sourcing/aggregation view

Items grouped where technically and commercially identical.

The second view is useful for requesting mill quantities and negotiating MOQ. The first view protects traceability back to the project documents.

Check before issuing the RFQ

After normalization, run these checks:

• missing grade;
• missing standard;
• missing delivery condition where relevant;
• inconsistent units;
• nonstandard size notation;
• duplicate line numbers;
• impossible/zero quantities;
• mismatch between length × pieces and total metres;
• major weight variance;
• contradictory test requirements;
• mixed certificate requirements within an aggregated line.

Only then should the list become the basis of an RFQ.

See How to prepare a steel RFQ that mills and stockholders can quote correctly.

Procurement takeaway

An MTO is source data. A procurement list is a normalized commercial/technical representation of that source data.

The transformation should make the material easier to buy without losing the ability to prove where every value came from.

References and verification sources

• DIN EN 10204:2005-01 — Metallic products, types of inspection documents
• DIN EN 10168:2004-09 — Steel products, inspection-document information