Definición Tecnica PCCE PDF

Documento Proyecto
Homologación Call
Técnico del Center –Portal Call
Proyecto Center
<<Código del Proyecto>>
El objetivo de este instrumento consiste en documentar los procesos técnicos y las

especificaciones de diseño que serán implementadas en la solución tecnológica.
DOCUMENTO TÉCNICO DEL PROYECTO
VICEPRESIDENCIA TECNOLOGÍA DE LA INFORMACIÓN
NOTA DE CONFIDENCIALIDAD
La información incluida en este documento ha sido preparada para ser utilizada en el contexto de
este proyecto. No debe ser utilizada como modelo o precedente en ninguna situación fuera del
presente trabajo.
Este documento no debe ser copiado o reproducido por ningún medio sin la autorización de las
partes involucradas.
Se ha realizado un gran esfuerzo en la preparación de este documento para asegurar que la
información presentada es correcta y completa.
HISTORIAL DE VERSIONES
NÚMERO DE
TEMAS REVISADOS Y MODIFICADOS FECHA EFECTIVA INSERTADA POR
REVISIÓN
01 Diseño arquitectónico 01-06-2012 Karla Flores

02 Vista lógica y vista de datos 03-04-2013 Yohalmo Castillo
Eduardo Rivas
Revisión. 1.0 Pág. | 2

12-Ago-2011
Contenido
1 Diseño de Vistas de Arquitectura .........................................................................................4

1.1 Representación Arquitectónica .................................................................................. 4
1.2 Metas y Restricciones Arquitectónicas .................................................................... 5
1.3 Vista de Despliegue........................................................................................................ 6
1.3.1 Vista Física........................................................................................................................................6
1.3.2 Componentes ..............................................................................................................................8
1.3.3 Mapeo de los componentes a la infraestructura ...........................................................9
1.3.4 Requerimiento de Operaciones TI ................................................................................... 10
1.4 Vista de Implementación ........................................................................................... 10

1.4.1 Patrón Arquitectónico ........................................................................................................... 11
1.4.2 Atributos de Calidad .............................................................................................................. 12
1.5 Vista Lógica ..................................................................................................................... 13

1.5.1 Resumen General ................................................................................................................... 13
1.5.2 Paquetes de diseño arquitectónicamente significativos .......................................... 13
1.5.3 Mapeo de las clases a los componentes ....................................................................... 16
1.6 Vista de Datos ................................................................................................................ 17

1.6.1 Entidades de persistencia ................................................................................................... 17
1.6.2 Interfaces .................................................................................................................................. 18
2 Especificación de Casos de Uso del Proyecto ................................................................19

2.1 Diagrama de Casos de Uso ....................................................................................... 20
2.2 Diccionario de Actores................................................................................................. 26
2.3 Diccionario de Casos de Uso..................................................................................... 27
2.4 Detalle de Casos de Uso............................................................................................. 28
2.5 Reglas de Negocio. ....................................................................................................... 42
3 Cumplimiento de directrices de seguridad......................................................................51
4 Seguimiento a Riesgos ...........................................................................................................51
5 Pruebas funcionales .................................................................................................................52
6 Control de Cambios TI ............................................................................................................52
7 Glosario .........................................................................................................................................52

12-Ago-2011
1 Diseño de Vistas de Arquitectura

(Fase de Planteamiento y Viabilidad)
Para esta solución se deberá seguir el patrón a capas que se describe a continuación.
cmp Components
Vista
Logica Interfaces
Acceso a Datos
1.1 Representación Arquitectónica

La solución deberá presentar un patrón arquitectónico a capas este se dividen en

• Vista: será la encargada de la lógica de presentación a los usuarios
• Logica: manejara toda la lógica de la aplicación y de negocio
• Acceso a Datos: la cual maneja la interacción con la base de datos
• Interfaces: la cual maneja las interfaces externas a otros sistemas y/o componentes.

12-Ago-2011
Adicionalmente se completar la siguiente tabla de información:
Nombre Aplicación Portal Call Center

Tipo de Aplicación Web
País de alojamiento
Descripción de la aplicación
Servidor de aplicaciones
Servidor de base de datos
Servidor de componentes
Servidor de páginas web
Servidor de robots
Nombre base de datos
Lenguaje de programación .Net
Método de Desarrollo In house
¿Tiene contrato de soporte?
¿Está configurado en alta Si
disponibilidad?
¿Está configurado con tolerancia a Si
fallos?
Responsable en IT
Usuario Responsable
Nombre de la base de datos
Motor de la base de datos Oracle 10.2
Área de negocio usuaria CCE
Proceso Soportado
Criticidad Alto detiene cara cliente
1.2 Metas y Restricciones Arquitectónicas

Metas
• Se debe garantizar la integridad de la información que será utilizada.
• Toda información sobre Tarjetas de Créditos u otra información sensible deberá estar
cifrada en la Base de datos (en caso de ser almacenada por la solución)
• Se deberán seguir las directrices y recomendaciones de PCI sobre el uso de información de
TC (tarjetas de crédito / debito)

12-Ago-2011
• Debe actualizarse el documento de PCI sobre aplicaciones que realizan transacciones de

tarjetas (debito o crédito), este puede encontrarse en el repositorio de Arquitectura
• Se deberán cumplir las políticas de Seguridad y Riesgos de la compañía
• Se deberá contar con roles de acceso a la misma
• Debe contarse con un log claro de aplicaciones, que permita registrar todos los sucesos en
el proceso de toma, conversión y entrega de la información.
• Para el modulo de reportes se deberá de utilizar Oracle Reports esto hasta no tener
definida una herramienta estándar para reportes
• Las consultas hacia otras bases de datos se deberán realizar por medio de DBlink
Restricciones
• Los cambios en el sistema debido a sinergias y/o definiciones no completas del negocio no
forman parte del alcance de este documento.
• La disponibilidad de la información, dependerá también de la disponibilidad de las
conexiones tanto de bases de datos, servidor web y/o conexión a internet/intranet
• La disponibilidad de información y/o tiempos de respuestas de otros sistemas
(middleware, feeManager) no hacen parte del diseño de esta solución
• Se debe tener en cuenta que al momento de tener definida la herramienta de reporteria
estándar, los reportes que hagan parte de esta solución deberán ser migrados a dicha
herramienta.
1.3 Vista de Despliegue

1.3.1 Vista Física

En esta vista se describen los componentes físicos de la solución en la cual se plantea una
arquitectura en alta disponibilidad, redundancia y fail load, en caso de alguna falla sobre la data.
Asi mismo se plantea un segundo despliegue para efecto de testing de la aplicación, este se
plantea con redundancia para efectos de realizar pruebas de estrés sobre la aplicación.

12-Ago-2011
Despliegue para Testing y/o pruebas

12-Ago-2011
1.3.2 Componentes
• Servidor de Aplicaciones: En este servidor se deberá alojar tanto los
componentes de lógica de la solución, las paginas aspx de la solución y los
componentes que realizaran interface con la base de datos y con terceros. Estos
deberán estar sobre un modelo de balanceo de cargas que permitirá controlar el
servicio de cada uno y así poder incrementar la disponibilidad y los tiempos de
respuesta, asi mismo se plantean servidores distribuidos geográficamente en SAL y
BOG debido a la ubicación geográfica con la que se contara en los call center
• El componente firewall: En este se deberán configurar temas de seguridad entre
otros.
• Servicios Externos: Servicios externos de los cuales hace uso la aplicación como
Middleware AVTA e integrador de ventas entre otros servicios.
• Base de Datos: Se refiere al servidor en donde se almacenara la persistencia de la
solución.
• SAN Principal, SAN de Respaldo: Se refiere al espacio compartido entre los
servidores para el almacenamiento de la data que permitirá que estos se
encuentran en un esquema fail load en caso de alguna eventualidad sobre alguno.

