Material Status Management System: RFP and 90-Day PoC

If a material status management system has been deployed but people still search the shop floor, reconcile a whiteboard with Excel, and reprint traveller labels, the missing element is not another screen. The identifiers for the physical item, location, status, quantity and label are telling different stories. This guide sets out an RFP, a 90-day proof of concept and acceptance criteria for a Thailand factory. The objective is to answer, from one controlled record: what is this item, where is it now, what state is it in, how much is there, and what may happen next?

Executive conclusion: combine an immutable item ID, an event ledger and a controlled physical label

A reliable system is more than a current-balance table. It assigns identifiers to raw material, work in process, finished goods, containers and pallets. It records receipt, split, merge, issue, operation start, completion, hold, movement and shipment as events with time, location, operator and business reason. Current location, state and quantity are results of those controlled events.

The physical traveller or material label links the record to the object. It needs human-readable identification, a barcode or 2D carrier, a revision and reprint history. The paper is not the system of record: if it is damaged or replaced, the ID and event history must still reconstruct the truth.

An RFP should require five connected controls.

When these controls share one transaction model, production progress visualisation and barcode management become dependable outputs. Building the dashboard first merely displays uncertain data more attractively.

What does shop-floor material status management cover?

It is not only a stock count. Two objects with the same part number may differ by batch, serial, operation, quality disposition, storage condition, owner and release status. A total of 100 pieces might comprise 40 completed at operation 10, 30 awaiting inspection, 20 on quality hold and 10 moving to the next operation. Planning can safely use only the 40 that meet its rule.

Decide the tracking granularity before choosing technology

Finer tracking is not always better. Item-level serialisation creates more labels, scans, events and data. Use a serial where warranty, customer or quality risk requires individual history; a lot where material can legitimately share one history; and a container or pallet ID when objects move together. The decision should balance risk and work content.

Separate at least these identities:

• Material master identity: what the object is, including a controlled specification revision where needed.
• Physical-item identity: the traceable instance, lot or shop-floor unit.
• Handling-unit identity: box, tote, rack, trolley or pallet.
• Location identity: site, warehouse, zone, rack, machine buffer, inspection or hold area.
• Work-order identity: why the object is being consumed, processed or moved.
• Event identity: the unique receipt, move, split, merge or state change.

Do not make one string such as “12345” mean a part, an item and a rack depending only on the screen. A prefix, data type, validation and master lookup should identify what has been scanned.

Keep current state and immutable history distinct

The application may maintain current location, status and quantity for fast queries, but it also needs the event that created each value. Record who acted, on which device, when, against what previous value and with which business instruction. Corrections should be reversal or adjustment events linked to the original, not silent overwrites.

This aligns with the event-oriented principle in GS1 EPCIS. EPCIS enables applications to create and share visibility events about identified objects—what happened, when, where and in what business context. A factory does not have to implement EPCIS to benefit from the model, but an event ledger is easier to integrate later. GS1’s standards repository lists EPCIS 2.0.1 as published on 1 July 2025.

How this differs from work-in-process inventory analysis

Work-in-process analysis asks where units wait, for how long and at which bottleneck. This article addresses the prerequisite: whether the object, physical label, location, state and quantity are internally consistent.

For bottleneck and ageing metrics, see WIP inventory management for Thailand factories. This guide deliberately concentrates on identity and transaction integrity instead of repeating those WIP KPIs.

Design the serial, lot and handling-unit identifiers

Avoid encoding every business attribute in the ID

An ID containing factory, part, date, line and sequence appears readable but becomes misleading after a line transfer, date correction or site consolidation. Prefer an immutable unique key and store changeable attributes separately. A short display ID may coexist with an internal immutable ID, but the RFP must state which is used on labels, APIs, CSV files and terminals.

Use lots and serials for different risks

A lot identifies a group managed under common conditions; a serial distinguishes one instance. A lot number alone does not identify the quantity or location of each separated container. Once a lot is split between two totes, each tote needs a material-unit or handling-unit identity linked to the common lot.

GS1 Application Identifiers define, among others, AI (10) for batch/lot, AI (21) for serial, AI (00) for SSCC and AI (01) for GTIN. Whether a particular factory must use GS1 depends on industry and trading requirements. The useful design principle is that the data carrier should unambiguously state what each identifier means.

Preserve genealogy through splits and merges

When 100 kg is split into 60 kg and 40 kg, do not overwrite the original record. Close or mark the source as split, create two new item IDs, and retain the parent-child relationship. A blend of multiple lots similarly links each input to the new output.

Use a conservation rule as the default:

quantity before split = quantities after split + recorded sample, loss or scrap

