bcquality/microsoft/knowledge/data-modeling/custom-document-dispatch-must-not-bypass-report-selections.bad.al
Michael Dieringer aad3991d9f Fix three merge-critical items from Jesper's 2026-09-29 review
- 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>
2026-09-29 16:45:02 +02:00

20 lines
922 B
AL

codeunit 50102 "Sample Posted Invoice Send"
{
procedure SendPostedInvoice(SalesInvoiceHeader: Record "Sales Invoice Header")
var
Customer: Record Customer;
begin
Customer.Get(SalesInvoiceHeader."Bill-to Customer No.");
Customer.TestField("E-Mail");
// WRONG: the report is hardcoded instead of resolved through the
// registered "S.Invoice" usage in Report Selections. This alone is
// the defect - no hand-built email is needed for it: a Report
// Selections row or a per-customer "Document Layouts" override
// that points this usage at a different report or layout is
// silently ignored, and the only way to change what this code
// prints is a code change and a new release.
SalesInvoiceHeader.SetRecFilter();
Report.RunModal(Report::"Standard Sales - Invoice", false, false, SalesInvoiceHeader);
end;
}