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.

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

Let's take for an example the hotel "Hôtel Golf Château de Chailly".
After calling the "rules/getAll" and "products/getAll" we see that the product "6c5ed799-2e8a-4a18-8325-ac7a0086a886" is applied for "ResourceCategoryType" equals to "Room" and "Suite". But it's not added to the price displayed on the booking engine, for example, for tarif "7c58c0e7-64f2-41d6-aaff-ac6f00c31da1" and room "7599d179-e235-4894-9310-ac6f00c320ff".

You colleague explained us that this product is the city tax. And as this product has the option Exclude price from offer so only the price of the room will appear on the distributor.

But how can we know if the product has this option (Exclude from offer) or not? By calling "products/getAll" and "rules/getAll" we don't receive any field which inicates it. Your colleague also confirmed that this information is not returned in your API response at the moment. So please include it.

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.

Most other PMS's (all using HTNG standard and most custom APIs) can provide a simple Date : Room Type : Out of Order count.

So like:

2021-06-30: King: 1 OOO
2021-06-30: Queen: 0 OOO

Mews requires storage of resourceBlocks, mapping of room numbers to resource categories, and storage of unique IDs for every OOO room. This is much more complex than other partners, and would require a whole new inventory architecture to support.

Now that you've added an Adjustments extent: would be great to be able to pull total Out of Order counts by date and by roomtype via getAvailability as well.

Integration partners can retrieve the estimated transaction fee via accountingItems/getAll, with CreditCardTransaction extent.

The "Fee" parameter gives the estimated transaction fee value. (https://mews-systems.gitbook.io/connector-api/operations/finance#credit-card-transaction)

However, with the recent feature release of transaction fee adjustments for select properties, the updated fees are not returned, and can cause discrepancy between data in Mews PMS and in other systems (e.g. accounting, business intelligence, etc).

In the exported Payment Report, "Fee total net"/"Fee total" refers to the estimated transaction fee and will be displayed "Fee" parameter in the CreditCardTransaction object. On the other hand, "Adjusted total fee" in the same report refers to the actual transaction fee (updated after 3 days) and is currently not returned in the API response.

https://help.mews.com/en/articles/4682847-track-your-fees-with-the-payment-report-export