Your Opera integration will allow you to post your payments and Spa Revenue to Opera in real time through the FIAS interface.
You can also charge spa treatments to guest rooms and individual PF accounts.
To integrate Trybe with Opera you’ll need to firstly contact your Opera account manager requesting an engineer's time to complete the configuration work on the Oracle side.
Please note that Opera tend to have a 4 week lead time with booking in their engineers. You will need 4 hours of an engineer's time to complete the configuration. Please make sure that when you get a date and time from Oracle to check with your Trybe account manager as we will also need to book in an engineer's time.
Once we have a date confirmed for the integration, you will need to set up your Revenue Centres and Payment types in Trybe. This will then help you with completing the split sheet:
When you've completed those sections, you'll be able to complete the split table. To do this, head to Integrations > Manage Integrations > Opera > and select ‘Split table’ to download a spreadsheet to complete and send on to Opera.
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. You will notice on the spreadsheet there will be one extra Revenue Centre and two extra Payment Names. These will need to be created in your Opera system accordingly for us to map too. See the section on ‘Integration Behaviour’ for details on what these will be used for. When setting these up in Opera we would suggest adding Trybe to the name i.e. ‘Trybe - Deposit’
The Split Table will need to be completed and sent back to your Opera account manager at least 2 days prior to the configuration date.
Once all is set up and the transaction codes have been mapped, when an order is Checked out in Trybe the revenue will go to the correct revenue centre/ transaction codes in Opera.
How will it work?
When the integration is working, there’s two jobs it will run:
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.
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.
What should you expect to see in Opera?
Payments - if payments have been set up with a Payment Kind of ‘Prepayments’ - see guide - you should expect the below behaviour:
A customer makes a booking (this can be for today or a date in the future) but they make the payment today i.e. for £50. In Opera you should see two things happen:
£50 will post to the Deposit Payment Method Selector that relates to the Payment Type i.e. Cash / Card etc. If the payment was made using Trybe Payment (Stripe or Adyen) this will post to the ‘Deposit - Non Revenue’ revenue centre we created (as per screenshot above)
You will also see a £50 payment posted to the ‘Deposit’ PF account.
If the payment type is not set to the Payment Kind of 'Prepayments' you should expect to see this behaviour on the revenue date once the Order has been checked out
Revenue - Then on the date the Order is happening/Revenue Date, your Operational team will ‘Check Out’ the Order once the customer has left and no further changes need to be made to the Order. In Opera you will see two things happen:
-£50 (a negative amount) will be posted to the ‘Deposit Redemption’ PF account
£50 of revenue will then be allocated to the relevant Transaction Codes that relate to the Revenue Centres the items in the Order have been configured to i.e. £50 to Spa Treatments. This is all configured within each of your Offering settings for example - see guide.
Manage your Opera Integration
To manage your Opera config head to Settings > Manage integrations > Opera > Configure.
Relay status:
Ok - if this is the status the integration is all working fine
Relay down - if this is the status you will need to contact your managed IT company to restart the relay
Select 'See diagnostics' to see:
Last message sent
Last message acknowledged
Last success
Last failure
Revenue centre settings
Here you can match up Trybe's revenue centres with the sales outlets in the FIAS interface configuration. Trybe will post to corresponding transaction codes mapped to these sales outlets when orders are checked out. To do this select the three dots > update mapping > enter in the Sales outlet > Update.
Payment Type Settings
Here you can match up Trybe's payment types with selectors configured in the Opera Fias Interface. Trybe will post the transaction codes mapped to these selectors when orders are checked out. If a payment type is configured to be a prepayment, Trybe will post this in real time to the deposit payment method selector you configure below. To do this select the three dots > update mapping > enter in the Selector > Update.
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.
Post offline membership payments - When enabled, Trybe will post recorded offline payments for memberships to the PMS. Payments will use the payment code from the mapping above and the analysis code mapped to the Membership fee revenue centre.
Voucher postings
Voucher revenues are tracked at four key points:
When a voucher is purchased the amount is added to ‘Vouchers’ revenue centre
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
On the day of the booking, the amount is moved from the ‘Vouchers’ revenue centre to the revenue centre for the offering(s)
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