FieldSet Extensibility
The most powerful extension mechanism in REDA Financials needs no code and survives every upgrade: field sets. Add your custom field to the right set and it appears on the entry forms, travels onto the ledger, filters the reports, and prints on the PDFs — the package's screens and engines read the sets at runtime. Forty-plus sets ship across the transactional objects, in three families.
The three families
| Family | Where it surfaces | Classic use |
|---|---|---|
| Interface | Extra columns/fields in the packaged entry forms (invoice lines, journal lines, receipt forms…) | Your industry's dimensions — Meridian added Property__c to invoice lines; it appears in the form grid like it was born there (and the same line set even extends recurring-template lines) |
| Posting_Mapping | Carries dimension values from documents onto the Accounting Transactions — and from there into report filters, drill-downs and dimension-matched applications | The same Property__c flowing to the ledger so the income statement can be run per property |
| PDF Template | Extra header rows / line details on generated documents (details) | Payment method on receipts, project codes on invoices |
Plus the Account Ledger set on Accounting Transaction — extra columns for the party ledgers and statements.
The reason this works at all: field sets on managed objects are deliberately left admin-editable by the platform. Your membership edits are org metadata — the package reads whatever the sets contain at runtime, which is why this is the primary no-code extensibility mechanism and why it survives every upgrade untouched.
The end-to-end recipe (a new dimension in ~15 minutes)
Create the field where it's entered — and where it lands
The custom field on the document line (e.g. Property on Sales Invoice Line) and a same-API-name field on Accounting Transaction. Matching API names are the contract that lets values flow.
Add to Interface (entry) and Posting_Mapping (flow)
Object Manager → Field Sets → drag the field in. The form shows it immediately; postings start carrying it; the report panel's Dimensions section and drill-downs pick it up automatically.
Optionally: print it, filter by it, match by it
PDF Template set → it prints. It appears among report dimension filters. And dimension-aware features (application matching, dimension-scoped year-end close) treat it like the built-in cost center.
In the package's own words
The field sets document themselves — their packaged descriptions are the design intent, verbatim. The Sales Invoice Line Interface set says: "Add client-specific accounting dimensions here (e.g. Property__c, Cost_Centre__c, Sub_Property__c)" — those are just the shipped illustrations; the same slots take whatever dimensions your industry tracks (cost centres, projects, departments, funds), which is exactly how a firm like Meridian uses them for properties. Forty-three field sets ship across the transactional objects; the pattern repeats per object so each document type's form, posting flow and PDF are independently extensible.
Two contracts sit behind the sets — one in the packaged descriptions, one in the engine itself — and are worth stating plainly:
- Name-matching is the plumbing. The posting flow maps by API name — and so does application matching: when dimension-matched applications are in play, the engine requires that "API names match between the two Posting_Mapping FieldSets" on the documents being matched. One field, one name, everywhere.
- Standard columns stay out. Interface sets are for your additions only; the packaged columns are already rendered by the forms, and re-adding them duplicates the column.
Meridian's Property dimension, everywhere at once
One custom field — Property__c — added per the recipe above, and here is everywhere it now surfaces without another minute of configuration:
| Surface | What Meridian sees |
|---|---|
| Sales Invoice form | A Property column in the line grid, populated per rent line |
| Recurring templates | The same column on template lines — the line Interface set extends both, so the monthly rent template carries the property too |
| The ledger | Every posted line's Accounting Transaction carries the property value (Posting_Mapping) |
| Reports | Property appears among dimension filters — income statement per building, drill-down included |
| Generated PDFs | The property prints on tenant invoices (PDF Template set) |
| AI extraction | The OCR field catalog includes it — uploaded vendor bills can have the property filled by the AI where the document implies it |
Common mistakes to avoid
| Mistake | Why it hurts | Do this instead |
|---|---|---|
| Different API names on the document field and its Accounting Transaction twin | The mapping is by name — values silently stop at the document and never reach the ledger | Create both fields with identical API names before touching the sets |
| Adding to Interface but not Posting_Mapping | Users faithfully fill a field that never reaches the reports — discovered at month-end | Think in pairs: entry (Interface) and flow (Posting_Mapping) together |
| Re-adding standard columns to an Interface set | Duplicate columns in the grid confuse the form | Interface sets carry your fields only |
| Renaming a dimension field after months of postings | Old ledger rows keep the old field; reports split one dimension into two | Choose names as carefully as GL accounts; a rename is a data-migration project, not an edit |
| Skipping the required-field conversation | Field sets make fields available, not mandatory — optional dimensions end up 60% populated | Pair the field-set change with validation or team process that makes the dimension trustworthy |
Where to go next
- FieldSet-Driven PDF Columns — the printing family in depth.
- Posting Dimensions — the accounting theory of dimensions.
- Lightning Web Components — when field sets aren't enough.
Frequently asked questions
The packaged forms are custom UIs (grids, wizards), not standard layouts — field sets are how a managed package lets you extend screens it owns. Same idea, richer surfaces: forms, engines, reports and PDFs all read them.
Yes — your membership edits are org metadata, preserved across package versions. That's precisely why this is the recommended extension path.
Technically generous; practically, every dimension is a field users must fill and reports must slice. Two or three well-governed dimensions beat eight half-populated ones — an accounting-policy decision more than a technical one.
No code, no deployment: it's Object Manager point-and-click, effective immediately. Govern it like configuration change all the same — sandbox first, because a live form gains a column the moment you save.
Interface — the same sets that extend the Purchase Invoice form's fields are read when the AI builds its field catalog, so extending the form automatically teaches the extractor about the new field. One definition, every consumer.
Yes. Any custom field you added that is not part of the Posting Mapping field set stays editable in every state — draft, posted, voided, even reversed. REDA locks only its own fields, the standard fields, and any field you've made a posting dimension (those are written into the ledger when the record posts, so they freeze with it). Plain flags, notes and integration keys are yours to change at any time. One precision: “yours” means a field in your own org's namespace. A custom field that arrives from another installed managed package is namespaced, so the guard treats it as governed rather than free.
Was this article helpful?