Universidad de Lima

Facultad de Ingeniería y Arquitectura

Carrera de Ingeniería de Sistemas

PROYECTO DE IMPLEMENTACIÓN DE
INTEGRACIÓN ASBANC PARA
PEOPLESOFT CAMPUS SOLUTIONS
Trabajo de suficiencia profesional para optar el Título Profesional de Ingeniero de
Sistemas

Javier Arturo Tokuda Oyafuso

Código 20051439

Asesor

Percy Diez Quiñones

Lima – Perú

Diciembre del 2018

ii
PROYECTO DE IMPLEMENTACIÓN DE
INTEGRACIÓN ASBANC PARA
PEOPLESOFT CAMPUS SOLUTIONS

iii
 TABLA DE CONTENIDO

RESUMEN .............................................................................................. 1
ABSTRACT ............................................................................................ 2
INTRODUCCIÓN .................................................................................. 3
CAPÍTULO I : PROBLEMÁTICA ........................................................ 5
1.1 Contexto: ........................................................................................... 5
1.2 Descripción del problema: ................................................................ 9
1.3 Objetivo general ................................................................................ 9
1.4 Objetivos específicos del proyecto ................................................... 9
CAPÍTULO II : DEFINICIÓN DEL PROYECTO ................................ 11
2.1 Definición del Proyecto .................................................................... 11
2.2 Beneficios esperados ......................................................................... 11
2.3 Interesados......................................................................................... 11
2.3.1Áreas impactadas y principales representantes ............................... 12
2.3.2Organigrama y matriz RACI del proyecto ...................................... 13
2.3.3Descripción de las funciones del Bachiller ..................................... 16
2.3.4Aporte del Bachiller en el Proyecto Profesional ............................. 16
2.4 Cronograma y riesgos iniciales del proyecto .................................... 17
2.4.1Cronograma ..................................................................................... 17
CAPÍTULO III : DESARROLLO DEL PROYECTO ........................... 18
3.1 Iniciación ........................................................................................... 18
3.2 Planificación...................................................................................... 23
3.2.1Alcance ............................................................................................ 23

iv
3.2.2Organigrama .................................................................................... 26
3.2.3Costos .............................................................................................. 26
3.2.4Riesgos ............................................................................................ 27
3.2.5Entregables ...................................................................................... 28
3.2.6Recursos .......................................................................................... 28
3.3 Ejecución ........................................................................................... 29
3.3.1Desarrollo adicional para ASBANC: Nueva Estructura de Moras . 29
3.3.2Herramientas de Desarrollo ............................................................ 31
3.3.3Herramientas de Pruebas ................................................................. 31
3.4 Seguimiento y control ....................................................................... 32
3.4.1Lógica de códigos de alumnos por doble unidad de negocio ......... 33
3.4.2Error con los códigos que empezaban con 0 ................................... 35
3.5 Cierre ................................................................................................. 38
CAPÍTULO IV : RESULTADOS........................................................... 40
CAPÍTULO V : CONCLUSIONES ....................................................... 41
CAPÍTULO VI : RECOMENDACIONES ............................................. 43
GLOSARIO DE TÉRMINOS ................................................................. 44
REFERENCIAS ...................................................................................... 46
ANEXOS ................................................................................................. 47

v
 ÍNDICE DE TABLAS

Tabla 2-1 Cuadro de responsables del proyecto ............................................................. 13

Tabla 2-2 Matriz RACI con las abreviaturas de los nombres del equipo ....................... 15
Tabla 3-1 Cuadro comparativo de las opciones a implementar ...................................... 18
Tabla 3-2 Cuadro comparativo entre modo nativo y nuevo para las moras ................... 30
Tabla 5-1 Cuadro comparativo antes y después de la implementación ASBANC ......... 41

vi
 ÍNDICE DE FIGURAS

Figura 1-1 Flujo de Matrícula ........................................................................................... 6

Figura 1-2 Diagrama de causas que generan problemas durante la matrícula .................. 9
Figura 2-1 Organigrama Funcional - Técnico del Proyecto ........................................... 14
Figura 2-2 Cronograma del Proyecto .............................................................................. 17
Figura 3-1 Arquitectura de integración ASBANC ......................................................... 20
Figura 3-2: Diagrama de secuencia ................................................................................ 21
Figura 3-3 Flujo de los métodos a implementar ............................................................. 24
Figura 3-4 Arquitectura simplificada entre los bancos y el cliente ................................ 25
Figura 3-5 Organigrama completo del Proyecto ............................................................. 26
Figura 3-6 Información de personas y transacciones según su unidad de negocio ........ 33
Figura 3-7 Detalles Biográficos (Personas) PeopleSoft Campus ................................... 34
Figura 3-8 Cuenta de Cliente PeopleSoft Campus ......................................................... 36
Figura 3-9 VIABCP móvil: deuda del alumno ............................................................... 37
Figura 4-1 Análisis Financiero ....................................................................................... 40

vii
 ÍNDICE DE ANEXOS

Anexo 1: Presentación Mejoras Campus Evolution. ...................................................... 48

Anexo 2: Reglamento Académico Toulouse Lautrec ..................................................... 53
Anexo 3: Servicios web a implementar .......................................................................... 54
Anexo 4: Diseño Funcional ASBANC ........................................................................... 60
Anexo 5: Cotización ....................................................................................................... 75
Anexo 6: Diseño Funcional Nueva Estructura de Moras ............................................... 79
Anexo 7: Código para validar ID del cliente .................................................................. 86
Anexo 8: Documento de Especificación de Requerimientos Técnicos - Certificación .. 87

viii
 RESUMEN

El proyecto de integración con el ERP educativo PeopleSoft Campus Solutions para el

grupo educativo surge con la necesidad de implementar una solución que pueda mejorar
el proceso de recaudación debido a la demora de un día para que se pueda ver reflejado
en el sistema y a la alta carga operativa que se generaba en periodos de matrícula.

Dado que el pago es un requisito para que el alumno pueda matricularse, se

generaban procesos manuales de validación de pagos. Esto significaba costos adicionales
en personas que pudieran atender a los alumnos y verificar sus pagos y transacciones con
el banco.

El proyecto contempló una etapa inicial de análisis donde se evaluaron distintas

alternativas que pudieran cubrir este requerimiento. Posteriormente, se decidió integrar
al ERP académico con el servicio del proveedor "ASBANC" denominado “Facilitador
Transaccional de Recaudaciones” o “FTR” que permitía revisar deuda y realizar pagos
en línea con más de una entidad bancaria con un mismo servicio web.

Los resultados obtenidos con la implementación de esta solución fueron altamente

