One document, in order, with a cover that says what is in it — the schedule, a shop drawing for every door, the finish tags and the keynote answers. Every page is generated from the door records, so the schedule and the drawings cannot disagree.
One page per door. Front elevation with the leaf, frame and rough opening dimensioned
and the handle height called out; a jamb section through the wall showing the frame, the trim
and the wall thickness; head and sill; the swing diagram for this door; and a data panel with
the selections. Drawn at a stated scale from the same doorResolve the schedule
reads, so the drawing and the schedule cannot disagree.
The three elevations share ONE scale, so they can be read against each other; the jamb detail and the operation diagram are enlarged, as details are. Every view states its own scale in its header. A browser prints through the page, so the paper size here sets the DRAWING size — choose the matching paper and turn scaling off, or the scale in the title block stops being true.
Nothing matches. Try another supplier, or clear the search.
)}Every line a LEON door can carry, each picked from Supplier Finishes — the same catalog the selections and the order read. The picture goes on the shop drawing. Mark a line N/A and it is left off the drawing and the schedule; a line left blank has not been answered yet, which is not the same thing.
Nothing matches. LEON's hardware is entered under LEON Collection → Supplier Finishes; anything added there is offered here straight away.
)}Every door is one record. The schedule, the elevation, the hardware and production all read it, so a width changed in the schedule is the same width the drawing redraws from.
| setSel(e.target.checked ? rows.map(r => r.door.id) : [])} /> | {DOOR_SCHEDULE_COLUMNS.map(c =>{c.label} | )}|||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| setSel(e.target.checked ? [...sel, d.id] : sel.filter(x => x !== d.id))} /> | setDoor(d.id, { mark: e.target.value })} className="w-20 px-1 py-0.5 font-bold bg-transparent border border-transparent hover:border-[var(--leon-line)] rounded" /> | {['location', 'fromRoom', 'toRoom'].map(f => ( | setDoor(d.id, { [f]: e.target.value })} className="w-28 px-1 py-0.5 bg-transparent border border-transparent hover:border-[var(--leon-line)] rounded" /> | ))}setDoor(d.id, { qty: Number(e.target.value) || 1 })} className="w-12 px-1 py-0.5 text-right bg-transparent border border-transparent hover:border-[var(--leon-line)] rounded" /> | {/* Sizes: typing here overrides the type for this door only, and the cell is tinted so an override is never invisible. */} {/* When a door is sized from the ROUGH OPENING the leaf is DERIVED, and the stored leafW/leafH are whatever the type last said — so printing them here put a 32" leaf in the same row as a 35 1/4" frame computed from the opening. A schedule that contradicts itself is how a door gets built wrong, so a derived leaf is shown as the computed figure and is not editable; edit the rough opening instead. */} {[['leafW', R.leafW, r.sizes.leaf.w], ['leafH', R.leafH, r.sizes.leaf.h], ['leafThickness', R.leafThickness, R.leafThickness]].map(([f, v, derived]) => (
{fromRo && f !== 'leafThickness'
? {fmtDim(derived, system, { inchesOnly: true })}
: |
))}
{r.frame ? r.frame.name : '—'} | {fmtDim(r.sizes.frame.w, system, { inchesOnly: true })} | {fmtDim(r.sizes.frame.h, system, { inchesOnly: true })} | {fmtDim(r.sizes.ro.w, system, { inchesOnly: true })} | {fmtDim(r.sizes.ro.h, system, { inchesOnly: true })} | {r.hardwareSet ? r.hardwareSet.code : '—'} | {/* The ARCHITECT's label for the hardware set (U1B, U1C) — what the reviewer and the hardware submittal both cite — kept beside the Hub's own linked set rather than instead of it. */}setDoor(d.id, { hwSetCode: e.target.value })} className="w-16 px-1 py-0.5 bg-transparent border border-transparent hover:border-[var(--leon-line)] rounded" /> | setDoor(d.id, { leafCode: e.target.value.toUpperCase() })} className="w-14 px-1 py-0.5 bg-transparent border border-transparent hover:border-[var(--leon-line)] rounded" /> | {/* Pre-hung or slab changes the price, the packing and what the installer expects off the truck. */}{R.fireRating || 'None'} {R.fireRating && R.fireRating !== 'None' && R.ratingState !== 'Certified' && req} | {editable && } | |||
| No doors on this project yet. |
Only the fields you set below are touched. Everything else on each door is left exactly as it is.
How would you like to define this opening? Enter either end — the other two are calculated from the frame's own rule, and they stay in step.
{R.modelCode} · {leonDoorModel(R.modelCode).style} — {leonDoorModel(R.modelCode).desc}
)} {step === 'design' && (A {String(R.operation).toLowerCase()} door does not swing, so handing below only says which side it parks on.
)} {doorIsPair(R.operation, R.handing) && (| {k} | {v} |
{blurb}
| {c} | )} {editable && onRemove &&} |
|---|---|
| )} | |
| Nothing here yet. |
Single Home Entrance Doors, the published product reference. A door cites a model by its code, which is what the schedule and the submittal quote.
These are catalog references: a code, a style and a description. They carry no dimensions and no photograph, so they name what was specified and do not drive the drawing — the leaf design, the frame and the sizes are still set on the door. The catalog file is the source and is not edited here.
{m.desc}
Nothing matches.
}A trim is specified in four answers — its design, its width, its thickness and how its corners are joined. Those four are what the shop cuts to.
A door no longer points at a profile here. Each door carries its own trim — design from Supplier Finishes, width, thickness and installation — set on the designer's Frame step. This library is where standard profiles are recorded and compared; it does not drive a drawing on its own.
Parametric, not pictures. The elevation is drawn from these numbers, so changing a groove count or a rail height redraws every door that uses the design.
{catalog.length} door hardware items are in the supplier catalog. Adding one copies its details into the door library; the catalog record stays the source.
A set is a recipe — assigning HW-03 to forty doors fills in every item on all forty.
A type is the standard; a mark is the door. Forty doors can point at TYPE A, and changing TYPE A reaches all forty — except any door that set its own value, which stays as it is.
Standard configurations, ready to use. Each is a real configuration — pick one and the size, frame and opening rule are already right — not a picture to copy.
Point this at the architect’s door schedule — Excel or CSV. It reads the rows, maps the columns to door fields, matches each row to a door type where it can, and shows you everything before a single record is created.
Mapping is guessed from the column names. Only Door mark is required — anything left unmapped simply comes from the door’s type instead.
| Mark | Type | Leaf | Handing | Fire | Location | Notes | |
|---|---|---|---|---|---|---|---|
| setSkip(e.target.checked ? skip.filter(x => x !== p.i) : [...skip, p.i])} /> | {p.door.mark || —} | {p.matchedTypeCode ? {p.matchedTypeCode} : p.typeCode ? {p.typeCode} ? : —} | {p.door.leafW && p.door.leafH ? `${fmtDim(p.door.leafW, system, { inchesOnly: true })} × ${fmtDim(p.door.leafH, system, { inchesOnly: true })}` : from type} | {p.door.handing || —} | {p.door.fireRating || —} | {p.door.location || ''} |
{p.notes.map((n, k) => (
{n.msg}
))}
{p.suggestions.map((sg, k) => (
{sg.raw} → suggested {sg.suggested} (not applied)
))}
|
A mark already on this job is updated, not duplicated — a re-issued schedule is the normal case. Abbreviations are only ever suggested; nothing is substituted for you.
{created} door{created === 1 ? '' : 's'} created{valid.length - created > 0 ? `, ${valid.length - created} updated` : ''} from {fileName}.
They are in the Door Schedule now. Any row that matched a type inherited its size, frame and rule; the rest are waiting for one.