Austrian merchants and 3PLs that ship through Österreichische Post usually run a broken loop: pick and pack in Odoo, then re-key every consignment into the Post business portal to buy a label, copy the tracking number back onto the delivery order by hand, and reconcile it all later. Odoo's native delivery and stock_delivery framework ships a generic delivery.carrier model and a couple of built-in carrier integrations, but there is no Österreichische Post provider in Community or Enterprise. So warehouse staff either pay flat manual rates with no rate shopping, or maintain a fragile spreadsheet bridge — and neither approach validates weight or format before a label is bought, which is where Nachnahme errors and rejected Pakete come from.

This connector closes that loop inside Odoo. We build a dedicated delivery.carrier provider (delivery_type = 'austrian_post') that authenticates with your Österreichische Post business-account credentials and talks to the Post labelling and shipping API over its REST/JSON interface, wrapped in Odoo's standard rate/ship/tracking/cancel hooks (rate_shipment, send_shipping, get_tracking_link, cancel_shipment). Rate estimation resolves the correct domestic or EU/international product by weight and format — Brief, Päckchen, or Paket — and returns a priced quote onto the sale order and delivery order. On validation, the connector calls the label API, stores the returned PDF or ZPL label as an ir.attachment on the stock.picking, and writes the carrier_tracking_ref plus a clickable tracking link straight onto the delivery order. Weight and format validation runs server-side in a @api.constrains/compute layer before any label is purchased, so an out-of-spec package is caught in Odoo, not at the counter.

The build covers the real-world Austrian shipping cases that off-the-shelf generic modules skip: Cash-on-delivery (Nachnahme) service with the collected amount carried on the shipment, pickup-station (Abholstation) and Post-Empfangsbox address handling so parcels route to the right receiving point, return-label generation for RMAs, shipment cancellation before pickup, and customs/CN22-CN23 document generation for non-EU destinations. Batch label printing runs from the stock.picking list so a full wave of orders is labelled in one action rather than one delivery order at a time. Everything is packaged as a proper Odoo module — __manifest__.py with declared dependencies on delivery, stock_delivery, sale_stock, and website_sale; models with ORM fields and computes; ir.model.access.csv plus record rules for security; XML/OWL views and settings; and QWeb where a printable artifact is needed — and it is delivered for your Odoo 17.0, 18.0, or 19.0 database (Community or Enterprise), with credentials and product mappings kept in configuration, never hard-coded.

Because this is build-to-order, nothing ships until we agree scope on a short call: your Post product catalogue, which services you actually use (Nachnahme, Abholstation, returns, international), your warehouse and multi-company layout, and any website checkout rate-display requirements. Typical delivery is one working week from confirmed scope, on a staging database first, with UAT and a rollback plan before we touch production. Pricing starts from $999 (indicative, single-company base scope); additional Post services, multi-company or multi-warehouse rate routing, website checkout rate integration, and deeper localization or data migration increase the quoted scope. You get a fixed quote after the scoping call — the from-price is a starting point, not a firm figure.