favorables. Por un lado, para el área financiera, debido a que ya no incurriría en gastos
adicionales en personal que valide las transacciones bancarias. Por otro lado, para el área
académica, debido a que los pagos impactaban directamente sobre la matrícula de
pregrado haciendo engorroso el proceso y causando incomodidad en los alumnos. Por
último, para los alumnos, sus pagos podían ser realizados momentos antes de la matrícula
no teniendo impacto en su turno de inscripción.

1
 ABSTRACT

The integration project with the Educational ERP PeopleSoft Campus Solutions for the
educational group arises with the need to implement a solution that can improve the
collection process due to the delay of one day so that it can be reflected in the system and
the high load operative that was generated in enrollment periods.

Since the payment is a requirement for the student to enroll, manual processes of
validation of payments were generated. This meant additional costs for people who could
serve the students and verify their payments and transactions with the bank.

The project contemplated an initial stage of analysis where different alternatives

that could cover this requirement were evaluated. Subsequently, it was decided to
integrate the academic ERP with the service of provider "ASBANC" called
"Transactional Facilitator of Collections" that allowed to review debt and make online
payments with more than one bank with the same web service.

The results obtained with the implementation of this solution were highly
favorable. On the one hand, for the financial area, since it would no longer incur
additional expenses in personnel that validates banking transactions. On the other hand,
for the academic area, because the payments directly impacted on the undergraduate
enrollment making the process cumbersome and causing discomfort in the students.
Finally, for the students, their payments could be made just before enrollment without
having an impact on their registration turn.

2
 INTRODUCCIÓN

El proyecto de integración ASBANC - PeopleSoft Campus Solutions para el Grupo

UCAL-TLS consistió en desarrollar una solución para poder transmitir información de
deuda de los alumnos en tiempo real a los bancos con los que se tiene convenio y poder
recepcionar los pagos de los mismos a través del proveedor ASBANC. El presente
documento académico tiene por objetivo cubrir la problemática de la institución, la
definición del proyecto, los riesgos y problemas no contemplados y, por último, las
conclusiones tras la implementación junto con el análisis financiero.

En el primer capítulo, se detallará el problema del presente informe el cual está

enfocado en el proceso de matrícula para los alumnos de pregrado y la forma de
recaudación de la organización.

En el segundo capítulo, se dará la definición del proyecto. En este, se describirán

cuáles son los beneficios esperados, stakeholders (desde el sponsor hasta los alumnos),
organigrama y cronograma.

En el tercer capítulo, se detallará el proyecto basado en las diferentes fases o

etapas de las que estuvo compuesto.

En los tres últimos capítulos, se detallarán los resultados, conclusiones y

recomendaciones respectivamente. Si bien en el capítulo de resultados está contemplado
más a manera de costo y tiempo, las conclusiones darán a conocer el impacto que tuvo el
proyecto frente a los usuarios finales: los alumnos. Finalmente, las recomendaciones
permitirán conocer a modo de lecciones aprendidas las consideraciones en futuros
proyectos similares.

Descriptores temáticos

● Integración FTR (facilitador transaccional de recaudación)

● ERP Educativo
● ASBANC

3
● Integración por web services
● Proceso de pagos
● Stakeholders

4
 Capítulo I : PROBLEMÁTICA

1.1 Contexto:

El Grupo UCAL-TLS, en adelante El Grupo, conformada por el Instituto Toulouse

Lautrec, con más de 30 años en el mercado, y la Universidad de Ciencias y Artes de
Latinoamérica (UCAL) creada en el 2010, son instituciones educativas especializadas en
diseño y creatividad que generan una oferta inigualable en las carreras de su rubro.

En setiembre del 2012, el Grupo UCAL-TLS solicitó una consultoría para la

evaluación de su situación actual (assessment) e implementación de la solución
tecnológica ‘World Class’ Oracle’s PeopleSoft Campus Solutions para cubrir las
necesidades académico-financieras de los alumnos; esto en el marco de un programa de
transformación de procesos de negocios con tecnología, que venían llevando a cabo con
éxito en toda la organización. El programa se inició el mismo año con la puesta en
producción del ERP SAP. La evaluación para el nuevo software académico duró 3 meses
y, a mediados del 2013 con la buena pro de los directores del Grupo, se decidió iniciar la
implementación de la solución de Oracle.

La implementación duró 7 meses teniendo como premisa contar con las

funcionalidades indispensables para la puesta en vivo y contar con mejoras constantes en
el sistema (como nuevas funcionalidades, mejoras en procesos, entre otros). El proyecto
tuvo como fecha de salida a producción diciembre del 2013 y la solución fue denominada
desde ese momento como Campus Evolution. Desde entonces, El Grupo ha tenido un
crecimiento económico bastante significativo, el cual equivaldría a un 20% anual
únicamente para el Instituto Toulouse Lautrec y la generación de 4 nuevas sedes. El
Grupo Enfoca adquirió la mayor parte de la participación del Grupo a inicios del 2018
(Gestión, https://gestion.pe/economia/enfoca-compra-ucal-instituto-toulouse-lautrec-
225007).

5
 A mediados del 2015, se inició una evaluación para modificar el proceso de
recaudación y conciliación bancaria con PeopleSoft Campus Solutions dado que, hasta
ese momento, aún se utilizaba los archivos de texto plano para el envío y recaudación de
deuda. El proceso, si bien funcionaba correctamente, tenía el gran problema de que era
un trabajo manual realizado en un único momento del día (usualmente en la mañana para
conciliar los pagos del día anterior). Es decir, si un alumno pagaba durante el día, el
sistema lo seguía considerando como deudor hasta la mañana del día siguiente. Esta
forma de conciliar no sería un proceso engorroso de no ser porque, en época de matrícula,
los alumnos de pregrado pagan su deuda antes de su turno de inscripción y es necesario
hacer una conciliación manual por parte de un encargado, debido a que el proceso de
conciliación recién iniciaría al día siguiente.

El proceso de matrícula para alumnos de segundo ciclo en adelante se muestra en

el siguiente flujo:

Figura I-1 Flujo de Matrícula

Proceso de matrícula y los módulos o áreas que intervienen en esta.

Fuente: Elaboración propia.

● Definir Población Nuevo Periodo: Se identifica a los alumnos que están

aptos para estudiar en el próximo periodo académico. Por ejemplo, se

6
 descarta los alumnos que hicieron retiro de ciclo en el último periodo
