CU_160_Tratamiento de Vigencias_v1.0

CU-160
Antecedentes del Caso de Uso
Caso de Uso:
Proyecto:
Código de Proyecto:
Nivel:
Contexto:
Actor Principal:
Actores Asociados:
Sistemas Externos:
Intereses:
Precondiciones:
Resultado Esperado:
Referencias:
Riesgos:
Tratamiento de vigencias
GPNR IBERIA
Aún no definido
[ ] – Resumen/General
[ ] – Usuario
[X] – Sub Función
Subproceso activado por el proceso de Carga Diaria, el cual realiza los
pasos necesarios para identificar todos los registros a los cuales se les
debe iniciar vigencia y cerrar vigencia.
Carga diaria
Operaciones
N/A
Actor Fuera de Escena
Intereses
Área Revenue Management Usar esta información para cargar modelo
de gestión propio.
Las etapas 1 a 6 del proceso de carga diaria terminaron exitosamente.
Las entidades Reservas, Reservas_segmentos, Reservas_pax y Ticket tiene
identificados los registros que iniciaran y cerraran vigencia en el proceso
de carga que está ocurriendo
CU_100 – Carga diaria
CU_120 – Procesar Reservas
CU_130 – Procesar Segmentos
CU_140 – Procesar Pax
CU_150 – Procesar Tickets
CU_200 – Control y monitoreo
N/A
Descripción de los Flujos
Flujo Básico
Descripción de Alto Nivel
El proceso de carga diaria activa el subproceso de vigencia, proceso que debe iniciar la vigencia a los
registros nuevos y cerrar vigencia a los que sufrieron cambio, fueron cancelados o volados
Dicho Proceso deberá asignar el valor:
Reservas:
 rvas_fch_inicio
 rvas_fch_fin
Reservas_Segmentos:
 rssg_fch_inicio
 rssg_fch_fin
Reservas_Pax
 rpax_fch_inicio
 rpax_fch_fin
Tickets:
 tkts_fch_inicio
 tkts_fch_fin
