Fia

MICROS-Fidelio Interface Application Specification V1.
50
FIDELIO TECHNOLOGIES, INC.
Interface Application Specification

In this document
Purpose ............................................................................................................... 3
History ................................................................................................................ 4
General Transmission Layer Considerations...................................................... 5
Data Bytes Format ......................................................................................... 5
Data Types ..................................................................................................... 5
Other Notes .................................................................................................... 6
Overview ............................................................................................................ 6
Field Types ......................................................................................................... 7
Record ID Types ............................................................................................ 8
Communications and Link Control........................................................... 8
LS - Link Start.................................................................................... 8
LA - Link Alive (Sanity check) .......................................................... 8
LE - Link End..................................................................................... 8
LD - Link Description......................................................................... 9
LR - Link Record................................................................................ 9
Database Resynchronization ................................................................... 12
DR - Database Resync request.......................................................... 12
DS - Database Resync start............................................................... 12
DE - Database Resync end................................................................ 12
Night Audit.............................................................................................. 13
NS - Night Audit Start ...................................................................... 13
NE - Night Audit End ....................................................................... 13
Guest Data............................................................................................... 14
GI - Guest Check-in......................................................................... 14
GO - Guest Check-out....................................................................... 14
GC - Guest data change..................................................................... 14
Extended Guest Data............................................................................... 18
XL - Guest message text and other details online.......................... 18
XM - Guest message request ............................................................. 18
XT - Guest message text and other details........................................ 18
XD - Guest message delete ............................................................... 18
XR - Guest bill request...................................................................... 18
XI - Guest bill item .......................................................................... 18
XB - Guest bill balance ..................................................................... 18
XO - Guest bill detail online .......................................................... 18
XC - Remote Check-out request ....................................................... 18
Locators................................................................................................... 23
LO - Locator On................................................................................ 23
LF - Locator Off............................................................................... 23
LP - Locator Retrieve....................................................................... 23
MICROS-Fidelio January 2001
MICROS-Fidelio Interface Application Specification V1.50
Room Data .............................................................................................. 25

RE - Room equipment status ............................................................ 25
RA - Assign room equipment ........................................................... 25
Wakeup ................................................................................................... 28
WR - Wakeup request ........................................................................ 28
WA - Wakeup answer ........................................................................ 28
WC - Wakeup clear............................................................................ 28
Point of Sale & Other Charge Systems ................................................... 29
PS - Posting (simple)........................................................................ 29
PR - Posting Request ........................................................................ 29
PL - Posting List............................................................................... 29
PA - Posting Answer ........................................................................ 29
Key Services............................................................................................ 38
KR - Key request............................................................................... 38
KD - Key delete................................................................................. 38
KA - Key answer............................................................................... 38
EFT.......................................................................................................... 41
$U - Card type/usage request/answer ............................................... 41
$A - Authorization request/answer................................................... 41
$B - Batch Begin .............................................................................. 41
$S - Settlement request/answer........................................................ 41
$Z - Batch End ................................................................................. 41
$E - Batch Entered ........................................................................... 41
$L - Blacklist check/answer (not currently supported).................... 41
$H - Hotel/Courtesy card (not currently supported)......................... 41
Appendix A - FAQ ........................................................................................... 47
Appendix B - Tables......................................................................................... 50
IF Interface Types .......................................................................... 50
AS Answer Statuses......................................................................... 50
GL Guest Languages........................................................................ 50
KT Key Types ................................................................................ 51
PT Posting Types ........................................................................... 51
CS Class of Service (COS) ............................................................ 51
MR, VR, TV, SM Guest Rights ................................................ 51
RS Room Maid Statuses ................................................................ 52
$C EFT Card Usage ....................................................................... 52
RT EFT Authorization & Settlement Request Types..................... 52
Appendix C - Field ID and Codes Table .......................................................... 53
Purpose
The purpose of this document is to set a standard for application record formats
and data flows to be used for data communications between a Property
Management System (PMS) and other hotel computer systems. It gives a general
description of record formats and data flow requirements, and covers specifics for
Record Types, Field Types, and Field usage. This document is intended for
distribution to all vendors and developers of hotel software systems. The data
contained herein is public information and is published for public use. However, if
you have received this copy from a firm other than MICROS-Fidelio, you may
want to contact us to insure that you have the most recent version of this
document; MICROS-Fidelio reserves the right to modify or correct this
specification.
For information regarding the low-level protocol specification and
recommendations used by MICROS-Fidelio, please refer to the MICROS-Fidelio
Interface Protocol Specification. For corrections, or copies of the current
specifications, please contact your local MICROS-Fidelio office or the applicable
MICROS-Fidelio Regional Office:
Micros Systems, Inc.
7031 Columbia Gateway Drive
Columbia, MD 21046-2289
U.S.A.
Tel: +1 443-285-8000
Fax: +1 443-285-6505
Fidelio Technologies
Micros-Fidelio Hotel Systems Division
Interface Product Management
Leandro N. Alem 668 8 Piso A
Capital Federal, CP 1001
Buenos Aires, Argentina
Tel: +541 14 312 8173
Fax: +541 14 312 8197
Micros-Fidelio GmbH & Co. KG

Regional Operations Center
Euro Center
Europadamm 2 - 6
41460 Neuss, Germany
Tel: +49 2131 137-0
Fax: +49 2131 137-702
Micros Fidelio Asia Pacific

Interface Product Manager
Suite 5.01 Menara Choy Fook On
Jalan Yong Shook Lin
46050 Petaling Jaya
Selangor Darul Ehsan
Malaysia
Tel: +603 7954 6188
Fax: +603 7954 7188
Information in this document is subject to change without notice.

MICROS-Fidelio makes no warranty of any kind with regard to this material, including but not
limited to the implied warranties of marketability and fitness for a particular purpose.
MICROS-Fidelio shall not be liable for errors contained herein or for incidental or consequential
damages in connection with the furnishing, performance, or use of this material.
Copyright 2000 MICROS-Fidelio. All Rights Reserved.
History
15 Sep 1994
31 Oct 1994
8 Nov 1994
20 Dec 1994
4 Jul 1995
2 Jan 1995
29 Mar 1996
30 Apr 1996
1 Aug 1996
26 Mar 1997
1 Oct 1998
9 Jan 1998
Jan 2001
Version 1.00 first draft, overview, Record and Field Types

Version 1.01 start of field explanations and tables, new fields for
guest rights
Version 1.02 varying corrections and additions to tables, all
revisions between last and current versions now
marked
Version 1.03a rough draft, revisions marked
Version 1.04 clarification of Link Start sequence, add fields for
Voice Mail, new language codes, clean up examples
(all changes since V1.02 marked)
Version 1.05 repaginate
Version 1.06 import into Word 7.0
Version 1.07 change Key Options functions (currently unused).
Enhanced EFT records and field types. All changes
from V1.06 marked.
Version 1.08 added Virtual/Phantom Extension examples,
changes for terminology, changes from V1.07
marked
Version 1.09 added Locator records, cleaned up examples, all
changes since V1.07 still marked
Version 1.10 major clean-up/reformatting, added more
examples, more tables, started FAQ, only
significant changes from 1.08/1.09 marked
Version 1.11 add PP for messages to be sent to printers, A0-A9
for assignable fields,
Version 1.50 added tables (available fields), reformatted
document, made further corrections and added more
examples.
General Transmission Layer Considerations

Data Bytes Format
Records are composed of data bytes and link control bytes. The data portion of a
record should not contain any bytes normally reserved for link control (Hex 00
through Hex 1F, and Hex 7F). The control characters from Hex 1C through Hex
1F (FS, US, RS) are used by some systems as field separators; for systems using
formatted text (guest messages or folios), it is also acceptable to embed such
characters as Hex 0A, Hex 0D (LF, CR).
When this is the case, these characters are considered as part of the normal data
stream and do not require a preceding escape character (DLE - Hex 10); they are
not then available for use as link control characters. For most transmissions, the
rest of the standard ASCII character set is sufficient (Hex 20 through Hex 7E);
however, in order to support multiple alphabets, extended ASCII (Hex 80 - Hex
FF) may be used. Data is passed in an unpacked format; it should not be packed in
nibblized, BCD, or other formats. This is to simplify installation and support.
This specification uses as a field separator the bar character ('|' - Hex 7C), the field
separator can be changed (see Link Description record). By using a field
separator, it is not necessary to pad fields to their maximum size. The PMS sends
all fields without padding, and when fields transmitted from the other system
reference data configured in the PMS (i.e. room numbers, guest numbers, etc.)
they should be sent without padding. If padding is done, numeric fields should be
right justified, with leading zeros ('0') except in the case of negative amounts when
the leading character is the minus sign ('-'); Alphanumeric fields are left justified
with trailing spaces.
Data Types
In general, fields are either numeric (decimal digits '0' - '9'), monetary (this
includes the decimal numeric characters, plus '-', and '.' as necessary), or alpha (all
alphabetic letters). Some fields require some combination of these types.
A - Alpha characters, includes all characters from 'A' - 'Z', 'a' - 'z', any common
punctuation characters such as periods ('.'), commas (','), and dashes ('-'), and any
characters from the extended ASCII character sets necessary to support local
alphabets
N - Numeric characters, includes '0' - '9', the minus sign ('-') as leading character,
and where necessary 'A' - 'F' and 'a' - 'f' as hex characters. These fields always
reflect integer values (no decimal positions).
M - Monetary characters, includes all numeric characters and period (.) as
decimal indicators where necessary. The PMS can handle monetary fields with an
implied decimal point.
AN - Alphanumeric characters, all characters included above as Alpha or Numeric
characters.
ANS - All characters, the entire printable ASCII character set

D - Date, numeric characters, formatted as YYMMDD
T - Time, numeric characters, formatted as HHMMSS