académico o aquellos que mantienen deuda pendiente con la institución.
● Activar Alumnos y Definir Turnos de Matrícula: Luego de identificar a
los alumnos aptos para el siguiente periodo, estos son activados en el ciclo
que podrían tener matrícula y se les asigna la prioridad o turnos de matrícula
clasificados por carrera, ciclo y promedio.
● Calcular Matrícula y 1° Cuota: A todos los alumnos activados, se realiza
lo que en el ERP educativo se conoce como “Cálculo de Matrícula” el cual
evalúa alumno por alumno identificando sus características (carrera, escala,
entre otros) para poder asignarle cuánto pagará por la matrícula y la primera
cuota. Asimismo, al generarle la deuda a los alumnos en este nuevo periodo
académico, se asigna un bloqueo para evitar que un alumno pueda
matricularse hasta haber saldado su deuda.
● Pagar Matrícula y 1° Cuota: El alumno cancela su deuda generada.
● Extornar Cargos: Dado que un alumno no está obligado a estudiar el
siguiente periodo académico; en caso decida no pagar la matrícula y 1° cuota,
simplemente se le extornan los cargos generados hasta que decida
reincorporarse a estudiar.
● Registrar Pagos y Liberar Deuda: En el caso de pagar en caja, la deuda es
liberada de forma inmediata. En el caso de que se pague a través de una
entidad bancaria, el sistema actualiza esta información al día siguiente
conciliando la deuda del alumno. Teniendo la deuda cancelada por completo,
el alumno es desbloqueado para poder realizar su matrícula académica.
● Realizar Matrícula: Los alumnos de segundo ciclo en adelante, pueden
realizar su matrícula por el autoservicio siempre y cuando no tengan una
restricción académica o cuenten con un bloqueo por deuda. Esta matrícula en
línea es realizada por turnos para poder dar prioridad de escoger los horarios
a los alumnos con mejor desempeño académico y para evitar congestionar el
sistema con una cantidad muy grande de usuarios a la vez.
Es importante recalcar que el reglamento de la institución (Toulouse, 2018),
especifica que un alumno no puede matricularse en un nuevo periodo académico de
7
contar con deuda. Asimismo, debe de cancelar los conceptos de matrícula y primera cuota
del presente periodo para poder entrar al proceso de matrícula. (Anexo 2.)

Por otro lado, es fundamental indicar que el flujo regular de matrícula inicia como
mínimo un par de semanas antes de las inscripciones de clases, dando tiempo suficiente
para que los alumnos puedan pagar. Sin embargo, es una tendencia en la población
cancelar la deuda durante la matrícula no dando tiempo suficiente para desbloquear al
alumno de su deuda para que pueda realizar su matrícula en línea.

8
1.2 Descripción del problema:

Durante las matrículas, los alumnos que pagan en bancos (por ventanilla o cualquier canal
digital) se ven afectados durante la conciliación debido a que no se actualiza en el sistema
académico de forma automática que ya no cuentan con deuda, debido a que recién se
realiza la conciliación de los pagos al día siguiente en el sistema. Esto ocasiona que se
generen colas para validar los vouchers de los alumnos que han pagado, para que puedan
matricularse según su prioridad. Esta es la única constancia que tienen los alumnos para
poder validar sus pagos el mismo día. En muchos casos, se da que, por esta demora, los
alumnos pierden cupos de las clases (curso-horario) que desean llevar.

Figura I-2 Diagrama de causas que generan problemas durante la matrícula

Diagrama con las causas que están afectando el proceso de matrícula para pregrado.

Fuente: Elaboración propia.

1.3 Objetivo general

Rediseñar y automatizar el proceso de pagos de matrícula para evitar retrasos de tal

manera que los alumnos no necesiten validar sus pagos de forma manual implementando,
a través del sistema bancario, pagos en línea.

1.4 Objetivos específicos del proyecto

● Eliminar las demoras entre el pago del alumno y la contabilización dejando que sea
transparente el proceso de matrícula para el alumno.

9
● Rediseñar y alinear los recargos administrativos y moras (intereses) con sus
respectivos cargos y pagos correspondientes.
● Eliminar trabajos manuales al revisar o remover bloqueos de deuda, especialmente
en época de matrícula.
● Reducir el tiempo de implementación de pago en línea con otras entidades
bancarias.

10
 Capítulo II : DEFINICIÓN DEL PROYECTO

2.1 Definición del Proyecto

Integración en línea utilizando el servicio de recaudación de ASBANC en su modalidad

On-Host (web services) teniendo como primera etapa convenio únicamente con el BCP.

2.2 Beneficios esperados

● Reducir el personal adicional requerido durante la matrícula para atención de los

alumnos, que concilian manualmente la deuda para permitir que se puedan
matricular.
● Identificar rápidamente alumnos deudores durante procesos críticos como la
matrícula.
● Permitir que los alumnos puedan matricularse sin retrasos.

2.3 Interesados

● Alumnos y padres de familia o apoderados.

● Área Caja (recaudación presencial).
● Dirección de Finanzas.
● Dirección de Sistemas.
● Registros Académicos.
● Entidades Bancarias (en primera instancia el BCP).
● ASBANC.

11
2.3.1 Áreas impactadas y principales representantes

o Alumnos: Esperan que, al pagar en una entidad bancaria, su pago se

vea reflejado inmediatamente en su cuenta del alumno y no tengan
problemas para matricularse.
o Caja: Dado que los alumnos llegan con un voucher, tienen que validar
el pago respectivo y desbloquear la restricción de pago pendiente para
que se puedan matricular.
o Área Finanzas: Requieren agilidad en el proceso y transparencia en
la conciliación.
o Área Registros: Están al pendiente de que los alumnos cumplan su
requisito de pago para poder matricularse.

12
2.3.2 Organigrama y matriz RACI del proyecto

Organigrama técnico-funcional. No incluye al equipo de infraestructura dado que no

teníamos contacto directo con ellos.

Tabla II-1 Cuadro de responsables del proyecto

Cuadro con los participantes, roles y a quién representaban.

Rol Empresa

Jefe de Desarrollo Grupo UCAL-TLS

Coordinador de Proyectos Grupo UCAL-TLS

Jefe Finanzas y Sponsor Grupo UCAL-TLS

Analista Finanzas del Alumnado Grupo UCAL-TLS

Analista de Servicios de Informática ASBANC

Consultor Técnico Integración ASBANC

Consultor Técnico PeopleSoft KANSEI

Consultor Funcional Campus Solutions KANSEI

Líder de Proyecto KANSEI

Fuente: Elaboración propia.

13
Figura II-1 Organigrama Funcional - Técnico del Proyecto

Organigrama funcional y técnico del proyecto.

Jefe de
Finanzas y Jefe de Proyecto
Sponsor

Coordinador de
Proyecto

Analista de Javier Tokuda

Servicios de Analistas Finanzas Líder de Proyecto
Informática – Kansei

Consultor Técnico Consultor Técnico

Integración PeopleSoft

Consultores
Funcionales
Campus Solutions

Fuente: Elaboración propia.

14
Matriz RACI:

