Chargé n'est pas vérifié

Chargé est la revendication du chargeur, un code a été saisi dans la chaîne. Vérifié est la preuve du moteur, le tarif négocié revient réellement à un agent, dans le bon champ, sous une identité autorisée, à la valeur négociée, et est réservable sur les dates qu'il devrait être.

La plupart des erreurs de chargement sont silencieuses. Le code semble entré, mais il revient dans le mauvais champ, ou une valeur différente, ou une propriété usurpatrice répond, ou elle est fermée un soir de pointe où elle devrait protéger. Chacun d'eux est une perte de chiffre d'affaires ou un défaut d'audit d'entreprise. Cette plateforme en fait une détection nommée et prouvée.

Chaque instruction aujourd'hui est Type, chargement de tarif, un tarif négocié à charger et prouver. Le champ type est conçu pour croître, mais le chargement de tarif est le seul pour le moment.

Elle atteint la plateforme de l'une des deux façons. Une instruction reçue est une RLI qu'un client ou un programme a envoyée, normalisée à partir du format dans lequel elle est arrivée. Un audit est un balayage auto-initié, un gestionnaire l'exécute, et le moteur génère les états attendus directement à partir du registre client pour vérifier ce qui est déjà chargé par rapport au programme archivé. Les audits portent un badge AUDIT distinct partout où ils apparaissent.

Un chargeur ouvre le panneau de vérification, choisit une propriété et un GDS, et colle l'écran réel qu'un agent verrait. Le moteur canonicalise chaque ligne retournée, l'apparie à l'état attendu, et enregistre un écart pour tout ce qui ne s'aligne pas. Il vérifie le code, le champ dans lequel il s'assied, la valeur, le type de chambre, l'identité (nom, pseudo city, office ID, code chaîne), et si quoi que ce soit est réservable. La réexécution recalcule l'ensemble de l'RLI, donc le résultat est toujours actuel.

Vérification (après le chargement)

Deux dimensions sont maintenues séparées à dessein. La exactitude du chargement (le bon code au bon endroit à la bonne valeur) échoue toujours quand elle est fausse. La réservabilité (ouvert ou fermé, et pourquoi) n'évalue que un chargement qui est autrement correct. Un tarif fermé ne masque jamais un mauvais code, et un tarif correct qui est simplement fermé à cause du rendement n'est pas appelé un échec.

Les dates de fermeture sont les nuits de pointe qu'un programme a négocié pour exclure. Elles sont appliquées comme des fermetures dans le système de réservation, séparément du chargement du code de tarif, ce qui est exactement où le revenu s'échappe discrètement. La plateforme les vérifie de deux façons.

• Non appliquée. le tarif négocié est réservable sur une date de fermeture contractuelle. La fermeture est manquante. C'est un échec (BLACKOUT_NOT_APPLIED) et le bouton de correction peut mettre en scène la fermeture.
• Correctement fermée. un tarif fermé sur une date de fermeture est attendu. Le moteur ne le lit jamais comme un échec.

Une honnête garde, si rien ne revient pour une fenêtre qui s'assied entièrement à l'intérieur d'une fermeture, c'est cohérent avec la fermeture, mais le silence ne peut pas confirmer que le chargement a jamais été fait correctement. La tâche reste PENDING (chargement non confirmé), jamais faussement VERIFIED et jamais faussement échouée. Vérifiez-la à partir d'une date non fermée.

Un tarif peut être chargé à la bonne valeur et être quand même faux sur les dates, actif pour la mauvaise fenêtre, ou expiré sans renouvellement derrière lui. La plateforme vérifie la période d'effet de deux façons.

• Écart de couverture (WRONG_EFFECTIVE_DATE). un chargeur sonde quelques fenêtres de séjour. Si le tarif négocié revient pour une fenêtre mais est vide pour une autre fenêtre qui s'assied à l'intérieur de la période contractuelle, les dates pour lesquelles elle est actif ne correspondent pas à la période négociée. Pour éviter une fausse détection, la fenêtre de preuve doit réellement contenir le code négocié, et la fenêtre de preuve et la fenêtre vide doivent provenir de la même pseudo city, donc un tarif libéré à un bureau mais pas à un autre se lit comme un écart de libération, pas un écart de date.
• Expiré (EXPIRED). la période négociée a pris fin et aucun renouvellement ne la succède (une fenêtre ultérieure ou ouverte pour le même programme le ferait). C'est un examen doux (NEEDS_RENEWAL), pas un échec difficile, le tarif doit être renouvelé ou supprimé, mais il peut être chargé parfaitement autrement, donc il ne se lit jamais comme un chargement cassé et jamais comme VERIFIED.

La disponibilité de la dernière chambre et la parité tarifaire sont de véritables exigences du programme, mais ni l'une ni l'autre n'imprime sur l'écran de vue agent qu'un chargeur colle. LRA est un contrôle d'inventaire et de vente, la parité est une comparaison inter-canaux. Donc la plateforme ne les devine pas à partir du collage. Une personne nommée, ou un enregistrement CRS, atteste si une restriction exigée a été reportée sur le chargement, et seule une restriction exigée attestée comme baissée produit une détection (DROPPED_RESTRICTION).

L'autorité de cette attestation est classée honnêtement. Un enregistrement CRS montrant une baisse LRA est de grade machine et échoue le chargement. Une attestation humaine d'une baisse LRA plafonne la tâche à UNVERIFIABLE_LRA jusqu'à ce qu'un enregistrement CRS la confirme, plutôt que de surévaluer un échec. Une baisse de parité plafonne toujours à UNVERIFIABLE_PARITY, car la vraie parité ne peut être prouvée que par l'achat sur plusieurs canaux. Le moteur enregistre le fait attesté, il n'en invente jamais un, donc une attestation ne peut jamais fabriquer un faux échec.

Séparément, quand le tarif négocié est présent mais fermé tandis que d'autres inventaires se vendent toujours sur un programme LRA, cette violation confirmée est sa propre détection (LRA_FAIL), lue directement à partir du collage.