Custom fields
Add your own fields to documents and masters — vehicle number, LR number, batch, salesperson — and watch them flow to registers, print, and exports.
Every trade has its own paperwork quirks — a transporter wants an LR number, a pharma wholesaler needs batch details, a dealership tracks vehicle numbers. Custom fields let you add exactly those, without waiting for the product to change.
Where custom fields can live
| Placement | Example |
|---|---|
| Sale / purchase header | Vehicle No, LR No, Salesperson — one value per document. |
| Sale / purchase line | Batch, Serial No — one value per item row, shown as a real column in the items table. |
| Account master | Route, Zone, Credit terms. |
| Item master | Shelf location, Brand line. |
| Account Group master | Review cycle, Reporting label. Entry only — these do not appear on documents or in exports. |
| Item Group master | Shelf zone, Storage temperature. Entry only — these do not appear on documents or in exports. |
Create a field
- 1
Open the designer
Go to Administration → Setup → Custom Fields and choose New field.
- 2
Pick where it lives
Choose the target (sale, purchase, account, item, account group, item group) and — for documents — header level or line level.
- 3
Define the field
Name, kind of value (text, number, date, choice), an optional default, and an optional pattern the value must match.
- 4
Choose visibility
Decide where the field shows: on the entry form, on printed documents, and in exports. Set the display order among your other fields.
- 5
Save and use
The field appears on the relevant form immediately, for everyone in your organisation who can open that form — the person billing at the counter types the batch number and expiry date, not only the person who set the field up. Values typed there flow to registers (as optional columns), print layouts, exports, and import mappings. Only users who manage Setup can add, change or switch off fields.
Numeric header fields can join the bill maths
A numeric header field may be linked to a bill sundry. Its value then appears as that sundry on the document, participating in totals the same audited way every other charge does.
Deactivate, don't repurpose
When a field outlives its use, switch it off — old documents keep their values for history, and they still open and save normally. The value stays on the record even though the field no longer appears anywhere, so switching the field back on brings it into view again exactly as it was. Renaming a field to mean something new rewrites the past; avoid it.
Marking a field required
A field marked required must be filled in before the document or master will save. The save is refused with a message naming the field, so nobody has to guess which one is missing. Two things worth knowing before you tick it. It applies from the moment you save the field, so documents already in your books are unaffected until somebody edits one and fills the form in again — an ordinary edit that does not touch your own fields is never blocked by it. It applies to the entry forms, where the field is on screen and can be filled in. A spreadsheet import does not enforce it — a row with nothing in that column still imports, with the field left blank — so if the value matters on imported records, map the column.
Where your fields appear for typing
Header and master fields show up wherever that record is created or edited — not only on the full form. The quick add-and-edit panels and pop-up dialogs for accounts and items show them, so a field you rely on can be filled in without leaving the screen you are on. The dispatch screen for a sale order and the automatic purchase-order screen show your document fields too, and there they are filled in once for the whole run. If your organisation has not defined any fields for a record, nothing extra appears and those screens look exactly as they always did. And on the rare occasion your fields cannot be read at that moment, the screen tells you so and offers to try again — so an empty section always means you have not set any up, never that something went quietly wrong. Your per-line fields follow the same rule: if they cannot be read, their columns are simply not drawn, and a note just below the item table says so in its own words — headed for the per-item fields, separate from the note about your document fields, so you can see which set is missing instead of wondering why a column you use every day has disappeared. It also reminds you that whatever was already recorded against each line is kept exactly as it is, but cannot be reviewed until the fields load.
A required field is checked before anything is saved
On the dispatch and automatic purchase-order screens, a required field you have left blank is pointed out before any part of the job starts — so a half-finished dispatch is not left behind while you go back and fill it in. Fill the field, then run it again.
Hiding a field from the entry form keeps what is already stored
You can keep a field switched on but take it off the entry form, so nobody types into it any more while what has already been recorded stays put. Saving those records again does not empty it — an editor who cannot see a field is never treated as having cleared it. Put the field back on the form and the old values are there, unchanged. Clearing a value you CAN see still works exactly as before: empty the box and save.
Keep line fields few
Up to four line-level fields render as inline columns in the items table, which keeps entry fast. Past that, ask whether the data really belongs on every line.
Fields you mark for printing also reach the customer's copy
Marking a field to show on printed documents is the whole decision: it then appears on your own printed invoice, on the PDF you send, and on the page a customer opens from a link you share. That is true of header fields (a doctor's name, a prescription number) as well as line fields (batch, expiry). A field you have not marked for printing stays inside your organisation and is never sent, and a header field with nothing typed in it is simply left off that document. Three things to expect: the same limit of four columns applies to the copy your customer gets; a shared PDF is only so wide — it shows the first two and says in a line beneath the table how many it left out, while the page opened from the link shows all four; and up to eight header fields are shown under the document number and date, with a short line saying how many more there were. One thing to know about dates: on the copy your customer receives, a date field is shown the way it was stored, as year-month-day, alongside the document's own date in the same style — so an expiry that reads 03/31/2027 on your own printout reads 2027-03-31 on theirs.
When a line field appears on the printed document
A line-level field marked to show on printed documents becomes an extra column in the items table — up to four of them, in your display order. Three things to know: the column appears only on documents that actually carry a value for it, so an unused field never leaves a blank column on your invoices; if you have already saved your own layout in Setup → Print, tick the field there to add it, because a saved layout prints exactly the columns you chose; and anyone in your organisation who can print the document sees the same columns you do — a salesperson's copy is not different from a manager's.
Was this page helpful?