Requerimiento para Migración:

1.1. Descripción Proceso de Migración

El proceso de migración comienza (o se gatilla) seleccionando beneficiarios con Código de Designación=3
(Pendiente de MIGR), el cual se encuentra en el campo AOP_ANDESOPREST de la tabla AFI_PERSONA
(vía Proceso Shell que se ejecuta cada 1 hora).

Una vez seleccionados los beneficiarios con código igual a ‘3’, se debe:
 Migración debe marcar a los beneficiarios con código “4” (En proceso de Migración) y comenzar las
tareas de migración.

El proceso de migración incluye los objetos: Cargas Familiares, Solicitudes de Acreditación y extinción,
Declaraciones Juradas y AFAs, considerando las reglas de negocio estipuladas en el documento de
“Especificación de Migración_vXX”

** Especificar como se migran los objetos según beneficiario seleccionado***

Parámetros de Entrada por Objeto:
- Cargas Familiares: RUT Beneficiario Designado.
- Solicitudes: RUN Causantes, de beneficiarios designados.
- Declaraciones: RUT Beneficiario Designado.
- AFAs: RUT Beneficiario Designado.

1.2. Resultados y Acciones del Proceso de Migración.

Los resultados que podría tener la migración, al ir concretando los distintos pasos pueden ser los
siguientes:
a. Selección de beneficiario, con error, enviar a informe de error.
- Error de comunicación con Menú Andes: El operador re-ejecutará el proceso hasta
recuperar la conexión con el servidor.

b. Selección de beneficiario “OK” y extracción sin datos, porque beneficiario no tiene datos a
migrar, entonces cambiar estado de designación a 2.

c. Selección de beneficiario “OK”, Modificada a código “4” y Extracción con error, proceder según
lo siguiente:
- Error de comunicación con Menú Andes: El operador re-ejecutará el proceso hasta
recuperar la conexión con el servidor.
- Error de data services: reintentos manuales dentro de las próximas 1 horas, sino
cambiar los registros a “1”. Los reintentos manuales, deben quedar estipulados en un
Procedimiento Técnico, el cual será entregado al Operador del Governance
correspondiente.
- Incompletitud de data para ser migrada: al momento de detectar incompletitud de
data, migración debe registrar el error en el log y cambiar estado de designación a 1.
 d. Selección de beneficiario “Ok”, Modificada a código “4”, Extracción “OK” e Inyección con error,
proceder según lo siguiente:
- Inconsistencia de Base de Datos: Si existe inconsistencia entonces cambiar estado de
designación a 1.
- Error de comunicación con Servidor de Base de Datos: El operador re-ejecutará el
proceso hasta recuperar la conexión con el servidor.
- …
e. Selección, extracción e inyección, terminen “Ok”, entonces cambiar estado de designación a 2.

OBS 1: El cambio de estado de designación, producto del resultado de la migración, debe ser realizado
por el Proceso de Migración.

OBS 2: Considerar que extracción e inyección, pueden contemplar procesos de validación manuales (de
usuario) antes de dar un OK definitivo. Es el Equipo de Migración quien debe determinar todas las tareas
necesarias para dar como válido el proceso de migración.

1.3. Tiempos del Proceso de Migración.

La migración se debe ejecutar inmediatamente al momento de designar un beneficiario como 3
(Pendiente de migración) con el fin de que los procesos de back office no deban esperar por una
migración desfasada.
Esto implica dos opciones a validar por el área técnica:
a) Migración en línea (con servicios).
b) Migración con un proceso Batch que se esté ejecutando continuamente.

1.4. Controles del Proceso de Migración.

La migración debe llevar un control de todos aquellos trámites que solicitaron migración, indicando si
terminó correctamente o con error y en el caso de tener error, llevar un control a detalle de los errores.

1.5. Migración de Datos de Cargas Familiares.

Aparte de las cargas familiares vigentes y para efectos de completitud de información y continuidad de
servicios, también se debe migrar la información de los otros afiliados con los que el causante haya estado
relacionado (sólo migrar como información histórica). La factibilidad de realizar este proceso debe
revisarse con las áreas técnicas de CLA y de Indra, para determinar si es posible de realizar de acuerdo a
la estructura de datos de legado y de PPFF. (Para mayor detalle revisar Anexo, punto III).

1.6. Riesgo MIGR.

Todo proceso de Asignación Familiar posterior a la migración indicada asociado a las cargas de un
beneficiario designado a PPFF, puede quedar desactualizado debido a que la carga puede ser invocada
por otro beneficiario.
Opciones de mitigación:
1. Solo SIAGF podrá validar la acreditación en PPFF para dichos casos.
2. Además del punto 1, realizar migraciones diarias de cargas que estén asociadas a Beneficiarios
de PPFF, lo cual no debe duplicar la información ya migrada.
3. Bloquear las cargas en Menú Andes, que fueron migradas con los beneficiarios designados.
 Este riesgo debe ser mitigado por el equipo de migración, en base al análisis para implementar este
requerimiento.

* Jaime solicitará estadística a Don Luis con número de beneficiarios por carga en un período de 5 años,
diferenciando por reconocimiento por período anterior o actual.

Anexo
I. Esquema para Migración de Selección de Cargas en base al beneficiario Designado.
El esquema que se refleja a continúan describe la selección de causantes, en base a los afiliados
candidatos a PPFF que son designados a PPFF, para la consideración en la migración de toda la
información necesario.

Considerar que este diagrama aplica para los cuatro objetos a migrar: Cargas Familiares, Solicitudes de
Acreditación /Extinción, Declaraciones Juradas y AFAs.