12-Ago-2011
1.3.3 Mapeo de los componentes a la infraestructura

12-Ago-2011
1.3.4 Requerimiento de Operaciones TI
Completar en el archivo adjunto los requerimientos a nivel de infraestructura física, que se

requieren para la ejecución de la solución tecnológica del proyecto. Del mismo modo, se debe
hacer un check en la lista que aparece a continuación con el fin de ilustrar de forma clara cuales
de las gerencias de OPS participan en el requerimiento con base en los capítulos diligenciados en
el formato anexo “Operaciones TI”
Gerencia OPS Soporte Infraestructura Telecomunicaciones Client

Technologies
Requiere
apoyo (X)
Detalle de
Requerimiento
a IT OPS Microsoft Word 97 -
2003 Document
1.4 Vista de Implementación


12-Ago-2011
1.4.1 Patrón Arquitectónico

cmp Connections
Vista
Interface de Usuario
Logica
Cotizacion Boletos y Modulo de Reserv as Interfaces

Serv ice Fee
«interface» «interface»
Interfaces::IVR Interfaces::WS-EMD
Modulo de pagos Modulo

Administracion
«interface» «interface»
Interfaces::Integrador de Interfaces::Middlew are
v entas AVTA
Serv icios comerciales Administracion de
Clientes
Acceso a Datos
«interface»
Interfaces::Base de
Datos
• Componentes Arquitectónicos
• Interface de Usuario: Se encontraran las interfaces que permitan al usuario

interactuar con el sistema
• Cotización de boletos y Service Fee: modulo de Cotización del Service Fee
• Modulo de Pagos: modulo con interface al integrador de ventas para efectuar los
pagos, en él se selecciona la forma de pago para la transacción
• Servicios comerciales: modulo que permitirá la venta de servicios comerciales
• Modulo de Reserva: modulo en el cual se habilita la generación de reservas

12-Ago-2011
• Modulo administración: modulo encargado de la administración y parametrizacion

del portal
• Administración de clientes: modulo que permite la administración de la
información de los clientes (nombre, dirección, teléfono, entre otros)
• Interfaces: interfaces que permiten a la solución la interacción con otros sistemas y/o
soluciones.
• Interface Base de Datos: Componente que permite la conexión con la base de datos
1.4.2 Atributos de Calidad
Funcionalidad: la solución debe proveer al área de call center la gestión de solicitudes y ventas
de productos y servicios ofrecidos por Aviancataca.
Rendimiento: Para alcanzarlo se diseñan estrategias de comunicación entre capas y

componentes especializados e incorporando redundancia de hardware asi también se plantea el
uso de mensajes cortos con bajo consumo de canal.
Seguridad: Al manejar información sensible (como lo es TC, informacion de clientes entre otros)
la solución deberá incorporar logs de todas las transacciones que se realicen.
En cuanto a infraestructura se deberá asegurar la comunicación de los canales entre los

servidores con SSL/HTTPS donde así lo requiera así como toda información sensible que se
almacene en la Base de Datos deberá estar cifrada, Asimismo se deberán seguir los lineamientos
de PCI, asi como las áreas de Seguridad y Riesgos de la compañia.
Disponibilidad: Se realiza un diseño en capas el cual permitirá la especialización de los

componentes y la redundancia, y así asegurar disponibilidad de cada uno de sus componentes.
Interoperabilidad: En cuanto a otros sistemas de los cuales no es posible comunicarse por

medio de WebServices, se deberá de implementar la comunicación con el sistema por medio de
DBLINK para poder interactuar con la base de datos.
Portabilidad:. siendo una aplicación WEB se asegura la portabilidad sobre los navegadores este
debe asegurar que la aplicación funcione en I.E, Mozilla y Chrome mínimamente
Re – usabilidad: El patrón arquitectónico por capas asegura la re usabilidad de los

componentes, haciendo que la operación interna de cada capa sea transparente para la siguiente.
Usabilidad: La usabilidad se deberá lograr con pantallas simples pero claras en su manejo. Es
fundamental este atributo de calidad para que el sistema se utilice y aporte lo que se busca.
Confiabilidad: A nivel de aplicación, esta debe permitir la asignación de roles y grupos de

usuarios, esto con el fin de evitar que un usuario realice operaciones fraudulentas. A nivel de
bases de datos la confiabilidad se debe asegurar con transaccionalidad (todo o nada) sobre la
base de datos y recuperación de fallas. Además, incorporación de Logs que permitan realizar
seguimientos a los procesos que se desarrollaran.

12-Ago-2011
A nivel de información sensible, se deberán seguir los lineamientos de PCI al tratar información
de Tarjetas de crédito/debito así como cifrar la información que se almacene en la BD e
incorporar seguridad en la comunicación de los canales entre los servidores con SSL/HTTPS.
1.5 Vista Lógica

(Fase de Diseño, Ejecución e Implementación)
1.5.1 Resumen General
Describir a detalle de cómo será diseñado el sistema, cuáles son las clases principales, por qué se
eligieron etc. Esta vista debe ser generada por el equipo de desarrollo.
Las clases principales dentro del Portal Call Center, son las siguientes:
• Autorization: Se encarga de realizar la autenticación de usuarios que intenten ingresar al

portal call center
• DataAccess: Se encarga de acceder a las fuentes de datos para la manipulación de los
mismos
• DataVentaBoletos: Se encarga de realizar peticiones al integrador de ventas para la
realización de ventas de boletos.
• DataVentaServicios: Se encarga de realizar peticiones al integrador de ventas para la
realización de ventas de servicios.
• DataCambiosFecha: Se encarga de realizar peticiones al integrador de ventas para la
realización de cambios de fecha en la reserva.
• DataWorkSpace: Se encarga de realizar consultas sobre estados de vuelos, pasajeros y
ticketes.
1.5.2 Paquetes de diseño arquitectónicamente significativos
Esta vista debe ser generada por el equipo de desarrollo. Debe incluir un diagrama de clases que
describa el tipo de información o nivel de detalle que debe colocarse en el diagrama de clases.

12-Ago-2011

12-Ago-2011

12-Ago-2011
1.5.3 Mapeo de las clases a los componentes
Especificar cómo será el montaje de las clases en cada uno de los componentes arquitectónicos.
Debe ser generado por el equipo de desarrollo.
Acceso a
datos
Logica de
negocio

12-Ago-2011
Autorizació
n
Vista Páginas ASPX.
1.6 Vista de Datos

1.6.1 Entidades de persistencia

Generar un diagrama de entidad relación y una descripción de cada una de las tablas.

12-Ago-2011
1.6.2 Interfaces
Describir las interfaces que el sistema expone o consume
Interfaces que consume:
Nombre de la interface: Middleware

Descripción: Servicios de acceso a Amadeus
Tipo: ASMX
Nombre de la interface: EMD Server

Descripción: Servicios de acceso a service fee y consumo de servicios varios
Tipo: ASMX
Nombre de la interface: Tarifa Administrativa

Descripción: Servicios de acceso a la tarifa administrativa para colombia
Tipo: ASMX
Nombre de la interface: Integrador de ventas

Descripción: Servicios de acceso para la gestión de ventas y cobros por
transacciones.
Tipo: ASMX
Nombre de la interface: Estado de Vuelos

Descripción: Servicios de acceso a la información de vuelos.
Tipo: ASMX
Nombre de la interface: Emd Router