Tabla II-2 Matriz RACI con las abreviaturas de los nombres del equipo

Cuadro con las responsabilidades de los participantes del proyecto.

Fuente: Elaboración propia.

Actividades de la matriz:

1. Reunión de explicación del servicio.

2. Reunión de definición del alcance.
3. Reunión de asignación de actividades de desarrollo PeopleSoft.
4. Desarrollo de documentos funcionales.
5. Desarrollo de servicios web.
6. Pruebas de servicios web.
7. Coordinación con el cliente de la culminación del desarrollo de servicios web.
8. Desarrollo nuevo formato de recargos administrativos para ASBANC.
9. Pruebas del nuevo formato de recargos.
10. Coordinación con el cliente de la culminación del desarrollo de nuevos recargos.
11. Pruebas de Certificación.
12. Pases a producción.
13. Monitoreo y revisión del comportamiento de la solución.

15
2.3.3 Descripción de las funciones del Bachiller

Planificación de los trabajos a realizar para implementar la solución en PeopleSoft

Campus Solutions:
● Presentación de la propuesta de implementación y estimación en tiempo y costos
para ser aprobados por el cliente.
● Evaluación de un consultor técnico adicional para apoyar con la implementación.
● Asignación de tareas a los recursos. Se contaban con un consultor técnico y dos
consultores funcionales. El consultor técnico realizaría de forma secuencial los
desarrollos de nuevo diseño de moras y servicio de integración con ASBANC. Del
lado funcional, el consultor con más experiencia se llevó la tarea de diseñar las dos
soluciones que el consultor técnico desarrollaría y, posteriormente, realizar las
pruebas integrales de la integración con ASBANC. Por otra parte, el segundo
consultor funcional, haría las pruebas integrales del desarrollo de nuevas moras. La
razón por la cual se necesitaban dos consultores funcionales más que consultores
técnicos se basa en la premisa que se requiere que especialistas en el negocio
puedan hacer pruebas integrales y no solo de la parte desarrollada. Adicionalmente,
la ruta crítica eran las pruebas y no los desarrollos.
● Seguimiento y control de las tareas.
● Entrega y comunicación de los requerimientos del sistema en el entregable de
diseño funcional.
● Entrega y comunicación del entregable proyecto (desarrollo).

2.3.4 Aporte del Bachiller en el Proyecto Profesional

● Generar propuesta de implementación.

● Generar plan de actividades.
● Gestionar y plantear soluciones para la realización del proyecto.
● Desarrollar set de pruebas.
● Validar información durante la certificación.
● Replantear escenarios por los controles de cambio.

16
2.4 Cronograma y riesgos iniciales del proyecto

2.4.1 Cronograma

Figura II-2 Cronograma del Proyecto

Cronograma de implementación para el proyecto de integración con ASBANC.

Fuente: Elaboración propia.

Leyenda de recursos

• LP: Líder de proyecto

• CP: Coordinador de proyecto
• JD: Jefe de desarrollo
• Equipo Desarrollo: Hace referencia al equipo de implementación funcional y
técnico
• AF: Analista funcional (usuario)
• Equipo ASBANC: Hace referencia al equipo del lado del proveedor del servicio.

La meta era concluir el proyecto para la matrícula 2017-0 (la matrícula del periodo
0 o verano se da en el mes de enero), por lo que debía concluir a mediados de diciembre
del 2016.

17
 Capítulo III : DESARROLLO DEL PROYECTO

3.1 Iniciación

La evaluación de la solución se inició en el 2015, brindándole opciones de integración en

línea a El Grupo. Entre ellas se tenían: Integración directa banco por banco, Integración
ASBANC, integración con VISA y CULQI.

Tabla III-1 Cuadro comparativo de las opciones a implementar

Cuadro comparativo entre implementar la integración de pagos banco por banco de forma
individual, a través de ASBANC, por VISA y Mastercard o por CULQI.

Banco por ASBANC VISA y MC CULQI

banco
Costo Implementación Por cada banco Una vez Por cada tarjeta Una vez
Tiemplo Implementación 2.5 meses 6 meses 3 meses 3 meses
Tiempo de Desarrollo 2 meses 3 meses 2.5 meses 2.5 meses
Tecnología a usar Web services Web services Web services Web services
Infraestructura adicional No requiere Instalación del No requiere No requiere
programa que
convoca al servicio
en el servidor local.
Pros Escalable para todas Permite usar
las entidades cualquiera de las
bancarias tarjetas de crédito.
Contras La Mayor duración de La implementación Costo muy alto por
implementación implementación por es por cada tarjeta. transacción
es por cada la instalación y
banco. El certificaciones que
tiempo de se dan banco por
desarrollo banco.
puede variar por
cada uno.
Entregable previo Presentación de Presentación de Presentación de
forma de forma de integración forma de integración
integración y y esfuerzo de y esfuerzo de
esfuerzo de desarrollo desarrollo
desarrollo
(continúa)

18
 (continuación)
Entregable para el Diseño Funcional y
proyecto Técnico para el
desarrollo de la
solución.
Información y
justificación de los
controles de cambio
necesarios

Costos Por transacción Por transacción Por transacción Fijo + Transacción

Fuente: Elaboración propia.

Luego de que El Grupo decidiera implementar ASBANC como solución

estratégica para cubrir sus necesidades de integración en línea para sus procesos
financieros, se revisó el alcance de la integración con el equipo de ASBANC en su calidad
de proveedor de la solución a integrar. En un primer momento, solo cubriría al banco
BCP debido a que era el único, en ese entonces, con el que contaban convenio.

PeopleSoft Campus Solutions es un sistema que permite mantener varias unidades

de negocio en una misma instancia (base o instalación). Por tal razón, tanto la unidad de
negocio del Instituto Toulouse Lautrec y la Universidad UCAL fueron implementadas
juntas y se encuentran en la misma instalación. Sin embargo, la forma de transaccionar
no es común para ASBANC, dado que los alumnos podían encontrarse en ambas
unidades de negocio y podría generar conflicto al momento de validar la deuda del
cliente. Este último punto fue desconocido para el equipo de desarrollo hasta que se
iniciaron las transacciones y se generaron incidencias.

19
Figura III-1 Arquitectura de integración ASBANC

Ejemplo de cómo se transacciona la información de pagos a través de ASBANC.

Fuente: (ASBANC, 2016)

20
 La arquitectura de ASBANC está construida para que el FTR (Facilitador
transaccional de recaudación) de ASBANC sea el intermediario entre la institución
bancaria y la empresa con la que mantiene convenio. Primero, el usuario realiza una
consulta a través de la entidad bancaria para buscar al cliente (usando un código o
identificador). En ese momento, el FTR consume el servicio expuesto para comprobar la
existencia del cliente y la deuda respectiva. Por último, si la respuesta es positiva, puede
volver a consumir el servicio a través del FTR para realizar el pago respectivo de la deuda.

