Merch and apparel brands that fulfil through print-on-demand partners usually end up running two systems that disagree. Orders land in Odoo Sales, then a person re-keys them into a partner portal, uploads the right artwork file for the right size and colour, watches for a production email, and pastes a tracking number back into the delivery order days later. Odoo out of the box has no concept of an external production partner: stock.picking expects goods you own to move out of a warehouse you control, product variants carry no print-file or placement metadata, and the partner's per-unit print charge never reaches the margin on sale.order.line. The result is drop-ship deliveries that sit "Ready" forever, customers emailing for tracking you already have, and a gross margin that is confidently wrong.

The Print-on-Demand Connector puts that whole loop inside Odoo. We add a pod.provider model holding per-partner credentials, endpoints and rate limits, and a pod.product.map model that binds each product.product variant to the partner's blank SKU plus its print placements — front, back, sleeve, hood — with each placement pointing at an artwork record. Artwork lives in pod.artwork as an ir.attachment-backed asset with print dimensions, DPI and colour profile stored as fields, so a compute checks resolution against the placement's required print area and blocks a submission that would ship a blurry garment rather than discovering it after production. Variant mapping is validated before it can be used: an unmapped attribute combination raises at order-confirmation time, not at the partner's API.

On confirmation, a queued job builds the partner payload from the sale order's shipping address, line quantities and mapped variants, and pushes it over the partner's REST API. The order reference, partner order id and per-line print cost come back and are written to a pod.order record chattered onto the sale order, so the whole exchange — request, response, retry, error body — is auditable in the Odoo log without opening a terminal. A scheduled ir.cron polls open POD orders for status transitions (accepted, in production, quality check, shipped, cancelled) and stamps each on the linked record; where the partner supports webhooks we expose a signed controller route instead, so status arrives in seconds rather than on the next cron tick. When a shipment event carries a carrier and tracking number, the connector validates the delivery and writes carrier_tracking_ref on the stock.picking, which means the standard Odoo shipping-confirmation email and portal both show real tracking with no extra work. Partner charges are reconciled back against the line: we store the quoted print cost, the invoiced cost and the delta, and expose them on a QWeb reconciliation report and a pivot view so you can see which designs and which partners are quietly eating your margin. Security is real access control, not a menu you hope nobody clicks — ir.model.access.csv entries for a POD Operator and POD Manager group, plus record rules keeping providers, artwork and POD orders scoped by company in a multi-company database.

Everything is written against the version you actually run. We support Odoo 17.0, 18.0 and 19.0, Community or Enterprise, and the __manifest__.py declares only the dependencies your scope needs — typically sale_management, stock and delivery, adding stock_dropshipping or account where the fulfilment and costing flows require it. No Enterprise-only feature is assumed: if your database is Community, the reconciliation reporting is delivered as QWeb plus list and pivot views rather than Enterprise dashboard widgets. If you run a hosted instance where you cannot install custom code, we can implement the same integration against the external XML-RPC/JSON-RPC API instead, and we will tell you which shape fits before you commit.

This is a build-to-order product, not a marketplace download. It starts with a scoping call where we confirm your partners and their API capabilities, your variant and artwork structure, your Odoo version and edition, and how you want costs to hit accounting. We come back with a fixed written scope, then build against it: source code delivered for your exact version, installed and configured on a staging database, tested on your real catalogue and real orders with your team in UAT, then deployed with a rollback plan. Typical delivery is one working week from confirmed scope, depending on how many partners are in play and how unusual their APIs are. You get the Git repository, so the module is yours to keep, read and extend — with or without us.