Operations registries, supply, and billing
This page complements the Operations overview and covers routes that are not commitment or fulfillment detail cards.
If a row shows a technical ID instead of a meaningful name or item code, do not treat it as business data. Refresh the card or report it to the owner, and do not use the frame in public documentation.
Summary and commitments
The Operations summary groups commitments needing attention, approaching due dates, service rights, and invoices requiring review. It is a triage view, not an accounting balance. A number without a row, period, or status is not a confirmed total; check permissions and data readiness before retrying a failed load.
If any summary source is not ready, the cards may not load completely. Retry the summary in a minute and do not treat missing values or zeros as the final total; for an ordinary load failure, retry the complete snapshot rather than an individual metric.
Services and entitlements
The services registry at /operations/services shows the entitlements available to the actor across the portal by default. The client picker is a local, non-persistent narrowing; the first load returns up to 25 rows and Show more continues the same filter. Open a specific entitlement at /operations/services/:entitlementId to review its type, status, and periods with granted, consumed, reserved, and available quantities. An empty filtered result is not the same as an empty global registry and does not mean zero rights. Do not promise grant or consumption actions unless the required action is visible.
When the relationships resolve, an entitlement card also links to the client and its source commitment. If enrichment cannot be read, the card remains usable with a neutral label; that does not prove the relationship is absent. Usage history and its state transitions still require their own permission and current-version checks.
The card also shows periods with granted, used, reserved, and available quantities, plus a usage table with pending_approval, captured, allocated, approved, posted, rejected, and reversed states. Log usage, Approve, and Post are separate actions with separate permissions; the author cannot approve their own entry. Recheck the available balance before entering usage, but do not promise an immediate overage rejection: a record may be created and the excess may only be detected when another reviewer approves or posts it. Reread the card after each transition and keep technical codes out of public frames.
Time quantities may be restated exactly in the purchased unit: for example, 480 and 390 minutes are displayed using one or more units configured for that entitlement. This is display formatting only—enter the amount in the unit printed beside the form field. Do not invent rounding for fractional or negative values.
When the current period and available balance are permitted, the Log usage form appears directly on the entitlement card beside the history. Enter a positive whole-number amount in the unit printed beside the field (for example, minutes) and optionally add a reason such as a request, task, or note. Saving creates a usage record; it does not replace the separate Approve and Post actions. If the form or unit is not visible, do not guess or retry the request.
Supply, warehouses, and procurement
/operations/supply has procurement and warehouse tabs. A warehouse row opens /operations/supply/warehouses/:warehouseId, showing type, state, time zone, locations, and stock. The warehouse moves from draft to active and then to suspended; these transitions require permission, and suspension pauses receiving, reservations, and stock moves.
In the current UI, warehouse lifecycle is limited to draft, active, and suspended states, with resume returning it to active: activate, suspend, and resume buttons are administrator-only and require a non-empty reason with the current revision. Locations can be added only while the warehouse is active. Do not promise decommission or close actions until their buttons are visible on this screen.
Creating a warehouse opens a modal: code and name are required, while type and time zone must be chosen explicitly. If administrator rights are missing, the code is already in use, or a field was rejected, correct the data or request access; do not retry blindly. Use a synthetic warehouse for testing, not real addresses.
Warehouses and invoices load in pages of up to 25 rows. Show more loads the next page without recalculating the rows already shown. The procurement tab requests up to 50 requisitions and supplier orders without a Show more control. The client filter narrows the list to the selected client; without it, the registry shows all records available to you.
The procurement tab lists requisitions and supplier orders. A requisition can be created automatically from a confirmed order under a buying fulfillment profile, or raised manually. /operations/procurement/requisitions/:requisitionId is the addressable detail; during supplier search it shows an immutable demand line with its exact quantity and a supplier picker. Approving, rejecting, starting supplier search, and cancelling require a reason and current revision. After a supplier is assigned, the requisition is ready for an order, but the supplier order is intentionally not built: if the relation or next step is not ready, it will not appear automatically. Check the requisition state and ask an administrator; an empty list may be the honest result of current data, not a UI failure.
During supplier search, choose or change the supplier for the specific demand line. Assignment is unavailable when the line or quantity is missing, supplier search is unavailable, no companies match, or the company cannot act as a supplier; refresh and check state before retrying instead of repeating blindly.
When the current portal exposes New requisition, the manual entry is /operations/procurement/requisitions/new. Choose a goods item and quantity; unit, item version, and precision come from the catalog, the buyer comes from an available legal entity, and need-by date and note are optional. Supplier, price, and warehouse are decided later. If you lack permission, the requisition already exists, or a field was rejected, check its state and correct the data before retrying.
Billing and invoices
/operations/billing is the invoice registry with an optional client filter; /operations/billing/invoices/:invoiceId is the invoice passport. Check number, status, issue/due dates, total, and outstanding. An invoice appears after the client makes an acceptance decision: while acceptance is only ready and has not yet been sent to the client, the invoice list may remain empty. In that state use Open acceptance, not Catalog; an empty list is not zero debt.
The same route also has a Charges tab for service amounts that have not yet been invoiced. It is not an invoice list: a row describes a charge and its service period, not proof that an invoice already exists. A pending charge can have an unknown amount rather than a zero amount; if its period, human-readable name, or amount is absent, do not invent it or infer debt. Create invoice changes data, so a read-only check may only open the tab and compare clear names, period, status, and currency—without selecting rows, creating, or submitting an invoice.
The invoice passport is read-only: issuing, approving, and other changes belong to an authorized role with the required capability. Statuses can be draft, awaiting approval, approved, issued, sent, partially paid, paid, overdue, void, or cancelled. Compare total, paid, credited, and outstanding, then inspect line descriptions, quantities, amounts, and linked documents. Retry a load error after checking state; distinguish an empty invoice or line list from an unavailable object.
At /operations/billing/invoices/:invoiceId, the passport loads the invoice and lines in parallel: loading, a retryable error, a missing or unavailable invoice, and empty lines are distinct states. A successful synthetic frame should show the number, status, dates, total/paid/credited/outstanding in the selected locale currency, lines, and linked documents. This is read-only: do not issue, pay, or mutate the invoice, and never use real payment details or customer data.
For every amount verify the displayed currency, calculation source, and rounding. Do not reuse financial examples across locales without checking the local currency.
Settings and work orders
/operations/settings controls which legal entities may appear as our side on orders, invoices, and delivery documents. Until at least one is allowed, creation may be blocked rather than guessing the issuer. Saving may be blocked by permissions, an outdated version, or temporary unavailability; check access, refresh, and try again later.
/operations/work-orders/:workOrderId is an addressable work-package card usually opened from fulfillment. There is no work-order index route; a missing link can mean the package is not created or is not available to the actor.
A work-order card can show Plan → Ready for work → In progress and a task package. In the current UI, however, that package has no command to create or dispatch a task component: a work-order status alone does not prove that a performer received or completed a task. If the process requires a task from the work order, stop handoff or delivery and agree the next step with the Operations owner; do not bypass this through a direct API call or technical identifier.
Errors and safe review
Distinguish an empty list, a filtered-empty list, no access, an unavailable object, a conflict, rejected fields, and a temporary outage. After a partial result, reread the registry and history before retrying with the current revision. For planned read-only service examples, keep one fixture chain: client Demo Client North, entitlement Support package — test, and source offering Support hours — test. Keep those entity types distinct; never show bank details, real invoices, contracts, or customer data. Before starting or sharing work, verify the displayed section, status, and action labels and currency in the selected portal language.
Related pages