Figura III-2: Diagrama de secuencia

Diagrama donde se visualizan los puntos de integración de la implementación.

Fuente: Elaboración propia.

1.1 Consultar existencia del cliente usando DNI o ID Alumno

1.2 Responde si es un cliente válido

2.1 Utilizando la información en 1.1, se consulta la deuda

2.2 Devuelve los cargos pendientes de pago

3.1 Al comprobar que existe deuda, puede pagar alguno de los ítems del 2.2.

3.2 Devuelve el estado de la operación.

Por otra parte, en ASBANC, se cuenta con dos modalidades de integración: El

On-host y el Off-host. La primera forma es una integración en línea basada en servicios
web. La segunda forma consta de generar constantemente un archivo en el servidor de
ASBANC para generar la deuda. La entidad bancaria, usando la misma lógica de la
21
arquitectura expuesta, solicita revisar la deuda, pero esta vez leerá sobre el archivo
generado y ya no un servicio web. Al momento de que se desee realizar un pago tras
consultar la deuda, se genera o actualiza un archivo con los pagos del día para que la
institución pueda conciliar con los pagos generados desde dicho archivo. Este mecanismo
no es el más eficiente debido a que no es en línea y se está sujeto a la validación periódica
del pago; si bien no tiene un retraso de un día como el de archivo de texto antiguo, puede
coincidir con que el alumno requiera matricularse cuando el pago aún no ha sido
registrado. Sin embargo, sirve de plan de contingencia cuando los servicios se saturan
por alta concurrencia. La implementación solo contará con la integración On-host.

22
3.2 Planificación
3.2.1 Alcance

La presente implementación debe lograr la integración, en primera etapa, al banco BCP

con el ERP educativo de El Grupo usando los servicios de integración de ASBANC.
Estos servicios incluyen los siguientes métodos:
● Validar Cliente: Usando los parámetros especificados por El Grupo,
permite consultar al cliente. Por ejemplo, con el código del alumno o el
DNI.
● Consultar Cliente: Tras obtener los parámetros validados del cliente, se
puede consultar la deuda con la institución.
● Realizar Pago: En caso el alumno tenga deuda, este puede realizar el pago
con la regla de pagar la deuda más antigua o vencida primero (prioridad
por antigüedad). La regla es que sean pagos totales; es decir, no se puede
pagar menos del monto adeudado por concepto o ítem (por ejemplo,
matrícula, primera cuota, seguro estudiantil, etc.). Si la deuda es de S/100,
el pago debe ser el monto exacto.
● Extornar Operación: Permite revertir la transacción realizada en un
plazo máximo de tiempo especificado en el convenio con la institución
bancaria.
La estructura de los métodos se encuentra en el anexo 3.

23
Figura III-3 Flujo de los métodos a implementar

Métodos de los servicios web y cómo transaccionan entre ellos.

Fuente: Elaboración propia.

Para poder conectarse con ASBANC, se solicitaba tener la siguiente arquitectura

en infraestructura la cual estuvo a cargo de IBM (hosting físico) que es donde están
alojados los servidores de El Grupo. Cabe recalcar que la razón por la cual se decidió por
IBM es porque el FTR debía estar alojado donde estuviera instalado el ERP o sistema
que lo iba a consumir.

24
Figura III-4 Arquitectura simplificada entre los bancos y el cliente

Arquitectura con las entidades bancos, bancared y el cliente al momento de transaccionar.

Fuente: (ASBANC, 2016)

25
3.2.2 Organigrama

Figura III-5 Organigrama completo del Proyecto

Diagrama en el que se muestran las posiciones de todos los participantes del proyecto.

Fuente: Elaboración propia

El Sponsor de El Grupo estaba representada por la jefa de finanzas quien buscaba

agilizar los procesos de recaudación.

El equipo de KANSEI o equipo desarrollador estaba compuesto por dos

consultores funcionales y un consultor técnico. Dentro de este tipo de implementaciones,
se requiere en mayor medida especialistas que conozcan de la herramienta y del negocio
para poder diseñar la solución y hacer las pruebas. Si bien el consultor técnico es
importante y debe tener experiencia en codificación, su aporte no involucra pruebas ni
involucramiento con el modelado de la solución.

3.2.3 Costos

Kansei Consulting, es una empresa fundada en el año 2015. Surge frente a la necesidad
de poder brindar servicios especializados en consultoría para los ERP PeopleSoft de
26
Oracle dado que había una falta de personal experimentado y con conocimientos del rubro
educación. Cuenta con especialistas en las ramas de Finanzas, HCM (recursos humanos),
CRM para educación y de la solución educativa. Desde sus inicios, la empresa ha
brindado servicios de soporte y mejora continua a El Grupo.

La consultora, al ser proveedor exclusivo del ERP educativo de El Grupo, realizó

un estimado de las tareas a realizar e hizo llegar su cotización de monto cerrado para la
implementación técnico-funcional como plan de mejoras continuas para El Grupo dando
un monto de S/ 27,588.40 incluido IGV. (Ver Anexo 5.)

Sin embargo, el costo se incrementó por un control de cambio para poder cubrir
una modificación que cambiaba la lógica de cómo se opera en el ERP de forma nativa.
Considerando la modificación nativa en la lógica de la generación de moras (especificado
en el alcance), soporte presencial y remoto, pruebas adicionales y controles de cambio de
la lógica de los códigos de los alumnos el monto se incrementó en S/ 6,608.00 (Estos
cambios son explicados a detalle en el punto 3.4.1 Lógica de Códigos de Alumnos por
doble unidad de negocio) y 3.4.2 Error con los códigos que empezaban con 0. Lo que
respecta a la nueva estructura de moras, se consideró como una nueva mejora y los otros
puntos fueron considerados como control de cambio por no formar parte del presupuesto
inicial para la mejora planteada. En términos de tiempo, la mitad del tiempo fue usado en
correcciones y la otra mitad en soporte específico presencial y remoto durante la primera
matrícula. Esto quiere decir que, a nivel de desarrollo, la implementación tuvo un
incremento del 12% aproximadamente.

3.2.4 Riesgos

El riesgo principal del proyecto más que el desarrollo no fluya a la velocidad

esperada, era que no hubiera la percepción de mejora por parte del alumnado quienes
fueron notificados que se iban a contar con los pagos en línea lo cual se traducía a no
tener que validar los vouchers de pago.

Por otro lado, en caso el desarrollo tuviera algún inconveniente, se hubiera

