Distrib — the portals

The manager portal, the consumer site and the till, screen by screen.

In detail

Each site is an instance of the same base, made up of configured pages. Three filters apply everywhere: the facet — a Distrib page disappears if the facet is not subscribed or not visible in the context — the role, and the context, whose scope is enforced server-side. Every list shares the same base: search, autocompletion filters, server-side sorting, pagination, export and indicators for the selection.

The manager portal

The fleet

One row per point of sale — the business identity, not the device: online or offline state, label, type, bound device or not, site, organisation, lifecycle with the "changed, not published" marker, consumable levels as coloured dots, catalogue publication date, last sale, and the day's revenue per currency, over the site's local day.

The point-of-sale record

The header gives the label, the device state as a duration, the type, the status, the bound device, the organisation and the fleet. The business block adds the lifecycle, the site, the last sale, the day's takings, pre-filtered links, and the actions: suspend or resume sales, restart, republish.

The tabs: the summary — a unified timeline of alerts, sales, logs and events — telemetry, configuration, then, for a recipe machine, consumables, menu, calibration, usage, sustainability and maintenance.

Point-of-sale configuration

• A button turns a business identity into a point of sale.
• Greyed out with its reason if it is awaiting qualification, retired, or of a type Distrib does not sell.
• A publication banner shows "changed, not published" with the matching button, or the date it was brought up to date.
• Identity: the type (read-only, immutable, with the reason shown), the site, the VAT context, the business status, the label and the currency.
• Policies in three sections — selling, payment, timeouts — each with its "inherited from type" or "overridden" marker and its switch.

Sales

Two instances of the same page: sales, and sales to review. The indicators for the selection give the count, the net revenue, the average basket, the settled amount and the subsidy.

The receipt shows its header — number, status, review reason, point of sale, organisation, consumer, with the offer and publication cited — then a timestamped timeline: created, priced, reviewed by whom and when, settled or cancelled. Then come the lines with their VAT, the totals, the linked operation with its detection hypotheses, and the payment part by part. The actions: confirm the review, correct it, settle, or cancel with a mandatory reason.

Operations

The raw facts reported by the machine, with their outcome, their flag severity (clean, notice, review, error), their confidence, the identification mode and the linked receipt. The detail opens in eight tabs: detection, actor, pricing, machine settlement, field, photographs, replay — which recomputes the receipt without writing anything — and the raw fact as ingested. An operation is never modified.

Catalogue

Label, nature, price, unit, VAT class (never a rate), default shelf life, meal voucher eligibility, external reference, and the "deployed in N offers" counter that leads to the offers concerned. The creation and edit form is the same one. You archive, you never delete. The spreadsheet import returns a line-by-line error report.

Offers

Title, point of sale, layout, validity window and temporal rank (current, future, past), the "in place at the point of sale" marker — the assortment the driver actually loaded, distinct from the one the dates propose — the number of locations and the last publication. The detail lists locations with the resolved price and where it comes from, with the inherited value shown alongside. The visual editor works by drag and drop, with a comparison before publishing, templates, duplication and printing.

Publications

Date, point of sale, scope, included offers, state, publisher and manifest fingerprint. The detail shows the published offers and the manifest files with their fingerprints.

Payments

This is the Octopoda Pay transaction portal, served inside the manager portal: indicators per currency and per means, then each transaction with its receipt, its holder, its means, its nature, its provider, the amount requested and the amount settled, its status and its error code. The actions: refund, issue a credit note, open a dispute.

Administration

