Docs · release note
0.1.0.37: the charter agreement terms there was nowhere to put
The standard charter agreement states four things Trident had no field for, so they lived in the contract and in somebody's memory and nowhere the system could see. Delivery and redelivery fees, the security deposit, the crew count and the cruising area. All four now have a place, and one of them changes what closeout tells you.
What this build is
A package that exists is not a release. This one was built, tested and hashed, and it has not gone out to a pilot yet. Nothing earlier went out to a pilot either, so the first build a pilot receives will already have all of this in it.
The whole suite ran against it and came back 586 passed, 0 failed, none skipped across 31 test codeunits on the evening of 12 August 2026. Run evidence is generated per machine and is not published. Ask and you get the raw result file.
The short version
Everything here is a field that the charter agreement fills in and Trident used to ignore. Two of them are money the operator can bill, one is money the operator is holding on somebody else's behalf, one is a headcount that belongs to the boat, and one is a line of contract text. The interesting one is the deposit, because it is the only money in the product that is meant to go back out.
Delivery and redelivery fees
Two amounts on the charter, refused below zero, and frozen once the charter is financially committed by the same lock that already holds the charter fee, the APA and the currency.
They are billable, not decorative. A payment schedule line can now be pointed at the delivery fees the same way it is pointed at net or gross charter, and it bills the two of them together. A line set to half bills half of both. A charter with no fees builds a zero line and not an error.
One thing was worth proving and is proved: a delivery fees line cannot absorb or leak the rounding remainder that the charter fee line carries. That is the property most likely to quietly break charters that already exist, so there is a test asserting it and not an assumption.
A security deposit, tracked apart from the APA
Guest money held against damage is not guest money spent on provisions, and Trident had one place for both. Now the deposit is its own amount on the charter, with a switch for having returned it, and the return records when it happened and who marked it.
- A deposit that has been returned cannot have its amount edited. A deposit still held can, because a correction before the money moves is a correction and a correction after it is a rewrite of history.
- Clearing the returned flag clears both stamps. If the return did not happen, the record of it does not survive.
- Marking a return on a charter that holds no deposit is an error. It used to be the kind of thing a system accepts silently and then nobody can explain the audit trail.
The deposit is never invoiced, and that is deliberate. Refundable money billed through the charter fee product would post as revenue, and the accounts would say the operator earned something they are holding for somebody else.
Crew count, from the boat
A vessel carries its crew count, and a charter takes it when the vessel is named, on a new charter and on an existing one. A count already typed on the charter is never replaced, and a vessel with no count leaves the charter at zero. There is no fleet-wide default, because a single number covering every boat is a number nobody could defend.
Cruising area
A line of contract text on the charter. It stores what the agreement says and nothing reads it, and this note says so plainly instead of dressing it up.
Closeout grew a twelfth row
The closeout checklist now watches the deposit. No deposit held reads Not Applicable, a deposit returned reads Ready, and a deposit still held reads Attention.
Attention, and not blocked. Returning a deposit is a bank transfer that can lag the paperwork by days, and a charter whose billing, APA and evidence are all settled should still be closable. Closeout says the deposit is outstanding and leaves the call with the operator.
The mistake this build made, and what caught it
The deposit row was first put in the billing section of the checklist. A test written months earlier failed immediately: every billing row on that checklist has to drill through to the payment schedule, and the deposit is a figure on the charter with no schedule line behind it, so there was nothing on the other side of the click.
The test was right and the placement was wrong. The row moved next to the charter lifecycle row and the closeout tests moved with it. No assertion was loosened to get the build green, which is the only reason the figure at the top of this page is worth printing.
Upgrade notes
Going from 0.1.0.26 to 0.1.0.37 runs everything the 0.1.0.26 note describes, and the six builds in the 0.1.0.31 to 0.1.0.36 note before it. This build adds no table, and nothing in it walks your existing data.
| Change | Effect on an existing charter |
|---|---|
| Eight new fields on the charter | All empty or zero. Every new behaviour is dormant until somebody types something |
| One new field on the vessel | Empty. Charters already created keep the crew count they have, which is zero |
| One new closeout row | The only visible change. Twelve rows instead of eleven, and the new one reads Not Applicable |
Take the backup you would take for any extension upgrade. After upgrading, confirm the four assignable permission sets are still assigned as intended: Trident Admin, Trident Ops, Trident Read and Trident API. Nothing about them changed in this build. The procedure is in the install runbook.
What still ships broken
The full register is on the known limitations page, and nothing in this build closes any of it. What matters most alongside these particular changes:
- The cruising area does nothing. It is stored and displayed and no rule anywhere consults it.
- The deposit has no posting path. Trident records that money is held and that it went back. Moving it is a bank transaction you do outside Trident, and the checklist is watching a flag somebody sets by hand.
- The broker commission is still half a feature. A charter states what is owed and there is no way to pay it from Trident.
- Every default in the product fills a blank once, at the moment the source of the answer is named, and none of them watches for a later change. A typed value is never overwritten by any of them, and that cuts both ways.
- Neither API page has a runtime test that repeats. The shape is held to a contract on every change, and nothing re-fires either of the two HTTP runs that proved the platform serves what the source declares.
- No live non-SUPER sign-off exists for all three UI personas in a controlled tenant on this build.
- The licence terms and the pilot agreement are unreviewed. Nothing gets signed until both come back from a lawyer.
- No telemetry reaches Marvera. If something is wrong on your install, tell me, because I will not find out on my own.
- Still not submittable to AppSource, for one remaining reason that has never affected a per-tenant pilot install. Debugging is enabled as a deliberate pilot-time setting.
This build has its package hashes written down, so whoever is eventually sent the file can check they were sent that one. They are on the install page. Writing the hashes down is not the same as shipping, and the sentence at the top of this page still stands. If something here is wrong or unclear, say so: [email protected].