A revised BOM and a completed batch
This example separates the definition used to prepare work from the transaction recording its outcome.
Definition
Assembly A-20 / BOM revision C
Retain the selected source identities and effective context.
Component requirement
Line 20 / RM-8 / 12 kg per 100 kg output
Preserve the quantity basis and line identity before scaling.
Actual usage
Lot L-501 / 11.8 kg
Link actual consumption separately from the planned requirement.
Submission
Manufacturing outcome OP-027
Keep payload, receiver identifier and reconciled status.
Keep the selected BOM revision with the order.
Confirm the NetSuite features, record types and interface available in the account. Do not assume every account exposes the same BOM model or permissions. Agree how the relevant assembly, BOM, revision and manufacturing order are selected, including effective dates and any applicable site or location context.
Preserve a snapshot of the selected definition for the receiving batch workflow. A later source revision should not silently replace the components already reviewed for an in-progress batch. Decide how a change is proposed and reviewed, and retain the source retrieval evidence that explains the definition originally used.
Distinguish component requirements from actual consumption.
Retain the BOM quantity basis, component line identifiers and units before scaling a requirement to an order size. Fixed quantities, proportional quantities, yield or loss assumptions and rounding must follow the configured manufacturing model. A generic multiplication across every line is not a reliable universal conversion.
A component item does not identify the inventory lot consumed. Resolve item master data separately from lot, serial, location and transaction references. Keep planned requirements, issued material and actual usage distinguishable so a reviewer can explain a variance without rewriting the source BOM.
Use existing templates and Script-owned fields.
A useful starting point is a batch or order record linked to a BOM snapshot and its component lines. Use typed fields for quantities and references for items, lots and source records. Preserve the source response as evidence where the workflow needs to reconstruct the import.
Agree which fields the integration owns. Do not overwrite operator notes, formula-derived quantities or review decisions when refreshing source data. Match source line identities rather than relying on row order: a newly inserted component should not cause a different component’s quantity to be updated.
Submit the intended transaction once and confirm its outcome.
If Seal returns material usage or completion, select the supported NetSuite operation for that outcome. Updating the BOM definition is not equivalent to recording a manufacturing transaction. Confirm required order, item, location and lot identifiers, permissions, and the review state that permits submission.
Record a stable operation identity and the submitted payload. A timeout after submission can mean the receiver accepted the transaction even though Seal did not receive its response. Reconcile against the receiving system before retrying an action that could move inventory twice. Keep validation failures and unresolved outcomes visible.
Test it with your data.
Use these cases to agree and test the connection’s behaviour. They are proposed acceptance checks, not completed tests or automatic connector features.
A newer revision becomes effective during execution
The batch started with revision R1. R2 becomes effective before the recorded work is finished.
- Expected behaviour
- Retain the revision selected for that batch. Assess any proposed change explicitly rather than replacing its component requirements on the next synchronisation.
- Evidence to keep
- The original revision reference, order context and any approved instruction for changing the running batch.
The transaction succeeded but its response was lost
A consumption request was sent; the connection timed out before the sender received confirmation.
- Expected behaviour
- Check the destination using the agreed transaction identity before retrying. Keep the outcome unresolved if acceptance cannot be established.
- Evidence to keep
- The submitted quantity, request identity, lookup outcome and destination transaction reference when confirmed.
More checks for this connection
- Import two revisions and verify an existing batch retains the reviewed definition.
- Insert a component line and confirm matching does not depend on row order.
- Test a unit conversion, a fixed quantity and a lot-controlled component.
- Simulate a lost response after submission and confirm reconciliation prevents duplicate transactions.
Before you connect
Is the connection read-only?
The configured scope determines that. Pulling BOM data and submitting manufacturing outcomes require separately agreed operations and permissions.
Does Seal need a separate integration engine for this?
Use the platform’s ordinary Scripts, entities, references and review process. The receiving NetSuite interface and transaction rules still need explicit configuration.
Check your system’s connection options.
Confirm the installed version, available exports and permissions. These pages cover the source interface and link to setup instructions.
For configuration: Seal Scripts and local-file collection.
Start with one export.
Bring the source evidence and the records it needs to connect to. For this workflow, a useful starting pack is:
- The assembly, BOM and revision records for one known manufacturing order.
- Revision effectivity, component identifiers, quantities and units.
- An example consumption transaction and the external identity used to reconcile its outcome.