Emisión

Anulaciones Batch
MAPFRE SOFT
01/04/2002
Control de cambios

Histórico de Versiones
Versión Fecha Resumen de los cambios Autor
1.0 01/04/2002 Documentación Técnica MAPFRE SOFT

Autorizaciones
Nombre Fecha
Preparación
Revisión
Aprobación
Distribución

Comentarios

El presente documento es propiedad de MAPFRE y es exclusivamente para uso interno

o de cualquiera de las Entidades del Grupo MAPFRE (listado completo en la página
www.mapfre.com). No podrá ser reproducido total o parcialmente, ni procederse a su
transmisión de ninguna forma, ya sea electrónica, mecánica, por fotocopia, grabación,
reproducción u otros medios sin autorización expresa al efecto.
Índice
1 Introducción.............................................................................................................. 4
2 Anulación por falta de pago.....................................................................................5
2.1 Requisitos previos...........................................................................................................5
2.1.1 Parámetros................................................................................................................5
2.1.2 Definiciones...............................................................................................................5
2.1.3 Ejecución del filtro......................................................................................................6
2.2 Descripción...................................................................................................................... 7
2.2.1 Pólizas que no pueden ser anuladas por el proceso.................................................7
2.2.2 Pólizas que se tratan.................................................................................................7
2.2.3 Funcionamiento.........................................................................................................7
3 Anulaciones definidas por la compañía...............................................................10
3.1 Requisitos previos.........................................................................................................10
3.1.1 Definiciones.............................................................................................................10
3.1.2 Filtro......................................................................................................................... 11
3.1.3 Procedimientos disponibles.....................................................................................12
3.1.4 Excepciones............................................................................................................12
3.2 Ejecución del proceso...................................................................................................12
3.2.1 Pólizas que no pueden ser anuladas......................................................................12
3.2.2 Comprobación de las condiciones de la póliza.......................................................12
3.2.3 Pólizas que se tratan...............................................................................................13
3.2.4 Funcionamiento.......................................................................................................13

2
ANULACIONES BATCH EMISION
1 Introducción
En este documento explicaremos tanto las anulaciones batch que proporciona el sistema, que serán
siempre por falta de pago, como cualquier otro proceso de anulación que se pueda definir en cada
compañía.

En las tablas los procesos se identifican con los siguientes códigos:

TIP_MVTO_BATCH Valor
11 Anulación por falta de pago
>11 Anulaciones propias de cada compañía

Los códigos del 1 al 11 pertenecen a procesos batch del sistema, estos códigos son inalterables.

3
ANULACIONES BATCH EMISION
2 Anulación por falta de pago

2.1 Requisitos previos

2.1.1 Parámetros
Deberá existir información en la tabla de “parámetros de anulación por falta de pago” (g2000570). Con
esta información se indican los siguientes datos:

■ Recibos que se tienen en cuenta

Será necesario indicar si se tienen en cuenta o no los recibos ‘EP’ (no puestos al cobro) a la hora de
recuperar el recibo que provoca la anulación
■ Tratamiento de fechas

Se definirá la forma de comprobar el vencimiento del recibo. Por un lado habrá que indicar si se debe
recalcular la fecha, teniendo en cuenta los días de vencimiento. En caso de no recalcular, se tomará,
como fecha de comparación, la fecha de vencimiento de pago del recibo. En caso de recalcular, será
necesario indicar sobre que fecha se hará el cálculo, pudiendo ser por la fecha de efecto del recibo, la
fecha de remesa o la mayor de las dos.
■ Forma de anular

El funcionamiento normal del proceso consiste en anular la póliza o suplemento, dependiendo de donde
se encuentre el recibo que provoca la anulación. En caso de querer anular totalmente la póliza,
independientemente del suplemento en que se origine la deuda, será necesario indicar un procedimiento,
que determine si la póliza se anula por la deuda o no.

