Three Operations, One Widespread Misunderstanding
To outsiders it is all a truck trip with a container. To the operation it is three fundamentally different processes: a delivery sends an empty container out. A swap brings a full one back and leaves an empty one, two container movements in one stop. A collection ends the rental and brings the container home. Generic software often knows a single order with a free-text field. That is exactly where the problems begin that later surface as dispatch errors or invoice disputes.
What Is Genuinely Different Operationally
Each order type has its own logic for the vehicle, the container account, and the documents. A swap needs the right empty container on the truck, or the trip was wasted. A collection reduces the container stock at the customer; a delivery builds it up. Weighing slips attach to different movements depending on the type, and invoicing follows different line items: rental, transport, disposal. If the order does not capture the difference, the paperwork cannot recover it later.
What Happens When Software Ignores It
Every operator knows the symptoms: container accounts that do not add up because a swap was booked as one movement. Empty runs because dispatch could not see that no matching container was on the vehicle. Invoices where the customer disputes the transport line because the process is not cleanly documented. None of this is human error. It is a data-model error, reproduced fresh every day.
Order-Type-Differentiated Creation in Practice
In ContainerGrid the order type is not a note; it is the model: delivery, swap, and collection each generate the correct container movements, require the right documents, and produce the right invoice lines. Dispatch sees at planning time which container type must be on the truck. Batch actions handle many similar orders in one step. And because every movement is documented, the container account at month-end is simply correct, no stocktaking weekend required. (As of: July 2026)