98% ASME and EN Piping Products. CS, SS, Alloy, Nickel, Non-Ferrous. All Dimensions.
Product Categories Covered by Engine
The normalization engine covers pipes, valves, fittings, flanges, gaskets, and bolts across ASME and EN standards. For each MTO line item, it generates a normalized description (human-readable) and an 18-digit unique product code for ERP systems, derived via SHA-256 hashing. Full traceability to manufacturing and dimensional standards.
Filters
Category
Product Types
Dimensional Std.
Material Specs.
All Grades
ASTM and EN material specifications, from carbon steel to exotic alloys
All Sizes
1/8" to 80", NPS and DN, every schedule and wall thickness
3M+ Unique Codes
Each product gets a normalized description and a unique ERP-ready code
The descriptive code is human-readable but too long for most ERP systems. We hash it with SHA-256 and truncate to 15 hex characters, prefixed by a 3-letter product identifier. This guarantees absolute uniqueness: same product always gets the same code, different products never collide.
Code anatomy
PIP
Product prefix
-
.
7F3A9E2B1C4D8AB
15-char SHA-256 hash of full description
Common Questions
How the codes work for stockists, mills, and distributors quoting buyer RFQs.
What are the benefits of product normalization for a stockist or mill?
When every product carries a single, unambiguous code, your sales team and your buyers stop arguing over what was actually quoted. Buyer RFQs map cleanly to your catalog, so quotes go out faster and without manual interpretation. Pricing stays consistent because the same product always carries the same code: no duplicate SKUs for the same flange, no scattered historical prices, no parallel codes that drift apart over time. For your ERP, e-commerce, and analytics, the code is the single source of truth.
Are all grades and sizes within a specification covered?
Yes. The table above shows macro-level ASTM/EN specifications, but the engine normalizes down to individual grades, classes, schedules, ratings, and sizes. For example, ASTM A182 covers dozens of grades (F304, F316, F321, F11, F22, F91 and more), each with multiple size and class combinations. Each one becomes a distinct normalized code, so when a buyer asks for an "A182 F316L 2in 300# WN flange" the engine matches the exact item in your catalog, not the family.
What if a product isn't listed in the table above?
The table shows the product families currently covered by the normalization engine. We are actively expanding coverage to structural steel, joints, and pipe supports. If your catalog includes a category not listed here, get in touch and we will evaluate adding it to the roadmap.
Does the normalization engine detect errors?
Yes. When a buyer RFQ contains inaccurate descriptions, references non-existent products, or has incomplete specifications, the engine flags the line and proposes a default for review instead of guessing. This catches mistakes early, before your sales team prices an item that does not exist or quotes the wrong material to a buyer. The same checks apply to your catalog imports, so duplicates and bad entries get caught at the source, reducing clarification rounds and avoiding wrong prices going out.
How does the engine handle messy buyer descriptions?
That's the core of what the engine does. A buyer might write "6in WN RF flge A105", another "FLANGE WN 150# 6" RAISED FACE SA-105", a third in another language entirely. All map to the same normalized code in your catalog. The engine parses free-text descriptions against a rules database covering all standard abbreviations, formats, and conventions used across piping procurement. No AI guessing, just deterministic rule-based parsing.
Why do you use SHA-256 to generate the ERP Product Code?
A fully normalized product description can be very long, too long for ERP material code fields. SAP's Material Master (MM), for example, allows a maximum of 18 characters for material numbers in classic configurations. We need a way to compress a full description into a short, fixed-length code while guaranteeing that every unique product gets its own unique code. That's where SHA-256 comes in. It's a cryptographic hash function, the same algorithm used in digital signatures, blockchain, and certificate verification. It takes any input and produces a fixed-length fingerprint that is deterministic: the same product always generates the same code, every time, on any machine. We use a 3-letter product prefix (e.g. PIP, FLG, VLV) followed by 15 hex characters from the hash. Those 15 digits alone give 1615 = 1.15 quintillion possible combinations, more than enough to cover every product variant in the global piping industry with a unique code. As for collisions (two different products generating the same code): with the birthday problem formula, at 3 million product codes the probability is roughly 1 in 256,000. At 10 million codes, about 1 in 23,000. In practice, it is virtually impossible for two different products to end up with the same code.
Why didn't you use MESC (Shell)?
MESC (Material Equipment Standards and Code), developed by Shell, covers only a fraction of the product variants we handle. MESC is also a closed, proprietary system with limited access and licensing restrictions. Our goal is different: an open codification standard that any stockist, mill, distributor, or software vendor can adopt freely. Piping procurement today is a tower of Babel where every company uses its own codes, abbreviations, and formats. Instead of relying on Shell's restricted catalog, we built an open, deterministic system that covers all piping product families, so a buyer's RFQ and your catalog finally speak the same language.
See Our Solutions in Action
Book a 30-min call and see how our engine works with your catalog.