Operaciones masivas (Bulk)

Dentro de la plataforma existen modelos de datos y representaciones de datos para el alta masiva de pólizas y certificados.

El siguiente capítulo detalla como debería ser el procesamiento de archivos para el vuelco masivo de operaciones. El objetivo es procesar por lotes la información de altas, renovaciones, endosos y anulaciones.

La siguientes tablas muestran la estructura de datos mínimas para el alta de una póliza, ya sea en su modalidad colectiva o individual. El objetivo es procesar por lotes la información de altas, renovaciones, endosos y anulaciones enviadas periódicamente por diferentes actores a la plataforma.

La característica del archivo de intercambio posee el siguiente formato:

• ASCII.
• CSV Comma Separated Values (Valores separados por coma).
• Los campos numéricos sin valor deberán poseer un cero.
• Los campos alfanuméricos sin valor deberán tener un blanco o nada.
• Los campos fecha sin valor deberán tener un blanco o nada.
• Todos los importes deberán estar con dos decimales y sin coma.
• Las fechas deberán tener formato yyyymmdd.
• Las horas con formato hhMMss.
• Todos los campos que son alfanuméricos deberán ser informados entre comillas dobles, esto evitará la mala interpretación de caracteres especiales, sobre todo cuando algunos campos pueden poseer comas o apóstrofes.

Archivos

Para la obtención de los archivos, el generador de los mismos deberá proveer los siguientes elementos:

