Line Item Builders

What They Are

A line item builder is the grid where somebody enters the lines of an order, quote, invoice or any other record made of items.

Where to find it

Architect Panel → Forms:

• Dynamic Add Fields — the definitions, then View Fields on a row
• Conditional Forms — show and hide rules
• Line Item Builders — the builders, then View Line Fields on a row

What a builder defines

Which table and field it belongs to, a name, whether the master row can be entered manually, how lines are displayed and grouped, an optional callback, a filter, whether all fields are forced, whether selection is fetched as you type, and which field is emphasised.

The line fields themselves are managed through View Line Fields on the builder’s row.

It is a component, not a datastore

The builder is how lines are entered and displayed. The lines themselves are records, with everything that implies — permissions, audit and reporting.

Emphasise the field people scan

Usually the description or the product name. On a grid of eight columns, one being visually dominant is what makes a long list readable at a glance.

Fetch-as-you-type matters on long lists

Where lines are chosen from a catalogue of thousands, loading them all is slow and a dropdown of thousands is unusable. Fetching matches as somebody types is the difference between a usable grid and one people avoid.

Grouping organises long documents

An order of forty lines is easier to read grouped — by category, by delivery date, by section. Grouping is display rather than structure, so it costs nothing in the data.

Manual master entry is a real choice

Whether somebody can type a line that is not in the catalogue. Allowing it is flexible and produces free-text descriptions that cannot be reported on; refusing it is clean and blocks the genuine one-off.

Most businesses need it and should watch how often it is used — frequent manual lines mean the catalogue is missing something.

Keep the columns few

Every column is entered per line. A grid with eleven columns is one where people fill in four and leave the rest, which is worse than not having asked.

Design it for keyboard entry

Somebody entering twenty lines is typing, not clicking. Tab order, sensible defaults and the ability to add a line without reaching for the mouse are what make the difference at volume.

Worked example

An order builder shows five columns with the description emphasised, fetches products as the user types, groups by delivery date, and permits manual lines. Manual line use was reviewed after three months and identified eleven products missing from the catalogue.

Recommendations

• Emphasise the field people scan.
• Fetch as you type for anything above a few hundred options.
• Few columns — each is entered per line.
• Watch manual line use as a catalogue signal.

Configuring the Lines

The line fields decide what somebody enters per line and how the grid looks.

Where to find it

Architect Panel → Forms:

• Dynamic Add Fields — the definitions, then View Fields on a row
• Conditional Forms — show and hide rules
• Line Item Builders — the builders, then View Line Fields on a row

What each line field carries

Which field it shows, its size, its order, whether it is a special field, and whether it displays a subtotal with its own formatting and decimal places.

Size the columns to their content

A quantity column as wide as a description invites the wrong thing in it and wastes space that the description needs. Column width is a hint, and on a grid it is a strong one.

Order for the way people work

What they choose first on the left. For most documents that is the item, then the quantity, then anything that varies, with computed values on the right.

The order should match the order somebody would say it aloud.

Put computed columns last

Line totals and derived values belong on the right, where they are read rather than entered. Mixing them among the input columns makes the grid harder to tab through.

Subtotals belong on the columns that sum

Quantity and value. A subtotal on a column that does not meaningfully add up — a reference, a date — is a number that means nothing and invites somebody to use it.

Set decimal places deliberately

Money to two, quantities to whatever your business actually uses. A quantity shown to four decimal places suggests a precision you do not have, and a value rounded to none loses money.

Formatting is per column

Which is right — a currency column and a quantity column should not look the same. Consistent formatting across documents matters more than any particular choice.

Force fields carefully

Requiring every field on every line means a line cannot be left half-entered, which is good for data and bad for somebody working through a long order who does not yet know one value.

For long documents, allow the line to be saved and validate at submission.

Test with a long document

Twenty lines, entered by keyboard, on the smallest screen anybody uses. That reveals column widths, tab order and grouping problems that five lines never will.

Worked example

A grid was arranged as item, quantity, unit price, discount and line total, with subtotals on quantity and total, money to two decimals and quantities to none. Testing with twenty lines on a laptop found the description column too narrow, which was widened at the expense of two columns nobody used.

Recommendations

• Size columns to their content.
• Computed columns last, inputs first.
• Subtotals only where they sum meaningfully.
• Test with twenty lines by keyboard.

Pricing and Totals

Totals are where a line item document is checked, disputed and paid. They deserve care.

Where to find it

Architect Panel → Forms:

• Dynamic Add Fields — the definitions, then View Fields on a row
• Conditional Forms — show and hide rules
• Line Item Builders — the builders, then View Line Fields on a row

Architect Panel → Data:

• Datastores — where line and header values are stored

Subtotals are per column

Each line field can display a subtotal with its own formatting and decimal places. That gives you a quantity total and a value total on the same grid, each formatted correctly.

Decide where the total is authoritative

Calculated for display, or stored on the record? Both are used and they answer different questions.

A stored total is what you charged; a calculated one is what today’s lines add up to. For anything invoiced, store it — otherwise editing a line changes an invoice you have already sent.

Round at the end, not per line

Rounding each line and then summing gives a different answer from summing and rounding once. Over a long document the difference is real, and it is the difference a customer’s accounts department will find.

Decide which you do, be consistent, and be able to explain it.

Percentages need a base

A discount or a tax percentage applies to something. Being explicit about whether it is before or after other adjustments is what makes a total reproducible.

Two people calculating the same document by hand should get the same answer.

Watch the order of operations

Line discount, then document discount, then tax — or a different order. It changes the answer, and it is exactly what a query about a total turns out to be.

Write it down.

Show the working

A document showing a net total, the discount, the tax and the gross is one somebody can check. A single figure is one they have to trust or query.

Test the awkward cases

• A line with a quantity of zero.
• A negative line, for a credit.
• A very large quantity.
• A hundred-line document.
• A discount taking the total to zero.

Each of those has produced a wrong total somewhere.

Check against a hand calculation

Once, properly, on a document with several lines and a discount. That single check is worth more than reading the configuration, and it is the thing nobody does.

Worked example

An organisation stores document totals rather than recalculating, rounds once at the document level, and writes its order of operations into its finance procedure. A hand check on a five-line order with a discount found a penny difference caused by per-line rounding, which was corrected before invoicing began.

Recommendations

• Store totals on anything invoiced.
• Round once, and be consistent.
• Write down the order of operations.
• Check one document by hand.