Every record you create or edit — a customer, a supplier, a product, a bank, a tax code — is laid out the same way, so once you have read one form you have read them all.
Blocks with plain names. A form is a short stack of outlined blocks, each named for what it holds: Basic info (the code, the name, what the record is), Contact & addresses (phone, email, and where goods and invoices go — ship-to and bill-to addresses sit under their own small headings), Billing info (currency and payment terms), Pricing & credit (credit limit, tax code, the account postings go to). Small setup records — a unit of measure, a payment term — are a single block with no name, because there is nothing to split. Fields sit side by side in proportion to what they hold: codes are narrow, names are wide, notes run the full width at the foot of their block.
One raised button. At the foot of every form there is exactly one raised, coloured button — Create on a new record, Save on an existing one. That is the button that commits what you typed; everything else in the row is deliberately quieter. Cancel is a plain text button that simply leaves. On a create form, Create & create another is outlined — it saves and opens a fresh blank form, which is the fast path when you are entering several records in a row.
Delete lives at the foot of the edit form. On an existing record, Delete is the red text button at the far left of the footer row — present, but never dressed up to compete with Save, and never in the header next to the working actions. (Only super-admins can delete at all; see 1.12 Permissions.)
Folded lines. Where a form carries a list — the contacts on a customer or supplier, for example — each entry you have filled in folds down to a one-line summary under a small header row, so you can read the whole list at a glance: for a contact, their name, job title, phone, and email. Click a folded line to open it and edit; the button at the foot of the list names what it adds — + Add contact.
Sales documents read the same way. A sales order, a sales invoice, a waybill, a credit note or a debit note opens with its header in one outlined block named for the document — the customer wide, the code and dates narrow, any notes at the foot of the block. Its lines fold exactly like the contacts do, under a header row naming the columns — product, quantity (always with its unit of measure), unit price and extended amount, in the document's own currency — so a ten-line order reads as ten tidy rows until you click one open to edit it. Under the lines, the totals sit at the right as a short stacked summary — subtotal, VAT, then the document total ruled off and bold — the same shape as the printed document. The buttons that move a document through its life — Approve, Post, Reverse — stay at the top of its edit and view screens, where the person reviewing it works; Save remains the one raised button at the foot, and Delete sits in the footer as described above.
Purchase and inventory documents read the same way. A purchase order, a goods receipt or a purchase invoice opens with its header in one outlined block named for the document — the supplier wide, the code and dates narrow, the goods-receipt picker on a purchase invoice on a row of its own, any notes at the foot of the block. Their lines fold exactly like the sales documents': product, quantity with its unit of measure, unit price and extended amount in the document's own currency. On a goods receipt the unit and currency are the purchase order's — that is where they come from — and on a purchase invoice the unit shown is the product's purchase unit. The totals sit at the right as the same stacked summary, ruled off at the document total. Payments and receipts carry their invoice allocations as folded lines too — invoice number and amount at a glance — and the journal entry screen proves itself the same way: under its lines, a short stacked summary shows total debits, total credits, and the difference, bold when the batch does not balance. Stock adjustments, stock transfers, stock counts, bank statements, feedings, mortalities and marketplace orders all follow the same grammar: one named block for the header, folded lines where the document has lines, the working buttons — Approve, Post, Reverse — at the top of the edit screen, and the one raised Save at the foot.
On a phone, the blocks stack into a single column, the folded lines stay readable, and the footer buttons stack with the raised Create or Save first — nothing important is ever off the edge of a small screen.
Views read like forms. Open a record instead of editing it and you get the same blocks, with the same names, in the same order — the view is the form, read-only, so nothing has to be learned twice. The customer, supplier and product record pages make the point most strongly: their Details tabs carry exactly the blocks their forms do — Basic info, Contact & addresses, Billing info, Pricing & credit — over the very same facts. (The one card with no form block of its own is a worked table, not a record field: a supplier's actual lead times, a product's pricing grid.) Work orders, donations, bank reconciliations, time entries and bills of materials follow the same grammar as every other form — a named block, weighted fields, the one raised button at the foot — so the whole application now reads as one document family.