Además de los datos que contiene esta tabla, si se recalcula la fecha en que se toma el recibo como
vencido, deberá existir, al menos 1 registro genérico, en la tabla de “parámetros para procesos Batch”
(g2000500), con este registro se indica el número de días a tener en cuenta a la hora de comprobar el
vencimiento del recibo (días de vencimiento)

2.1.2 Definiciones
Es obligatorio definir los datos indicados en el documento “Procesos Batch” para la ejecución de las
anulaciones por falta de pago.

Las definiciones necesarias son las siguientes:

■ Identificación del proceso

Se debe crear un registro que identifique el proceso, en el que se indique además, la fecha de
tratamiento (por esta fecha se recuperarán las pólizas a anular) y la forma de determinar la fecha en que
vencen los recibos.
■ Filtros

Se debe ejecutar el filtro que realiza la selección de pólizas.

4
ANULACIONES BATCH EMISION
No se necesita definir un filtro, las condiciones que deben cumplir las pólizas ya están establecidas en el
programa, en la definición del proceso y en la tabla de “parámetros para procesos batch” (g2000500)
■ Excepciones
Recordemos que la exclusión de pólizas por determinadas características puede hacerse previamente,
mediante excepciones manuales o mediante filtros o puede definirse un procedimiento en la tabla de
“excepciones de procesos masivos” (g2000580) que se lanzará durante la ejecución del proceso, por
cada póliza que se trate.

Las definiciones necesarias deben ser creadas y ejecutadas por el programa de “mantenimiento de
tablas generales” (AP299510.inp)

2.1.3 Ejecución del filtro

Ejecutando el filtro se cargan, en la tabla de “pólizas para procesos batch” (a2000500), todas aquellas
pólizas que tengan recibos pendientes a la fecha de proceso.

Para determinar si el recibo está pendiente, se tendrá en cuenta la definición del tratamiento de fecha
que se ha indicado en el proceso.

Si el primer recibo que provoca la anulación es negativo, se ignora la póliza, solo se toma si existe otro
recibo positivo vencido.

Al ejecutar el filtro, por cada póliza, se ejecutará el procedimiento que determina el tipo de anulación de
la misma, grabando en la tabla una marca que indica si se anula por la deuda o se anula totalmente sin
tener en cuenta el suplemento donde se origina la deuda.

Los registros cargados en la tabla se identifican con el código de proceso de anulación por falta de pago
(TIP_MVTO_BATCH = 11)

5
ANULACIONES BATCH EMISION
2.2 Descripción

2.2.1 Pólizas que no pueden ser anuladas por el proceso

Las pólizas o suplementos que por determinadas características no puedan anularse por los
suplementos de anulación ON-LINE, no podrán tratarse en este proceso.

No podrán ser anuladas aquellas pólizas que tengan recibos, posteriores al recibo que provoca la
anulación, cobrados.

Por último, no se anulará la póliza si el importe total de sus recibos es negativo o 0.

Las pólizas con estas características, serán seleccionadas por el filtro, pero se rechazarán en la
ejecución del proceso. Se tratarán como pólizas con error, es decir, el proceso marcará el registro como
“terminación anormal” y grabará un error en la tabla de “pólizas con error en procesos batch” (a2000520)

2.2.2 Pólizas que se tratan

Se tomarán todas aquellas pólizas cargadas identificadas con el código del proceso, que no hayan sido
tratadas.

En la tabla, la columna TIP_SITU nos indica la situación de la póliza dentro del proceso.

TIP_SITU Valor
1 No tratada
2 En proceso
3 Terminación normal
4 Terminación anormal
5 No procesada por excepción
6 Retenida por control técnico

Una vez que la póliza sea seleccionada para ser tratada por el proceso, la situación del registro cambiará
a “en proceso”.

2.2.3 Funcionamiento
Por cada póliza que deba ser tratada, se volverán a comprobar las condiciones que debe cumplir para
ser anulada por este proceso:
■ El recibo que provoca la anulación sigue pendiente

