Shipping Labels in a Business App: Reprint the Document or Create Another Shipment?

A “Print shipping label” button can hide two very different actions: asking a carrier to create a shipment, or retrieving a document for a shipment that already exists. Specify them separately. A paper jam should not leave staff guessing whether another click will create another carrier record.

Identify what happens before the printer starts

Ask the implementer to show the carrier interaction, not only the printed page. Does the app merely calculate a rate, create a shipment or retrieve an existing label? Which step may incur a charge under your carrier agreement? Verify that commercial question with the carrier rather than inferring it from a button name.

The Odoo 19 label documentation illustrates the distinction: generating carrier labels requires a carrier connector and a delivery-method integration level called “Get Rate and Create Shipment.” It also describes label printing triggered by validation of a configured picking or packing operation in multi-step delivery.

That is a product-specific workflow, not a universal recommendation about when to dispatch goods. Agree the trigger for your process and explain it to staff. A label available before collection is not evidence that a carrier has taken the parcel.

Bind each label to its package

Odoo documents a PDF label attached to the record's conversation history and an individual label for each package in multi-package shipping. For your app, make the package-to-document relationship visible. Staff need to know which parcel receives which label, rather than selecting an unexplained attachment from a list.

Decide where the accepted address, carrier service and package details are recorded. If those details change after label creation, require a reviewed replacement process. Editing a customer profile must not silently make an old label appear current. Whether a carrier record can be cancelled and whether charges are reversed are separate provider questions.

Recover from printer failure without guessing

Specify a retrieval or reprint action that uses the existing accepted label and shipment reference. Keep it distinguishable from an action that requests a new shipment. If printing fails, show that failure separately from the carrier's creation outcome.

The harder case is a carrier request whose response never reaches the app. Ask for an explicit unresolved state, a durable record of the attempted operation and a reconciliation path using the provider's supported facilities. Do not instruct staff to keep trying creation until a page prints. A local success flag cannot guarantee exactly-once behaviour at an external carrier.

These are implementation requirements to demonstrate; the cited Odoo guide does not prove your connector's retry or reconciliation behaviour.

Accept the failure cases as well as the happy path

Use the provider's supported test facilities without creating live shipments or charges. Demonstrate a normal label, a multi-package case, a printer failure followed by retrieval of the same document, and an uncertain provider response. Show how an authorised replacement remains distinguishable from a reprint.

Check document size and readability on the actual agreed printer setup. Access to a label also reveals delivery details, so include staff permissions and document retention in scope rather than making label files public.

Add these cases to your acceptance criteria when planning the carrier integration. Acceptance should establish which carrier record exists and which document was printed, not just that paper came out.