Octubre 2019
L M M J V S D
« Abr    
 123456
78910111213
14151617181920
21222324252627
28293031  

Categorías

Nuevo Manual de Nóminas de Vida

Se actualizó el Manual de Nóminas de Vida con los más recientes desarrollos en el área.

Índice del Manual

Lección 15.1. Introducción
Lección 15.2. Interfase de Nómina
Lección 15.3. Configuraciones previas: Plan de Cobertura y Tarifa
Lección 15.4. Configuraciones previas: Certificado Individual de Cobertura
Lección 15.5. Tabla General de Nóminas
Lección 15.6. Cabecera de la Nómina
Lección 15.7.  Importar archivo. Restaurar al estado anterior. Actualizar Nómina. Tabla de Integrantes de la Nómina.
Lección 15.8. Calcular Coberturas. Riesgos y Coberturas del integrante.
Lección 15.9. Requisitos de Suscripción. Validación de Nómina. Requisitos del Integrante. Nómina disponible para emisión.
Lección 15.10. Emisión de Nuevas y Endosos con Nómina. Historial del Integrante. Certificado individual de Cobertura.
Lección 15.11. Reportes de Nóminas
Lección 15.12. Síntesis: Pasos para Trabajar con Nóminas.

1. Introducción

2. Interfaz de Nómina

3. Configuraciones previas: Plan de Cobertura y Tarifa

4. Configuraciones previas: Certificado Individual de Cobertura

5. Tabla General de Nóminas

6. Cabecera de la Nómina

7.  Importar archivo. Restaurar al estado anterior. Actualizar Nómina. Tabla de Integrantes de la Nómina.

8. Calcular Coberturas. Riesgos y Coberturas del integrante.

9. Requisitos de Suscripción. Validación de Nómina. Requisitos del Integrante. Nómina disponible para emisión.

10. Emisión de Nuevas y Endosos con Nómina. Historial del Integrante. Certificado individual de Cobertura.

11. Reportes de Nóminas

12. Síntesis: Pasos para Trabajar con Nóminas.

Acceda al Manual con el siguiente link:

CTSA_GAUSmp_15NóminasVida_003_20120424

Nuevo manual: gestión de talonarios

Nuevo manual del área de Cobranzas: Gestión de Talonarios

CTSA_ManualTalonarios_001_20110107

Nuevo Manual, Canjes

Nuevo Manual del Área de Cobranzas: Cobranzas por Canje

CTSA_GAUSmp_ManualCobranzaCanjes_001_20101210

Preliquidación por Gobierno (2da parte)

Se cambió el sistema para que sea posible hacer una preliquidación para la Casa de Gobierno, a la cual se envía un solo archivo. El retorno de la información viene estructurado de la siguiente forma:

  • Un archivo por las jurisdicciones 01 a 16
  • Un archivo individual por cada una de las jurisdicciones 17 en adelante

En Gaus/400, por ejemplo, la Casa de Gobierno era el “cobrador” 131. Luego, para sus jurisdicciones se utilizó la tabla de “zonas” (de la 01 a la 101).

En GAUSmp, la Casa de Gobierno es una entrada en la tabla de “Grupo de Cobradores para Preliquidación”, y las jurisdicciones, son los “cobradores”.

Administración:

Dar de alta el ítem de menú “Trabajar con Grupo de Cobradores no Productores p/Preliquidación”,

El mismo servirá para dar de alta los grupos (Casa de Gobierno) y subgrupos (luego se comenta) a los que pertenecen los cobradores (antes llamados zonas).

El Grupo es una nueva tabla. No es un dato filiatorio ni es un cobrador.

Al dar de alta el grupo si el parámetro Apertura por SubGrupo=NO, se creará un subgrupo por defecto, llamado Genérico, luego presionando en la lupa se podrán dar de alta los cobradores ligados a ese grupo/subgrupo.

Si el parámetro esta en SI, se podrán dar de alta N subgrupo y para cada subgrupo sus cobradores.

