0.1.0.41: the readiness centre catches a pricing scheme nothing can apply

---

The short version

The readiness centre gained a thirteenth check. It looks at the pricing schemes your charters are sitting on and reports any whose setup is missing or switched off. A scheme nobody uses is left alone. A scheme charters depend on and nothing can apply is now a blocking line, with the scheme named.

---

Why this was worth a build

Trident ships three pricing schemes and sets each of them up when it installs. Another extension can add a fourth. Trident cannot set up a scheme it has never heard of, and until this build nothing told you one was missing.

So the failure surfaced at the worst possible moment. Somebody opened a charter, tried to price it, and was told pricing setup was missing for a scheme the company had been using for weeks. Everything upstream of that, the readiness centre included, said the company was ready.

A setup gap should be caught by the page whose whole job is catching setup gaps, and not by the person trying to do the work.

---

What it actually reports

• Only schemes in use. A pricing scheme nobody has put a charter on is not a setup problem and is not named. A company that never touches a scheme somebody else added is never nagged about it.
• Missing and switched off are separate. A scheme with no setup at all, and a scheme whose setup exists but is inactive, appear under separate headings, because the fix differs. One means create the row, the other means tick a box.
• Only the headings that apply. If nothing is switched off, the line does not carry an empty heading saying so. A sentence that reports an absence costs you a read and tells you nothing.
• The schemes are named. The line says which ones, so the fix is the pricing setup list and one row per name, not a hunt.

---

It blocks guided setup and stops no posting

The line is a blocker, and blocker means one specific thing here: guided setup stays open until it is fixed. Nothing about it prevents a posting, closes a period, or interferes with a charter that is already priced.

It earns the stronger wording because the fix is one row and the thing it breaks is live work. The orphaned-records check beside it stays a warning for the opposite reason: an old orphan has no clean fix, and shouting about it every morning would only train people to ignore the page.

---

What is not in this

• No scheme is set up for you. Trident will not invent pricing setup for a scheme somebody else added, because it has no way of knowing what that scheme is meant to charge for.
• No existing check changed. The twelve that were there report exactly what they reported before, in the same order.
• Nothing new on the API. The two API pages are unchanged.
• No new field and no new object. The readiness centre is worked out when you open it, so there is nothing stored and nothing to migrate.

---

Upgrade notes

Going from 0.1.0.26 to 0.1.0.41 runs everything the 0.1.0.26 note describes, the six builds in the 0.1.0.31 to 0.1.0.36 note, the charter agreement terms in the 0.1.0.37 note, the invoice language in the 0.1.0.38 note and the status history in the 0.1.0.39 note.

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.

---

There is no 0.1.0.40

0.1.0.40 was built, tested and written up. Then the wording this check puts on screen was changed to drop a placeholder, and by that point the file hash of 0.1.0.40 was already written on the install page. Publishing a different file under a hash somebody had been told to check would have made that page lie, so the version moved instead. No 0.1.0.40 package went to anyone.

---

What still ships broken

The full register is on the known limitations page, and this build closes none of it. What matters most alongside this particular change:

• Pricing setup is still one row per scheme. This build tells you when a row is missing or switched off. It does not make the row carry more than it did, and what else belongs on it is still an open question.
• 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].