Help for each MaeWest product line.

MaeWest Office is installed on each user's workstation and shares one central SQL Server database on an office PC or server, so all office users work from the same records.

For a standard deployment, the installer handles the technical setup: SQL Server Express, the application database, firewall access, and the workstation configuration file.

Each workstation needs the installer package supplied with the licence and normal network access to the office LAN or VPN. The host PC should normally remain powered on during office hours.

For a normal MaeWest install, you do not install SQL Server manually. Run the Office installer on the machine chosen to host the database and select the shared database option.

The installer creates the EXPDB database, opens the required firewall rule, and configures the application login used by workstations.

If MaeWest is being attached to an existing corporate SQL Server, your IT team should enable TCP/IP, use a reachable SQL Server instance, and confirm the firewall allows workstation connections.

For standard deployments, end users do not need SQL Server logins. The installer creates the application login and workstations use the generated configuration.

To add a new user, give them Windows/network access, run the workstation installer, and point it at the host machine.

If your IT team manages SQL Server manually, they can create an application login mapped to EXPDB with the required read/write permissions.

The workstation installer writes appsettings.json automatically. In normal use, operators should not need to open or edit it.

The file tells MaeWest where the shared database is hosted. It may need to be regenerated if the host PC is renamed, replaced, or moved to a different SQL Server.

Because it may contain connection details, treat appsettings.json as a configuration file and do not post it publicly.

To deploy MaeWest to a new workstation, run the installer supplied with the licence, enter the host machine name when prompted, then start MaeWest from the desktop shortcut or Start menu.

There are no per-user database roles to assign for a standard install; the host setup and workstation installer handle the connection details.

For off-site users, configure the VPN before expecting the workstation to reach the office database.

Remote users need a secure VPN connection to reach the office network when working directly with the shared database.

When the VPN is unavailable, Field users should use the signed transfer-bundle workflow instead of trying to write directly to the office database.

Bundles can be saved locally and later submitted over VPN, emailed, transferred by USB, or imported by an office administrator.

The Field app is designed for operators who may not always have live connectivity. It records Field data locally and packages selected records into signed ZIP bundles.

Bundles are saved under Documents > MaeWest > Transfers. They can be submitted to the office server when VPN is available, or sent to the office for manual import.

The bundle workflow is safe to repeat: records already present on the office server are detected and skipped or reviewed according to the import rules.

When a Field user has VPN connectivity, they can submit a newly created bundle directly to the office server or submit an existing saved bundle later.

The submit process connects to the configured remote database, pushes records from the bundle, and shows a summary of inserted and skipped rows.

A ZIP bundle remains saved locally as a backup, even when direct submission succeeds.

Office administrators use Import Bundle when a Field bundle arrives by email, USB, network share, or any other file transfer method.

The Import Preview dialog shows the operator, bundle date, bundle hash, tables, row counts, conflicts, and any report files included.

After review, the administrator clicks Import. The app records inserted rows, skipped rows, conflict decisions, copied report files, and the import log path.

A row conflict occurs when a bundle contains a record with the same key as an office record but different payload values.

The Import Preview dialog allows the administrator to Skip, Accept, or Reject each conflict. Skip and Reject leave office data unchanged and record the decision in the audit chain; Accept performs an audited update.

Conflict decisions appear in the import summary, import log, and audit chain so an auditor can reconstruct what happened.

MaeWest records add, edit, delete, and bundle-import actions in a tamper-evident audit log.

This protects both the data and the operator: if a report is questioned, the audit trail shows what changed, who changed it, when, and why.

Bundle imports write anchor rows using the bundle's SHA-256 content hash, so an auditor can filter the audit log and see the complete import envelope.

The audit trail applies to data changes made inside MaeWest. It does not monitor externally edited Word, PDF, or template-derived reports such as Discharge Reports, STS Reports, or other documents edited outside the application.

When a record is edited or deleted, MaeWest asks for a reason and a category before saving.

Categories identify whether the change was a typo or clerical correction, a material correction affecting report values, or another explained reason.

The reason and category become part of the audit record and cannot be silently altered without breaking chain verification.

Reports re-check the audit chain for the rows behind the report and display a verification banner.

A green banner means the chain verified successfully. A red banner means one or more audit rows did not match their stored fingerprint and the report should not be treated as audit-quality evidence until investigated.

Administrators can use the Audit Trail Viewer to locate and investigate the affected audit row.

Generated reports include a Data Integrity change summary showing inserts, updates, deletes, and bundle-import activity behind the rows shown on the report.

Typo corrections are counted, while material corrections are listed with before-and-after values and the written reason.

The same integrity summary is written beside exported reports so audit evidence can travel with the PDF.

The Audit Trail Viewer is an Office administration tool for reviewing audited changes. It is read-only and cannot modify records.

Administrators can filter by table, author, date range, operation, and category, then verify the visible chain or export the results to CSV.

The detail pane shows the full audit record, including the canonical JSON used to compute the row hash, so an external reviewer can independently confirm the evidence under supervision.

MaeWest Blending pairs a Trader app on shore with an FSO app on the vessel so every blending instruction is signed on issue, executed against the vessel's own tank mirror, and returned as a signed executed record.

The workflow is deliberately simple: pair the two installations, refresh the latest vessel bundle, draft the blend, issue a signed instruction, and import the executed result back on the Trader side.

There is no server or live link; the two applications exchange signed files by USB, email, or network share.

Install both apps, pair the installations, and confirm the pairing fingerprint matches on both sides before any campaign work begins.

Load the FSO master data for tanks, grades, and calibration tables, then populate the Trader component library with the grades and cost data you will actually blend against.

Freeze the design around the current release and re-read the operating notes if the software version changes.

Refresh the latest tank mirror bundle from the vessel, open the Blender tab, choose the target grade and quantity, and add the source lines until the spec badge is green.

Write the FSO note for the operation, then issue the instruction. The app signs the record, appends it to the audit chain, and exports a signed instruction bundle for the vessel.

For repeatable recipes, save or reuse a favourite recipe so the same blend logic can be reused on future instructions.

Import the signed instruction bundle on the FSO side, verify the signature, and confirm the instruction still matches the cargo brief before the operation starts.

Execute the transfer through the normal cargo procedure, log actuals in the Executed tab as the operation progresses, then sign and export the executed record back to the Trader.

The app refuses duplicates and warns if the instruction appears stale or the tank mirror is out of date.

If a signature is invalid, ask for a fresh copy rather than trying to force the import. If the same instruction is imported twice, the duplicate warning is intentional and should be treated as a guardrail.

If the tank mirror is out of date, refresh the latest vessel bundle before issuing an instruction. If the instruction looks old or stale, stop and confirm the campaign reference before proceeding.

If a genuine correction is needed after signing, use the correction flow so a new signed record is created rather than overwriting the original.

Keep the instruction file, executed record, and related bundles for the campaign lifetime plus one year because these are the evidence you can hand to an auditor.

Every record is hash-chained, so an auditor can verify the signed instruction and the executed record as a paired history rather than as isolated files.

The app also supports a CofQ-style report from the Reports tab to help explain the result, even though the v1.0 release keeps the evidence loop focused on signed records and bundle history.

Do not edit system clocks to backdate an entry, do not share a signing identity between two people, and do not archive or delete the instruction and bundle files after import.

Do not run two campaigns from the same Trader database into the same FSO database without clearly identifying the campaign reference on the instruction.