NetSuite BOM revision — first-run working review
WORKING NOTES — review decisions belong in your controlled records.
Guide: https://seal.run/integrations/netsuite

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.

1. Installed configuration and source route
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.
Your evidence and observations:
[Not recorded]

2. Identity and expected population
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.
Your evidence and observations:
[Not recorded]

3. Quantity and receiving evidence
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.
Your evidence and observations:
[Not recorded]

4. Exercise 1: 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.
Record the actual input/evidence references, observed result, whether it matches the expectation and any unresolved issue.
Your evidence and observations:
[Not recorded]

5. Exercise 2: 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.
Record the actual input/evidence references, observed result, whether it matches the expectation and any unresolved issue.
Your evidence and observations:
[Not recorded]

6. Exercise 3: 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.
Record the actual input/evidence references, observed result, whether it matches the expectation and any unresolved issue.
Your evidence and observations:
[Not recorded]

7. Exercise 4: 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.
Record the actual input/evidence references, observed result, whether it matches the expectation and any unresolved issue.
Your evidence and observations:
[Not recorded]

8. Implementation review and next work
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.
Your evidence and observations:
[Not recorded]

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.