Discrepancias de precios u otras excepciones de cambio de precios

  1. Se ha producido un cambio de precios en la propiedad antes de que el usuario reservara o la actualización del cambio de divisa ha provocado que ya no coincida la disponibilidad mostrada cuando se devolvieron las tarifas de habitación en la respuesta. Cuando la tarifa no coincide con la de la base de datos, se produce un error de discrepancia de precio.
  2. En los casos en los que no se ha producido realmente un cambio de precio "activo", pero se recibe un mensaje de cambio o discrepancia de precio, comprueba la exactitud de todos los valores que se envían en la reserva. El envío de datos o valores incorrecto en rateKey, roomTypeCode, rateCode o total provoca una discrepancia de precio en el momento de la reserva. Los valores de todos estos elementos deben coincidir con la selección que hace el usuario en la respuesta de disponibilidad de habitaciones.
  3. También puede haber un error de discrepancia de precio cuando la configuración regional y la divisa no coinciden con la ubicación geográfica de customerIpAddress (dirección IP del cliente). En estos casos poco habituales, trata el error mediante el envío de nuevo de la reserva omitiendo el elemento customerIpAddress (dirección IP del cliente) para esa solicitud. Si la reserva es correcta, la discrepancia de precio se ha producido al establecer de forma imprecisa la coincidencia geográfica de los valores enviados. Los valores de recargo se calculan según la ubicación geográfica indicada por estos elementos y, cuando su coincidencia no se establece de forma precisa, los valores de recargo pueden discrepar de la tarifa establecida en la base de datos para esa asignación.

Mensaje de ejemplo devuelto cuando se utiliza la Versión 3, revisión menor 9 o superior:

Ejemplo de respuesta XML

<ns2:HotelRoomReservationResponse xmlns:ns2 = "http://v3.hotel.wsapi.ean.com/">
   <EanWsError>
      <itineraryId>XXXXXX</itineraryId>
      <handling>RECOVERABLE</handling>
      <category>PRICE_MISMATCH</category>
      <exceptionConditionId>1673</exceptionConditionId>
      <ErrorAttributes>
         <errorAttributesMap>
            <entry>
               <key>RATE_CHANGE</key>
               <value>121.89</value>
            </entry>
            <entry>
               <key>RATE_KEY</key>
               <value>4fc6fd3b-03b4-49e2-96cf-22b1aa4ad89b</value>
            </entry>
         </errorAttributesMap>
      </ErrorAttributes>
      <presentationMessage>Error de verificación final del precio antes de la reserva. (Tarifa solicitada: 120,89(USD)) (nueva tarifa: 121,89(USD)). Vuelva a intentarlo con la nueva tarifa.</presentationMessage>
      <verboseMessage>
         Error de verificación final del precio antes de la reserva QuoteKey: 4fc6fd3b-03b4-49e2-96cf-22b1aa4ad89b
         RatePlan: status = Available
         roomTypeId = 19304
         ratePlanId = 200245232
         ....  [datos de solicitud general eliminados por brevedad] ...
         Error de verificación final del precio antes de la reserva. (Tarifa solicitada: 120,89(USD)) (nueva tarifa: 121,89(USD)). Vuelva a intentarlo con la nueva tarifa.
      </verboseMessage>
      <ServerInfo
         serverTime = "13:52:51.848-0500"
         timestamp = "1318963971"
         instance = "167"/>
   </EanWsError>
   <customerSessionId>0AB81CA7-9955-D913-3162-AA666D9074FD</customerSessionId>
</ns2:HotelRoomReservationResponse>

Ejemplo de respuesta JSON

