Micros 3700 or 4700 POS Interface Support to MyPMS

The MICROS 'standard' (term used loosely) is used by many global POS vendors, we find, and is sufficient for most Property Management System interfacing. Attached to this article is the actual MICROS documentation that we use for this interface, called "FIAS_2.12 5.chm". You may need to find a viewer for this type of application. Just look for an application that can open .chm file types for your OS (Mac or Windows).

As a 'cloud' program running this as a TCP/IP service, the following will guide you in analyzing support for, and deploying, this interface:

• The Micros spec is a result of serial communications and when they adapted it to tcp/ip they maintained all the same conventions even though they were redundant. So, when talking to the Property Management System, a POS system needs to be mindful of this and know that asynchronous communication is not allowed. The thing about keeping the connection up is kind of wacky. If we were talking to Fidelio (the Property Management System Micros initially deployed this against), the POS would open a socket and never close it. In order to prevent it from closing in the tcp/ip world, BookingCenter would need to send keep alive messages all the time. We don't want to do this - it's too chatty.

• BookingCenter is the 'server' and the POS system is the 'client'. The POS sends a message to us. We respond. Because we are a centrally-hosted 'cloud' service, and your POS is as well, we can open up ports between our test/production environments to allow these messages to pass between us in a secure manner.

• We ignore the persistent connection requirements, as our server can handle more than a single connection at a time. The POS client opens a socket when needed. For load balancing, we can have as many ports open as needed and we will set the specific port for each install of your POS somewhere in your POS setup. You must be able to define a host, port, and Sales Outlet (SO) to make the interface work.

• Since our Server is listening for connections from the POS, BookingCenter needs a Site Identifier to know which POS the hotel message is coming from. On the Micros spec, we use the SO Sales Outlet, for our Site/Property ID (a 3-7 ctr alpha code). We use the WS Workstation ID, for the ID of the device/user the posting came from (ie, the actual 'server' issuing the posting from your POS).

• At least one Category Code is required to post to a foio.  We 'map' Category Code1, for example, to FOOD in the PMS.  Thus, the contents of the FOOD posting would appear on the folio using whatever description was set for the Item + the ticket number sent from the POS system.  So, if the FOOD item mapped to Category1 was described in MyPMS as 'Food Charge', and the ticket number from the POS was: 12345, then the guest would see a Folio posting as "Food Charge - 12345" and the amount an quantity field from the POS system.

• There are two types of transactions used from the attached spec--- the inquiry and the posting.

--------------------
--> The Inquiry. The inquiry returns a list of guests for the room and the post returns a success or failure.
--------------------

In both cases the POS sends a PR message. If the PI field is set [the format is PI + ROOM NUMBER], this basically means this is an inquiry only. BookingCenter will reply with a PL message.

Here is an example of the PR Inquiry + PL list answer:


• Posting Request (Inquiries)/List/Answer

Posting Request from POS Sales Outlet (SO) 123, Terminal (WS) 456, User ID Eli, for Room (PI) 2781 using PayMethod (PM) ROOM:

PR|SO123|WS456|IDELI|PI2781|DA000915|TI124254|P#1734|PMROOM|

List of guests (PL) in Room (RN) 2781:

PL|SO123|WS456|IDELI|RN2781|G#12345|GNGuest, Mr.|RN2781|G#12381|GNSharer, Mr.|P#1734|

As seen in the example above, if guests matching the PI search criterion are found, the list is formatted as Room Number (RN)/Reservation 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/Reservation 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>|

So much for the Inquiry.

--------------------
--> The Posting.
--------------------

Once the POS has obtained the Guest List, the POS has enough info to generate the PR Post. A response in this case is a PA message.

Here is one of the PR + PA examples:


• Posting Request (Charges)/Answer

Posting request from POS for Room (RN) 2781 with Reservation 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|P#1737|PMROOM|

Posting accepted (ASOK):

PA|SO123|WS456|IDJOSH|RN2781|G#12875|GNGaribaldi, Mr.|ASOK|DA000915|TI124254|P#1737|

Note: In all cases, the sum calculated by adding all subtotal, tax and discount fields (which means the amount in a discount field should be negative) must equal the Total Amount (TA) field (see check splitting example below).

The interface calculates as follows:

TA = S1 + [S2] + [S3] + T1 + [T2] + [T3] + D1 + [D2] + [D3]

e.g.:
|TA1000|S1800|D1-200|T1400|

=> 10.00 = 8.00 - 2.00 + 4.00


So much for the Posting.

For a general overview of this interface, please see the article: https://support.bookingcenter.com/index.php?/Knowledgebase/Article/View/480