Request for correction

[Ulrich Seppi]

Hello at all,

while my last AlpineBits Certification Audit I’ve found the following rule, which 

could be problematic in some cases:

See page 24 of AlpineBits 2017-10 document, there is following rule:

- One RatePlan element with:

- a RatePlanCode Attribute (mandatory for reservations, optional for quote request) …

This means, that a server, in case of a delivery of reservations (bookings), MUST set the RatePlanCode attribute.

The problem is, that in some cases (ex: case of channel manager), the reservation could come from a third-party OTA like (booking.com),

which does not use AlpineBits and RatePlanCode at all. So this attribute could not be set by the server.

I tried to add an empty RatePlanCode attribute to the message, but this does not validate with OTA xsd.

Therefore I invite you to remove this „mandatory“ rule also for reservations!

Thanks and bye

Uli

[Daniele Gobbetti - Peer GmbH/Srl]

Hello Uli,

If I understand the situation you describe, a server does not know the RatePlanCode for which it is sending a GuestRequest of type Reservation.

If my description is accurate, we should think of why this might happen:

• if the server receives Rateplans (and Inventory, Freerooms) data from an AlpineBits client, then it MUST know this information. If it does not, there is something wrong in the server implementation.
• if the server does not receive Rateplans (and Inventory, Freerooms) data from an AlpineBits client, then this information might actually be missing.

Changing the rule as you suggest would make it legit also for “full-AlpineBits” servers to generate Reservations that are not linked to an actual RatePlan. Is this ok?

Another question that comes to mind is whether it’s within the scope of AlpineBits to force a client to process a Reservation that has no link to its RatePlans.

Further, consider that in 2018-10 we are adding a new functionality that allows a client to query the list of RatePlans. This was requested by some channel managers, that are only able to issue Overlay RatePlan messages (no new/completeset). The background issue was that the Channel Manager needed to create a mapping with AlpineBits RatePlanCodes! Hence I believe 2018-10 supersedes the needs for the change you described by providing the Channel Managers with the RatePlanCode information.

Best regards,
Daniele Gobbetti

P.S. A note on the wording: I don’t think it is accurate to call the change you are suggesting a “correction”. Unless my description above is wrong, your request highlights a new use-case and, for clients, definitely a breaking change.

—

--
You received this message because you are subscribed to the Google Groups "AlpineBits" group.
To unsubscribe from this group and stop receiving emails from it, send an email to alpinebits+...@googlegroups.com.
To post to this group, send email to alpin...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/alpinebits/6CF85D82-34F5-4FB9-A1BB-E0ECB57E1A79%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

​

--

	Daniele Gobbetti Head of Development & Operations
	Peer GmbH/Srl - www.peer.biz Tel. +39 0471 631080 - Fax +39 0471 631724

[Ulrich Seppi]

Hello Daniele,

as Yanovis told to me, there is another case that we should consider:

Consider the case that the booking comes from a third-party OTA and an alpinebits server (channel manager) is the "man in the middle“ which 

delivers this booking to the client.

In this case it could happen, that the alpinebits server could not match the booking to a rate plan, if the third-party OTA does not support this information

in his booking. 

So I would ask now: Is it always possibile to match a booking of a third party OTA to a RatePlanCode?

I would invite Yanovis and other members and ChannelManagers to give their feedback to this question.

Thanks to all,

Uli

--

<nkllnaifbfelahhm.gif>

Daniele Gobbetti Head of Development & Operations

Peer GmbH/Srl - www.peer.biz Tel. +39 0471 631080 - Fax +39 0471 631724

<blddlepkbjaicaha.gif>

--
You received this message because you are subscribed to the Google Groups "AlpineBits" group.
To unsubscribe from this group and stop receiving emails from it, send an email to alpinebits+...@googlegroups.com.
To post to this group, send email to alpin...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/alpinebits/8c84475b-569c-9501-ba8a-51cd4cfc36ae%40peer.biz.

[Thomas Alber]

Ciao Daniele,