{
    "HotelRoomReservationResponse" : {
        "EanWsError" : {
            "itineraryId" : XXXXX,
            "handling" : "RECOVERABLE",
            "category" : "PRICE_MISMATCH",
            "exceptionConditionId" : 1673,
            "ErrorAttributes" : {
                "errorAttributesMap" : {
                    "entry" : [{
                        "key" : "RATE_CHANGE",
                        "value" : 151.8
                    },
                    {
                        "key" : "RATE_KEY",
                        "value" : "d18ce59c-82ba-4dbd-8f9a-5b04ec2283bd"
                    }]
                }
            },
            "presentationMessage" : "Error de verificación final del precio antes de la reserva.
             (Tarifa solicitada: 141,8(USD)) (nueva tarifa: 151,8(USD)). Vuelva a intentarlo con la nueva tarifa.",
            "verboseMessage" : "Error de verificación final del precio antes de la reserva QuoteKey: d18ce59c-82ba-4dbd-8f9a-5b04ec2283bd \nRatePlan: status =                Available\nroomTypeId = 8282\nratePlanId = 8282\nrateRuleId = 200584001\nratePlanType =
           Expedia CollectStandard\nratePlanName = Habitación de lujo con dos dobles
           ....  [datos de solicitud general eliminados para brevedad] ...
           Error de verificación del precio antes de la reserva. (Tarifa solicitada: 141,8(USD)) (nueva tarifa: 151,8(USD)).
           Vuelva a intentarlo con la nueva tarifa.",
            "ServerInfo" : {
                "@serverTime" : "17:06:46.659-0500",
                "@timestamp" : "1320358006",
                "@instance" : "42"
            }
        },
        "customerSessionId" : "0ABAA856-E9C5-4913-36B2-5C0F37906376"
    }
}

El error tendrá este aspecto en nuestro sistema:

SUPPLIER : 13
      FUNCTION : 3
      CATEGORY : 25
      HANDLING : 1
      SEVERITY : 0
      ITIN ID : XXXXX
      DB MSG : Excepción de discrepancia de precio del proveedor de reservas de Expedia
      PRESENTATION MESSAGE: Ha cambiado el precio de la habitación seleccionada.
      VERBOSE MESSAGE: 3000: El precio ha cambiado.

{: style="margin-left: 50px; margin-right: 50px;"}

  • OBSERVA que handling=RECOVERABLE, lo que indica que se puede "recuperar" si se utiliza el procesamiento correcto.
  • OBSERVA que category=PRICE_MISMATCH para las excepciones de cambio de precio.
  • Observa también que reservationStatusCode=DT. La solicitud se ha borrado, NO habrá ningún agente que haga un seguimiento y NO se envía ningún mensaje de correo electrónico al usuario cuando handling=RECOVERABLE por el afiliado.

Cómo forzar un error de discrepancia de precio para realizar pruebas

Para forzar una respuesta de error de discrepancia de precio, cambia el valor de "chargeableRate" en la solicitud de reserva antes del envío. Por ejemplo, si el valor devuelto en la respuesta de habitación que se va a usar como chargeableRate es 150,00, envía cualquier otro valor en la nueva solicitud de reserva, como, por ejemplo, 151,00. La excepción devuelta te permitirá hacer pruebas en el algoritmo para escoger los atributos de error para reenviarlos en la nueva solicitud de reserva.

Ten en cuenta también que se devuelve un ID de itinerario en estos errores, que se puede enviar en la solicitud de reserva posterior. Al utilizar el mismo ID de itinerario, se incluirán menos solicitudes de error canceladas en las estadísticas del afiliado y todos los intentos que haga el mismo usuario para la misma solicitud de reserva se encontrarán en el mismo itinerario.

Sigue las instrucciones indicadas en Solicitud de reserva para utilizar el ID de itinerario en la solicitud de reserva reenviada.

Recuperación de la reserva fallida mediante el manejo del error descrito:

  • La revisión minorRev=9, o superior, devuelve nuevos valores de entrada de asignación para ayudarte con la recuperación de este error. También omite la necesidad de actualizar los resultados de disponibilidad de habitaciones para obtener los precios actuales al incluir el nuevo valor de precio, que se puede obtener de forma automática del mensaje de error y utilizarlo para reenviar la reserva.
  • Muestra la nueva tarifa de habitación al usuario para que la acepte con el fin de evitar problemas con los clientes sobre los cargos esperados.
  • Incluye el nuevo valor de rateKey en la reserva reenviada.

