0.1.0.38: the invoice comes out in the guest's language

---

The short version

One field, filled from one place. A new charter takes its invoice language from the customer the invoice will be addressed to, which is the bill-to customer when one is named and the chartering customer otherwise. A language already typed on the charter is never replaced. A customer with no language on their record leaves the charter blank, and blank is the honest answer.

---

The bill-to customer decides it

Charters are often booked by one party and paid by another: a broker, a management company, the guest's own office. Trident already knows which of the two the invoice is addressed to, because that is the customer it raises the invoice against. The language follows the same party, not the one who signed.

Naming either customer re-evaluates it. Put a bill-to customer on a charter that already exists and the language moves to theirs. Put a chartering customer on one with no bill-to and it moves too, because the bill-to follows the chartering customer while it is empty.

This is the half of the change worth stating plainly, because it is the half somebody would later flatten to whichever customer is closest to hand. There is a test pinning the precedence for exactly that reason.

---

A typed language is never overwritten

A guest who asks for their paperwork in English when their company record says German is a decision, not a gap. Trident fills a blank once, when the customer is named, and after that the value on the charter is whatever the operator left there.

That behaviour is the same one every other default in the product has, and it cuts both ways: change a customer's language next year and the charters already created keep what they had.

---

The permission set that changed

This is the first default in Trident whose answer comes from a Business Central record and not from a Trident one, so Trident Ops now reads the customer list. Nothing else about the four permission sets moved, and the two read-only sets were left alone because neither creates charters.

The alternative was to fill the language only for people who can see customers and quietly skip it for everybody else. That was rejected. The same charter created by two colleagues would come out differently and nothing on screen would explain why, which is worse than a permission set that states out loud what it needs.

The restricted-user checks that exist to catch a permission set growing too wide all still pass, so nothing else was opened by this.

---

What is not in this

• No company-wide default. A single language covering every charter is a number nobody could defend, the same reasoning that kept a fleet-wide crew count out of 0.1.0.37.
• Nothing is pushed onto the invoice itself. Business Central already puts the customer's language on a sales document when it creates one. Trident's field is the charter's record of what was agreed, and overriding the platform's own answer would be Trident asserting something about a document it does not own.
• No fallback past the customer. No country guess, no company default. If the customer record has no language, the charter says nothing.

---

Upgrade notes

Going from 0.1.0.26 to 0.1.0.38 runs everything the 0.1.0.26 note describes, the six builds in the 0.1.0.31 to 0.1.0.36 note, and the charter agreement terms in the 0.1.0.37 note. This build itself adds no table and no field, and nothing in it 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.

---

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 this particular change:

• 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.
• The broker commission is still half a feature. A charter states what is owed and there is no way to pay it from Trident.
• The cruising area does nothing. It is stored and displayed and no rule anywhere consults it.
• The security 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.
• Neither API page has a runtime test that repeats. Two HTTP runs have proved the platform agrees with the source, the second of them as a restricted user and driven by a script, and nothing re-fires either when a page changes.
• 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].