tomado la decisión de dar marcha atrás a la recaudación antigua por archivo a los bancos.
27
Esta situación era comprendida por el área de Finanzas y se minimizaba con la estrategia
de la salida en vivo durante la matrícula de verano, en la que la población era hasta un
20% menor de lo habitual a un ciclo regular.

Por otra parte, antes de la salida en vivo, ASBANC certificaba con el BCP la
situación actual de la implementación para asegurar la calidad en respuesta de las
transacciones. Esto, por lo menos, minimizaba los problemas de que las transacciones
tuvieran alguna falla.

3.2.5 Entregables

Los entregables dentro del proyecto fueron:

● Diseño funcional Integración y Recaudación FTR ASBANC. Ver Anexo 4.

● Proyecto Integración y Recaudación FTR ASBANC (código fuente).
● Diseño funcional Nueva Estructura de Moras. Anexo 6.
● Proyecto Nueva Estructura de Moras (código fuente).
● Plan de Comunicaciones con los interesados sobre avances.
● Generación de la data de prueba para las certificaciones.

3.2.6 Recursos

La mayor parte de las personas de la consultora son a tiempo parcial, Debido a que se
cuenta con capacidades limitadas, se decidió subcontratar a una persona técnica para
poder cubrir todos los requerimientos de desarrollos para este proyecto. La distribución
de las tareas se manejó de la siguiente manera:

● Consultor Funcional 1: Diseño funcional FTR ASBANC, revisión de consultas y

pruebas.
● Consultor Funcional 2: Diseño funcional Nueva Estructura de Moras y pruebas.
● Consultor Técnico: Desarrollo de FTR ASBANC y Desarrollo de Nueva
Estructura de Moras. Revisión de incidencias.

28
3.3 Ejecución

3.3.1 Desarrollo adicional para ASBANC: Nueva Estructura de Moras

Durante el desarrollo, debido a la complejidad de la generación de las tramas de los

servicios web, el equipo se percató que el método ConsultarCliente fue interpretado que
el ERP cumplía con la estructura necesaria para enviar las tramas de forma natural (sin
necesidad de transformar los datos). Una vez que el equipo de KANSEI reconoció la
dificultad y la diferencia en la forma de trabajar y la requerida, se hicieron las
validaciones respectivas con el equipo de ASBANC para confirmar la estructura y, luego,
hacer llegar al encargado de El Grupo el desarrollo adicional que había que construir para
Campus Evolution (ERP educativo renombrado de PeopleSoft Campus Solutions), a fin
de poder cubrir la estructura requerida por el método en cuestión.

¿Qué es una mora o un recargo administrativo?

Es un cobro adicional que realiza la institución cuando el cliente cae en penalidad

por no pagar en la fecha de vencimiento de un cargo adeudado. Según las políticas de
cada institución, se establecen reglas para que la penalidad sea diaria, monto fijo más
porcentual diario, porcentaje mensual, entre otros. Asimismo, las políticas empleadas
tienen que estar alineadas con la gestión de cobranza de la institución. Por último, las
moras pueden aplicar tanto a alumnos como a organizaciones.

29
Tabla III-2 Cuadro comparativo entre modo nativo y nuevo para las moras

Cuadro en el que se ejemplifica la lógica de funcionamiento del ERP frente a lo que se

necesitaba modificar a nivel de procedimiento.

Generación de Moras Nativo Nueva Estructura de Moras

Forma estándar de trabajar de Campus Solutions Construcción o desarrollo adicional que permite el
Evalúa los cargos vencidos (cuando fecha de funcionamiento con pagos en línea como tarjetas de
vencimiento es mayor a la fecha actual) y genera cargos crédito o ASBANC.
agrupados sin distinción bajo el concepto de mora. Evalúa cada cargo y genera una mora que hace
referencia a este. Esto permite poder identificar qué
cargo generó qué mora y se pueda pagar en línea
específicamente lo que debe y su recargo
correspondiente.

Ejemplo: Ejemplo:
Cuota 1: S/ 400 Cuota 1: S/ 400 Mora Cuota 1: S/ 35.4
Cuota 2: S/ 400 Cuota 2: S/ 400 Mora Cuota 2: S/ 20
Cuota 3: S/ 400 Cuota 3: S/ 400
Mora: S/55.4 (se desconoce el origen o cargo que la Las cuotas 1 y 2 presentan recargos asociados mientras
generó y, sobre todo, cuánto le corresponde) que la cuota 3 no.
Fuente: Elaboración propia.

La forma nativa o estándar de PeopleSoft Campus Solutions se basa en generar

los recargos de forma diaria por los conceptos que ya estén vencidos. No obstante, no

hace una distinción o separación de qué cargos generan qué moras y sus montos

respectivos.

La nueva estructura de moras propuso sustituir el proceso estándar para poder

generar las moras con la estructura que requería ASBANC que consta de cargo con fecha

de vencimiento y el monto de la mora en el caso contase con esta.

30
3.3.2 Herramientas de Desarrollo

Las soluciones PeopleSoft cuentan con su herramienta de desarrollo llamado

PeopleTools, la cual permite crear nuevas páginas, modificar código fuente, crear

procesos, servicios web, entre otras funciones.

El desarrollo de la solución para ASBANC consistió en proveer de un servicio

web de la instancia de Campus Evolution para que pueda ser consumido y así utilizar los

métodos planteados. El desarrollo en PeopleSoft genera un WSDL (Web Service

Description Language) que permite la comunicación y transferencia de datos entre dos

sistemas utilizando XML (Extensible Markup Language). En un primer momento, se

generó uno en el ambiente de desarrollo que también fue utilizado para certificación y,

posteriormente, a producción.

3.3.3 Herramientas de Pruebas

Para las pruebas del WSDL, se utilizó la herramienta SoapUI (soapui.org, 2018) la cual

permite, en forma sencilla, consumir el servicio (WSDL generado en PeopleSoft) para

poder hacer uso de los métodos de forma directa sin necesidad del otro extremo de

desarrollo (ASBANC) para interactuar con la información que se va enviando y

recibiendo. Es decir, se podían ir probando los servicios expuestos sin necesidad de

recurrir al programa de ASBANC ni a un banco.

31
3.4 Seguimiento y control

A nivel de tiempos, costos y calidad, se cubrieron los requisitos especificados por

ASBANC para poder certificar la solución y el BCP la acepte como apta para poder

transaccionar de forma segura (Ver anexo 8). Sin embargo, se listarán algunas

dificultades que se encontraron, ya una vez en producción, lo cual conllevó a tener que

corregir en el ambiente productivo por la urgencia de la solución.

32
3.4.1 Lógica de códigos de alumnos por doble unidad de negocio

Figura III-6 Información de personas y transacciones según su unidad de negocio

Lógica de creación de transacciones del ERP. Siendo las personas una fuente única y los
datos de venta o académicos lo que hace a una persona diferente dentro del sistema.

