The DV2000 provides several features and utilities that support using the system in a hospitality environment:
The DV2000 is primarily a room-based environment. Each room mailbox represents a single room which may contain zero or more guests.
On check-in, the mailbox is marked as occupied and, depending on the data included in the command, may set the guest name and password and perform several other actions. A subsequent check-in would overwrite the old name and password with the new ones. In other words, if the PMS sends a check-in command for each guest in the room, the last guest to check in is the one whose name is stored in the mailbox (and, if relevant, sent to the PBX).
Likewise, on check-out the entire mailbox is cleared, regardless of how many guests may be in the room. Subsequent check-outs would perform all the same actions (clearing messages, resetting the password and text message count, clearing the name, etc.) except it would not archive any messages; archiving only happens when a check-out is sent to a room mailbox that is marked as occupied.
Room move is also handled on a per-room basis, not per-guest. That is, if a room move is received, then the wakeup call, messages, guest name, language selection, password, text message count, and any group membership are all copied to the new room. After that, the original room is checked out, unless the command sent by the PMS is one that expects the original room to remain checked in.
Other specialized PMS commands such as change name, change language, change phone class of service, set wakeup call, and so forth, are all handled on a room-oriented basis as well. For example, a command to change the name will change the name in the mailbox (and, if relevant, on the PBX) and the original name will be discarded.
When the DV2000 is configured to link with a PMS using the Oracle FIAS 2.20 protocol, a guest-based approach to managing rooms and guests is required. Consequently, the DV2000 offers limited support for guest-based management for this case.
What this means in practice is that most commands sent from the PMS specify a unique guest ID in addition to the room number. So in the case of the check-in command, the Opera will send a check-in for each guest who will occupy the room. The DV2000 will store the name of the first guest in the mailbox (and, if relevant, will send it to the PBX). For each subsequent guest, the name, guest ID and any other data will be stored in a database table but will not be sent to the PBX or otherwise used, except to track whether the room is occupied.
When a check-out is received, if the guest ID is the primary guest (that is, the one stored in the mailbox), then the system will clear that guest out of the mailbox and the database and will then select one of the other guests in the database to become the primary guest. That guest's name will be placed in the mailbox and sent to the PBX (if relevant). When a guest is checked out and there are no more guests in the database, then the mailbox will be fully checked out and marked as vacant.
How a room move is handled depends on the status of the destination room. If it is occupied, then the guest is moved to the new room and the messages, text message count and wakeup calls are all moved over to the new room but no other changes are made (no change to the language, the phone class of service, the guest name in the mailbox or the mailbox password). If the room is vacant, then the guest will be checked into the room as the primary guest, and all relevant data is copied to the room: guest name, password, language, text message count, voice messages, and wakeup calls. In either case, if the original room is now vacant then it will be checked out. If it is not vacant but the guest who moved was the primary guest, then one of the remaining guests will be selected as the primary and his or her name will be set as the guest name and sent to the PBX (if relevant).
The room mailbox type, which uses the Guest COS template by default, provides the following features:
If you change the COS template to Extended Stay, the mailbox acts the same as above, but with the following exceptions:
Mailboxes can be created either by using the DV2000 Manager application on the DV2000 system or using the Web UI from with a web browser.
An alternate method that may work in some cases is to let the system auto-create the mailboxes based on input from the PMS. This method has the following requirements:
To use this method, open DV2000 Manager and follow these steps:
The DV2000 provides the ability to translate from the room (or extension) numbers sent by the PMS to the mailbox numbers it uses, and vice-versa. This is done using a translation table that maps the room number directly to the mailbox number using simple substitution.
For sites with multiple PMS instances, there is a separate hospitality server instance for each PMS, each with its own configuration and translation table.
Configuration of PMS translation tables is done using the DV2000 Manager application, under Features / Hospitality / Translation.
On receipt of any message packet from the PMS, if the message contains a room number the system will perform a forward lookup in the translation table. If the given room number is found, it will be replaced with the associated mailbox number before the command specified by the message is processed.
The PMS translation table provides a many-to-one relationship for room numbers to mailbox numbers. This means that every room number maps to one and only one mailbox number, but multiple different room numbers can map to the same mailbox number.
For example, the following translation table is entirely valid:
| Room Number | Mailbox Number |
|---|---|
| 71101 | 1101 |
| 81101 | 1101 |
| 21101 | 1101 |
In this case, the room numbers 71101, 81101 and 21101 all map to mailbox 1101. This is valid.
In some cases, a room may have multiple physical phones, each with its own extension, and the PMS may be sending commands with extension numbers rather than room numbers. This can be handled using a translation table similar to that shown above. In this case, 71101, 81101 and 21101 are all extensions in room 1101 and the PMS may send a check in for each extension rather than a single check in for the room number. Using a translation table like this allows the VMS to map all 3 extensions onto one mailbox.
If a PBX link is also being used to pass phone control states, name changes, and so forth to the PBX, you would need to assign each extension to the MWI address fields in the mailbox as well, because translations are not supported for the PBX link.
In the example above, you could assign 71101 to the address MWI 1, 81101 to MWI 2 and 21101 to MWI 3, all in mailbox 1101. If there is a hunt group associated with the room, say 1101, then you should assign it to the Extension field on the owner settings page (which will also assign it to MWI 0 automatically). The Extension field is used when dialing wakeup calls, so it should always be assigned the extension (or hunt group) that should be dialed for the wakeup calls.
Whenever the system needs to send a message to the PMS for a room, it will perform a reverse lookup in the translation table to get all room numbers associated with the given mailbox number. A message will then be generated and sent to the PMS for each room number found.
Using the example in the previous section, if the system needed to pass a housekeeping status change on to the PMS for mailbox 1101, it would look for 1101 in the translation table (searching on the mailbox number field). It would find 3 entries, for rooms (or extensions) 21101, 71101 and 81101. It would then send a maid status update message for each one. The same process would apply for voice message count updates.
If no translations are found for a given mailbox number, then a single message will be sent using the mailbox number as the room number.