Esto permitirá configurar la metodología de trabajo indicada al comienzo de este release notes. Es decir:

  • Crear cada una de las denominadas “zonas” como un “cobrador”. Es decir crear el dato filiatorio (el sistema le asignará un número correlativo) y ligarle el tipo de proveedor “210-COMISIONES DE COBRANZAS A PAG.”. A diferencia de los cobradores comunes, estos no llevan número interno (porque su número es el mismo número de grupo), pero si llevan número externo. Este número externo, es conocido número de la zona (01 a 101)
  • Crear un grupo de cobradores, por ejemplo 131 llamado Casa de Gobierno, indicando que SI  apertura por subgrupo.
  • Crear el subgrupo 01=Cuerpo Central, y a este ligarle los cobradores ya creados como datos filiatorios con número externo 01 a 16.
  • Crear el subgrupo 17, y a este ligarle solo el cobrador ya creado con número externo 17.
  • Crear el subgrupo 18, y a este ligarle solo el cobrador ya creado con número externo 18.
  • Y así hasta el cobrador con número externo 101.

Tabla de medios de pago:

Crear un nuevo medio de pago llamado “Cobrador Grupal” con el tipo de medio de pago “COBRADOR GRUPAL”, o si ya existe (puede que sea el llamado “5-Convenios”) cambiar el tipo de pago “COBRADOR NO PRODUCTOR” por el tipo “COBRADOR GRUPAL”.

Emisión de operaciones:

En el Tab de “Medios de Pago”, seleccionar el “Cobrador Grupal”, el subgrupo 01 si es para Cuerpo Central o 17 en adelante si es el resto, y finalmente el cobrador (jurisdicción).

Configuración Tipo de Ingreso

Se debe dar de alta el  tipo de ingreso y sus configuraciones necesarias  para poder llevar a cabo las preliquidaciones para convenio de gobierno. Este tipo de ingreso  se llama “Grupo Preliquidación Cobradores no Productores”.

Al dar de alta un ingreso para el tipo antes mencionado, al llegar al tab de preliquidaciones se podrá crear la cabecera de la preliquidación,  se elegirá un grupo y al dar confirmar se crearan tantas cabeceras de preliquidación como subgrupo tenga asociado el grupo seleccionado.

Una vez en la grilla, al presionar el botón Crear Preliquidación, se crearan los pagos que corresponderán a aquellas cuotas de las operaciones que pertenezcan a cada uno de los cobradores que estén en el subgrupo. Luego se podrá exportar el archivo, creando un único archivo con todos los cobradores.

El proceso de importación es a nivel de cada una de los registros de la grilla (subgrupo).

Reservas de presentación

Como se sabe el proceso de Cierre Mensual de Reservas de Siniestros (Proceso HsehSinCieResWW) produce los siguientes efectos:

  • Barre las tablas de Reservas y obtiene el Saldo para cada Reclamo a la fecha de cierre
  • Adicionalmente Actualiza por Índices y Recalcula las Reservas para el caso de Reclamos en Estado Judicial
  • Calcula el recupero estimado de Reaseguro para todos los casos
  • Guarda el estado de las tablas al momento del cierre y emite 19 reportes con el contenido de las mismas

Hasta aquí el proceso normal contenido en GAUSmp

No obstante algunos usuarios no mantienen las reservas durante el trimestre sino que trabajan en la actualización luego del cierre del mismo.

Para este tipo de usuarios es que se ha habilitado el siguiente proceso, el cual básicamente permite modificar el lote de reservas una vez cerrado y volver a generar los reportes tantas veces como sea necesario hasta obtener los resultados deseados.

Las medidas de seguridad que se han dispuesto en tal sentido son las siguientes

  • Solo puede modificar reservas los usuarios específicamente habilitados
  • Solo se pueden modificar reservas del último lote
  • Cuando al menos una reserva se modifica se cambia el estado del lote, obligando a que se emitan nuevamente los reportes a efectos que los mismos coincidan con el estado de las tablas
  • Se genera la correspondiente trazabilidad para indicar los “valores anteriores” de las reservas modificadas por este método
  • Las modificaciones realizadas de esta manera solo tienen vigencia para este lote  o sea las reservas de presentación, pero no afectan las reservas reales de la empresa

Restricciones

Para el caso de las reservas en gestión Judicial, SOLO se modifica el Saldo Final de la Reserva de modo que dicho valor no se corresponderá con el que surgiría de la aplicación del procedimiento específicamente indicado por la SSN

Como tal el usuario que utilice este procedimiento para cambiar el valor de una Reserva de Juicio o Mediación, estará expuesto  al mencionado Riesgo.

Convenios de Siniestros

Generar el “instrumento” Convenio, que se firma entre la compañía y uno o más reclamantes para la cancelación de los efectos del siniestro

Generar Plantillas

