This is a section describing what is required for the implementation of new POS interfaces. For existing interfaces please visit the detailed description of these interfaces. The implementation of using actual covers is optional for POS systems.
| # | Data element | Description | Mandatory / Optional | Comment |
|---|---|---|---|---|
| 1 | Property ID and/or name | Identification of the property (hotel, restaurant) | M | The import flow for a property is mostly set up per property. In this case the property identifier is specified in the flow. If a data set (file) includes data for multiple properties the property identifier needs to be part of the data set (file). |
| 2 | Department ID and/or name | Identification of the department within the property | M | This field is mandatory if the file contains more than one unit. |
| 3 | Date | Transaction date | M | |
| 4 | Account ID and/or name | Identification of the account | M | This field is mandatory if the file contains more than one unit. |
| 5 | MealPeriod ID and/or name | Identification of the meal period | M | Required when using covers. If this field is not available in the source system, the records can be grouped based on time of the day. |
| 6 | Covers | Number of covers/guests | M | Required when using covers. |
| 7 | Revenue | Revenue without VAT and other authority charge rates | M | If the revenue includes VAT this can be corrected in the mapping. Only one percentage can be used in the mapping to subtract additional charges.Note: Usually, revenue registered in POS (e.g. Micros) is automatically fed to PMS (Opera). However, adjustments (at higher level) are often made in PMS without these changes being fed back to POS. Therefore, it is common that revenue in PMS is used to update in PMI – not revenue from Micros. |
Please note: The names of data elements are provided in source system (native) codes. These native codes are translated into PMI names in PMI.