0.1.0.31 to 0.1.0.36: the numbers an operator was holding in their head

---

The short version

A charter has always known which vessel it is on, which broker arranged it and which country it embarks in. It used to ask the operator to type the consequences of all three anyway. The payment split, the broker's rate, the bank account holding the guest's money and the VAT percentage now arrive from where the answer already lived, and a value somebody has already typed is never replaced by any of them.

Two builds do something else. One reports the damage an older defect left behind, and one renames every object in the product without changing a single thing it does.

---

0.1.0.31 and 0.1.0.32: the payment split, and a finder for the old orphans

These two were built the same evening and 0.1.0.31 was superseded by 0.1.0.32 within hours, so they are written up together.

• The pricing scheme carries its payment split. The industry standard charter agreement treats the instalment structure as a property of the scheme, and Trident asked for it on every charter with nothing behind it. A pricing scheme now names a default payment template, and a charter created under that scheme arrives with it. A template chosen on the charter is never overwritten, and confirming a charter still refuses a missing template exactly as before.
• Charter records orphaned before the delete guard existed are now reported. The guard that shipped in 0.1.0.30 refuses the next orphaning delete and does nothing about the last one. Rows deleted under an earlier build survive the upgrade naming a charter that no longer exists, and charter numbers come round again. The Readiness Center now counts expense entries, settlement statements and commercial entries whose charter number matches no charter, on a row of their own. It warns and does not block, because those rows come from a version the tenant has already left and no setup page repairs a cleanup across three tables.

Three tests came with the payment split and five with the orphan count.

---

0.1.0.33: a charter can state what the broker is owed, and still cannot pay it

The word commission did not appear anywhere in the product while the broker's name sat on the charter header. The standard charter agreement states the commission as a percentage of the charter fee payable to the broker who arranged it, so Trident captured who the broker was and nothing about the broker's money.

• A pricing scheme carries a default commission rate, and naming a broker on a charter brings that rate onto the charter. A negotiated rate already there survives, and a scheme with no rate changes nothing.
• The amount is worked out, not typed. It comes off the net charter fee, so a discount reduces the base and a changed fee moves the money with it.
• Both directions of the same rule are refused. A commission rate on a charter with no broker is rejected, and so is removing the broker from a charter that still carries commission. Each refusal says which one it is.
• The money still cannot leave. There is no payable, nothing posts, and the broker is a contact and not a vendor, because no purchase or supplier machinery exists anywhere in the product to hang it on. This build lets a charter say what is owed and gives no way to pay it from Trident. It is half a feature on purpose and it is on the limitations page as one.

Seven tests came with it.

---

0.1.0.34: every object renamed, nothing changed

There is nothing to see in this build and it is here because it closes something that was going to get expensive.

Microsoft registered a three-letter affix to Marvera on 12 August 2026, and every object in the product was renamed onto it the same day. It was done now because no tenant outside the build environment holds Trident data, and a rename stops being free the moment one does. Five names had to shrink to fit the length limit that applies to object names, and their ids did not move. The integration surface did not move either, so anything reading Trident over the API reads exactly what it read before.

No test was added, removed, retitled or rescoped, and the suite came back with the same result on the renamed source as on the source before it. One of the two reasons Trident could not be submitted to AppSource goes away here. The other one, a missing telemetry connection string, is still open and neither has ever affected a per-tenant pilot install.

---

0.1.0.35: the APA bank account comes from the boat

A charter that takes an advance provisioning allowance cannot be confirmed without naming the bank account that holds it. Until this build that account was typed from memory on every single charter.

• A vessel carries the account its charters hold APA in, on a Finance group on the vessel card. A charter that names the vessel arrives with the account filled, and naming a vessel on a charter that already exists fills it too.
• An operator running one account for the whole fleet sets it once, on charter setup, and it is used when the vessel names none. The vessel wins when both are set.
• An account already on the charter is never replaced, and with neither configured the charter stays blank exactly as before.

Six tests came with it. What Trident decides here is which account arrives on the charter. Everything about the account itself stays where Business Central keeps it.

---

0.1.0.36: the VAT rate comes from the country

The charter VAT percentage was a number with nothing behind it. The charter already knew which country it embarked in and which country it disembarked in, and used neither.

• A country can be given a charter VAT percentage, with a description and a switch to turn it off. No rates ship with the product and none are derived. The figures are whatever the operator's own tax advice says they are.
• A charter takes the rate of the country it embarks in, on creation and when an embark country is named later. A rate somebody has already typed is never replaced, a rate switched off reaches nothing, and a country with no rate configured leaves the charter at zero.
• A charter that crosses a border takes no rate at all. When the embark and disembark countries differ the field is left blank on purpose. That is exactly where one country's rate is most likely to be the wrong number, and a confident default would hide it.

Seven tests came with it. The percentage is a figure on the charter and it is not a tax posting setup, so nothing here reaches a tax authority.

---

Upgrade notes

Going from 0.1.0.26 to 0.1.0.36 runs everything the 0.1.0.26 note describes, and nothing in these six builds walks your existing data.

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. The procedure is in the install runbook.

One behaviour changes for anyone already using the broker field. Clearing the broker now fails on a charter that carries a commission, and the message says to set the rate to zero first. Every charter arrives in this build carrying zero, so nothing can hit it until somebody enters a rate.

The rename in 0.1.0.34 is the one to read twice. Nothing a user clicks moved and nothing an integration reads over the API moved, but a report, a custom extension or a saved view written against Trident's own object names will not find them under the old spelling.

---

What still ships broken

The full register is on the known limitations page. What matters most about these particular builds:

• The broker commission is half a feature and stays that way. A charter states what is owed and there is no way to pay it from Trident. If your brokers are paid out of the same system that raises the charter invoice, this is not that yet.
• All four defaults share the same shape and the same limit. Each one fills a blank field once, at the moment the source of the answer is named. None of them watches for a later change, so moving a charter to another country after the fact leaves the old rate sitting there, and it is meant to, because a typed number is never overwritten by any of them.
• Charter VAT is a percentage on a charter and nothing more. It is not a tax posting setup, it reaches no tax authority, and no rates ship with it.
• Payment unapplication is tested against seeded data only. A payment spread across two charters, a credit memo closing an invoice in the same transaction, an unapplied settlement payment and a closed charter each got a test on 6 August 2026 and all of them are green. None of them has met a real ledger with a year of history behind it.
• Neither API page has a runtime test. The one HTTP run that proved Business Central serves what the source declares was done by hand, once, against one company.
• 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, and the pilot agreement's governing-law clause is deliberately unsettled. 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 reason now instead of two, and neither has ever affected a per-tenant pilot install. Debugging is enabled as a deliberate pilot-time setting.

---

Each of these builds has its package hashes written down, so whoever is eventually sent one can check they were sent that file. The current one is 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].