FLYR’s integration with Opera on Prem (OXI) is designed to ensure accurate synchronization of operational and financial data. However, due to specific constraints in the OXI interface and data handling within Opera, some scenarios are currently not supported or behave differently than expected.
If any of these discrepancies were identified during your onboarding process, our team would have proactively flagged them and discussed potential impacts and workarounds with you.
Note:
The information in this article applies to Opera version 5.5.0.23 or higher. If your property is using an earlier version, functionality may differ, and additional limitations could apply.
Below is a list of known unsupported scenarios, including detailed explanations and suggested workarounds.
1. Postings to Account Receivable (AR)
Description
Postings made directly to Accounts Receivable (AR) are not received via OXI and therefore do not appear in FLYR.
Suggested Workaround
Post accommodation charges directly to PM reservations instead of AR.
2. Postings to Passer By Rooms
Description
Postings made directly to Passer By rooms are not transmitted through OXI and will not appear in FLYR.
Suggested Workaround
Post accommodation charges directly to PM reservations rather than Passer By rooms.
3. Accommodation Charges Manually Posted to Checked-In Reservations
Description
Accommodation charges manually posted to checked-in reservations (e.g., early check-in charges) are only received via the STAY message upon check-out.
This means interim updates will not reflect in FLYR until the reservation is checked out.
Suggested Workaround
None. This is a standard behavior in Opera and a limitation of OXI.
4. Routings to PM Reservations
Description
There are three routing-related scenarios that can impact data synchronization:
Scenario 1: All reservations routed to a PM
Revenue remains on the individual reservations until the PM checks out. Upon PM check-out, the revenue is reverted from the PM to the original reservations.Scenario 2: All reservations manually transferred to a PM
Revenue is removed from individual bookings upon their check-out. When the PM checks out, OXI sends the revenue for the manually transferred postings — this revenue is not reverted to the original reservations, and the PM retains all revenue.
Manual posting movements cannot be traced back to the original booking because routing instructions are missing.Scenario 3: Mixed routed and manual transfers to a PM
For routed bookings, revenue remains on individual reservations until PM check-out, at which point it’s reverted appropriately.
For manually transferred bookings, revenue is only received when the PM checks out and is not reverted.
Suggested Workaround
Use Opera’s routing functionality to manage routings efficiently and avoid manual transfers whenever possible.
5. Manual Postings to Future Reservations
Description
Manual charges posted to future bookings are not received via OXI.
Suggested Workaround
None. This is standard Opera behavior.
6. Manual Postings After Check-Out
Description
Charges posted after a reservation’s check-out date are not transmitted through OXI and will not appear in FLYR.
Suggested Workaround
Post such charges to a PM reservation instead of a checked-out booking.
7. Manually Transferred Revenue Between Bookings
Description
When revenue is manually transferred from one booking (A) to another (B) that has different stay dates (e.g., back-to-back reservations), the revenue from the first booking will only be received after the second booking checks out.
Suggested Workaround
None. This is standard Opera functionality.
8. One-to-Many Routings Not Supported
Description
FLYR supports only one-to-one routing instructions.
If a reservation includes multiple routings (e.g., first night to Reservation A, second night to Reservation B), only the first routing is processed, and all revenue is allocated to the first reservation.
Suggested Workaround
None. This aligns with standard Opera routing behavior.
9. Tax Codes for Service Charges
Description
In certain configurations (notably observed in UAE properties), tax codes used for service charges may be set up to generate accommodation revenue.
In such cases, this revenue is only received upon check-out, which causes a delay in reporting the associated accommodation revenue.
Suggested Workaround
None. This is standard Opera behavior.
10. Revenue for Historically Cancelled Reservations
Description
Revenue from cancelled reservations prior to the initial FLYR connection is tracked only if cancellation charges were actually posted.
If no such charges exist, accommodation revenue for those historical cancelled bookings cannot be retrieved.
Suggested Workaround
None. This is a limitation of Opera’s export functionality.
11. Derived Rate Plans – Parent-Child Relationships (Resolved)
Description
Previously, missing parent-child relationships caused all rate plans to be retrieved as “parent” plans.
This issue has been resolved.
Suggested Workaround
For existing customers, request a rate plan resync to ensure relationships are restored.
Note: PMS access is required for this process.
12. Derived Rate Plans – Base and Dynamic Base Rate Configuration
Description
If a derived rate plan includes both a Base Rate and a Dynamic Base Rate, FLYR will set the Base Rate as the parent rate plan.
This may cause inconsistencies in rate inheritance.
Suggested Workaround
Only configure one type of Base Rate (either Base Rate, Dynamic Base Rate, or Advanced Dynamic Base Rate) per derived rate plan.
13. Derived Rate Plans – Price Import Limitations
Description
Rate imports are not possible for child rate plans that use Dynamic Base Rates or Advanced Dynamic Base Rates, as these do not store fixed prices in Opera. Prices are dynamically calculated at runtime during booking or availability checks.
Suggested Workaround
None. This is a known limitation within Opera and OXI.
14. Derived Rate Plans – Restrictions on Dynamic Base Rates
Description
Opera requires a price to be stored for restrictions to apply.
Since FLYR and the integration adapter cannot retrieve prices for derived rate plans using Dynamic or Advanced Dynamic Base Rates, restrictions cannot be sent or applied.
Suggested Workaround
None. This is a limitation within the FLYR/Adapter integration due to Opera’s design.
Summary
While FLYR’s integration with Opera V5 (OXI) provides extensive coverage of reservation, revenue, and rate data, some scenarios remain unsupported due to the technical constraints of the OXI interface. For information on any other temporary discrepancies, check out this article.
By following Opera best practices — particularly around routing, PM usage, and rate plan setup — you can help minimize data inconsistencies between Opera and FLYR.
If you have questions about any of the above scenarios or notice discrepancies not covered here, please reach out to our support team for further guidance.