Opera PMS Integration (OHIP)

Connect AVA to Oracle's Opera Cloud property management system via OHIP (Oracle Hospitality Integration Platform). Once configured, AVA syncs reservations, room inventory, and guest information directly from Opera. Guest profiles now open in AVA's shared profile layout.

Quick Setup

Most hotels finish this in 10 to 15 minutes. If you use OCIM, ask Oracle for enterpriseId first.

Where to Find It

Settings → Essentials → Property Management System (PMS) Integration

Before You Start

Get these credentials from your IT team or Oracle/Opera administrator:

Credential	Description
OHIP Host Name	API base URL (e.g., ohip.oraclecloud.com)
OHIP Application Key	Application key for API access
OHIP Hotel ID	Your property identifier in Opera
OHIP Client ID	OAuth client identifier
OHIP Client Secret	OAuth client secret
enterpriseId	Oracle's OCIM enterprise identifier. Required when OHIP Identity Management is OCIM.

warning

Opera OHIP integration requires technical setup by Oracle or your IT team. They will provide the API credentials after enabling OHIP access for your property.

OCIM requires one extra value

If you select OCIM, AVA now needs enterpriseId before it can request tokens. Keep that value with the rest of your OHIP credentials.

Room key validity uses local time

Set the property's IANA timezone in Settings → Essentials → Hotel Basic Details. AVA uses it to format Opera room-key validity in local wall-clock time.

Required for Thailand compliance reports

Ask your Opera administrator to enable Module Level Access Control in Global Administration. They must also grant the AVA OHIP client Sensitive Data Access. Without this access, Opera masks some passport numbers and birth dates in TM30 and RR4 reports.

Configuration Steps

Step 1: Select Opera as Your PMS

1. Go to Settings → Essentials
2. Scroll to PMS Integration
3. Click the Opera card
4. A checkmark (✓) appears to confirm selection

Step 2: Enter OHIP Configuration

Fill in each field:

• OHIP Host Name: The base URL of your OHIP API instance (e.g., ohip.oraclecloud.com)
• OHIP Application Key: Your application key for API access (click Edit Secret to update)
• OHIP Hotel ID: Your property's Opera hotel code
• OHIP Identity Management: Choose OCIM (Oracle Cloud Identity) or SSD (Direct Credentials)
• OHIP Client ID: OAuth client identifier
• OHIP Client Secret: OAuth secret key (click Edit Secret to update)
• enterpriseId: Oracle's OCIM enterprise identifier. Use this only when OHIP Identity Management is OCIM.

If you selected SSD for identity management, also enter:

• OHIP Username: Direct login username
• OHIP Password: Direct login password

Step 3: Save and Verify

1. Click Save
2. Check the status indicator:
   • 🟢 "Opera Integration Configured" = All required fields are entered
   • 🟡 "Opera Integration Not Configured" = Missing required fields

Set reservation note defaults

Use these optional fields when staff add reservation notes from AVA. The Reservation Notes panel shows the filing values before staff add a note. AVA loads comment types and locations from Opera. Each list uses its own shared cache for up to 30 days. Click Refresh from PMS beside a field when you need the latest choices. Every field using that list updates together, including fields on other settings pages. If a list is unavailable, AVA keeps other lists available and the field remains editable.

Setting	What it controls	Empty value
Reservation Note Comment Type	The Opera comment type for staff notes	GEN
Reservation Note Comment Location	The Opera location for staff notes	RESERVATION

1. Open the Opera integration's Advanced settings.
2. Select the Opera note type and location your hotel uses.
3. Leave either field empty to use its displayed default.
4. Click Save.

AVA displays the filing summary as GEN · RESERVATION when both fields use defaults. Staff can select Configure in Settings from Reservation Notes when they have access.

Staff notes and payment comments are separate

These settings apply only to notes added from Reservation Notes. They do not change payment or pre-authorization comments. Those comments continue using Default Comment Type / Location in Settings → Payment.

Confirm note types with your Opera administrator

Opera note-type codes are hotel-configured. Confirm that your selected code is valid before staff add notes.

The available comment locations are CASHIER, GENERAL, IN HOUSE, and RESERVATION. The list of comment types comes from your Opera reservation note configuration. If a saved code is no longer available in Opera, AVA keeps it visible and flags it. Replace the flagged code before staff add reservation notes.

Check-in policy location

Configure Match and merge guest profiles under Settings → Check-In → Check-In Policy → Guest registration. See Match and Merge Guest Profiles.

Alert the front desk when the main guest arrives later

Use this setting when an additional guest may check in before the main guest. AVA adds an alert to the main Opera reservation. The setting is off by default.

1. Go to Settings → Check-In → Check-in essentials.
2. Find Alert the front desk when the main guest is arriving later.
3. Turn on the setting.
4. Select Choose alert.
5. Choose one hotel-configured OPERA alert code.
6. Choose where Opera shows the alert.
7. Choose the alert code description or Custom text.
8. Enter custom text when required, then select Apply.
9. Select Save Check-In Policy.

The alert area and text choices come from your Opera connection. For custom text, AVA requires a non-empty message.

Setting	What it controls
OPERA alert code	Identifies the alert in Opera
Show the alert in	Selects the Opera alert area
Alert text	Uses the code description or your custom message

In Assisted Check-In, AVA asks staff about the main guest when the alert is enabled. The question appears when the primary booking is not already checked in. This includes accompanying and mixed arrivals. Staff can choose Yes, arriving later or No, not staying. In Self Check-In, AVA treats an absent main guest as arriving later by default. An explicit saved staff choice of No, not staying overrides that default. The latest explicit staff choice remains available for later self check-ins. The alert targets the main reservation, not the additional guest's reservation. Alert delivery is best-effort and does not delay or fail check-in.

Check the reservation before retrying

Opera alert posting can be delayed by a record lock. Check the main reservation in Opera before selecting Continue again.

Issue room access when a sharer arrives first

When a sharer checks in before the main guest, AVA can issue room access. This applies when the sharer is marked arrived and shares the assigned room.

For keycards, AVA refreshes the live Opera occupancy before refusing the request. The same check supports lost-keycard replacement for an arrived sharer. Accompanying guests remain on the main reservation and follow the normal flow.

If the sharer has checked out, or uses another room, AVA refuses access. This protects the room from an incorrect keycard.

1. Confirm the sharer is checked in through AVA or Opera.

2. Confirm the sharer and main guest use the same room in Opera.

3. Retry Create Keycard or the lost-keycard flow.

4. Send the guest to the front desk if Opera cannot confirm the stay.

   ✓ AVA should issue access only after the live room and arrival checks pass.

Step 4: Choose Guest Placement

Choose how AVA places additional guests in Opera during registration.

1. Go to Settings → Check-In → Check-In Policy

2. In Registration, find Additional Guest Under.

3. Choose one option:

   Option	Result
   Sharer Reservation	Creates a separate Opera reservation for the additional guest.
   Accompany Profile	Adds the guest as an accompanying profile on the main reservation.

4. Decide whether to apply the choice to existing additional guests.

5. Turn on Apply this setting to existing additional guests when you want existing guests converted. AVA converts eligible Opera sharers or accompanying guests during registration.

6. Click Save Check-In Policy.

   ✓ New additional guests always follow the selected option.

Room attachment follows the same placement choice after guest synchronization. In Sharer Reservation mode, AVA verifies the linked sharer before attaching the room. It does not add an accompanying profile to the main reservation. In Accompany Profile mode, AVA keeps the guest attached to the main reservation.

Choose Sharer Document Destination

Choose where Opera shows passport, identity-document, and signed registration-card attachments. Passport and identity-document copies also remain on each sharer's guest profile. The saved destination controls new uploads, including cards created during explicit-arrival check-in. Your selected destination takes priority over AVA's default sharer reservation target.