■ No existen recibos posteriores cobrados

■ Las características de la póliza permiten que pueda ser anulada por el sistema

■ El importe total de los recibos de la póliza es positivo

6
ANULACIONES BATCH EMISION
Como se ha indicado anteriormente, el proceso no siempre anulará la póliza, existen casos en que la
deuda se produce a partir de un suplemento y no es necesario anular toda la póliza, sino que debe
anularse el suplemento.

Para determinar esto, en el registro de la tabla se indica el número de suplemento al que pertenece el
recibo vencido. El tipo de anulación depende del tipo de este suplemento.

Se anulará la póliza siempre que el recibo vencido se encuentre en un suplemento de renovación,

rehabilitación o en el suplemento inicial de la póliza. En todos los demás casos se anulará el suplemento.

Esta forma de trabajar no se tendrá en cuenta si en el registro de la póliza se indica que la anulación no
se hará por la deuda, en este caso, siempre se anulará totalmente la póliza.

Tal y como funciona la anulación de suplementos, no es posible anular un suplemento, sin haber anulado
antes los suplementos posteriores a este, es decir, la anulación de suplementos siempre toma el último
suplemento, no anulado, de la póliza.

El proceso Batch, anulará uno a uno, todos los suplementos de la póliza hasta poder anular el
suplemento que indica el registro de la tabla.

Igualmente, no se permite anular una póliza a una fecha anterior a la fecha del último suplemento, a no
ser que se anule antes este suplemento, por ejemplo, no es posible anular una póliza a inicio si existen
suplementos, no anulados, con fecha posterior a la fecha de efecto de la póliza.

En este caso se anularán todos los suplementos posteriores con fecha mayor a la fecha de anulación,
antes de anular la póliza.

Por cada movimiento a anular se ejecutará, internamente, un suplemento batch (TIP_MVTO_BATCH =

4), este tipo de proceso ejecuta los pasos necesarios para el suplemento que se le indique en el código y
sub-código, tratándolo como se hace en el suplemento ON-LINE.

Para la anulación de suplementos se utilizarán los códigos de suplemento que se indican en los
parámetros de la tarea.

Para la anulación de la póliza se utilizará el código de suplemento que se indica en el registro de la tabla
de “pólizas para procesos batch” (a2000500)

La fecha de anulación la determinará el procedimiento que recupera la fecha a la que debe ser anulada
una póliza (em_p_fecha_anulacion), si este procedimiento no devuelve valor, se anulará a partir de la
fecha de efecto del recibo.

Una vez tratada la póliza, se actualizará la situación del registro para indicar si el proceso ha sido
ejecutado satisfactoriamente o si por el contrario se ha detectado algún error, en este caso se graba un
registro en la tabla de “pólizas con error en procesos batch” (a2000520) indicando el mensaje del error y
el riesgo.

7
ANULACIONES BATCH EMISION
3 Anulaciones definidas por la compañía
Como hemos indicado, el sistema solamente contempla anulaciones batch por falta de pago, es posible
crear procesos para incluir anulaciones por cualquier otro criterio que determine cada compañía.

Las anulaciones que se definan deben tener las mismas características que el proceso de anulación por
falta de pago, es decir, se anulará el suplemento o la póliza, dependiendo del tipo de suplemento a partir
del cual se quiere anular.

En caso de querer crear un proceso de anulación para anular pólizas o suplementos, según se indique
en el registro de la tabla, sin que sea el proceso el que determine lo que se va a anular, se deberá crear
como suplemento batch (TIP_MVTO_BATCH = 4)

3.1 Requisitos previos

3.1.1 Definiciones
Como todos los procesos batch, cualquier otro tipo de anulación requiere de las definiciones descritas en
el documento “Procesos Batch”, la diferencia radica en que los datos para los procesos que proporciona
el sistema, siempre pueden ser definidos o ejecutados mediante el programa de “mantenimiento de
tablas generales” (AP299510.inp), mientras que para este tipo de proceso, muchos pasos deben ser
ejecutados por procedimientos externos.