Fuente: Elaboración propia.

En PeopleSoft Campus Solutions (Campus Evolution), la información de

personas es compartida sin importar la cantidad de unidades de negocio se creen. Es decir,

un alumno se diferencia si es del Instituto Toulouse Lautrec o de UCAL por las

transacciones del alumno (Tx). Por ejemplo, cuando el alumno cuenta con matrícula o

tiene cargos en una u otra unidad de negocio.

33
Figura III-7 Detalles Biográficos (Personas) PeopleSoft Campus

Información personal. En la imagen se puede visualizar que una misma persona puede
tener dos códigos diferentes de alumno, pero la persona sigue siendo una sola y no una
por cada unidad de negocio.

Fuente: Oracle. 2016. PeopleSoft Campus Solutions 9.0

Para evitar estos conflictos, lo que se utiliza es un tipo de documento llamado “Código

de Alumno” el cual permite saber cuándo una persona estudia en una u otra unidad de

negocio. En la imagen superior, se puede visualizar que el alumno, adicionalmente a su

DNI, cuenta con un documento llamado “código alumno TLS” y “código alumno UCAL”

permitiendo que una misma persona (sin necesidad de crear duplicidad de datos) pueda

tener una codificación única en cada unidad de negocio.

No obstante, cuando se hizo la implementación, no se previó si es que un alumno

podía tener el mismo código de alumno en ambas unidades de negocio, dado que la

estructura en la codificación de alumnos es la misma. La lógica para ambas unidades de

negocio estaba compuesta por el año de ingreso más el semestre (semestre 1 o 2) y 5

34
dígitos correlativos (por ejemplo, 2018+1+00001). La confusión inicia cuando, al ser el

mismo servicio web tanto para el instituto Toulouse Lautrec como para UCAL (dado que

es el mismo ERP y una única integración hacia ASBANC), el sistema puede buscar un

alumno con un código cuando en realidad querían el de la otra unidad de negocio (en caso

tuvieran el mismo código de alumno), lo que generaría un error. En otras palabras, al

momento de buscar un alumno, no existía ningún identificador para saber si se quería leer

de alumnos Toulouse o alumnos UCAL y no se tuvo conocimiento de ello cuando se

diseñó la solución.

Posteriormente, ASBANC dio la solución de enviar una codificación adicional al

código de alumno en el caso se quiera pagar los conceptos educativos de Toulouse

Lautrec o la Universidad de Ciencias y Artes de Latinoamérica agregando previamente

un 0 más coma seguido del código para el caso que desee pagar el servicio de Toulouse

(0,2017129054) o un 1 más coma seguido del código para el caso que desee pagar el

servicio de UCAL (1,2017129054) para el método ValidarCliente.

Por otro lado, por iniciativa de KANSEI, se sugirió simplemente enviar el DNI,

para simplificar el proceso, dado que es un código único. Para los casos de los alumnos

extranjeros, ellos tenían la posibilidad de seguir usando el código de alumno al momento

de querer pagar.

3.4.2 Error con los códigos que empezaban con 0

Poco después de la salida en vivo, ASBANC indicó que el BCP no interpretaba a los

alumnos que tenían código que iniciaban con 0. Esto era un problema bastante grave

35
debido a que, incluso, existía codificación de código de alumno antiguos que empezaban

con 0 (por ejemplo, 091AI00001 para un alumno que ingresó en el 2009. Esta

codificación fue generada en el sistema previo a PeopleSoft Campus Solutions). De la

misma manera, los DNI de las personas que empezaban con 0 no eran leídas. Por ejemplo,

el DNI 09753242 lo interpretaba como 9753242 lo cual no era encontrado por el servicio

web.

Estos problemas, si bien no eran causados por ASBANC ni por el desarrollo de

KANSEI, tenían que ser solucionados debido a que el BCP no iba a cambiar su forma de

transaccionar. Entonces, se tuvo que manejar como un control de cambio para adicionar

ceros a la izquierda en el caso que no encuentre código para lograr una longitud máxima

de 10 caracteres que es el tamaño máximo de cualquier código que se maneje en el

sistema.

Figura III-8 Cuenta de Cliente PeopleSoft Campus

Visualización de la cuenta del cliente (información financiera del alumno) a través del
ERP Académico.

36
 Fuente: Oracle. 2016. PeopleSoft Campus Solutions 9.0

La columna de Tipo de Ítem hace referencia al concepto que tiene adeudado; por

ejemplo, cuota 3, 4 o 5. Por otra parte, en la columna Vencimiento se muestra la fecha en

la que cada cargo debe ser pagado antes que se generen recargos.

Figura III-9 VIABCP móvil: deuda del alumno

Imagen obtenida del aplicativo móvil para ejemplificar una visualización de deuda y
cómo seleccionaría el alumno para pagar sus cargos.

37
Fuente: BCP. 2018. Banca Móvil BCP versión Julio 2018.

El código utilizado para dicha lógica se encuentra en el anexo 7.

3.5 Cierre

Tras la puesta en producción de la integración con ASBANC, el proyecto dejó pendientes

para atender a corto y mediano plazo.

38
 Uno de los puntos de corto plazo o inmediato constaba en reprocesar las moras

generadas por el proceso anterior. Si antes se contaba con una gran bolsa con recargos

sin saber su origen (qué cargo vencido lo generó y cuánto es el monto), era necesario

revertir todos los conceptos moratorios para ejecutar el nuevo proceso de generación de

moras para que lo cree bajo la lógica requerida por ASBANC. Este proceso debía

mantenerse de tal forma que se ejecute diariamente para evaluar los recargos a agregar.

Por otra parte, la atención a mediano plazo se centraba en tener el plan de

contingencia e implementar la versión off-host de ASBANC. Así como encontrar puntos

de mejora para la integración on-host. Por ejemplo, optimizar las consultas SQL o

mejorar el tiempo de respuesta bajo alta concurrencia de transacciones.

39
 Capítulo IV : RESULTADOS

Figura IV-1 Análisis Financiero

Información comparativa entre el costo del proyecto actual versus el futuro.

Fuente: Elaboración propia.

Los costos de recaudación actual corresponden al modelo de recaudación por archivo de

texto plano. Estos están compuestos por el costo de soporte de mantener dicho modelo
en el que se requería bastante personal presencial y externo para atender a los alumnos
que solicitaban ayuda para validar sus comprobantes de pago en el banco.

Por otra parte, los costos del nuevo modelo en línea tuvieron una inversión que
responde al desarrollo de las integraciones y los cambios de procesos que se tuvieron que
realizar. En su contraparte, los costos de soporte resultaron considerablemente menores
debido a que no se requerían trabajos manuales ni horas extras del personal para atender
al alumnado.

