Skip to main content

Opera OHIP Integration

This Guide will provide assistance in connecting your Opera Cloud PMS to Trybe using an OHIP Integration.

Colin Newman avatar
Written by Colin Newman
Updated today

With our integration to Opera Cloud, we are now able to support connection using OHIP instead of the current FIAS integration! With OHIP, this removes the previously required Trybe Relay to establish connection and is considered a modern integration option.

This integration will still allow you to post payments and revenue in real time to your selected transaction codes and paymaster rooms.

In order to establish connection between the two systems, we can connect either using OCIM or SSD. You would need to obtain this information from either your managed IT Team or from your Oracle Account Manager.

Once we have a date confirmed for the integration, you will need to set up your Revenue Centres and Payment types in Trybe ahead of configuration. Once you have this information completed, you will then be able to fill out what is known as a split table which will look similar to the below.

This spreadsheet will contain the Revenue centres and Payment types shaded in the yellow columns and then you will need to fill out the pink columns accordingly with the Paymaster and Transaction codes set up in Opera.

How will it work?

When the integration is working, there’s two jobs it will run:

  1. Posting Payments - Payments can be posted on the date the payment is made or on the revenue date, the behaviour you want needs to be set up when the client creates the Payment Types - see guide on Payment Kind rules.

  2. Posting Revenue - Revenue is posted as soon as a user ‘Checked Out’ an Order. See this guide on the Check in and Check Out process for your Operational team. The revenue can only post to Opera to the date it was checked out. Therefore, if a user forgets to check out the order on the day the order took place and instead checks it out two days later the revenue will post to the date it is now being checked out, i.e. 2 days later than the Order happened. If this happens, the revenue will need to be moved in Opera manually. You can use your Daily Revenue report to check that all Orders have been posted to Opera in the ‘Posted to PMS’ section - see guide.

With the Opera OHIP integration, this only supports a deposit posting behaviour so you will need to have a deposit non-revenue transaction code and a deposit redemption paymaster room created.

Manage your Opera Integration

To manage your Opera config head to Settings > Integrations > Manage integrations > Opera > Configure.


Revenue centre settings

  • Here you can match up Trybe's revenue centres with the transaction codes found in the Opera Cloud interface configuration. Trybe will post to corresponding transaction codes when orders are checked out.

Payment Type settings

  • Here you can match up Trybe's payment types with paymaster rooms and payment method codes configured in the Opera Cloud interface. Trybe will post to the paymaster rooms when orders are checked out.

Integration behaviour

  • Post prepayments - When enabled, Trybe will post custom payments configured as prepayments. Successful payments will hit the deposit analysis code above in real time. When the associated orders are checked out, the negative amount will be posted to the redemption code configured above.

  • Reverse deposit on check out - When enabled, Trybe will post a negative amount to the payment code configued above for deposits.

Voucher postings

Voucher revenues are tracked at four key points:

  1. When a voucher is purchased the amount is added to ‘Vouchers’ revenue centre

  2. When a voucher is used to pay for an order the amount from 'Voucher redemption' revenue centre is taken and put it in the 'Vouchers' revenue centre

  3. On the day of the booking, the amount is moved from the ‘Vouchers’ revenue centre to the revenue centre for the offering(s)

  4. If an order is refunded we need to reverse the 'Voucher redemption' amount and also the amount sent to the offering revenue centre(s)

To handle these we use two main voucher revenue centres:

  • Vouchers -> when a voucher is purchased (point 1 above)

  • Voucher redemption -> when a voucher is used (point 2 above)

If a voucher is ever sold for an amount that's different from its value, then two further revenue centres are used:

  • Voucher difference to track the difference between the sale price and the value of the voucher at points 1 and 2 above

  • Voucher discount to track the 'discount' applied to a revenue centre as a result of using a voucher that cost less than its value at point 3 above

Did this answer your question?