Las definiciones necesarias son las siguientes:

■ Código de proceso

Se debe crear un nuevo código para el dato TIP_MVTO_BATCH en la tabla de “listas de valores de
campos” (g1010031)
Los códigos del 1 al 11 están reservados para los procesos batch del sistema, se podrá tomar cualquier
valor mayor a 11.
■ Identificación del proceso

Es obligatorio crear un registro identificando el proceso en la tabla “maestra de movimientos”

(g2000510), este registro puede ser creado por el programa o en el mismo proceso que seleccione las
pólizas a tratar.
■ Filtro

Se debe crear un proceso para recuperar las pólizas que cumplan las condiciones para ser anuladas.
■ Excepciones

Las excepciones se harán de la misma forma que para el resto de procesos batch.

8
ANULACIONES BATCH EMISION
3.1.2 Filtro
El proceso que seleccione las pólizas a anular debe rellenar siempre, la tabla de “pólizas para procesos
batch” (a2000500), recuperando los datos necesarios del suplemento que se va a tratar.

Se debe rellenar también la tabla “maestra de movimientos” (g2000510) si se va a crear, en el mismo

proceso de filtro, el registro para identificar el proceso.

Características del registro de la tabla g2000510

En esta tabla se deben indicar, de forma obligatoria, el código de proceso, la fecha de tratamiento y un
número de orden, este número indica el orden del proceso dentro de la fecha, se utiliza solamente para
que puedan existir varios procesos con la misma fecha de tratamiento.

El campo TIP_SITU_FILTRO de esta tabla indica la situación en que se encuentra el proceso.

TIP_SITU_FILTRO Valor
1 Sin filtrar
2 Filtrando
3 Ya filtrado
4 Excepcionando
5 Ya excepcionado
6 Ya tratado

Una vez realizada la selección de las pólizas, este campo deber tener valor 3 “ya filtrado”, para indicar
que ya se ha ejecutado el filtro. Si el registro se crea en el mismo proceso, se creará con este valor, si se
crea por el programa de mantenimiento, habrá que actualizar la columna ya que el programa la dejará
con valor 1 “sin filtrar”.

Características del registro de la tabla a2000500

Es obligatorio rellenar los datos que identifican el suplemento a realizar, teniendo en cuenta que
cualquier proceso definido con código mayor a 11 se tratará como una anulación, por tanto, el tipo de
suplemento elegido deberá ser ‘AT’.

Es muy importante indicar el número de suplemento desde el que se quiere anular, ya que, como se ha
visto en el proceso de anulación por falta de pago, por este suplemento se determinará si se anula la
póliza o el suplemento.

La fecha de anulación debe estar indicada en la columna FEC_EFEC_SPTO de esta tabla, teniendo en
cuenta, que al ejecutar el procedimiento que recupera la fecha a la que se anula la póliza
(em_p_fecha_anulacion), esta fecha puede cambiar.

9
ANULACIONES BATCH EMISION
El campo TIP_SITU, como hemos visto anteriormente, se utiliza para saber la situación de la póliza
dentro del proceso. Al cargar las pólizas este campo tendrá, siempre, valor 1 para indicar que el registro
no ha sido tratado.

Recordemos también que los movimientos que se hagan a la póliza quedarán grabados con el usuario
indicado en el campo COD_USR_CAPTURA, en su defecto, se tomará el usuario de base de datos que
ejecute el proceso.

3.1.3 Procedimientos disponibles

Como se indica en el documento “Procesos Batch”, existen procedimientos, en los packages que utiliza
el programa de mantenimiento, para insertar la información de estas tablas. Se recomienda la utilización
de estos procedimientos en el programa que realice el filtro.