1. In Registration, find Upload sharer documents to.

2. Choose one option:

   Option	Result
   Main Guest Reservation	Collects all sharer documents and registration cards on the main reservation.
   Sharer Reservation	Attaches each sharer's documents and registration card to that sharer's reservation.

3. Click Save Check-In Policy.

   ✓ New travel documents and signed registration cards use the selected Opera destination.

Existing PMS attachments

Changing this setting does not move attachments already stored in Opera. New uploads follow the setting after you save it.

Existing guest conversions

The checkbox is off by default. When it is off, AVA preserves existing sharer and accompanying-guest relationships. When it is on, AVA converts eligible existing additional guests during registration. This is not a bulk migration. Turning it off later does not undo completed conversions.

Conversion eligibility

AVA converts only reserved Opera bookings with complete, unchanged financial details. Packages on the main reservation are allowed and remain unchanged in both conversion directions. An eligible sharer may inherit rate-plan packages with zero quantity, value, allowance, and consumption. A nonzero package unit price alone does not block conversion when its quantity and computed value are zero. Reservation-added, consumed, nonzero, or unknown package activity still requires staff review. Removing an existing sharer still requires the package, occupancy, rate, and financial checks to pass. An eligible sharer with zero adults and children can convert when every outgoing routing destination targets the retained main reservation ID. Folio or comp routing, routing to another reservation, and unsupported routing structures still block conversion. AVA rechecks routing after share separation and before it cancels the old sharer reservation. If Opera cannot prove the conversion is safe, AVA pauses registration for staff review.

If a conversion stops part-way, restore the original setting before retrying. Otherwise, ask staff to reconcile the affected guests in Opera.

Configure Sharer Payment

Use this setting when AVA creates a separate sharer reservation for an additional guest.

1. Go to Settings → Check-In → Check-In Policy

2. In Registration, set Additional Guest Under to Sharer Reservation.

3. Find Sharer payment method, then click Configure.

4. Choose how Opera should set the sharer's payment and guarantee codes:

   Option	Use it when	Result
   Same as main reservation	The sharer should match the main booking	AVA uses the main reservation payment method.
   Specific OPERA method	The sharer needs an independent payment method	AVA uses your selected payment and guarantee codes.

5. For Specific OPERA method, select an eligible OPERA payment method and OPERA guarantee code.

6. Click Apply, then click Save Check-In Policy.

   ✓ The saved pair is used for generated sharer reservations, even when the request has no override.

AVA loads eligible non-card payment methods and guarantee codes from Opera. Labels use Opera descriptions, and codes appear in numeric order. Each list stays cached for 30 days. Click Refresh from OPERA after changing codes in Opera. The refresh updates every field using the selected list. AVA checks the pair against a fresh Opera read before refusing a newly added code.

Refresh results

If a refresh cannot read a list, AVA keeps the codes read earlier and shows a refresh warning. Use Try Again to request that list again. The warning clears when you open the fields again.

Both lists must load

You cannot save Specific OPERA method until AVA loads both eligible lists. If one list is unavailable, use Try Again or ask your Opera administrator to check access. Only users with settings write access can refresh these lists in the sharer dialog.

When you save the guest-placement or sharer-payment settings, AVA syncs them to Vouch Core for Opera. This keeps generated sharer reservations aligned with your saved policy.

Confirm Opera settings before deployment

AVA no longer applies a property-specific sharer payment code. Confirm your intended setting is saved before deploying an Opera integration change. For an independent cash sharer, select CA and NON only when Opera lists both as eligible.

Set the Sharer Rate Code

Use this setting when new Opera sharer reservations need a specific rate code.

1. Go to Settings → Check-In → Check-In Policy

2. In Registration, set Additional Guest Under to Sharer Reservation.

3. Find Sharer Rate Code.

4. Click the field to load active rate-code suggestions from your PMS catalogue.

5. Select a suggestion, or enter a valid code manually.

6. Clear the field when you want to remove the override.

7. Click Save Check-In Policy.

   ✓ AVA saves the code for future sharer reservations and synchronizes it with Opera.

The setting applies when AVA creates a separate Sharer Reservation. An empty value removes the override and restores the main reservation's normal rate-plan behavior. AVA keeps custom values even when the catalogue has no matching active suggestion.

Rate-code suggestions

Suggestions show active rate plans for the hotel you currently selected. If the list is empty or unavailable, enter the code manually or click Retry.

Re-save older sharer rate settings

If your property saved a sharer rate before this update, save Sharer Rate Code again after deployment. This persists the existing value for new sharers and synchronizes it with Opera. Previously saved values remain available after the field is renamed.

What Syncs from Opera

Once connected, AVA receives:

• ✅ Guest reservations and folios
• ✅ Room availability and status
• ✅ Guest profile information in the shared AVA format
• ✅ Check-in/out transactions
• ✅ Room blocking information
• ✅ Do Not Move room-lock status
• ✅ Reservation expected arrival and departure times through the standard reservation flow
• ✅ Group Checkout capability for linked reservations

Guest & Staff Impact