Método alternativo para aplicaciones que no utilizan la Versión 3, revisión menor 9 o superior:

  • Actualiza el resultado de la disponibilidad de habitaciones y compara las tarifas de la habitación seleccionada.

Si la tarifa es inferior:

  • Envía de nuevo la solicitud de reserva con el nuevo precio inferior y la clave de tarifa.
  • Notifica al usuario la tarifa inferior reservada en el resultado de la reserva o confirmación.
  • Algunas configuraciones regionales internacionales o algunos países pueden exigirte, por motivos legales, que informes al usuario sobre la nueva tarifa (aunque sea inferior a la seleccionada en un principio) antes de realizar la compra automática de la reserva. Asegúrate de cumplir con todos los requisitos legales de tu país o región.

Si la tarifa es superior:

  • Notifica al usuario que la tarifa ha cambiado.
  • Muestra la nueva tarifa de habitación correspondiente a la selección original con las opciones de habitación adicionales de la propiedad.
  • Concede al usuario las siguientes opciones:
    1. Aceptar la nueva tarifa y continuar con la reserva
    2. Seleccionar otra habitación y continuar con la reserva
    3. Seleccionar otro hotel de la lista anterior

Envía la nueva selección de reserva con los datos que el usuario ha introducido en el intento de reserva original y que se han guardado temporalmente. Se trata de una comodidad para el usuario, ya que no tiene que introducir de nuevo la misma información personal y de pago.

Si el error de discrepancia de precio o de cambio de precios se produce en más de dos solicitudes válidas para la misma propiedad, significa que hay un problema con dicha propiedad y se debe seleccionar un nuevo hotel.

Cómo evitar reservas duplicadas en caso de un tiempo de espera agotado

Se puede agotar el tiempo de espera de un intento de reserva en las situaciones siguientes:

  • En el servidor del afiliado se ha configurado un tiempo de espera demasiado corto.
  • El sistema de procesamiento de reservas es lento en el nivel de proveedor.
  • La puerta de enlace de pagos es lenta en el nivel de procesamiento de pagos.
  • Los servidores se sobrecargan por un pico inesperado en el tráfico.

¿Dónde sucede el agotamiento del tiempo de espera?

  • El agotamiento del tiempo de espera puede suceder en el servidor del afiliado si la respuesta tarda más que el tiempo definido en tu configuración de servidor. Se recomienda configurar al menos 30 segundos para que dé tiempo suficiente a que se procesen todas las reservas y pagos. Aunque el procesamiento no suele tardar tanto tiempo, dependemos de la eficacia de las puertas de enlace de pagos y de proveedores.
  • Un agotamiento del tiempo de espera puede suceder en nuestros propios servidores si la ejecución de las puertas de enlaces de pagos o proveedores dura más de los 60 segundos establecidos como tiempo de espera antes de que recibamos un resultado. No obstante, el procesamiento puede ser correcto, aunque todos los sistemas agotaran el tiempo de espera antes de que se conociera el resultado de la reserva. Desafortunadamente, esto implica que es posible que no tengamos toda la información de confirmación sin comprobar el sistema.

¿Cómo puedo comprobar que una reserva ha concluido correctamente en caso de que se agote el tiempo de espera? ¿Cómo puedo comprobar si el resultado de la reserva se ha devuelto vacío porque se ha agotado el tiempo de espera en los sistemas en cualquier nivel?

Consulta Solicitud de reserva para conocer los detalles sobre el uso de affliateConfirmationId (ID de confirmación de afiliación), que se puede utilizar para buscar una reserva en caso de que se haya agotado el tiempo de espera y no se conozca una confirmación o itinerario correctos.

  • Puedes evitar la duplicación de reservas mediante la inclusión de una lógica especial en las páginas de reserva que sea capaz de manejar las reservas en casos de tiempo de espera agotado o resultados de reserva vacíos.
  • Después, comunica la información adecuada al usuario y utiliza la lógica correcta para recuperar la reserva.