noi abbiamo la situazione che dei partner internazionali (Che purtroppo non usano AlpineBits) ci mandano delle prenotazioni senza riferimento al prezario (RatePlan). Per esempio le prenotazioni di AirBnb ci vengono inoltrate tremite il protocollo iCal. Ogni stanza ha un calendario iCal e nella communicazione riceviamo solamente il periodo prenotato e il nominativo del ospite. In questo caso non abbiamo la informazione del prezzario e non possiamo inoltrare un RatePLanCode.

Se il RatePlanCode rimane mandatory siamo costretti a inventarci un RatePlanCode fittizio, per esempio RatePlanCode="unknown". Credo che questa non é una buona soluzione, secondo noi sarebbe meglio rimuovere il mandatory dal RatePlanCode.

Un caro saluto

Thomas

[Ulrich Seppi]

Hello,

as discussed at the last developer meeting here my proposal for the best practice text for this topic:

In the use case where a server (such as channelmanager) pass though reservations (note: not quote requests!) from a third party to the client, it could happen, 

that it wont't be possible to match a reservation to a given rateplan. In consequence the RatePlanCode attribute could not be set properly by the server, even if this attribute is mandatory for such a message. 
Considering that OTA's xsd doesn't allow empty values for this attribute, and only in this use case, it is recommend to fill it with the string "unknown".

It would give me a pleasure if this could be added as best practice in the coming release (2018) and until we find an appropriate solution for a future release.

Best regards,

Uli

To view this discussion on the web visit https://groups.google.com/d/msgid/alpinebits/ab934efa-4054-4aaf-8dc4-8a704137ed6a%40googlegroups.com.

[Martin R]

According to the last developer meeting "[...] there’s not enough time to review this point within the AlpineBits 2018-10 version as it needs."

As discussed by the board the current best practice describes a workaround for the server which means trailing another workaround on the client. 

While the workaround in the server is necessary to respect the certification, the workaround on the client guarantees the correct mapping of Rateplan named "unknown" and prevent end users from the potential issue of getting mapping errors.

Since not reviewing this point would mean accepting the workarounds for release 2018 and postpone the solution to AlpineBits release 2020, the board invites all developers to review this business case in the next developer meeting on October 25th.

Hence there has to be analyzed what consequences the decision has in respect of implementations, compatibility, correctness and pragmatism, if

- RatePlanCode remains mandatory 

- RatePlanCode gets optional

- other solution to respect the business case

best regards

MR

Best regards,

Uli

To unsubscribe from this group and stop receiving emails from it, send an email to alpinebits+unsubscribe@googlegroups.com.

[Daniele Gobbetti - Peer GmbH/Srl]

Hello Martin, hi all,

In order to allow everyone to discuss internally and speed up the discussion, I believe it would be helpful if you describe what is(are) the concrete proposal(s) that you mean with:

- other solution to respect the business case

Thanks a lot.

Best regards,
Daniele Gobbetti

—

To view this discussion on the web visit https://groups.google.com/d/msgid/alpinebits/5ce707f5-bfc6-4db5-8aab-48e1692e8c7d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

​

--

Daniele Gobbetti Head of Development & Operations

d.gob...@peer.biz

[Martin R]

Hello Daniele,

for the time being there are two concrete but contrary solutions: RateplanCode mandatory vs. RatePlanCode optional.

Furthermore there is the current workaround with string "unknown" being interpreted to be a non-existing RatePlanCode. 

This could be classified as "other solution to respect the business case" because the mandatorily sent string "unknown" does respect the current protocol rules, while forcing both server and client to interpret it as a special case with optional data.

My intention was to point out that the discussion is not limited to the two proposals mandatory vs. optional.

best regards

Martin

[Martin R]

Result of the discussion for release 2018-10:

- attribute RatePlanCode remains mandatory

- the workaround gets introduced into the documentation

- string "Unknown" (with capital letter U!) is used to tell a client that the server has no RatePlanCode for a booking; string "Unknown" is used elsewhere in OTA as well 

https://gitlab.com/alpinebits/developers-kit/merge_requests/25/diffs?commit_id=549ad8514b1f32c12119cae38b2e693dc6363bea