TransferFields Won't Save You

TransferFields Won't Save You

Every night an import drops proposed master-data edits into a staging table; a coordinator reviews them the next morning and applies the approved ones to the live Delivery Agent records. The first version of the apply routine was one proud line — TransferFields plus Modify — and it looked like it worked, until the pricing team noticed that agents moved to a better service group kept billing at the old rate, and a field the team had retired months ago started coming back from the dead. Moving a value into a field is not the same as validating it: only one of assignment, TransferFields and Validate runs the field's OnValidate trigger, and this task is about knowing which — and when a trigger must not run.

The tables (shipped complete — do not change them)

The starter contains two finished tables. The grading tests depend on their exact trigger behavior, so leave both tables as they are; your work is the codeunit.

Table "Delivery Agent" — the live master record:

• Field 1 "No." — Code[20], the primary key.
• Field 2 Name — Text[100].
• Field 10 "Service Group" — Code[10]. Its OnValidate recalculates "Base Rate": empty group → 0, BRONZE → 10, SILVER → 20, GOLD → 35, and any other value raises an error ("... is not a known service group."). It deliberately does not touch "Total Fee".
• Field 20 "Priority Level" — Integer. Its OnValidate recalculates "Total Fee" as "Base Rate" × (100 + 10 × "Priority Level") ÷ 100 — it reads whatever "Base Rate" is at that moment.
• Field 30 "Base Rate" and field 40 "Total Fee" — Decimal, side-effect fields; nothing but the triggers above ever writes them.