• Simulated provider: the queue of pending payments, with approval or refusal, which replay exactly the path of the real provider, as often as you like.
• Review: the queue of sales to review, each decision recorded with its author.
• Disputes: opening, investigation, decision, partial refund line by line.
• Closings and accounting export: a frozen and versioned VAT report, an exchange format, gapless numbering, a signed audit export, payout statements per merchant.
• Consumers: their account, their organisation, their expandable means of recognition — with revocation or reactivation — the queue of unattached badges, import and anonymisation.
• Subsidies: plans per organisation, and meals defined by a time slot, days, a readable rule and a base of eligible products.
• Customer feedback: the rating, the problem type, the comment, then the decision — credit or refuse, with a mandatory reason.
• Sites: label, country, time zone, employer reference, VAT contexts.
• Rules and promotions: discounts, meal deals, promotional codes with their quota and their uses, and the basket simulator to check before publishing.
• Merchants: their catalogue, their attributed sales, their payout accounts and their statements.
• Fleet map and third-party connectors: points of sale with no Arkipelis hardware, product mapping, and quarantined facts.
• Integrations: outbound notifications with their secret and delivery state, and interface keys for partners.
• Recovery: open debts, reminders, write-offs.
• Replenishment orders: products and quantities per point of sale, generated from the alerts.
• The day's round, with the assortment to put in place.

The tabs of a recipe machine

1. Consumables: the level as a dot, editable for a machine without a probe.
2. Two adjustable thresholds, and a "replaced" button that resets to full.
3. Menu: the preview as the machine will receive it, withdrawn recipes and reasons included.
4. The switches for waters and flavourings, and the price grid.
5. Free mode, payment methods, languages and sustainability factors.
6. Calibration: pulses per litre, line by line, with their date and author.
7. Usage: a date range in local days, indicators for pours, litres, revenue and bottles avoided, a histogram by day and tables by water, flavouring and size.
8. Sustainability: bottles avoided and carbon equivalent over a rolling twelve months and since commissioning.
9. Maintenance: the last service, the next one due with its overdue state, adding an intervention and the append-only record.

The consumer site

Its title is an account setting — "My canteen", "My fridge", "The bar": white labelling goes as far as the name. It is a multi-point-of-sale site, with optional open sign-up, on the customer's domain. Technically it is a context whose user axis is "current user": everyone sees only their own data, and support can "view as" a consumer, read-only and under audit.

• Wallet: the available balance in large type, the detail of the balance and vouchers, and an alert banner if the balance is negative.
• Payment methods: enrolled cards (verified without a charge), top-up at preset amounts, and automatic top-up with its threshold, amount and monthly ceiling.
• My drinks, for recipe machines: litres poured, last pour, bottles avoided, favourite flavourings.
• My badges: their type, label and rights — and attaching an unknown badge through the four-digit code shown on the machine.
• My purchases: each receipt with its status, the ability to rate or report a problem, the receipt resent by email, and opening a dispute.
• My containers in circulation and their returns.
• Order and collect: the time slot, preparation tracking, collection by a third party.
• My organisation: attachment to a company by code.
• My preferences: allergen exclusion applied to the catalogue, language, unsubscriptions.

Without installing an application: scanning the machine's code opens a web page, sign-in happens there, then the opening — with age verification when a product requires it.

Field journeys

They do not live in a dedicated site, but each in its own place:

• The delivery session is on the machine's screen, not in a site: it happens in front of it.
• Typed movements with standard reasons, and batch date entry for perishables.
• Closing with an assortment switch and a session report — offline included.
• Technician interventions are in the machine's technician application: tickets, scheduled interventions, the machine's lifecycle with site transfer, jams.
• Replenishment orders and the round are in the manager portal, next to stock and alerts.

The till site

This is the Octopoda Pay till system, set on the Distrib catalogue and offers:

• Configurable till screens, published as an offer layout: settlement across several baskets and split payments, customer identification in three modes, re-pricing of an unsettled sale, extras and options.
• Till session: opening with a cash float, closing with a count and a logged discrepancy.
• Immutable, numbered closing report, by means, rate and seller.
• Chained, tamper-proof receipts.

Principles across the portal

Each page is either generated from configuration or a dedicated component, with its own permissions. Viewing in place of a user is read-only and audited, and cascading configuration always shows where each value comes from. Operating the platform itself does not happen inside the accounts' sites, but in the Console.