[Ontology] changeRequest: requestedCurrency / unitsPreference

[LauraWeissgerber]

I am not sure where to put "requestedCurrency" in the current specification.

One option: BookingOptionRequest - unitsPreference: "@type": "iata:Value", "iata:value#unit": "EUR" In this option you do not know that this unit belongs to currency.

Proposal 1: BookingOptionRequest - ratingsPreference - ratings - requestedCurrencyCode (new field): "EUR"

Proposal 2: BookingOptionRequest - unitPreference - currencyCode (new field) - value

If we choose proposal 2, then it would also make sense to offer more options to set a unitsPreference: BookingOptionRequest - unitPreference - currencyUnit (new field) - value (example: "EUR") BookingOptionRequest - unitPreference - measurementUnit (new field) - value (example: "cm") BookingOptionRequest - unitPreference - volumeUnit (new field) - value (example: "mc") BookingOptionRequest - unitPreference - weightUnit (new field) - value (example: "kg")

If we would choose proposal 2, then we would not need to set the valueUnit everytime in dimensions / grossweight / etc.

What do you think about this? OR: How would you show the requested currency in the current specification?

[lambertciata]

Hi,

With current specifications, we recommend to use BookingOptionRequest - unitsPreference with the corresponding unit and either blank or "currency" in the value.

I reckon it's not optimal, we could consider a "Units" object that would contain "Currency, dimensions, etc." To be discussed with taskforce, thanks for the proposal.

[mskopp]

I remember we added Waybill#originCurrency after some discussions as well because it kind of was essential to be able to map a 1R Waybill e.g. to XFWB. (This might be required if a country legally requires XFWB, e.g. for a customs system)

I am not sure about the use case here - I would have expected a booking request also identifies the party requesting the booking and with party I mean an "office", e.g. ForwarderX office in Frankfurt or ForwarderX office in New York. The expected currency might be determined by the default currency of the country of the requesting office.

But maybe there are also business cases where a booking request is done for a currency which might deviate from that. In such a case I second the idea of adding a requestedCurrency field to either a BookingOptionRequest or to a LO which is essentially required for a BookingOptionRequest.

[LauraWeissgerber]

I also see another problem in our current data model. Currently it is possible to add for the same measurement different units, e.g. height in “cm” and length in “ft”. We want that we calculate in one unit – I think about a possible solution and will come back to you with another proposal.

[LauraWeissgerber]

Another idea:

[lambertciata]

Closed with 3.0.0