b983a6da57
The same plain-backtick "See sample: \`x.good.al\`." form fixed on al-methods-limited-during-write-transactions (PR #161) turned up repo-wide on 15 more of this PR's articles - Knowledge-Retrieval.ps1 requires the markdown-link form to associate a sample with its article. All 16 fixed; the four local validators (frontmatter, knowledge-index, knowledge-retrieval, review-fixtures, skill-index) pass.
3.8 KiB
| bc-version | domain | keywords | technologies | countries | application-area | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
data-modeling |
|
|
|
|
Wire dimension support through DimensionManagement, not ad hoc fields
Contributions welcome — open a PR to refine or extend this article.
Description
Adding dimension support to a custom table is not just a matter of adding a Code[20] field, and master tables and document/transactional tables wire into Codeunit "Dimension Management" through two different models — treating them as one mechanism is itself the mistake this article corrects:
- Master data (a custom master table, e.g. "Course") persists Default Dimension records: each shortcut dimension field validates through
ValidateDimValueCode, then the result is saved viaSaveDefaultDim, andDeleteDefaultDimremoves them again inOnDelete. BothValidateDimValueCodeandSaveDefaultDimtake the shortcut dimension number (1-8, matchingGeneral Ledger Setup's "Shortcut Dimension N Code" fields) as their first/third argument respectively — not the AL field ID of the table field being validated. The master record itself carries noDimension Set IDfield. - Transactional/document data (a custom document or journal-line table) carries a single
Dimension Set IDfield — a pointer to a shared, deduplicated set of dimension values inDimension Set Entry, assembled from whatever the document inherited plus whatever the user overrode. A document does not acquire that ID by callingSaveDefaultDim; it builds a source list withAddDimSource(naming the related master table and its key, e.g.Database::Customer), then callsGetDefaultDimIDto compute a newDimension Set IDthat inherits the master's Default Dimension records. Editing a shortcut dimension field directly on the document validates throughValidateShortcutDimValues, which updates the sameDimension Set IDin place rather than writing a separate Default Dimension record.
Skipping the model that actually matches the table's kind produces a field that looks correct in the designer but silently fails to save, validate, or carry through to postings — or, for a document, one that never picks up the customer's/vendor's own dimensions at all.
Best Practice
For a master table, validate each shortcut dimension field through ValidateDimValueCode, save the result with SaveDefaultDim, and delete the matching Default Dimension records in OnDelete.
For a document table, when the field that attaches the document to a master record changes (e.g. Customer No.), call AddDimSource naming that master table and key, then GetDefaultDimID to compute the document's new Dimension Set ID, inheriting the master's Default Dimension records. Pass 0 for GetDefaultDimID's InheritFromDimSetID argument in this case — passing the document's existing Dimension Set ID instead inherits whatever dimensions were already in it, so a value the previous linked record supplied can survive into the new one even where the new record has no default for that dimension. Validate the document's own Shortcut Dimension fields through ValidateShortcutDimValues, which updates that same Dimension Set ID in place rather than persisting a separate Default Dimension record.
See sample: dimension-management-wiring.good.al.
Anti Pattern
Adding a dimension-looking field with only a TableRelation to Dimension Value, and no call into DimensionManagement at all. The field accepts input but never becomes a real Default Dimension record, so it does not validate against blocked values and does not flow into postings.
See sample: dimension-management-wiring.bad.al.