Descripción: Servicios de acceso a la información de EMDs
Tipo: ASMX
Nombre de la interface: Pax

Descripción: Servicios de acceso para la gestión información de pasajeros
Tipo: ASMX
Nombre de la interface: Rapid Reprice

Descripción: Servicios de acceso para la validación y gestión de cambios
automáticos de fechas.
Tipo: ASMX
Nombre de la interface: Smiles

Descripción: Servicios de acceso para la gestión de la información de clientes
Frecuentes.
Tipo: ASMX
Nombre de la interface: GetCom Server

Descripción: Servicios de acceso para la gestión de la recuperación de información
a la planta telefónica.
Tipo: ASMX

12-Ago-2011
Nombre de la interface: DBLink ODS

Descripción: Acceso a OSD para obtener información histórica de los vuelos y
pasajeros
Tipo: Link de Tabla
Nombre de la interface: DBLink REVENUE

Descripción: Acceso a REVENUE para obtener información histórica de ticketes
Tipo: Link de Tabla
2 Especificación de Casos de Uso del Proyecto


12-Ago-2011
2.1 Diagrama de Casos de Uso

Portal-CCE-001
Firmar en IVR
Firmar en ARD
Autenticarse en la
Planta Telefónica
«uses»
Asignación de skill
Agente/Supervisor
Firmar en Portal
CCE
«uses»
Asignación de
perfil
Portal-CCE-002
«uses»
Carga de Identificación de
aplicativos homologados perfil
Carga de barra
integradora y tipificación
Agente/Supervisor

12-Ago-2011
Portal-CCE-003
Planta telefónica Portal CCE
Cargado de
Ingresar ID para información de la llamada
identificación
«uses» «uses»
Cliente
Búsqueda del Firma autómatica

cliente en BD del OID
Agente/Supervisor
Identificación del Cargado de
cliente información del cliente
Cargado de
información de la solicitud

12-Ago-2011
Portal-CCE-004
ARD
Portal CCE Proporcionar datos

del viaje
Cotización de vuelo
Verificar
disponibilidad de viaje
Informar precio
total de vuelo
Cotización de TKT
Agente/Supervisor Generar RIR Fee Manager

(Remark-Factura-Itinerario)
«extends»
Carga de impuestos Carga de Service
Fee
«extends»
Verificación de datos
capturados en llamada y cargados
desde la BD Carga de impuestos
de vuelo
Cliente
Generación de PNR

12-Ago-2011
Portal-CCE-005
Seleccionar tipo
de transacción
«uses»
Informar
formas/medios de pagos
Cliente
Agente Solicitar
forma/medio de pago
Portal-CCE-006
Crear nuevo cliente
«uses»
Agente BD cliente
Solicitar datos de
TC
«uses»
Completar datos de
IVR TC

12-Ago-2011
Portal-CCE-007
Portal CCE
Informar sobre TC
disponibles
«uses»
Cliente
Despliega
información de TC
Agente/Supervisor
«uses» IVR
Escoger TC Ingresar datos TC
Portal-CCE-008
Solicitar datos TC
«uses»
IVR Cliente
Completar datos TC
«uses»
Agente/Supervisor
Enviar información
Integrador de Ventas

12-Ago-2011
Portal-CCE-009
Convertir PNR en
referencia de pago
«uses»
Agente/Supervisor Informar Cliente

record/referencia
Enviar información
de valor a pagar
Autorización de
Integrador de ventas emisión
Banco
«uses»
Información de
autorización
Portal-CCE-010
Agente/Supervisor
Transferir llamada
Banco
Cliente
Autorización de
emisión
Portal CCE

12-Ago-2011
Portal-CCE-011
Portal CCE
IVR
Elige opción de Muestra
proceso a seguir información del Cliente
Ingresa PIN de Genera preguntas

cliente corporativo aleatorias Agente
Realiza dos pregutas

aleatorias para
validación
Cliente
Conecta a IVR
Valida PIN de
cliente corporativo
Continúa proceso
segun opción
2.2 Diccionario de Actores

Nombre Descripción
Agente CCE Usuario que ingresa y hace uso del portal CCE.
Supervisor Usuario que ingresa y hace uso del portal CCE con privilegios.
Cliente Persona que realiza la llamada al Call Center para solicitar un
servicio.
IVR Captura datos y transfiere llamadas de cliente.
BD Clientes Repositorio que contiene la información personal de los clientes.
Banco Conjunto de entidades o instituciones que prestan el servicio de
pagos de transacciones.
Portal CCE Plataforma que reúne las funcionalidades del Call Center.
MiddleWare Intermediario de comunicación entre Amadeus y las aplicaciones.

12-Ago-2011
2.3 Diccionario de Casos de Uso

Prioridad ID Nombre Descripción
Media Portal-CCE- Ingreso al Sistema Otorga los permisos y perfiles

001 necesarios al agente o supervisor para
el ingreso al Portal de CCE, por medio
de un user name y un password
Baja Portal-CCE- Carga de Opciones Despliega las opciones del usuario
002 de Usuario ingresado en el portal CCE según el
skill de su firma.
Media Portal-CCE- Cargado de Desplegar información y herramientas
003… información en el necesarias de acuerdo al tipo de
portal CCE solicitud ingresada por el cliente
capturada previamente por medio del
IVR
Alta Portal-CCE- Cotización de Verifica la disponibilidad y calcula el
004 Ticket y Service precio total del viaje según
Fee. especificaciones del cliente durante la
llamada.
Baja Portal-CCE- Selección de tipo Obtiene tipo de transacción que el
005 de transacción a cliente desea efectuar, así como la
realizar. forma de pago de acuerdo al tipo de
transacción seleccionada.
Alta Portal-CCE- Registro de Cliente Registra en la base de datos la
006 Nuevo y Tarjeta información del cliente y la(s) tarjeta(s)
de Crédito del que el cliente desea asociar a su perfil
Cliente para futuras transacciones.
Alta Portal-CCE- Autenticación de Autentica información del Cliente y de
007 Cliente y Tarjeta Tarjeta de Crédito existentes asociada
de Crédito al perfil del cliente que está realizando
Existentes. la transacción.
Alta Portal-CCE- Autenticación de Autentica información del Cliente
008 Cliente Existente y Existente y registrar nueva tarjeta de
Tarjeta de Crédito crédito asociada al perfil del cliente que
Nueva está realizando la transacción.
Baja Portal-CCE- Pago de TKT por Brinda los estatutos necesarios para la
009 transferencia realización del pago por medio de
transferencia.
Baja Portal-CCE- Pago de TKT por Brindar los estatutos necesarios para la
010 Sistema de audio- realización del pago por medio de
respuesta de Sistema de Audio-respuesta de la
entidad entidad consolidadora de bancos.
consolidadora de
Bancos (PSE)
Media Portal-CCE- Verificación de Verifica que los datos de un cliente
011 datos del cliente corporativo sean válidos para realizar
Corporativo su correspondiente transacción.

12-Ago-2011
Alta Portal-CCE- Venta de Servicios Cotizar y vender servicios para

012 reservas
Alta Portal-CCE- Cambios de Fecha Cotizar y realizar un cambio de fecha
013 para una reserva
2.4 Detalle de Casos de Uso

Id caso de uso Portal-CCE-001
Nombre del caso de uso Ingreso al Sistema
Actores
Agente, Supervisor
Objetivo Otorgar los permisos y perfiles necesarios al agente o supervisor

