Hotel Channel Manager Connector

ECOSIRE builds a dedicated Hotel Channel Manager Connector as a proper Odoo module. We add channel and channel-mapping models (models.Model with ir.model.access.csv permissions and multi-property record rules) that bind each Odoo room type and rate plan to its counterpart on every OTA. A sync engine pushes ARI outward whenever a booking, price change, or stop-sell is recorded in Odoo, and pulls new reservations inward — either directly against each OTA's API or through a channel-manager hub (a supported aggregator), depending on your distribution mix. Inbound reservations land as native Odoo bookings with guest, room type, dates, and channel commission attached, so your existing folio, invoicing, and QWeb confirmation reports keep working unchanged.

Technically, the connector is built the Odoo way. Availability is a computed value derived from confirmed reservations with @api.depends on the booking lines, so a new reservation instantly recalculates what is left to sell and fans that number out to every mapped channel. Outbound calls run through Odoo's queued jobs / ir.cron scheduled actions with retry and backoff, so a slow OTA endpoint never blocks a front-desk clerk mid-checkout. Inbound reservations arrive via a controller endpoint (webhook) or a polling cron, are de-duplicated on the channel reservation ID, and are logged to an audit model you can inspect from a dedicated OWL/XML backend view. Stop-sell, minimum-stay, and closed-to-arrival restrictions are modeled as first-class fields and pushed alongside rates. All third-party calls go through Odoo's XML-RPC/JSON-RPC or REST layer with credentials stored in encrypted config parameters, never hard-coded.

Because this is build-to-order, nothing ships until we agree on scope. We start with a short scoping call to confirm which OTAs, which PMS (Odoo Enterprise's own or a third-party hospitality app), how many properties and room types, and whether you connect direct-to-OTA or via a hub. We then build against your exact Odoo version (17.0, 18.0, or 19.0), validate the full push/pull cycle on a staging database with your real room and rate structure, and only deploy to production after you sign off on UAT. Typical delivery is 2–4 weeks from confirmed scope. Community vs Enterprise differences are handled explicitly — if your PMS is an Enterprise app we integrate with it; if you run a community hospitality stack we adapt the mapping layer accordingly.