Module Serial Numbers From Factory to Site: Connect NetSuite With a Supabase Delivery and Acceptance Register

What this looks like in modular and prefab building supply and installation

A modular supplier ships a building in several loads. One module reaches the site, another remains at the factory, and a third arrives with a condition issue. The customer accepts only the first portion. A project-level delivered flag cannot represent this state. A useful register lets logistics, project management and finance see each module's location and evidence while preventing a shipment notice from becoming customer acceptance.

Records, ownership, and update rules

Work through the process

1. 01
   Use one persistent module reference

   Carry the module ID from factory records through shipping and site documentation. Keep design revision and customer project reference as related attributes rather than replacing the identity when the specification changes. Decide how labels and corrected identifiers are reviewed before the first shipment.
2. 02
   Model events instead of one status

   Represent released, dispatched, received and accepted separately, with the source and time of each event. Several modules in one project can be at different stages. The current summary can be derived from those events, but the underlying history should remain available for reconciliation.
3. 03
   Validate the ERP and register boundary

   Confirm the NetSuite objects or custom records used for module identity and approved project context. Check their actual read and write support. A register can begin with visibility and reviewed event submissions while a particular downstream operation remains outside the automated scope.
4. 04
   Control who can submit evidence

   Use Supabase grants and row policies for factory, logistics, site and customer roles. A user permitted to record receipt should not automatically be able to approve customer acceptance. Keep integration credentials separate from client access and test project-level isolation.
5. 05
   Reconcile partial and corrected events

   Allow receipt and acceptance to cover specific modules, not just the shipment header. If a receiver corrects an identifier or condition, retain the prior event and reviewed correction. Use stable event references so a repeated mobile submission cannot create duplicate custody or acceptance records.
6. 06
   Support an authorized correction without rewriting custody

   If a receiver submits the wrong module ID, record a correction that points to the original event and the verified module. Preserve who reviewed the change and why. Replacing the event in place can make the transport and acceptance history impossible to reconcile. The current register should show the corrected state while logistics and finance can still trace how the original shipment was recorded and resolved.

Handle the exceptions explicitly

One load contains modules for different projects

Associate each module with its own project and authorized receiving scope.

Receiver notes damage

Record condition and the accepted or held scope separately from physical arrival.

Module label is corrected after dispatch

Preserve the cross-reference and audit trail instead of creating an unrelated replacement record.

What to verify before expanding

• Each module retains its identity from factory to site.
• Shipment, receipt and acceptance remain separate events.
• Users can act only on their authorized projects and roles.
• Duplicate submissions do not create duplicate acceptance evidence.

Technical references

• Stacksync NetSuite connector and object support
• Stacksync Supabase connection setup
• Supabase row level security