para el ingreso al Portal de CCE.
Precondiciones
Poseer usuario y contraseña del sistema.
Post Condiciones
Escenario de éxito:
1. Usuario se firma en IVR. (Regla de Negocio 1)
2. Usuario se firma en ARD.
3. Ingresa código de autenticación en la planta telefónica.
4. Planta telefónica asigna los skills al usuario. (Regla de negocio 1)
5. Usuario se firma en el Portal CCE (Regla de Negocio 2).
6. Portal CCE asigna el perfil al usuario.
Flujos Alternativos(Extensiones)
1. Usuario no tiene acceso a la planta telefónica.
1.1. Usuario recibe mensaje de error.
2. No se le pudo asignar un skill al usuario.

12-Ago-2011
3. Usuario no tiene acceso al Portal CCE.
4. Nombre de Usuario y contraseña no coinciden.
4.1. Se muestra un mensaje de error.
5. Cuenta de usuario está inactiva
5.1. Se muestra mensaje de error.
Nombre del caso de uso Carga de Opciones de Usuario
Actores
Agente, Supervisor
Objetivo
Desplegar las opciones del usuario ingresado en el portal CCE.
Precondiciones • Usuario previamente logueado en el portal CCE.
• El usuario debe tener un perfil previamente asignado.
Post Condiciones
1. El Portal CCE identifica el perfil del usuario ingresado. (Regla de Negocio 2)
2. El Portal CCE carga aplicativos homologados de acuerdo a perfil previamente asignado

al usuario ingresado.
3. El portal CCE carga la barra integradora.
1. Usuario no tiene perfil asignado en el Portal CCE.
1.2. Menú no desplegado.

12-Ago-2011
Nombre del caso de uso Cargado de información en el portal CCE
Actores
Agente, Supervisor, Cliente
Objetivo Desplegar información y herramientas necesarias de acuerdo al

tipo de solicitud ingresada por el cliente.
Precondiciones • Agente/Supervisor previamente logueado.
• Llamada del cliente en progreso.
Post Condiciones
1. Cliente se identifica por medio del IVR (Regla de negocio 4 y Regla de Negocio 5)
2. Planta Telefónica identifica al cliente en base de datos.
3. Portal CCE carga información de llamada.
4. El portal CCE identifica OID en el cual el agente/supervisor se firmará

automáticamente. (Regla de negocio 7)
5. El portal CCE carga la información del cliente. (Regla de negocio 7)
6. El portal CCE carga la información del tipo de solicitud que se seleccionó.
1. Cliente no introduce la información correctamente.
2. La planta telefónica no identifica al cliente en la base de datos.
2.1. La llamada es transferida a un asesor.
3. El portal CCE no carga la información del origen de la llamada
3.1. Se despliega mensaje de error y se archiva en log.
4. El portal CCE no carga la información del cliente.

12-Ago-2011
5. El portal CCE no carga la información del tipo de solicitud que el cliente seleccionó.
6. El portal CCE identifica IOD en el cual el agente/supervisor se firmará

automáticamente.
Nombre del caso de uso Cotización de Ticket y Service Fee.
Actores
ARD, Cliente, Agente, Supervisor y Fee Manager
Objetivo Verificar disponibilidad y cotizar el precio total del viaje según

especificaciones del cliente.
Precondiciones • Información del cliente cargada por el sistema.
Post Condiciones
1. Cliente proporciona información del viaje al asesor.(Regla de negocio 8 y Regla de
negocio 15)
2. El agente/supervisor verifica disponibilidad de las especificaciones del viaje.
3. Cliente elige el itinerario de vuelo.
4. El agente/supervisor realiza la cotización del ticket.
5. Se carga de manera automática los impuestos.
6. Portal CCE se conecta con Fee Manager para cargar el Service Fee.
7. El agente/supervisor informa el costo total al cliente.
8. Se genera RIR automático con el costo total cotizado.
9. Agente/supervisor verifica si los datos del cliente fueron capturados en la llamada y

cargados en la base da datos de clientes en el portal CCE.
10. Agente/supervisor transfiere información del cliente para realizar la reserva. (Regla de

12-Ago-2011
Negocio 9)
11. Agente/supervisor transfiere información del cliente a ARD para generar el PNR.
1. Cliente no proporciona información del viaje al asesor.
1.1. Notificar al cliente la información requerida para cotizar el vuelo.
2. No hay vuelos disponibles.
2.1. Notificar al Cliente.
3. Impuestos no son cargados.
3.1. Desplegar mensaje de error.
4. Portal CCE no se conecta con Fee Manager.
4.1. Desplegar mensaje de error de conexión.
5. No se genera RIR automático.
5.2. Notificarlo con ARD.
6. Los datos del cliente no pudieron ser capturados en la llamada.
6.1. El gente solicita el ID del cliente e incluye la información en la ventana del cliente
dentro del portal CCE.
7. Los datos del cliente no fueron capturados correctamente en el sistema.
7.1. Notificar error al cliente, a causa de la ausencia de algún dato faltante o mal
introducido.
8. Los datos no fueron cargados correctamente desde la base de datos Clientes.
8.1. Notificar error de base de datos.
9. La información del cliente no fue transferida.
9.1. Muestra mensaje de error.
10. La información del cliente no está actualizada
10.1. Agente/supervisor actualiza información del cliente en ARD para introducirla en

12-Ago-2011
el PNR.
Nombre del caso de uso Selección de tipo de transacción a realizar.
Actores
Agente, Supervisor y Cliente
Objetivo Obtener tipo de transacción que el cliente desea efectuar, así

como la forma de pago de acuerdo al tipo de transacción
seleccionada.
Precondiciones • Poseer cotización de reserva.
Post Condiciones
1. Cliente selecciona el tipo de transacción que desea efectuar. (Regla de negocio 10,
para aquetes turisticos Regla de negocio 16 y Regla de negocio 17)
2. Agente/supervisor informa al cliente los tipos de forma de pago de acuerdo a la

transacción que elige y el país de origen de la llamada del cliente.
3. Agente/supervisor solicita al cliente el tipo de forma de pago para efectuar la

transacción.
1. Cliente no selecciona tipo de transacción.
1.1. Notificar al cliente que debe seleccionar un tipo de transacción.
2. Formas de pago no son mostradas al agente/supervisor.

12-Ago-2011
Nombre del caso de uso Registro de Cliente Nuevo y Tarjeta de Crédito del Cliente
Actores
Agente,Supervisor, BD Clientes, IVR
Objetivo Registrar información del Cliente y de Tarjeta de Crédito del

cliente en BD.
Precondiciones • Información de cliente Adquirida
Post Condiciones
1. Agente/supervisor Solicita información del cliente.(Regla de negocio 11)
2. Cliente proporciona datos de Tarjeta de Crédito por medio de conexión IVR.
3. Agente/supervisor adiciona información de tarjeta de crédito de cliente.
4. Agente/supervisor completa información de tarjeta de crédito.
1. Información del cliente no fue obtenida o completada
2. Información de Tarjeta de crédito no fue completada
Nombre del caso de uso Autenticación de Cliente y Tarjeta de Crédito Existentes.
Actores
Agente, Supervisor, Cliente , IVR
Objetivo Autenticar información del Cliente y de Tarjeta de Crédito

existentes.
Post Condiciones

12-Ago-2011
1. Agente/supervisor selecciona la tarjeta de crédito que se utilizará. (Regla de
Negocio 11)
2. Agente/supervisor muestra información de tarjeta de crédito elegida
3. Agente/supervisor informa a cliente la tarjeta de crédito elegida.
4. Cliente completa Datos de Tarjeta de crédito vía conexión IVR
1. Cliente no completa datos de tarjeta de crédito
1.1. Notificar al cliente los datos necesarios para completar la información de tarjeta
de crédito.
Nombre del caso de uso Autenticación de Cliente Existente y Tarjeta de Crédito Nueva
Actores
Agente, Supervisor, Cliente , IVR, integrador de ventas
Objetivo Autenticar información del Cliente Existente y registrar nueva

