This is a build-to-order module, not an instant download. Typical delivery is one working week from a scoped kickoff. We start by mapping your outlets, folio/PMS model, posting accounts, and roles; build and test on a staging environment against Odoo 17, 18, or 19; then install to production with an end-to-end charge-to-settlement smoke test and staff training. Complex multi-property or custom-PMS integrations may extend the timeline, which we confirm in writing before we begin.

Every build includes a defined post-go-live support window with an SLA for bug fixes and adjustments. Because you own the module source, you're never locked in. When you upgrade your Odoo version, we provide a compatibility check and, if needed, a migration pass. Ongoing enhancements and extended support are available under a maintenance agreement that we scope with you.

Both. If you manage folios inside Odoo, we post to a native folio model. If you run a separate PMS, we push charges over XML-RPC / JSON-RPC or your PMS's REST API, with idempotent posting and a retry queue so a network drop never double-charges or loses a check. During scoping we map your booking and folio objects; if your PMS lacks a usable API we'll tell you up front rather than promise an integration we can't deliver.

Odoo 17, 18, and 19, on both Community and Enterprise. The module extends the standard Point of Sale app, so it works with Odoo's core POS on Community and with Enterprise POS features where you run them. We build and test against your exact edition and version, and the __manifest__.py declares the supported series so upgrades stay predictable.

Guest and room lookup at the POS only lists currently checked-in guests, so a cashier can't post to an empty or checked-out room. Security is enforced with ir.model.access.csv and record rules: outlet staff can post charges, but only front-desk and night-audit roles can settle, void, or transfer them, and a settled folio can't be silently reopened. Optional credit-limit guardrails block or warn when a charge would exceed the allowed folio balance, and every action is stamped in an audit log.

Each outlet (restaurant, bar, spa, room service, minibar) maps to its own income account and/or analytic tag during setup. When a POS order is room-charged, the folio line carries that outlet tag, so revenue lands in the correct ledger and analytic reporting — not in a single undifferentiated POS account. This lets your night audit tie out per revenue center and gives your controller accurate outlet-level margins without spreadsheet cleanup.

Yes. The module supports transferring a charge from one folio to another (for example, moving a bar tab onto a group master folio) and splitting a single check across two rooms. Transfers and splits are restricted to authorized roles and are recorded in the audit trail, so the movement of any charge is always traceable at night audit and checkout.