Device fulfilment

A fulfilment operator prepares physical devices on behalf of an ordering client and ships them to that client’s customers. Each device must be ordered, matched to a physical unit, personalised with the customer’s data, labelled, packed with the right paperwork, shipped, tracked, sometimes returned, and invoiced. This is simple to describe and hard to run:

• Several device types, several manufacturers, several sets of rules: different file formats, different labels, different processing steps.
• Delivery addresses in several countries, with different postal formats and countries that cannot be shipped to; a wrong address is a wasted device and a parcel that comes back much later.
• Several organisations in one process: the client orders, the manufacturers deliver stock, the operator prepares, carriers ship, and the client’s customer service answers the phone. Everyone needs the same status.
• Deadlines with agreed service levels per country, for personalisation and for delivery.
• Money follows the work: preparation, cartons, shipping by weight and zone, surcharges and customs fees have to be invoiced correctly for every parcel.

It fits an operator that moves serialised physical items through several organisations, deadlines and paperwork on behalf of one or more ordering clients: devices arrive from manufacturers, are personalised per end customer at workstations, and leave as tracked parcels. It fits best where several device types share one floor, where the ordering client has its own departments and its own customer service, and where the client is willing to correct its own data in a portal instead of by e-mail.

It does not fit a company looking for warehouse staff or a carrier service: what is delivered here is the operating software. It does not fit an operation without serialised items or without a per-item processing step — plain parcel shipping is a carrier’s business, not this platform’s. It is not an off-the-shelf product: it is the reference shape of one delivered platform, adapted per implementation.

Orders and addresses

Stock and personalisation

Documents and shipping

Client side

Invoicing, service levels and operations

Dependencies: re-sending an undeliverable parcel needs carrier label generation; the delivery service level needs the carrier’s tracking data; the client editing its own templates needs the client portal; an invoicing run needs products, zones, carriers and price grids configured first.

What is included in a given delivery, and how it is delivered: configuration vs. custom · delivery approach.

• Warehouse staffing or carrier services. What is delivered is operating software, not a physical fulfilment or transport service.
• The devices, the personalisation equipment and the manufacturer contracts. The platform tracks and drives them; it does not supply them.
• Carrier contracts and tariffs. These stay between the operator and the carrier.
• The accounting system. The invoicing run computes the service and produces reports; fiscal issuance and bookkeeping happen outside.
• The ERP that consumes the stock files. The platform produces the files; what is done with them downstream is the client’s.
• The ticketing engine. A third-party component, integrated rather than built.
• Production operation and the data-processing agreement. Who operates the platform, and who signs as data processor, is set in the delivery agreement; where we operate it, that is contracted through Managed Hosting.
• Strict validation of every scanned barcode format. Scans are checked by the workflow — the right parcel, the right device, every label — not by a format rule per barcode type. Stricter input validation is scoped where a device type needs it.
• A postal reference dataset, and a subscription to one. Address validation runs against the platform’s own loaded reference data, not against an external validation provider. The data has to be brought and kept current for every country in the footprint; sourcing and licensing it is not part of the platform.

Technology-neutral shape of the solution:

The two sides have separate user models and screens. They are connected through an event bus and a read-only data connection. Workstation isolation — a tablet user only sees the parcels of the workstation they selected — is enforced by the API, not by the screen.

Implementation stack of the delivered platform: PHP services on Laravel with a GraphQL API, RabbitMQ, MySQL and Redis; Vue and React browser applications; containerised and deployed through a CI pipeline.

What the platform connects to, in which direction, and what moves:

Anything outside this set — another carrier, another manufacturer format, an ERP connection in either direction, a customs or payment system — is scoped after discovery and contracted separately.

• Two isolated sides. The operator side and the client side have separate authentication and separate databases; the client side works on a read-only copy of the data and sends corrections and requests back as events.
• Authentication per surface. Password-based login with tokens for the dashboards, personal tokens and a scanned label code for the tablets, one-time codes for client password resets, token-based access with rate limits for the external API, temporary links for downloads. Services authenticate each other with a signed, daily-rotating key.
• Roles and isolation on the server. Role-based permissions on both sides; a tablet user is limited by the API to the workstation they selected; the client’s administrators manage their own users, roles and languages, with a context per department.
• Audit trail. Every state change on every order, parcel, device, document, delivery, pallet, stock item, workstation task and invoicing run is recorded with the actor and a snapshot; a rollback is recorded like any other transition.
• Personal data. End customers’ names and addresses pass through the platform. A scheduled job cleans sensitive data from completed parcels. The public tracking page is reachable without a login by anyone holding a parcel’s reference; what it shows beyond the carrier status is a personal-data decision taken at implementation. The retention rule, deletion governance and the data-processing agreement between operator and ordering client are set in the delivery agreement.

The common baseline is documented once: security baseline. No certification is claimed for this solution. Who owns and operates the platform in production is set in the delivery agreement.