The quick answer
On a dynamic-mode record, commitLine applies the selected line’s edits to the in-memory record. It does not persist the separately loaded transaction. Call its save method, retain the returned internal ID, and load a new record object to verify the intended line and value. This guide executes that distinction only in a local stand-in.
This walkthrough executes supplied JavaScript against a limited local N/record stand-in. Its purchase-order page reads the local backing store. It verifies the missing-save distinction in that model, without reproducing native Suitelet execution, permissions, validation, sourcing or account automation. The original forum author still reported an issue after adding save and correcting a permission error; their later date-format recollection was uncertain. This is not a confirmed full resolution of that case.
Before you start
The fictional PO6427, internal ID 6427, has two existing rows. Pressure Manifold, item 1452, is the first row, index 0, with quantity 4 at 100.00. Valve Housing is the second row, quantity 2 at 60.00. The total is 520.00. Their expected receipt dates are 11/02/2026 and 11/06/2026. All dates in this local exercise use MM/DD/YYYY.
The source uses new Date(2026, 10, 9) for November 9. JavaScript months start at zero; this is not a locale-parsing exercise. This N/record setter takes a valid Date object for a date field. The model deliberately does not implement native role checks, mandatory-field validation, sourcing, workflows or user events. Passing ignoreMandatoryFields: false expresses intent; it does not add those native checks to the model.
The two rows stay fixed throughout. Real form parameters need integer and bounds checks plus a stable line-selection strategy. Item ID alone is insufficient when an item appears on multiple lines. Reordering, insertion, deletion and concurrent edits are outside this exercise.
01. Identify the line
Open the local purchase-order view for PO6427 and identify both rows in Items. Scroll the grid horizontally to Expected Receipt Date. The first row is 11/02/2026; the second is 11/06/2026. The source will log item 1452 when it selects the known first row.
02. Inspect the unsaved change
Open po_line_date.js in the local Code Editor. It dynamically loads the purchase order, selects line 0, sets the target Date and calls commitLine. A comment marks the absent record save; the following load still reads the stored record.
Click Run local harness. Inspect the three states:
- Current date: 11/09/2026 — the selected line buffer.
- Committed date: 11/09/2026 — the line in the loaded record after commit.
- Reloaded date: 11/02/2026 — a fresh read of the model's unchanged saved store.
Model save calls: 0 explains the difference. In this model, the line commit changed the in-memory record, but no save call updated its stored record.
03. Recheck the stored baseline
Reopen the same local purchase-order view. Its first expected receipt date remains 11/02/2026, and the second remains 11/06/2026. Run local harness uses an isolated copy of its inputs. It has no connection to the page's separate backing store, even when the source later calls save inside that sandbox.
04. Save the loaded record
Replace the comment with the record save, and use the returned ID in the next load:
const savedId = po.save({ignoreMandatoryFields: false});
const check = record.load({type: 'purchaseorder', id: savedId});
This code belongs after po.commitLine({sublistId: 'item'}) in the displayed onRequest function. The po variable is the dynamically loaded record; record is the imported N/record module.
Run the isolated harness again. It now reports Reloaded date: 11/09/2026 and Model save calls: 1. That is a fresh read after a save in the sandbox, not a native account result or a change to the purchase-order page.
05. Run the saved source
Click the editor's Save, then Run local exercise. File Save retains source bytes. The exercise executes those exact bytes against the local record backing store and writes only records computed by the source's save calls.
Confirm Reloaded date: 11/09/2026 and Local backing store updated: 1 record(s). No file was uploaded to a File Cabinet and no script was deployed to an account.
06. Verify the readback
Reopen and reload the local purchase-order view for PO6427. Its first expected receipt date is now 11/09/2026; the second stays 11/06/2026. Scroll back to identify both rows and confirm quantities 4 and 2, rates 100.00 and 60.00, and total 520.00. This local page reads the computed local saved record.
Common questions
Does commitLine save the transaction?
Record.commitLine commits the selected line on a dynamic-mode record. Record.save saves the separately loaded record and returns its internal ID. A successful line commit alone does not establish persistence.
Why inspect both current and committed values?
Current date and Committed date are local log labels. The code reads getCurrentSublistValue before commitLine, then getSublistValue on the loaded object afterward. Loading a new record object after save checks the saved state. Inspect the same record and intended line at each stage.
Why does Run local harness not change the purchase-order page?
It uses an isolated store. Its save call changes only that sandbox. Run local exercise executes the saved source against the separate local backing store used by the page. The two exercises have separate boundaries; neither proves native account execution.
Is the editor's Save the same as po.save()?
No. The editor's Save retains a JavaScript file. po.save() is an API call inside that source. Saving the file does not execute it or persist a purchase order.
What if save throws a permission or validation error?
Record the actual error and verify the effective runtime role, restrictions, editable field and account validation. Do not assume that a developer's administrator session proves the deployment's access. The local model does not test these rules, and granting Full permission is not a general fix established by this lesson.
What if save returns an ID but a fresh load is unchanged?
Confirm the returned ID, the same intended line, field ID and valid date value. Check whether sourcing or account automation overwrote the value. A correct log before save does not prove the final saved state. Investigate the actual account result rather than inferring a date-format cause.
Does a Date object fix every expected-receipt-date issue?
setCurrentSublistValue requires a value matching the field type; date fields take Date values. A valid Date can still represent the wrong intended day. Parsing, timezone construction and account behavior need separate checks. The source's later client taxcode anecdote does not establish the cause of its server-side date issue.