Fulfilment
Order approval, manual fulfilment and service-order lifecycle for MSPs who sell hardware and services to their clients from one system.
How Solidlio helps
Solidlio makes the order itself the record. A client places an order in the MSP’s own store; it arrives as PENDING_APPROVAL and the MSP approves or rejects it in one click. From there the MSP walks it forward — Processing, Shipped, Delivered — attaching a carrier and tracking number as they go, and every step is visible to the client on their own order page in real time. Reaching Delivered is what makes a net-terms order invoiceable, so the nightly invoicing run bills exactly the orders that actually arrived, once each. Service sales run the same way through a single ServiceOrder record covering direct sales, marketplace resales, support blocks, projects, managed services and escalations, with revenue and platform fees calculated as the order moves.
Capabilities
| Capability | What it does |
|---|---|
| Order approval queue | Client orders arrive awaiting approval; approve or reject with a reason that is written to the order |
| Forward-only fulfilment | Advance an order through Processing → Shipped → Delivered; no step can be undone or skipped backwards |
| Carrier and tracking capture | Attach a carrier and tracking number at the shipping step; both surface on the client’s order page |
| Client-visible order timeline | Placed, Approved, Processing, Shipped, Delivered — with dates — in the client’s own portal |
| Mobile order tracking | Customer and Organization users can review their web order status, items, carrier, tracking number and delivery milestones |
| Automatic milestone stamping | Ship date and delivery date are recorded the first time an order crosses each line, never overwritten |
| Delivered-triggers-invoice | The nightly run invoices every delivered net-terms order; a unique invoice link makes double-billing impossible |
| Tax-hold safety | An order whose Canadian tax jurisdiction cannot be resolved is held, never invoiced at zero tax |
| Service order lifecycle | Draft → Approved → Completed for direct sales, marketplace resales, support blocks, projects, managed services and escalations |
| Server-side pricing | Subtotal, discount, tax, total and platform fee are computed on the server and floored at zero |
| Revenue analytics | Revenue by month, by order type, by service and by client, plus a full platform-fee ledger |
| Buyer isolation | A client sees only their own organization’s orders; a sibling client’s order returns “not found” |
| Fulfiller attribution | Every fulfilment step records the user who performed it |
Built for MSPs and their clients
Fulfilment is two-sided by design. The client places and watches; the MSP decides and moves.
| Client organization | MSP | |
|---|---|---|
| Placing an order | Places orders from the MSP’s store | Sets the catalogue and the client’s prices |
| Approval | Waits — sees “Pending approval” on their order | Approves or rejects with a recorded reason |
| Fulfilment | Watches the timeline advance | Advances Processing → Shipped → Delivered and attaches tracking |
| Visibility | Own organization’s orders only | Every order in the account; can filter to any client org |
| Billing | Receives the invoice once the order is delivered | Delivery is the trigger; the invoicing run does the rest |
How it works
- The order arrives. A client places an order in the MSP’s store. It lands as Pending Approval with its currency and exchange rates snapshotted, so it re-prices identically forever.
- The MSP decides. Approve, or reject with a reason. Rejection cancels the order and records why.
- The MSP fulfills. Start processing, mark shipped — entering the carrier and tracking number — then mark delivered. Each transition is validated server-side against a forward-only graph.
- The client watches. The order page in the client’s portal shows a five-step timeline with the dates the MSP’s actions produced, plus the carrier and tracking number. The same organization-scoped, read-only lifecycle is available in Solidlio Mobile under Orders & Delivery.
- The order’s invoice link is unique, so it cannot be billed twice.
- Services follow the same shape. A service order is drafted, submitted — which approves it and records the platform fee in the same transaction — and marked complete when the work is delivered.
Compliance and audit
- Approval records who approved the order and when; every fulfilment step records the user who advanced it.
- Rejection reasons are written into the order record, not into a chat thread.
- Ship and delivery dates are stamped once, on first crossing, and are never rewritten by a later call.
- The order-to-invoice link is a unique database constraint, so the claim “this order was invoiced exactly once” is enforced by the schema rather than by convention.
- Dry runs of the invoicing job are verified end to end: if the downstream service does not echo back that it ran read-only, the run is reported as a failure rather than as a clean rehearsal.
- Buyer isolation fails closed — a caller with no organization context is refused, and a sibling client’s order is indistinguishable from one that does not exist.
Plans and access
Availability depends on your plan, role and account permissions. Capacity limits and service terms apply. Compare current plans and integration requirements, or ask us about your setup.
An order that shipped is an order that gets billed, once.