Multiple Environments
ResRequest provides two types of environment (Reservations and Property) within which a user can operate. The environment is inherently determined by the server that the user logs on to.
There can only be one Reservations environment and it may incorporate multiple servers. There is always a web server (WB) and there can be any number of offline servers (R*). There is often a RS server and on rare occasions we may have clients with additional R* servers. This happens when the client has multiple reservations office locations that are not able to operate on the web.
When we have multiple servers within the reservations environment we have a situation where users are working concurrently on independent instances of the database. This represents a threat to data integrity because users on different servers could update the same data within the same time. When the databases are synchronised (via data transfer) one user’s changes will be overwritten.
To guard against this possibility we have the concept of master status. Master status can be viewed as a token that can be passed between the reservations servers and only the server that holds the token is authorised to edit data. On a server that does not hold master status new data can be added but existing data cannot be edited / changed. For example you could add a new reservation but you could not change the name of an existing reservation.
This is not a foolproof safeguard. An example of the risk is if there is one remaining room available on a particular day, it could be booked concurrently by users on different servers, resulting in an overbooking. The longer the gap between data transfers, the greater the possibility of this situation occurring.
All servers within the reservations environment share data ownership. This means that data created on any of the servers can be updated on any of the other servers (subject to the master status control). This is in contrast to data created in a property environment, which cannot be updated in the reservations environment.
A principal may have any number of Property environments and each environment can be represented by only one server. Therefore, the concept of master status does not apply within property environments. Effectively, a property server is always the master of its own data. This means a user can always update data that is owned by (was created in) that environment. They can never update data owned by any other environment.
Property Environments
Each Property environment has ownership only of its own data. For example, a user at property A cannot receipt cash at property B. That said, users on property environments may receipt cash, add extras and add notes on any bookings made in reservation environments. Any additions made that carry a charge will result in a new folio being created that may only be invoiced at the property that created it. Consequently, Property environments may be set up with their own distinct invoicing units. Invoices generated on a property server will always have their own invoice number sequence.
Working with the financial interface
If you are using the Financial Interface, i.e. exporting journals or invoices to your accounting system, you have the option of restricting the processing of financial transaction batches to a specific environment. This is unrelated to the creation of the financial transactions, which is inherent in the invoicing and receipting processes. The restriction applies specifically to mapping ResRequest codes to financial accounts, placing transactions in batches and exporting those batches.
So we can see that ResRequest’s technical architecture automatically consolidates your financial data from any number of locations, while separating the data access rights of different parts of the organisation. This enables you to produce comprehensive financial reports and to integrate electronically with your accounting system.
Visit our website
