At FLYR, we aim to ensure a seamless integration and data synchronization experience between Opera Cloud and FLYR. However, due to certain limitations in Opera Cloud’s API and data structures, there may be instances where reported data between the two systems does not fully align.
If any of these discrepancies were identified during your onboarding process, rest assured that our team would have proactively flagged and discussed them with you.
Note:
The information in this article applies to an Opera Cloud version of 22.4 or higher. If your property is using an earlier version, functionality may differ, and additional limitations could apply.
Below is a detailed overview of known data gaps, their causes, and suggested workarounds.
1. Postings on Account Receivables (AR) Are Not Supported
Description
Opera allows retrieval of revenue posted to Accounts Receivables (AR) via the API, but it does not provide detailed transaction code breakdowns.
As a result, while total revenue can be accessed, transaction-level details cannot — meaning these postings will not appear in FLYR.
Suggested Workaround
Post accommodation charges directly to PM reservations instead of Accounts Receivables (AR).
2. Postings on Passer Rooms Are Not Supported
Description
FLYR does not currently support retrieving postings made on Passer rooms through the Opera API. Consequently, any revenue posted to Passer rooms will not be reflected in FLYR.
Suggested Workaround
Post accommodation charges directly to PM reservations rather than Passer rooms.
3. Manual Transaction Routings Cannot Be Traced Back to the Original Bookings
Description
When postings are manually moved between reservations without using Opera’s routing instructions, those transactions cannot be linked back to the original booking. As a result, the original reservation’s revenue traceability is lost.
Suggested Workaround
Use the routing functionality in Opera to manage routings efficiently and maintain traceability.
4. Occupancy for Groups Under Contract or Forecast Is Not Supported
Description
Room allocations under “Contract” or “Forecast” statuses in the Group Room Grid are not retrieved via the API and will not appear in FLYR.
Suggested Workaround
Add tentative or definite room blocks under the “Current” field in the Room and Rate grid to ensure inclusion.
5. Block Deletion Is Not Supported
Description
Opera does not send a business event when a block is deleted. As a result, deleted blocks remain marked as Confirmed in FLYR and continue showing revenue and occupancy.
Suggested Workaround
Instead of deleting blocks, cancel them. This ensures the block status and associated data are correctly updated in FLYR.
6. Revenue Cannot Be Traced for Block Reservations Without Routings
Description
If reservations have postings routed to a PM or another reservation without visible routing instructions in Opera, the associated revenue cannot be traced back to the original reservations in FLYR.
Suggested Workaround
Always include routing instructions in Opera and avoid manual routings whenever possible.
7. FLYR Supports Only One-to-One Revenue Routings
Description
Currently, FLYR supports only a single routing instruction per reservation. If a reservation has multiple routings (e.g., first night to Reservation A, second night to Reservation B), only the first routing will be processed — all revenue will be allocated to the first reservation.
Suggested Workaround
None available. This behavior aligns with standard Opera functionality.
8. Reservation Deletion Is Not Supported
Description
If a reservation is deleted (instead of canceled), Opera returns a “Not Found” error. This prevents FLYR from updating the status to “Canceled,” leaving the reservation incorrectly marked as Confirmed.
Suggested Workaround
Cancel reservations instead of deleting them to ensure accurate reflection in both systems.
9. Only Daily Rate Plans Are Supported for Price Updates
Description
For FLYR to push price updates successfully, the Base Rate Plan must be a daily rate plan. Non-daily rate structures are not supported.
Suggested Workaround
If your property uses a non-daily rate plan, create a daily rate plan and set up dependencies for other rates accordingly.
10. Pick-Up Revenue for Adjustments on Past Reservations
Description
Revenue adjustments for past stay dates are generally reflected correctly in FLYR as long as they are non-overnight. However, overnight adjustments may cause pick-up discrepancies between FLYR and Opera.
Suggested Workaround
None required — this is a known timing discrepancy that typically resolves once both systems process the overnight adjustment.
11. Pick-Up Revenue for Routed Bookings
Description
For routed bookings, pick-up revenue may temporarily display on different dates than the actual posting.
Revenue may initially appear as removed from the origin booking (often on the check-in date) and later reappear under the destination booking on the correct stay date. This can cause temporary inflation until both bookings are updated, usually upon check-out.
Suggested Workaround
None. This is a limitation related to how Opera updates booking modification timestamps.
12. Multiple shared reservations across different stay dates
Description
When multiple shared reservations span different stay dates, Opera does not provide a clear identifier to determine which reservation should be considered the primary share for holding occupancy. As a result, it is not possible to reliably identify the correct primary share based solely on the data returned by Opera.
Suggested Workaround
Create separate reservations when guests do not share the same stay dates.
Only create shared reservations when all guests have identical stay dates.
13. Overlapping restrictions of different types
Description
Opera Cloud (OHIP) has a fundamental constraint in how it stores restrictions: for any given combination of rate plan + room type + stay date, only one restriction type can be active at a time. In FLYR, restrictions across different types can coexist and be active at the same time.
Restriction types in FLYR fall into three categories:
Arrival-based — Closed for Arrival (CTA), Minimum/Maximum Length of Stay (ALOS)
Stay-based — Closed to Stay, Minimum/Maximum Stay Through
Departure-based — Closed for Departure, Minimum/Maximum Stay Departure
When FLYR sends two restrictions of the same type that overlap (e.g., a CTA and an ALOS2 both applied to the same rate plan, room type, and date range), Opera handles them correctly — and will put in place only the currently active restriction of that type.
However, when FLYR sends two restrictions of different types that overlap on the same rate plan + room type + stay date, Opera can only hold one. This means that if the higher-priority restriction is later removed (e.g., FLYR removes a tactical ALOS), Opera will not automatically reapply the other restriction that was effectively overwritten — it will simply be gone.
Example: A hotel sets a strategic Closed to Stay restriction at the rate plan level in FLYR. After that a a tactical ALOS2 (Arrival LOS) restriction on the same date and rate plan is applied. Because these are different types (stay-based vs. arrival-based), when FLYR later removes the ALOS2, the Closed to Stay does not reapply — it was already displaced. If the strategic restriction had instead been a CTA (also arrival-based), removing the ALOS2 would replace it with the CTA again.
Suggested Workaround
To avoid this issue, follow these two principles:
1. Set strategic restrictions at rate plan level using the same type as FLYR's tactical restrictions.
FLYR's tactical restrictions use either arrival-based or stay-based logic — not both. Your property's configuration will determine which type FLYR uses (e.g., if your setup is arrival-based, FLYR will recommend CTA and ALOS). Strategic restrictions set manually in Opera should use that same type so they coexist safely with any tactical restrictions FLYR applies.
2. Do not combine different restriction types that overlap in date and rate plan scope.
Avoid a situation where, for example, a Stay Closed is active at the rate plan level while FLYR is applying Arrival LOS restrictions on overlapping dates. If you do see a mismatch between restrictions in FLYR and Opera, contact our support team.
Summary
While FLYR’s integration with Opera Cloud captures the majority of operational and financial data, a few structural differences and API limitations can lead to persistent discrepancies. For more information on temporary discrepancies, check out this article.
By following the suggested workarounds above and adhering to Opera best practices (such as using routing instructions and canceling rather than deleting records), properties can significantly minimize data inconsistencies.
If you have any questions or encounter discrepancies not listed here, please reach out to our support team! We’re here to help ensure your reporting remains as accurate as possible.