tarjeta de crédito del mismo.
Post Condiciones
1. Agente/supervisor guarda información de tarjeta de crédito del cliente. (Regla de
Negocio 11)
2. Cliente completa Datos de Tarjeta de crédito vía conexión IVR
3. Agente/supervisor guarda información de cliente de manera permanente.
4. Agente/supervisor envía información al integrador de ventas.

12-Ago-2011
1. Cliente no completa datos de tarjeta de crédito
1.1. Notificar al cliente los datos necesarios para completar la información de

tarjeta de crédito.
2. Cliente no acepta guardar su información
2.1. En este caso solamente se guarda de manera temporal durante la

transacción del pago.
Nombre del caso de uso Pago de TKT por transferencia
Actores
Agente, Supervisor, Cliente, integrador de ventas, Banco
Objetivo Brindar los estatutos necesarios para la realización del pago por
medio de transferencia
Post Condiciones
1. Agente/supervisor convierte el record de la reserva en referencia de pago. (Regla de
Negocio 12 y 13)
2. Agente/supervisor informa a cliente record de referencia.
3. Agente/supervisor envía información del valor a pagar.
4. Banco autoriza emisión de transferencia
5. Agente/supervisor envía a integrador de ventas la autorización de la transacción.
1. Banco no autoriza emisión de transferencia.
1.1. Desplegar mensaje de error y notificar al cliente

12-Ago-2011
Pago de TKT por Sistema de audio-respuesta de entidad

Nombre del caso de uso
consolidadora de Bancos (PSE)
Actores
Agente, Supervisor, Cliente, Banco
Objetivo Brindar los estatutos necesarios para la realización del pago por
medio de Sistema de Audio-respuesta de entidad consolidadora
de bancos.
Post Condiciones
1. Agente/supervisor transfiere llamada a Banco para solicitar servicio (Regla de Negocio
14)
2. Banco autoriza servicio solicitado.
3. Agente/supervisor informa a cliente sobre la autorización del servicio y envía de

soporte de compra al cliente.
1. Banco no autoriza el servicio solicitado.
1.1. Desplegar mensaje de error y notificar al cliente

12-Ago-2011
Nombre del caso de uso Verificación de datos del cliente Corporativo
Actores
Agente, Cliente
Objetivo Verificar que los datos de un cliente corporativo sean válidos

para realizar su correspondiente transacción
Precondiciones • El cliente ha seleccionado una opción en el IVR para
corporativos
Post Condiciones
1. Cliente ingresa el la opción de transacción que desea realizar a través del IVR
2. Se muestra la información del cliente al asesor en el portal CCE.
3. Asesor continua proceso de validación del cliente por medio de preguntas

aleatorias generadas por el portal CCE.
4. Asesor transfiere al cliente hacia el IVR para que ingrese su PIN corporativo.
5. Cliente ingresa PIN corporativo a través del IVR. (Regla de negocio 5)
6. Asesor verifica el PIN corporativo ingresado por el cliente.
7. Se continua el proceso segun la transacción elegida por el cliente.

12-Ago-2011
1. Cliente no posee PIN corporativo
1.1 Se le pide que ingrese por la Pagina .com para solicitarlo
2. El PIN del cliente no es correcto.
2.1 Se le pide al cliente que vuelva a digitar su PIN
3. La información del cliente no pudo ser cargada
Nombre del caso de uso Cotización Servicios
Actores
ARD, Cliente, Agente, Supervisor y Fee Manager
Objetivo
Vender un servicio para las reservas
Post Condiciones
1. Agente realiza reserva con especificaciones proporcionadas por el cliente en ARD.
2. Agente coloca seguro en la reserva en ARD.
3. Agente coloca PNR/Ticket number en el portal call Center y da clic en cargar.
4. El portal CCE se conecta con Fee Manager para cargar el servicio e información de
reserva y pasajeros.
5. El agente elije a que pasajeros y para que piernas del itinerario asignar el servicio
seleccionado previamente.
6. El agente/supervisor informa el costo total al cliente.
7. El agente/supervisor cobra la trascción mediante alguna de las formas de pago

disponibles deacuerdo al país seleccionado.

12-Ago-2011
8. El agente/supervisor envía transacción al integrador de ventas.
1.1 Notificar al cliente la información requerida para cotizar el vuelo.
2. No hay vuelos disponibles.
2.1 Notificar al Cliente.
3. Impuestos no son cargados.
3.1 Desplegar mensaje de error.
4. Portal CCE no se conecta con Fee Manager.
4.1 Desplegar mensaje de error de conexión.
5.1 El gente solicita el ID del cliente e incluye la información en la ventana del

cliente dentro del portal CCE.
6.1 Notificar error al cliente, a causa de la ausencia de algún dato faltante o

mal introducido.
7.1 Notificar error de base de datos.
8. La información del cliente no fue transferida.
8.1 Muestra mensaje de error.
9. Transacción no recibida por el integrador de ventas
9.1 Mostrar mensaje de error con la causa por la cual la transacción no fue
aceptada por el integrador de ventas.

12-Ago-2011
Nombre del caso de uso Cambio de fechas
Actores
ARD, Cliente, Agente, Supervisor y Rapid Reprice
Objetivo
Realizar un cambio de fecha para una reserva
Post Condiciones
1. Agente coloca PNR/Ticket number en el portal call Center y el apellido del cliente
como mínimo y da clic en cargar.El agente/supervisor verifica disponibilidad de las
especificaciones del viaje.
2. El portal CCE se conecta con Rapid Reprice para validar si la reserva aplica a un
cambio de fecha.El agente/supervisor realiza la cotización del ticket.
3. El portal CCE conecta con Travelport para realizar el cambio de fecha acorde a las
necesidades del cliente.Portal CCE se conecta con Fee Manager para cargar el
Service Fee.
4. Luego de terminar el cambio en Travelport el portal despliega los totales para que
el agente notifique al cliente el costo total.
5. El agente/supervisor cobra la trascción mediante la única forma de pago disponible

para cambios de fecha: Tarjeta de CréditoAgente/supervisor verifica si los datos
del cliente fueron capturados en la llamada y cargados en la base da datos de
clientes en el portal CCE.
6. El agente/supervisor envía transacción al integrador de ventas.
1.1 Notificar al cliente la información requerida para cotizar el vuelo.
2. No hay asientos disponibles para el Nuevo itinerario.
2.1 Notificar al Cliente.
3. Portal CCE no se conecta con Rapid Reprice.
3.1 Desplegar mensaje de error de conexión.

12-Ago-2011
4.1 El gente solicita el ID del cliente e incluye la información en la

ventana del cliente dentro del portal CCE.
5.1 Notificar error al cliente, a causa de la ausencia de algún dato

faltante o mal introducido.
6.1 Notificar error de base de datos.
7. Transacción no recibida por el integrador de ventas
7.1 Mostrar mensaje de error con la causa por la cual la transacción no

fue aceptada por el integrador de ventas.
2.5 de Negocio.
Regla de Negocio 1: Obtención de Firmas del Asesor

El asesor debe registrarse en la planta telefónica del proveedor conectándose a la IVR para
firmarse en ella.
Al firmase en la planta telefónica, se le asigna un skill al agente.
Los skill configurados en la planta telefónica son los siguientes:
- Multi-Skill Comercial: Ventas y Reservas, Lifemiles, Segmento Corporativio, AviancaTour.