• Guest forms adapt to Opera rules. Required fields and hidden fields change based on Opera configuration, so guests only see what is needed.
• Guest profiles use the shared AVA layout. Opera guest details now open in the same field structure as AVA v2.
• Long guest addresses sync safely. AVA splits addresses across Opera's four address lines when needed. Each line stays within Opera's 80-byte limit.
• Address updates clear stale lines. AVA fills all four Opera address slots, so shorter replacements remove leftover lines from earlier addresses.
• Reservation lookup uses Opera. If Opera is not configured, the guest lookup step will fail.
• Recent Opera changes may take up to five seconds to appear. This can affect reservation and folio reads after an external Opera update. Wait briefly, then refresh AVA before verifying the change.
• Opera accepts an extra guest above reported room capacity. AVA adds the guest through Opera's accompanying-profile flow.
• External-reference lookup verifies the full reservation. AVA checks the requested external reference and arrival date on the full Opera record before selecting it. If the values mismatch or results are ambiguous, AVA does not select a reservation.
• OTA references can use different letter casing. If an exact external-reference lookup returns no result, AVA retries once with the reference in uppercase. It then compares the reference without case differences on the full reservation record. Confirmation-number lookup behavior is unchanged.
• Selected arrival reservations stay explicit. When an arrival supplies selected Opera reservations, AVA checks in only those reservations. It does not add absent sharers automatically, preserves the due-in main booking when a sharer arrives first, and never expands an empty selection.
• Checkout lookup follows Opera's PMS business date. After midnight, AVA limits checkout lookup to departures due on Opera's current PMS business date. AVA also checks the departure date itself. A calendar-date departure may remain unavailable until Night Audit advances the business date.
• Departure-day room badges stay consistent. When Opera reports an occupied reservation as Due Out, AVA shows Due Out on the reservation and each occupied room card. This keeps single-room and expanded multi-room views aligned. Explicit room states such as Reserved, Checked Out, Cancelled, and No Show remain unchanged.
• ACI name searches use active reservations. Staff Access checks active Opera reservations using the guest's complete name, including multi-part names.
• Staff Access groups native Opera families across arrival-list pages. During a broad arrival refresh, AVA reads the full window before grouping booking families. A linked companion stays with the correct room even when Opera returns it on another page.
• Native grouping applies to every Opera merchant. AVA uses Opera's own booking relationships for guest lookup and Staff Access. You do not need a property-specific grouping rollout.
• The primary reservation stays primary. AVA waives main guest registration only for selected additional reservations.
• Additional guest updates do not overwrite the primary guest. Name-bearing updates create an additional guest on the selected reservation.
• Returning additional guests can reuse an Opera profile. When Match and merge guest profiles is on, AVA searches by name and identity document before creating a new additional-guest profile.
• Opera passport codes can match AVA passport types. AVA treats the exact Opera codes PAS and PASSPORT as equivalent during profile matching.
• Uncertain matches do not reuse a profile automatically. AVA requires a verified unique match. Staff can choose a verified candidate or create a new profile.
• Profile matching uses extra Opera calls. A unique match can require more profile reads. Staff comparison shows only a bounded set of verified candidates.
• Verified duplicate profiles can be merged when enabled. Staff can merge two to five matching profiles after choosing the survivor and confirming a fresh Opera preview.
• Merges are deliberately strict. AVA requires matching full names, unmasked identity documents, birth dates, compatible nationalities, and unchanged profile details.
• A completed merge creates a new survivor receipt. Retired profile IDs remain blocked, so an old selection cannot create or edit a retired profile.
• Uncertain or partial merges stop for support review. AVA does not retry an unclear Opera write or assume that a merge succeeded.
• Accompanying profiles use authoritative main-guest context. Before creating an accompanying profile, AVA refreshes the Opera reservation and requires exactly one explicit main guest with a usable profile ID. Missing, blank, mismatched, or ambiguous identity context stops the action before profile creation.
• Manual grouping changes AVA's ACI journey only. It does not create or change a reservation group in Opera.
• Active reservations appear by default. Cancelled reservations stay out of normal lookup results unless a workflow explicitly requests them.
• Multi-room reservations keep the searched room on the right card. AVA preserves the confirmation you looked up, even when Opera normalizes the family to the main confirmation or uses different internal IDs.
• Opera data defines the booking family. AVA uses Opera links, SiteMinder components, and eligible CRS co-booked rooms. It does not merge reservations only because they share a profile, arrival date, or external booking ID.
• Native grouping keeps only matching rooms. AVA excludes cancelled, no-show, checked-out, pseudo-room, and non-overlapping stays. It also collapses share partners and same-room records into one physical room.
• Some unlinked CRS rooms can form one booking family. AVA groups rooms from one CRS when the same guest profile and arrival date match. The rooms must be created within 10 seconds, and the family can contain up to nine rooms. This covers CRS sources such as Accor TARS and SynXis.
• Native links and room sharing take priority. AVA keeps shared rooms together only among share partners. Hotel-created group bursts, bookings with different guest profiles, and groups of 10 or more rooms stay separate.
• SiteMinder bookings use an exact component reference. If Opera has no native link family, AVA matches the exact SiteMinder component reference. Similar references do not merge unrelated bookings.
• Shared-room guest lookups use the host reservation. In Self Check-In, entering a linked sharer's confirmation opens the live host reservation when both records represent one share-only room. This keeps both occupants on one AVA check-in record.
• Host selection does not rely on reservation ID order. AVA compares the linked reservation's role, rate plan, and adult count before using numeric IDs as a fallback. A newly created zero-adult sharer can therefore keep the original host reservation, even when Opera gives the sharer a lower ID.
• ACI keeps each sharer linked to its owning reservation. When a guest arrives through a linked Opera sharer, AVA uses that sharer's reservation identity during check-in. This prevents a valid sharer from being blocked when its confirmation differs from the host reservation.
• Multi-room and exact reads keep their requested reservation. A booking with multiple rooms does not re-anchor to a host. Check-in writes, guest sync, adding guests, checkout, and lost-keycard lookup still target the reservation they request.
• Host lookup errors stop the guest lookup. If AVA cannot reread the host reservation, retry the lookup after the Opera connection recovers. AVA does not fall back to the sharer's reservation.
• Your searched reservation stays primary for grouped results. Opening a child or sharer in a genuine multi-room family still starts from that reservation, while AVA shows the other eligible rooms in the same family.
• A booking family can contain several Opera reservation IDs. AVA shows the eligible rooms together while keeping the requested reservation for room-specific actions.
• Each family room keeps its own reservation holder. AVA shows that room's confirmation number, stay dates, and reservation identity.
• Excluding a reservation excludes only its room. Other rooms in the same Opera family remain visible with their own holders.
• Room swaps protect family rooms. AVA never plans another booking into a room held by a family sibling.
• Shared rooms are not offered for swaps. If two reservations share a room, AVA counts both holders and refuses the target.
• Your own family room may still appear. Selecting it is refused because the room belongs to the guest's own booking.
• Verified One Device and Two Device ACI support room operations. Staff can view room condition and occupancy, refresh the Opera assignment, choose a ready replacement room, and update Clean, Dirty, or Inspected conditions.
• Room refreshes fail closed. If Opera returns no room or an ambiguous multi-room result, AVA keeps the stored room instead of choosing another one.
• Smart assignment checks the full stay window. AVA excludes rooms assigned to another reservation between the requested arrival and departure dates, even when Opera shows them vacant today.
• Smart assignment reads every relevant Opera room holder. AVA continues through Opera's reservation pages before deciding that a room is free. This keeps later-page bookings visible during room assignment and ACI room-swap planning.
• Swap planning reads current Opera holders. AVA refreshes every relevant reservation page before building a plan. This includes bookings created recently on another AVA session. AVA still rejects plans that become stale before confirmation.
• Room-holder checks use the requested room type. AVA asks Opera for one room type at a time, so upgraded bookings remain visible under the room type Opera assigned.
• Smart assignment checks future room blocks. AVA also excludes rooms with an Opera Out of Order or Out of Service period during the stay. A room must be ready and available for every night.
• Room-type upgrades are Opera-only. When your hotel has a room-type ladder enabled, AVA can offer a higher room type when the booked type has no ready room for the full stay.
• Upgrades follow the hotel's ladder. AVA offers the nearest allowed higher types first and shows how many levels each option is above the held type.
• Upgrades never reduce the paid type. AVA uses the higher of the paid type and held type as the minimum allowed type. It does not move a booking below the room type it paid for.
• An upgrade does not reprice the booking. The paid room type, rate plan, nightly amounts, and total remain unchanged after a room-type assignment.
• Room swaps can move bookings upward. When a selected room is held by another eligible booking, AVA may plan a chain of higher-type moves. It rechecks nightly inventory before execution and can drop a plan that no longer fits.
• Room-swap plans can show holder membership details. When Opera provides them, AVA shows the booking holder's membership programme and tier while staff review a possible move. This helps staff choose between eligible swap plans.
• Swap cards show complete holder alerts. When AVA reads a swappable holder, the card can show every Opera alert, including global profile alerts.
• Alert details stay on the staff card. Review each alert's code, area, description, and global status before approving a swap.
• Committed rooms cannot be swapped. In Opera, AVA treats its DNR alert, Strictly DO NOT RELEASE. Room Committed for Kiosk Guest, like Do Not Move. It never moves that booking during a room-swap plan.
• Hotel alert codes can also block swaps. In Settings → Check-In → Check-In Policy → Kiosk & payments, add your hotel's own codes under Alert codes that block a room swap. A holder with a selected code stays in place.
• Codes ignore spacing and letter case. AVA trims configured codes and compares them without case differences. DNR always blocks and does not need to be listed.
• Other holder alerts rank last. AVA places plans that move an alerted booking below plans that move no alerted bookings. Review the alert and confirm the move before continuing.
• Unverified alerts are marked. A room may show an unverified alert count when AVA cannot read it, excludes it, or reaches the read limit. AVA does not offer that room for swapping.
• Room-type policies control take-backs. Depending on your hotel's policy, AVA may allow a booking to return to its booked type when higher rooms are needed. A take-back never moves the booking below its paid type.
• Assignments use an allow-list guard. If a room action supplies allowed room types, Opera refuses another type before AVA releases the current room. The booking stays in its current room.
• Late Opera sharers keep the shared room. If the main guest is in-house, AVA keeps that room for a late linked sharer, even when reassignment is allowed.
• Later-arriving sharers can recover after the main guest checks in. Opera may stop listing the future sharer from the in-house main reservation. AVA can recover the sharer from its own reservation when Opera links it back to the main reservation. The stay must remain active.
• Recovery is limited to safe matches. Cancelled, no-show, checked-out, mismatched, or unreadable sharer reservations remain unresolved for staff review. Normal arrivals make no extra Opera read.
• Room readiness still applies to kept sharer rooms. AVA accepts Clean, Inspected, Dirty, or Pickup when the linked stay holds the room. Out of Order and Out of Service remain blocked.
• Your reservation's own preassignment remains eligible. AVA does not reject the room simply because Opera lists it for the current booking.
• Opera record delays use the existing fallback. If AVA cannot read overlapping reservations, Opera remains the final conflict check and AVA retries another room after a conflict.
• An empty Opera out-of-service result is valid. When Opera returns no out-of-service rooms, AVA treats the result as empty. Room assignment can continue. A missing or malformed result still shows a PMS-unavailable error.
• Component suites check every linked room. If Opera represents a suite with component rooms, AVA checks each member's occupancy and readiness before assignment.
• Occupied component rooms keep priority. If one member is occupied, AVA preserves that occupied reason instead of selecting another unready status.
• Unverified auto-selected suites stay blocked. If AVA cannot verify an automatically selected component suite, it blocks the assignment request.
• Ordinary rooms keep the existing path. These extra component-room checks do not apply to ordinary rooms or unrelated auto-selected rooms.
• Room operations require a verified staff device. AVA checks the current Opera assignment before room changes and requires Opera confirmation before reporting a housekeeping update as successful.
• Required moves respect Do Not Move. If Opera locks a booking, a required move to a different room fails with a clear message. AVA does not report a false successful move or change the locked room.
• Normal Opera assignments stay movable. AVA keeps bookings unlocked after ordinary pre-arrival assignments unless you explicitly request a room lock. Staff can move the booking later when Opera allows it.
• Group Checkout is available when Opera reports support. Turn it on in Settings → Check-In → Check-In Policy after the connection is active.
• Partial multi-room check-in survives a refresh. After the registered main room checks in, a refetched booking keeps an empty subsequent room eligible. AVA matches the room to the same booking family, so an unrelated checked-in room cannot unlock it.
• Empty subsequent rooms can check in during explicit arrival. With Allow empty subsequent room check-in on, an empty later room skips the arrival preview and decision. Staff authorization, payment readiness, and room readiness still apply.
• Empty subsequent-room actions remain available. After you select and check in an empty subsequent room, AVA sends only that room to Opera. For an already checked-in empty room without its own access payload, AVA checks the merchant Keycard setting. If unavailable, AVA checks explicit Keycard access from an in-house sibling in the same reservation. Room Information and Create Keycard then appear.
• Sharer reservations stay separate. If Opera uses one confirmation number for multiple reservation IDs, AVA keeps each reservation as its own check-in target.
• Redundant sharers share one room result. When Opera links a main reservation and a zero-occupancy sharer to one physical room, AVA shows one room result.
• Independent sharer state stays visible. AVA keeps a related record visible when it has guest progress, payment, billing, or check-in state.
• Guest placement is opt-in for existing guests. The Apply this setting to existing additional guests checkbox is off by default. When enabled, registration converts eligible existing Opera sharers or accompanying guests to the selected Additional Guest Under option. New additional guests always use the selected option.
• Zero-occupancy sharer packages can be inherited safely. A sharer with zero adults and children can retain rate-plan packages when their quantity, computed price, allowance, and consumption are zero. A nonzero unit price alone does not block conversion. Reservation-added, consumed, nonzero, or unknown package activity still requires staff review. Main reservation packages remain unchanged.
• Sharers routed to the main reservation can convert. A sharer with zero adults and children can convert when every outgoing routing destination points to the retained main reservation. Folio or comp routing, another reservation destination, and unsupported structures remain blocked.
• Existing guest conversion requires Opera confirmation. AVA keeps registration pending until Opera returns complete, matching guest and reservation identifiers for the new placement. It then delivers queued documents to the confirmed destination.
• Pending conversions survive reservation refreshes. AVA preserves the pending guest and its files while Opera temporarily omits or changes the guest profile. Refresh the reservation and retry after Opera confirms the placement.
• Sharer payment settings control generated reservations. A specific payment-and-guarantee pair takes priority over Opera's cash-method lookup. Without a specific pair, AVA uses Opera's eligible cash payment method.
• Sharer Rate Code saves synchronize with Opera. AVA saves the code before completing the dependent PMS synchronization. A failed PMS settings save stops the rate-code synchronization, preventing a partial update. Clearing the field removes the override for future sharer reservations.
• Sharer payment copies reconcile separately. AVA can complete the share while the payment copy remains pending. Confirmed pre-dispatch failures and Opera rejections can reopen the copy for a safe retry. Unclear outcomes stay paused to prevent duplicate payment methods in Opera.
• Guest-placement settings sync with Vouch Core. Saving Additional Guest Under or sharer-payment settings forwards the saved values for future Opera guest actions.
• Charged room type stays stable. When AVA assigns a room in Opera, it keeps the charged room type unchanged, even if the physical room has a different type.
• Adding guests to a room stays synced. If staff add another guest during check-in, AVA updates Opera so the extra guest stays attached to that room.
• Room attachment respects guest placement. AVA uses the current Additional Guest Under setting when attaching a room after guest synchronization. In Sharer Reservation mode, AVA requires the linked sharer to match the reservation and have a primary guest profile. It does not create an accompanying profile during room attachment. In Accompany Profile mode, AVA keeps the existing accompanying-profile attachment flow.
• New duplicate relationships are blocked. If Opera cannot prove the requested sharer link, AVA stops the room attachment instead of rewriting the main reservation's guest list. This protects against duplicate sharer and accompanying-profile relationships. It does not remove duplicates that already exist or repair adult and child occupancy counts.
• Assisted check-in can show rate codes. When Opera sends a rate code, AVA shows it on the selected reservation card during staff-assisted check-in.
• Two-device ACI can show an Arrival brief. Staff can review advisory suggestions and read-only reservation facts from the staff screen.
• The Arrival brief can show ten Opera detail groups. These include VIP level, membership type, rate code, alerts, notes, deposit paid, balance, total stay cost, preferences, and packages.
• The Arrival brief can show membership details. When Opera provides them, the staff screen shows the membership programme, tier, and card number. These details are read-only and stay on the staff screen.
• Membership tiers use Opera's description. For example, Opera may provide ALL Accor - Gold as the programme description. AVA uses that description instead of requiring a separate membership catalogue lookup.
• Inactive memberships remain evidence but do not become staff facts. Review the active membership shown by the staff screen before using it for arrival decisions.
• The Arrival brief loads details as needed. AVA loads core reservation facts first, then retrieves profile, rate, or folio details when requested.
• Arrival brief reads stay bounded. A basic brief uses two upstream reads for an assigned room. Opening Rate, Profile, or Folio adds only that section's on-demand reads, then reopening it uses the cache.
• OPERA balance values stay distinct. The basic Balance is the current guest-window balance. The Rate section's outstanding stay cost comes from OPERA rate information and is not inferred from the basic balance.
• Optional sections load independently. Staff can open Profile, Rate, or Folio without loading the other sections.
• Optional sections can be refreshed. Staff can select Refresh after a section loads or when a read fails.
• Multi-reservation briefs use the available rail space. The guest-tablet controls stay at the bottom of the rail.
• Single-reservation briefs stay compact. AVA keeps the guest-tablet controls in their usual position.
• The paired tablet preview keeps its size. The staff panel scrolls on short screens instead of shrinking the guest preview.
• On-demand loading does not change ordinary billing. Check-in, checkout, and payment workflows keep their existing behavior.
• Missing Opera values remain visible. AVA shows Not provided instead of hiding a missing detail.
• The Arrival brief is staff-only and read-only. It checks the staff role, hotel, reservation, and guest membership without taking journey ownership. Staff can reopen it in a fresh Check-in Connect session without a paired guest tablet. Guest-tablet actions still require the active two-device ACI journey.
• Two-device ACI can print a pro-forma invoice. The action appears when Opera reports support. The PDF uses the property's Opera folio template and shows the projected stay with deposits as credits. It reads folio window 1 and does not post the projection to the live folio. Selecting Print pro-forma opens the PDF in a new browser tab. If the browser blocks the tab, AVA downloads the PDF and shows a downloaded notice.
• Arrival brief suggestions can be reviewed. Staff can select Done or Dismiss, then use Reopen when needed.
• Travel-agent labels stay visible. Opera can pass the agency name into sourceName. That lets waiver matching see labels like Booking.com (VCC).
• Payment posts can add comments. After a successful Opera payment or deposit, AVA adds a reservation comment in Opera. It uses your configured Default Comment Type / Location from Settings → Payment.
• Payment amounts should match the property currency. Opera can return an internal error when currencies do not match.
• Uploaded documents can appear in Opera attachments. After sync, you can verify travel document and registration card uploads from the reservation.
• Opera attachment names are normalized before upload. AVA removes guest-name punctuation while preserving letters, including Thai characters, digits, spaces, _, and -. AVA detects common file types from the file content and uses the matching extension. This prevents names such as R. Rendy Purwidyaputra from causing an OHIP "Chosen file is invalid" rejection.
• Reservation expected times stay in sync. AVA writes estimated arrival and departure times back to Opera. It reads the normalized values into Streamliner after Opera responds. Guest-entered Estimated Arrival Time and Departure Time values update Opera after guest registration. For a main reservation, AVA uses the canonical main guest's valid values. For an Opera sharer, AVA writes valid times to the sharer's own reservation. If a time field is visible only to the main guest, the sharer inherits the main guest's valid value. A sharer's own valid value remains authoritative when that field is available to the sharer. AVA does not copy a sharer's times onto the main reservation. Missing or invalid values leave the existing Opera time unchanged. You can see PMS-backed arrival and departure times on supported reservation cards and rows.
• Special codes follow the selected check-in mode. Pre-arrival, Self Check-In, and Assisted Check-In each use their own registration, pre-authorisation, and check-in codes. If you explicitly leave a mode code blank, AVA does not fall back to the global OPERA Check-In code. Older flat settings are copied into each mode when AVA first loads them. Edit and save each mode separately when their codes differ. The Self Check-In tab opens first, and inactive mode panels remain hidden until selected. Checkout remains separate and uses the global checkout code.
• Optional checkout special codes retry transient Opera failures. AVA retries once after a short-lived OHIP error. It checks Opera before retrying, so an uncertain response does not create a duplicate code. Checkout still completes if the optional update fails.
• Opera billing policies shape the guest bill. Hide and waive rules have different effects.
• Payment policy controls appear in Settings → Payment. Capability data controls which accommodation and Opera-specific controls you see.
• v4 No Post follows a priority order. Authenticated Assisted Check-In uses the staff choice first when two-device ACI supports it. For kiosk and eligible pre-arrival journeys, payments set to Do not collect, or a zero deposit, force No Post. Kiosk journeys with a required deposit use Set No Post after Payment for the remaining cases.
• A paid deposit does not always prevent No Post. When Set No Post after Payment is on, kiosk and repaired-arrival guests can still receive No Post.
• Two-device ACI shows a staff choice. Set No Post in the PMS appears above Proceed to Check-In on a connected staff device. Tick No Post by default on Assisted Check-In preselects the box. Staff can clear or select it before check-in. One-device ACI, the guest tablet, and older staff builds use the saved setting without showing the box.
• v4 No Post covers reservations put in house. AVA applies the decision to every reservation checked in during that action, including newly checked-in sharers. A later kiosk companion receives No Post only on the companion reservation. The room booking is not re-restricted.
• A No Post failure does not undo check-in. Verify the reservation in OPERA and apply the restriction manually when the follow-up fails.
• Payment and ACI settings have separate scopes. The payment setting controls kiosk and payment-policy cases. The Assisted Check-In setting provides the two-device staff default. A forged ACI header cannot bypass the guest policy. Older v2 behavior is unchanged.
• Waive policies reduce room-package charges and identified room-package components. For pre-arrival reservations, projected Opera rate-info room charges and their tax are waived together.
• Separately posted extras and their taxes can remain payable. They are not part of the booked room rate.
• Hide policies mask room and tax rows. The balance due stays unchanged.
• Evaluated payable billing controls checkout payment. AVA uses that amount instead of the display summary.
• An explicit Opera zero balance stays authoritative. AVA does not rebuild a positive balance from visible room, tax, or service rows. This applies when routed or settled counterparts are not visible. AVA trusts that zero only when the amount and currency match the normalized Opera bill. A mismatch remains unconfirmed.
• Payment reversals keep their sign. An Opera payment and equal negative reversal net to zero in AVA's folio and billing review.
• Selective billing stays within the guest's folio window. Routed charges from other windows do not increase the balance.
• Checkout prepares routed folio windows after an empty Window 1. OPERA may reject an empty primary window, while routed windows still need folios. AVA continues preparing those windows before checkout. Other folio-generation errors stop a new checkout.
• Incomplete folio data stays unconfirmed. AVA avoids showing a false zero when the guest window is incomplete.
• Projected invoice lines can remain visible. Compare unexpected charges with Opera before collecting payment.
• If no policy matches, AVA uses the billing response it receives.
• Locked rooms stay locked in AVA. If Opera marks a reservation Do Not Move, Streamliner shows the lock icon in room-change views.

