1. User Guide
  2. Administration
  3. Financial Administration
  4. About Transaction Codes
  5. About Transaction Diversion

About Transaction Diversion

Prerequisites for Transaction Diversion

Transaction diversion is a process whereby postings against selected transaction codes can be automatically diverted to a pseudo room based on the membership type and level, or the VIP level associated with the reservation. Transaction diversion rules determine the conditions under which the posting will be diverted. For example, a transaction diversion rule could state that charges for Internet access are to be diverted to pseudo room 9020 for reservations that have a Platinum level Priority Club membership attached. Transaction diversion rules apply at the property level and are not applied to individual reservations.

You should be aware:

  • The transaction diversion rule is validated only on the initial posting of the transaction, not upon transfer / adjust / split / refresh / routing, etc.

  • When transaction diversion applies to a reservation, transaction diversion rules will be applied to postings before routing.

  • When generates (such as taxes) apply to a charge made to a reservation, and that charge is covered by transaction diversion, the generates will be diverted to the applicable pseudo room along with the charge to the main transaction code.

  • Transaction codes will display only revenue transaction codes excluding tax, package wrapper, package profit/loss and internal transaction codes. Routing codes will not be displayed here for selection.

  • It is not recommended that transaction codes that are defined for package elements be selected for transaction diversion rules. Nevertheless, if these transaction codes are included in a transaction diversion rule, and the package charge is posted to a reservation, the complete package charge is posted directly to the guest room. If you post a charge directly against the same transaction code, the posting will be diverted. However, where a package allowance applies to the package that includes the element having the diverted transaction code, no consumption against the allowance is recorded.

  • If for some reason the target pseudo room defined for a transaction diversion rule is not checked in at the time a qualifying posting is made, the posting will follow the normal process and be charged to the guest room. The Reference field on the Transaction Details screen will include a notation similar to the following: "Attempted trans. diversion (room number) not checked in." This notation will also appear on the guest's folio next to the charge that has been posted to the guest's room. If you prefer that the notation not appear on the folio, place the Reference notation inside square brackets. For example: [Attempted trans. diversion #9002 not checked in.]

  • A charge that has already been automatically diverted to a pseudo room can be transferred back to the guest room or any other room using normal charge transfer functionality.

  • Transaction diversion does not apply to passer-by postings because there is no reservation to which a membership or VIP level can be attached.

  • In the event there are routing instructions for a transaction code on the target room, the charge will be routed per normal routing functionality.

  • If at any point a transaction diversion rule is changed, existing postings per that rule are not modified, but all future postings will be affected.

  • All the transaction diversion rules must be a unique combination of VIP level or membership type/level, transaction code, and pseudo room.

When viewing the diverted posting on the target room's Billing screen, the Billing screen Reference field will contain details pertaining to the room number and guest name from which the charge was diverted.

If a transaction is eligible for diversion but is not diverted due to the target room not being checked in, the Reference field will contain details as such.

Note:

The sequence number of the rules determines the priority of which pseudo room the charge will be diverted to in the event there is a situation where the same transaction code is attached to a membership type or level and VIP code, and the reservation has this same membership type or level and VIP code. When the posting is made, OPERA Cloud will always validate against the diversion rules starting with the rule having sequence number 1 and continue to subsequent rules; whichever rule is satisfied first, and the posting will be diverted to the defined pseudo room for that rule, provided the pseudo room is checked in. If the pseudo room is not checked in, the charge remains on the original guest folio.

In case of a POS check that could possibly contain multiple transaction codes, each of the transaction codes needs to be validated separately for transaction diversion.

If there are multiple memberships attached to the reservation (for example, a loyalty and FF membership), and there are transaction diversion rules for both membership types for the same transaction code, then when posting, OPERA Cloud looks at the rule with the lowest sequence number (that is, the highest priority) and posts to the associated Posting Master (PM) room.

Parent topic: About Transaction Codes