e-bon
e-bon.ro
Portal

Operators

Add and manage operators (cashiers, waiters, shop managers) on a fiscal device from the Portal — Set Operator flow on the Device Detail Operations tab, with capabilities queried live from the AMEF.

Operators

Operators are the people who issue receipts on a fiscal device — typically cashiers, waiters and shop managers. The AMEF stores who is "logged in" as the active operator and stamps every emitted receipt with that operator's slot, so daily takings, X / Z reports and receipt history all attribute correctly.

The Portal exposes a single, focused flow to manage this: Device Detail → Operations tab → Set Operator. There is no standalone "Operators" page — operators live on the device itself, not in the Portal database, so everything you do here is a live round-trip to the AMEF.

Operator records live on the device, not on a location or in your e-bon organisation. Each AMEF tracks its own operator slots independently. If the same person works on two devices, set them up on each device individually with the same name and ID.

Find the Set Operator flow

  1. Open the Portal at https://app.e-bon.ro and sign in.
  2. Go to Devices and open the device you want to configure.
  3. Switch to the Operations tab on the Device Detail page.
  4. Click Set Operator (icon: i-lucide-user).

The button is disabled when the device is offline — the Portal needs a live connection to the AMEF to query its capabilities and write the operator slot.

Add or update an operator

Open the device

From Devices, click the row for the AMEF you want to configure. The Device Detail page opens.

Switch to the Operations tab

The Operations tab groups the live device-control actions (clock sync, VAT rates, header / footer, Set Operator). All of these require the device to be online.

Click Set Operator

The "Set Operator Name & Password" modal opens. While it loads, you'll see "Loading operator capabilities..." — the Portal is calling GET /api/v1/devices/:deviceId/operator-capabilities, which dispatches the GetOperatorCapabilities command to the AMEF and waits for it to answer with { supportsPassword, maxNameLength, maxPasswordLength, ... }.

Fill in the form

Three fields, in order:

  • Operator ID — integer, minimum 1. This is the slot on the AMEF the operator will occupy. Each AMEF has a fixed number of slots; setting an existing ID overwrites that slot.
  • Operator Name — free text, capped at maxNameLength from the device's capabilities (default: 32 characters if the device doesn't report a value).
  • Password (optional) — only shown when the device reports supportsPassword: true. Capped at maxPasswordLength (default: 8 characters).

Save

Click Save. The Portal calls POST /api/v1/devices/:deviceId/operator with { operatorId, name, password? } and dispatches SetOperator to the AMEF. On success a toast shows "Operator settings saved successfully" and the modal closes.

The field limits and the visibility of the Password field come from the AMEF, not from e-bon. Different AMEF models report different maxNameLength, maxPasswordLength and supportsPassword values — that is why the modal opens with a "Loading operator capabilities..." state and queries the device every time.

Track who issued which receipt

Every receipt the AMEF emits is stamped with the active operator's ID, and that ID is preserved in the receipt's archive in the Portal alongside the rest of the fiscal data.

You can see it in the Portal on the Receipts page: open any receipt to view its detail panel — the Operator field shows the operator ID that issued it. The receipt list itself does not currently filter by operator; you can scan the operator value on each row's detail view, or pull it programmatically over the API.

Past receipts retain the operator that was active at the time of emission. Overwriting an operator slot later does not retroactively change the operator on already-issued receipts — the historical attribution stays in the fiscal archive forever.

Replace or remove an operator

The Set Operator flow is the only write path. To rotate operators, you have two options:

  • Reuse the same slot. Open Set Operator, enter the same operatorId, and overwrite the name (and password, if supported). The new operator takes over that slot immediately. Past receipts emitted under the previous name are unaffected.
  • Move to a fresh slot. Open Set Operator, enter a new operatorId that is not currently in use. The new operator gets their own slot; the old slot stays as it was on the device until you overwrite it.

There is no Portal-side "delete operator" action — operator slots are device-managed. Treat the AMEF's slot table as the source of truth.

Manage devices across multiple locations

setOperator is per device. There is no "assign this operator to a location and have it propagate to every device in that location" feature — if the same person works on three devices, you do Set Operator three times, once per device.

Devices are grouped under locations in your organisation (see Locations & Devices). That grouping organises devices in the Portal UI, but operator slots remain a device-local concept.

Manage operators programmatically

The same two endpoints are exposed via the public API and the SDK, so you can script onboarding (e.g. provision the same set of operators across every device in a chain) instead of clicking through the Portal device-by-device.

  • REST: GET /api/v1/devices/:deviceId/operator-capabilities (scope: DevicesRead) and POST /api/v1/devices/:deviceId/operator (scope: DevicesWrite, body { operatorId, name, password? }). Full reference in API → Devices.
  • SDK: client.devices.getOperatorCapabilities(id) returns { capabilities, deviceId, timestamp }; client.devices.setOperator(id, body) writes the slot. Full reference in SDK → Devices.
  • Both endpoints round-trip to the AMEF, so the device must be online when you call them.

Sign-up & Sign-in

Create your e-bon account, sign in to the Portal, and reset a forgotten password at app.e-bon.ro.

Alerts

Real-time device alerts in the e-bon Portal — the five alert types, how each one is derived, where they surface in the UI and how to read them programmatically through the API.