- Skill Front o Servicios: AviancaTour, Smiles, información de asesorias, Agencias, Agencias
Elite.
- Mono-Skill: Aerogal, Revisados (Reemitidos), Deprisa, soporte web, información asesoria,
segmento corporativo.
- Multi-Skill: Gestión cliente, Equipajes.
Los perfiles que podría adquirir son los siguientes:

- Comercial y Servicio
- Aerogal
- Revisados o Remitidos
- Deprisa
- Soporte web
- Gestión client y equipajes.
- Backoffice comercial

12-Ago-2011
- Aviacantours y de redes sociales.
Regla de Negocio 2: Registro del Asesor en el portal CEE

El asesor debe registrarse en el portal CCE introduciendo la firma, llave y contraseña para la
Planta dentro de la extensión del portal CCE.
Al registrarse en el portal CEE, éste reconoce el perfil del agente, así mismo se cargan los enlaces
necesarios acorde al perfil asignado en la pestaña de Enlances.
Regla de Negocio 3: Llamada del cliente al CEE

La planta telefónica reconoce el origen de la llamada del cliente, todo se reconoce por el origen
de la llamada, clasificando los CCE de la siguiente manera:
- CCE1: USA, Centro América

- CCE2: Colombia, América del Sur
- CCE3: Europa
Así mismo se reconoce los ANI el origen de la llamada y los DNI a donde debe dirigir la llamada.
Cada Planta telefónica tiene un menú configurado para cuando llama el viajero escoja la opción
que desea realizar. *
Posteriormente la planta telefónica según la opción digitada por el viajero redirecciona la

llamada a un IVR - ASR de servicios o a un operador.
* Estas opciones están siendo definidas
Regla de Negocio 4: Identificación del cliente.

La PT solicita al viajero que se identifique ingresando un ID (Documento de identidad, Número de
Viajero Frecuente, Documento Tributario, Pasaporte), IATA o Convenio corporativo.
Si no se identifica al viajero en las BD, se enruta la llamada a un asesor.
La PT está conectada a varias BD dependiendo de la opción digitada por el viajero, las BD
consultadas son:
- AV: smiles, No FQTV, corporativo
- Teleperformace: IATA, Ecopetrol, Cliente directos inscritos, TC corporativos (no necesitan

identificar al ingreso de la llamada)
Si no se pudieron capturar los datos del cliente en la llamada, el asesor solicita el ID del viajero y
lo incluye en la ventana de cliente que tiene el portal de CCE para hacer la búsqueda.
Regla de Negocio 5: Identificación del cliente corporativo

La PT está conectada a la base de datos de Corporativo y solicita al viajero que se identifique
ingresando su número de convenio para revisar que dicho número sea correcto, al mismo tiempo

12-Ago-2011
captura el tipo de negociación, si no lo tiene o no se identifica el número en la base de datos,

espera en línea para ser atendido por un asesor. Tiene un máximo de 3 oportunidades para
ingresar su PIN corporativo.
Regla de Negocio 6: Opciones de menú corporativo en IVR

IVR Ofrece las opciones del menú corporativo que son:
1. Redención o cambios en tiquetes redimidos
2. Consulta de saldos
3. Compras o cambios a tkt comprados
4. Información del programa
1. Redención o cambios en tiquetes redimidos: Estas solicitudes las atiende directamente el

skill de corporativo. Dentro de la barra integradora se carga la información del cliente y se
autenticará por medio de un Pop Up con 2 preguntas aleatorias. Finalmente el asesor
continúa con el proceso de redención dentro del aplicativo corporativo
2. Consulta de saldos: Estas solicitudes las atiende directamente el monoskill de corporativo.

Dentro de la barra integradora se carga la información del cliente y se autenticará por
medio de un Pop Up con 2 preguntas aleatorias.
IVR ofrece dos opciones de saldos: Back End y Saldo valores agregados para que el
cliente digite alguna de las 2 opciones y el IVR se conecte a la aplicación corporativo y
suministre información de saldos.
3. Compras o cambios a tkt comprados: En esta opción IVR ofrece dos opciones del menú: 1.
Compras y 2. cambios en tiquetes comprados.
❖ Si el cliente escoge la opción 1: Estas solicitudes las atiende directamente el

monoskill de corporativo.
El IVR de acuerdo al tipo de negociación del cliente envía al split correspondiente,
si es Cliente con negociación Up front (1), el IVR transfiere llamada a un asesor
disponible de corporativo y dentro de la barra integradora, el asesor corporativo
recibe un Pop Up con información básica del cliente corporativo y con Account
Code, posteriormente el Asesor transfiere el cliente al IVR para hacer la validación
del PIN y continua con el proceso venta aplicando descuento upfront con el account
code.
❖ Si el cliente escoge la opción 2: Estas solicitudes las atiende directamente el

multiskill comercial.
El IVR transfiere llamada a un asesor disponible de ventas. El asesor de ventas
recibe un Pop Up con información básica del cliente corporativo y recordatorio de
ingresar CC en Tour Code para continuar con el proceso venta ingresando el CC en
Tour Code en la reserva.

12-Ago-2011
4. Información del programa: Estas solicitudes las atiende directamente el monoskill de

corporativo. El IVR transfiere llamada a un asesor disponible de corporativo. Dentro de
barra integradora, le llega al Asesor corporativo un Pop Up con información básica del
cliente para que el Asesor corporativo atienda al cliente de acuerdo a su necesidad.
El proceso de venta se realizará si el viajero escogió la opción de compras o cambios a tkt

comprados con compras back end o millas.
Regla de Negocio 7: El portal CCE.

El portal CCE debe cargar la información del origen de la llamada, información del cliente y tipo
de solicitud, esta información es digitada por el cliente (barra integradora)
El portal cuenta con las siguientes secciones:
- Barra Integradora
- Tipificación Llamada
- Información del Cliente
- Script de información
- Aplicativos Homologados por perfil usuario (AVTA, Proveedor CCE, Externas)
El Portal CCE carga una barra con los siguientes datos:

• Nombre completo
• Fecha de cumpleaños
• Ciudad
• Tipo de documento
• Número de documento
• Email
• Teléfonos (Fijos-Celulares)
• Nivel Lifemiles (si aplica)
• Corporativo, que implica un convenio (si aplica)
• Dirección del cliente
El Porta CCE identifica la oficina según origen de la llamada, donde firma automáticamente al
asesor en el OID que aplique.
El portal de CCE tiene la opción de cambio manual de OID (se define por proceso los casos) y la
correspondiente firma en ese OID elegido.
Regla de Negocio 8: Cotización de Ticket y Service Fee.

Asesor debe tener en el Portal CCE cargado:
1) La información del cliente
2) la oficina según llamada de origen
3) Estar registrado en la oficina remotamente
4) Tipificación de la llamada

12-Ago-2011
5) Script de Venta
Según datos de viaje el asesor, así es la disponibilidad y cotización del TKT según origen de la
llamada en ARD.
Los impuestos se cargan de forma automática.
El Portal CCE está conectado a la aplicación de Fee Manager para cotizar los Service Fee
(servicios especiales).
La CCE muestra al Asesor el total del TKT + Service Fee para informarle al cliente el costo total
de su cotización.
Regla de Negocio 9: Realización de Reserva.

El asesor verifica si los datos del viajero fueron capturados en la llamada y cargados desde la BD
de clientes en el portal CCE.
Si los datos del cliente fueron capturados, el asesor podrá hacer transferencia de estos datos
para crear PNR automáticamente con la entrada APU de ARD.
La APP posee una ventana con formato para que el asesor diligencie cuando la BD de cliente
tenga que ser actualizada porque los datos están errados, notificando a los responsables de
actualizar los datos a una lista de tareas del BO.
Para clientes corporativos