Casos de Uso – Tratamiento de Vigencias | Versión. 1.0 | 15-11-2015
Página 1 de 7
Descripción Detallada (Paso a Paso)
1. El Proceso de carga diaria activa el subproceso de validación de integridad PNR.
2. El subproceso registra punto de control, indicando el inicio de la actividad. Ver caso de uso
CU200 – Control y Monitoreo.
3. El Proceso extrae los registros los record locator y fecha de creación de la tabla temporal de
reservas.
4. El Proceso extrae íntegramente todas las entidades de PNRs del modelo final que crucen con los
PNR obtenidos en el paso anterior.
5. El proceso determina que pnrs del paso 3 y 4 son total volados o cancelados REF[001]
6. El proceso elimina íntegramente todos los registros de los PNR del paso 3 que cumplan la
condición anterior y que no crucen con los datos del paso 4 [PNRs creados y cancelados el
mismo día].
7. El proceso determina que cambios se han producido por cada entidad, entre los datos
temporales y los recuperados en el paso 4. REF[002]
8. El proceso setea los inicios y cierres de vigencia para cada entidad REF[003]
9. El subproceso registra punto de control, indicando el término de la actividad. Ver caso de uso
CU200 – Control y Monitoreo.
10. Fin del Caso de Uso.
Flujos Alternativos
El Sistema no logra la
conexión con la base de
datos.
[ X ] Excepción
[ ] Validación
[ ] Búsqueda
[ ] CRUD
[ ] Otro
NO Hay Espacio en
FileSystem.
[ X] Excepción
[ ] Validación
[ ] Búsqueda
[ ] CRUD
[ ] Otro
El Proceso termina con
Problemas distintos a las
excepciones anteriores.
[
[
[
[
[
] Excepción
] Validación
] Búsqueda
] CRUD
] Otro
Descripción de Alto Nivel
El Proceso NO se conecta a la Base de datos de Gestión PNR
Descripción Detallada (Paso a Paso)
1. El subproceso NO logra acceder a la base de datos.
2. El proceso de Carga diaria finaliza con error. Ver caso
de uso CU200 – Control y Monitoreo.
3. Fin del caso de uso
Descripción de Alto Nivel
El Proceso detecta que NO tiene espacio en el FileSystem
asignado a Sistema en el Servidor DataStage para
almacenar los datos.
Descripción Detallada (Paso a Paso)
1. El Proceso NO encuentra espacio en el FileSystem de
DataStage para almacenar la información.
2. El proceso de Carga diaria finaliza con error. Ver caso
de uso CU200 – Control y Monitoreo.
3. Fin del caso de uso
Descripción de Alto Nivel
El Proceso termina con Problemas.
Descripción Detallada (Paso a Paso)
1. El Proceso termina con Problemas.
2. El proceso de Carga diaria finaliza con error. Ver caso
de uso CU200 – Control y Monitoreo.
3. Fin del caso de uso
Integraciones
1. <<Nombre Sistema Externo 1>>
1.1 <<Nombre de la Acción 1.1>>
Precondiciones
Post condiciones
Flujos Normal y
Descripción Detallada (Paso a Paso)
Casos de Uso – Tratamiento de Vigencias | Versión. 1.0 | 15-11-2015
Página 2 de 7
[Listas las
precondiciones que
deben cumplirse para
que la integración sea
exitosa.]
[Indicar el estado de
cómo debe quedar tanto
el sistema origen como el
externo luego de la
transacción (no aplica
para consultas).]
Alternativos
Flujo Normal
<<Evento que
gatilla el flujo>>
<<Evento que
gatilla el flujo>>
N/A
N/A
N/A
Información Complementaria
Comentarios y aspectos no resueltos
Los resultados de este proceso quedaran en tablas temporales por entidad que serán usadas en la carga
final:
Reservas a iniciar vigencia
Reservas a cerrar vigencia
Segmentos a iniciar vigencia
Segmentos a cerrar vigencia
Reservas_pax a iniciar vigencia
Reservas_pax a cerrar vigencia
Tickets a iniciar vigencia
Tickets a cerrar vigencia
Pax a iniciar vigencia
Implementación
REF[001]: Reglas para identificar un PNR al cual se le debe cerrar vigencia:
a. La regla de PNR volado, es decir, todos sus segmentos fueron volados hace más de 3 días.
b. La regla de reutilización de código de pnr, es decir, si llega un reserva por PNR files, cuyo record
locator coincide un record locator de la tabla RESERVAS de GPNR, pero ese record no coincide
en fecha de creación, entonces se deben cerrar las vigencias de ese PNR porque se creó otra
reserva en el host que reutilizo el record locator, de acuerdo a lo informado por los PNR files.
c. La regla de PNR completamente cancelado, es decir, un PNR informado en PNR files con todos
sus segmentos cancelados.
Nota: Para mantener la lógica del punto C equivalente a la implementada en NH_GPNR, los segmentos
cancelados activos se descartan en cálculos complejos, módulo V del caso de uso de segmentos.
REF[002]: Los atributos que definen si un registro ha sufrido modificación son:
a.
Tabla RESERVAS cruza el registro temporal con el del modelo final por record y fecha de
creación, si alguno de los siguientes campos es distinto se considera cambio en el registro.
De lo contrario el registro mantiene su vigencia en el modelo final.
cdds_cdg_destino
cdds_cdg_origen
pses_cdg_iso
rvas_cdg_ageiata
rvas_cdg_pnr
rvas_cdg_pnr1a
rvas_cdg_pnrcrs
Casos de Uso – Tratamiento de Vigencias | Versión. 1.0 | 15-11-2015
Página 3 de 7
rvas_dias_estadia
rvas_fch_reserva
rvas_fch_vlo_1seg
rvas_ind_grupo
rvas_ind_nego
rvas_ind_ofipropia
rvas_ind_roundtrip
rvas_ofi_amadeus
rvas_ofi_emisora
rvas_ofi_other
rvas_txt_routing
rvas_txt_routingclase
stdt_cdg
rvas_cdg_tipofi
b.
Tabla RESERVAS_SEGMENTOS cruza el registro temporal con el del modelo final por record,
fecha de creación, correlativo segmento, si alguno de los siguientes campos es distinto se
considera cambio en el registro. De lo contrario el registro mantiene su vigencia en el
modelo final.
ato_cdg_destino
ato_cdg_destino_verdadero
ato_cdg_destinoinbound
ato_cdg_destinooutbound
ato_cdg_origen
ato_cdg_origen_verdadero
ato_cdg_origeninbound
ato_cdg_origenoutbound
cdds_cdg_destino
cdds_cdg_destino_verdadero
cdds_cdg_destinoinbound
cdds_cdg_destinooutbound
cdds_cdg_origen
Casos de Uso – Tratamiento de Vigencias | Versión. 1.0 | 15-11-2015
Página 4 de 7
cdds_cdg_origen_verdadero
cdds_cdg_origeninbound
cdds_cdg_origenoutbound
cltf_cdg
esrs_cdg
rgcv_comercializador
rssg_cdg_clasecodshare
rssg_cdg_linea
rssg_cdg_lineacodeshare
rssg_cdg_lineainbound
rssg_cdg_lineaoutbound
rssg_cdg_pnr_padre_nego
rssg_dias_estadia
rssg_fch_creasegmento
rssg_fch_llegadasegmento
rssg_fch_salidasegmento
rssg_fch_ultimoestado
rssg_fch_vuelo
rssg_nmr_pax
rssg_nmr_paxnoshowbajada
rssg_nmr_paxgoshowbajada
rssg_nmr_paxdeniedbrdngbaj
rssg_nmr_segmento
rssg_nmr_vuelo
rssg_nmr_vuelocodeshare
rssg_nmr_vueloinbound
rssg_nmr_vuelooutbound
rssg_tipo_codeshare
rvas_cdg_pnr
rvas_fch_reserva
tsmk_cdg
Casos de Uso – Tratamiento de Vigencias | Versión. 1.0 | 15-11-2015
Página 5 de 7
c.
Tabla TICKETS cruza el registro temporal con el del modelo final por número de ticket, si
alguno de los siguientes campos es distinto se considera cambio en el registro. De lo
contrario el registro mantiene su vigencia en el modelo final.
rvas_cdg_pnr
rvas_fch_reserva
tkts_fch_ticket
tkts_nmr_cupon
tkts_nmr_ticket
tkts_tipo_emision
d.
Tabla PAX cruza el registro temporal con el del modelo final por record, fecha de creación,
correlativo pax, si alguno de los siguientes campos es distinto se considera cambio en el
registro. De lo contrario el registro mantiene su vigencia en el modelo final.
pax_apds
pax_cdg_fqtv
pax_fch_nacimiento
pax_lnar_fqtv
pax_nmbs
pax_pasaporte
pax_sexo
pax_ttlo_cortesia
pses_cdg_iso
Nota: Los registros de cualquier entidad que estén en un pnr temporal, que no esté en su homologo del
modelo final se considera como nuevo. Viceversa se considera como cancelado.
REF[003]: Se fijan los valores de inicio y cierre de vigencia.
Reglas generales
1. PNR Nuevo (todas sus entidades):
a. Inicio vigencia: Fecha del archivo
b. Fin vigencia: 2050-01-01
2. PNR Modificado (en alguna de sus entidades):
a. Fin vigencia PNR anterior: Fecha del archivo – 1
b. Inicio vigencia PNR modificado: Fecha del archivo
c. Fin vigencia PNR modificado: 2050-01-01
3. PNR Cancelado (todas sus entidades):
a. Inicio vigencia: Fecha del archivo
b. Fin vigencia: Fecha del archivo
Excepciones
1. Se pide que cuando llegue un PNR completamente cancelado (sin segmentos activos) y éste ya
Casos de Uso – Tratamiento de Vigencias | Versión. 1.0 | 15-11-2015
Página 6 de 7
existe con vigencia (2050-01-01) en la base de datos, se pide que se genere una nueva vigencia
en la tabla RESERVAS.
Fecha
[Fecha de la última
revisión.]
Registro de Cambios del Caso de Uso
Revisión
Descripción
Autor
[# de
[Modificación [Nombre del
revisión.]
realizada.]
autor del
documento.]
Casos de Uso – Tratamiento de Vigencias | Versión. 1.0 | 15-11-2015
Fuente
[Contraparte
del cliente
que otorgo
la
definición.]
Aprobación
[Contraparte
del cliente
que aprobó
la
definición.]
Página 7 de 7