Note: As the PMS sends fields without padding, leading zeroes or spaces on
alphanumeric fields are considered significant data (i.e. if a room number contains
a leading zero, this digit is regarded as part of the room number).
Other Notes
Low-level ACK/NAK responses are required; application level responses are only
necessary where appropriate (only applies to asynchronous serial connections). It
is not necessary for the receiving system to send an application level response that
a particular action has been performed; in the PMS's case, this type of response is
sent only when the other system requires them. When receiving them, it carries
out meaningful processing on them only when they require further action.
In most cases where records are rejected at the application level there shall be an
application level response, for example, a posting record that is received correctly
but contains bad/invalid data (e.g. unknown room number, the application
response would contain |ASNG|CTINVALID ROOM|).
Using a NAK causes immediate retransmission of the same record with only lowlevel logging of communication errors.
Overview
This specification is designed to allow for future expansion, either of new records
or new fields, by using records that are not of fixed length or content. Neither are
the fields of fixed position (with the exception of the Record ID field). This means
that as more information becomes available or no longer necessary, the interface
can add or omit fields by configuration.
In most cases, fields are not mandatory; when required, they are noted: tables
listing available Field IDs will have mandatory fields in bold typeface.
Mandatory fields must be defined in the Link Record for that Record ID.
The PMS works by parsing incoming records according to the Record ID field. If
fields are sent containing data that the PMS does not require or use for that Record
Type, the data will be parsed over and ignored.
Records should always contain all the data necessary to perform a function.
However, for many functions, such as Check-in, defaults for unspecified statuses
should be used. For example, a Check-in record sent to a PBX should contain the
room number, any necessary guest information and default to opening the phone
line. It is not necessary to specify that the line should be opened, nor is it
necessary to send separate records to support guest information at Check-in.
Field Types
Field Types are two-character IDs (ANS) included at the beginning of each field.
This allows the field to be easily identified. Fields have maximum sizes, but it is
not necessary to transmit the entire field size as all fields have a separation
character ('|' - 0x7C; this is the default - see section on Communications and Link
Control below). Even if there is no data for a field (i.e. the Record Type field), if
the field ID is included, it must have a separation character to indicate the presence
of a blank field.
Note: All examples are shown without low level protocol framing or response
characters. Fields listed in these examples are defined in Record ID Types below.
Please note that these are only examples; where fields are not mandatory, they are
included to indicate how this specification works, not to restrict the functionality
of your system. Field Types in the examples are in bold typeface to help identify
them. The symbol indicates this record is sent from the PMS, that the
record is sent to the PMS.
Example
GI|RN103|GNMr. Rogers|
GI - Check-in
RN - Room number: 103
GN - Guest Name: Mr. Rogers
As mentioned above there are in most cases only a few strict requirements as to
which fields must be included or allowed in any given record. Please note that
even though a field is requested, if it does not have a logical use within the context
of that Record Type, it might not appear in the actual records sent, or it may be
sent with no data (i.e. immediately followed by a field separator).
There are some fields that because of their original usage may have names or IDs
that do not indicate their full potential. For example, the KO field was originally
meant to be used for supplying a wider range of on-site configurable options for
Key Services. However, it can have other uses, such as providing more options for
Video Systems other than those available by using TV, VR, or SM.
Please note that the content of many Field Types is configurable within the PMS
(e.g. GN, GV etc.) and as a result may vary from site to site.
It is beyond the scope of this document to describe all the possible usages of the
fields listed below. Please contact your local MICROS-Fidelio office or the
applicable MICROS-Fidelio Regional Office if you have questions about specific
fields.
Record ID Types
The first field in all records is the Record ID. There is no data for this field; the
Record ID is followed immediately by the field separator character, Field Types
and relevant data.
Listed below are the IDs for the Record Types currently supported, grouped in
logical or functional families.
Communications and Link Control
LS - Link Start
LA - Link Alive (Sanity check)
LE - Link End
These Record Types are used to control the status of the link. The PMS only
opens or closes the link when starting or stopping its software. This means that if
a Link Start (LS) is received from the PMS, the Link Description (LD) and Link
Records (LR) must be retransmitted (see Implementation Notes & Exceptions
below).
The Link Alive (LA) record is provided as a means to verify the link is still
functioning. The PMS only uses this Record ID to respond to a Link Start (LS) or
a Link Alive (LA) when the link is or was previously active (see Implementation
Notes & Exceptions below).
However, if the other system sends a LA record as a test of the link, the PMS will
send a low-level acknowledgment (only applies to asynchronous serial
connections, see the MICROS-Fidelio Interface Protocol specification for further
details). The other system should recognize this as a signal that the PMS interface
software is running; an application level response is not sent.
If the PMS sends a Link End (LE) record, the other system should buffer all nondiscardable records (i.e. charges) until it receives the next communication. At that
point, the link should be reactivated even if the Link Start (LS) record is missed.
Record ID Field ID
Description
Format
Direction
LS, LA,
LE
Date
Time
D
T
Both
Both
DA
TI
LD - Link Description
LR - Link Record
These records must be sent by the other system immediately after it receives the
Link Start (LS) record from the PMS upon startup or initialization. Please note
that it is possible to reconfigure the link at any time.
The link description (LD) record indicates the start of the Link Records (LRs) and
general link information (such as change of field separator). Link Records (LRs)
are sent by the other system to describe each record it will be sending and expects
to receive; this is basically a Record ID Type, followed by a list of fields that
should be included (for that particular Record ID), one Record ID per Link Record
(LR).
Note that in the examples below, the order of the fields requested may not match
the order in which they are sent in the record; field order is not considered
significant. After the last Link Record (LR), the other system should send a Link
Alive (LA) to indicate that the link is now considered active.
Record ID Field ID
Description
LD
Date
Interface Family
DA
IF
TI
V#
FS
RL
Format
D
AN, 2 chars
(see Interface
Type table)
Time
T
Vendor Version # AN, max. 10
Field Separator
ANS, 1 char
Max. record length N, variable
(max. record
length is 2,000)
Direction
To PMS
To PMS
To PMS
To PMS
To PMS
To PMS
determines the display of the PMS Interface system
LR
FL
RI
Field List
Record ID
ANS, variable
ANS, 2 chars
To PMS
To PMS
Examples
The following is an example of both systems starting at the same time. The data
flow should be followed exactly, with the exception of the format of the Link
Records (LRs). These are sent as required by the functionality of the other system.
The PMS sends a Link Start (LS) record with date (DA, 15 October 2000) and
time (TI, 12:30:45 PM) fields. This indicates that the PMS software has been
restarted and the other system must send any configuration records (LD/LR/LA)
before sending any buffered data records:
LS|DA001015|TI123045|
The other system responds with a Link Description (LD) with vendor version #
(V#) 1.01, and interface type (IF) PBX:
LD|DA001015|TI123046|V#1.01|IFPB|
Then it sends a Link Record (LR) with Guest Check-in field list (RIGI)
requested fields are Room Number (RN), Guest Number (G#), Guest Name (GN),
Guest Language (GL), Guest VIP status (GV), and Guest Group number (GG),
with support for multiple guests (Guest Share, GS), include Swap Flag (SF) in
database resync records:
LR|RIGI|FLRNG#GNGLGVGGGSSF|
Link Record (LR) with Guest Change (GC) field list requested field list is the
same as Guest Check-in (RIGI above) with the exception of the SF field (GC
records are not sent as part of a database resync and dont use the Swap Flag) and
the RO field (used in Room Move records):
LR|RIGC|FLRNG#GNGLGVGGGSRO|
Link Record (LR) with Guest Check-out field list (RIGO) requested fields are
Room Number (RN), Guest Number (G#), Guest Share (GS) and Swap Flag (SF):
LR|RIGO|FLRNG#GSSF|
Note: Guest Check-out records (GOs) sent during database resync will not contain
any fields other than Room Number (RN) and the Swap Flag (SF), as there is not
valid data for other fields (see database swap example below).
After the last Link Record (LR), the other system should send a Link Alive (LA)
record. This indicates that the other system has sent descriptions of the link and all
Record Types that it wants to receive or send. The link is now active and the PMS
will immediately start sending any real-time or buffered data:
LA|DA001015|TI112349|
The PMS responds with a Link Alive (LA) as the link was inactive before:
LA|DA001015|TI112350|
10
Implementation Notes & Exceptions

The PMS will send a Link Start (LS) as its first message when initializing its
software. The other system may respond with a Link Start (LS), or go straight to
the Link Description/Link Record(s)/Link Alive (LD/LR/LA) sequence.
If the PMS does not receive a response to the Link Start (LS), especially the Link
Description (LD) and Link Records (LR), it will retransmit a Link Start (LS) upon
receiving the first record from the other system. The other system must respond
with the above sequence (LD/LR/LA) whenever it receives a Link Start (LS) from
the PMS.
If the PMS receives a Link Start record (LS), it responds with a Link Start (LS) if
the link has never been started. The other system should then transmit the
LD/LR/LA sequence. If the link is currently active or if it had been terminated
with a Link End (LE) by the other system, the PMS transmits a Link Alive (LA),
indicating it has a valid configuration for the other system. The other system may
then choose to send a Link Alive (LA), or to reconfigure the link by sending the
LD/LR/LA sequence.
The functionality of the PMS if it sends a Link Start (LS) and receives a response
other than a Link Start/Link Description/Link Records/Link Alive (LD/LR/LA)
sequence is undefined. It can default to using whatever functionality it considers
appropriate. This can range from no low-level response on the link, to sending all
outbound records with default field lists (default field lists may vary with the PMS
configuration).
For normal shutdown, the system that is dropping the link should transmit a Link
End (LE). However, in exception situations (hardware or software failure, or user
error), the PMS will consider the link inactive if there are consecutive low level
timeouts (no response from the other system) exceeding a configurable count. The
PMS will buffer what it considers critical data, but it is recommended that after the
other system sends the Link Alive (LA), that it immediately requests a database
resync (DR).
If the PMS considers the link inactive (i.e. Link End (LE) from the other system,
or excessive low level timeouts), it will consider the link active upon the receipt of
the first record from the other system. This is to avoid situations where the Link
Start (LS) record is missed. The PMS will decide at this point if it needs to
transmit a Link Alive (LA).
11
Database Resynchronization
DR - Database Resync request
DS - Database Resync start
DE - Database Resync end
These records are used to request an initialization or refresh of the system
database, and to indicate the start or end of that resync. With few exceptions, the
PMS regards its databases as the master copy. As the PMS can intermix
database records with real-time records, the DS and DE records insure that the
other system knows its request has been correctly received and that all database
resync information has been sent.
The records sent as part of the database resync are the same as sent during realtime situations with the addition of the swap flag field (SF); this allows the other
system to determine the difference between the resync records and real-time
messages. Resync records will contain the swap flag field (SF), real-time records
will not. It is strongly recommended that database resyncs are supported.
Record ID Field ID
Description
Format
Direction
DR, DS,
DE
Date
Time
D
T
Both
Both
DA
TI
Examples
The other system requests a database resync (DR):
DR|DA001005|TI125045|
The PMS responds with start (DS), data (i.e. GI and GO), and end (DE) records.
This example assumes that the other system only requested the Room Number
(RN), Guest Number (G#), and Swap Flag (SF) fields in the Link Record (LR)
describing the Guest In (GI) and Guest Out (GO) records during the link startup
sequence (i.e. LRGI|FLRNG#GSSF, LRGO|FLRNG#GSSF):
DS|DA001005|TI125047|
GI|RN1001|G#12345|GSN|SF|
GO|RN1002|GSN|SF|
GO|RN1004|GSN|SF|
GI|RN1003|GSY|G#12329|
DE|DA001005|TI1252001|
Note: The sixth record sent in this example is a real-time check-in record; the last
record received for any room or guest always reflects the current status. Also,
there is no G# included in GO as these rooms are empty. In addition, at the end of
a database resync that is guest-oriented (i.e. the GI records contain the Guest
Number, G#), if the other system has not received a GI record during the resync
for a previously checked in guest, but the room is still occupied in its system by
another guest, the missing guest has checked out and should be deleted from the
other systems database.
12
Night Audit
NS - Night Audit Start
NE - Night Audit End
These two records provide other systems with an audit date and time stamp so that
any accounting functionality can match hotel dates and posting periods.
It should be taken into account that standard PMS practice is to accept the time of
posting as sent by the other system, but to replace the date of postings with the
Hotel date (as opposed to calendar date).
Record ID Field ID
Description
Format
Direction
NS, NE
Date
Time
D
T
From PMS
From PMS
DA
TI
Example
NS|DA001031|TI030405|
NE|DA001101|TI041425|
Note: The date field in the Night Audit records is the hotel date, not calendar date.
13
Guest Data
GI - Guest Check-in
GO - Guest Check-out
GC - Guest data change
These records are used to transmit data concerning guests: any information
required to set or update the guest data will be included in these records. The
records can contain similar data fields, but the Record Type specifies what actions
should be performed.
A GI record for a previously empty room, i.e. the record contains a Guest Share
flag, GS set to N, sent as an online message (does not contain the Swap Flag, SF)
should set all statuses as specified in the record (unspecified statuses should have
defaults).
A GI record with a Swap Flag (SF) should only be used to compare statuses and
update what has changed, it should not set unspecified statuses to their defaults.
This is also true of GC records. Only statuses listed in the record should be
changed, all other statuses should remain at their current settings.
Note: If multiple guests per room (Sharers) are supported, it is required to use the
Guest Number (G#) and Guest Share (GS) fields; this is to prevent overwriting
current guest data. Guest Number (G#) is a unique number (assigned in the PMS)
that provides a means of identifying guests, even during name changes. It is
recommended for use with all systems; it is required for systems that provide
multi-occupancy features (Sharers) or can change guest-related information after
check-in.
Another item to be aware of is name format; when Guest Name (GN) is used, the
format of the name is configurable in the PMS.
Certain fields (i.e. TV, MR) are supported here however it is more common to
have them defined in room-oriented records, please see Room Equipment (RE)
section below for further details.
14
Record ID
Field ID
Description
Format
Direction
GI
(Guest
Check-in)
G# 1
RN
GS 1
A0 A9 2
DA
GA
GD
Guest Number
Room Number
Share Flag
User Definable
N, max. 10
AN, max. 8
AN, 1 char (Y/N)
ANS, variable
From PMS
From PMS
From PMS
From PMS
D
D
D
From PMS
From PMS
From PMS
ANS, max. 20
AN, max. 10
From PMS
From PMS
GL
Date
Guest Arrival Date
Guest Departure
Date
Guest First Name
Guest Group
Number
Guest Language
From PMS
GN
GT
GV
KO
MR
Guest Name
Guest Title
Guest VIP Status
Key Options
Minibar Rights
AN, max 2
(see Guest
Language table)
ANS, max. 40
ANS, max. 20
AN, max. 3
AN, max. 20
AN, 2 chars
(see Guest Rights
table)
No data (if this
field is sent, the
record is part of
the database swap)
N, 2 digits
(see Guest Rights
table)
T
AN, 2 chars
(see Guest Rights
table)
AN, 2 chars
(see Guest Rights
table)
N, max. 10
AN, max. 8
AN, 1 char (Y/N)
D
No data (if this
field is sent, the
record is part of
the database swap)
T
From PMS
From PMS
From PMS
From PMS
From PMS
GF
GG
2
2
Swap Flag
SF
GO
(Guest
Checkout)
SM
Seminar Channels
TI
TV
Time
TV Rights
VR
Video Rights
G#
RN
GS
DA
SF
Guest Number
Room Number
Share Flag
Date
Swap Flag
TI
1
2
Time
From PMS
From PMS
From PMS
From PMS
From PMS
From PMS
From PMS
From PMS
From PMS
From PMS
From PMS
mandatory for guest-oriented systems

requires special configuration in PMS.
15
Record ID
Field ID
GC
(Room
Move)
G#
GS
RN
1
1
RO
Guest Number
Share Flag
Room Number
(destination room)
N, max. 10
AN, 1 char (Y/N)
AN, max. 8
From PMS
From PMS
From PMS
Guest Number
Share Flag
Room Number
User Definable
N, max. 10
AN, 1 char (Y/N)
AN, max. 8
ANS, variable
From PMS
From PMS
From PMS
From PMS
D
D
D
From PMS
From PMS
From PMS
ANS, max. 20
AN, max. 10
From PMS
From PMS
GL
Date
Guest Arrival Date
Guest Departure
Date
Guest First Name
Guest Group
Number
Guest Language
From PMS
GN
GT
GV
KO
MR
Guest Name
Guest Title
Guest VIP Status
Key Options
Minibar Rights
AN, max 2
(see Guest
Language table)
ANS, max. 40
ANS, max. 20
AN, max. 3
AN, max. 20
AN, 2 chars
(see Guest Rights
table)
N, 2 digits
(see Guest Rights
table)
T
AN, 2 chars
(see Guest Rights
table)
AN, 2 chars
(see Guest Rights
table)
G# 1
GS 1
RN
A0 A9 2
DA
GA
GD
SM
TI
TV
VR
Direction
From PMS
From PMS
GF
GG
Format
Old Room Number AN, max. 8

(source room)
Date
D
Time
T
DA
TI
GC
(Guest
Info/Name
Change)
Description
2
2
Seminar Channel
Time
TV Rights
Video Rights
From PMS
From PMS
From PMS
From PMS
From PMS
From PMS
From PMS
From PMS
From PMS
From PMS
mandatory for guest-oriented systems

Requires special configuration in PMS
Note: Only one LR is required for GC, it should contain Field Types for both
Room Move (if required) and Guest Information change records.
16
Examples
Check-in (GI) for Room (RN) 2781, Guest Number (G#) 12345, Guest Name
(GN) Mr. Guest, Language (GL) English, VIP status (GV) Y, Group Number
(GG) A123, non-share (GS) to an unoccupied room (GSN):
GI|RN2781|G#12345|GNGuest, Mr.|GLEA|GVY|GGA123|
GSN|
Change guest information (GC) for Room (RN) 2781, Guest Number (G#) 12345,
Guest Name (GN) is now Hr. Gast, Language (GL) German, all other statuses
remain the same:
GC|RN2781|G#12345|GNGast, Hr.|GLGE|
Check-in (GI) for Room (RN) 2781, Guest Number (G#) 12381, Guest Name
(GN) Dr. Sharer, Language (GL) English, VIP status (GV) N, Group Number
(GG) A123, to an occupied room (GSY):
GI|RN2781|G#12381|GNSharer, Dr.|GLEA|GVN|
GGA123|GSY|
Move (GC) Guest Number (G#) 12345 from Room (RO, source room) 2781 to
Room (RN, destination room) 9327. The Guest Share (GS) flags indicate the new
room is unoccupied, but the old room is still occupied. The room move should be
treated as a Check-in for the new room, but the only effect on the old room would
be to remove the information for Guest Number (G#) 12345:
GC|RN9327|GSN|G#12345|RO2781|GSY|
Note: It is the responsibility of the receiving system to properly set or change
statuses when moving a guest from a share or to a share. It is also expected that if
a guest is moved from a room that is now empty, this will function the same as a
GO record; if the guest is moved to a previously unoccupied room, all statuses,
Wake-up calls, etc. will be transferred accordingly.
Database resync update for Room (RN) 9327/Guest Number (G#) 12345 and
Room (RN) 2781/Guest Number (G#) 12381, with refresh of available statuses:
GI|RN9327|G#12345|GNGast, Hr.|GLGE|GVY|
GGA123|GSN|SF|
GI|RN2781|G#12381|GNSharer, Dr.|GLEA|GVN|
GGA123|GSN|SF|
Check-out (GO) Room (RN) 9327 , Guest Number (G#) 12345, individual or last
guest to depart room (GSN):
GO|RN9327|G#12345|GSN|
17
Extended Guest Data

XL
XM
XT
XD
XR
XI
XB
XO
XC
Guest message text and other details online

Guest message request
Guest message text and other details
Guest message delete
Guest bill request
Guest bill item
Guest bill balance
Guest bill detail online
Remote Check-out request
These Record Types provide a mechanism to request and pass guest specific
information of a more comprehensive nature. They are designed for guestoriented systems. It is possible to send message text (XL) or guest bill
information (XO) as an online process, that is, without requests, but as they occur
in real-time.
Please note that most of these records require additional configuration in the PMS.
Record ID
Field ID
Description
Format
Direction
XL
(Guest
Message
text online)
G#
MI
MT
Guest Number
Message ID
Message Text
From PMS
From PMS
From PMS
RN
DA
TI
Room Number
Date
Time
N, max. 10
N, max. 8
ANS, variable
(max 1000)
AN, max 8
D
T
XM
(Guest
message
request)
G#
RN
DA
MI
TI
Guest Number
Room Number
Date
Message ID
Time
N, max. 10
AN, max. 8
D
N, max. 8
T
To PMS
To PMS
To PMS
To PMS
To PMS
XT
(Guest
Message
text)
G#
MI
MT
Guest Number
Message ID
Message Text
From PMS
From PMS
From PMS
RN
DA
TI
Room Number
Date
Time
N, max. 10
N, max.8
ANS, variable
(max. 1000)
AN, max. 8
D
T
From PMS
From PMS
From PMS
From PMS
From PMS
From PMS
18
Record ID
Field ID
Description
Format
Direction
XD
(Guest
message
delete)
G#
MI
RN
DA
TI
Guest Number
Message ID
Room Number
Date
Time
N, max. 10
N, max. 8
AN, max. 8
D
T
Both
Both
Both
Both
Both
XR
(Guest bill
request)
G#
RN
DA
TI
Guest Number
Room Number
Date
Time
N, max. 10
AN, max. 8
D
T
To PMS
To PMS
To PMS
To PMS
XI
(Guest bill
item)
BD
Item
Description
Item Amount
Department
Code
Guest Number
Room Number
Date
Window/Folio
Number
Item Display
Flag
Time
AN, max. 25
From PMS
N, max. 20
N, max. 4
From PMS
From PMS
N, max. 10
AN, max. 8
D
N, 1
From PMS
From PMS
From PMS
From PMS
AN, 1 char (Y/N)
From PMS
From PMS
Balance
Amount
Guest Number
Room Number
Date
Time
N, max. 20
From PMS
N, max. 10
AN, max. 8
D
T
From PMS
From PMS
From PMS
From PMS
BI
DC
G#
RN
DA
F#
FD
TI
XB
(Guest bill
balance)
BA
G#
RN
DA
TI
19
Record ID
Field ID
Description
Format
Direction
XO
(Guest bill
detail
Online)
BA
Balance
Amount
Item
Description
Item Amount
Dept. Code
Window/Folio
Number
Item Display
Flag
Guest Number
Room Number
Date
Time
N, max. 20
From PMS
AN, max. 25
From PMS
N, max. 20
N, max. 4
N, 1
From PMS
From PMS
From PMS
AN, 1 char (Y/N)
From PMS
N, max. 10
AN, max. 8
D
T
From PMS
From PMS
From PMS
From PMS
AN, 2 chars
From PMS
(see Answer Status
table)
N, max. 20
Both
BD
BI
DC
F#
FD
G#
RN
DA
TI
XC
(Remote
Check out request)
AS
Answer Status
BA
Balance
Amount
Guest Number
Room Number
Clear Text
Date
Time
G#
RN
CT
DA
TI
1
2
N, max. 10
An, max. 8
ANS, max. 40
D
T
Both
Both
From PMS
Both
Both
- sent from PMS to show status of request

- sent as part of Remote Check-out request
Examples
Message # (MI) 903 sent online (XL, immediately after entry in PMS) for Guest
Number (G#) 12345 in Room (RN) 2781 entered in Front Office on 31 October
2000 (DA) at 12:47:53 PM (TI):
XL|RN2781|G#12345|MI903|MTThis is a sample
message.<CR><LF>It contains formatting inf
ormation<CR><LF> because it will be printe
d directly by<CR><LF>the other system.<FF>|
DA001031|TI124753|
20
Request for text of [all] guest messages (XM) for Room (RN) 2781, Guest
Number (G#) 12345:
XM|RN2781|G#12345|
Response to guest message request (XT) - same message as shown in the XL
record above:
XT|RN2781|G#12345|MI903|MTThis is a sample
message.<CR><LF>It contains formatting inf
ormation<CR><LF> because it will be printe
d directly by<CR><LF>the other system.<FF>|
DA001031|TI124753|
Note: It is possible for a system to work with both modes (online and request
mode). In this case, request mode is generally used as a means to resynchronize
the messages stored in the external system. At initialization, sending a Link
Record (LR) for the guest message request (XM), enables request mode. If, in
addition, a LR for online mode (XL) is sent, this mode will also be enabled.
Request to delete (XD) Message # (MI) 903 for Guest Number (G#) 12345 in
Room (RN) 2781:
XD|RN2781|G#12345|MI903|
Request to view bill (XR) for Guest Number (GN) 12345 in Room (RN) 2781:
XR|RN2781|G#12345|
Response to bill request (XI), bill items (BI) for Guest Number (G#) 12345 in
Room (RN) 2781 with item information - PMS department code (DC), item
amount (BI), item description (BD), date (DA) & time (TI) of posting, balance
record (XB) has a folio total (BA) of 138.50:
XI|RN2781|G#12345|DC327|BI350|BDTelephone|
DA001031|TI124753|
XI|RN2781|G#12345|DC400|BI2500|BDLobby Bar|
DA001031|TI1843000|
XI|RN2781|G#12345|DC100|BI11000|BDRoom&Tax|
DA001101|TI031000|
XB|RN2781|G#12345|BA13850|DA001101|TI071500|
Note: The balance reflects the total of the items sent (generally items that the guest
will pay). This may not be the same as the total of the entire guest folio as there
may be items that the guest will not pay (i.e. postings covered by a travel agent)
and that should not be displayed to the guest. If the requesting system also works
with Online Bill Display (XO), the Item Display (FD) and Window Number (F#)
fields should be requested also for the Bill Item (XI) records at startup, and
MICROS-Fidelio should be configured to send all items; this will keep the
balances in sync. It is the responsibility of the requesting system to properly
handle display of the items based on the Item Display status (see note for Online
Bill Item below).
21
Online bill display (XO) for Guest Number (G#) 12345 in Room (RN) 2781,
Department Code (DC) is 327, charge amount (BI) is $3.50, description (BD) is
Telephone, folio balance (BA) is $138.50, item can be displayed (FD), folio
window (F#) 1:
XO|RN2781|G#12345|FDY|F#1|DC327|BI350|BDTelephone|
BA13850|DA001031|TI124753|
Note: If the balance sent in an XO record does not match the item amount (BI)
plus the balance already received, a request to view the guest bill (XR) should be
made (see example above). Also, the Item Display (FD) and Window Number
(F#) fields are mandatory for Online Bill display. This is because the Bill Total
(BA) reflects all items, even those that should not be shown to the guests. If FD is
set to N, the item has not been sent to be displayed, only to keep the balance in
sync.
Remote check-out request (XC) for Guest Number (G#) 12345 in Room (RN)
2781, balance (BA) 138.50. Note that balance (BA) must be included in XC
records:
XC|RN2781|G#12345|BA13850|DA001101|TI071600|
Response to remote check-out request (XC) for Room (RN) 2781, Guest Number
(G#) 12345 with positive answer status (AS) (check-out allowed and will be done
as background process):
XC|RN2781|G#12345|ASOK|DA001101|TI071602|
22
Locators
LO - Locator On
LF - Locator Off
LP - Locator Retrieve
Guest locators are used to indicate where a guest is in the hotel if not in their room.
A typical situation is where a guest is waiting for an important call or fax but goes
to the restaurant for lunch. A locator set (LO) by the POS can inform the Front
Desk or switchboard personnel where the guest can be found. However, if the
functionality is required, any system may send or retrieve locators.
Please note that there can only be one active locator for a guest at any time. This
might seem to lead to some problems if multiple systems are setting the locator,
but in reality, the guest can only be in one place at a time.
Locator records must always include the Guest Number (G#), as they are a guest,
not room, related feature. If the locator record is sent from a system that does not
have the Guest Number (G#), this can be retrieved by looking up the guest in
question using a Posting Request (PR) record containing a Posting Info (PI) field
(See Point of Sale & other Charge systems section for details). This record is
normally used by POSs, but can be used by any system doing a basic inquiry to get
a list of guests, and their room and guest numbers.
When turning a locator on (LO), the record must also include the current guest
location sent as clear text (CT), and time at which the locator should automatically
expire (LT), i.e. for how long the locator is valid. When turning a locator off
(LF), it is advisable that the external system first retrieve (LP) the current (if
existing) locator for that guest to verify that it is not turning off a locator set by
another system. It is not necessary to turn off locators; in many cases, especially
when dealing with locators of short duration, it is easier to let the locator expire on
its own.
Record ID Field ID
Description
Format
Direction
LO
(Locator
On)
ANS, max. 80
N, max. 10
HHMM
To PMS
To PMS
To PMS
TI
DA
RN
Clear Text
Guest Number
Locator expiry
time
Time
Date
Room Number
T
D
AN, max. 8
To PMS
To PMS
To PMS
G#
DA
RN
TI
Guest Number
Date
Room Number
Time
N, max. 10
D
AN, max. 8
T
To PMS
To PMS
To PMS
To PMS
LF
(Locator
Off)
CT
G#
LT
23
Record ID Field ID
LP
(Locator
Retrieve)
Format
Direction
AN, 2 chars
(see Answer Status
table)
ANS, max. 96
N, max. 10
HH:MM
(PMS format)
D
AN, max. 8
T
From PMS
AS
Answer Status
CT
G#
LT
Clear Text
Guest Number
Locator Expiry
Time
Date
Room Number
Time
DA
RN
TI
1
Description
From PMS
Both
From PMS
Both
Both
Both
only required in response from PMS
Examples
Turn on a locator (LO) for Guest Number (G#) 19683 from the Lobby Bar (CT)
which expires (LT) at 14:30:
LO|G#19683|CTLobby Bar|TI123000|LT1430|
Turn off the locator (LF) set for Guest Number (G#) 19683:
LF|G#19683|
Retrieve locator (LP) for Guest Number (G#) 19683:
LP|G#19683|
Guest locator found with location (CT) and expiration time (LT):
LP|G#19683|ASOK|CTLobby Bar|LT14:30|
No guest locator found for this guest (AS, CT):
LP|G#19683|ASNM|CTNo Current Locator|
24
Room Data
RE - Room equipment status
RA - Assign room equipment
RE records are used to control the status of any room equipment (i.e. set/clear
items such as message waiting status (ML) or Class of Service (CS) for TMSs;
set/clear TV privileges for Video systems (TV), etc.). These records are generally
room-oriented and need to be configured in the PMS. In some cases (i.e. TV and
MR), it is also possible to configure them in the Guest Data records (GI, GC).
RA records are used to assign room equipment dynamically (RA), as in the case of
DID, virtual, or phantom telephone extensions. Please note that Virtual Numbers
requires an additional module in the PMS.
Record ID Field ID
Description
Format
Direction
RE
(Room
equipment
status)
Room Number
Class of Service
AN, max. 8
AN, max. 1
(see COS table)
ANS, max. 40
AN, max. 1 (Y/N)
N, max. 10
AN, 1 char (Y/N)
Both
From PMS
AN, 2 chars
(see Guest Rights
table)
N, 1
N, 1
(see Room Maid
Status table)
AN, 2 chars
(see Guest Rights
table)
AN, max. 4
From PMS
RN
CS
CT
DN
G#
ML
MR
PP
RS
Printer Port
Room Status
TV
TV Rights
VM
3
3
Clear Text
Do-not-Disturb
Guest Number
Message Light
Status
Minibar Rights
Voice Mail
To PMS
Both
From PMS
From PMS
To PMS
To PMS
From PMS
To PMS
required only if line COS (bar/unbar) functionality is available and used

can only be used together with VM, DN, RS
3
required only if Message Lamp functionality is available and used
4
required only if Minibar functionality is available and used
5
required only if TV Rights functionality is available and used
2
RA
(Assign
room
Equipment)
RN
ES
EN
Room Number
Equipment
Status
Equipment
Number
AN, max. 8
AN, 1 char (A/U)
From PMS
From PMS
AN, max. 8
From PMS
25
Examples
Turn Message Light (ML) on for Room (RN) 2781
RE|RN2781|MLY|G#12345|
Turn DND (DN) on for Room (RN) 2781:
RE|RN2781|DNY|
Set COS (CS) to 3 for Room (RN) 2781:
RE|RN2781|CS3|
Voice Mail (VM) notification on for Room (RN) 2781:
RE|RN2781|VMY|
or
Voice Mail (VM) notification with Unread (1)/Read (3) counts for Room (RN)
2781:
RE|RN2781|VM0103|
Maid status notification (RS) (clean/vacant) for Room (RN) 2781 (default maid
statuses are listed in the Room Maid Statuses Table in Appendix B):
RE|RN2781|RS3|
Maid status notification (RS) with text (CT) to print on printer (PP) 1 for Room
(RN) 2781:
RE|RN2781|RS1|PP1|CTSend maintenance personnel.|

Text (CT) to be printed on printer (PP) 1 for Room (RN) 2781:
RE|RN2781|PP1|CTGuest in 2781 needs assistance.|

Note: The printer port (PP) and text (CT) can be used with RE records to print a
message on a specified printer (must be configured); this only occurs if both fields
exist in the record. If there are other fields included (i.e. set room status RS),
this action will also be performed.
26
Set Minibar rights (MR) to normal vend (i.e. no alcoholic articles) for Room (RN)
2781:
RE|RN2781|MRMN|
Set Pay TV rights (TV) to block Adult movies in Room (RN) 2781:
RE|RN2781|TVTX|
Notes: Pay TV rights have the following precedence: TN, no rights (no TV
channels); TM, all Pay channels blocked; TX, Adult Pay channels blocked; TU,
all rights (includes all Pay channels). With TV rights it is not possible to block
normal Pay channels and allow Adult pay channels.
Assign (ESA) Virtual Extension (EN) 920920 to Room (RN) 2781, Class of
Service (COS) set to default by the TMS:
RA|RN2781|EN920920|ESA|
Unassign (ESU) Virtual Extension (EN) 920920 from Room (RN) 2781. This
implicitly sets COS for the Virtual Extension to barred status:
RA|RN2781|EN920920|ESU|
Unassign (ESU) all Virtual Extensions from Room (RN) 2781:
RA|RN2781|ESU|
Note: Virtual Numbers requires an additional module in the PMS. RA records are
directly linked to the Guest Data records.
27
Wakeup
WR - Wakeup request
WA - Wakeup answer
WC - Wakeup clear
Wakeup records allow the other system to set (WR) and the PMS to clear (WC)
wakeup calls. In addition, the other system should report the success or failure
status of the call (WA) to the PMS, and the PMS should be able to request an
immediate wakeup call.
Record ID Field ID
Description
Format
Direction
WR, WC
(Wakeup
request
/clear)
DA
RN
TI
Date
Room Number
Time
D
AN, max. 8
T
Both
Both
Both
WA
(Wakeup
answer)
AS
Answer Status
To PMS
DA
RN
TI
Date
Room Number
Time
AN, 2 chars
(See Answer
Status table)
D
AN, max. 8
T
To PMS
To PMS
To PMS
Examples
Request from the PMS to set a wakeup call (WR) for Room (RN) 2781 at 7 AM
(TI) on 31 October 2000 (DA):
WR|RN2781|DA001031|TI070000|
Wakeup system response (WA) that the above wakeup call was unsuccessful (AS)
because the telephone was busy:
WA|RN2781|DA001031|TI070000|ASBY|
Request from PMS to clear (WC) this wakeup call:
WC|RN2781|DA001031|TI070000|
Request from wakeup system to clear (WC) all wakeup calls for this room:
WC|RN2781|DA|TI|
28
Point of Sale & Other Charge Systems

PS
PR
PL
PA
Posting (simple)
Posting Request
Posting List
Posting Answer
The simple form of Posting records (PS) is for systems that do room postings
without having to verify the guest (i.e. telephone, TV, etc.). These systems
generally use the GI/GO records to ensure that the system in a specific room
should be active. They also should use the Room Equipment status or Guest Data
(Guest Rights) records to allow changing the status of the equipment after check-in
(see examples in the sections above). In this case it is also suggested to support a
Class of Service (for example, a guest is checked in but cannot view Pay TV).
Another means of verifying guest privileges is by reading the information stored
on a magnetic stripe card (i.e. normally Track 2 on the guests room key); this is
useful for Minibars, Vending machines, and other self-service POSs. When keys
have been encoded with the standard MICROS-Fidelio Track 2 information, the
POS can forward this track to identify guests and verify posting privileges.
Posting Request records (PR) are intended more for providing the functionality
required by POS systems and allow for posting to PMS folios or accounts. The
charges are generally guest-oriented and allow the user to make inquiries (PI) to
the PMS to provide information such as room occupancy, guest hotel status or
credit status, etc. The Posting Request record (PR) can be used both to inquire and
make the posting. If there is no Guest Number (G#), or it is empty, then the
request is treated as an inquiry; if it is included, the request is treated as a posting.
If a guest selection is needed, the PMS will return a Posting List record (PL); if
there are multiple guest folios that match the search criterion (i.e. sharers by room
search), there will be multiple name fields (GN) returned.
The Posting Answer record (PA) is required in all cases to be sure that the charges
were posted properly and to control the data flow. If specific fields are required to
route a Posting Answer (PA) to a terminal or other posting location (WS/SO),
these should be specified in the Field List (FL) for this Record Type during
startup.
Note: Certain fields that may be defined in the Link Record (LR) for PL and/or
PA will only contain data if they are sent in the PS/PR record by the other system
e.g. P#, SO etc.
29
Record ID
Field ID
Description
Format
Direction
PS
(Posting
simple)
DA
DD
DU
M#
Date
Dialed Digits
Duration
Number of
Articles
Minibar Article
Meter or Tax Pulse
Posting Type
D
N, max. 23
T
N, max. 2
To PMS
To PMS
To PMS
To PMS
N, max. 4
N, max. 10
AN, 1 char
(see Posting Type
table)
AN, max. 8
N, max. 5
M, max 15
To PMS
To PMS
To PMS
T
N, max. 16
To PMS
To PMS
N, max. 8
AN, 1 char, (Y/N)
To PMS
To PMS
ANS, max. 20
N, max. 5
M, max. 15
AN, max. 16
N, max. 4
To PMS
To PMS
To PMS
To PMS
To PMS
AN, 1 char
AN, max. 5
N, max. 6
To PMS
To PMS
To PMS
M, max. 15
M, max. 15
N, max. 4
N, max. 4
M, max. 15
M, max. 15
AN, max. 16
To PMS
To PMS
To PMS
To PMS
To PMS
To PMS
To PMS
MA
MP
PT
RN
SO
TA
1
1
2
2
3
4
5
TI
$2
C#
CO
CT
CV
D1-D9
ID
P#
PC
PM
PX
S1-S9
SC
ST
T#
T1-T9
TP
WS
Room Number
Sales Outlet
Total Posting
Amount
Time
Fidelio standard
Track 2 format
Check Number
Credit Limit
Override Flag
Clear Text
Covers
Discount 1-9
User ID
Posting Sequence
Number
Posting Call Type
Payment Method
Posting Route
(i.e. Trunk)
Subtotal 1-9
Service Charge
Serving Time
Table Number
Tax 1-9
Tip
Workstation ID
To PMS
To PMS
To PMS
- if Posting Type is T and charge costing is done by PMS using Duration (DU),
Dialed Digits (DD) must be sent.
2
- required if Posting Type is Minibar Charge (M)
3
- required if Posting Type is Telephone Charge (T) and charge costing is done
by PMS using meter pulses
4
- required if more than one Posting Type is used by the same interface
5
- required if Posting Type is Direct Charge (C)
30
Record ID
Field ID
PR
(Posting
Request)
DA
G#
GN
PI
PM
RN
TA
TI
$2
1
1
2
3
C#
CO
CV
D1-D9
ID
M#
MA
P#
PC
PD
PT
S1-S9
SC
SO
ST
T#
T1-T9
TP
WS
Description
Format
Direction
Date
Guest Number
Guest Name
Posting Inquiry
Payment Method
Room Number
Total Posting
Amount
Time
Fidelio standard
Track 2 format
Check Number
Credit Limit
Override Flag
Covers
Discount 1-9
User ID
Number of
Articles
Minibar Article
Posting Sequence
Number
Posting Call Type
Dialed Digits
Posting Type
(except T)
D
N, max. 10
ANS, max. 40
AN, max. 10
AN, max. 5
AN, max. 8
M, max 15
To PMS
To PMS
To PMS
To PMS
To PMS
To PMS
To PMS
T
N, max. 16
To PMS
To PMS
N, max. 8
AN, 1 char, (Y/N)
To PMS
To PMS
N, max. 5
M, max. 15
AN, max. 16
N, max. 2
To PMS
To PMS
To PMS
To PMS
N, max. 4
N, max. 4
To PMS
To PMS
AN, 1 char
N, max. 20
AN, 1 char
(see Posting Type
table)
M, max. 15
M, max. 15
N, max. 5
N, max. 4
N, max. 4
M, max. 15
M, max. 15
AN, max. 16
To PMS
To PMS
To PMS
Subtotal 1-9
Service Charge
Sales Outlet
Serving Time
Table Number
Tax 1-9
Tip
Workstation ID
To PMS
To PMS
To PMS
To PMS
To PMS
To PMS
To PMS
To PMS
- required only after guest selection

- required only for inquiries with no guest selection
3
- required for all postings if a non-room payment type (e.g. cash) is also used,
needs additional configuration in PMS.
2
31
Record ID
Field ID
Description
PL
(Posting
List)
G# 1
GN 1
RN 1
A0
A9 2
BA
C#
CL 2
DA
GA
GD
Guest Number
Guest Name
Room Number
User Definable
N, max. 10
ANS, max. 40
AN, max. 8
ANS, variable
From PMS
From PMS
From PMS
From PMS
Balance Amount
Check Number
Credit Limit
Date
Guest Arrival Date
Guest Departure
Date
Guest Group
Number
Guest Language
M, max. 20
N, max. 8
M, max. 15
D
D
D
From PMS
From PMS
From PMS
From PMS
From PMS
From PMS
AN, max. 10
From PMS
AN, max 2
(see Guest
Language table)
AN, max. 3
AN, max. 16
N, max. 4
From PMS
AN, max. 5
From PMS
N, max. 5
T
AN, max. 16
From PMS
From PMS
From PMS
GG
GL
Guest VIP Status

User ID
Posting Sequence
Number
PMS Payment
Method
Sales Outlet
Time
Workstation ID
GV
ID
P#
PM
SO
TI
WS
1
2
Answer Status
AS
CT
DA
RN
TI
C#
G#
GN
ID
P#
SO
WS
2
Direction
From PMS
From PMS
From PMS
- required if account(s) matching search information in PI are found

requires configuration in PMS
PA
(Posting
answer)
Format
2
2
Clear Text
Date
Room Number
Time
Check Number
Guest Number
Guest Name
User ID
Posting Sequence
Number
Sales Outlet
Workstation ID
AN, 2 chars
(see Answer Status
table)
ANS, max 50
D
AN, max. 8
T
N, max. 8
N, max. 10
ANS, max. 40
AN, max. 16
N, max. 4
From PMS
N, max. 5
AN, max. 16
From PMS
From PMS
From PMS
From PMS
From PMS
From PMS
From PMS
From PMS
From PMS
From PMS
From PMS
- required only if search fails (PR only)

not available when PS is used
32
Examples
1) Posting (simple)/Answer
Telephone charge posting (PTC, i.e. call costed by other system) to Room (RN)
2781, cost (TA) 10.50, on 15 September 2000 (DA) at 12:35:45 (TI), sequence
number (P#) 0729, dialed digits (DD) 004989920920, international call (PC/CT):
PS|RN2781|TA1050|DA000915|TI123545|P#0729|
DD004989920920|PCI|CTInternational|PTC|
Posting accepted (ASOK):
PA|RN2781|ASOK|P#0729|DA000915|TI123545|
Telephone posting (PTT, i.e. call costed by PMS by pulse count) to Room (RN)
2781, 8 meter pulses (MP), on 15 September 2000 (DA) at 12:40:41 (TI),
sequence number (P#) 0730, dialed digits (DD) 2123830, local call (PC/CT):
PS|RN2781|PTT|MP8|DA000915|TI124041|P#0730|
DD2123830|PCL|CTLocal|
PA|RN2781|ASOK| P#0730|DA000915|TI124041|
Telephone posting (PTT, i.e. call to be costed by PMS by duration and dialed
digits) to Room (RN) 2781, duration (DU) 3 minutes, 45 seconds, on 15
September 2000 (DA) at 12:42:54 (TI), sequence number (P#) 0731, dialed digits
(DD) 5106850320, national call (PC/CT):
PS|RN2781|PTT|DU000345|DA000915|TI124254|P#0731|
DD5106850320|PCN|CTNational|
PA|RN2781|ASOK|P#0731|DA000915|TI124254|
Note: For Telephone charge psotings, the PMS will be configured to use only one
posting method, i.e. pre-costed call (PT field set to C) or costing by pulse (MP) or
duration/dialed digits (DU/DD, PT field set to T). If the costing is done by
duration (DU), dialed digits (DD) must be provided. Date (DA) and time (TI)
reflect the start of the call. Posting Sequence (P#) in all cases should be
incremented after every successful transmission.
Minibar posting (Direct Charge, PTC) to Room (RN) 2781, Sales Outlet (SO) 100
(this charge comes from a system that also sends laundry charges), cost (TA)
14.50, on 15 September 2000 (DA) at 12:42:54 (TI), sequence number (P#) 0732:
PS|RN2781|PTC|SO100|TA1450|DA000915|TI124254|P#0732|
33
PA|RN2781|ASOK|P#0732|DA000915|TI124254|
Note: Even though this is a Minibar posting, it uses Posting Type (PT) set to C
because the charge amount (TA) is sent.
Minibar posting (PTM) to Room (RN) 2781, guest consumption: 2 (M#) of article
(MA) 1450 and 3 of 1501, on 15 September 2000 (DA) at 12:42:54 (TI), sequence
number (P#) 0733:
PS|RN2781|PTM|MA1450|M#2|MA1501|M#3|DA000915|
TI124254|P#0733|
PA|RN2781|ASOK|P#0733|DA000915|TI124254|
Note: Posting Type (PT) is sent as M to indicate that the PMS should calculate the
charges itself based on article number (MA)/articles consumed (M#); this will be
done even if a pre-calculated charge is sent. If MA is sent but no M#, the article
count defaults to 1. If these fields occur more than once in a record, they must
occur in matched pairs.
2) Posting Request (Inquiries)/List/Answer

Posting Request from POS Sales Outlet (SO) 123, Terminal (WS) 456, User ID
Eli, for Room (PI) 2781:
PR|SO123|WS456|IDELI|PI2781|DA000915|TI124254|
List of guests (PL) in Room (RN) 2781:
PL|SO123|WS456|IDELI|RN2781|G#12345|
GNGuest, Mr.|RN2781|G#12381|GNSharer, Mr.|
Note: No Payment Method (PM) field has been included here because this POS
only sends room charges. If other payment methods (i.e. City Ledger, A/R, EFT,
Cash, etc.) are supported, the PM field must be included even with room charges.
As seen in the example above, if guests matching the PI search criterion are found,
the list is formatted as Room Number (RN)/Guest number (G#)/Guest Name (GN)
triplets (these can occur multiple times if there are sharers in a room, but all three
fields are sent for each guest). If the search data was ASCII (i.e. search by guest
name), the Room Number/Guest Number/Guest Name fields can also occur more
than once:
<Guest List> := <Room List>[<Room List>][<Room List>]
<Room List> := RN<data>|G#<data>|GN<data>|
34
For A/R or City Ledger charges, inquiries are still required. However, since these
accounts are not checked into rooms, the Room Number (RN) field is not included
in the room list. It then takes the following form:
<Room List> := G#<data>|GN<data>|
Posting Request from POS Sales Outlet (SO) 123, Terminal (WS) 456, User ID
Josh, for posting information (PI) 5781:
PR|SO123|WS456|IDJOSH|PI5781|DA000915|TI124254|
Invalid room response (AS/CT):
PA|SO123|WS456|IDJOSH |ASNG|CTINVALID ROOM|

Posting request from POS Sales Outlet (SO) 123, alpha search (PI) for G:
PR|SO123|WS456|IDELI|PIG|DA000915|TI124254|
List of guests (PL), Room (RN) 2781 Gast (GN), Room (RN) 352 Gandhi and
Garibaldi (GN, see room list description above):
PL|SO123|WS456|IDELI|RN2781|G#12345|GNGast, Hr.|
RN352|G#12940|GNGandhi, Mr.|
RN352|G#12875|GNGaribaldi, Mr.|
3) Posting Request (Charges)/Answer

Posting request from POS for Room (RN) 2781 with Guest Number (G#) 12875
selected, Sales Outlet (SO) 123, total (TA) to post 105.75, F&B (S1) charges
80.00, tax (T1) 25.75, check number (C#) 1234, 2 covers (CV), serving time (ST)
4:
PR|SO123|WS456|IDJOSH|RN2781|G#12875|
GNGaribaldi, Mr.|TA10575|S18000|T12575|
C#1234|CV2|ST4|DA000915|TI124254|
PA|SO123|WS456|IDJOSH|RN2781|G#12875|GNGaribaldi,
Mr.|ASOK|DA000915|TI124254|
Note: In all cases, the sum calculated by adding all subtotal and tax fields, and
subtracting discount fields (which means the amount in a discount field should be
positive) should equal the Total Amount (TA) field (see check splitting example
below).
TA = S1 + [S2] + [S3] + T1 + [T2] + [T3] - D1 - [D2] - [D3]
35
Posting request from POS for Room (RN) 2781 with Guest Number (G#) 12345
selected, Sales Outlet (SO) number 123, total (TA) to post 221.50, food charges
(S1) 80.00, beverage charges (S2) 60.00, miscellaneous (S3) 40.00, tax food (T1)
25.75, tax beverage (T2) 15.25, tax miscellaneous (T3) 10.50, discount food (D1)
10.00, check number (C#) 1234, serving time (ST) 4:
PR|SO123|WS456|IDELI|RN2781|G#12345|GNGast, Hr.|
TA22150|S18000|S26000|S34000|T12575|T21525|T31050|
D11000|C#1234|ST4|DA000915|TI124254|
PA|SO123|WS456|IDELI|RN2781|G#12345|GNGast Hr.|
ASOK|DA000915|TI124254|
Note: It is not necessary to send a subtotal, tax, or discount field if the value is 0.
In the above example, even though there could be corresponding discounts for
beverage (S2/D2) and miscellaneous (S3/D3), they are not sent because there was
no discount given. However, if a Tax (T?) or Discount (D?) field is sent, there
must be the respective Sales Itemizer (S?).
The following example is wrong because Tax (T8) and Discount (D9) fields are
sent without respective Sales Itemizers (S?):
PR|SO123|WS456|IDELI|RN2781|G#12345|GNGast, Hr.|
TA22150|S18000|S26000|S34000|T12575|T21525|T81050|
D91000|C#1234|ST4|DA000915|TI124254|
If the other system is a POS which supports splitting checks between guests or
payment methods, the individual subtotals, taxes, and discounts should also be
split so that when added together, they equal the Total Amount to be posted. This
way, all rounding corrections are handled by the same system, and the revenue
totals between the POS and the PMS will match.
For a split check, where only 110.75 should be posted, these items should be
recalculated as follows:
PR|SO123|WS456|IDELI|RN2781|G#12381|GNSharer, Mr.|
TA11075|S14000|S23000|S32000|T11287|T2763|T3525|
C#1234|D1500|ST4|DA000915|TI124254|
The following example is wrong because the subtotals, taxes, and discounts
reflect the totals for the whole check:
PR|SO123|WS456|IDJOSH|RN2781|G#12381|GNSharer, Mr.|
TA11075|S18000|S26000|S34000|T12575|T21525|T31050|
C#1234|D11000|ST4|DA000915|TI124254|
36
Posting request from POS for payment method (PM) AMEX selected, Sales Outlet
number 123, total (TA) to post 105.75, F&B (S1) charges 80.00, tax (T1) 25.75,
check number (C#) 1234, serving time (ST) 4:
PR|SO123|WS456|IDJOSH|PMAMEX|TA10575|S18000|T12575|C#12
34|ST4|DA000915|
TI124254|
PA|SO123|WS456|IDJOSH|ASOK|DA000915|TI124254|
Note: Inquiries for payment methods that are configured to post directly to one
specific account (i.e. normally anything other than room or A/R charges), for
example Cash or EFT charges, are neither required nor supported. These postings
are either accepted (ASOK), or the Answer Status field (AS) is accompanied by a
Clear Text field (CT) with a failure message. In addition, if payment methods are
enabled for non-room charges, the Payment Method (PM) field should be sent
with room charges also e.g. PMROOM.
Some POS systems are capable of reading and passing information from Track 2
of magnetic key cards. With these systems the track should be read and passed as
is to the PMS (the data on Track 2 up to the end sentinel for the card number
should be transparent to both the Key Service System and the POS).
Posting Request with Track 2 information ($2) 1000278100012345 included, Sales
Outlet (SO) number 123, total (TA) to post 105.75, F&B (S1) charges 80.00, tax
(T1) 25.75, check number (C#) 1234, serving time (ST) 4:
PR|SO123|WS456|IDELI|PMROOM|$21000278100012345|
|TA10575|S18000|T12575|C#1234|ST4|DA000915|TI124254|
PA|SO123|WS456|IDELI|RN2781|ASOK|DA000915|TI124254|
Note: This type of charge is still sent as room charge. The PMS will determine the
proper account, based on the data encoded on the key.
37
Key Services
KR - Key request
KD - Key delete
KA - Key answer
These are general purpose keycard system records. The Key Request (KR) record
can be used by the PMS to make all possible requests to the Key Services system
(KSS); different types of keys (i.e. new vs. duplicate keys) are specified by the
fields sent in the record. The Key Delete (KD) record is provided for those
systems that would prefer to get specific delete commands. Please note that it is
possible to use the GO record for the same purpose. The Key Answer (KA) is
supplied for completeness; the PMS may or may not pass responses from the KSS
to the Front Office users.
The specification currently supports up to 20 extra doors or areas that can be
accessed with the guest key. These are sent in the KO field and are position
dependent, i.e. position 1 = Garage, pos. 2 Minibar, etc. These are not hardcoded
from MICROS-Fidelio's viewpoint; they can vary from installation to installation.
Any position that is blank uses the defaults in the keycard system; as MICROSFidelio doesnt send trailing blanks, if the field is shorter, any trailing positions
should use default settings. Any position that contains a 0 is disabled. Any other
character is significant only in the keycard system. If only a toggle is required,
then a 1 should be sent to enable this door/area. If a specific area has different
access levels, specific characters are sent for the different levels. This method can
be used to handle rooms that are sometimes sold together as suites, sometimes sold
as separate rooms.
Note: In the following examples, references are made to sending commands to, or
receiving commands from, the key coder. However, this is for addressing and
claritys sake; there is only one physical connection between the MICROS-Fidelio
Interface PC and the KSS master PC.
38
Record ID Field ID
KR
(Key
request)
Description
K#
KC
KT
Key Count
Key Coder
Key Type
RN
WS
$2
Room Number
Workstation ID
Fidelio standard
Track 2 format
User Definable
A0
A9 2,
DA
DT 1
Format
Direction
N, max. 2
AN, max. 8
AN, max. 2 (see
Key Type table)
AN, max. 8
AN, max. 16
AN, max. 16
From PMS
From PMS
From PMS
ANS, variable
From PMS
From PMS
From PMS
From PMS
From PMS
From PMS
G#
Guest Number
D
HH:MM
(as defined in
PMS)
N, max. 10
GA
Guest Arrival Date
From PMS
GD
Guest Departure
Date
Guest Group
Number
Guest Name
Key Options
Time
From PMS
AN, max. 10
From PMS
ANS, max. 40
AN, max. 20
T
From PMS
From PMS
From PMS
GG
GN
KO
TI
1
1, 3
Date
S
i (CheckDeparture
out) Time
From PMS
not available with One Shot Keys

One Shot Key only supports A0
3
Requires configuration in PMS
2
KD
(Key
Delete)
KC
RN
WS
DA
G#
TI
Key Coder
Room Number
Workstation ID
Date
S
i
Guest
Number
Time
AN, max. 8
AN, max. 8
AN, max. 16
D
N, max. 10
T
From PMS
From PMS
From PMS
From PMS
From PMS
From PMS
KA
(Key
Answer)
AS
KC
WS
CT
DA
TI
Answer Status
Key Coder
Workstation ID
Clear Text
Date
S
Time i
AN, 2 chars
AN, max. 8
AN, max. 16
ANS, max. 40
D
T
To PMS
To PMS
To PMS
To PMS
To PMS
To PMS
39
Examples
Key request (KR) from workstation (WS) 3 for key coder (KC) 1, for (K#) 1 new
key (KT) for Room (RN) 2781, (KO) area 1 enabled, areas 2 & 4 set to default,
area 3 set to access level 2, area 5 enabled, areas 6-20 set to default, arrival date
(GA) 29 December 1999, departure date (GD) 2 January 2000, Guest Number
(G#) 11122, guest name (GN) Hr. Garibaldi, Track 2 ($2) should be encoded with
the following string - 1000278100011122:
KR|WS3|KC1|RN2781|KTN|K#1|KO1 2 1|GA991229|GD000102|
G#11122|GNGaribaldi, Hr.|$21000278100011122|
Key request (KR) from workstation (WS) 9 for key coder (KC) 3, for 2 duplicate
keys (KT) for Room (RN) 2781, (KO) area 1 enabled, area 2 set to default, area 3
is disabled, area 4 set to access level 2, areas 5-20 set to default., arrival date (GA)
30 December 1999, departure date (GD) 5 January 2000, Guest Number (G#)
12345, guest name (GN) Hr. Gast, Track 2 ($2) should be encoded with the
following string - 1000278100012345:
KR|WS9|KC3|RN2781|KTD|K#2|KO1 02|GA991230|GD000105|
G#12345|GNGast, Hr.|$21000278100012345|
Note: The field list is the same for both key requests; the content can be quite
different (arrival/departure dates, optional areas, Track 2 information, etc.). It is
up to each KSS to decide how much information to maintain in its databases, and
how much information should be duplicated from the original card to the
duplicate. The most important point is that New keys cancel any existing keys
for the main room (both in databases and in the locks themselves) and that
Duplicate keys do not.
Another important point is that the KSS should not attempt to interpret the data in
Track 2 ($2) as the contents of this data may be encoded and/or formats changed.
The main purpose of such track encoding is that the keys can be used in a POS that
supports EFT cards. Such POSs can then send the information to the PMS to
interpret as needed; both the KSS and the POS should consider the track data
transparent.
Response (KA) from key coder (KC) 3, answer status (AS) OK:
KA|WS9|KC3|ASOK|
Note: It is necessary to specify both the PMS workstation and the Key Service
systems coder in cases where more than one PMS workstation may be addressing
one key coder.
Key delete (KD) from workstation (WS) 9 for key coder (KC) 3 for Room (RN)
2781, guest number (G#) 12345:
KD|WS9|KC3|RN2781|G#12345|
Response (KA) from key coder (KC) 3, answer status (AS) OK:
KA|WS9|KC3|ASOK|
40
EFT
$U
$A
$B
$S
$Z
$E
$L
$H
Card type/usage request/answer

Authorization request/answer
Batch Begin
Settlement request/answer
Batch End
Batch Entered
Blacklist check/answer (not currently supported)
Hotel/Courtesy card (not currently supported)
Blacklist checking ($L) is not currently supported except where it is an integrated

part of type/usage verification ($U), authorization ($A), or settlement ($S)
processes.
Settlement records ($S) can either be sent online (at Check-out) or as batches. For
systems that use batches, the Batch Entered ($E) record must be returned to
confirm the acceptance of the entire batch.
Record ID Field ID
$U
(Card
type/
usage)
Description
$C
Credit Card
Number
Credit Card
Track 2
Card Usage
$D
$T
G#
S#
$I
WS
Expiry Date
Card Type
Guest Number
Sequence number
Merchant ID
Workstation ID
$#
$2
Format
Direction
N, max. 23
Both
AN, max. 40
From PMS
N, 1 digit
(see EFT Card
Usage Table)
YYMM
AN, 2 chars
N, max. 10
N, max. 5
AN, max. 16
AN, max. 16
To PMS
From PMS
To PMS
Both
Both
From PMS
Both
- sent by the PMS only if the card was swiped
41
Record ID Field ID
Description
Format
Direction
$A
(Auth)
N, max. 23
AN, max. 40
YYMM
N, max. 10
From PMS
From PMS
From PMS
To PMS
N, max. 10
AN, 2 chars
ANS, max. 40
N, max. 5
M, max. 15
Both
To PMS
To PMS
Both
From PMS
M, max. 15
From PMS
$C
Credit Card #
Track 2
Expiry Date
Reference Number
(Approval code)
Guest Number
Answer Status
Clear Text
Sequence Number
Total Posting
Amount
Secondary
Authorization
Amount
Card Usage
From PMS
$I
IN
RT
Merchant ID
Issue Number
Request Type
SD
WS
Start Date
Workstation ID
N, 1 digit
(see EFT Card
Usage Table)
AN, max. 16
N, max. 2
AN, 2 chars
(see Request
Type table)
YYMM
AN, max. 16
N, max. 16
D
T
N, max. 5
AN, max. 16
AN, max. 16
From PMS
From PMS
From PMS
From PMS
From PMS
From PMS
$#
$2
$D
$R
G#
AS
CT
S#
TA
$+
From PMS
Both
From PMS
Both
Both
$B
(Batch
Begin)
$N
DA
TI
S#
$I
WS
Batch Number
Date
Time
Sequence Number
Merchant ID
Workstation ID
42
Record ID Field ID
Description
Format
Direction
$S
(Settle)
Credit Card #
Track 2
Expiry Date
Reference Number
(Approval Code)
Answer Status
N, max. 23
AN, max. 40
YYMM
N, max. 10
From PMS
From PMS
From PMS
From PMS
AN, 2 chars
(see Answer
Status table)
ANS, max. 40
N, max. 10
N, max. 5
M, max. 15
To PMS
N, 1 digit
(see EFT Card
Usage Table)
AN, 16 chars
From PMS
AN, max. 16
N, max. 2
AN, 2 chars,
(see Request
Type table)
YYMM
AN, max. 16
From PMS
Both
From PMS
$#
$2
$D
$R
AS
Clear Text
Guest Number
Sequence Number
Total Posting
Amount
Card Usage
CT
G#
S#
TA
$C
$F
$I
IN
RT
SD
WS
1
2
Audit Trail
Number
Merchant ID
Issue Number
Request Type
Start Date
Workstation ID
To PMS
Both
Both
From PMS
From PMS
Both
Both

not required from other system in Batch response
$Z
(Batch
End)
$N
DA
TI
S#
$I
WS
Batch Number
Date
Time
Sequence Number
Merchant ID
Workstation ID
N, max. 16
D
T
N, max. 5
AN, max. 16
AN, max. 16
From PMS
From PMS
From PMS
From PMS
From PMS
Both
$E
(Batch
entered)
$N
AS
Batch Number
Answer Status
To PMS
To PMS
DA
TI
WS
Date
Time
Workstation ID
N, max. 16
AN, 2 chars
(see Answer
Status table)
D
T
AN, max. 16
To PMS
To PMS
Both
43
Examples
1) Card Type/Usage
Card Type/Usage request from the PMS, Sequence Number (S#) 1, Merchant ID
($I) 00747576, Guest Number (G#) 12345, Credit Card Number ($#)
370000000000002, Expiry Date ($D) 12/01, Track 2 data ($2)
370000000000002=12011231345:
$U|S#1|$I00747576|G#12345|$#370000000000002|
$D0112|$2370000000000002=12011231345|
Card type/usage answer from the EFT to request (S#) 1, Guest Number (G#)
12345, Credit Card Number ($#) 370000000000002, Card Type ($T) VS, valid as
Credit and Debit Card ($C):
$U|S#1|G#12345|$#370000000000002|$TVS|$C5|
Notes: The sequence number (S#) returned by the EFT should be the same as the
one in the PMS request; this allows for multi-threading of requests. If the EFT is
doing card type/usage verification, the card types ($T) no longer use the PMS
hardcoded card types and card number check digit schemes. The card types as
defined in the EFT must be defined also in the PMS configuration and enabled as
Credit Card in Credit Limit. The card usage ($C) values are specified in the EFT
Card Usage Tables below.
2) Authorization
Authorization request from the PMS for the above guest, request made during
Check-In (RT - for Request Type values see table below), Authorize 1000.00 (TA)
as Credit Card ($C):
$A|S#2|$I00747576|G#12345|$#370000000000002|$D0112|
RTCN|$C1|TA100000|$2370000000000002=12011231345|
Authorization answer for Guest Number (GN) 12345, Approved (ASOK),
Approval Code ($R) 0729:
$A|S#2|G#12345|ASOK|$R0729|
Note: The reference number field ($R) when returned in an authorization request is
the approval code.
Authorization request from the PMS for the above guest, request made during
Check-In, Authorize 1000.00 (TA) as Credit Card on a manually entered card (no
$2), with Issue Number (IN) 3 and Start Date (SD) October 2000:
$A|S#2|$I00747576|G#12345|$#370000000000002|$D0012|
RTCN|$C1|TA100000|IN3|SD0010|
44
Secondary Authorization request from the PMS for the above guest for 500 extra
($+), Authorize as Credit Card:
$A|S#3|$I00747576|G#12345|$#370000000000002|$D0112|
RTOT|$C1|TA150000|$+50000|$2370000000000002=12011231|
Note: MICROS-Fidelio Front Office automatically calculates and makes
secondary approvals when necessary (i.e. when postings plus expected charges
covering the rest of the guests stay exceed the previously approved amount).
Both the total amount (TA) and secondary amount ($+) are sent so that the EFT
can decide on the appropriate action based on local floor limits or other factors.
Secondary authorizations can also occur because of manual action taken by the
user.
Authorization request from the PMS, for the same guest, Authorize as Debit Card:
$A|S#4|$I00747576|G#12345|$#370000000000002|$D0112|
RTOT|$C3|TA100000|$2370000000000002=12011231345|
Authorization answer for Guest Number (G#) 12345, Referral
(ASRF/CTREFERRAL):
$A|S#4|G#12345|ASRF|CTREFERRAL|
Authorization answer for Guest Number (G#) 12345, Denied
(ASDN/CTDENIED):
$A|S#4|G#12345|ASDN|CTDENIED|
3) Batch/Online Settlements
Settlement Batch Begin record, Merchant ID (MI) 00747576, Batch # ($N)
0009151:
$B|S#5|$I00747576|$N0009151|DA000915|TI014254|
Settlement request from the PMS, Guest Number (G#) 12345, Card Number ($#)
370000000000002, Expiry Date ($D) 12/01, Settle 315.00 (TA) as Credit Card,
Approval Code ($R) 0729, Track 2 data ($2) included, Audit Trail # ($F)
12345079202:
$S|S#6|G#12345|$#370000000000002|$D0112|RTOT|$C1|
TA31500|$R0729|$2370000000000002=12011231345|
$F12345072902|
Note: In countries where an audit trail/transaction number must be generated for
printout on the guest folio, MICROS-Fidelio currently uses the guest number
combined with the reference number and the last 2 digits of the card number; in
the above example, the audit trail number would be 12345072902. However, the
format of the number may be changed in the future.
45
Acceptance of settlement record (ASOK):
$S|S#6|G#12345|ASOK|
Settlement request from the PMS, Guest Number (G#) 12540, Card Number ($#)
370000000000010, Expiry Date ($D) 12/01, Settle 470.50 (TA) as Debit Card,
Approval Code ($R) 0309, Track 2 data ($2) included, Audit Trail # ($F)
12450030910:
$S|S#7|G#12540|$#370000000000010|$D0112|RTOT|$C3|
TA47050|$R0309|$2370000000000010=12011231345|
$F12450030910|
Acceptance of settlement record (ASOK):
$S|S#7|G#12540|ASOK|
Settlement void request from the PMS, Guest Number (G#) 12723, Card Number
($#) 370000000000002, Expiry Date ($D) 12/01, Settle as Bank Card, credit
Amount (TA) 123.75, Track 2 data ($2) included, Audit Trail # ($F) 1272302:
$S|S#8|G#12723|$#370000000000002|$D0112|$C2|
$2370000000000002=12011231345|TA-12375|$F1272302|
Note: MICROS-Fidelio doesnt support approval codes ($R) for voiding charges.
This also affects the audit trail # ($F).
Acceptance of settlement void record (ASOK):
$S|S#8|G#12723|ASOK|
Settlement End record, Merchant ID ($I) 00747576, Batch # ($N) 0009151:
$Z|S#9|$I00747576|$N0009151|DA000915|TI020254|
4) Batch entered
$E|S#9|$I00747576|$N0009151|DA000915|TI020254|
Note: MICROS-Fidelio expects that if a specific settlement from a batch is
accepted, then it is settled. The Batch Entered record is only to indicate that the
EFT has received the Batch End and done any processing appropriate to Close
Day.
46
Appendix A - FAQ
This section contains answers to frequently asked questions.
Do I have to send the link startup sequence (LD/LR)?

We strongly recommend that the link startup sequence is sent if you receive a Link
Start (LS) record from MICROS-Fidelio. If it is not sent, you will receive only
default records with default formats. There are very few situations where the defaults
are useful, as they are quite limited, not defined in the specification, and may change
at any time. There may be a point where no default record formats are supported.
Which records should I describe in the link startup sequence?

It is best to send a Link Record (LR) for all records that you wish to use, not just the
ones that you will receive, but also the ones that you will send (not currently required,
though helpful for installation and maintenance, and may be required in future
versions). The only records you dont need to describe are the Link records
themselves (LS/LD/LR/LA/LE) and the Database records (DR/DS/DE), these
records have fixed formats and cannot be changed.
What do I include in the Link Record (LR) as Field List (FL) if a record has
multiple uses?
Include all fields in the FL that you will use, regardless of which direction the record
is sent. For example, the Room Equipment (RE) record can be used both to control
Message Lamps (ML), Do Not Disturb (DN), and to report Room Status (RS) from
the external system. The same applies for Guest Data change (GC); it can be used for
Guest Info/Name change and also for Room Moves. Only send one LR for such
records.
Do I have to send the LD/LR/LA sequence every time at startup?

No. This is dependent on what you receive as a response to your Link Start (LS). If
you receive an LS, this means that the MICROS-Fidelio interface has been restarted
while your software was stopped; you must redescribe your record formats. If you
receive a Link Alive (LA) when you send an LS, this means that MICROS-Fidelio
still recognizes your interface. You may resend the LD and LR records if you wish to
change your configuration, or you may just send the LA to finish opening the link.
Shall I answer Link Alive (LA) records with an LA record?

Only if you did not send an LS or LA. This is in most cases sent by MICROS-Fidelio
in response to one of these two records having been sent by the other system
47
What should I do if I receive a <ENQ> at startup?

This means that MICROS-Fidelio has been sending a record, usually a Link Start (LS)
or Link End (LE). If you are using the full-duplex low level protocol, respond with a
<NAK> to indicate that you have not received a valid record. For legacy interfaces
using a half-duplex protocol, you should respond to the first <ENQ> with an <NAK>
to resynchronize the protocol.
Can I receive commands ( e.g. Check-In, GI), right after start up?
You will not receive any records (other than link control records) until the Link Alive
(LA) record is received and answered by MICROS-Fidelio.
Why dont I get guest-oriented messages (i.e. records are sent only for one guest in
the room when there are sharers)?
If the Guest Number field (G#) is not requested in the field lists (FL) for GI and GO,
the interface defaults to using room-orientation. This means that only the first checkin and last check-out will be sent even when there are sharers. In addition, Guest
Change (GC) records will be sent haphazardly, only updating the current primary
guest. If you need guest-oriented information, request the G# field for all three
Record Types (GI, GC, GO).
It is also strongly suggested that if you are using the guest-oriented approach that you
request the Guest Sharer (GS) field in all three records so that your system can do any
necessary processing when there are sharers. This is very important for proper
handling of room moves, and secondary check-ins and check-outs.
Do I need to do an inquiry before posting charges?

If your system can support guest identification through some other means (for
example, virtual numbers used as PIN codes), or if the charges you send are roombased (such as Minibar), then no inquiry is necessary. For restaurant charges,
inquiries should be sent only for payment methods that require guest identification.
For cash or other payment types that are sent for audit purposes (all charges are posted
to a pre-configured account), no inquiry should be sent.
What are the recommended features for POS?

We recommend that POS systems (generally referring to guest-oriented charges)
support inquiries as well as postings. Most hotels are interested in being able to track
charges by time of day; to do this you should include the Serving Time (ST) field to
indicate breakfast, lunch, dinner, or other meal periods. Itemization (i.e. sending
subtotal fields with respective tax and discount fields where applicable for various
menu categories such as food, beverage, etc.) is also considered a high priority by
many hotels. Lastly, many hotels wish to have the transfer of non-room charges such
as cash, EFT, and A/R supported.
48
Can monetary fields contain a decimal character? If not, do they always contain 2
implicit decimal places?
Monetary fields contain no implicit decimal character. As most currencies support 2
decimal places, this is the default behavior. If you work with currencies without
decimal places, you should still include them in monetary fields. If you work with
currencies with more than 2 decimal places, send your amounts as is (but without the
decimal character). MICROS-Fidelio can be configured to scale the charges down by
factors of 10 to obtain the correct amount.
Do I need to send response messages for Wake-ups?

It is strongly recommended that you send them so that if a Wake-up fails, the hotel
staff can be notified to wake the guest by some other means.
What records should be used for Dynamic Virtual Number assignment?

Use the Room Equipment Assign (RA) to assign and unassign Virtual Numbers to
physical telephone lines. The Room Equipment (RE) records can be used to control
COS the same as with fixed telephone extensions.
There are Record Types/fields that we would like to see included in the spec. How
can this be done?
Please contact the MICROS-Fidelio Regional Interface Department at the telephone or
fax numbers, or write us at the addresses provided above.
49
Appendix B - Tables
IF Interface Types
(Used by PMS to determine the screen display for the requested interface type)
Interface
Call Accounting
Key Services System
EFT
Energy Management
Minibar
TMS/PBX Gateway
POS
Pay TV/Extended Video Services
Voice Mail
In-Room Internet Systems
Code
CA
DL
EF
EM
MB
PB
PO
VI
VM
WW
AS Answer Statuses
Code
BM
BY
CD
DN
FX
IA
NA
NF
Interface Type
VSS/remote check-out
Wakeup/
Key Services
EFT
Guest related requests
Guest related requests
All systems
NG
NM
NR
OK
All information requests

Message/Locator request
Wakeup
All systems
RF
RY
UR
EFT
All systems
All requests
Meaning
Balance mismatch
Busy
Check-out date is not today
Request denied
Guest not allowed this feature
Invalid account
Night Audit
Feature not enabled or Check-out
process not running
Guest not found
Message/Locator not found
No Response
Command or request completed
successfully
Referral
Retry
Unprocessable request, this request
cannot be carried out , no retry
GL Guest Languages
Language
English/American
French
German
Italian
Japanese
Spanish
Code
EA
FR
GE
IT
JA
SP
50
KT Key Types
Code
N
D
O
Meaning
New key request. Cancels any existing keys
Duplicate key request. Any existing keys remain valid/active.
One shot key. Key is only valid for use once.
PT Posting Types
Code
C
M
T
Meaning
Direct charge, record must include Total Amount (TA) field
Minibar charge, record must include Minibar Article (MA) field, and
Minibar count(M#), posting is by PMS using article number/count
Telephone charge, record must include Meter Pulse (MP) field, call
charge is calculated by PMS. (Not supported by PR record)
CS Class of Service (COS)

Code
0
1
2
3
Meaning
Barred/hotel internal only
Local
National
No restrictions
MR, VR, TV, SM Guest Rights

Type
MR Minibar rights
SM Seminar channel rights
TV Pay TV rights
VR Video rights
Accepted statuses
MU - unlock Minibar
MN Minibar normal vend
ML - lock Minibar
2 digit numeric field specifying allowed
channel
TU unlimited pay channels (default)
TM - no Pay movies
TX - no Adult movies
TN - no TV rights
VA - view bill & remote c/o (default)
VB - only view bill
VN - no video rights
Notes: Video rights have the following precedence: VN, no rights; VB, view bill
only; VA, all rights (view bill and remote check-out allowed). It is not possible to
block view bill rights and still allow remote check-out.
Pay TV rights have the following precedence: TN, no rights (no TV channels);
TM, all Pay channels blocked; TX, Adult Pay channels blocked; TU, all rights
(includes all Pay channels). With TV rights it is not possible to block normal Pay
channels and allow Adult pay channels.
51
RS Room Maid Statuses

Code
1
2
3
4
5
6
Room Maid Status

Dirty/Vacant
Dirty/Occupied
Clean/Vacant
Clean/Occupied
Inspected/Vacant
Inspected/Occupied
$C EFT Card Usage

Code
0
1
2
3
4
5
6
7
Meaning
No valid usage at this site
Credit card usage only
Bank card usage only
Debit card usage only
Combined credit and bank card
Combined credit and debit card
Combined bank and debit card
All usages
RT EFT Authorization & Settlement Request Types

Code
AR
CN
DP
OT
Meaning
Accounts Receivable
Check-In
Deposit
Other
52
Appendix C - Field ID and Codes Table

Field ID
Description
Format
Record ID
$#
$+
N, max. 23
M, max. 15
$A, $S, $U
$A
AN, max. 40
AN, max. 16
$C
Credit Card Number

Secondary
Authorization Amount
Credit Card Track 2
Fidelio standard Track
2 format
Card Usage
$A, $S, $U
KR,
PR, PS
$A, $S, $U
$D
$F
$I
$N
Expiry Date
Audit Trail Number
Merchant ID
Batch Number
$R
$T
A0 A9
Reference Number
(Approval Code))
Card Type
User Definable Fields
AS
Answer Status
AN, 2 chars
(see Answer Status table)
BA
Balance Amount
BD
BI
C#
CL
Item Description
Item Amount
Check Number
Credit Limit
CO
CS
Credit Limit Override

Class Of Service
CT
Clear Text
N, max. 20
M, max. 20
(may include decimal point
depending on local currency)
AN, max. 25
N, max. 20
N, max. 8
M, max 15
(may include decimal point
depending on local currency)
AN, 1 char (Y/N)
AN, max. 1
(see COS table)
ANS, variable
(depends on usage)
CV
Number Of Covers
$2
N, 1 digit
(see EFT Card Usage Tables)
N, 4 chars. (YYMM)
AN, 16 chars
AN, max. 16
N, max. 16
$A, $S, $U
$S
$A, $B, $S, $U, $Z
$B, $E , $Z
N, max. 10
$A, $S
AN, 2 chars
ANS, variable
$U
GC (Guest Info/Name Change), GI,
KR,
PL
$A, $E, $S,
KA,
LP,
PA,
XC (RCKO Response),
WA
XB, XC (RCKO request), XO
PL
N, max. 5
XI, XO
XI, XO
PA, PL, PR, PS
PL
PR, PS
RE
$A, $S,
KA,
LO, LP,
PA, PS,
RE (VM, DN, RS),
XC (RCKO response)
PR, PS
53
Field ID
Description
Format
Record ID
D1 D9
DA
Discount 1 9
Date
M, max. 15
D
PR,
$B,
DE,
GC,
KA,
LA,
LF,
NS,
PA,
XB,
XM,
WR,
XI,
PS
RE
DC
DD
DN
Department Code
Dialed Digits
Do-Not-Disturb Status
DT
Departure (Check-out)
Time
Duration
Equipment Number
Equipment Status
DU
EN
ES
N, max. 4
N, max. 23
AN, max. 1
(Y, enable/N, disable)
HH:MM (as defined in PMS)
PR, PS,
XD, XI, XL,
XR, XT,
WA
KR (KTN, KTD)
PS
RA
RA
AN, 1 char (Y/N)

ANS, variable
ANS, 1 char
N, max. 10
XI, XO
LR
LD
$A, $S, $U,
KD, KR (KTN, KTD), GI, GC,
GO,
LO, LF, LP,
PR, PL, PA,
RE (ML),
XB, XC, XD, XI, XL,
XM, XO, XR, XT
KR (KTN, KTD),
PL
KR (KTN, KTD),
PL
GC (Guest Info/Name Change), GI
KR,
PL
PL
KR (KTN, KTD),
PA (Response to PR ), PL, PR
FD
FL
FS
G#
GA
Guest Arrival Date
GD
Guest Departure Date
GF
GG
Guest First Name

Guest Group Number
ANS, max. 20
AN, max. 10
GL
Guest Language
GN
Guest Name
AN, max. 2
(see Guest Language table)
ANS, max. 40
$Z,
DS,
GO,
KR,
LE, LS,
LP,
T
AN, max. 8
AN, 1 char
(A, assign/U, unassign)
N, 1
Window/Folio
Number
Item Display Flag
Field List
Field Separator
Guest Number
F#
PS
$E,
DR,
GI,
KD,
LD,
LO,
NE,
PL,
XC,
XO,
WC,
XO
XI, XO
54
Field ID
Description
Format
Record ID
GS
GT
GV
Share Flag
Guest Title
Guest VIP Status
AN, 1 char (Y/N)

ANS, max. 20
AN, max. 3
ID
IF
User ID
Interface Family
IN
K#
KC
KO
Issue Number
Key Count
Key Coder
Key Options
AN, max. 16
AN, 2 chars
(see Interface Type table)
N, max. 2
N, max. 2
AN, max. 8
AN, max. 20
GC, GI, GO
PL
PA, PL, PR, PS
LD
KT
Key Type
LT
M#
MA
MI
ML
MP
MR
Locator Expiry Time

Number Of Articles
Minibar Article
Message ID
Message Light Status
Meter Or Tax Pulse
Minibar Rights
MT
P#
Message Text
Posting Sequence
Number
Posting Call Type
Inquiry Data
Payment Method
PMS Payment Method
Printer Port
Posting Type
PC
PI
PM
PP
PT
PX
RI
RL
RN
Posting Route
(i.e. Trunk)
Record ID
Maximum Record
Length (specifies the
overall max. length of
records for a specific
system
Room Number
AN, max. 1
(see Key Type table)
T
N, max. 2
N, max. 4
N, max. 8
AN, 1 char (Y/N)
N, max. 10
AN, 2 char
(see Guest Rights table)
ANS, variable (max 1000)
N, max. 4
$A, $S
KR
KA, KD, KR
KR (KTN, KTD)
KR
LO, LP
PR, PS
PR, PS
XD, XL, XM, XT
RE
PS
RE (Minibar)
XL, XT
PA, PL, PR, PS
AN, 1 char
AN, max. 10
AN, max. 5
AN, max. 5
N, 1
AN, 1 char
(see Posting Type table)
N, max. 6
PR, PS
PR
PR, PS
PL
RE (VM, DN, RS)
PR (except PTT), PS
ANS, 2 chars
N, variable
(max. record length is 2000)
LR
LD
AN, max. 8
GC,
RA,
KD,
LF,
PA,
XB,
XM,
WA,
PS
GI,
RE,
KR,
LO,
PL,
XC,
XO,
WC,
GO,
LP,
PR, PS,
XD, XI, XL,
XR, XT,
WR
55
Field ID
Description
Format
Record ID
RO
RS
Old Room Number

Room Maid Status
GC (Room Move)
RE
RT
Request Type
S#
S1 S9
SC
SD
SF
Sequence Number
Subtotal 1 9
Service Charge
Start Date
Swap Flag
SM
Seminar Channels
SO
ST
T#
T1 T9
TA
TI
Sales Outlet
Serving Time
Table Number
Tax 1 9
Total Posting Amount
Time
AN, max. 8
N, 1
(see Room Maid Status table)
AN, 2 chars,
(see Request Type table)
N, max. 5
M, max. 15
M, max. 15
YYMM
No data (if this field is sent, the
record is part of a DB swap)
N, 2 digits
N, max. 5
N, max. 4
N, max. 4
M, max. 15
M, max 15
T
TP
TV
Tip
TV Rights
V#
VM
VR
Vendor Version
Number
Voice Mail
Video Rights
WS
Workstation ID
M, max. 15
AN, 2 char
AN, max. 10
AN, max. 4
AN, 2 char
AN, max. 16
$A, $S
$A,
PR,
PR,
$A,
GI,
$B, $S, $U, $Z

PS
PS
$S
GO

PA, PL, PR, PS
PR, PS
PR, PS
PR, PS
PS, PR, $A, $S
$B, $E, $Z,
DE, DR, DS,
GC, GI, GO,
KA, KD, KR,
LA, LD, LE, LS,
LF, LO, LP,
NE, NS,
PA, PL, PR, PS,
XB, XC, XD, XI, XL,
XM, XO, XR, XT,
WA, WC, WR
PR, PS
RE
LD
RE
$A, $B, $E, $S, $U, $Z
KA, KD, KR,
PA, PL, PR, PS
56

Fia

Uploaded by

Copyright:

Available Formats

Fia

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Fia

Uploaded by

Copyright:

Available Formats

MICROS-Fidelio Interface Application Specification V1.

FIDELIO TECHNOLOGIES, INC.

Interface Application Specification

MICROS-Fidelio Interface Application Specification V1.50

Room Data .............................................................................................. 25

MICROS-Fidelio January 2001

MICROS-Fidelio Interface Application Specification V1.50

Micros-Fidelio GmbH & Co. KG

Micros Fidelio Asia Pacific

Information in this document is subject to change without notice.

Copyright 2000 MICROS-Fidelio. All Rights Reserved.

MICROS-Fidelio January 2001

MICROS-Fidelio Interface Application Specification V1.50

Version 1.00 first draft, overview, Record and Field Types

MICROS-Fidelio January 2001

MICROS-Fidelio Interface Application Specification V1.50

General Transmission Layer Considerations

MICROS-Fidelio January 2001

MICROS-Fidelio Interface Application Specification V1.50

ANS - All characters, the entire printable ASCII character set

T - Time, numeric characters, formatted as HHMMSS

MICROS-Fidelio January 2001

MICROS-Fidelio Interface Application Specification V1.50

MICROS-Fidelio January 2001

MICROS-Fidelio Interface Application Specification V1.50

MICROS-Fidelio January 2001

MICROS-Fidelio Interface Application Specification V1.50

determines the display of the PMS Interface system

MICROS-Fidelio January 2001

MICROS-Fidelio Interface Application Specification V1.50

MICROS-Fidelio January 2001

MICROS-Fidelio Interface Application Specification V1.50

Implementation Notes & Exceptions

MICROS-Fidelio January 2001

MICROS-Fidelio Interface Application Specification V1.50

MICROS-Fidelio January 2001

MICROS-Fidelio Interface Application Specification V1.50

MICROS-Fidelio January 2001

MICROS-Fidelio Interface Application Specification V1.50

MICROS-Fidelio January 2001

MICROS-Fidelio Interface Application Specification V1.50

mandatory for guest-oriented systems

MICROS-Fidelio January 2001

MICROS-Fidelio Interface Application Specification V1.50

Old Room Number AN, max. 8

mandatory for guest-oriented systems

MICROS-Fidelio January 2001

MICROS-Fidelio Interface Application Specification V1.50

MICROS-Fidelio January 2001

MICROS-Fidelio Interface Application Specification V1.50

Extended Guest Data

Guest message text and other details online

MICROS-Fidelio January 2001

MICROS-Fidelio Interface Application Specification V1.50

AN, 1 char (Y/N)

MICROS-Fidelio January 2001

MICROS-Fidelio Interface Application Specification V1.50

AN, 1 char (Y/N)

- sent from PMS to show status of request

MICROS-Fidelio January 2001