Processes with conversion, moisture, rounding or variable yield need a documented tolerance and reason. A generic “inventory adjustment” that closes any difference can conceal missing scrap or incorrect consumption.

Update location, state and quantity as one business transaction

Common failures are partial: location changes while quantity remains in the source, a label prints while the status remains obsolete, or an ERP issue succeeds while the mobile transaction times out.

Treat in-transit as a legitimate state

Changing the destination location at dispatch says the material has arrived when it may still be on a forklift. Leaving it at the source makes the moving item invisible. Risky or long movements should use dispatch, in-transit and receipt. A short, controlled one-way move may use one scan. Choose by handover risk, distance and intermediate storage rather than applying two scans everywhere.

Enforce a state-transition matrix

Do not accept free-text status. Define source state, destination state, role, reason and approval.

The server must reject issue of held material and shipment of incomplete material. A visual warning is insufficient because integrations and bulk uploads could bypass it.

Make retries idempotent

Industrial Wi-Fi can lose a response after the server has committed a movement. If the terminal retries, the same business transaction must not double the quantity. Give every command a unique transaction ID; a repeat with the same ID returns the same outcome.

Offline-first is not synonymous with safe conflict handling. Microsoft’s Power Apps documentation explains that local updates are queued and synchronise when connectivity returns. It does not claim that this alone guarantees business consistency. A quantity or quality conflict should be quarantined for authorised resolution rather than silently accepted.

Material label issuance is a controlled process, not a print button

Decide what the label carries

A typical label may show item ID, part number and description, lot/serial, quantity and unit, quality state, current or next operation, issue time and label revision. It may also require expiry, inspection date, customer order, storage or hazard information.

Do not encode every changing value. A good default is to encode an immutable identifier and retrieve current status after scanning. Otherwise every move requires a replacement label. Add offline attributes only where the business case requires them and control their version.

Accept barcode performance under real conditions

GS1 describes barcodes as carriers for keys identifying products, shipments and locations, with attributes such as serial, lot and dates. Selecting a valid symbology is only the beginning. Test label stock, ribbon, printer resolution, oil, powder, condensation, curved surfaces, mounting position, distance, lighting, gloves and device cameras.

Create boundary samples: creased, rubbed, faded, partly contaminated and exposed to relevant temperatures. Acceptance should record first-read success and scan time by condition, not only show that one pristine sample works.

Link reprint to invalidation of the old label

An unrestricted reprint can create two physical labels for one identity and allow one to be attached to another object. Capture reprint reason, operator, time, printer, previous label and new issue. Recover or destroy the old copy, or mark its issue number invalid in the system.

If multiple physical copies are genuinely needed, assign a copy number or purpose. Distinguish multiple controlled copies for one object from assigning one identity to different objects.

Derive production progress from trustworthy events

Operation start, completion, inspection and receipt events can be aggregated against the work order. A useful board highlights exceptions: planned start passed but no input, completion without arrival at the next operation, unresolved hold, missing label, stale item or unsynchronised event.

Executives need delivery impact and value on hold; supervisors need the next hour’s shortages and wrong-route arrivals; operators need the next valid action. One event source supports all three without forcing one dashboard on every role.

Define timestamps before measuring lead time. “Start” could mean first material scan, machine cycle start or operator confirmation. “Finish” could mean last piece, inspection release or handover. The RFP must fix the event meaning.

ISA describes ISA-95 as a family of standards for the interface between manufacturing operations and enterprise functions, especially level 3 manufacturing operations management and level 4 business planning/logistics. Use that boundary to decide, for example, that ERP owns orders and valuation while MES or the material-status service owns shop-floor events. For broader product selection, see production management system comparison for Thailand.

Write an RFP that vendors can price and prove

“Barcode ready”, “real-time dashboard” and “ERP integration” are not comparable requirements. Provide common scope, data, scenarios, exceptions, migration and tests.

Scope and system boundaries

List sites, buildings, stores, operations, part families, shifts, users, devices, printers, networks and connected systems. State whether phase one covers receipt-to-shipment or two or three inter-operation movements.

For each master and transaction, name the system of record. State which fields this application may edit, acceptable synchronisation delay and the contingency during an outage.

Data dictionary

For every field define meaning, data type, length, mandatory status, unit, code list, owner, update rule and retention. Quantity needs base unit, display unit, conversion and rounding. Time needs time zone and a rule for device versus server clocks. Location needs in-transit, inspection, quarantine and external processor where applicable, not a permanent “other” bucket.

Business scenarios

Require end-to-end descriptions and demonstrations for:

