Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Chapter 16: ERP Case Studies and Examples

Objectives

By the end of this chapter you will be able to:

  • See how the individual AL objects you built in Chapters 7 to 15 form one coherent extension
  • Trace a single business event through every layer: table, page, codeunit, permissions, tests
  • Evaluate a second, unfamiliar case study using the same design questions
  • Plan your own small extension from a business problem, not from a list of AL features

16.1 Case study: Loan Repayment Management, end to end

Here is everything you built, in the order a request flows through it:

  1. A purchasing or finance user opens the page (Chapter 8) built on Loan Repayment Schedule.
  2. The table (Chapter 7) enforces that every row has a valid "Vendor No."-style relation, a composite key of loan + installment, and a correct "Total Amount". The amount is always right because the table’s own triggers calculate it, not the page.
  3. Clicking “Mark Paid” runs a page action that calls LoanRepaymentMgt.MarkInstallmentPaid (Chapter 9). The logic isn’t written inline on the page, so the same rule applies no matter what calls it.
  4. That codeunit’s logic is protected by a test (Chapter 14) that would fail loudly if a future change reintroduced the Rec/xRec bug from Chapter 9.
  5. Only users who hold the right permission set (Chapters 11 and 15) can open the page or run the codeunit at all, and a “View Only” role can see schedules without being able to change them.
  6. Every field on the table carries a DataClassification (Chapter 15) that would hold up in a compliance review.

No single chapter’s topic (tables, pages, codeunits, tests, or permissions) does the whole job. The extension works only because the pieces fit together.

Hint: Here is a way to check that you understood a chapter’s topic and didn’t just copy its code. Can you point to the one line in a different chapter’s object that depends on it? If you can’t, reread the chapter before moving on.

16.2 A second case study: Petty Cash Log

Here is a new, smaller problem. Work through the same design questions yourself before you read the suggested answers:

A small office wants to log petty cash disbursements: who received cash, how much, for what, and on what date. Someone should be able to mark an entry as “reconciled” once it’s been checked against a physical receipt, and reconciled entries shouldn’t be editable.

Ask yourself:

  • What table(s) do you need? Is one table enough, or does “who received cash” imply a relation to an existing table (like Employee)?
  • What would the composite or single-field primary key be?
  • Which field(s) need a MinValue, NotBlank, or TableRelation?
  • What trigger enforces “reconciled entries can’t be edited,” and does it need the Rec/xRec lesson from Chapter 9?
  • What single procedure in a codeunit should “mark reconciled” call through, rather than being written directly on a page action?
  • What would a “View Only” vs “Full Access” permission set look like for this?

Try it yourself: Before you look at the suggested design below, sketch your own table definition for Petty Cash Log on paper or in a scratch .al file.

A reasonable design, for comparison: a Petty Cash Log table with an auto-increment "Entry No." primary key. The key isn’t composite: there’s no natural grouping field the way loans group installments. The table also has a "Received By" field with TableRelation = Employee."No.", plus Amount, Purpose, "Entry Date", and Reconciled (Boolean). The OnModify trigger checks xRec.Reconciled, the same way the loan table checks xRec.Paid. A "Petty Cash Mgt." codeunit exposes MarkReconciled, and a page action calls it. The logic is never written inline on the page.

16.3 Planning your own extension

The habit to take from these case studies is to start from the business problem and the questions in 16.2, not from “which AL features should I use.” Answer those questions first, and the table design follows from the answers.

Chapter summary

In this chapter you:

  • Traced how every AL object type from Chapters 7 to 15 contributes to one working extension
  • Worked through a second case study using the same design questions, before seeing a suggested answer
  • Came away with a repeatable set of questions for starting any new extension from a business problem

Tasks

  1. Diagram your extension. Draw (on paper or in any tool) the six steps from 16.1 as boxes and arrows, labeling which AL object handles each step.
  2. Build Petty Cash Log. Implement the table, codeunit, permission sets, and at least one test for the case study in 16.2, using Chapters 7–15 as your reference — but write the code yourself.
  3. Try it yourself. Petty Cash Log’s suggested design uses a single auto-increment key instead of a composite one like Loan Repayment Schedule. Write one sentence explaining why a composite key wasn’t the right choice here.

Check your work: compare your Petty Cash Log objects against the reference solution in the Chapter 16 solutions.