The code that dies in the next inbox
Today an architect copies a stock code from a PDF, and the contractor pastes it into a second catalog and gets silence, because that code was minted inside the first ERP. A manufacturer part number travels further until a revision reuses it, and a file can arrive with no barcode.
Three people touch the listing: the architect who specifies it, the contractor who buys it out, and the supplier who publishes it. Material Engine™ mints a BIM-ID on each listing, so a paste lands on that one row, while two sellers of the same part still price it separately.
Why a supplier's stock code dies at the next firm
The supplier mints the SKU for how that firm stocks the item. Schema.org calls sku a merchant-specific identifier, so the same tile at two branches can carry two stock codes and neither will resolve in the other's system. The architect who copies one into a schedule has copied a private key. When the contractor later asks a second distributor for that string, the second catalog has no row to return, and the line goes out as a description someone has to guess at.
The failure stays inside one database. The code still works for the firm that minted it, on their pick ticket and in their own ERP, and it stops at the edge of that system, even though the product itself has not changed. The next company was not the reader that stock code was written for.
When the manufacturer part number points at the wrong revision
The manufacturer prints the part number on the datasheet, the carton, and the catalog page, and that string is what a submittal is actually about. The UK Builders Merchants Federation's Industry Product Data Template treats it as a key only when it is paired with the manufacturer: unique inside that manufacturer's range, not across the trade. Two brands can print 100-2 and mean different goods.
Our catalog stores that number as an optional field and matches it only together with the manufacturer, because revisions reuse the string. Match on the characters alone and the contractor can award last year's gauge, or a different brand's part that happens to share them. The pair is what makes the match safe. A quote PDF that drops the brand name has already lost it.
What is left when the file has no barcode
A GTIN is the number under a UPC or EAN, allocated through GS1, and it is the identifier meant to name one trade item at one packaging level for every firm that touches it. GS1's construction guideline puts professional construction products already on the market without a GTIN inside its scope, which is a plain statement that a real slice of the catalog ships with the barcode still missing. When the file a distributor sends has no barcode, there is no global trade-item key to join two sellers, and the match falls through to the manufacturer plus the product name.
The architect cannot invent that missing barcode on the schedule. The supplier cannot scan a number the manufacturer left unregistered. The listing still has to be findable.
What a pasted BIM-ID resolves to
We mint a BIM-ID when the product row is created. The shape is BIM- plus eight characters drawn from an alphabet that leaves out the glyphs people mix up when they read a code aloud (zero with O, one with I), so a code taken off a submittal or a phone call does not swap one character for its lookalike. The row's own database id stays the primary key. The BIM-ID is the paste handle, and the constraint on it is one string to one listing across the catalog we hold. A paste of that shape is an exact hit on that row, which is the behavior a buyer gets in product search.
The alphabet and the length are ours: eight characters from 32 glyphs is the space we draw from, on the order of a trillion combinations, with a retry if two creates collide. That is a property of the handle, not a claim about how many products the trade has. What the reader gets is narrower than that space. Whoever receives the code can paste it and land on the listing it was minted for, after the stock code has died at the edge of its ERP or the barcode was missing from the file.
Why two sellers of the same part keep two codes
Dedup does not merge the BIM-IDs. When two distributors list the same manufacturer part, a GTIN match, or a manufacturer part number paired with the manufacturer, links both rows to one canonical product. Search can then show one product with two supplier listings, which is how a specifier compares lead time and price on the building materials marketplace instead of wading through duplicate names. Each listing keeps its own BIM-ID. Paste one code and the result is that seller's row, with that seller's price, not a blend of the two.
That split is the trade-off, and it is deliberate. A single shared code would make the paste land on "the product" and hide which firm is actually selling it, whereas two codes keep the commercial fact intact: same part, two offers. The canonical record is what says they are the same part, and the BIM-ID is what says which offer was asked for.
What the BIM-ID does not stand in for
A submittal still needs the manufacturer part number, because that is the string the datasheet and the spec section share. A yard that scans cartons still needs the GTIN. Material Engine keeps those fields beside the BIM-ID rather than overwriting one with another, which is the same separation Schema.org draws between sku, mpn, and gtin. The BIM-ID is the handle for the moment the stock code has left its ERP, the part number has been reused, or the barcode was missing from the file.
The architect specifies against a listing that can be pasted again. The contractor buys out that same row instead of a description. The supplier lists under their own code, next to a peer who sells the same part at a different price.