EN NO

Modules · 14

Purchasing

Requisition to receipt, on the shipowner’s own thresholds, where nobody approves their own commitment.

What it is for

The requirement

The shipowner’s policy — not a conventionThere is no convention, no class rule and no Norwegian regulation that says how many quotes a purchase needs or at what amount a second signature is required. Every shipowner sets its own, and every shipowner sets them differently. So the thresholds here are the company’s, they are versioned, and an approval permanently records the version of the policy it was judged under.

Purchasing is where a ship management system usually stops being about ships. It becomes a procurement tool, with catalogues and approval matrices and an assumption that the buyer has a stable internet connection and a calm afternoon. None of those hold on a vessel that needs a seal by Thursday.

This module starts from the vessel’s need, keeps the approval rules the shipowner actually has, and never pretends the rules are universal. It also refuses the one thing every finance department asks for and no purchasing system should allow: a person approving a commitment they themselves made.

The purchasing tasks screen listing requisitions awaiting this person with their status and next action.
Pl. 01Purchasing: what this person owes the chain, and nothing else.

In detail

What the module does

  • Thresholds that are yours, and versioned. How many quotes, at what amount, approved by whom — all set by the company, and every change makes a new version. An approval records the version it was judged under, so a policy change next year does not retroactively make last year’s approval wrong or right.
  • Nobody approves their own commitment. The rule is in the domain, tested, and cannot be configured away. It is the single most common finding in an internal audit of purchasing and it is a structural refusal here.
  • Answers, not invitations. A supplier’s response is a priced answer to the specific need, compared on a landed total — goods, freight, duty, currency — because the cheapest line item is regularly the most expensive delivery.
  • Officer-only access, in four parts. Who may see prices, who may commit, who may approve and at what scope: four separate questions with four separate answers, because a purser who may raise an order should not necessarily see the fleet’s pricing.
  • An exception that is documented and never backdated. Sometimes the seal has to be on the quay on Thursday and the policy cannot be followed. The product records that as a documented exception, at the time it was taken, by the person who took it — and will not let it be entered afterwards with an earlier date.
  • Three quantities on the quay. Ordered, delivered, accepted. They are different numbers more often than anyone expects, and a system with one field for them loses the disagreement that matters.

Screens

What it adds to the app

  • My tasks — what this person owes the chain today
  • New requisition, raised from the vessel’s need
  • Orders, sourcing, deliveries and suppliers, for the office
  • The policy — thresholds, versions, and who approved which

The decision

Eight statuses, one next action

Every requisition is in one of eight states and every state has exactly one next action and exactly one person who owes it. That is what the whole module is organised around, because the failure mode of purchasing software is not a missing feature — it is forty open items and nobody knowing whose move it is.

The emergency route exists and is honest about being one: it is faster, it is recorded as an exception, and it is reviewed afterwards.