Add 5 AL/BC patterns: document distribution (Report Selections, Document Sending Profile, Find Entries, TransferFields)

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>

microsoft/knowledge/data-modeling/custom-document-dispatch-must-not-bypass-report-selections.md

@@ -0,0 +1,62 @@
+---
+bc-version: [all]
+domain: data-modeling
+keywords: [report-selections, document-layouts, custom-report-layout, email-attachment, bespoke-dispatch]
+technologies: [al]
+countries: [w1]
+application-area: [all]
+---
+
+# 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/`.