aad3991d9f
- Barcode: drop the false claim that '*value*' is mismatched with the
IDAutomation Code 39 font; '*' is a documented start/stop form and
'(' / ')' an accepted alternative. Cue and article now route only
independently provable validation/checksum/font-binding defects.
- Dispatch good samples (and matching bad samples) now pass a
Sales Invoice Header with the S.Invoice usage, matching the record
the selected report (1306 "Standard Sales - Invoice") expects.
- custom-document-dispatch rule made disjunctive: a hardcoded report
or a hand-built email is each a bypass on its own; scoped to
customer/vendor-facing documents. Bad fixture shows the hardcoded
report alone.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
3.4 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, ...)),
or 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. Either
bypass is a defect on its own: a hardcoded report ignores the registered
report and any per-account layout override even when no email is
involved, and a hand-built email ignores the registry's attachment and
email-body configuration even when the report itself came from it. 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"), plus a separate per-usage layout
override, "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, or builds its own email
message directly, for a document that has (or should have) a
Report Selections usage — each is independently a bypass, and the
sample shows the first on its own. 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 — field 7,
"Custom Report Layout Code"; 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/.