3.1.4 Excepciones
Aunque las excepciones se pueden realizar de la misma forma que para el resto de procesos, si se
quisiera realizar procedimientos externos con este fin, estos procedimientos solamente deben dejar, los
registros de las pólizas a excluir marcados, en la tabla de “pólizas para procesos batch” (a2000500),
como “no procesadas por excepción” (TIP_SITU = 5)

3.2 Ejecución del proceso

3.2.1 Pólizas que no pueden ser anuladas

En ningún caso podrán anularse aquellas pólizas o suplementos que no puedan ser anuladas por un
suplemento ON-LINE.

Si no se excluyen estas pólizas en el filtro, se tratarán como se ha indicado en el proceso de anulación

por falta de pago, quedarán marcadas con situación “terminación anormal” y se grabará un registro en la
tabla de “pólizas con error en procesos batch” (a2000520)

3.2.2 Comprobación de las condiciones de la póliza

En el intervalo de tiempo existente entre la ejecución del filtro y la ejecución del proceso de anulación, las
pólizas seleccionadas inicialmente pueden haber sufrido cambios. Estos cambios pueden significar que
ya no sea necesaria la anulación de la póliza, es decir, al cambiar su situación la póliza ya no cumple las
condiciones que requiere el tipo de anulación que se está ejecutando. Si se volviese a ejecutar el filtro,
esta póliza no se seleccionaría.

Por tanto, se hace necesaria la comprobación de las condiciones de las pólizas antes de la ejecución del
proceso. Para ello debe crearse un procedimiento que vuelva a comprobar si las pólizas cargadas siguen
cumpliendo las condiciones para ser anuladas.

Este procedimiento deberá tomar cada póliza, comprobar sus condiciones y si detecta que no debe ser
anulada, tratarla como una excepción, marcando el registro como “no procesado por excepción”
(TIP_SITU = 5), si se quiere dejar constancia del motivo por el que no se anula la póliza, se puede
insertar un registro en la tabla de “pólizas con error en procesos batch” (a2000520)

El procedimiento debe ser ejecutado, inmediatamente antes de cada ejecución del proceso de anulación.

10
ANULACIONES BATCH EMISION
Aunque hemos dicho que si se vuelve a ejecutar el filtro, estas pólizas se excluyen de la selección, no se
recomienda esta opción porque se perderían las pólizas que han sido tratadas previamente, ya que al
estar anuladas tampoco entrarían en la selección del filtro.

3.2.3 Pólizas que se tratan

Igual que cualquier otro proceso batch, tomará de la tabla aquellas pólizas identificadas con el código del
proceso, que no hayan sido tratadas.

Una vez recuperada la póliza, la situación del registro quedará como “en proceso”.

3.2.4 Funcionamiento
Por cada póliza que se tome para tratar se comprobará, únicamente, que el sistema permita la anulación
de la póliza o el suplemento.

La ejecución del nuevo proceso de anulación seguirá los mismos pasos descritos para la anulación por
falta de pago, ejecutándose internamente como un suplemento batch (TIP_MVTO_BATCH = 4) para, de
esta forma, tratar las anulaciones tanto de póliza como de suplementos, como se hace en los
suplementos ON-LINE.

Se utilizará el mismo criterio para determinar si se anula la póliza o el suplemento, recordemos que se
anula la póliza siempre que el número de suplemento, indicado en el registro, sea el suplemento inicial
de la póliza o sea un suplemento de renovación o rehabilitación, en caso contrario se anula el
suplemento.

Se anularán, igualmente, los suplementos posteriores hasta poder anular la póliza o el suplemento que
se indica en el registro.

Si el procedimiento que recupera la fecha a la que debe ser anulada una póliza (em_p_fecha_anulacion)
no devuelve valor, se anulará a partir de la fecha de efecto de suplemento que se indica en el registro de
la tabla de “pólizas para procesos batch” (a2000500)

Igual que para todos los procesos batch, una vez tratada la póliza, se actualizará la situación del registro
y en caso de error se grabará la tabla de “pólizas con error en procesos batch” (a2000520)

11
ANULACIONES BATCH EMISION