Troubleshooting

"Integration Not Configured" Status

Required fields missing. Ensure you have entered:

1. OHIP Host Name
2. OHIP Application Key
3. OHIP Hotel ID
4. OHIP Client ID

No OPERA alert code appears

What you see: The alert picker shows no codes, or it cannot load codes.

Fix:

1. Confirm the active PMS is Opera.

2. Confirm your Opera user can read hotel alert-code reference data.

3. Refresh Settings → Check-In → Check-in essentials.

4. Select Choose alert again.

5. Ask your Opera administrator to configure an alert code if none exists.

   ✓ AVA accepts only alert codes returned for your hotel.

The arriving-later alert is not posted

What you see: An additional guest checks in first, but the main reservation has no new alert.

Fix:

1. Confirm the alert setting is enabled and saved.
2. Confirm the selected alert code still exists in Opera.
3. In ACI, select Yes, arriving later when AVA asks.
4. Open the main reservation in Opera and check the selected alert area.
5. Wait briefly and refresh Opera before retrying.

AVA prevents a duplicate when it can already find the same code and area. If Opera rejected a record update, retry only after checking the reservation state. 5. enterpriseId if you selected OCIM

API Connection Errors

1. Verify OHIP Host Name is correct
2. Check that your OHIP subscription is active
3. Confirm enterpriseId is saved when using OCIM
4. Contact IT to confirm firewall/network access
5. Verify credentials with Oracle support