El convenio se basa en una plantilla que debe llevar un equivalente específico

Generar la plantilla colocando las variables de reemplazo que se deseen, son válidas todas las disponibles, excepto las correspondientes a Liquidaciones de siniestros

Como se recuerda para generar plantillas el camino es el siguiente Trabajar con Ramas >> Selecciona la Rama >> Plantillas de siniestros

Generar el convenio

Desde el TAB correspondiente accionar el botón para crear un convenio

Loa datos que requiere un convenio son los siguientes

  • Moneda e importe Total
  • Fecha de celebración
  • Título o Descripción
  • Plantilla en la que se basa
  • Importe por cada Reclamante
  • Una descripción breve y una descripción ampliada por cada reclamante (Opcional)

Una vez que están completados los datos, se acciona el botón para generar el covenio, el cual ejecuta el programa que produce el efectivo reemplazo de las variables

Aprobación de un Convenio

Para poder imprimirse un convenio debe estar aprobado

para ello se lo envía a cualesquiera de las Bandejas de Siniestros que atiendan el servicio “Siniestros Otros Sectores”

Desde esta bandeja se aprobará o se reclazará el convenio, dejandose contancia de las acciones tomadas el Historial de la tarea.

 Acciones posteriores

Un convenio “aprobado” puede visualizarse a través de la “vista previa” y eventualmente imprirse

Un convenio rechazado solo se puede consultar, pero no se permite la impresión

Deducción de saldo de pólizas pendientes

Deducir automáticamente el saldo pendiente de la póliza, en caso de Pago Directo al Asegurado de la indemnización de un Siniestro 

 

Configuración de Hechos Generadores

Si bien la decisión de deducir o no el Saldo pendiente de una Póliza es un hecho que exige la confirmación por parte de un usuario habilitado, se puede configurar en GAUSmp el comportamiento “sugerido” para cada uno de los hechos generadores.

En la tabla de Hechos generadores por lo tanto se agregó el atributo:

Siniestro Consume Saldo de Póliza? El cual deberá configurarse en SI cuando como consecuencia del siniestro se produzca la cesación del Riesgo de la póliza y en NO en los demás casos

Este atributo luego se exibe en la Bandeja de Cobranza, que atiende la Cobertura financiera de Siniestros, ya que es en dicho lugar donde debe tomarse la decisión correspondiente

Valores por Defecto

Toda vez que se carga un siniestro los valores relativos a la deducción del saldo pendiente se inizializan en forma negativa, o sea NO Deducir Saldo pendiente.

Bandeja de Cobertura Financiera de Siniestros

Cuando se carga un siniestro puede darse dos situaciones

  • Que esté configurado como que “automáticamente” se solicita cobertura financiera, en cuyo caso, en el mismo momento de carga se enviará la solicitud a la bandeja que atiende el citado servicio
  • Que no esté configurado en forma automática, con lo cual será el usuario que carga el siniestro el que tendrá la obligación de enviar el mismo a la bandeja de cobertura financiera a efectos que indenque el camino a seguir

Opciones en la Bandeja de Cobertura Financiera

En la bandeja de cobertura financiera se presenta la siguiente pantalla

imagen 1

Es decir que cuando se contesta la cobertura financiera, adicionalmente se debe indicar si:

  • Se deducirá o no el saldo de la póliza en el momento del pago directo al asegurado
  • En caso que se trate de una póliza flota el “porcetanje a deducir”, que no podrá ser el 100% del valor facturado

Adiconalmente el sistema  controlará (solo para el caso de operaciones que se refacturen) si está totalmente facturado el premio de la operación, ya que en caso que esto no sea así se deberá gestionar primero que se emitan las facturaciones faltantes antes de poder formalizar la deducción.

La información acerca de las acciones a seguir se registran dentro de la trazabilidad del siniestro, para que quede constancia de la decisión tomada por el sector de cobranzas.

Aplicación de la cobranza

Cuando se genera una cuenta a pagar, mediante una liquidación que sea de indemnización y de pago directo al asegurado, al pasar por el TAB de Débitos y Créditos varios se presentará la opción de “deducir el saldo de la póliza” siempre que:

  • Esté la orden dada por el Sector Cobranza
  • La operación tenga saldo pendiente

En caso que se produzcan inconvenientes por la existencia de una configuración defectusa que impida generar automáticamente el ingreso de valores y la aplicación de la cobranza se dará la opción de generar igualmente la cuenta a pagar, dejando debida constancia en la trazabilidad de la orden de pago

