Stamp the Posted Invoice

Easy

event-subscriber

sales-post

posting

table-extension

Stamp the Posted Invoice

Sales operations records a deal reference on every sales document, and finance wants that reference on the posted invoice so they can trace each invoice back to the deal that produced it. The catch: posted documents are created by the standard posting routine, codeunit 80 "Sales-Post" — base code you cannot modify. Your job is to carry the field across from the outside.

Requirements

Create a table extension for the Sales Header table with a field named "Deal Reference" of type Text[30].
Create a table extension for the Sales Invoice Header table with a field named "Deal Reference" of type Text[30]. Give the two fields different field IDs: the posting routine happens to copy same-numbered fields between these two tables, and relying on that accidental ID collision is exactly the fragile shortcut this task exists to replace.
When a sales document is posted, the resulting posted Sales Invoice Header must carry the same "Deal Reference" value the sales document had at posting time — both when a sales order is posted (ship and invoice) and when a sales invoice document is posted directly.
When the sales document's "Deal Reference" is blank, the posted invoice's field must stay blank.
Put your logic in a new codeunit — its name is up to you (not graded). Do not try to change base objects; extend them from the outside.

Pick all object and field IDs in the 50100–50199 range, and reference other objects by name, never by ID. No page extensions are needed — grading reads and writes the fields in code. Captions are good practice but not graded.

What the tests check

The tests create real sales documents with the standard library and post them through the standard posting routine. They post a sales order carrying a generated 30-character reference and a directly posted sales invoice carrying another, and assert that the posted Sales Invoice Header's "Deal Reference" matches character for character. They post an order whose reference was never filled in and assert the posted field stays blank. Finally they verify both fields are declared as exactly Text[30] by checking their maximum length, and that the two "Deal Reference" fields are declared with different field IDs — a submission that relies on the accidental same-ID copy fails.

Learn More

Table extension object — adding fields to Sales Header and Sales Invoice Header.
Events in AL — how publishers, subscribers, and raised events fit together.
Subscribing to events — writing a subscriber method in your own codeunit.
EventSubscriber attribute — the attribute syntax, and the Shift+Alt+E event lookup in VS Code.

Hint 1

You cannot edit codeunit 80 "Sales-Post", but you don't need to: it publishes integration events at every step of posting, and a subscriber in your own codeunit runs as if it were part of the routine. In VS Code, Shift+Alt+E lists every event you can subscribe to.

Hint 2

Look for the event Sales-Post raises just before it inserts the posted invoice header: it hands you the Sales Invoice Header about to be inserted (by var, so your changes are what gets saved) together with the source Sales Header. An AL subscriber may declare only the parameters it needs — they are matched by name.

Hint 3

The subscriber is [EventSubscriber(ObjectType::Codeunit, Codeunit::"Sales-Post", 'OnBeforeSalesInvHeaderInsert', '', false, false)] on a procedure taking var SalesInvHeader: Record "Sales Invoice Header" and var SalesHeader: Record "Sales Header" — its body copies your field from the source header onto the invoice header.

ALBusiness Central 28.5

Press Compile to check your code compiles — Submit runs the tests.

The code editor is desktop-only

Open this problem on a computer to write and run code. Reading the description, tests and discussion works fine here.