Union of Two Filtered Sets

Filtering

Medium

mark

markedonly

customer

Union of Two Filtered Sets

Marketing is launching a phone campaign, and the callers want one list built from two rules: every customer located in the campaign city, plus every key account — a customer whose credit limit reaches a threshold — wherever they live. Two easy filters, except the rules live on two different fields, the callers want a single list, and nobody may be called twice.

Requirements

Create a codeunit named "Campaign Call List" with one public procedure:

procedure BuildCallList(var Customer: Record Customer; CampaignCity: Text; VipCreditLimit: Decimal)

Rules:

The caller hands you a fresh Customer record variable (no filters, no special state) and afterwards reads the list by iterating that same variable with FindSet/Next — whatever view your procedure leaves on the record IS the call list.
The list contains every customer whose City equals CampaignCity — the whole value, exactly (a customer in Northport is not in the city North).
The list also contains every customer whose "Credit Limit (LCY)" is at or above VipCreditLimit, whatever their city — a credit limit exactly equal to the threshold qualifies.
Nobody is called twice: a customer matching both rules is visited exactly once when the caller iterates the list.
Nobody else is called: a customer matching neither rule must not appear in the list.
The procedure only shapes which records the caller sees — it must not insert, modify, rename or delete any customer.
The caller may iterate the list several times; every pass must visit the same customers.

What the tests check

The grading tests seed customers with unique city-name markers and run-time-generated credit limits, call BuildCallList once, then iterate the record your procedure shaped, counting how often each seeded customer is visited: qualifying customers exactly once, non-qualifying decoys never. Expect a decoy city that merely starts with the campaign city's name, a credit limit one cent below the threshold next to one exactly at it, a customer matching both rules who must show up exactly once, and a customer matching neither rule who must both stay off the list and still exist in the database after the call — the tests also re-read every seeded customer afterwards and verify it still exists and is completely unchanged, field for field, so any write to a customer fails grading even if the value is later restored. The tests run in a real company with other customers present — that's fine; the assertions only look at the customers the tests seed.

Learn More

Hint 1

Try expressing 'city X or credit limit at least Y' with record filters and watch what happens: filters on two different fields always combine with AND. No single filter expression can produce this list — you need two passes over the table and a way to remember what the first pass found.

Hint 2

A record variable can remember individual rows across filter changes: Mark(true) tags the current row, and the tag sticks to the variable no matter how the filters change afterwards. Loop the city set tagging every row, then swap the filters to the credit-limit rule and tag those rows too.

Hint 3

After both passes, clear the field filters and switch the view with MarkedOnly(true) — iteration now visits exactly the tagged rows, each one once. Two traps: remove the city filter before applying the credit filter (or the second pass tags the intersection), and clear filters field by field at the end — Reset wipes the marks along with the filters.

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.