Sync and Re-sync Utility for the V3.X Property Interface

The Interface includes a first time synchronize utility to deliver all allotments, profiles, reservations and stays. This ensures synchronized inventory as soon as the Interface is installed and the CRS has run the sync utility. A range of messages are created for every transaction that is downloaded and uploaded following the normal Interface messaging and transportation.

Prior to the installation of V3.x, if your hotel chain maintains double entries for all or part of the objects the Interface is uploading or downloading, only those objects that do not exist at both sides require a sync. For example, if rates are entered on both sides with the same rate code, you do not need to sync rates.

Items and Order to Sync

The Pre-Sync utility must be initiated from the property.

• Rates (both ways)*
• Restrictions (Yet, it is recommended that new restrictions be set up once the Interface is initiated.)
• Profiles (including central comments, if any, but this is not required)
• Allotments (upload only)
• Reservations (upload only)
• Inventory (Not Available at this time.)

Prior to Starting the Sync Process

The following items must be accomplished:

• Data on both sides must be clean.
• Interface must be turned off while cleaning the data on both sides; the trigger module in the PMS must also be turned off.

Screen Defaults:

• A solid box = the default when the main object box is checked.
• Dark check boxes should be checked by default.
• Inventory default from today + 1 year.

Items and Schedule for Synchronization

Checklist prior to Synchronization:

• Build package elements in both V6 and ORS
• Ensure that the Currency exchange rates for local currency is mapped correctly in OXI_HUB
• Ensure that the package department code is setup in ORS for the respective property
• Ensure that the Tax package elements are mapped correctly to the respective ORS Department code (Exclusive Room transaction, Inclusive Room transaction code)

Synchronization Process:

• Rate codes. [using F_UTIL]
• Profiles. [using V3 Profile sync tool]
• Allotments. [using F_UTIL]
• Reservations. [using V3 Reservation sync tool]
• Room Status - Out of Order. [using F_UTIL]
• Availability /Inventory. [using F_UTIL]
• Rate Availability/Restrictions. [using F_UTIL]

If allotments are checked, it is important that the following objects are synched first:

• Rates (Packages)

If reservations are checked, it is important that the following objects are synched first:

• Rates
• Allotments

Key Points to Remember when Using the Sync Utility

Rates

If all rate codes existing in the CRS are already manually entered in the PMS, the user should only have to sync from the PMS to the CRS. The suggested order of rates to be sync would be:

Convert all CRS rates to CIS rates using the utility on the sync screen.

CRS to PMS

• The rate code is key.
• Only downloads the CRS created rate codes.
• Ensure all CRS rate codes exist on the PMS.
• CRS products must exist at PMS before the sync process is started.

PMS to CRS

• The rate code is key.
• Inserts the PMS rate codes.
• Ignores the already existing CRS rate codes.
• PMS packages must exist in CRS before sync starts.

Restrictions

Note:  We do not recommend the synchronization of restrictions.

Profiles

The clean up of profiles before synchronization is very important. Again, during the clean up process on both sides the Interface must be turned off.

You need not sync profiles with all reservations and allotments, since the attached profiles will also be sent to the destination.

If you want to sync profiles, it should be started as stated below.

CRS to PMS

• The CRSNAME_ID in GAESTEST is key.
• The Interface receives a PMS name id back, so when the sync up is done it will not re-insert those profiles.

PMS to CRS

• The Name_ID is key.

Blocks

All allotments should be created on both sides manually. If the manually entered allotments on both sides have the exact same code they won't be inserted, as the Interface should recognize the existence of allotments during the upload or download process. All allotments created in the CRS MUST exist in PMS. Only allotments "open for pick up" should exist in CRS.

PMS to CRS:

• The allotment code is key.
• Since all groups exist in the PMS, we can assume that the most accurate information on the allotment exists in the PMS.

CRS to PMS (is not needed if the hotel has been consistent in entering allotments received from the PMS)

• The allotment code is key.
• Only downloads the allotments previously entered manually.
• Only inserts the allotments with a code previously not existed in PMS.

Reservations

In theory, all CRS reservations should exist in all PMS systems with the CRS confirmation number. Reservation sync should only be needed from the PMS to the CRS. It is currently recommended that you not sync the latest time ranges. Oracle recommends that you test the sync in small increments by trying a week first, then a month, six months and then the remaining period.

PMS to CRS:

• The CRS confirmation number is key.
• First 1 week.
• Then month-by-month for the next 3 months.
• Then the remaining time period.