AL Development Guide: Automating Email Alerts for Cash Receipt Application
AL Development is often as much about understanding the functional flow of a document as it is about writing the actual code. We recently stumbled upon a common yet tricky request in the Dynamics 365 Business Central community: a finance team needed automatic email notifications whenever a Customer Cash Receipt Journal was posted and successfully applied to an invoice (or unapplied later).
If you have ever tried to explain to a generic ERP system that it needs to send an email only when money touches a specific invoice, you know this isn’t an out-of-the-box toggle. It requires getting your hands dirty with code.
The Business Scenario
Most finance managers live in their email inboxes. They don’t want to constantly refresh the Customer Ledger Entries page to see if a payment has cleared against a major invoice. They want a ping.
The specific requirement here is twofold:
- Trigger an alert when a Cash Receipt Journal is posted that applies to an invoice.
- Trigger an alert if an entry is subsequently unapplied.
The challenge? Posting a journal involves moving data from the Journal Line to the Ledger Entry, creating G/L entries, and generating Detailed Ledger Entries. Finding the exact moment in that transaction to trigger an email—without breaking the transaction or sending duplicates—is where good AL Development practices come into play.
Identifying the Right Event Subscriptions
Many developers initially look at the OnAfterPostGenJnlLine event in Codeunit 12 (Gen. Jnl.-Post Line). While this confirms a line was posted, it doesn’t explicitly tell you if an application took place easily without querying the new entries.
To capture the application specifically, you are better off looking at the creation of Detailed Cust. Ledg. Entries. Every time an application occurs (whether during posting or manually afterwards), Business Central inserts a record into the Detailed Customer Ledger Entry table with the Entry Type set to Application.
1. Handling the “Apply” Logic
A robust approach involves subscribing to Codeunit 12 or the table events directly. However, for cleaner logic during the posting routine, consider looking at:
- Codeunit 12 (Gen. Jnl.-Post Line): specifically
OnAfterInsertDtldCustLedgEntry.
By subscribing here, you can check if the Entry Type is Application. If it is, you can trace back to the Cust. Ledger Entry and the Document No. involved. This covers the scenario where the application happens during the journal posting.
2. Handling the “Unapply” Logic
Unapplying entries is a different beast because it usually happens outside the posting routine, often via the Unapply Entries page. For this, you need to look at Codeunit 226 (CustEntry-Apply Posted Entries).
Search for the event OnAfterUnApplyCustLedgEntry. This event gives you access to the specific entry being unapplied, allowing you to trigger that “Uh-oh, this payment is open again” email to the finance team.
The Code Logic Structure
When writing your AL code, avoid putting the email generation logic directly inside the posting transaction. If the SMTP server hangs or fails, you do not want to roll back the entire financial posting.
Instead, use the Job Queue or a buffer table pattern:
- Capture the Event: On the
Applicationevent, write the details (Customer No, Amount, Invoice No) to a custom staging table. - Process Separately: Have a scheduled task or a background session pick up those records and send the emails via the Email Message codeunit.
Here is a conceptual breakdown of the subscription:
|
1 2 3 4 5 6 7 8 9 |
[EventSubscriber(ObjectType::Codeunit, Codeunit::"Gen. Jnl.-Post Line", 'OnAfterInsertDtldCustLedgEntry', '', false, false)] local procedure OnAfterInsertDtldCustLedgEntry(var DtldCustLedgEntry: Record "Detailed Cust. Ledg. Entry") begin if DtldCustLedgEntry."Entry Type" = DtldCustLedgEntry."Entry Type"::Application then begin // Logic to check if this is a Cash Receipt and queue the email end; end; |
Why Granularity Matters
The reason we focus on Detailed Cust. Ledg. Entries rather than just the journal line is accuracy. A single journal line might apply to multiple invoices, or perform a partial payment. The detailed entries give you the exact breakdown of the math.
Final Thoughts
Automation in Business Central is powerful, but it requires precision. By hooking into the Application entry types rather than generic posting events, you ensure the finance team only gets notified when it actually matters. It keeps their inbox clean and their trust in the system high.
