CHM API extensions - due to Choice implementation #180
Conversation
| "availabilityBlockCode": "Channel-manager-Wedding123", | ||
| "availabilityBlockConfirmationNumber": "Mews-Wedding123", |
There was a problem hiding this comment.
they are documented, were just not in the example
| "loyaltyCode": "PG60972345", | ||
| "loyaltyInfo": { | ||
| "membershipId": "PG60972345", | ||
| "programCode": "BWR", | ||
| "tierCode": "Gold" | ||
| } |
There was a problem hiding this comment.
was added to wrong level. only for main customer (as documented)
| @@ -135,8 +129,7 @@ This option allows creations, modifications, and partial or complete cancellatio | |||
| "title": "Misses", | |||
| "nationalityCode": "US", | |||
| "languageCode": "en-US", | |||
| "telephone": "1-369-81891", | |||
| "loyaltyCode": "PG60972345" | |||
There was a problem hiding this comment.
incorrect placement, moved to main customer
| @@ -86,14 +88,6 @@ This option allows creations, modifications, and partial or complete cancellatio | |||
| } | |||
| } | |||
| }, | |||
| "paymentCard": { | |||
There was a problem hiding this comment.
this is not sent here. Replaced with PaymentCardData on Reservation level
| "number": "4111111111111111", | ||
| "type": 1 | ||
| }, | ||
| "paymentType": 1, |
There was a problem hiding this comment.
Not sent in res sync
| "loyaltyCode": "PG60972345", | ||
| "loyaltyInfo": { | ||
| "membershipId": "PG60972345", | ||
| "programCode": "BWR", | ||
| "tierCode": "Gold" | ||
| } |
There was a problem hiding this comment.
same here, example had it on incorrect place
| @@ -277,7 +278,8 @@ The third `reservation` definition shows the partial cancellation - cancelling t | |||
| | Property | Type | Contract | Description | | |||
| | :-- | :-- | :-- | :-- | | |||
| | `membershipId` | `string` | required | Loyalty membership identifier of the Customer. | | |||
| | `programCode` | `string` | required | Loyalty program code. | | |||
| | `programCode` | `string` | optional | Loyalty program code. | | |||
| | `tierCode` | `string` | optional | Loyalty tier code. | | |||
There was a problem hiding this comment.
added 1 more field, present in the examples for both direction
| | ~~`adultCount`~~ | ~~`int`~~ | ~~required \(exc. Cancellation\)~~ | ~~Number of adults in the reservation.~~ **[Deprecated!](../deprecations/README.md)** | | ||
| | ~~`childCount`~~ | ~~`int`~~ | ~~optional \(exc. Cancellation\)~~ | ~~Number of children in the reservation.~~ **[Deprecated!](../deprecations/README.md)** | |
There was a problem hiding this comment.
Since this reservation object is shared with res sync from the CHM operations, I moved this to a specific section, as this is supported for only 1 direction (CHM -> Mews)
mews-operations/reservations.md
Outdated
| | `timeState` | `int` | required | [Reservation Time State](#reservation-time-states) code of reservation state. | | ||
| | `paymentCardData` | [`Payment Card Data`](#payment-card-data) object | optional | Represents the payment card of the [`Customer`](#customer) to cover for the booking. | |
There was a problem hiding this comment.
new fields for Res sync only
changelog/README.md
Outdated
|
|
||
| * [Availability block](/channel-manager-operations/availabilityBlock.md#availability-block) extended with `notes` field. | ||
| * Customer [Loyalty info](/mews-operations/reservations.md#loyalty-info) extended with `tierCode` field. | ||
| * [Reservation synchronization](/channel-manager-operations/reservations.md#process-group) operation was extended with [`timeState`](/mews-operations/reservations.md#reservation-time-states) field and [`paymentCardData`](/mews-operations/reservations.md#payment-card-data) object in [`Reservation`](/mews-operations/reservations.md#reservation) object. |
There was a problem hiding this comment.
I would prefer to call the operation by the name as it appears in the docs, and where the same operation appears on both sides, to use the prefix 'CHM:' or 'Mews:'
| * [Reservation synchronization](/channel-manager-operations/reservations.md#process-group) operation was extended with [`timeState`](/mews-operations/reservations.md#reservation-time-states) field and [`paymentCardData`](/mews-operations/reservations.md#payment-card-data) object in [`Reservation`](/mews-operations/reservations.md#reservation) object. | |
| * [CHM: Process group](/channel-manager-operations/reservations.md#process-group) operation was extended with [`timeState`](/mews-operations/reservations.md#reservation-time-states) field and [`paymentCardData`](/mews-operations/reservations.md#payment-card-data) object in [`Reservation`](/mews-operations/reservations.md#reservation) object. |
| @@ -224,14 +232,15 @@ This option allows creations, modifications, and partial or complete cancellatio | |||
| | `availabilityBlockConfirmationNumber` | `string` | optional | Unique identification of the availability block in the Mews. | | |||
| | `currencyCode` | `string` | required \(exc. Cancellation\) | 3 letter code of currency of all prices within the booking. | | |||
| | `totalAmount` | [`Amount`](../mews-operations/reservations.md#amount) object | required \(exc. Cancellation\) | Total amount of the whole booking. | | |||
| | `paymentType` | `int` | required \(exc. Cancellation\) | [Payment Type](../mews-operations/configuration.md#payment-types) code - determines whether the booking is prepaid or not. | | |||
There was a problem hiding this comment.
Is this field being deprecated? Or is there some reason we are not marking it as a deprecation?
There was a problem hiding this comment.
It is never passed, it was never used. It is used on the Mews side (it was copied here incorrectly).
There was a problem hiding this comment.
shouldn't have been here in the first place, copy paste issue (same like the payment card above)
| | `customer` | [`Customer`](../mews-operations/reservations.md#customer) object | required \(exc. Cancellation\) | Represents the main booker. Does not necessarily mean that the person arrives to the property. | | ||
| | `sources` | [`Source`](../mews-operations/reservations.md#source) collection | optional | Represents the sources for the booking. | | ||
| | `company` | [`Company`](../mews-operations/reservations.md#company) object | optional | Represents the company associated with the booking. | | ||
| | `travelAgency` | [`Travel Agency`](../mews-operations/reservations.md#travel-agency) object | optional | Represents the travel agency associated with the booking. | | ||
| | `reservations` | [`Reservation`](../mews-operations/reservations.md#reservation) collection | optional | Each reservation within the booking. If the value is null or an empty collection, this implies that the whole group will be cancelled. | | ||
| | `comments` | `string` collection | optional | Represents any comments related to the booking. | | ||
|
|
||
| Note that there are some [additional fields](../mews-operations/reservations.md#synchronization-specific-fields) in [`Reservation`](../mews-operations/reservations.md#reservation) object for this direction. Otherwise the `Reservation` object is the same for both directions. |
There was a problem hiding this comment.
Can we move this note into the description for the operation at the top? That helps us to maintain the structure of the docs, I'm trying to avoid adding additional paragraphs. Thks.
There was a problem hiding this comment.
it is not about deprecations. There are fields that are used on Mews side only, and some field used on Choice side only.
There was a problem hiding this comment.
I can extend the table saying that is is only for CHM: Process group or Mews: Process group operation and not used in the other one. But then the table would be huge ...
There was a problem hiding this comment.
will remove this note
mews-operations/reservations.md
Outdated
| @@ -385,6 +385,32 @@ The third `reservation` definition shows the partial cancellation - cancelling t | |||
|
|
|||
| > **From/To:** This represents the reservation arrival, `from` is arrival date, `to` is departure date. So reservation for 2 nights (e.g. 2021-12-24/25 and 2021-12-25/26 is represented as `"from": "2021-12-24", "to": "2021-12-26"`). | |||
|
|
|||
| ##### Delivery specific fields | |||
There was a problem hiding this comment.
| ##### Delivery specific fields | |
| #### Delivery specific fields |
There was a problem hiding this comment.
it is a subnote under #### Reservation, so that it should have 1 more, right?
mews-operations/reservations.md
Outdated
| | ~~`adultCount`~~ | ~~`int`~~ | ~~required \(exc. Cancellation\)~~ | ~~Number of adults in the reservation.~~ **[Deprecated!](../deprecations/README.md)** | | ||
| | ~~`childCount`~~ | ~~`int`~~ | ~~optional \(exc. Cancellation\)~~ | ~~Number of children in the reservation.~~ **[Deprecated!](../deprecations/README.md)** | | ||
|
|
||
| ##### Synchronization specific fields |
There was a problem hiding this comment.
| ##### Synchronization specific fields | |
| #### Synchronization specific fields |
There was a problem hiding this comment.
same problem with #### Reservation
mews-operations/reservations.md
Outdated
|
|
||
| ##### Synchronization specific fields | ||
|
|
||
| Following fields are specific to Mews -> Channel manager resevation synchronization operation [Process group](../channel-manager-operations/reservations.md#process-group). |
There was a problem hiding this comment.
| Following fields are specific to Mews -> Channel manager resevation synchronization operation [Process group](../channel-manager-operations/reservations.md#process-group). | |
| Following fields are specific to Mews -> Channel manager reservation synchronization operation [Process group](../channel-manager-operations/reservations.md#process-group). |
mews-operations/reservations.md
Outdated
| @@ -385,6 +385,32 @@ The third `reservation` definition shows the partial cancellation - cancelling t | |||
|
|
|||
| > **From/To:** This represents the reservation arrival, `from` is arrival date, `to` is departure date. So reservation for 2 nights (e.g. 2021-12-24/25 and 2021-12-25/26 is represented as `"from": "2021-12-24", "to": "2021-12-26"`). | |||
|
|
|||
| ##### Delivery specific fields | |||
|
|
|||
There was a problem hiding this comment.
I must admit I am struggling with these sections. I think there are three reasons:
- The objects passed on both sides have their own unique definitions, there is no implication that they might be the same, so if they are different then nothing special is needed except perhaps a helpful note to put in the operation description.
- The docs is getting messy, it would be better to try and follow a simpler model where the API Reference section contains purely factual descriptions of the operations and data fields, and any discussion of how they are used is put into a separate section of guidance on using the API, outside of the API Reference. I also think this model will be a lot easier to maintain going forward.
- There is potential confusion in the CHM API because of having the two sides, especially as operations on both sides have the same name, so I think we have to follow a strict naming convention. My recommendation is, for example,
CHM: Process groupvsMews: Process group
There was a problem hiding this comment.
yeah, the solution for it would be to "duplicate" the definition on each side. Right now the CHM side links the explanation on Mews side (same as in code ...).
…er-api into choice-extensions
* Capitalized new headings as per standard * Corrected "cancelled" (British English) to "canceled" (American English) in descriptions
Re-wrote the changelog entry to make the changes clearer; added minor changes otherwise omitted; updated date to today's date.
Minor change to improve the wording of Process group description.
No description provided.