0.1.0.27 to 0.1.0.30: four defects, found and fixed the same day

---

The short version

Three of the four fixes protect the same thing from different angles: money that the product has already recorded somewhere, and a charter that quietly disagrees with it.

0.1.0.27 stopped a charter claiming it was paid after the payment was undone, and made a payment taken through the journal mark the charter paid without anyone pressing a button. 0.1.0.28 seeded a company somebody creates after Trident is installed, which until then got nothing and failed on its first charter. 0.1.0.29 stopped the guest-facing settlement statement printing an expense line with a blank category. 0.1.0.30 stopped a charter being deleted while it still held APA entries, an issued statement or commercial evidence.

Nothing else in the product changed across the four. There are no new features here.

---

0.1.0.27: the unapply fix

This is the build that carries the fix for the defect measured on 5 August, the one described in full on the known limitations page.

• A charter no longer reports itself as paid after the payment is unapplied. Undoing a payment now moves the schedule line back to Posted, and reapplying restores Paid. Before this, the invoice reopened correctly and the charter kept saying it had been paid.
• A payment taken through the payment journal marks the charter paid by itself. It did not before. The schedule line sat at Posted until somebody ran Sync Paid Invoices by hand, and closeout readiness reads that same line, so a fully paid charter could be blocked from closing. The unapply fix could not cover this on its own, because a payment applied while it posts takes a different road through Business Central. The charter now registers a payment from every route one can arrive by, and the change only ever promotes a line to Paid, never demotes one.
• The build compiles again. Three analyser errors had stopped it. Nothing about the product changed, it just builds.
• The APA Journal can add a line to a table that already holds entries.
• Two people opening the Trident Role Centre in the same instant no longer collide. The losing insert on the cue singleton is caught and the winner's record is read instead.

---

0.1.0.28: a company created after install gets seeded

Add a second company to a tenant that already has Trident, and until this build that company got no setup record, no APA expense categories and no pricing setup. Nothing said so. The first person to price a charter in it hit Charter pricing setup is missing, on a tenant that had been working fine for months.

The cause was that company setup ran at install and at upgrade, and neither happens for a company somebody adds later. Setup now also runs the moment a company is created.

Five tests came with it. One of them asserts the actual failure: pricing raises the error in an emptied company and succeeds once the seed has run.

What that does not prove is the new path in production conditions. The per-company setup was watched running in a company that had never held a Trident record, but the moment-of-creation trigger itself has not yet been observed firing end to end. It is on the list for the clean-install rehearsal.

---

0.1.0.29: no more blank category on the statement

The charter statement is the document a guest settles the advance provisioning allowance against, and it could show an amount with nothing beside it.

• The statement resolves the category instead of copying it. It took the code and description straight off the ledger entry. An entry written before customer-maintained categories existed carries only the old enum, with both text fields empty. The entry already knew the answer: a resolver has mapped that enum to a code and description since the category table was added, and nothing on the statement path called it. It does now.
• An APA entry can no longer be marked reviewed with no category at all. This shipped in the same build deliberately. The resolver falls back to the old enum, and an uncategorised entry leaves that enum at its default first value, so fixing the statement on its own would have replaced a visible blank with an invisible Provisions on the same document. Nothing anywhere forced a category. Review is now refused for such an entry, naming every offending entry number, and a statement only ever includes reviewed entries.
• The category backfill is testable and its legacy map exists once. It sat behind an upgrade tag that by design runs once and never again, so no test could reach it, and it carried a private copy of the old enum mapping that nothing held in step with the real one. The copy is gone and the upgrade asks the category table for the answer the running code uses.

Seven tests came with it. The build was installed through a real data upgrade, so the upgrade path ran across both companies on the container tenant. What that does not prove is that the backfill repaired any real data, because neither company holds a pre-category APA entry and it ran over an empty set.

---

0.1.0.30: a charter cannot be deleted while it still holds money

Found by a permission review that was looking for something else.

• The delete guard checked one thing and there were four. It refused when a payment line had been processed. A charter whose lines were all still Planned deleted cleanly while holding APA ledger entries, an issued settlement statement and commercial evidence entries. Nothing reads those three through the charter, so nothing failed and nothing warned. The rows stayed behind naming a charter number that no longer existed. Charter numbers come round again on a number series, and the next charter to take that number would show the previous charter's expenses and the previous charter's statement, on the finance pages and on the document a guest settles against. The delete now refuses on each of the three separately, and each message names which one is in the way.
• A charter that is allowed to go takes its own record of itself with it. The status log, the APA review history and the document links were orphaned by the same gap. They are deleted with the charter. The permission for that sits on the table itself and not on any persona, so the audit trail leaves with its parent and still cannot be cleared by hand.
• The permission review came back clean, and that is recorded here because a review that finds nothing tends to get quietly dropped. All four sets were read end to end. One item is a disclosure and not a fix: the Ops persona holds full rights on document attachments and cannot hold less, because Microsoft's own attachment page writes that table on the user's behalf.

Six tests came with it. Three of them went red on the first attempt for a reason that was not the guard, which is worth knowing if you write tests against this product: an expected error rolls an AL test back past its own uncommitted insert, so the row the guard was meant to refuse over was no longer there. They were rewritten to read the last error text.

---

Upgrade notes

Going from 0.1.0.26 to 0.1.0.30 runs everything the 0.1.0.26 note describes, and these four builds add no new step that walks your 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 thing to know if you added a company to your tenant before installing 0.1.0.28 and it never worked: the fix seeds a company created from now on, and it also seeds on upgrade, so the broken company is repaired by upgrading. You do not have to recreate it.

---

What still ships broken

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

• Most of payment unapplication still has no test behind it. The tests that exist cover one charter at a time. A payment spread across invoices belonging to two different charters, application against a credit memo in the same transaction, unapplying an APA settlement payment, and unapplying against a charter that is already closed all have nothing guarding them. Neither does a straight reversal with no unapplication first, which posts down a different path from the one the 0.1.0.27 fix subscribes to. If your charters routinely see credit notes or one payment applied across several charters, this is the area to press on.
• The charter number reuse consequence is a reading of the code and not a test. The 0.1.0.30 guard is proved against rows a test inserted. What makes an orphan expensive, a number coming round again and inheriting the previous charter's expenses and statement, has not been reproduced in a test.
• Neither API page has a runtime test. The codeunit behind expense import staging is well covered and the page shape is not. The one HTTP run that proved Business Central serves what the source declares was done by hand, once, against one company. Integrations must re-read the import status after calling promote.
• The permission contract records what is there today. A grant that changes fails the build. A grant that was already too broad when the contract was written stays, and only a human review finds it. The 0.1.0.30 review was one of those and it came back clean.
• 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.
• Not submittable to AppSource as it stands, for reasons that do not affect a per-tenant pilot install, and debugging is enabled as a deliberate pilot-time setting.

---

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