Docs · runbook
Install it, prove it landed, upgrade it, take it out
Written for the administrator who will actually do it. The docs page is the shorter version; this one covers the parts that matter after the first hour, which are upgrades and removal.
Before you start
- Extension
- Trident, publisher Marvera
- Version
0.1.0.46- Minimum base application
25.0.0.0- Runtime
14.0- Object range
70241000..70241999- Distribution
- Per-tenant extension upload. No AppSource listing
This page describes 0.1.0.46, packaged on 13 August 2026 and queued for the next pilot delivery. Nothing has gone out to a pilot yet, so there is no older version in the field: the build described here is the build a pilot receives, and the limitations page says what it still gets wrong. The file is sent per pilot; there is no download link, deliberately.
Two things to settle before the install window, because both are yours and neither can be fixed from my side.
- The tenant allows per-tenant extension uploads, and whoever installs holds the administrator rights Extension Management needs. On a managed tenant that often sits with the partner who administers the environment, not with finance.
- The target is a sandbox first. This is a 0.1.x build. Install it on a sandbox copy, run a real charter through it, and only then have the conversation about production.
Nothing leaves your tenant
Trident makes no outbound network calls. There is no HTTP client anywhere in the source, no sync, no export, and no Marvera-side service for it to talk to. Everything it writes stays where you installed it. Privacy covers the detail.
That paragraph is checked, not just asserted. Any HTTP type appearing in the source, or any Application Insights key appearing in the manifest, fails the build, so the sentence above cannot quietly stop being true between one version and the next. The same check holds the numbers in the table above against the manifest they came from, in both directions, so a version bump cannot leave you planning an install window from a stale figure. That check is merged and it runs on every change.
1 · Check the file, then upload it
Before anything is uploaded, confirm the file you were sent is the file that was built and tested. Run this where the .app sits:
Get-FileHash -Algorithm SHA256 .\Marvera_Trident_0.1.0.46.app
- File name
Marvera_Trident_0.1.0.46.app- Size
- 1,617,045 bytes
- SHA256
9457BC749DE3699F46256651C7A7A6D9313BBBD6E8E6B189253337E356FB56B0
If the hash does not match, stop and tell me. Do not upload it. The likely explanation is dull, a truncated download or an older build sent by mistake, but the check costs ten seconds and the alternative is installing something nobody can account for.
You may also receive a second file whose name contains TridentTests. Do not install it. It is the test app. It belongs in the build environment and it has no place on your tenant. If it reached you, it reached you by accident.
Then: Extension Management, then Manage, then Upload Extension. Point it at the production .app and let the deployment finish before touching anything else.
The deployment status page reports the outcome. If it fails there, nothing was installed and nothing needs undoing. Send me the deployment status detail and your base application version and I will tell you what it means.
2 · Assign permission sets
Four assignable sets ship with Trident. None of them needs SUPER.
| Set | Object | Who holds it |
|---|---|---|
| Trident Admin | 70241000 | The person who configures Trident. Everything Ops does, plus setup, payment templates, charter terms templates, pricing setup and the guided setup |
| Trident Ops | 70241017 | The daily job. Charters, schedules, invoices from stages, APA entry and review, reconciliation, statements |
| Trident Read | 70241018 | Look, do not touch. Charters, APA, documents and evidence. No APA journal, no settlement actions |
| Trident API | 70241019 | A service account behind an integration, and nothing else. API guide |
Admin includes Ops, so an administrator needs only the one set. Ops and Read are independent of each other; do not give a reviewer both, because Ops is the wider grant and it defeats the point of the read persona. API is in none of the others and none of the others is in it.
These sets grant what Trident needs. They do not grant the standard Business Central permissions a person needs to be a finance user in the first place, so your normal sales and general ledger sets still apply on top.
3 · Assign the role centre
The profile is Trident Finance. Assign it to the operators and reviewers who live in Trident all day. An administrator who only visits to configure things does not need it.
4 · Complete setup
Trident registers a guided setup called Set up Trident Finance, filed under First Invoice. Start there, or open Charter Setup directly. The setup record is a singleton created for you at install, and it cannot be deleted.
| Field | Needed for |
|---|---|
| Charter No. Series | Assigning charter numbers. Required before the first charter |
| Charter Fee Item No. or Charter Revenue Account No. | Charter fee invoice lines. One of the two is required |
| APA Item No. or APA Revenue Account No. | APA advance invoice lines and settlement documents. One of the two is required |
| Default APA % | Pre-filled on new charters. Optional |
| Default Currency Code | Pre-filled on new charters. Optional |
| Default Payment Terms Code | Pre-filled on new charters. Optional |
| Default APA Bank Account No. | Pre-filled on new charters that name no vessel account of their own. Optional, and only worth setting if the whole fleet holds APA in one account |
Two rules catch people out. Both are enforced in code, so neither is left to guesswork.
- A blocked item is not accepted as a billing product, and neither is a G/L account that is blocked or does not allow direct posting. Trident checks the product is usable, not merely that a value was typed in.
- Scheduled billing needs at least one active payment template with active lines. Without it, charter billing setup can look complete and schedules still will not generate.
5 · Verify it landed
Four checks, in order. The first three are free. The fourth is the one that proves it works.
- Extension Management lists Trident, publisher Marvera, version 0.1.0.46, installed, in every company you intend to use.
- Setup Readiness Center runs thirteen checks across numbering, charter billing, APA billing, payment templates, payment schedules, pricing setup, the pricing schemes your charters are actually on, APA categories and guided-setup completion. Each row has a status, a detail line and the action that clears it. Blocked means the named thing will fail; a warning means it will work but something you probably wanted is missing.
- APA Expense Categories holds the ten seeded rows: Provisions, Fuel, Harbour Fees, Crew Expenses, Entertainment, Maintenance, Transfers, Laundry, Communications, Other. They are written per company at install, at upgrade, and when a company is created afterwards, so a company missing them is a company the seeding did not reach.
- Create one charter, generate its payment schedule, post one invoice from a schedule line, and check it appears under the charter's document links. Shortest path that exercises setup, numbering, billing product and invoice sync together.
Seeding runs per company. On a multi-company tenant, check each company. Do not assume the first one is representative. Before 0.1.0.28 a company created after the install got none of it, and charter pricing failed in that company until somebody worked out why; see the known limitations.
Upgrading between builds
Upload the newer .app the same way. Business Central runs Trident's upgrade code once per company. Ten steps exist, each guarded by its own upgrade tag so it runs exactly once and is safe to re-run. Six touch data.
| Step | What it does |
|---|---|
| APA categories | Backfills category code and description on APA entries that carry only the legacy category |
| Currency snapshots | Fills in missing currency snapshots on APA entries |
| Evidence states | Flips an entry from Missing to Attached where a receipt attachment already exists |
| Review history | Writes one baseline review entry per APA entry that is not draft, so review history is not empty for pre-existing entries |
| Commercial evidence origin | Re-stamps existing entries whose origin was UI as Upgrade |
| Cue singleton | Removes blank-key cue rows and re-initialises the singleton |
The remaining four set their tag and change nothing; they exist so later builds can hang data work off a known baseline.
Four of these walk every APA entry in the company. On a first install there are none and it is instant. On a pilot company with real history it is proportional to the number of APA entries, which for charter finance is small. It is still an upgrade, so take the backup you would take for any extension upgrade.
Removing it
Uninstall from Extension Management.
Business Central's uninstall dialog decides what happens to the data, not Trident. The dialog offers to delete extension data for all companies: leave it unticked and the Trident tables stay in your tenant untouched, tick it and they go. Trident does not delete anything on your behalf and has no uninstall trigger that touches data.
Your Business Central data is unaffected either way. Trident writes charters, schedules, APA entries and evidence into its own tables. It links to standard sales documents and customer ledger entries and never replaces them. Posted invoices, credit memos and ledger entries are Business Central records and stay exactly as they were.
If something goes wrong
[email protected] for anything with a security dimension, and the disclosure policy says what happens after you send it. [email protected] for everything else. These save a round trip each:
- Base application version, and whether it is a sandbox or production.
- Trident version from Extension Management.
- The company name, because install and upgrade both run per company.
- What the Setup Readiness Center says, row by row.
- The full error text, copied out. A description of it is no use.
Acknowledgement inside two business days. During a pilot there is no committed resolution time; the licence terms say what that does and does not promise, and known limitations says what is not covered yet.