Allocation and fulfillment

Fulfillment Operator works from the selected customer order and its product lines. Allocation reads draft and open lines, creates an allocated fulfillment event for each eligible line and marks the line allocated. The workflow checks existing events so repeating the request does not allocate the same line again. An operation receipt records the activity against the order.

The release workflow starts from an approved customer order. It walks the order lines, creates a shipped fulfillment event for each line and marks each line fulfilled. The event keeps its type, status, date, facility location and quantity. Those values let support staff answer a customer question from the recorded order activity rather than from a disconnected shipment note.

• Allocation. Each eligible line gets its own allocated event and changes to an allocated line state.
• Release. An approved order is the input for shipped events and fulfilled lines.
• Event record. The facility, quantity, occurrence date and event status show what was recorded for the order.

Choose which fulfillment team owns each organization and how facility names are entered. Agree who verifies the product and batch code before allocation, and what to do when an order exception reports a stock shortage or expired batch. The order’s promised date helps prioritize work, but the operator still needs the correct line and product before recording an event.

Decide how shipping facts arrive from a carrier or warehouse. A connected system may provide a provider reference or event update; the team should decide which event status means the shipment was confirmed. Keep the local release action and the carrier’s external delivery confirmation distinct during the rehearsal.

Prepare an approved order with two lines. Allocate one draft line and one open line. Check the events, quantities and line states, then repeat allocation and confirm it does not create a duplicate allocated event. Release the order and check that each line has a shipped event and a fulfilled state. If the team later records a delivered or returned event, it should remain distinguishable by event type.

Create a failed fulfillment event on another order. Support Specialist should find it with the order’s exception and owner, while the operator can identify the facility and quantity involved. The event history is the basis for reconciliation.

• Approved orders — Orders ready for fulfillment work, with promised date and units.
• Shipped and Delivered Events — Shipment and delivery activity linked to its customer order.
• Fulfillment event failures — Events requiring operator investigation.

See allocation and shipment and see payment and reconciliation.