Fan Out the Fee Engine

Fan Out the Fee Engine

Your logistics app totals shipment fees: every shipment carries fee lines, and each line's fee type decides which calculator runs. The catalog must stay open in both directions — partner apps keep adding fee types your code has never heard of, and when a partner app is uninstalled its fee type keeps sitting in the data as a naked number. The invoice run must survive both without a single case statement naming a fee type, and without ever crashing on a stored value nobody recognizes anymore.

Requirements

The starter ships four files. The interface "Fee Calculator" and the table "Shipment Fee Line" are the fixed contract — submit them unchanged, the tests bind to them. The enum and the engine are skeletons for you to finish.

interface "Fee Calculator"
{
    procedure ApplyFee(RunningAmount: Decimal): Decimal;
    procedure GetFeeLabel(): Text;
}

"Shipment Fee Line" has "Shipment No." (Code[20]) and "Line No." (Integer) as its primary key, and "Fee Type" (Enum "Shipment Fee Type").

1. Finish the enum "Shipment Fee Type". It must stay Extensible = true — the grading extension of rule 3 cannot compile otherwise — and keep the four shipped values None, Flat, "Fuel Surcharge" and Handling, which the tests reference by these exact names. Keeping the shipped ordinals (0–3) and adding no values of your own is good practice, not graded. Every value must resolve to a calculator: assigning the value to an Interface "Fee Calculator" variable — which is all the engine's GetCalculator of rule 5 does, and how the tests reach every calculator — runs that value's calculator.
2. Write the calculators as codeunits of your own — their names are your choice, the tests reach them only through the enum. Behavior of each, where ApplyFee receives the running amount and returns the new one:
   • Flat: returns the running amount plus a flat 15.00; GetFeeLabel returns FLAT.