La pantalla para realizar la deducción efectiva es la siguiente

Puede darse la situación (como en este caso) que la operación tiene un saldo pendiente de $ 5780.- y la cuenta a pagar sea solo de $ 4500.-

Si se accione el botón del “dinero” para que se genere automáticamente la cobranza el resultado será el siguiente:

imagen 2

GAUSmp generó automáticamente un Ingreso de Valores y una aplicación de cobranza, aplicando a la operación, hasta la concurrencia de la cuenta a pagar (o sea solo 4500.-), imputando debitando dicha cobranza a la cuenta Documentos a Cobrar, que luego incluye dentro de los “Debitos y Créditos Varios” de la Orden de pago.

En este caso en particular, no queda Saldo a Pagar, generándose una Cuenta a Pagar automáiticamente cancelada.

No obstante el caso habitual es que se tome el total del saldo pendiente y la cuenta a pagar se genere por la diferencia.

Atención

El ingreso de valores no queda “transaccionalmente” vinculado a la cuenta a pagar de modo que en caso que la cuenta a pagar se anule, se deberá anular manualmente también la aplicación de la cobranza

Ordenes de pago a futuro

Cada vez que se da de alta una Cuenta a Pagar se ingresa la fecha de pago, la misma por defecto viene cargada con la fecha que esta configurada en la empresa, la misma puede ser modifcada a futuro, si se modifica se graba una excepción que sera visualizada en el Tab de Condiciones de Pago.

La nueva fecha puede ser mayor pero NO menor a la fecha propuesta por el sistema.

El libro contable debe estar abierto para el mes y año de la fecha de pago.

La cuotas se deben generar de acuerdo a la fecha ingresada.

Cada vez que se anula una Cuenta a Pagar, la fecha de anulacion sera:

Se compara la fecha obtenida en la empresa con la fecha de la cuenta a pagar, si la fecha obtenida es mayor que la fecha de la cuenta a pagar, mantener la fecha obtenida (quiere decir que la cuenta a pagar NO es “a futuro”) , si la fecha obtenida es menor que la fecha de la cuenta a pagar, entonces  la fecha de anulación sera la fecha de la cuenta a pagar. En este caso la fecha de anulación es igual a la fecha de la cuenta a pagar.

 Cada vez que se cancela una Cuenta a Pagar, en el lote NO se  incluiran aquellas CAPs   cuya fecha  sea mayor que la fecha del lote.

Componente Financiero de Siniestros (Intereses Implicitos)

Con las modificaciones introducidas en las ultimas versiones de GAUSmp (incluyendo la actual) se ha ampliado notablemente el concepto de Pago de un Siniestro.

Se detalla a continuación todas las alternativas posibles para pagar un siniestro y la relación de cada una de ellas con el concepto de componente financiero

 

imagen 1

Activación

Para activar el tratamiento del componente financiero en siniestros, seguir los siguiente pasos

  • Cargar la TASA que se vaya a utilizar en la tabla de Indices, esto es que habrá un valor de TASA por cada Mes y Año
  • La tasa debe cargarse en PORCENTAJE ANUAL
  • Vincular dicha TASA con la Rama de seguros donde se desee aplicar el tratamento de componente financiero, a través de la tabla de Configuración de Siniestros para la Rama

 Formula y monento en se aplica

  • El componente financiero se aplica en el momento en que se CONFIRMA la liquidación, esto es cuando se arranca la generación de la cuenta a pagar
  • para el cálculo se aplica la siguiente fórmula 
 Valor Actual del pago = Importe pagado / (1 + i * n)

Componente Financiero = Importe Pagado – Valor Actual del Pago

 

Donde:

i = Tasa Anual / 100 * 365 => Tasa diaria expresada en “tanto por uno”

n = Cantidad de días transcurridos entre la fecha de pago y la fecha de ocurrencia del siniestro

 

Otros Pagos de Siniestros (Pagos contra Reservas)

From release v08r07m0009

Se ha implementado la funcionalidad de vincular Ordenes de Pago administrativas a Siniestros, a través de la utlización del sistema de “Pagos contra Reservas” que en lo sucesivo denominaremos como “Otros Pagos de Siniestros”

 Generación de un Cupo de Pagos