Sharer Rate Code does not save

What you see: You cannot save a sharer rate code, or the code does not reach Opera.

Why this happens: AVA must confirm that the PMS accepted the setting. A provider configuration failure stops the dependent rate-code update.

Fix:

1. Confirm Opera Integration Configured appears in Settings → Essentials.
2. Return to Settings → Check-In → Check-In Policy.
3. Select an active catalogue suggestion, or enter the exact code from Opera.
4. Click Save Check-In Policy again.
5. If rate-code suggestions fail, click Retry or enter the code manually.
6. Confirm the code in Opera before creating a new sharer reservation.

Existing values after this update

Re-save the field after deployment when your property configured a sharer rate previously. This synchronizes the retained value with Opera.

Opera authentication is rejected during an action

What you see: An Opera action briefly pauses or shows an authentication or timeout error.

Why this happens: Opera may reject cached credentials or briefly delay its OAuth service. AVA handles each case with one automatic retry.

Fix:

1. Wait up to 30 seconds for AVA to finish its automatic retry.
2. Try the action again only if the error remains.
3. If the error returns, verify the Opera environment and credentials.
4. Re-enter the credentials in AVA, then click Save.
5. Contact Oracle or Vouch support if the error continues.

One automatic retry

AVA refreshes Opera configuration after cached credentials fail. It also retries one transient OAuth timeout or gateway error. Invalid credentials and rate limits do not trigger this retry.