La reserva se hace en ARD de Amadeus para convenios back end y de forma automática, en el
campo tour code se colocará el código del convenio corporativo (CC), para tkt comprados con
back end o millas, antes de la emisión.
Cuando el asesor del front hace la venta, las tarifas para corporativos están cargadas en la
categoría (XXX) y con una entrada en Amadeus cuando se hace la cotización, el PNR tiene en el
tour code el CC (convenio corporativo) para que Amadeus aplique el descuento automáticamente
(No se realiza ninguna validación desde el programa corporativo)
Cuando se va a hacer una redención, el asesor hace la reserva en ARD y luego se pasa al sistema
corporativo donde va a cargar la reserva y va a descontar los waiver, las millas, upgrade o el
back end.
Regla de Negocio 10: Información de Medios de Pago según transacción.

En el portal de CCE posee un área para poder mostrar cada proceso teniendo en cuenta las
formas y medio de pago.
Cuando el sistema identifique el país de la llamada, se activan medios y/o formas de pago de
cada país, cuando el Asesor seleccione la forma de pago se despliega la información que
suministra al cliente y un menú de opciones en el IVR de TC para seleccionar el tipo de
transacción a realizar:
• Ventas de Tiquetes
• Ventas productos comerciales ( seguro y alquiler de carros, Servicios Especiales)
• Cambios (revisado)
• Low Revenue (viajeros que solo pagan impuestos)

12-Ago-2011
• Productos LifeMiles y corporativo.
Con esta información el Asesor informa al viajero las formas y medios de pago con las que cuenta
en el país donde está haciendo la llamada. Dichas formas y medios son:
• Pago por tarjeta de Crédito
• Pago por Depósito
• Pago por Transferencia
• Pago por cheque, efectivo y a domicilio.
• Pago por Sistema de audiorespuesta de entidad consolidadora de Bancos (PSE).
Finalmente el asesor solicita al cliente que forma va a utilizar.
Para cambio de fecha únicamente se acepta la forma de pago de Tarjeta de Crédito.
Regla de Negocio 11: Formas de Pago con Tarjeta de Crédito
Para el pago con tarjeta de crédito se tienen las siguientes posibilidades:

• Cliente nuevo y Tarjeta de Crédito Nueva: Para este caso, se crea un nuevo cliente en la
base de datos con la siguiente información: Tipo de pasajero(Natural o Empresarial),
nombres, apellidos, género, fecha de nacimiento, estado civil, tipo de documento, número
de documento, identificador, número de documento, país de nacimiento, país de
residencia, ciudad de residencia, código de país, código de área, teléfonos celular y fijo,
correo electrónico y dirección. Luego se crea una nueva TC en la BD mediante la conexión
IVR para que solicite la siguiente información: Número de TC, Fecha Vencimiento, CCV2.
El asesor diligencia por medio de una ventana los datos de la TC los siguientes campos de
información:
o Número y tipo de documento (aplica solo para los casos que el ID sea alfanumérico
y esta fue la indicación del TH en el IVR)
o Entidad Bancaria (nombre banco emisor de la tarjeta)
o Dirección a donde recibe el extracto de la cuenta bancaria
o Nombres de como figura en el plástico
o Apellidos de como figura en el plástico
o Código de país
o Ciudad
o Estado
o Zip code (para US y CA)

12-Ago-2011
Se muestran los 4 últimos dígitos, CCV2 y Fecha de vencimiento, esto no es mostrado

a los asesores de Front y se almacena temporalmente hasta q se emite el TKT.
Si el número de documento es alfanumérico, el IVR indica al cliente para que marque

otra opción para cuando termine la llamada con el IVR y este saque una alerta para
que el Asesor solicite dicha información al cliente.
• Cliente Existente y Tarjeta de Crédito Existente: El asesor puede ver las tarjetas de crédito
activas que tiene guardadas el Viajero en la BD.
La Tarjeta de crédito está encriptada y le permita visualizar la siguiente información:

✓ Últimos cuatro dígitos
✓ Banco Emisor
✓ Franquicia
✓ Nombres
✓ Apellidos
✓ Código del país
✓ Ciudad
✓ Estado
✓ Zip code (para US y CA)
Hay un botón para conectar al cliente con el IVR para completar los datos de TC, el IVR
informa al Cliente la TC seleccionada (4 últimos dígitos), Si el cliente está de acuerdo, se
continúa el proceso para solicitar CVV y Fecha de Vencimiento.
Los datos de CCV y fecha de vencimiento no se almacenan en la BD, estos datos deben
estar siempre encriptados y borrados después de que se haga la compra.
Existe un botón para poder guardar la información del viajero si el acepta, o que solo
estén temporalmente en la pantalla mientras se hace la venta.
• Cliente Existente y Tarjeta de no está creada: Si el cliente no tiene una tarjeta de crédito
creada o registrada se le solicitan los datos por medio de un IVR. Debe existir un botón
que lo conecte con este IVR. Luego se conecta con IVR para solicitar: Número de TC,
Fecha Vencimiento, CCV2.
Regla de Negocio 12: Formas de Pago con Depósito/Transferencia (cuenta a cargo)

En el Portal CCE hay un programa que convierte el Record de la reserva en referencia de pago,
recolectar información de pago y armar una estructura.
Hay una conexión con los bancos donde se posee convenio para realizar pagos por medio de
transferencia. El cliente ingresa a la página del banco y hace la transferencia de pago con la
referencia que le dio el asesor para que el sistema del banco debe envíe la autorización a AVTA
para que la emisión se realice automáticamente.
El Portal CCE envía la información de autorización de pago al integrador de ventas para que haga
la emisión y notificación cliente.

12-Ago-2011
Regla de Negocio 13: Formas de Pago mediante cheque, efectivo y el pago es hecho a
domicilio.
En el Portal de CCE hay un programa para que el asesor administre las solicitudes de domicilio.
En esta APP el asesor digita la forma de pago y la dirección donde se llevará el servicio a
domicilio, fecha y hora de entrega. Este aplicativo confirma si la dirección aplica para este
servicio, también consulta en qué estado se encuentra las solicitudes de domicilio.
El portal CCE tiene un programa para recolectar información del pago y armar una estructura al
enviarla al integrador de ventas para la emisión
El integrador de ventas ingresa automáticamente la forma de pago de acuerdo a la seleccionada
por el Asesor y emite el ticket para ponerlo en estado suspendido inmediatamente después de su
emisión cuando el viaje sea en las próximas 24 horas.
Una vez el mensajero confirme vía SMS "OK PAGO" el recibido del dinero, el portal de CCE
recolecta esta información para que el asesor de BO levante automáticamente el estado de
suspendido.
Regla de Negocio 14: Formas de Pago mediante por Sistema de audiorespuesta de

entidad consolidadora de Bancos (PSE).
En el portal de CCE tiene una aplicación que permita la comunicación entre el cliente con el IVR
de la entidad consolidadora.
El aplicativo de venta captura el valor de la tarifa del TST y envía la autorización a AVTA para la
emisión automática. Posteriormente se realiza el envío de soporte de compra al cliente.
El aplicativo captura el record como llave de comunicación y der ser necesario lo convierte en
referencia de pago (información solo numérica)
Regla de Negocio 15: Cotización de paquete turístico

El Asesor cotiza el paquete turístico en la herramienta de Rezpackage.
Regla de Negocio 16: Forma de pago para paquete turístico

El asesor ingresa al portal de Call Center para consultar información del viajero, es importante
tener en cuenta que en el Call Center solo se utilizar forma de pago Tarjeta de Crédito para
paquete turístico.
Regla de Negocio 17: Pago de paquete turístico

