Orders, fulfillment, and acceptance
This page covers the Operations chain: sales order, fulfillment plan, handoff, and acceptance. Actions depend on permissions, client, legal entity, and the state of the work process.
1. Create and confirm an order
Open /operations/orders/new or enter from a client card. Add one or more order lines, from 1 to 40. Each line has its own catalog offering, quantity, unit, and frozen pricing terms; the last line cannot be removed. Mixed currencies are not allowed and block submission. If the directory or terms are unavailable, do not substitute zeroes or create an order blindly; a terms error belongs to the affected line and offers a retry for that line only.
After you choose the client and the first offering/price, the portal suggests a title such as “offering — client”. Until you edit it, the suggestion updates when the selection changes; after a manual edit, the portal preserves your text. An order may remain untitled and uses a neutral fallback in the list, so do not invent data just to fill the form.
The lifecycle is draft → submitted → confirmed → provisioned. Save the draft, submit it with a basis or reference, then confirm using the current version. Confirmation turns the order into a commitment; provisioning creates the fulfillment plan. If an action is not accepted, check permissions and required fields, refresh the order, and only then retry.
For a managed-service line (managed_service), the separate Connect service action is the step that creates or reuses the service entitlement. Confirming the order or starting the plan does not create that entitlement by itself. If the action is unavailable or no right appears under Services and SLA, check the line state and access, reread the card, and retry only with the current data.
In /operations/orders, client and filterable statuses are draft, submitted, confirmation_pending, confirmed, on_hold, and completed. Rows may carry provisioned, fulfilled, cancelled, or closed; these states remain visible when you open an order. The list supports table/cards, totals, pagination, retry, and empty states.
When a row is available to you, open its order passport at /operations/orders/:orderId to review lines, parties, status, and the next available step. The URL is addressable and suitable for sharing with colleagues, but access still follows permissions.
For a confirmed order, the passport also shows each fulfillment line's progress: planned, in_progress, handed_over, accepted, or cancelled. When the handed-over quantity reaches the required quantity, the line is shown as Fully handed over even if the parent plan status has not caught up. Use /operations/fulfillment for the action and reread the current line; do not infer handoff from the parent order status alone.
The registry starts across all clients the actor may read, loads up to 25 rows, and continues with Show more. Status filters, the client filter, and the table/cards switch are local to the screen; an empty result, a filtered-empty result, and a load error are different states.
When related reads succeed, the order passport shows What came out of this order with links to the derived commitment and acceptance cards. The block may be absent because the result is empty or the read failed; its absence does not prove that no derived record exists.
2. Prepare fulfillment
In /operations/fulfillment, review the plan and its lines. Plans in planning or blocked can become ready; ready or partially_completed plans can start. Each transition needs a non-empty confirmation or reference and the current version.
Starting the plan and handing off an individual line are different steps. Starting moves the plan into work; it does not hand off any line. Handoff is available only while the plan is in_progress and the selected line still has unhanded quantity, so check the line status and remaining amount before acting.
Do not treat a plan as ready only because the order is confirmed; verify its lines, quantity, unit, owner, and legal entity.
The delivery register is portal-wide by default; the client filter is local to this screen and is not persisted. The “promised but not yet delivered” plan block loads only after selecting a client; clear the filter to return to all deliveries. An empty plan block with no client selected is not proof that data is absent.
Each delivery shown on a client card now links here with that client already in the URL filter, and its row opens a separate delivery detail card at /operations/fulfillment/deliveries/:deliveryId. That card is for delivery details and status; row actions—Open acceptance, Return, Correct, Report a problem, and Cancel—still start in this register. A row uses the delivery's human display name when available and falls back to the delivery method only for older records.
The detail route may show a loading state first; wait for it to finish rather than treating it as missing data. A temporary error offers Retry; retry rereads the card and does not perform an action. If access is denied, request access or return to the register—this does not mean the delivery is absent. A card with no lines can be a valid empty state: it has no actions to start and is not itself an error.
Deliveries use the shared registry with table/cards and a row action menu. Unavailable actions remain visible with a reason; after an operation, reread the registry because a success message is not a substitute for checking the resulting status.
Check lines, quantity, unit, owner, and legal entity. A missing work-order package may mean that it is not materialized yet or is already linked in the work-order section; these are different states, and neither by itself proves that a task was assigned to a performer.
An empty “Work order” cell can also be normal: when executionContainerPolicy=work_order is not used, work is tracked on the line, but this does not prove that a task was created, assigned, or completed. If the policy requires one, “Not created yet” means only that the package has not been materialized; it is not the same as an access error. In the current portal, a work-order lifecycle and its package do not provide a path to create or dispatch a task component and do not prove that a performer received or completed work. Before handoff or completion review, verify the actual outcome in the agreed task and assignee context; if it is unavailable, pause and ask the portal owner rather than bypassing this through a direct API call.
3. Hand off a line
Handoff is available only while the plan is in_progress and only for quantity that is not already handed over or accepted. Provide evidence and a method: a physical good uses shipment; other types use the service method.
A handoff can create a delivery with a partial result. Refresh the plan and history before retrying, so a second action does not create a duplicate. Cancelling a delivery requires a non-empty reason; an already-handed-over line and stale information are handled separately.
The row menu offers Correct and Return once something has been handed over; both require a non-empty explanation and apply only to a single-line delivery. Return also requires the current delivery revision and is unavailable after an acceptance decision; correction is recorded alongside the original. When there are no lines or more than one line, the menu explains the restriction. Registry statuses may include ready_for_handoff, received, accepted, returned, and exception (Problem); do not treat these labels as claims about stock movement.
If a delivery record appears after a handoff but confirmation is not shown, reread the registry instead of creating another delivery. Cancellation requires a reason and a refreshed card; an already handed-over line cannot be cancelled.
A delivery created by mistake can be withdrawn only in planned, ready_for_handoff, or exception, while no handover line has been recorded. After handover, the action is not offered. Withdrawal requires a reason and the current card version; success changes the delivery to cancelled. The registry date is the delivery creation time, not the handover date; use the status to determine whether handover happened.
If the current version shows Report a problem, this records an incident rather than acting on the goods. It can be available for planned, ready_for_handoff, partially_handed_over, and handed_over; describe what happened. The delivery is marked as a problem, but no return, acceptance, or stock movement starts. If the state or card version changed, reload the registry and check again.
On an acceptance card, the source order title is now a link to /operations/orders/:orderId when the order can be opened. If the title is unavailable or still loading, the portal uses a neutral label and does not expose a technical ID.
4. Review acceptance
/operations/acceptance and its acceptance card show the source order, accepted and rejected quantities, status, rework warning, dates, linked documents, and history. Use /operations/acceptance/:acceptanceCaseId to open a specific acceptance card directly.
In the shared list, each acceptance row is titled with its source sales order; if that title has not loaded, the neutral fallback is Acceptance. Statuses are shown as draft, collecting_evidence (Collecting proof), ready_for_submission (Ready to send), submitted (Sent to client), pending (Awaiting decision), under_review (Under review), partially_accepted (Partially accepted), accepted, rejected, and cancelled (Withdrawn). In ready_for_submission, the portal shows Send to client; sending starts a separate approval flow and may wait for a second staff member under separation-of-duties rules.
Open acceptance belongs to a specific delivery line whose status is handed_over, not merely to the delivery status: it may still be offered when the parent delivery is exception if that handed-over line needs acceptance. It is not offered for a returned or cancelled delivery.
On the acceptance card, first choose Attach evidence: from draft this moves the case to collecting_evidence. Staff can Cancel only from draft, with a non-empty reason and the current case revision. Ready for submission appears only from collecting_evidence and requires a non-empty immutable evidence watermark. In ready_for_submission, Send to client creates or reuses an approval request and may require a second staff member; the technical decision reference is not shown in user-facing text. The client's decide action is a separate path for the other party, not a staff action. Accept, rework, and reject controls require the corresponding capability and separation of duties. If the button is unavailable because of access or separation-of-duties rules, record the next step in a task or document.
When the client confirmed the result outside the portal, record manual evidence only from a real external confirmation: identify the confirming party, basis, time, and accepted or rejected quantity. The witness is recorded first and then applied to the case in a separate confirmation. With separation of duties, the person who created the case, delivery, or line cannot record it, and the person who recorded it cannot apply it; these are two different next steps. The portal cannot hand a recorded witness to a colleague, and after leaving the page it cannot be reopened by its technical code. Do not copy that code, bypass the rule with a direct request, or record first and coordinate the second person later.
After an accepted or partially_accepted decision, the acceptance card offers one action to ensure the charge and a link to Charges (route /operations/billing?view=charges). No charge amount is entered manually: the server derives it from the accepted quantity, frozen terms and policy, unit price, and allowed precision. Repeating the action is idempotent: the card distinguishes “charge created” from “charge already existed” and never duplicates it. The action requires the relevant capability and separation of duties; handle a disabled billing trigger, invalid price/terms/precision, invalid acceptance state or source, not-found, and revision-conflict errors separately (on conflict, reread the card). Show the amount in the selected locale/legal-entity currency; use synthetic examples only, with no real invoices, bank, or client data.
Evidence, money, and privacy
Use synthetic clients, offerings, legal entities, and amounts. For materials with sums, verify that the currency matches the selected language and legal entity; never move a currency between locales. A confirmation must identify what happened, who owns it, and which order version it belongs to. Never show real contracts, invoices, bank details, tokens, or client data. After an error, inspect the order history and state before retrying with the current version.
Related pages