Admin-Configurable PDF Columns
Every organization eventually wants one more thing on its documents — the payment method on receipts, a project code on invoice lines, the check number on payment vouchers. In REDA Financials that's not a template redesign; it's an administrator dragging a field into a list. The PDF layouts read their extra content from field sets — admin-configurable lists of fields — named PDF Template on each document object.
Access you'll need. Editing field sets is a Salesforce administrator capability (the "Customize Application" permission), not one of the REDA Financials permission sets. Everyday users simply see the resulting columns on the generated PDFs.
What appears where
| Field set on… | Renders as… |
|---|---|
| The document header (Sales Invoice, Cash Receipt, Cash Disbursement, Purchase Order) | Extra label/value rows in the document-details card, after the standard number/date/reference rows |
| The lines (Sales Invoice lines, Purchase Order lines) | A small detail strip under each line — "Label: value" pairs beneath the description, keeping the main table clean |
Out of the box, receipts already show Applied to Invoices, Bank Account, Unapplied Cash, Payment Method and Type this way, and payment vouchers show Bank Account, Applied Amount, Unapplied Amount, Payment Method and Check Number — those defaults are just field-set entries you can extend or trim.
Each document object carries its own list, so the full map looks like this:
| Document | Header list ships with… | Line list |
|---|---|---|
| Sales Invoice | Empty — add what your invoices need | Ships with Tax Base; add your own (project codes, cost centres…) |
| Cash Receipt | Applied to Invoices, Bank Account, Unapplied Cash, Payment Method, Type | — (receipts have no lines) |
| Cash Disbursement | Bank Account, Applied Amount, Unapplied Amount, Payment Method, Check Number | — (vouchers have no lines) |
| Purchase Order | Empty | Available, ships empty |
A worked example, receipts being the classic case: Meridian wants its rent receipts to say which bank the money landed in. Nothing to do: Bank Account already ships in the Cash Receipt PDF Template field list, so every receipt's details card already carries a "Bank Account: First National Bank - Operating" row — the account's name, not a code. The same list is where they would add a genuinely new one: open it, drag the field in, done. Total elapsed time: about two minutes, no release, no downtime.
Adding a field (administrator, ~2 minutes)
Open the object's field sets
Setup → Object Manager → the document object (say, Cash Receipt) → Field Sets → PDF Template.
Drag the field into the set
Anything on the object qualifies — standard, packaged, or your own custom fields. Order in the set is order on the paper.
Regenerate and look
No deployment, no code — the next generation picks it up. Check one document; done.
How values print
- Lookups print names — a Bank Account field shows "First National Bank - Operating", never an ID.
- Formats follow the document's locale — dates, numbers (two decimals for money), percent signs, and Yes/No for checkboxes. The locale itself resolves sensibly: the template's locale when set, otherwise the customer's, otherwise yours.
- Empty values vanish — a blank field prints nothing, so sparse data never produces rows of empty labels.
- Statements have their own list — columns added to the Account Ledger's field set appear on both the on-screen ledger and the exported Statement of Account, between Reference and the amount columns.
Common mistakes to avoid
| Mistake | Why it hurts | Do this instead |
|---|---|---|
| Adding the field to the wrong list | Header vs line, or the wrong document object entirely — the field prints nowhere and the change looks broken | Every document object has its own PDF Template list; open the object the paper comes from, and pick header or line deliberately |
| Testing on a record where the field is blank | Blanks are skipped by design, so a perfectly good configuration looks like a failure | Regenerate a document where the field definitely holds a value |
| Surfacing internal fields on customer paper | The list is org-wide per document type — a margin or internal code added "for one entity" prints for every entity, to every customer | Only reader-relevant fields; internal analysis belongs on reports, not invoices |
| Expecting statement columns from the document lists | The statement reads a different list — the Account Ledger's — so document-list changes never reach it | Add statement columns to the Account Ledger field set; they'll show on screen and on the exported PDF |
| Solving a layout wish with more fields | Ten extra rows per line drowns the document the reader actually needs to parse | Three well-chosen extras; switch the template to Landscape when a document genuinely needs width |
Where to go next
- PDF Template Configuration — the styling around your fields.
- Payment Details on PDFs — standing instructions vs record facts.
- Supported Document Types — each document's base layout.
Frequently asked questions
Field sets are per document type across the org — every entity's invoices share the list. Entity-specific presentation (colors, sections, text) lives on templates; entity-specific field lists aren't a supported combination.
Two usual suspects: the field is empty on the document you tested (blanks are skipped by design), or it was added to the wrong set (header vs line, or the wrong object). Test with a record where the field definitely has a value.
The layout renders line extras as a detail strip under each line — it keeps the main table readable at any number of extras. If a value is important enough to be a column, it usually belongs in the description your team writes on the line.
No — it's an administrator's drag-and-drop in Setup, and the next generation picks it up. That's the point of the design: document content evolves at configuration speed, not release speed.
The ones with lines: sales invoices (credit memos included) and purchase orders. Receipts and payment vouchers are single-amount documents — their extras all go in the header details card.
No — existing files are historical. The next generation (or a manual regeneration, which versions the same file) picks up the new field.
Was this article helpful?