1. Receipt and initial label issue.
2. Allocation and issue to a work order.
3. Start, partial completion and full completion.
4. Split, merge and unit conversion.
5. Dispatch, arrival and overdue in-transit material.
6. Inspection, hold, release, nonconformance, rework and scrap.
7. Damaged or lost label, reprint and replacement.
8. Mis-scan, duplicate scan, reversal and correction.
9. Wi-Fi, server, printer and synchronisation failure.
10. Physical count, investigation, approval and close.

Non-functional and security requirements

Define response time, scan-to-commit time, concurrency, daily event volume, retention, backup, recovery objectives, monitoring, audit, roles, encryption and vulnerability management under stated device, network and peak-load conditions.

NIST IR 7693 describes constructs, a data model and methods for uniquely identifying assets from known identifiers or asset information. Its subject is IT asset management, not a shop-floor material specification, but it is a useful reminder that an identifier requires governance and interpretation—not just a number format.

Acceptance requirements

Agree scenarios, test records, preconditions, expected outcomes, evidence, pass/fail and retest before contract award. Test duplicate lots, fractional quantities, long descriptions, Thai and Japanese text, invalid masters and degraded labels using factory-like data.

A 90-day proof of concept in three evidence-building phases

A 90-day PoC is not a rushed enterprise rollout. It reduces uncertainty about identity, operator work, connectivity, integrity, benefit and scaling cost on a bounded flow.

Days 1–30: baseline and design

• Limit scope to one site, one line or two to three representative operations.
• Walk the physical flow and observe searches, reconciliation, reprints and handwritten corrections.
• Approve granularity, locations, states, quantity rules, label format and exception codes.
• Trial stock, printer, scanner, device and Wi-Fi in the actual environment.
• Define minimum ERP/MES interfaces and the temporary PoC system of record.
• Capture baseline method, sample size and conditions.

The highest-value output is a shared definition, not an early screen. Operations, quality, planning, warehouse, maintenance and IT should decide while looking at the same physical examples.

Days 31–60: operate normal and priority exception flows

• Run receipt, label, move, start, completion, split and hold in daily work.
• Deliberately test duplicate scans, damaged labels, reprints, disconnection and printer failure.
• Review scan time, manual entries, failed sync, rejected transitions and reversals daily.
• Record workarounds and refine layout, work instructions and training weekly.
• Link every specification change to an issue and revision.

Define a brief parallel-operation period and the fallback record. Endless double entry distorts results; an abrupt shutdown of the old process can expose production to an immature system.

Days 61–90: accept peak, failure and scale

• Run a representative peak and shift handover.
• Test concurrency, API delay, Wi-Fi loss, device replacement and backup restoration.
• Reconcile physical item, label and application record in a count.
• Ask a supervisor to reconstruct an exception from event history.
• Measure effort to add a part, operation, location and printer.
• Price remaining gaps, production rollout, training and support.

PoC metrics and measurable acceptance criteria

Targets should derive from the baseline and business risk. The following values are illustrative RFP wording, not market benchmarks or TOMAS TECH guarantees.

A percentage without a denominator and test condition is not acceptance. Two mismatches in 1,000 may pass 99.8%, but a held item issued to production is a critical failure. Separate frequency from severity.

Essential acceptance scenarios

1. Move one item to two locations concurrently from two devices.
2. Attempt a split whose outputs exceed the source quantity.
3. Attempt to issue held material.
4. Reprint a label and scan old and new issues.
5. Make an offline movement, change status elsewhere, then synchronise.
6. Cancel a work order in ERP while a terminal holds an old copy.
7. Print Thai names and Japanese remarks repeatedly.
8. Restore a backup and reconcile the final confirmed event.
9. Retry the same API transaction and prove it posts once.
10. Reverse an event while retaining original record and reason.

Select barcode, RFID, devices and printers by the use case

A linear barcode can be efficient for a short immutable ID and may fit existing readers. A 2D symbol carries more data in less area but needs appropriate module size, print quality, surface and reading distance. Choose by data, space, distance, installed base, customer requirement and applicable standard.

The GS1 General Specifications are the core rules for GS1 keys, attributes and barcodes. For material entering external commerce, confirm requirements with trading partners and the relevant GS1 Member Organisation rather than inventing a private format.

RFID can read multiple tags without line of sight and may suit reusable containers or a portal. It also requires tests around metal, liquid, tag position, read zone, stray reads, interference and cost. Compare barcode and RFID on the same representative items, measuring misreads, association effort, durability and exception work—not just nominal read rate.