Para implementar esta metodología lo primero es configurar “cupos” de pagos, los que básicamente se componen de un “importe total a gastar” y una imputación contable.

El diseño de la mencionada tabla es el siguiente

imagen 1
En el ejemplo se observa un cupo de $ 3.000.000.- que se contabilizará en la cuenta “Gastos de Publicidad”

No se han indicado Distribuidores de Costos, pero podría hacerse

Las relaciones entre la cuenta contable y los distribuidores de costo son las generales de modo que dirigirse la la documentación correspondiente en caso de dudas con respecto a dicho item.

Un cupo se “bloquea” automáticamente una vez que se consume, pero en caso que se desee dejar de utlizar podrá bloquearse  manualmente

 Creación de Pagos contra los cupos

Los pagos que pueden aplicarse contra cupos están sometidos a las siguientes normas

  • Deben cumplimentar los muismos requisitos formales que cualquier pago de indemnización que se realiza por GAUSmp, con la sola excepción que no es necesario que exista “saldo de reserva de siniestros pendientes”
  • Por el contrario si debe existir una cabecera de Reserva asignada a un Riesgo y Cobertura
  • En caso que se desee pagar Gastos, también podrá hacerse en tanto y cuanto exista una cabecera de Reservas habilitada.

 Trabajar con Pagos contra Cupos

Los pagos “contra cupos” u “otros pagos” se ubican en el Trabajar con Reclamos, ya que -como se indicó anteriormente- los requisitos formales son los mismos que para realizar un pago de indemnización

la siguiente grilla se utiliza para trabajar con “otros pagos”

imagen 2
En nuestro ejemplo ambos pagos tienen vinculada una cuenta a pagar de modo que no es posible eliminar los mismos

En caso de “error” se deberá desvincular la cuenta a pagar y anular la misma utlizando el Módulo de Egresos.

Dado que dicha funcionalidad ya existe, no es razonable repetirla en este punto

En esa situación es posible eliminar el pago y realizar uno nuevo por el importe correcto

Nota

La Fecha del pago se toma “provisoriamente” cuando se crea el mismo (que sería el “simil” a generar una liquidación), pero la fecha real se “sobreescribe” cuando se concreta la Cuenta a Pagar, ya que es este módulo el único habilitado para fijar fechas “ciertas” con trascendencia contable.

Estado del pago contra reservas

Des de la consulta consolidada de pagos el comportamiento de estos items es el siguiente

  • Si no existe la cuenta a pagar o existe, pero NO está confirmada (sin asiento generado), No se considera Pago sino solo Liquidación
  • Si existe la cuenta a pagar y tiene el asiento generado, entonces se expone como pago real

 Generación de la cuenta a pagar

Es similar al ciclo de toda cuenta a pagar, en la que se autogenera la cabecera y el concepto

El usuario tiene que confirmar las demás pantallas para que se realicen los cálculos específicos a cada una de ellas (Impuestos, retenciones, etc.)

 Consulta consolidades de Pagos

La generación de esta nueva forma de pagar sinistros hizo necesario contar con una “consulta consolidada” que exponga en una única pantalla las distintas formas por las que un siniestro puede recibir pagos, los que existen en el sistema dispersos en cada uno de los módulos que les dan origen

 Lista de formas de pago

GAUSmp admite actualmente los siguientes estados de pagos para un siniestro

imagen 3

Relaciones

El código STO_3RO solo admite pago, ya que antes de cargar la factura del proveedor se muestra como OCP_3RO o sea como Orden de Compra, pendiente de aplicación de factura

Es por eso que el STO_3RO no tiene estado “en proceso” y el OCP_3RO no tiene estado “pagado”

El código OCP_DIR > Ordenes de compra para pagos directos, cuando se liquida se convierte en un código STO_IND, no obstante NO todos los STO_IND se originan en Ordenes de Compra, ya que en dicho código se registran tamibén los Pagos “indemnizatorios” que no llevan circuito de Nota de Pedido

Formato de consulta

El formato de la nueva consulta consolidada es el siguiente:

imagen 4

La colúmna “Pago”, la ícono verde indica que es un pago realmente realizado (contabilidado o no según sea directo o de Liquidadores de terceros)

En cambio el ícono amarillo indica que es un pago “en proceso” que puede estar basado en una Liquidación de Siniestros, en una Orden de Compra aún no liquidada o en un Pago contra Reserva para el cual no se cargó aún la Cuenta a Pagar