Bridg
Documentation · PMS interface

Tests de certification PMS

Les 19 tests à dérouler sur le staging avant la mise en production d'une intégration.

Staginghttps://staging.bridgchannel.appv1.0 · 2026-09-11<?Label BRIDG|DOC|1.0|NEW?>

This technical documentation is available in French only.

Avant la mise en production d'une intégration, Bridg_ demande de dérouler les tests ci-dessous sur l'environnement de staging, connexion en statut PENDING puis ACTIVE. Chaque test est vérifiable par l'intégrateur lui-même dans l'écran Interface PMS (journaux entrants et sortants) et dans le calendrier de disponibilité / tarifs de Bridg_.

Prérequis

  • Une connexion staging créée avec le bon dialecte (opera-oxi, bridg-hms ou winner).
  • Au moins 2 types de chambre et 2 plans tarifaires mappés.
  • En mode webhook JSON : l'URL et les jetons de l'API du PMS enregistrés (Voie sortante).
  • En XML : la configuration OXI (ou équivalente) pointée sur l'URL staging avec ?key=.

Déroulement

  1. Tests 1 à 10 en statut PENDING (l'ARI est appliqué, aucune réservation n'est émise).
  2. Passage en ACTIVE par le propriétaire.
  3. Tests 11 à 19.
  4. Remplir la grille de résultats (§ fin de page) et la transmettre à Bridg_.

Anti-patterns qui font échouer la certification

  • Envoyer un item par requête (des centaines d'appels pour une journée).
  • Full sync sur minuterie toutes les N minutes.
  • Réémettre en boucle un message refusé de façon déterministe (code non mappé).
  • Acquitter une réservation avant qu'elle soit écrite dans le PMS.
  • Ignorer la révision et appliquer une modification périmée par-dessus une annulation.
  • Corps compressé (gzip) ou dates hors format AAAA-MM-JJ.

Tests

ARI

# Test Ce qui est vérifié
1 Synchronisation complète Le PMS envoie disponibilité, prix et restrictions sur 365 jours pour tous les types et tarifs mappés, en messages regroupés par nature (pas un item par appel). Tout est visible dans le calendrier Bridg_.
2 Disponibilité — date unique Une réservation prise au PMS décrémente la disponibilité d'un type sur une nuit ; le message arrive en quelques secondes et le calendrier reflète le nouveau chiffre.
3 Disponibilité — plage, plusieurs types Un changement d'inventaire sur plusieurs types et plusieurs nuits part en un seul message.
4 Prix — date unique Un changement de prix pour un type × tarif sur une nuit ; le prix à l'occupation 2 est celui attendu (TTC ou HT selon le tarif Bridg_).
5 Prix — plages, plusieurs tarifs Plusieurs tarifs et plusieurs plages en un message. En XML : vérifier la dernière nuit de la plage (rateEndDateInclusive).
6 Stop-sell Fermeture puis réouverture d'un tarif sur une plage ; la réouverture ne touche ni CTA/CTD ni LOS.
7 Durée de séjour minLos puis maxLos sur une plage ; un minLos seul ne rouvre pas un tarif fermé.
8 CTA / CTD Fermeture à l'arrivée et au départ, puis réouverture.
9 Restrictions multiples Un message qui combine stop-sell, CTA, CTD et LOS sur plusieurs tarifs et plages.
10 Refus déterministe Un item avec un code non mappé : l'accusé le signale (UNMAPPED_UNIT_TYPE) et les autres items du message sont appliqués. Le PMS ne réémet pas le message en boucle.

Réservations Bridg_ → PMS (statut ACTIVE)

# Test Ce qui est vérifié
11 Création Une réservation créée dans Bridg_ (moteur direct, ou OTA de test) arrive au PMS avec le bon type, le bon tarif, les nuits datées et le total ; le PMS l'acquitte (RESULT / POST …/results / réponse webhook) ; la ligne passe à DONE dans le journal.
12 Modification — dates Changement de dates : le PMS reçoit l'état complet avec une révision supérieure et remplace la réservation.
13 Modification — ajout et retrait d'une chambre Passage de 1 à 2 chambres puis retour à 1 : la ligne retirée est annulée côté PMS.
14 Annulation La réservation est annulée dans le PMS ; une modification périmée rejouée ensuite est ignorée.
15 Refus déterministe côté PMS Le PMS refuse une réservation (type inconnu) en le signalant : la ligne passe en dead-letter (FAILED) et reste rejouable après correction du mapping.
16 Panne transitoire côté PMS Le PMS est indisponible pendant l'émission : Bridg_ réessaie (backoff) ou ressert le message au prochain feed ; aucune réservation n'est perdue ni dupliquée.

Réservations PMS → Bridg_

# Test Ce qui est vérifié
17 Création, modification, annulation Une réservation prise à la réception apparaît dans Bridg_ avec la source PMS ; sa modification remplace les lignes ; son annulation la passe en annulée. La disponibilité n'est modifiée que par le message ARI qui suit.

Robustesse

# Test Ce qui est vérifié
18 Rejeu Le même message (même identifiant) envoyé deux fois : le second reçoit l'accusé mémorisé, rien n'est appliqué deux fois.
19 Débit Le PMS respecte 600 requêtes / minute et gère un 429 sans perdre de mise à jour.

Notes de capacité (à renseigner)

  • Variantes de durée de séjour supportées par le PMS (min stay à l'arrivée / sur le séjour).
  • Restrictions non supportées par le PMS.
  • Multi-chambres et multi-tarifs dans une même réservation.
  • Prix par occupation (1..N) ou occupation de référence seulement.
  • Compression : le PMS envoie-t-il toujours des corps non compressés ?

Grille de résultats

# Test Résultat (OK / KO / N/A) Identifiant de message Commentaire
1 Synchronisation complète
2 Disponibilité — date unique
3 Disponibilité — plage
4 Prix — date unique
5 Prix — plages
6 Stop-sell
7 Durée de séjour
8 CTA / CTD
9 Restrictions multiples
10 Refus déterministe
11 Création
12 Modification — dates
13 Modification — chambres
14 Annulation
15 Refus côté PMS
16 Panne transitoire
17 Réservation PMS → Bridg_
18 Rejeu
19 Débit