Skip to main content

Dayend Close - Exports

Setup > Configuration > Guest Ledger > Dayend Close Options > Exports tab

Nightly Export to XML (Frequent Stay Programs and Custom Revenue Tracking Databases) roomMaster can export an XML document to be imported in to a frequent stay application, provided it can read the XML format. The format includes the folio number, guest name, stay information, custom (extrafield) information, guest gender, birthdate, room type, membership/loyalty number and revenue posted to the folio. Once the document is created, it can optionally be sent to a remote site via FTP (file transfer protocol). The document follows OTA_HotelStayInfoNotifRQ (Open Travel Alliance) standard document for sending "Hotel Stay Information" and Reservation Confirmations.

Run XML Export - Check this box to run the export as one of the last steps of the night audit. Information will generate for all Checked Out folios. It is important that the remote application using the file understands that the folio can be transmitted multiple times, if it is brought back from history for example on another day. The information would be the 'new' information and the application must disregard the information it has previously received and use the new information as updated information. Another option would be to compare the information from the last transmission of that folio and only update the difference.

File Name - Enter the file name of the XML document. The system will append YYYYMMDD.XML to the file name. If the File Prefix is "MyPointProgram" then the end result would be "FS_MyPointProgram20110501.xml" for example.

HotelCode - Enter the SiteID/Hotel Code which will be embedded in the XML export to uniquely identify this site. This code would be given to you by the vendor who is expecting the export file.

Select only folios when Custom Field 1 exists - Check this box to only include folios which have an extra field 1 not equal to blank. This could be if you choose to store your frequent flyer or guest number in this field and only want to select folios that are part of this program.

Transmission - Once the file is created, it can be transmitted to a remote site. If the transmission fails, the file is kept in the directory until the audit is performed again on the next night. It is then transmitted again along with the new file. The files will continue to try to be transmitted each night until they have been successfully transmitted. Once successfully transmitted, they will be deleted.

  • FTP transmissions: This is the method preferred. If the file is successfully transmitted, it will be deleted locally from your roomMaster directory

  • HTTP Post Data transmission: The file is transmitted via an HTTP Post Method. Once the file is posted, the remote server must respond with an XML response with /Success. If the response does not say "/Success", the file is not deleted and will be continually transmitted each night. The Username and Password are ignored.

Sample HTTP Success Response: <FrequentStay></Success></FrequentStay> Sample HTTP UnSuccess Response: <FrequentStay><Error>Invalid Request - Not Permitted</Error></FrequentStay>

See Internet FTP Settings for detailed information on FTP settings. For standard connections, the default port number is 21. For secure connections, the default port number is 990.

Technical Documentation

In the OTA_HotelStayInfoNotifRQ document, the TransactionIdentifier field contains the Audit Date.

Revenue Figures are as follows:

RevenueCategoryCode 9 is Room Revenue

RevenueCategoryCode 12 is Taxes

RevenueCategoryCode 1 is MiniBar (Beverage)

RevenueCategoryCode 3 is Food and Beverage

RevenueCategoryCode 5 is Laundry

RevenueCategoryCode 7 is Parking

RevenueCategoryCode 11 is Spa

RevenueCategoryCode 14 is Telephone

RevenueCategoryCode 6 is other revenue including Adjustments (+ and -)

RevenueCategoryCode 17 is total revenue (not including Taxes)

RevenueCategoryCode 99 is Room Revenue inclusive of any VAT and GST.

Programmer Note: Entire file information can be sent twice, such as an audit being redone a day later because of disaster recovery or a glitch in some area. It is important the system only processes one unique file (defined as "HotelCode and Audit Date" found in the TransactionIdentifier) and view any other file as a duplicate. The Sequence Number is used to determine which file is a newer version of the file if two files were to be received, however, it cannot be used as the unique identifier.

IMPORTANT: All folios with a Checked Out status will be transmitted including any modified folios that could have occurred that day. It is important that when reading this file, that the programmer look for a match of HotelCode and UniqueID Type 14 which is the Guest Folio Number.

<UniqueID Type="14" ID="10" ID_Context="Folio"/>

If a match occurs, it means the folio has been transmitted before and an UPDATE to the figures should be done versus adding to the figures. Postings to a frequent stay system should be based on your own identifier of a guest (email, Profile ID, etc.) and the unique posting of a HotelCode and UniqueID=14. The hotel could pull back a guest bill a week later or even a month later, make modifications to it (ie: adjustments) and then resend the frequent stay information for that particular folio. Do not just add all information coming in constantly to a summary bucket. Keep a tally of each folio as it comes in to know if adjustments need to be made.

Also, another indication of a change would be in the ResStatus field:

  • Initiate = First time data for this folio is sent
  • Modify = Data has already been sent before, modify the totals for this record
  • No-show = Folio was canceled and charged as a No-show (usually first night Room and Tax)

Qantas Frequent Flyer Points Program Quanta's Airways Limited (r) offers Frequent Flyer points to members who stay at certain hotels. If your hotel participates in this program, you must accept the Quanta's Frequent Flyer membership number (which starts with a Q) and record it on the guest folio in to Extrafield2. The only place this is accepted is by placing it on EXTRAFIELD2 in the User Field Setup. Information is then collected during each dayend close and written out to a file. (the default file name is fflyer.txt)