Opera rejects a valid document attachment

What you see: A passport, guest document, or registration card fails with "Chosen file is invalid."

Why this happens: Opera can reject attachment names containing guest-name punctuation.

Fix:

1. Refresh the reservation in AVA.

2. Retry the document upload once.

3. Open the reservation in Opera and confirm the attachment appears.

4. If the upload still fails, contact support with the reservation number and error screenshot.

   ✓ AVA now removes unsupported punctuation before sending Opera attachments.

Opera rejects a long guest address

What you see: A guest update or check-in fails while saving a long address.

Why this happens: Opera limits each address line to 80 bytes and allows four lines.

Fix:

1. Refresh the reservation in AVA.

2. Retry the guest update or check-in once.

3. If the address still fails, shorten unnecessary text in the address fields.

4. Confirm the saved address in the guest profile or Opera.

   ✓ AVA splits long addresses at suitable breaks before sending them to Opera.

Vietnamese and other accented addresses

Opera counts bytes, not visible characters. Accented characters can reach the limit sooner.

Opera says the reservation is being changed

What you see: Final check-in shows "This reservation is being changed by user …".

Why this happens: Another Opera update still holds the reservation record lock. Room assignment may already have succeeded before this message appears. AVA retries the final Opera check-in write up to four times automatically.

Fix:

1. Wait for AVA to finish its automatic retries.

2. Refresh the reservation in AVA if the conflict remains.

3. Check the reservation in Opera for the latest room and check-in status.

4. Retry final check-in once only if Opera did not complete it.

   ✓ A short-lived Opera record lock should clear without changing the room.

If AVA shows PMS_RESERVATION_MUTATION_IN_PROGRESS after four attempts, contact support. Include the reservation number, time, and error screenshot.

Check Opera before repeating check-in

Do not repeat final check-in when Opera's result is unclear. Confirm the reservation status in Opera first.

An Opera sharer payment copy needs review

What you see: A sharer reservation exists, but its copied payment method is missing or unclear.

Why this happens: Opera appends copied payment methods and may accept a request before AVA receives its response. AVA retries only confirmed pre-dispatch failures and explicit Opera rejections. It pauses unclear outcomes to prevent duplicate payment methods.

Fix:

1. Refresh the reservation in AVA.

2. Open the related sharer reservation in Opera.

3. Confirm whether the payment method already appears.

4. Do not add the payment method manually when the result is unclear.

5. Contact support with the confirmation number, reservation ID, and time of the attempt.

   ✓ AVA can safely retry confirmed failures without appending a second payment method.

Do not repeat an unclear payment copy

An Opera timeout does not prove that the copy failed. Check Opera before repeating any payment action.

Sharer payment codes do not load

What you see: The sharer payment dialog shows no eligible payment or guarantee codes, or shows a refresh warning.

Why this happens: Opera did not return one or both requested code lists. AVA keeps each list separate, so one failed list does not hide the other list. After a failed refresh, AVA keeps earlier codes on screen when available.

Fix:

1. Click Try Again in the sharer payment dialog.

2. If codes changed recently, click Refresh from OPERA.

3. If the refresh button is disabled, ask a user with settings write access to refresh the lists.

4. Ask your Opera administrator to confirm the codes are active and allowed for reservations.

5. Confirm the Opera connection has permission to read payment methods and guarantee codes.

6. Save Specific OPERA method after both lists appear.

   ✓ AVA should show both eligible lists before you save the sharer payment pair.

Existing additional guests keep their old placement

What you see: An existing Opera sharer or accompanying guest keeps its current relationship after registration.

Why this happens: Apply this setting to existing additional guests is off by default. AVA preserves existing relationships unless you enable this Opera-only option.

Fix:

1. Open Settings → Check-In → Check-In Policy.
2. Confirm the intended Additional Guest Under option.
3. Turn on Apply this setting to existing additional guests.
4. Click Save Check-In Policy.
5. Register the affected reservation again.
6. Check Opera to confirm the eligible guest moved to the selected arrangement.

Existing checkpoints

If a previous conversion is unfinished, turning this option off does not accept the partial change. Restore the setting used by that conversion, then retry or ask support to review it.

A Returning Guest Creates a Duplicate Profile

What you see: A returning additional guest receives a new Opera profile.

Why this happens: Profile reuse is off, or AVA could not verify one unique match. An ambiguous result also needs a staff choice in two-device ACI. AVA treats only the exact passport codes PAS and PASSPORT as equivalent.

Fix:

1. Open Settings → Check-In → Check-In Policy.

2. Confirm the active PMS is Opera.

3. Find Guest registration.

4. Turn on Match and merge guest profiles.

5. Click Save Check-In Policy.

6. Check that the guest's name and identity document match Opera's existing profile.

7. Retry the additional-guest registration.

   ✓ AVA reuses the existing profile only when the identity match is verified.

Opera passport codes

Opera may store a passport as PAS, while AVA confirms PASSPORT. These exact codes match during profile reuse. Other document codes still require an exact match.

Two-device ACI review

On the staff device, select Review profile for one candidate or Review N profiles for several candidates. Compare the candidate details, then select the profile or Create new. Select Retry when the guest row shows a failed search. Registration uses the saved choice without repeating the profile search.

Merge Verified Duplicate Opera Profiles

Use this workflow when Opera already contains two to five verified profiles for the same guest. The merge is available only when your rollout enables both Opera profile reuse and guarded profile merges.

1. Open the duplicate-profile review in Assisted Check-In.

2. Select two to five verified duplicate profiles.

3. Choose the profile that should remain as the Survivor.

4. Review the fresh Opera preview.

5. Confirm the merge only when the profile details and survivor are correct.

   ✓ AVA completes the merge only after Opera confirms the survivor and removes the retired profiles. ✓ Reservations, dates, occupancy, and status stay attached to the correct reservation.

Merging is permanent

Do not merge profiles until you confirm the guest identity and survivor. Retired profile IDs cannot be reused after a completed merge.

Why AVA may block a merge

AVA blocks the merge when names, unmasked documents, birth dates, or nationalities do not match. It also blocks changed profile contents, ambiguous candidates, and incomplete Opera responses.

An empty profile review needs a decision

What you see: The review opens, but no Opera profiles are available to select.

Fix:

1. Select Retry lookup to refresh the empty result.

2. Wait for the retry cooldown if AVA temporarily disables the button.

3. Open the review again if the result remains empty.

4. Select Create a new profile only after checking that no existing profile is correct.

5. Continue registration after AVA shows your decision on the guest row.

   ✓ AVA does not select a profile or create one automatically.

Your saved signature remains available after a failed profile lookup. An explicit choice remains during receipt renewal when the identity is unchanged. If the chosen profile becomes unavailable, AVA asks for a new decision. The choice becomes fixed when registration starts.

Do not choose from uncertain results

If several profiles match, review the candidates in AVA. Do not rely on a masked document suffix alone.

The duplicate-profile merge is unavailable

What you see: The merge action does not appear during duplicate-profile review.

Why this happens: Guarded merges are off, profile reuse is off, or Opera did not report the merge capability.

Fix:

1. Confirm the active PMS is Opera.