• Servicio SFTP. (https://es.wikipedia.org/wiki/SSH_File_Transfer_Protocol)
• Usuario y password de acceso. Mejor si provee un certificado generado por el servicio.
• Path de lectura del archivo, verificando que el usuario provisto tenga permisos de acceso y lectura.
• Un archivo diario con la nomenclatura que se describe a continuación.

La nomenclatura del archivo será la siguiente respetando la configuración de la identificación en la plataforma.

Identificación del canal + sub canal +  Nombre interfaz  + fecha en forma yyyymmdd + hora en formato hhmmss

Servicio de detección de cambios en los directorios

Para poder detectar que un archivo se creó o ha sido modificado en la plataforma, Insurance Service Bus tiene la capacidad de suscribirse a eventos que suceden en un directorio, de manera tal de que cualquier cambio que ocurra en el mismo el bus podrá disparar diversos eventos de procesamiento de archivos. De esta manera el ISB se comportará de forma autónoma y no se necesitará operación manual.

Este mecanismo es un servicio de soporte para la automatización del intercambio de archivos mas allá de la capa de transporte que se decida utilizar para intercambiarlos. Los eventos que se pueden suscribir en este tipo de servicios son creación, borrado o modificación.

Técnicamente desde el ISB se necesitan realizar los siguientes pasos para la implementación de este servicio:

• Crear un servicio que implemente la interfaz Watchable, la clase existente Path es ideal para este tipo de operaciones.
• Definir los eventos sobre los cuales estamos interesados para luego disparar servicios de procesamiento de datos. En el ejemplo utilizamos StandardWatchEventKind que implementa WatchEvent.Kind.
• Un modificador que especifica como la interfaz Watchable es registrada con WatchService.

El siguiente ejemplo, describe como la interfaz suscribe a eventos de un directorio dentro de la plataforma.

//define a folder root it my suscribe windows like folders or unix/linux 
//Path myDir = Paths.get("D:/data");
Path myDir = Paths.get("/opt/data");

try {
  WatchService watcher = myDir.getFileSystem().newWatchService();
  myDir.register(watcher, StandardWatchEventKind.ENTRY_CREATE, 
  StandardWatchEventKind.ENTRY_DELETE, StandardWatchEventKind.ENTRY_MODIFY);
  //Watch for events for processing
  WatchKey watckKey = watcher.take();
  List<WatchEvent<?>> events = watckKey.pollEvents();
  for (WatchEvent event : events) {
    if (event.kind() == StandardWatchEventKind.ENTRY_CREATE) {
      //Trigger any policy processing when a file is created
      System.out.println("Created: " + event.context().toString());
    }
    if (event.kind() == StandardWatchEventKind.ENTRY_DELETE) {
      //Trigger any policy processing when a file is deleted
      System.out.println("Delete: " + event.context().toString());
    }
    if (event.kind() == StandardWatchEventKind.ENTRY_MODIFY) {
      //Trigger any policy processing when a file is modified
      System.out.println("Modify: " + event.context().toString());
    }
}

Diagrama de diseño

Cada elemento de la póliza tiene su estructura dentro del archivo el cual se describe a continuación:

0 - Cabecera (Header)

Esta misma deberá estar presente una sola vez por archivo, generalmente al principio del mismo, este es un indicador de que se va a comenzar a procesar información masiva para la plataforma. Por otro lado se identificará el código de la interfaz, campo 2, el cual determinará el modelo y modo de parsing del archivo.

99 - Pie (Trail)

El pie del archivo genera un resumen de control del archivo de procesamiento, el mismo deberá estar presente una sola vez por archivo, generalmente al final. Si el pie no coincide por el motivo que sea, ya sea por integridad de datos o porque no está presente el archivo no será procesado e insertado en la plataforma, notificando este suceso por correo electrónico.

10 - Operación Emisión

Una vez presente el encabezado del archivo, se podrán incorporar operaciones que la plataforma deberá interpretar según el código de registro. Las operaciones podrán ser de diversa naturaleza como emisiones, renovaciones o endosos. Para cada tipo de operacion se especificará un tipo de registro diferente, para emisión corresponde el tipo "10".

Entidades afectadas

Las siguientes entidades son afectadas dentro del modelo de la plataforma por este tipo de registro.

• CONTRACT_HEADER.
• POLICY.
• POLICY_STATUS.
• POLICY_AUDIT.
• POLICY_AFFINITY_GROUP.
• POLICY_REFERRAL.
• POLICY_REFERRAL_TYPE.
• Dependiendo de los valores de los campos SECTION, SUBSECTION, COVERAGE_PLAN y el nombre de la interfaz luego se alterarán entidades derivadas de POLICY como por ejemplo LIFE_POLICY, COLLECTIVE_LIFE_POLICY.

11 - Intermediarios en la operación de emisión

Con el tipo de registro 11 se especifican los intermediarios y los roles de los mismos los cuales participan de la operación previamente registrada. De esta manera se podrá representar toda la estructura comercial de la operación.

Entidades afectadas

Las siguientes entidades son afectadas dentro del modelo de la plataforma por este tipo de registro.

• CONTRACT_COMMERCIAL_STRUCTURE.
• POLICY.
• POLICY_COMMISION.

Es importante destacar que para que este tipo de registro sea ingresado satisfactoriamente, los intermediarios y estructuras comerciales deberán ser previamente configuradas.

12 - Personas que participan de la operación

Para cada una de las personas ya sean físicas o jurídicas que participan en la operación, se deberá crear un registro especial de tipo "12". Por cada persona deberemos especificar el rol de la misma.

Entidades afectadas

Las siguientes entidades son afectadas dentro del modelo de la plataforma por este tipo de registro.

• PARTY. Entidad principal para el manejo de personas.
• PERSON o ORGANISATION. Entidad para la persistencia de personas físicas o jurídicas.
• IDENTIFICATION y PARTY_IDENTIFICATION. Entidad de indentificaciones y relación con las personas.
• ADDRESS y PARTY_ADDRESS. Entidad de direcciones y su relación con personas.
• PHONE y PARTY_PHONE. Entidad de registro de teléfonos y su relación con personas.
• PARTY_ACTIVITY, PARTY_PRACTICE, PARTY_CIIU. Entidad de registro de actividades y su relación con personas.
• EMAIL, PARTY_EMAIL. Entidad de registro de correos electrónicos y su relación con personas.
• PARTY_SOURCE para identificar que esta persona viene por el sistema de migración bulk. Fuente de datos de personas.
• PARTY_STATUS. Entidad para registrar el estado de una persona, incialmente se deberá registrar como activa.
• PARTY_TYPE. Mas allá de ser una entidad persona u organización, se puede tipificar la persona como por ejemplo, retailer, comercio, municipalidad, universisdad, consumidor final, otros.

13 - Riesgos que participan de la operación

Los campos de tipo de registro "13" (Riesgos que participan de la operación) son de longitud variable en cantidad de campos según el tipo de riesgo y seguro que se esté registrando. En el caso de pólizas individuales, se encontrará un sólo registro de tipo 13 por póliza, no deberá tener número de certificado informado. A continuación se detallan todas las variantes de tipo de registro 13 para cada tipo de riesgo.

13.1 - Para riesgos de personas AP y Vida.

Se deberá informar tantos registros de tipo 13 como personas involucradas en el riesgo existan. Por ejemplo si existe una póliza individual con un asegurado y un adicional se deberá tener dos registros de tipo 13.

Entidades afectadas

Las siguientes entidades son afectadas dentro del modelo de la plataforma por este tipo de registro.

• CONTRACT_ITEM.
• CONTRACT_ITEM_AUDIT.
• CONTRACT_ITEM_STATUS.
• PERSON_INSURED.
• BENEFICIARY.

13.2 - Para riesgos de Hogar.

Entidades afectadas

Las siguientes entidades son afectadas dentro del modelo de la plataforma por este tipo de registro.

• CONTRACT_ITEM.
• CONTRACT_ITEM_AUDIT.
• CONTRACT_ITEM_STATUS.
• HOUSE.
• HOUSE_INSURED.

13.3 - Para riesgos de Bolso Protegido

Entidades afectadas

Las siguientes entidades son afectadas dentro del modelo de la plataforma por este tipo de registro.

• CONTRACT_ITEM.
• CONTRACT_ITEM_AUDIT.
• CONTRACT_ITEM_STATUS.
• OBJECT_INSURED.

14 - Coberturas

Este tipo de registro, especifica todas las coberturas que serán alcanzadas por los riesgos informados en la operación. Por cada riesgo se deberá tener este tipo de registros.

14.1 Coberturas de vida.

Se especifíca este tipo de registro para las coberturas de vida ya que pueden haber coberturas particulares para adicionales en un certificado o póliza. Para esto, se indica en este registro el tipo y número de identificación de la persona asociada a la cobertura.

14.2 Coberturas para el resto de los riesgos.

Entidades afectadas

Las siguientes entidades son afectadas dentro del modelo de la plataforma por este tipo de registro.

• CONTRACT_ITEM.
• CONTRACT_ITEM_AUDIT.
• CONTRACT_ITEM_COVERAGE.

15 - Valores económicios

Para informar los valores económicos de las pólizas o ítems, se utilizará el tipo de registro 15. Se entiende por valor económico a cualquier valor asociado a la póliza como ser impuestos, prima, premio, tasas, coeficientes, costos y recargos o cualquier otro índice que sea relevante. Para codificar cada tipo de valor económico se deberá configurar la tabla POLICY_ECONOMIC_ITEM.

Si el valor a informar corresponde a un valor genérico de la póliza el número de ítem deberá venir vacío o nulo, si el valor económico a informar corresponde al ítem se deberá informar su correspondiente número de certificado.

20 - Operación Endoso

Para informar una operación de endoso, se deberán crear registros de tipo "20".

La cabecera del registro es como la que especifica la tabla luego deberá contener todos los registros hijos como lo hacen las operaciones de emisión:

• Intermediarios.
• Personas.
• Riesgos.
• Coberturas.

30 - Operación Renovación

Para informar una operación de renovación, se deberán crear registros de tipo "30".

La cabecera del registro es como la que especifica la tabla luego deberá contener todos los registros hijos como lo hacen las operaciones de emisión:

• Intermediarios.
• Personas.
• Riesgos.
• Coberturas.

40 - Operación Siniestros

Para informar los siniestros se crearán registros de tipo 40, de manera tal que se puedan reportar en forma batch todos aquellos siniestros de la cartera de pólizas.

Todos los sinistros tienen que tener al menos un hecho generador representado por un subregistro de uno de tipo 40.

Entidades afectadas

Las siguientes entidades son afectadas dentro del modelo de la plataforma por este tipo de registro.

• CLAIM.
• CLAIM_AUTHORITY.
• CLAIM_CAUSE.
• CLAIM_CHARACTERISTIC.
• CLAIM_DAYTIME_TYPE.
• CLAIM_OCCURRENCE.
• CLAIM_STATUS.
• CLAIM_SUBCAUSE.
• LIFE_CLAIM.

41 - Subsiniestro para vida y AP

Entidades afectadas

Las siguientes entidades son afectadas dentro del modelo de la plataforma por este tipo de registro.

• LIFE_CLAIM.
• CLAIM_CUESTIONARIE, CLAIM_QUESTION, CLAIM_ANSWER, CLAIM_CUESTIONARIE_QUESTION. Para todos aquellos que requieren inspección de vida.

42 - Subsiniestro de Hogar.

En el caso de tener varias coberturas afectadas ingresar múltiples subsiniestros de registro 42.

Entidades afectadas

Las siguientes entidades son afectadas dentro del modelo de la plataforma por este tipo de registro.

• HOUSE_CLAIM.
• CLAIM_CUESTIONARIE, CLAIM_QUESTION, CLAIM_ANSWER, CLAIM_CUESTIONARIE_QUESTION. Para todos aquellos que requieren inspección de hogar.

43 - Subsiniestro de Bolso Protegido

Entidades afectadas

Las siguientes entidades son afectadas dentro del modelo de la plataforma por este tipo de registro.

• OBJECT_CLAIM.
• CLAIM_CUESTIONARIE, CLAIM_QUESTION, CLAIM_ANSWER, CLAIM_CUESTIONARIE_QUESTION. Para todos aquellos que requieren inspección.

60 - Cobranzas

Entidades afectadas

Las siguientes entidades son afectadas dentro del modelo de la plataforma por este tipo de registro.

• BILLING_STATEMENT.
• BILLING_COLLECTION.

90 - Asientos contables

El siguiente ítem describe la forma de realizar asientos contables por interfaces. El sistema de carga de asientos por interfaces responde a un formato específico acorde al plan de cuentas configurado y a una serie de validaciones que se llevarán a cabo previamente a la inserción de los mismos.

91 - Renglones de asientos contables

El siguiente tipo de registro representa todos los renglones de los asientos contables.