affiliateConfirmationId (ID de confirmación de afiliación) (cadena)

  • ID exclusivo de afiliado que se utiliza para tu propio seguimiento de afiliación o solo para uso personal del afiliado.
  • DEBE ser un valor exclusivo.
  • Se producirá un error en la reserva si se envía el mismo valor dos veces, incluido un valor de una reserva fallida.
  • Este valor también se puede utilizar para evitar la duplicación de reservas si el usuario hace clic en el botón de reservas más de una vez.
  • Si se transmite, validaremos que aún no existe ninguna reserva en el sistema realizada con el mismo affiliateConfirmationId (ID de confirmación de afiliación). Además, los afiliados pueden recuperar los itinerarios del sistema mediante este ID.
  • Todos los afiliados que utilicen este campo deben asegurarse de que el ID realmente sea exclusivo, como un ID GUID.
  • El ID debe crearse antes de que el usuario envíe el formulario de reserva final. Si el mismo usuario vuelve a pulsar el botón Enviar, se enviará el mismo affiliateConfirmationId (ID de confirmación de afiliación) y se detectará como una reserva duplicada.
  • Ten sumo cuidado al enviar este elemento, ya que existen muchos casos en los que se debe realizar una solicitud totalmente nueva y con un NUEVO affiliateConfirmationId (ID de confirmación de afiliación); por ejemplo, en una reserva fallida o irrecuperable.
  • Este elemento se usa para
    • tu propio seguimiento;
    • evitar reservas y cargos duplicados enviados por los usuarios;
    • comprobar el sistema para ver si hay un itinerario aunque se haya agotado el tiempo de espera de la reserva o esta haya devuelto un resultado vacío por procesos en sistemas de terceros cuyo tiempo de espera se haya agotado.

Pasos para determinar si existe una reserva cuando se agota el tiempo de espera en una solicitud de reserva o el resultado se devuelve vacío.

  1. La solicitud de reserva se envía con un affiliateConfirmationId (ID de confirmación de afiliación) exclusivo.
  2. Se agota el tiempo de espera o no se devuelve ningún resultado tras un tiempo prolongado.
  3. Una vez que se ha agotado el tiempo de espera o se ha obtenido un resultado de reserva vacío, realiza una solicitud de itinerario usando solo el affiliateConfirmationId (ID de confirmación de afiliación).

  4. Esta solicitud devolverá cualquier información de itinerario correspondiente a ese affiliateConfirmationId (ID de confirmación de afiliación), en caso de que se haya creado.

  5. También mostrará el ESTADO de dicho itinerario.

    • CF: reserva confirmada
    • PS: pendiente: normalmente es el estado que se obtiene si se devuelve handling=3, que indica que un agente debe finalizar la reserva. EAN continuará intentando procesar estas reservas y puede efectuar la resolución a CF o UC sin avisar.
    • UC: sin confirmar: esta reserva ya no está disponible y no se confirmará.
    • DT: borrada: la solicitud se ha cancelado y el itinerario se ha borrado de todas las estadísticas. Suele ser el estado habitual en las solicitudes de reserva en las que se obtienen errores irrecuperables. ^
  6. Si se devuelve un resultado de la solicitud de itinerario con cualquier otro estado distinto de CF, haz lo siguiente:

    • Avisa al usuario de que ha habido un problema con su reserva e indícale el estado de esta.
    • Si se devuelve handling = 3, un agente se pondrá en contacto con el usuario en un máximo de 24 horas.
    • También puedes ofrecer al cliente la opción de cancelar esa solicitud de reserva y comenzar una nueva.
    • Si se cancela la solicitud, utiliza la información del itinerario obtenida para enviar la solicitud de cancelación de ese intento de reserva.
    • Esto notificará a los agentes de que no es necesario realizar un seguimiento de ese intento de reserva.
  7. {: .red} Si se devuelve un resultado de la solicitud de itinerario con el estado CF:

    • Muestra al usuario los resultados de la reserva correcta de los resultados del itinerario, de igual forma que harías si la reserva se hubiera confirmado correctamente sin que se agotara ningún tiempo de espera.
  8. Si no se devuelven resultados:

    • No se ha realizado ninguna reserva durante la solicitud de reserva cuyo tiempo de espera se ha agotado.
    • Avisa al usuario de que ha habido un problema con el procesamiento de la reserva y ofrécele las distintas propiedades que puede utilizar para intentarlo de nuevo.
    • Asegúrate de emitir un nuevo affiliateConfirmationId (ID de confirmación de afiliación), ya que este debe ser un valor exclusivo de cada solicitud de reserva.

