A commercial project that spreads one tile order across several rooms, floors, or buildings needs a way to know which lot went where, before a shade variation or a shortage forces a decision under pressure. Without a controlled register, procurement and site teams are left reconstructing that history from delivery notes and memory, at the exact moment a replacement or claim decision cannot wait.
Define the Register Scope and Batch Unit
The first decision is not a template but a definition: what counts as a batch, and at what level the project will track it. Piastrelle in ceramica – Parte 1: Requisiti per le prove sulle piastrelle treats batching as part of the sampling and inspection basis for ceramic tile, which means batch identity is not a shipping convenience but a condition tied to how the product was tested and accepted in the first place. If the project treats a batch as “whatever arrived on one truck,” it will merge material that the supplier itself did not treat as one production group. If it treats a batch as the supplier’s own declared production lot, it inherits a narrower and more defensible unit, but one that may not align neatly with how areas are scheduled or how pallets are broken down on site.
Before any register field is populated, the project should fix four things: which project the register covers, which supplier item numbers are in scope, which order line each item belongs to, and which installation area each line is expected to serve. These four coordinates are what later let the register answer a shade or performance question by area rather than by shipment alone. Where a project has one supplier item feeding multiple areas, the register scope must anticipate that a single order line will need to be split across area records later; where each area draws from a distinct order line, the register can stay simpler because the order line and the area are already the same unit.
The register also needs an owner and a boundary on what “in scope” means. A register that tries to track every packaging detail becomes unusable; a register that tracks only order lines cannot answer the questions a site team asks when a pallet does not match its paperwork. The scope decision should state explicitly whether the register follows material only to receiving, or continues through installation and into post-installation replacement stock, because that boundary determines whether the register can later answer a claim or warranty question without a separate reconstruction effort.
Trace Each Order Line Through Lot, Pallet and Carton
Once scope is fixed, the register needs a consistent chain linking the commercial record to the physical material. Documentazione tecnica di RAKO describes batch identity as something that appears across client documents, pallet labels, packages, and delivery notes, which is the practical basis for building a chain from purchase order line, to supplier item, to declared production lot, to pallet, to carton group. Each link in that chain should preserve the supplier’s own code and legend rather than a project-invented shorthand, because a translated or simplified code loses the ability to match back to the supplier’s own records if a question arises later.
This chain matters because the failure point in most multi-area projects is not the order line, which is usually clear, but the gap between the pallet as received and the area as installed. A pallet can contain more than one production lot if the supplier’s packing practice allows it, and a single production lot can be split across multiple pallets. If the register only records “pallet number” without also recording the lot declared on that pallet’s label, a shade or caliber difference discovered during installation cannot be traced back to a specific production run, only to a physical unit that may already have been broken apart and distributed to more than one area.
| Register field | Source record | Decision use | Status convention |
|---|---|---|---|
| Project and PO line | Current purchase order | Fix the commercial scope | Confirmed or open |
| Supplier item and description | Supplier product record | Preserve product identity | Confirmed or mismatch |
| Production-lot code | Supplier declaration or batch document | Define the traceable manufacturing group | Declared or unconfirmed |
| Pallet and carton identifiers | Physical labels and packing record | Locate material within the shipment | Reconciled or exception |
| Shade, caliber and quality fields | Supplier legend and labels | Screen area compatibility | Matched, separated or review required |
| Sample and revision reference | Approved sample record and project specification | Connect the decision basis | Current or superseded |
| Planned and actual area | Area schedule and receiving/allocation record | Control where each lot is used | Planned, allocated, received or installed |
| Evidence and disposition | Inspection or receiving record | Preserve release, segregation or hold status | Dated decision |
The register fields above give a structure, but the judgment is in how the project applies the status conventions. A “declared” lot code is only as reliable as the label it came from; where a carton’s label is missing or damaged, the register should record that gap as an exception rather than infer the lot from a neighboring carton. A project reviewing a supplier’s item record, such as the Gres porcellanato di lusso VGL1172008 product page, should confirm that the item description and the quality or caliber fields in the register match what the supplier lists, since a mismatch at this stage is the cheapest point at which to catch it.
Add Sample, Revision, Area and Evidence Fields
A register that only identifies material does not tell the project whether that material was approved for use, or where it was approved to be used. UFGS 01 33 00 requires that controlled project records identify the project, the revision in effect, the product, and the location, which is the basis for adding four categories of fields beyond pure identification: the approved sample or reference the material is being checked against, the specification revision current at the time of approval, the planned installation area, and the evidence or disposition status attached to the material.
These fields exist because identity and approval are different questions. A production lot can be correctly identified and still be unsuitable for a given area if the sample it was checked against has since been superseded by a specification revision, or if the area it was received for has changed since the order was placed. Where a project specification is revised after material has already been ordered against an earlier revision, the register needs to show which revision governed the original approval, so that a later reviewer can tell whether the material in hand was approved under current requirements or under a version that no longer applies.
The evidence field carries similar weight. Recording that a lot was received is not the same as recording that it was released for installation, held pending inspection, or segregated because of a discrepancy. A register that collapses these into a single “received” status loses the distinction between material that is simply on site and material that has been cleared to use. Where the project defines area as a fixed field tied to the original order line, and a lot is later redirected to a different area, the area field must be updated as a new record, not silently overwritten, because that is the point at which allocation history and identification history diverge. Fields that are not yet known, such as a revision not yet confirmed with the supplier or an evidence status still pending inspection, should be labeled as unknown or pending rather than filled with an assumed value, since a guessed entry is harder to correct later than an acknowledged gap.
Record Allocation Changes Without Overwriting History
Material identified correctly at receiving does not necessarily stay where it was first assigned. Pallets get split between areas when quantities run short in one location and surplus in another. Substitutions happen when a specified item becomes unavailable and a project accepts an alternate. Shortages trigger partial allocations that get topped up later from a different lot. Replacement stock, ordered after initial installation to cover damage or future repair, may or may not match the original lot depended on what was available when it was ordered. Each of these is a movement, not a correction, and the register needs to record it as a dated event rather than as an edit to the original allocation.
The distinction matters because a register that overwrites a field to reflect the current state loses the ability to explain how that state was reached. If an area record shows only the lot currently installed, a later question about why an adjacent area shows a different shade cannot be answered from the register alone; the project would need to reconstruct the sequence of splits and substitutions from other records, if those records still exist. A dated movement log, even a simple one, preserves the sequence: which lot was originally allocated to an area, what quantity moved, when, and under whose decision.
This is also where allocation across areas needs to be an explicit decision rather than a default. A lot that arrives as one unit does not become multi-area material just because it was physically split on site; it becomes multi-area material when the project decides, and records, that a specific quantity from that lot is now assigned to a second area. Where that decision is not documented, a later reviewer has no way to distinguish an intentional allocation from an undocumented mix-up, and the two carry very different implications if a shade or performance question surfaces after installation.
Replacement stock deserves particular attention in this log. Stock ordered months after original installation, intended to match existing material for future repairs, should be logged against the area it is meant to serve, with its own lot identity, rather than merged into the original area record as if it were part of the same delivery. Where the replacement lot differs from the original, the register should preserve both identities and the date the replacement was added, since that gap is precisely the information a future repair decision will need.
Reconcile the Register at Each Project Handoff
A register that is only updated when someone remembers to update it drifts from the physical material it is meant to describe. Reconciliation points anchor the register to specific moments in the project sequence rather than to any consistent update habit. Four points recur across projects with multiple areas: pre-shipment inspection, when the supplier’s declared lots are checked against what is about to ship; receiving, when the physical pallets and cartons are checked against the shipment paperwork; area release, when material is confirmed as approved for a specific installation area; and installation handoff, when responsibility for the installed material passes from one party to another.
Each of these points asks a different question of the register. Pre-shipment reconciliation asks whether the declared lots match what the order line expects, before quantity and area allocation become relevant. Receiving reconciliation asks whether the physical pallets and cartons match the shipment record, and flags any pallet whose label does not match its paperwork as an exception rather than resolving the discrepancy by assumption. Area release reconciliation asks whether the lots assigned to an area still match the sample and specification revision current for that area, given that time may have passed between order and installation. Installation handoff reconciliation asks whether the register’s area and evidence fields reflect what was actually installed, including any late substitutions or splits recorded in the movement log.
Where a project treats these as one combined check at the end, discrepancies from earlier points compound and become harder to trace to their source. Where the project reconciles at each point separately, a discrepancy is caught closer to where it originated, and the register’s movement log carries less weight because fewer changes accumulate before they are checked. The exact batch codes, document formats, quantities, project zones, responsible parties, and retention period the register uses still need to be agreed for the specific order; a register structure and a reconciliation sequence do not substitute for that agreement, and confirming it early is what determines whether the register can answer a replacement-stock question without reconstructing history from scratch.
Domande frequenti
Q: Can one production lot be assigned to several project areas in the batch register?
A: Yes, through an explicit project allocation decision. Keep the declared lot connected to its order line, pallets and carton groups, and show the quantity and planned or actual area for each allocation. This preserves the common source identity while making the use of material in each area visible.
Q: How should we record a split pallet or a transfer between areas?
A: Record a dated movement that preserves the original lot, pallet and carton connections. Show the changed allocation rather than replacing the earlier area entry without history. At the next receiving, area-release or installation handoff, reconcile the movement and quantities so the register describes where the material actually went.
Q: The supplier has not confirmed the batch code yet. Can we use our own assumed code to finish the register?
A: Mark the production-lot identity as unconfirmed rather than guessing the supplier’s code. Define what the project means by a batch and request the original declaration and code legend. The register can distinguish known order and area information from the missing lot link without presenting an invented identity as confirmed evidence.
Q: Does a complete batch register mean the tile is approved for installation?
A: Completeness of the identity chain is only part of the decision. The register also needs the current sample and specification references, linked inspection or receiving evidence, and a dated release, segregation or hold disposition. Review those fields together so traceable material is not mistaken for material already released for the intended area.