Midoco User ID

Midoco supports the assignment of bookings to users. The Midoco Connector uses the travel agent assigned to the itinerary. Similar to the agency, one can set an external reference of type "Midoco" and, as a value, the Midoco user ID.

Whenever the agent user assigned to the itinerary in TripBuilder has that Midoco external reference set, it will be passed to Midoco automatically as user ID.

Remark for Marketplace Operators: When submitting a component from the Marketplace Operator TripBuilder instance to Midoco where the net price is in a different currency than the sales price, the revenue calculation method defaults to "price" instead of "buying price foreign."

It's important to note for Marketplace Operators that amounts displayed in a foreign currency should serve solely for monitoring and control purposes. Invoice payments within Midoco are not conducted using foreign currencies.

Remark:

The following inputs have the associated maximum lengths:

pickupCode - 10
pickupDescription - 30
returnCode - 10
returnDescription - 30
countryCode - 3
countryDescription - 64
returnCountryCode - 3
returnCountryDescription - 64

Promo Code

The Midoco Connector supports the submission of TripBuilder promo codes. Please check your Midoco Connector configuration, the submission of promo code information to Midoco needs to be explicitly enabled.

How it works: the promo code will be mapped to a generic Midoco service with a negative sales price, the value of the reduction applied by the promo code. This service is added to the Midoco order but outside of the travel package. By default, the supplier ID will be the ID of your tour operator instance in Nezasa. However, you can configure a dedicated supplier ID just for promo codes on your Midoco configuration in order to identify the promo code services in Midoco and define your accounting rules accordingly, if required.

Cancellation event: when a booking with a promo code is cancelled in TripBuilder, upon data submission to Midoco, its status is updated to 'Cancelled' (i.e. "XX" - as referred in Booking Status), aligned with all other booking components.

Nezasa Component - Midoco Booking[GenericServiceType]

BookingPrice

Midoco GenericServiceType

Midoco Order Attributes

Midoco supports the so-called "order attributes" (or also called "marketing attributes") which are simple name-value pairs on the package level. The Midoco Connector submits the following order attributes. All attributes submitted by TripBuilder will start in "Nz". Please note that in Midoco, you need to explicitly configure the respective attributes you'd like to use. For more details, please refer to the Midoco documentation.

Remark to Marketplace Operators: only the attributes NzItineraryId, NzTourOperatorId, and NzTourOperatorName are submitted to your Midoco instance because the other order attributes are only relevant to tour operators.

Payment Information Submission

After successful payment and booking in TripBuilder, the payment information shall be available in:

• System Events (in Cockpit Settings > Monitoring > System Events)
• Booking API
• Midoco

The Midoco Connector supports the submission of payment information with the credit card alias to Midoco. Based on the alias, further payments can be triggered (for example, the rest payment).

Independently of the feature, any performed payment transaction in the TripBuilder checkout will lead to the submission of a so-called “external payment” to Midoco.

FAQ

Q: Are all Midoco setups compatible with the Nezasa Midoco Connector?

A: Generally yes. However, the Nezasa Midoco Connector always submits package information. Your Midoco configuration might not be yet ready for all use cases within Midoco. Therefore, please get in touch with your Midoco project manager.

Q: The supplier IDs of Nezasa and the ones we already have set up in Midoco are different. Can this be mapped? 

A: Yes, in Midoco. Midoco has the option to map the supplier IDs. Please contact your Midoco project manager for details. For what is considered the "tour operator" in TripBuilder and which is used as the default supplier in Midoco on components, the ID to be used towards Midoco can be configured on the Midoco connector.

Q: Does the Midoco Connector pass the gender of PAX?

A: No, this is currently not supported by the Midoco API.

However, the Midoco Connector maps the gender to the salutation attribute of Midoco. Setting the salutation attribute takes into account the preferred language of the itinerary (for example, for English: male -> Mister, female -> Miss). 

Also, note that the preferred language stored on the itinerary is passed as well to Midoco. In Midoco, in the section to manage the CRM master data, you'll find advanced mapping options for salutations. For detailed questions about that mapping, please contact your Midoco project manager.

Q: The sales price of the package in Midoco is 0. Why?

A: The cause of this might be another error. Generally, Midoco doesn't show the package sales price if there is an error within the package. Another possible cause can be that the package was cancelled, and there were no cancellation fees. In that case, the sales price is supposed to be 0. That would be correct.

