83f041b662
Five rules about Business Central's document distribution architecture, verified against BCApps source and Microsoft Learn. - custom-document-dispatch-must-not-bypass-report-selections - document-print-and-email-actions-call-report-selections-directly - extend-find-entries-navigate-for-new-document-types - extend-report-selection-usage-for-new-document-types - transferfields-mirrored-fields-must-match-type-and-length Wired into al-data-modeling-review.md's worklist cues. Added a disambiguation note on the TransferFields article distinguishing it from the existing transferfields-skip-type-mismatch-can-drop-data.md (type-mismatch skipping vs. length mismatch, which SkipFieldsNotMatchingType does not affect). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2.8 KiB
| bc-version | domain | keywords | technologies | countries | application-area | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
data-modeling |
|
|
|
|
Custom document dispatch must not bypass Report Selections
Description
A codeunit that hardcodes which report to run (Report.RunModal(MyReportId, ...))
and builds its own email directly, instead of registering the document
through table 77 "Report Selections" and calling its own
Print/Email procedures, works for the one case it was written for — and
loses everything the platform's registry provides for free. Report Selections carries its own attachment/email-body configuration per usage
("Use for Email Attachment", "Use for Email Body", "Email Body Layout Code", "Email Body Layout Type", "Custom Report Layout Code"), and
table 9657 "Custom Report Selection" (the "Document Layouts" page on the
Customer/Vendor card) lets one specific account override the report or
layout without touching code at all. None of that exists for a document
whose dispatch was hand-rolled: there is no registry row to point
"Document Layouts" at, so an admin who goes looking for where to change
this document's layout — the same place they'd look for every other
document in the system — finds nothing, because the document was never
registered there.
Best Practice
Register the document under a Report Selection Usage value (see
extend-report-selection-usage-for-new-document-types.md) and dispatch
through Report Selections' own Print/Email procedures (see
document-print-and-email-actions-call-report-selections-directly.md),
even when the surrounding business logic — which counterparty to use,
what validation must pass before sending — is genuinely specific to the
document. Custom logic belongs around the call to Report Selections,
not instead of it.
See sample: custom-document-dispatch-must-not-bypass-report-selections.good.al.
Anti Pattern
A codeunit that runs a hardcoded report ID and builds its own email
message directly, with no Report Selections row backing it. It works for
the default case, but the report/layout cannot be changed per account
without a code change and a new release, and the document is invisible to
"Document Layouts" — the standard place every other document's
distribution is configured.
See sample: custom-document-dispatch-must-not-bypass-report-selections.bad.al.
Source
BCApps ReportSelections.Table.al (table 77 — fields 19–26 for email
attachment/body configuration; SendEmailToCust/PrintWithDialogForCust
as the registry-backed dispatch entry points) and
CustomReportSelection.Table.al (table 9657, the per-account override
backing the "Document Layouts" page) — both under
src/Layers/W1/BaseApp/Foundation/Reporting/.