Devices must be evaluated with gloves, drops, dust, liquid, temperatures, batteries, language switching and shift patterns. Accept printer consumable changes, head cleaning, template distribution, queue recovery and destruction of bad output. Define a temporary label and later reconciliation if the printer is unavailable.

Allocate responsibility across ERP, MES and the material system

Do not copy ownership everywhere. A practical allocation is:

Messages need message ID, business transaction ID, event time, creation time, source, retry and result code. Monitoring must show pending, held, retrying and business-error transactions—not merely that the API server is online.

Thailand factory operating requirements often missed

Multilingual design is more than translated buttons. Use one approved glossary across screens, alarms, work instructions, labels, states and training. A Thai, English and Japanese synonym must map to the same code. Part code should remain stable while searchable display names can be language-specific.

Shift handover should expose open movements, holds, failed sync, printer problems and temporary labels with owner and next action. Changes to racks, operations, label stock, devices, Wi-Fi or ERP fields require impact assessment, effective dates, testing, training and rollback.

Build a cautious business case

Benefits may include less searching, transcription, reprinting, counting, mis-issue, held-material use and exception investigation. Time saved is not automatically cash: it becomes financial benefit only when overtime, staffing, delay or constrained capacity changes.

Illustration only: if 30 people spend 12 minutes per day searching or reconciling, across 250 working days at an assumed labour cost of THB 180 per hour, the annual time value is 30 × 0.2 × 250 × 180 = THB 270,000. Replace every assumption with measured PoC data. Do not double-count the same saved minutes as both labour saving and capacity gain.

Cost includes software, configuration, integration, devices, printers, labels, Wi-Fi, master-data cleansing, migration, training, support, replacements and consumables. Compare three-to-five-year total cost and the organisation needed to maintain masters and exceptions.

Common failure patterns

• Believing a label creates traceability. The scan must invoke a defined business event and validation.
• Migrating only an Excel balance. Reconcile physical objects, locations, states and obsolete labels first.
• Testing only the happy path. Damaged labels, fractions, reversals, outage and hold release determine usability.
• Adding manual input to improve visibility. Derive fields from identity and show only allowed next actions.
• Ignoring paper contingency. Control temporary IDs, owner, time and recovery entry sequence.

FAQ: material status systems, traveller labels and barcode management

What is a material status management system?

It identifies raw material, WIP, finished goods and handling units, then controls location, state, quantity, operation, label and change history. Its defining capability is the event trail behind the current balance.

What must be controlled when issuing a material label?

Control the item ID, template revision, issue number, operator, time, printer, reprint reason and invalidation of the old issue. Prefer an immutable ID in the symbol and retrieve changing status from the system.

How does it enable production progress visualisation?

Start, completion, inspection and arrival events are aggregated by work order. Progress is reliable only after event meanings, item-to-order links and timing rules are fixed.

Is a QR or 2D code enough to build a barcode management system?

No. The carrier is only the entry point. Numbering, transitions, quantity, roles, reversals, reprint, devices, printing, network behaviour and ERP/MES integration are also required.

What should a 90-day PoC cover?

A representative line or two to three operations, key item types and major exceptions. Include split, hold, reprint, outage and shift handover, not only normal movement.

What are good acceptance criteria?

Measure first-read success, location agreement, quantity conservation, forbidden transitions, duplicate prevention, reprint control, history reconstruction, response and recovery under stated conditions.

Barcode or RFID—which is better?

RFID may help with multiple non-line-of-sight reads and reusable assets; barcodes may be simpler, visible and economical. Test metal, liquid, read zone, stray reads, durability and exception work on actual objects.

Summary: accept a system in which the object and record describe the same fact

The objective is not to attach more barcodes or draw a prettier map. It is to keep item and handling-unit IDs, location, state, quantity, physical label and business events consistent. The RFP should define the data dictionary, transitions, split/merge, reprint, offline conflict, ERP/MES ownership and scenario-based acceptance. The 90-day PoC should establish definitions and baseline in the first month, exercise normal and exception flows in the second, and prove peak, recovery and scalability in the third.

TOMAS TECH can support current-state observation, identifier and label design, RFP development, a 90-day PoC, barcode/RFID selection, ERP/MES interfaces and acceptance tests for factories in Thailand. A team may contact us while still comparing requirements and retaining its existing Excel process.

References

• GS1 Global Traceability Standard
• GS1 traceability standards
• GS1 barcode standards
• GS1 Application Identifiers
• GS1 General Specifications
• GS1 EPCIS 2.0.1
• ISA-95 Standard
• OPC UA Common Object Model: ISA-95
• Microsoft Power Apps mobile offline overview
• NIST IR 7693: Specification for Asset Identification 1.1