What’s New
Editing custom fields on a contract type in Settings → Contract Types had several rough
edges around calculated currency fields. A field that pointed at another field further down the
list refused to save at all, deleting a field looked like it worked but never did, and when the
server did reject a save the message gave you nothing to act on.
Fixes
-
A calculation can point at a field further down the list. Fields are now saved in the
order their calculations depend on each other, so a “TC Fee” that is calculated from an
“Agent Split” you just added below it saves correctly. Previously it failed with
Calculation anchor field not found on this contract type. -
The list stays in the order you arranged it. Saving in dependency order no longer reshuffles
how the fields appear — on the contract type, on every contract using it, and in the version
history. -
Deleting a custom field actually deletes it. Removing a field and saving used to report
success while quietly keeping the field, which reappeared the next time you opened the
contract type. -
A field other fields are calculated from can’t be deleted by surprise. Removing one now
tells you which calculated fields still depend on it, instead of silently leaving it in place. -
Save errors say what is wrong. Validation failures — a calculation loop, a duplicate field
name, a field that can’t be deleted — now appear in full. They previously collapsed into a
generic Failed to update contract type. -
One save creates one version. A contract type with five custom fields used to record five
versions every time you saved it, each capturing a half-applied configuration. Saving now
records a single version describing the finished contract type.