This task would be to expose a new flag in the

https://mews-systems.gitbook.io/connector-api/operations/finance#get-all-bills

API Endpoint that would determine whether a particular bill item originated from POS.

You may need to have this flag set to true when items are pushed into Mews.

What's our Use Case?

We want to be able to retrieve bill items that have originated in POS to Mews and we'll use Mews' interface to receive this information.

However, we only want POS specific items, other items not originating from POS we don't want.

Alternatively, there may be an option to get a list of interfaces that the Mews account is currently connected to. And perhaps have an origin ID or something that could associate back to the list of interfaces.

This could assist us greatly in managing revenue between both systems.

External systems that have group room blocks typically allow groups to go through a series of statuses that determine whether the blocked rooms should be taken from inventory. This is important as once a hotel promises a number of rooms to a group, it has to make good on that promise.

With the way availability is updated in Mews currently, space categories can be overblocked and cause our users to fail to have all promised rooms available for their guests.

Example:

1. Hotel has space category "King Villa" with 10 rooms available for every day in July

2. External system creates an availability block "A" for July 1st to July 5th, blocking 10 "King Villa" rooms for each day

3. Group "A" in the external system has its status marked as "Definite", which in this example means the contract has been signed and those rooms are promised to the group.

4. External system creates an availability block "B" for July 4th to July 8th, blocking 5 "King Villa" rooms for each day. Despite July 4th and 5th having all their rooms blocked by a definite group, this availability will be successfully blocked in Mews.

5. Reservations for the "B" block get created in Mews before reservations for "A" get created

6. When a user tries to create reservations for the July 1st to July 5th for the "A" block, not all of the inventory will be available.

In Mews there needs to be some type of overbooking prevention or statuses on availability blocks to determine whether their availability adjustments should take priority over other block's availability adjustments.

Connector API does not have an endpoint for updating an availability block. There are only endpoints for creating (availabilityBlocks/add), deleting (availabilityBlocks/delete) and updating its service availability (services/updateAvailability).

Some reasonable use cases for updating an availability block would be:

1) Block created for 5 days. After some time the sales person needs to extend the block with, let's say, one day pre and two days post, so the block becomes 8 days long.

2) Update the release date of the block.

3) Update the booking notes with some special instructions which has been assigned later.

4) Update the block's name (in case of typo or whatever reason).

These are some of the scenarios where the block itself needs to be modified. The scenarios are very common in all property management systems which manage group blocks.

A workaround like deleting the block and re-creating it with the new data wouldn't work for several reasons:

• Already linked blocks may be sent again and mess up the hotel's general availability.
• If the block has active reservations, it can't be deleted. So, to do, let's say, a simple modification of the release date, the vendor must cancel all reservations, then the block, then to create them back as fresh block and reservations in order to simply change the cutoff date.
• Potential reporting mismatches.

When a POS is sending a product to post in Mews, the product must have an accounting category in the POS and Mews. If there is no accounting category set in POS, then the item as well as any other items in the Cart are not posted in Mews.

In other POS systems, if an accounting category is accidentally not created in the POS, the PMS will accept the product as well as the full cart of items but place the item in a "None" category or "Uncategorized", allowing the charge. Similar to what Channel Managers do with Mews. If a rate code was built in CM, but not in Mews, the reservations is still pushed into Mews but the rate code and market segment is changed to the default rate code and market segment used by the property.

This is often overlooked during a testing phase as the assumption is that like other PMS systems (Opera, OnQ) respond the same if an accounting category has not been set in the POS.

There are some endpoints (for example: the /reservations/search endpoint) that allow us to query certain objects like reservations that were created or modified in a certain time interval. If the time interval causes Mews to fetch too many objects, it will return a 408. This can be less straightforward for the caller as the caller does not know in which time interval most creations/modifications happened and the caller will thus keep calling the endpoint until the time interval is finally small enough for the request to succeed. As you can see, this can/will result in several consecutive failing calls which results in a longer wait time for the caller (you need to wait for the response to know if the time interval is ok and if not, you actually waited for nothing) and several unnecessary queries in your database as the result isn't used.

To overcome this, we would like to suggest adding pagination to your endpoint. Pagination means that you will only return X objects in the response (lowering the impact on your database) and let the user know if there are more objects that match the time interval filter so they can crawl the next page. This means that each call be the caller will also be successful and the wait wasn't for nothing

The current rates/getall API call does not bring up the Rate Description and Rate Segment.

Regarding the Segment: Arguably, someone could link the rates response to the reservations response and grab the Segment of the rate from the reservations it's linked to. The issue however is that once a rate is applied to a reservation, the user can go to the reservation and change the segment field, which leads to different segments on the reservation level and the corresponding rate level.

Regarding the Descriptions: It would be useful if we can have the Rate Descriptions in the rates/getall API response for reporting.

Mews now send and API call to Hotek Key cutter for only one key at a time, if you want to create multiple keys at a time it send it separately and not in one command. We check with Hotek and they confirmed to us that Mews send multiple keys creating in different commands and not in one command. This cause a lot of irritation with people at the reception, because it's not clear when the first key is created and when they need to put the second key on the card reader. Allowing duplicate keys is not and option as lost card or stolen card are not deleted from the system and still has access to the room creating a security issue.