We have every drawing, so why can't it price from them?
A fabricator sent 14 shop drawings expecting the quoting system to read sizes off them. All were stamped not to scale. What a drawing can and cannot tell a quote.
You have a drawing for everything you build. Years of them. So the obvious question, when a quoting system is being set up, is why it cannot simply read the drawings and price the job: the sizes are on there, the parts are on there, a fitter reads them every day.
This fabricator sent 14 of them, and the assumption on our side was the same as theirs: these are the authoritative record, the real dimensions and real geometry, the thing the pricing rules should be checked against and, eventually, the thing a 3D preview could be generated from.
Every one of them is stamped not to scale. That one stamp changes the estimate for any “just read the drawings” request by a wide margin, and it is worth knowing before that request is made rather than after money has been spent on it.
What was actually going on
Not to scale means the lines in the file do not represent the size of the thing. Any tool that measures the drawing gets a number that means nothing. What the drawings carry, and the only thing they carry, is a set of measurements the draughtsman typed on as text.
Getting even that out had a cost. All 14 files were in a proprietary binary CAD format, at a recent version, and nothing in the language the rest of the system is written in can read it. The only route was a conversion step through an external desktop program, which needs administrator rights to install and is fundamentally a graphical application that happens to accept a batch command. That is now a permanent dependency of any automated extraction. Reading a proprietary CAD format is a purchasing decision before it is a programming one.
Once converted, the useful content is the typed measurements: imperial inches, written the way a person writes them on a shop drawing. Some are plain numbers with an inch mark. Some are mixed fractions. Some are wrapped in formatting because the draughtsman wanted a particular text height, so the value is buried inside a control sequence. A reader for that is a reader of handwriting habits, not of a file format, and it has a coverage figure rather than a guarantee. Of the 14 drawings, two yielded no dimensions at all, because their measurements were written in a form the reader did not recognise. That was reported as two files unparsed, cause suspected, rather than quietly returning fewer numbers.
The second assumption went the same way. In a well-built CAD model a recurring component is a block, inserted repeatedly, so detecting which features an item has is a matter of listing the blocks. There were none, not one across 14 files. Every feature is drawn as raw lines on what is effectively a single layer. Features cannot be detected from structure at all, only guessed from labels. That is what ended the idea of driving anything automatic from the drawings, and it is why the 3D preview is generated from the quote’s own data instead.
The general point: a file format’s capabilities say nothing about whether a given file uses them. These are production shop drawings made for a fabricator to read, not a data model made for a program to read.
What the drawings were genuinely good for
Each drawing was matched to its product type and used to check the definitions of that product’s pricing rules, not the prices. Does each step refer only to values that exist at that point, does every name resolve to a dimension the system knows, a material slot or a rate code. Across every product the 14 drawings mapped to, that check returned zero problems. It independently confirmed what a separate reconciliation against the source workbook had already concluded, by a different route, and two unrelated checks agreeing is worth more than either alone.
They also gave a comparison nothing else could. For a work table with a sink, the pricing model needs 11 dimension variables. The drawing annotates 5. That gap is not a fault in either. The drawing records one item that was actually built, with the standard sizes left off because the workshop knows them. The model describes every item of that type that could be ordered, so it has to spell out the optional features and the sizes the workshop would otherwise assume. A record of a built thing and a specification of a sellable thing are complete in different ways, and confusing them is how a business comes to believe a quoting system can be derived from a drawings folder.
The small findings
Four drawings had no confident product-type match, which means either those products are absent from the catalogue under a recognisable name or the naming has drifted. That is a question for a person, not a defect. And the comparison turned up some untidiness in the dimension definitions themselves: a handful of length variables tagged with a count unit, at least one pair covering the same measurement under two names, and a rate sitting in the dimension list where it does not belong. None of it broke anything; all of it would eventually confuse whoever maintains the catalogue next, and none of it would have been found by testing prices.
The rule
Before treating any document as a source of truth, read what it says about itself. “Not to scale” on a drawing is the file telling you which of its contents can be relied on. Then ask the narrower question: not what can be generated from this, but what can this prove. A set of drawings that cannot supply dimensions can still verify that your pricing definitions are well formed.
Where this ends up
The drawings ended up as an independent check on the calculation definitions in Quote, rather than as a source of dimensions, which is the most they could honestly be asked to do.