Connect the NetSuite revision, its component lines and the batch
Start with one assembly, its selected BOM revision and one component. Seal can retain that manufacturing definition beside the actual material use, so a batch review can explain both what was required and what happened. The first implementation task is to keep the source identities and quantity basis intact.
Choose 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}. Oracle: BOM Revision REST record.
In Seal: Retain the revision and BOM identities, the retrieved component population and the retrieval evidence with the receiving batch. Confirm the account’s available fields and operations in its REST API Browser.
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. Oracle: Creating BOM Revisions.
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.
Retrieve one complete BOM revision before building the exchange
Use a sandbox BOM that the manufacturing owner can also open in NetSuite. The first useful result is a captured revision whose component population and quantity basis agree with the source. Once that works, 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.
Oracle: BOM revision availability and UI location · Oracle: REST prerequisites
Authenticate the integration in this environment
Create or use the agreed integration record and OAuth 2.0 application. Oracle prefers OAuth 2.0 for REST; a UI username and password are not a REST login. In Manage Roles → Permissions → Setup, the access role needs Log in using OAuth 2.0 Access Tokens as well as the required REST and record permissions. OAuth 2.0 Authorized Applications Management serves a different administrative purpose and is not a substitute for token-login permission. Use the account’s SuiteTalk URL from Company Information → Company URLs.
Check: The token, role and hostname must belong to the intended sandbox. Production OAuth authorizations are not copied to a sandbox; sandbox refresh requires authorization again. Record the environment and role with the test, without putting tokens into evidence files.
Oracle: REST authentication · Oracle: OAuth role permissions · Oracle: OAuth environment separation · Oracle: account URL location
Read the revision, then resolve its component resource
Send the read-only request below with the actual revision ID. Inspect the returned JSON before writing a mapping. If the component property contains a resource link rather than populated items, retrieve the linked resource using the same account and authorization. Do not interpret a link-only representation as an empty bill of materials.
Check: Retain the response with its account, request URL and retrieval time. Match each retrieved component to the source revision. Record the number of components and the unit/scaling evidence used to interpret each bomQuantity.
Oracle: accessing subresources · Oracle: retrieving records and body fields
Finish collection reads before reconciling missing records
For paged collection reads, inspect count, hasMore, totalResults and the returned next link. Retrieve the remaining pages. If you construct offsets, Oracle requires the offset to be divisible by the limit. A collection response and a fully retrieved record are different stages of the read.
Check: For a fictional response with count 2, totalResults 3 and hasMore true, the read is incomplete. Reconcile three identities only after collecting the final page; do not remove the third receiving record after seeing the first two.
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 recovery approach for this read-first evaluation.
Scroll across to see every column →
| 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 to a later manufacturing write | The intended transaction and destination evidence | Keep the outcome unresolved until reconciled. A read retry policy does not establish whether a write already posted. |
A read-only request to adapt to your account
Replace the placeholders with your sandbox SuiteTalk hostname, selected revision and OAuth access token in your API client. Revision 215 is the fictional record used below. This request reads a NetSuite record; 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.
Component 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.
Scroll across to see every column →
| 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"
}
}Run 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.
Interrupt a multi-page read
Input: Stop after the first page of a three-record collection, then resume from the saved retrieval state.
Expected: The partial population remains incomplete. Completing the read reconciles the same three identities, with no deletion based solely on absence from an earlier page.
What to bring to the implementation review
Bring the account and role identifiers, one complete revision response, component/unit evidence, a page-completion record if applicable, and the planned-versus-actual batch comparison. With those records, Seal’s implementation team can define the receiving model and any separately required manufacturing transaction without guessing from a BOM name.
Diagnose 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. Oracle: BOM Revision REST 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. Oracle: Creating BOM Revisions.
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 consumption is sent twice after a timeout
Reading bomRevision and posting a manufacturing outcome are different operations.
Use the agreed transaction identity to reconcile destination evidence before another posting. Updating a BOM component quantity is not a consumption transaction.
Apply 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 behavior 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 hostname, enabled REST and Advanced BOM features, integration/role identity and authentication method. Identify the successful read request and response evidence without recording credentials.
Identify the BOM, exact revision and component item/line IDs. Record how linked component resources and pagination were resolved; compare the retrieved 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: Stop after the first page of a three-record collection, then resume from the saved retrieval state. Expected: The partial population remains incomplete. Completing the read reconciles the same three identities, with no deletion based solely on absence from an earlier page. 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 resources, authorization problems and revision changes without inventing an actual-consumption API.
Use 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 retain the 2.50 kg requirement, the 2.40 kg observation and any unresolved destination transaction separately.
Work through consumption recovery →