Sum a Filtered Set Correctly

Filtering

Easy

findset

repeat-until

aggregation

customer

Sum a Filtered Set Correctly

Finance wants a per-city credit exposure widget: the sum of customer credit limits in a city, plus a policy variant where no single customer counts for more than a given cap. The first version shipped and the numbers are wrong — multi-customer cities come up short, a one-customer city shows zero, and an empty city crashes the widget. The loop in the starter is the culprit.

Requirements

Create a codeunit named "City Credit Aggregator" with two public procedures:

procedure TotalCreditLimit(CityName: Text): Decimal
procedure TotalCreditLimitCapped(CityName: Text; Cap: Decimal): Decimal

Rules:

TotalCreditLimit returns the sum of "Credit Limit (LCY)" over every Customer whose City equals CityName — the whole value, exactly (searching North must not include a customer in Northport).
TotalCreditLimitCapped sums over the same set of customers, but caps each customer's contribution: a customer whose "Credit Limit (LCY)" is above Cap counts as exactly Cap; a customer at or below Cap counts at their own limit. Above-cap customers are capped, never dropped from the total.
Cap is always greater than zero, and the credit limits the tests seed are never negative.
A city with no customers totals 0 from both procedures — never an error.

What the tests check

The grading tests seed customers with run-time-generated credit limits into marker city names, next to decoys in other cities, and assert exact totals — the amounts are generated, so no constant can pass. The data is crafted so each classic aggregation-loop mistake produces its own wrong number: a three-customer city (losing the first record or keeping only the last amount comes up short), a single-customer city (a loop that steps to the next record before reading the first returns 0), an empty city (an unguarded find crashes), and a decoy city that merely extends the searched name. The capped tests place one customer below, one exactly at, and one above the cap — forgetting the cap, capping every customer, or dropping the above-cap customer all give a different total — and keep an above-cap decoy in another city, so the capped total must filter by city too.

Learn More

Hint 1

The starter's loop is wrong in three independent ways: it moves to the next record before reading the one it just found, it overwrites the running total instead of adding to it, and its find call errors out when the city has no customers. Each is a one-line fix.

Hint 2

FindSet() returns a Boolean and leaves you standing ON the first record of the set — so the canonical read loop guards with an if, reads the record inside repeat, and only then steps with Next(). Accumulate with += where := keeps only the last amount.

Hint 3

Capping happens per record, not per filter: a credit-limit filter like ..Cap silently removes the big customers instead of counting them at the cap. Keep only the city filter and, inside the loop, add whichever is smaller — the customer's "Credit Limit (LCY)" or Cap.

ALBusiness Central 28.4

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.