What may be changed, and what may not
Five grounds a record may be uneditable on, one partial ground, and why the answer arrives before the Edit button is drawn.
Every screen asks one question before it draws an Edit button, and one place on the server answers it. The same function then judges the save — so a button that appears is a button that works, and a button that does not appear says why in its place.
The default is yes. A record is editable unless one of five things is true.
| Ground | Why not | What to do instead |
|---|---|---|
| View | The screen is assembled from other records rather than holding its own. | Change those records; this one follows. |
| Immutable | It is an audit trail or a system log — a chart-access record, a stock movement, a job run. | Nothing. That it does not change is the point of keeping it. |
| Status | The document has posted, been cancelled, or been converted. | Reverse it, or raise a credit memo. |
| Period | The fiscal period it falls in is closed. | Post the correction into an open period. |
| Historic | It is an effective-dated version whose window has already ended. | Change the version in force. This one is what an as-at date before then still answers with. |
The partial ground
When other records point at this one, its identifying number or code freezes and everything else about it stays editable. Renumbering an account that forty journals quote would make those journals say something they did not. But a supplier whose address is wrong is not uneditable because it has invoices against it — the form shows the frozen field, locked, with the reason, and lets you fix the address.
Read-only no longer means immutable. A screen marked read-only in the navigation may still permit a correction under this rule; the server decides per record, per user, at the moment you ask. Do not conclude from a missing Edit button on one row that the screen cannot be corrected on another.
Date-sensitive data changes FROM a date
On a record that carries an effectivity window, the edit form asks when the change takes effect. Move the date forward and the version in force is closed the day before and a successor is written, carrying the whole record with your change on top. Leave the date as it is and that version is corrected in place.
History is never rewritten. That is what makes an as-at date mean anything: asking what a rate, a price or a job grade was on a date in March returns what it actually was in March, not what it is now. The rule applies identically from the list, from the record page and from the master-data panel.
Every screen has a form
Where a curated form is declared it is used. Where none is, the server describes one from the columns the record actually accepts — types, required fields, and a picker for every foreign key. So a record can be corrected on a screen nobody sat down and designed, rather than being uncorrectable because nobody had got to it yet.