Cómo evitar envíos duplicados

Los usuarios crearán reservas duplicadas cada vez que pulsan un botón Enviar sin restricciones o actualizan la página de reservas para la misma reserva.

Debido a la naturaleza de Internet, los sistemas electrónicos y otros factores incontrolables, la transmisión de los envíos y los tiempos de respuesta pueden retrasarse.

  • Si esto sucede, los usuarios se pueden impacientar y hacer clic en tu método de envío de reservas varias veces.
  • En estos casos, se crea una nueva reserva por cada envío que se realiza.
  • Como las respuestas de confirmación reales pueden quedar sobrescritas con respuestas más recientes, es posible que el usuario no vea ni detecte que su reserva se ha enviado varias veces y se ha duplicado en el sitio hasta que consulte los mensajes de correo electrónico de confirmación o se presente en la propiedad.

¿Cómo afectan al usuario las reservas duplicadas?

  • En las reservas prepagadas, se realiza un cargo en su tarjeta de crédito cada vez que se recibe un envío duplicado y se crea un nuevo registro de reserva.
  • En las reservas de Hotel Collect/Hotel Collect, se crean varias reservas para el mismo usuario en el sistema para la misma propiedad.
    • La propiedad las verá como reservas de varias habitaciones y el huésped deberá hacerse cargo del coste de cada habitación en el registro de entrada, ya que se han reservado todas las habitaciones solicitadas con la garantía de su tarjeta de crédito y no se han podido vender a otros clientes.

Como afiliado, ¿cómo me afectan las reservas duplicadas?

  • Todos los afiliados son responsables de crear sus propias aplicaciones y, por tanto, también lo son de sus clientes.
  • Si la situación no se trata correctamente, los conflictos con los clientes pueden crear cargos innecesarios que se cobrarán directamente al afiliado.

Para evitar reservas duplicadas, incluye una lógica especial en tus páginas de reserva con el fin de manejar las situaciones en las que se realizan varios envíos y comunicar la información adecuada al usuario.

  • En la mayoría de los casos, basta con indicar al usuario que se cargará el importe dos veces en su tarjeta si hace clic varias veces.
  • También puedes añadir código sencillo para deshabilitar el botón Enviar de tu página de reservas después de un clic, lo que evitará que el usuario vuelva a hacer clic durante el tiempo de carga.
  • En otros casos de error del sitio web, tendrás que adoptar medidas especiales para asegurarte de que no se envía la reserva dos veces cuando se pretende hacer solo una.

Las medidas de manejo especiales también deberían tener en cuenta que algunos errores de reserva se pueden solucionar mediante un nuevo envío de la solicitud.

  • Según la naturaleza del error y el código de manejo (handling) de una excepción que se devuelva durante la reserva, puedes determinar si se debe enviar de nuevo una reserva.
  • En estos casos, no se duplica la reserva, sino que se intenta de nuevo para conseguir un procesamiento correcto.

Consulta Solicitud de reserva para conocer los detalles sobre el uso de <affliateConfirmationId>, que puede ayudar a nuestro sistema a detectar un intento de reserva duplicado.

Por último, utiliza la solicitud del itinerario para comprobar si existe un itinerario o, en caso afirmativo, cuál es el estado de este.