1Connect the NetSuite revision, its component lines and the batch.
Start with one assembly, its selected BOM revision and one component. Seal’s NetSuite connector reads the revision, and Seal keeps that definition beside the material use recorded in the batch, so a review can explain both what was required and what happened. Reads make no changes in NetSuite. The only supported write is a new inactive BOM revision through the separately enabled BOM API.
2Choose the source route.
Read the selected revision
Oracle exposes the REST record type bomRevision when Advanced Bill of Materials is enabled. A revision can be retrieved at /services/rest/record/v1/bomRevision/{id}.¹
In Seal: Select the revision by its numeric internal ID. The capture includes the parent BOM, revision name, inactive state, effective dates when returned and expanded component item IDs, quantities and unit IDs. Keep that capture with the receiving batch.
Establish the quantity and effective context
The revision carries components and BOM quantities. Oracle documents component units and allows gaps between revision dates, while disallowing overlap.²
In Seal: Resolve the actual selected revision for the batch date and applicable manufacturing context. A missing applicable revision is a selection problem; do not substitute whichever record was most recently retrieved.
Propose a new inactive revision, if needed
NetSuite manages changes to a bill of materials as new revisions with their own effective dates.²
In Seal: With ERP BOM transfers enabled and an explicit writer grant, a Script can preview and submit a new inactive revision under the selected BOM. It does not activate or overwrite revisions, update orders, move inventory or record consumption.
3Retrieve one complete BOM revision before setting up the exchange.
Use a sandbox BOM that the manufacturing owner can also open in NetSuite. Connect it through Seal’s guided NetSuite connector; reads make no changes in NetSuite. The first useful result is a captured revision whose components and quantity basis agree with the source. Then connect it to one Seal batch and test how the receiving record behaves when the definition changes.
Download the first-run procedure and receiving checks
Identify the account, record and manufacturing basis
Record the sandbox account, selected BOM ID, revision ID, assembly, planned finished quantity and unit. Open the revision at Lists → Supply Chain → Bills of Materials. Confirm Advanced Bill of Materials is enabled. Separately check REST Web Services under Setup → Company → Enable Features → SuiteCloud.
Check: Have the source owner show the chosen revision and its components. A displayed BOM name alone is insufficient to identify the revision your request will retrieve.³⁴
Connect with the guided NetSuite connector
In NetSuite, enable REST Web Services and OAuth 2.0 and create an integration record with the Client Credentials (Machine to Machine) grant. Give a dedicated role REST Web Services access and only the View permissions needed, including the BOM revisions, components, items and units. Register an RSA certificate under OAuth 2.0 Client Credentials (M2M) Setup, mapping the integration, entity and role. Then open Settings → Integrations → NetSuite, enter the SuiteTalk host from Company Information → Company URLs, the client ID and certificate ID, upload the private key and choose Test and connect.
Check: The client ID, certificate, role and host all belong to the intended sandbox; sandbox mappings and certificates are configured separately from production. Do not use an administrator role. Keep the private key out of evidence files.⁴⁵⁶
Select the revision and compare its components
Choose BOM revisions and enter the revision’s numeric internal ID; a BOM name or displayed number will not match. Inspect the capture: parent BOM, revision name, inactive state, effective dates when returned and each component’s item ID, quantity and unit ID.
Check: Match every captured component to the revision the source owner showed you. Record the number of components and the unit and scaling evidence used to interpret each quantity. Order lines, lot balances and custom fields are outside the capture, so do not infer them.¹
Locate the request evidence before changing the mapping
Open Setup → Integration → Manage Integrations, select the integration record, then Execution Log → REST Web Services. Compare the request URL, method, status and response with the receiving log. NetSuite displays the request time in its server time zone.
Check: A missing component, a rejected request and a successful request sent to the wrong environment need different fixes. Capture the actual response and time-zone context so another engineer can reproduce the investigation.⁷
Choose the next action from the actual response
Oracle’s error body can contain several entries in o:errorDetails. Keep the machine-readable code and any supplied path with the response. The actions below are a proposed approach for this read-first evaluation.⁸
| Response evidence | What to inspect | Next action |
|---|---|---|
| 401 / INVALID_LOGIN | Token, account and role; Login Audit Trail | Correct authentication before retrying the same read. |
| 404 / NONEXISTENT_ID | Record type, internal ID and environment | Verify the selected source record. Do not turn the failure into an empty component list. |
| 400 / INVALID_CONTENT | detail and o:errorPath, when supplied | Repair the indicated field or reference; retain the rejected request for comparison. |
| 429 / CONCURRENCY_LIMIT_EXCEEDED | Concurrent requests sharing the account | Reduce concurrency and retry with a bounded delay; do not change material identities to work around throttling. |
| No response after submitting a new BOM revision | The transfer ID and its saved receipt | Run the same transfer again to reconcile. A new transfer ID can create a duplicate revision. |
An optional request to check the source response
Seal’s connector handles authentication, so you do not need this request to connect. Use it only to compare NetSuite’s own response with the capture: replace the placeholders with your sandbox SuiteTalk hostname, the revision and an access token issued to your API client. Revision 215 is the fictional record used below; the proposed Seal JSON further down is a receiving design, not a NetSuite request body.
GET https://<account-host>.suitetalk.api.netsuite.com/services/rest/record/v1/bomRevision/215
Authorization: Bearer <access-token>
Accept: application/jsonA successful read is only the first checkpoint. Confirm that the component data was retrieved, the IDs match the intended source account and revision, and the quantity basis is known before calculating a batch requirement.
4Component line 7 refers to item 870; neither is revision 215.
Fictional projection of documented BOM revision fields for one planned finished unit. The quantity basis is supplied separately from the confirmed BOM/item configuration. The destination is a proposed Seal record design, not an API request or a captured customer response.
| Source information | Example identity or value | Why it stays distinct |
|---|---|---|
| Revision identity | 215, scoped to the NetSuite account | Identifies the selected manufacturing definition; it is not the BOM identity. |
| BOM identity | 410 | Groups the definition’s revisions. Preserve the revision actually selected for this batch. |
| Component line and item | Line 7 → item 870 | The line identifies an entry within the revision; the item identifies the material master. Neither establishes an inventory lot. |
| bomQuantity and quantity basis | 2.50 kg per finished unit in this example | Resolve units and scaling rules before deriving batch requirements. Actual use has its own source event. |
The planned 2.50 kg remains in the definition. The 2.40 kg execution event is separate evidence; the 0.10 kg variance can be reviewed without editing the source requirement. Refreshing the definition must not replace the physical-use event or its container reference.
Inspect the source and proposed destination records
Source example
{
"revision": {
"id": "215",
"billOfMaterials": {
"id": "410"
},
"component": {
"items": [
{
"id": "7",
"item": {
"id": "870"
},
"bomQuantity": 2.5
}
]
}
},
"confirmedQuantityBasis": {
"unit": "kg",
"perFinishedUnit": 1
}
}Proposed Seal records
{
"batch": "B-610",
"definition": {
"source": "NetSuite",
"bom": "410",
"revision": "215"
},
"component": {
"sourceLine": "7",
"item": "870",
"plannedQuantity": 2.5,
"unit": "kg",
"basis": "per finished unit"
},
"actualUse": {
"event": "USE-610-007",
"container": "C-610-04",
"quantity": 2.4,
"unit": "kg"
}
}5Run these cases against the proposed Seal mapping.
These are worked test inputs and expected outcomes to verify in your configured connection.
Scale the requirement without changing the source
Input: Use the example requirement of 2.50 kg per finished unit for a batch planning four finished units. Record 9.60 kg actual use across two separate container-use events.
Expected: The proposed Seal batch shows 10.00 kg planned, 9.60 kg used and a 0.40 kg shortfall for review. Both use events retain their containers. NetSuite’s per-unit requirement remains 2.50 kg.
Read the same revision twice
Input: Repeat the same successful read with unchanged component evidence.
Expected: The batch still has one selected definition and its existing component requirements. The second retrieval is recorded as another observation; it does not create another material-use event.
Change the source after the batch has started
Input: In the test fixture, replace the component requirement with 2.60 kg and keep the original 2.50 kg snapshot for the started batch.
Expected: The comparison identifies the changed requirement and affected component. The running batch does not silently acquire a new requirement. A reviewed decision records whether the change applies and preserves the earlier definition.
Search by the displayed number
Input: Try to select a work order by its displayed order number instead of its internal ID.
Expected: No match is returned. Selecting the numeric internal record ID finds the intended record.
What to bring to the implementation review
Bring the account and role identifiers, one complete revision capture, component and unit evidence, and the planned-versus-actual batch comparison. With those records, Seal’s implementation team can define the receiving model without guessing from a BOM name. Order updates, inventory movements and manufacturing activation are outside the NetSuite connector.
6Diagnose the failure from the source evidence.
The BOM revision record is unavailable
The account may not have Advanced Bill of Materials enabled, or the selected role/interface may not expose the record.¹
Establish feature availability and the permitted REST record before designing a parser around an assumed response.
A component appears to change identity after a save
Oracle documents updates to component internal IDs in the AM BOM Operations field when a BOM revision is saved.²
Reconcile a changed revision as a source change. Retain prior line mappings and verify the new component population; a line identifier should not be assumed immutable across every edit.
A new revision may have been submitted twice after a timeout
The BOM API uses the transfer ID as NetSuite’s idempotency key. Submitting the same proposal under a new ID can create a duplicate revision.
Reuse the same transfer ID and run the transfer again to reconcile its outcome. Confirm that only one revision exists before preparing a replacement.
7Apply this to your records
Use this with the NetSuite BOM revision first-run procedure. Retain the actual configuration and evidence, then record what happened in each receiving exercise. Expected behaviour is printed as a prompt; your observed result starts blank.
Download the blank working review
Write your working notes here
Notes stay in this tab and are not submitted. Download them before leaving to keep a copy. Use record references to identify your evidence.
Record the sandbox account, SuiteTalk host, enabled REST and Advanced BOM features, integration record, role and certificate ID used by the guided connector. Note the successful connection test without recording the private key.
Identify the BOM, exact revision and component item IDs. Compare the captured component population with the source revision. Note effective dates and any gaps relevant to the batch.
State the assembly/output basis and each component’s unit and planned quantity. Show the scaling to the planned batch and compare separately with supported actual use. Record the request/error evidence for a missing or conflicting component.
Input: Use the example requirement of 2.50 kg per finished unit for a batch planning four finished units. Record 9.60 kg actual use across two separate container-use events. Expected: The proposed Seal batch shows 10.00 kg planned, 9.60 kg used and a 0.40 kg shortfall for review. Both use events retain their containers. NetSuite’s per-unit requirement remains 2.50 kg. Record the actual input/evidence references, observed result, whether it matches the expectation and any unresolved issue.
Input: Repeat the same successful read with unchanged component evidence. Expected: The batch still has one selected definition and its existing component requirements. The second retrieval is recorded as another observation; it does not create another material-use event. Record the actual input/evidence references, observed result, whether it matches the expectation and any unresolved issue.
Input: In the test fixture, replace the component requirement with 2.60 kg and keep the original 2.50 kg snapshot for the started batch. Expected: The comparison identifies the changed requirement and affected component. The running batch does not silently acquire a new requirement. A reviewed decision records whether the change applies and preserves the earlier definition. Record the actual input/evidence references, observed result, whether it matches the expectation and any unresolved issue.
Input: Try to select a work order by its displayed order number instead of its internal ID. Expected: No match is returned. Selecting the numeric internal record ID finds the intended record. Record the actual input/evidence references, observed result, whether it matches the expectation and any unresolved issue.
Identify the configuration/mapping revision tested, reviewer, open issues and owner for each next action. Cite the retained source and destination evidence. A filled note is not itself an accepted test; record the review decision through your actual process.
Unanswered sections remain marked ‘Not recorded’ in the download.
Evidence needed to finish
The retained revision has the expected component population, each planned quantity has an explicit unit and scaling basis, and the receiving batch points to that definition. Test outcomes identify missing records, permission problems and revision changes. The connector records no consumption in NetSuite.
8Use the connected evidence in a review.
With the selected BOM, component requirement and actual-use event linked to B-610, ask Neil to explain the 0.10 kg variance and identify the supporting source records. The review should keep the 2.50 kg requirement and the 2.40 kg observation separate.