Cargado no es verificado

Cargado es la afirmación del cargador: se ingresó un código en la cadena. Verificado es la prueba del motor: la tarifa negociada realmente regresa a un agente, en el campo correcto, bajo una identidad autorizada, al valor negociado, y es reservable en las fechas que debería estarlo.

La mayoría de los errores de carga son silenciosos. El código se ve ingresado, pero regresa en el campo incorrecto, o un valor diferente, o una propiedad ocupante responde, o está cerrado en una noche pico que se suponía que debería proteger. Cada uno de esos es ingresos perdidos o un fracaso de auditoría corporativa. Esta plataforma convierte cada uno en una captura nombrada y evidenciada.

Cada instrucción hoy es Tipo: Carga de Tarifa: una tarifa negociada para cargar y probar. El campo de tipo está hecho para crecer, pero Carga de Tarifa es el único por ahora.

Llega a la plataforma de una de dos formas. Una instrucción recibida es una RLI que un cliente o programa envió, normalizada desde el formato que fuera que llegara. Una Auditoría es un barrido auto-iniciado: un gerente lo ejecuta, y el motor genera los estados esperados directamente desde el registro del cliente para verificar lo que ya está cargado contra el programa en archivo. Las auditorías llevan una insignia AUDIT distinta dondequiera que aparezcan.

Un cargador abre el panel de verificación, elige una propiedad y GDS, y pega la pantalla real que vería un agente. El motor canonicaliza cada fila retornada, la compara contra el estado esperado, y registra una discrepancia para cualquier cosa que no esté alineada. Verifica el código, el campo en el que se encuentra, el valor, el tipo de habitación, la identidad (nombre, ciudad seudónima, ID de oficina, código de cadena), y si algo es reservable. Re-ejecutar recomputa toda la RLI, así que el resultado siempre está actual.

Verificación (después de la carga)

Dos dimensiones se mantienen separadas a propósito. La corrección de carga (¿está el código correcto en el lugar correcto al valor correcto?) siempre falla cuando es incorrecto. La reservabilidad (¿está abierto o cerrado, y por qué?) solo califica una carga que de otro modo es correcta. Una tarifa cerrada nunca oculta un código incorrecto, y una tarifa correcta que simplemente está cerrada por yield no se llama un fracaso.

Las fechas de apagón son las noches pico que un programa negociaron para excluir. Se aplican como cierres en el sistema de reservas, separados de la carga del código de tarifa, que es exactamente donde los ingresos se pierden silenciosamente. La plataforma las verifica de dos formas:

• No aplicado: la tarifa negociada es reservable en una fecha de apagón contratada. El cierre está faltando. Esto es un fracaso (BLACKOUT_NOT_APPLIED) y el botón Fix puede preparar el cierre.
• Correctamente cerrado: una tarifa cerrada en una fecha de apagón se espera. El motor nunca lo lee como un fracaso.

Un guardia honesto: si nada regresa para una ventana que se encuentra completamente dentro de un apagón, eso es consistente con el cierre, pero el silencio no puede confirmar que la carga alguna vez se hizo correctamente. La tarea se mantiene PENDING (carga-no-confirmada), nunca falsamente VERIFIED y nunca falsamente fallida. Verifica desde una fecha no de apagón.

Una tarifa puede cargarse al valor correcto y aún ser incorrecta en fechas: vigente para la ventana incorrecta, o vencida sin renovación detrás. La plataforma verifica el período efectivo de dos formas.

• Brecha de cobertura (WRONG_EFFECTIVE_DATE): un cargador sondea algunas ventanas de estadía. Si la tarifa negociada regresa para una ventana pero está vacía para otra ventana que se encuentra dentro del período contratado, las fechas en que está vigente no coinciden con el período negociado. Para evitar una captura falsa, la ventana de prueba debe realmente contener el código negociado, y la ventana de prueba y la ventana vacía deben venir de la misma ciudad seudónima, así que una tarifa liberada a una oficina pero no a otra se lee como una brecha de liberación, no una brecha de fecha.
• Vencido (EXPIRED): el período negociado ha terminado y ninguna renovación lo reemplaza (una ventana posterior o de extremo abierto para el mismo programa lo haría). Esto es una revisión suave (NEEDS_RENEWAL), no un fracaso duro: la tarifa necesita renovarse o removerse, pero puede estar cargada perfectamente de otro modo, así que nunca se lee como una carga rota y nunca como VERIFIED.

La Disponibilidad de Última Habitación y la paridad de tarifas son requisitos reales del programa, pero ninguno se imprime en la pantalla de vista de agente que un cargador pega. LRA es un control de inventario y venta, la paridad es una comparación entre canales. Así que la plataforma no los adivina desde el pegado. Una persona nombrada, o un registro CRS, atestigua si una restricción requerida se llevó a la carga, y solo una restricción requerida atestiguada como descartada produce un hallazgo (DROPPED_RESTRICTION).

La autoridad de esa atestación se califica honestamente. Un registro CRS que muestra una caída de LRA es de grado de máquina y falla la carga. Una atestación humana de una caída de LRA limita la tarea a UNVERIFIABLE_LRA hasta que un registro CRS la confirme, en lugar de sobrealcanzar un fracaso. Una caída de paridad siempre se limita a UNVERIFIABLE_PARITY, porque la verdadera paridad solo puede probarse por compras entre canales. El motor registra el hecho atestiguado, nunca inventa uno, así que una atestación nunca puede fabricar un fracaso falso.

Separadamente, cuando la tarifa negociada está presente pero cerrada mientras otro inventario todavía se vende en un programa LRA, ese incumplimiento confirmado es su propia captura (LRA_FAIL), leída directamente desde el pegado.