2. Confirm Match and merge guest profiles is enabled.

3. Ask your Vouch administrator to confirm guarded profile merges are enabled for the property.

4. Refresh the guest review and compare the candidates again.

   ✓ The merge action appears only when the rollout and property settings allow it.

Opera blocks or leaves a profile merge uncertain

What you see: AVA blocks the merge, shows an uncertain result, or reports that support must review it.

Why this happens: Opera may reject changed profile details, return incomplete verification data, or leave the write outcome unknown.

Fix:

1. Do not repeat the merge immediately.

2. Open the affected profiles in Opera and check which profile remains active.

3. Record the survivor, retired profile IDs, reservation numbers, and message shown in AVA.

4. Contact Vouch support for reconciliation.

   ✓ AVA keeps uncertain operations blocked until support confirms the Opera state.

An Opera sharer conversion is blocked by routing

What you see: An eligible-looking sharer with zero adults and children does not convert to an accompanying guest.

Why this happens: AVA allows only room routing that points every destination to the retained main reservation. Folio or comp routing, another reservation destination, and unsupported routing structures are not eligible.

Fix:

1. Open the sharer and main reservation in Opera.

2. Review every outgoing routing destination on the sharer.

3. Remove unsupported routing or route all charges to the retained main reservation.

4. Refresh the reservation in AVA and register the guest again.

   ✓ AVA rechecks routing before cancelling the old sharer reservation.

Room attachment is blocked for an Opera sharer

What you see: Room attachment stops after guest synchronization, or Opera shows an attachment error.

Why this happens: AVA could not verify the linked sharer, reservation identity, or primary guest profile. AVA stops instead of creating an accompanying profile or rewriting the main guest list.

Fix:

1. Open the main reservation and linked sharer in Opera.

2. Confirm the share link points to the same reservation family.

3. Confirm the sharer has a primary guest profile.

4. Refresh the reservation in AVA.

5. Retry room attachment.

   ✓ AVA attaches the room after Opera confirms the requested placement.

Existing duplicates are not repaired

This protection blocks new duplicate relationships. It does not remove duplicate profiles or correct adult and child occupancy counts already stored in Opera. Ask support to review existing duplicates before changing the guest placement setting.

Registration remains pending after a guest conversion

What you see: Registration does not complete after an existing guest conversion. The guest's documents are not delivered to Opera yet.

Why this happens: AVA waits for Opera to confirm the new guest placement. This prevents documents from being sent to an old or incorrect guest profile.

Fix:

1. Wait for Opera to finish the reservation update.

2. Refresh the reservation in AVA.

3. Retry registration when Opera shows the confirmed guest placement.

4. Check the guest's profile or reservation attachments in Opera.

   ✓ AVA delivers documents only after the confirmed Opera identifiers are saved.

Do not use the old Opera profile

Do not upload documents manually to the previous profile while registration is pending. Ask reception to review the reservation in Opera if the pending state continues.

Completed conversions are not reversed

Turning the checkbox off prevents future conversions. It does not restore relationships already converted in Opera.

OCIM fails as soon as you save

What you see: AVA rejects the connection right away when you choose OCIM.

Fix:

1. Ask Oracle for the correct enterpriseId.
2. Re-enter the OCIM credentials in AVA.
3. Save again.
4. If it still fails, confirm the client ID and client secret with Oracle.

No Reservations Appearing

1. Wait 15-30 minutes for initial sync
2. Verify OHIP user permissions in Opera
3. Check that reservations exist in Opera
4. Contact support with error logs

Opera compliance report values are masked

What you see: A TM30 or RR4 report omits an Opera passport number or birth date.

Fix:

1. Ask the Opera administrator to enable Module Level Access Control.
2. Ask them to grant the AVA OHIP client Sensitive Data Access.
3. Confirm the permissions apply to the correct Opera hotel.
4. Generate the report again after the permissions update.

AVA excludes masked passport values and the 1800-01-01 birth-date placeholder.

Checkout completes, but the Opera report misses the special code

What you see: AVA completes checkout, but the configured checkout special code is missing in Opera.

Why this happens: The optional Opera update can fail after checkout. AVA retries transient OHIP errors once.

Fix:

1. Wait briefly, then refresh the reservation in Opera.
2. Confirm the Specials code for check-out is saved in Settings → Check-In.
3. Check the Opera reservation again.
4. Contact support if the code remains missing.

Checkout is not blocked

A failed optional special-code update does not undo or block checkout. AVA does not retry non-transient errors.

Extras remain payable after an accommodation waiver

What you see: AVA shows a positive balance after room-package rows are waived.

Pre-arrival Opera rate tax

AVA treats projected Opera rate-info room charges and their tax as one room-package amount. A matching rate-code waiver should not leave projected room-rate tax payable. Only separately posted extras and their taxes should remain collectible.

Fix:

1. Review the balance and extra GST in Opera.
2. Confirm the remaining charges are correct.
3. Refresh the reservation in AVA after Opera finishes syncing.
4. Select Pay when the positive balance matches Opera's outstanding balance.
5. If Opera reports zero, refresh AVA and confirm the balance is zero.

Opera folio data is incomplete

What you see: AVA cannot confirm the balance after an Opera folio update.

Fix:

1. Confirm that Opera returned the guest's primary folio window.
2. Check that the folio window includes a balance or usable postings.
3. Wait up to five seconds for a recent external Opera change to appear.
4. Refresh the reservation in AVA.
5. Wait for Opera to finish updating the folio.
6. Contact your front desk or support team if the balance stays unconfirmed.

ETA or expected departure time does not update

What you see: The reservation still shows the old arrival or departure time.

Fix:

1. Open the reservation in Opera.
2. If the guest is a sharer, check the sharer's own reservation.
3. If the field is visible only to the main guest, check the canonical main guest's value.
4. Confirm the expected time is saved on the correct reservation.
5. Refresh Operations View after the update syncs.
6. If the time came from a guest form, confirm the matching time field was enabled.
7. If it still does not appear, check the Opera connection and retry after a few minutes.

Sharer times stay on the sharer reservation

AVA does not copy a sharer's own expected times onto the main reservation. Main-only fields can provide the sharer's missing value from the canonical main guest. This keeps each guest's arrival and departure details on the correct Opera stay.

A multi-room room card looks empty

What you see: A room card opens, but the main guest is missing.

Fix:

1. Confirm you loaded the reservation by confirmation number.
2. Refresh the check-in screen and open the room again.
3. If the guest is still missing, contact support with the confirmation number and arrival date.

An Opera sharer appears as a second room

What you see: One Opera booking appears as two room results in AVA.

Why this happens: Opera can return a main reservation and a linked sharer for one physical room.

New Self Check-In lookups resolve a share-only sharer confirmation to the host reservation. AVA identifies the host from the linked reservation's role, rate plan, and adult count before using numeric reservation IDs as a fallback. This preserves the original host when Opera assigns a newly created zero-adult sharer a lower ID. Records created before this behavior changed are not repaired automatically.

AVA groups redundant zero-occupancy sharers into the room with the complete guest information. Records with guest progress, payment, billing, or check-in state remain visible.

Fix:

1. Refresh the reservation in AVA.

2. Confirm the duplicate records use the same physical room and stay dates in Opera.

3. Check both records for guest progress, payment, billing, or check-in activity.

4. Continue from the room result that contains the complete guest information.

5. Contact support if two room results remain without independent activity.

   ✓ A redundant Opera sharer should appear within one physical room result.

A departure-day room shows the wrong status badge

What you see: One room shows Checked In, while another room in the same departing Opera booking shows Due Out.

Why this happens: Opera can return In House as the raw reservation status and Due Out as its computed departure status. AVA uses the computed departure status for occupied room cards, while preserving explicit room states.

Fix:

1. Refresh the reservation in AVA.

2. Confirm the guest's departure date is today in Opera.