El portal está conectado con la BD única de TC y trae información del cliente y de las TC
asociadas al mismo, si no tiene una tarjeta asociada el asesor conecta al cliente con el IVR para
que pueda crearla por medio de la conexión con el IVR.
Posteriormente el asesor debe hacer nuevamente la consulta y el portal de CCE trae los datos de
la TC encriptados, solo debe mostrar los 4 últimos dígitos.
Si ya existen tarjetas de crédito creadas en la BD, el asesor pregunta al viajero que TC va a
utilizar y la selecciona. El asesor da clic en botón de TC seleccionada y conectará al cliente con el

12-Ago-2011
IVR de TC para que el cliente digite los datos de CCV2 y fecha de vencimiento de la TC
seleccionada.
El IVR envía estos datos a la BD única donde se almacenaran temporalmente ya que después de
la venta hay un procedimiento automático para que se borren los datos.
En el portal de CCE hay una ventana donde se muestre al asesor el nombre del cliente, tipo id,
numero id, correo electrónico, cuatro últimos dígitos de la TC, numero de cuotas y campos de
para que el asesor ingrese manualmente el valor a pagar del paquete turístico.
Los campos incluidos son: El costo del valor servicio, valor de impuestos, valor otros impuestos,
valor de Tarifa Administrativa y Total del Paquete turístico. Dichos valores serán digitados
manualmente por el agente.
El Portal de CCE genera un código de la transacción a realizar, ya que el paquete turístico no ha
generado hasta el momento PNR. La transacción se hace automáticamente y de forma offline.
El portal de CCE envía información del cliente, código transacción, información del pago del
paquete turístico al integrador de ventas para que se haga la validación automática con el
modulo antifraude y pase por la pasarela de pagos.
Regla de Negocio 18: Cotización de Servicios.

4) Script de Venta
5) Información de la reserva.
El asesor coloca el código de la reserva o el número de ticket para obtener la información de la

misma, asignar el servicio seleccionado por pasajero y por itinerario.
El Portal CCE está conectado a la aplicación de Fee Manager para obtener los servicios disponibles
La CCE muestra al Asesor el total del costo del servicio.
Las formas de pago, así como sus parámetros se cargan acorde al país seleccionado.
Regla de Negocio 19: Cambios de Fecha.

4) Script de Venta

12-Ago-2011
El portal a travez de travelport realiza el cambio correspondiente en caso de que la reserva

aplique para ello, al finalizar este redirecciona denuevo al Portal CCE para obtener los costos
totales por haver realizado el cambio. Posteriormente el agente realiza el cobro respectivo.
La única forma de pago para los cambios de fecha es Tarjeta de Crédito.
Para Colombia se tendrá la opción de realizar un cobro extra, por realizar el cambio.
3 Cumplimiento de directrices de seguridad

Completar en el archivo adjunto el cumplimiento o no de las directrices y su respectiva

justificación.
Politica de Seguridad
PCCE
4 Seguimiento a Riesgos
Incluir el informe de Riesgos de TI entregado por el área correspondiente y completar El formato

de aceptación de riesgos (si aplica). Se entregan a continuación los documentos que deben
diligenciarse.

12-Ago-2011
Informe GRTI-PCCE
PV
5 Pruebas funcionales
Completar la matriz de pruebas funcionales utilizadas para llevar el control de los cambios
realizados a los casos de prueba debido a cambios en documentación, requisitos u otras
modificaciones durante el ciclo de vida del proyecto.
QC TestScript - QC TestScript -
Desarrollo.xls Operaciones.xls
6 Control de Cambios TI
Completar en el archivo adjunto el detalle de las actividades que se deben tener en cuenta para
la salida en vivo del proyecto en ambiente productivo. Este es un requerimiento que debe ser
presentado y sustentado ante el Comité de Cambios de TI, con el fin de que dicho ente entregue
el aval para la implementación.
Control de Cambios
TI
7 Glosario
(Fase de Planteamiento y Viabilidad – Fase de Diseño, Ejecución e Implementación)

12-Ago-2011
Definir o clarificar los términos principales del negocio utilizados en este documento.
TÉRMINO DEFINICIÓN

12-Ago-2011

Definición Tecnica PCCE PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Definición Tecnica PCCE PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Documento Proyecto

El objetivo de este instrumento consiste en documentar los procesos técnicos y las

01 Diseño arquitectónico 01-06-2012 Karla Flores

Revisión. 1.0 Pág. | 2

1 Diseño de Vistas de Arquitectura .........................................................................................4

1.4 Vista de Implementación ........................................................................................... 10

1.5 Vista Lógica ..................................................................................................................... 13

1.6 Vista de Datos ................................................................................................................ 17

2 Especificación de Casos de Uso del Proyecto ................................................................19

Revisión. 1.0 Pág. | 3

1 Diseño de Vistas de Arquitectura

1.1 Representación Arquitectónica

La solución deberá presentar un patrón arquitectónico a capas este se dividen en

Revisión. 1.0 Pág. | 4

Adicionalmente se completar la siguiente tabla de información:

Nombre Aplicación Portal Call Center

1.2 Metas y Restricciones Arquitectónicas

Revisión. 1.0 Pág. | 5

• Debe actualizarse el documento de PCI sobre aplicaciones que realizan transacciones de

1.3 Vista de Despliegue

1.3.1 Vista Física

Revisión. 1.0 Pág. | 6

Despliegue para Testing y/o pruebas

Revisión. 1.0 Pág. | 7

Revisión. 1.0 Pág. | 8

1.3.3 Mapeo de los componentes a la infraestructura

Revisión. 1.0 Pág. | 9

1.3.4 Requerimiento de Operaciones TI

Completar en el archivo adjunto los requerimientos a nivel de infraestructura física, que se

Gerencia OPS Soporte Infraestructura Telecomunicaciones Client

1.4 Vista de Implementación

Revisión. 1.0 Pág. | 10

1.4.1 Patrón Arquitectónico

Cotizacion Boletos y Modulo de Reserv as Interfaces

Modulo de pagos Modulo

• Interface de Usuario: Se encontraran las interfaces que permitan al usuario

Revisión. 1.0 Pág. | 11

• Modulo administración: modulo encargado de la administración y parametrizacion

1.4.2 Atributos de Calidad

Rendimiento: Para alcanzarlo se diseñan estrategias de comunicación entre capas y

En cuanto a infraestructura se deberá asegurar la comunicación de los canales entre los

Disponibilidad: Se realiza un diseño en capas el cual permitirá la especialización de los

Interoperabilidad: En cuanto a otros sistemas de los cuales no es posible comunicarse por

Re – usabilidad: El patrón arquitectónico por capas asegura la re usabilidad de los

Confiabilidad: A nivel de aplicación, esta debe permitir la asignación de roles y grupos de

Revisión. 1.0 Pág. | 12

1.5 Vista Lógica

1.5.1 Resumen General

• Autorization: Se encarga de realizar la autenticación de usuarios que intenten ingresar al

1.5.2 Paquetes de diseño arquitectónicamente significativos

Revisión. 1.0 Pág. | 13

Revisión. 1.0 Pág. | 14

Revisión. 1.0 Pág. | 15

1.5.3 Mapeo de las clases a los componentes

Revisión. 1.0 Pág. | 16

Vista Páginas ASPX.

1.6 Vista de Datos

1.6.1 Entidades de persistencia

Revisión. 1.0 Pág. | 17

Nombre de la interface: Middleware

Nombre de la interface: EMD Server

Nombre de la interface: Tarifa Administrativa

Nombre de la interface: Integrador de ventas