Por último, la tasa interna de retorno al segundo año de la implementación

responde al 13% considerando que se redujeron considerablemente los procesos
manuales en horas adicionales por el personal interno y la disminución en el soporte
externo debido a la automatización del proceso.
40
 Capítulo V : CONCLUSIONES

A pesar de las complicaciones que surgieron en el ambiente productivo por temas

fortuitos, el proyecto fue exitoso desde distintas perspectivas y, aunque pudieron haber

surgido algunos inconvenientes con alumnos que no pudieron transaccionar por

problemas con los códigos de alumnos, se disminuyó el riesgo considerablemente,

teniendo como objetivo salir a producción en matrícula de verano en el que un

aproximado del 20% del total de alumnos se matricula.

Los datos presentados a continuación, forman parte de un análisis realizado desde

que se cuenta con el ERP PeopleSoft Campus Solutions en cuanto al antes y después de

la implementación de la solución ASBANC.

Tabla V-1 Cuadro comparativo antes y después de la implementación ASBANC

Cuadro en el que se comparan los cambios y diferencias del punto inicial a la nueva
integración y cómo esta afectó positivamente a la organización.

Antes Después

Personal para la matrícula (120 horas x persona) 8 0

Alumnos que pagan durante la matrícula 40% 20%

Alumnos afectados por turno de matrícula 20 0

Tiempo de demora en conciliación 1 día 5 minutos

Costo de implementar un banco en línea con web services S/ 27,588.00 + el S/ 0

incremento
(continúa)

41
 (continuación)

Alumnos que pagan en caja 30% 5%

Alumnos que pagan por ventanilla o agentes 50% 35%

Alumnos que pagan por internet 20% 60%

Fuente: Elaboración propia.

Por último, en cuanto al análisis financiero, los resultados mostraron que el

proyecto resultó beneficioso para la organización.

42
 Capítulo VI : RECOMENDACIONES

Uno de las lecciones aprendidas del proyecto es no asumir que, porque las pruebas
generales resultan bien, para todos los casos similares se vayan a cumplir de la misma
manera. Por tal razón, es importante considerar un checklist de todos los casos y variantes
para asegurar que se está totalmente cubierto y no se tendrá deuda técnica.
Si bien en el presente proyecto se consideraron diferentes casuísticas, no se
consideró que un código mal registrado podía ser causante de diversos problemas. Es ahí
donde ingresa la segunda recomendación: Dado que no podemos tener control de algún
sistema externo o de terceros, es necesario conocer cómo se está transmitiendo la
información y cómo está llegando. Dada las diferencias entre diversos softwares,
fabricantes o protocolos, un “0” puede ser un “0” o simplemente un espacio vacío. Dicho
esto, ninguna prueba está de más o comparar los valores del xml para asegurar la
información punto a punto.

43
GLOSARIO DE TÉRMINOS

1. FTR (Facilitador transaccional de recaudación): Es un servicio desarrollado por

ASBANC, en conjunto con los bancos, que permite a las empresas, como clientes
bancarios, realizar transacciones de forma segura y en tiempo real utilizando el
servicio de recaudación. (ASBANC, 2018)
2. ERP (acrónimo en español: Planificación de Recursos Empresariales): Hace
referencia a un sistema integrado dentro de una organización que facilitan el flujo
de información y comunicación en la empresa. Un ERP está diseñado según la
estructura de datos de forma centralizada para poder brindar una única fuente de
información. (Oracle, 2018)
3. Web Services: Los servicios web son componentes de aplicación web que
permiten, a través de estándares de comunicación, comunicar uno o más sistemas
de forma confiable. (W3SCHOOLS, 2018)
4. WSDL (Web Services Description Language): Es un lenguaje basado en XML
para describir la estructura de los servicios web. (W3SCHOOLS, 2018)
5. XML (eXtensible Markup Language): Es un lenguaje web muy parecido al
HTML utilizado para almacenar y transferir información. El código XML es auto-
descriptivo. De manera simple, el código no tiene utilidad por sí mismo y sólo
tiene utilidad cuando se utiliza con un software adicional. Dado que su función es
para almacenar datos, esta es utilizada en diversos protocolos para transferir
información. Por ejemplo:
<verDeuda>
<codigoAlumno>2018100123</codigoAlumno>
<deuda>500</deuda>
<moneda>PEN</moneda>
</verDeuda>
(W3SCHOOLS, 2018)

44
6. SOAP (Simple Object Access Protocol): Es un protocolo basado en XML para
poder acceder a los servicios web. (W3SCHOOLS, 2018)
7. Modalidad ON-HOST: Modalidad de operación sobre la que funcionará
regularmente el servicio, donde el encargado de autorizar los pagos es el sistema
de TOULOUSE, teniendo en consideración los escenarios para cada banco.
8. Modalidad OFF HOST: Modalidad de operación de contingencia en la que los
pagos son autorizados por el sistema FTR Empresa instalado en un servidor
provisto por TOULOUSE dentro de sus instalaciones, mientras se verifica se
normalice la operatividad del sistema de la empresa para retornar a la modalidad
regular de operación. Esta modalidad entra en operación por las siguientes
razones:
a. Tiempos de respuesta por encima del límite establecido para cada banco.
b. Cantidad “N” de rechazos provocados por la caída del sistema de
TOULOUSE.

45
REFERENCIAS

Toulouse Lautrec. (2018). LINEAMIENTOS BÁSICOS PARA EL SEMESTRE

ACADÉMICO 2018-1 TLS. Lima, Perú: Intranet. Recuperado de
http://intranet.tls.edu.pe/images/Tesoreria/18-1/18-1_Lineamientos_de_pago.pdf

Oracle (2018). ¿Qué es ERP? Recuperado de

https://www.oracle.com/lad/applications/erp/what-is-erp.html

Oracle (2018). PeopleSoft Campus Solutions [Software]. Recuperado de

https://www.oracle.com/lad/products/applications/peoplesoft-
enterprise/overview/index.html

ASBANC (2016). Servicios de Tecnología. Recuperado de

http://www.asbanc.com.pe/Paginas/Servicios/Servicios.aspx

SoapUI (2018) [Software]. Recuperado de

https://www.soapui.org/

W3School (2018). ¿Qué es XML? Recuperado de

https://www.w3schools.com/xml/xml_whatis.asp

W3School (2018). Servicios que utilizan XML. Recuperado de

https://www.w3schools.com/xml/xml_services.asp

BCP (2018). Banco Móvil BCP [Software]. Recuperado de

https://www.viabcp.com/

46
ANEXOS

47
LOS ANEXOS NO ESTÁN DISPONIBLES POR
CONTENER INFORMACIÓN CONFIDENCIAL

48