Q: Can I see what the Midoco Connector sends to the Midoco API?

A: Yes, this is possible via the Nezasa Cockpit UI and can be very helpful to investigate on a more technical level. The XML requests sent to Midoco can be found in the system events.

Q: Are cancellations supported?

A: Yes, upon cancellations, the status of components or the package is updated accordingly. Furthermore, the sales price of the package resp. the purchase price of components is updated to the remaining costs after the cancellation, that is, the remaining price/fees after cancellation.

Q: Why are remarks not updated in Midoco when a new submission is made?

A: The Midoco API used by our Midoco Connector doesn't support overwriting remarks at the moment. That's why the old, possibly outdated remarks remain in Midoco. The Midoco team has, however, the possibility to implement so-called "rule-based actions" in your Midoco setup that can take care of cleaning up outdated remarks. Please get in touch with Midoco directly in case this is needed.

Q: Are Optional Service Charges made available in Midoco?

A: Optional Service Charges (OSCs) associated with an itinerary can be submitted via connector into Midoco. Data flow is controlled by a Cockpit setting ("Send Optional Service Charge"), available to TripBuilder admin users, enabling flexibility and control over if/how these charges are managed and processed by TripBuilder and Midoco.
OSCs, being internal, are configured to not appear on customer invoices when submitted to Midoco.

In the event of an itinerary cancellation, OSCs are treated distinctly and marked with an "XX" status, signalling cancellation.

Q: Certain components from TripBuilder are not visible in Midoco. Why?

A: Generally, the Midoco Connector submits all TripBuilder components to Midoco. A good way to verify this is to check the XML request sent to Midoco in the system events. A possible reason that a certain is not listed in Midoco can be that the booking reference is not unique. In Midoco, supplier codes and booking references need to be unique.

Q: Will booking changes to ad-hoc and inventory components lead to duplicate entries in Midoco upon submission?

A: The existence of duplicate ad-hoc and inventory components in Midoco depends on the type of change applied and the need to keep both versions (before and after booking change) for tracking reasons.

For changes to attributes of an existing component (that will not trigger a cancel/rebook operation), the cancelled component is not part of the submission to avoid duplication. These can include:

• Altering the supplier confirmation number
• Modifying the description
• Changing the name

However, for operations that are mostly related to a cancel/rebook, both the cancelled and booked components are submitted. This can occur when:

• Removing and replacing a component
• Altering the itinerary start date
• Adding more nights into a stop as part of your booking change
• Changing a category/amenity in an inventory product
•  

This distinction only applies to ad-hoc and inventory components, not to live supply.

Q: Sometimes, different bookings are merged together in the same Midoco order. What might cause this?

A: One reason is when the same invoice address and the same travel dates are used for different bookings. Midoco tries to merge them together automatically. This can happen more while testing different itineraries using the same dates and passenger information.

Another use case results from Midoco considering that travel services must be unique regarding the attribute pair “supplier ID” / “booking ID”. Especially in the case of ad-hoc components, users might violate the requirement due to manual text entry. As a result, Midoco merges the two travel services, causing the impression that one of the services has not been submitted to Midoco by TripBuilder. The situation is mitigated in two ways:

• For administrators, the system events show a warning as below:

• For agents, in the ad-hoc component modal, a warning is presented if two components that have the same supplier ID and booking ID.

Q: Is it possible to see Midoco's order number at the Agency Centre?

A: To identify bookings more easily, the Agency Centre can present the booking reference as a tag (the feature requires a feature flag activation in Settings by Nezasa). Further, text search also considers the booking reference. To show the order number of Midoco in the Agency Centre instead:

• Enable on the Midoco Connector that the order number is stored as “external ref id” in TripBuilder
• Request Nezasa's Customer Support team to enable this feature flag
  

Feature Limitations

Not all data available in TripBuilder is submitted to Midoco, nor is TripBuilder having an equivalent feature for the wide set of options Midoco supports. Please find below a list of functionality that was mentioned to Nezasa before but is currently not supported.

• Agency Commissions: TripBuilder currently has no support for agency commissions.
• Rest Payments: Rest payments don't automatically trigger a new submission to Midoco. A manual submission can be triggered in these cases to update the payment status on Midoco’s side. Only the main booking actions, such as a booking, booking change, PAX change and cancellation, trigger an automatic transmission to Midoco.