3. Confirm each occupied room belongs to the same Opera booking.

4. If one room still shows Checked In, contact support with the confirmation number and a screenshot.

   ✓ All occupied rooms due to depart today should show Due Out consistently.

Genuine two-room bookings remain separate

AVA does not combine reservations assigned to different physical rooms or different share groups.

Opera groups the wrong rooms

What you see: A multi-room lookup includes an unrelated room, or a linked room is missing.

Why this happens: Native grouping uses Opera's linked family, SiteMinder component reference, or eligible CRS co-booking data. AVA does not merge records only because they share a profile, arrival date, or external booking ID. Cancelled, no-show, checked-out, pseudo-room, and non-overlapping records are excluded.

Fix:

1. Open every affected reservation in Opera.

2. Confirm the reservations belong to the same native linked family, SiteMinder component, or eligible CRS co-booking family.

3. Check that the stays overlap by at least one night.

4. For unlinked CRS rooms, confirm the same primary profile and arrival date.

5. Confirm the rooms were created within 10 seconds of the first room.

6. Confirm the room is not cancelled, no-show, checked out, or a pseudo-room.

7. Refresh the reservation in AVA after saving the Opera correction.

8. Contact support if the family still looks wrong.

   ✓ AVA should show one result for each eligible physical room.

SiteMinder matching

SiteMinder components without native Opera links use their exact component reference. Similar guest profiles, arrival dates, or booking references do not join unrelated bookings.

CRS bookings with different profiles stay separate

AVA does not group travellers who share a corporate CRS reference but have different primary guest profiles. It also keeps a burst of 10 or more rooms separate because it may be a group allotment.

A room does not appear in room changes

What you see: The room is missing from Allow move room.

Fix:

1. Check the reservation in Opera.
2. Remove the Do Not Move lock if the room should be movable.
3. Refresh the reservation in AVA.
4. Try the room change again.

An Opera component suite is not ready

What you see: Check-in stops because an Opera suite is not ready, or the room assignment is unavailable.

Why this happens: Opera represents the suite with linked component rooms. AVA checks every linked room before assigning the suite.

Fix:

1. Open the suite in Opera.
2. Check every component room for occupancy and readiness.
3. Resolve any occupied, dirty, or unavailable component room in Opera or Housekeeping.
4. Confirm the suite's room configuration lists the exact component members.
5. Return to AVA, click Refresh, and retry check-in.

If AVA selected the suite automatically but cannot verify its exact configuration, ask your Opera administrator to correct the mapping.

Ordinary rooms are unchanged

AVA uses the existing room-assignment path for ordinary rooms and unrelated automatically selected rooms.

Opera smart assignment skips a vacant room

What you see: A room appears vacant today, but Smart Room Assignment chooses another room.

Why this happens: The room is assigned to another reservation during this guest's stay window. AVA protects the other reservation, even when the room is physically vacant today. AVA checks all matching Opera room holders before marking a room available.

Fix:

1. Check the requested arrival and departure dates in AVA.

2. Open the room's overlapping reservation in Opera.

3. Confirm whether that reservation should keep the room.

4. Refresh the reservation in AVA and retry assignment.

5. Assign the room manually only after confirming the overlapping booking.

   ✓ Smart assignment selects rooms ready now and free for the full requested stay.

Temporary Opera record delays

If AVA cannot read overlapping Opera reservations, Opera still checks conflicts during assignment. AVA can retry another candidate after Opera rejects a conflicting room.

No higher room type is offered

What you see: The guest has no ready room, but AVA does not show a higher room type.

Why this happens: Upgrades appear only when the hotel's room-type policy allows them. The booked type must also lack a ready room for every night of the stay.

Fix:

1. Confirm the hotel uses Opera as its active PMS.

2. Check that the room-type upgrade policy is enabled for the hotel.

3. Confirm the booked room type appears in the hotel's ladder.

4. Check that a higher room has inventory and is ready for the full stay.

5. Refresh the reservation and open room assignment again.

   ✓ AVA shows eligible higher types nearest to the booked type.

No partial-stay upgrades

AVA does not offer a room that becomes unavailable on any night of the stay.

A room-type swap plan is rejected

What you see: AVA shows a possible room swap, but the plan cannot be completed.

Why this happens: Another booking may have changed, or one night's inventory no longer supports the plan. Opera may also protect a booking with Do Not Move or AVA's DNR room-commitment alert. If the swap card shows holder alerts, review them before choosing the plan.

Fix:

1. Check both reservations and their room types in Opera.

2. Confirm every destination room is ready for the complete stay.

3. Check for Out of Order, Out of Service, Do Not Move, the Room Committed for Kiosk Guest alert, or a hotel-configured blocking alert code.

4. Refresh AVA and request the room swap again.

5. Choose a free eligible room if the swap still fails.

   ✓ AVA executes only a plan that still fits current nightly inventory.

Opera refuses a required room move

What you see: A required room change fails with a message that the booking is locked or set to Do Not Move.

Why this happens: Opera protects the booking's current room from required changes. AVA keeps the current room and does not claim that the requested move succeeded.

Fix:

1. Open the reservation in Opera.

2. Confirm whether Do Not Move is still required.

3. Remove the lock only if the room should be movable.

4. Refresh the reservation in AVA.

5. Retry the room move.

   ✓ AVA moves the booking only after Opera confirms the requested room.

Automatic assignments

Smart assignment and check-in auto-assignment keep a locked booking in its current room. They do not silently override Do Not Move.

A room swap is refused for a family or shared room

What you see: AVA refuses a room selected during a swap.

Why this happens: The room is held by another reservation in the guest's Opera family, or by multiple reservations sharing it.

AVA protects the current holder. It also prevents a swap from moving one share partner away.

Fix:

1. Check the selected room's reservation holders in Opera.

2. If the room belongs to the guest's family, select another room.

3. If two reservations share the room, keep the shared room unchanged.

4. Refresh the reservation list in AVA.

5. Choose a room with one eligible holder, or use a free room.

   ✓ AVA offers only rooms that the swap can safely move.

Security Best Practices

• 🔒 Store credentials securely (they're encrypted in AVA)
• 🔒 Use OCIM when possible for better security
• 🔒 Keep enterpriseId with the rest of your OCIM credentials
• 🔒 Rotate client secrets periodically
• 🔒 Limit OHIP user permissions to minimum required

Getting OHIP Credentials

If you don't have credentials:

1. Contact Oracle Hospitality Support or your Opera system administrator
2. Request OHIP API access for AVA integration
3. They will provide:
   • OHIP Host Name
   • Application Key
   • Client ID and Secret
   • Hotel ID
   • enterpriseId for OCIM
4. Document received credentials securely

A later-arriving sharer is unresolved

What you see: The main guest is already in-house, but a later-arriving sharer shows "Guest reservation membership is unresolved".

Why this happens: Opera may stop listing the future sharer after the main guest checks in. AVA can recover the sharer when its own reservation links back to the main reservation. The stay must also remain active.

Fix:

1. Confirm the main guest is in-house in Opera.

2. Open the sharer's own reservation in Opera.

3. Confirm it links to the same main reservation and is not cancelled, no-show, or checked out.

4. Refresh the reservation in AVA.

5. Retry the arrival or room-access action once.

   ✓ AVA should resolve the sharer and continue check-in or keycard delivery.

If the error remains, contact support with both confirmation numbers and the arrival date.

Still Stuck?

Contact success@vouch-technologies.com if:

• ❌ The OCIM connection still fails after you add enterpriseId
• ❌ Reservations do not appear after the first sync window
• ❌ Oracle says the credentials are valid, but AVA still rejects them

Include:

• Screenshot of the error
• Your Opera identity management mode
• Time the problem started
• Steps you already tried

Related Guides

• PMS Connection
• PMS Connection Errors
• Sync Issues