El proceso tiene como objetivo principal automatizar el envío preventivo de notificaciones por correo electrónico a clientes y proveedores cuyos certificados de exención de retenciones estén próximos a caducar. La finalidad de esta herramienta es solicitar al tercero la renovación oportuna de la documentación para mantener los beneficios de alícuotas reducidas (típicamente del 0.00%) en sus próximas operaciones. Al garantizar la recepción del nuevo certificado a tiempo, la empresa evita aplicar retenciones indebidas en los pagos o cobros.
Adicionalmente, la implementación de este flujo elimina la necesidad de que los analistas del departamento de Impuestos realicen revisiones manuales semanales sobre los informes y padrones de retenciones, mitigando el margen de error humano y optimizando los tiempos del área contable. Es importante destacar que el proceso se limita estrictamente a la alerta preventiva y no incluye la recepción o actualización automática de los nuevos archivos PDF dentro del sistema.
Requisitos Previos y Configuraciones en el Sistema
Para que el motor de reglas (BModeler) ejecute de manera exitosa el análisis y despacho de los recordatorios, el administrador del sistema debe garantizar que las siguientes parametrizaciones base se encuentren configuradas:
1. Habilitación de Permisos de Acceso: Para que los usuarios puedan visualizar y operar el menú de procesos, es imperativo habilitar la prestación correspondiente. El administrador debe dirigirse a la vista de “Prestaciones”, buscar la aplicación “APP BUILDER” y seleccionar el registro “BMODELER-PROCESOS”. Posteriormente, se debe acceder a la ventana de “Definición de Permisos” y marcar la casilla de la columna “Accede” para el rol o equipo de trabajo deseado, como por ejemplo “Administración de Cajas” o “Administración y Finanzas”.
ATENCIÓN: Tras guardar la asignación de permisos, es estrictamente obligatorio que el usuario cierre su sesión activa y vuelva a ingresar al sistema (Log out / Log in). De omitir este paso, el módulo “BModeler - Procesos” no se reflejará en el panel lateral de navegación izquierdo.
2. Configuración del Servidor de Correo Saliente (SMTP): El sistema ERP debe contar con una cuenta de correo electrónico saliente correctamente configurada y testeada. Esta configuración es el motor de comunicación; sin una cuenta SMTP válida, el programador de tareas fallará al intentar despachar las alertas a las casillas de los proveedores y clientes.
3. Creación de Grupos de Difusión: Se requiere la creación de un “Grupo de Difusión” (por ejemplo, bajo el código y nombre “Avisos Impositivos”) donde se colocarán tanto contactos de clientes/proveedores a notificar como usuarios internos de la empresa que serán los encargados de recibir los certificados impositivos. La correcta configuración de este grupo tiene un doble propósito operativo fundamental:
- Para los Terceros (Destinatarios Externos): Permite unificar y dirigir el envío únicamente a los contactos idóneos. Al asignar el contacto de Cobranzas o Impuestos de un proveedor a este Grupo de Difusión, el sistema sabrá exactamente a qué casilla enviar el requerimiento, evitando notificar a áreas irrelevantes del proveedor.
- Para los Usuarios Internos (Receptores de Renovaciones): Es estrictamente obligatorio vincular a este mismo grupo a los usuarios internos de la empresa emisora (por ejemplo, los analistas de impuestos). El motor automatizado filtra a estos usuarios internos y utiliza sus direcciones de correo para poblar dinámicamente la variable
{{Emails_Contacto_Interno}}dentro del cuerpo del mensaje.
ATENCIÓN: El sistema envía los correos desde una casilla genérica saliente y solicita al proveedor no responder a ese remitente. La única forma de que el proveedor sepa a quién debe enviar el nuevo certificado PDF es leyendo las casillas de los usuarios internos listadas en el cuerpo del correo. Si no se configuran usuarios internos en el Grupo de Difusión, el correo se enviará con una instrucción incompleta.
4. Parametrización del Maestro de Empresas (Agente de Retención): Para que el sistema despache un correo exigiendo un certificado a nombre de una empresa emisora en particular, esta debe poseer dicho impuesto configurado en la solapa “Contabilidad e Impuestos” de su maestro de Empresas. Además, es un requisito excluyente que el impuesto tenga una cuenta contable asignada en el campo “Emisión”. El motivo de esta validación es lógico: si el campo de emisión está vacío, el sistema asume que la empresa no actúa como agente de retención para ese tributo en particular y, por ende, omitirá solicitar el certificado para dicha sociedad.
5. Configurar Bproc " Envío de recordatorio de Certificados Impositivos": Para evitar que el usuario deba modificar el código duro del diagrama BPMN ante cada cambio de normativa o proceso, se utiliza una entidad de configuración denominada “BProc”. Esta actúa como una carátula o panel de control donde el administrador define las variables exactas con las que correrá el proceso automatizado. Se debe activar el Bproc “Envío de recordatorio de Certificados Impositivos” y completar los siguientes parámetros (desde el ícono de “engranaje” 
) :
| Parámetro a Configurar | Tipo de Campo | Explicación Operativa y Ejemplos de Uso |
|---|---|---|
| Grupo de Difusión por Defecto | Selector o Alfanumérico | Define el grupo que el sistema buscará en el perfil del cliente para notificar. Ejemplo numérico/texto: Ingresar “Avisos Impositivos”. |
| Retenciones a Excluir | Alfanumérico | Permite ingresar los códigos de aquellos impuestos que no requieren renovación de exenciones, excluyéndolos del rastreo. Para ignorar múltiples conceptos, deben separarse por punto y coma (;). Ejemplo: “IVA - Argentina; SUSS”. |
| Días de Anticipación | Numérico | Fija la ventana temporal previa al vencimiento para disparar la alerta (valor estándar: 30). Ejemplo cotidiano: Si un certificado caduca el 31 de mayo, y este parámetro está en “30”, el sistema lo detectará y enviará el correo a partir del 1 de mayo. |
6. Activación del Scheduler: Finalmente, el Bproc mencionado en el punto anterior debe encontrarse activo y en ejecución. La tarea encargada de gatillar este proceso evaluará los padrones con una frecuencia semanal fija, ejecutando la barrida de información todos los días lunes a las 8:00 a.m.. Dicha ejecución es configurable.
Flujo Operativo
1. Inicio del Proceso
El flujo operativo inicia de manera automática mediante un evento de tiempo gestionado por el Bproc. La configuración predeterminada estipula que el sistema despierte y ejecute este barrido de información todos los días lunes a las 8:00 a.m.. El propósito de este horario es garantizar que los analistas de impuestos cuenten con las notificaciones enviadas a primera hora de la semana laboral.
2. Extracción y Validación de Exenciones
Una vez iniciado, el sistema ejecuta una consulta a la base de datos leyendo la información contenida en el informe de “Admin. de retenciones y percepciones por contribuyentes”. Para que una exención sea considerada como “próxima a vencer” y pase a la etapa de notificación, el registro debe cumplir estrictamente con cinco condiciones simultáneas.
A continuación, se detallan las validaciones lógicas que aplica el motor para evitar enviar correos erróneos:
| Condición de Validación | Campo en el Sistema | Explicación Operativa |
|---|---|---|
| Origen de la Exención | Check “Manual” = Activo | El sistema solo evalúa registros cargados como “Excepción manual”. |
| Beneficio Total | “Alícuota” o “Porcentaje” = 0.00 | Se busca exclusivamente el beneficio total. Un registro con alícuota de 1.50% será ignorado. |
| Impuestos Permitidos | “Tipo de Retención” | El código del impuesto no debe figurar en la lista de “Retenciones a Excluir” del BProc. |
| Ventana de Vencimiento | “Fecha Hasta” | La fecha de caducidad debe ser menor o igual a la suma de la [Fecha Actual] + [Días de Preaviso]. Ejemplo: Si faltan 20 días para el vencimiento y el parámetro es 30, el registro es capturado. |
| Anti-Renovación (Falsos Positivos) | Múltiples Campos | El sistema busca si ya existe un registro más nuevo para ese CUIT e impuesto. Si halla una fecha de vigencia posterior, aborta la alerta asumiendo que el tercero ya entregó la renovación. |
ATENCIÓN: El sistema requiere datos precisos para realizar cálculos matemáticos. Si un registro en el padrón de retenciones posee el campo “Fecha Hasta” vacío (Nulo) debido a una migración defectuosa o error de carga manual, el sistema omitirá dicho registro automáticamente para evitar un fallo crítico en la ejecución.
3. Agrupamiento y Privatización Para no saturar la casilla del cliente o proveedor, el sistema agrupa los registros encontrados utilizando una clave compuesta por la [Empresa Emisora] + [CUIT del Tercero]. Si un proveedor tiene tres certificados por vencer para la misma empresa, recibirá un único correo consolidado.
En este punto, el sistema evalúa el ámbito del tercero:
- Si el proveedor es “Público”, se procesará para todas las empresas que retengan ese impuesto.
- Si el proveedor es “Privado”, solo se enviará el correo a nombre de las empresas donde dicho maestro esté habilitado.
Además, valida que la Empresa emisora tenga parametrizada una cuenta contable de “Emisión” para ese impuesto. Si carece de esta cuenta, el sistema asume que la empresa no actúa como agente de retención y omite el envío.
4. Resolución del Destinatario
Para definir a qué dirección de correo electrónico enviar la alerta, el sistema ejecuta una lógica de búsqueda en cascada o “Fallback” con tres niveles de prioridad:
- Prioridad 1 (Grupo de Difusión): El sistema busca el CUIT en el grupo de difusión configurado (Ej: “Avisos Impositivos”). Si el cliente tiene contactos asignados a este grupo, se enviará el correo a esas direcciones.
- Prioridad 2 (Contacto Principal): Si el cliente no posee contactos en el grupo de difusión, el sistema buscará en el campo general “Email” ubicado en la cabecera del maestro del tercero. Si este campo contiene varios correos separados por comas o punto y coma, el sistema limpiará el texto y enviará el aviso a todas las direcciones válidas encontradas.
- Prioridad 3 (Sin Contacto): Si el proveedor carece de correos en ambas instancias, el sistema omite el envío, registra el caso como una advertencia en la bitácora interna, y continúa con el siguiente proveedor sin detener el proceso general.
5. Despacho del Correo Electrónico
Finalmente, el sistema ensambla el correo utilizando una plantilla HTML predefinida. El asunto incluirá el nombre de la empresa emisora para facilitar la identificación por parte del proveedor. En el cuerpo del correo, se insertará una tabla detallando el Nombre de la Retención, el Concepto y la Fecha de Vencimiento.
Adicionalmente, el sistema incluirá en el texto los correos de los usuarios internos (ej. analistas de impuestos) mapeados en el mismo Grupo de Difusión, solicitando al proveedor que envíe la nueva documentación comunicándose a dichas casillas internas.
Finalización del Flujo
Una vez que el sistema completa la iteración y el envío de todos los correos electrónicos correspondientes a la barrida semanal, el flujo de BModeler alcanza su evento de fin y concluye de manera automática en segundo plano. El cierre del proceso no requiere ningún tipo de validación, confirmación o intervención manual por parte de los analistas de impuestos o administradores.
Interacciones Externas y Límites del Alcance
Es fundamental comprender las fronteras operativas de esta herramienta. El proceso interactúa hacia el exterior ensamblando correos mediante plantillas HTML que mapean variables dinámicas (como el nombre de la empresa y la fecha de vencimiento) y consolidando múltiples casillas de destino en caso de que el cliente posea varios correos separados por comas. Sin embargo, el retorno de esa comunicación queda fuera del circuito.
Alcance: El alcance de este proceso se limita estrictamente a la emisión de la alerta preventiva. El sistema no realiza la recepción, el procesamiento, ni la importación de los archivos PDF adjuntos que devuelvan los proveedores o clientes en respuesta a la notificación. Asimismo, el motor automatizado no ejecuta la actualización de las fechas de vigencia ni crea nuevos registros por sí solo en la vista de “Admin. de retenciones y percepciones por contribuyentes”. La carga de la renovación continuará siendo una tarea manual o dependerá de una fase futura de integración externa.
Impacto Contable y Operativo La ejecución de este proceso automático no genera asientos contables, ni comprobantes, ni produce alteraciones directas en los saldos del sistema. Su impacto es netamente procedimental y preventivo. Al disparar la alerta con una ventana temporal de holgura (cuyo parámetro estándar es de 30 días de anticipación), otorga el tiempo necesario para que el tercero provea la documentación. El objetivo definitivo de esta gestión es mantener el beneficio de las alícuotas de retención reducidas al 0.00% en las cuentas corrientes, evitando aplicar quitas monetarias indebidas en los próximos pagos o cobros.
Casos de uso y buenas prácticas
La siguiente matriz detalla los problemas operativos comunes, la razón técnica detrás de los mismos y los pasos exactos para su corrección.
| Escenario de Error / Síntoma | Explicación del Comportamiento (Por qué) | Procedimiento de Resolución (Paso a paso) |
|---|---|---|
| El sistema no notifica un certificado próximo a vencer (Falso Positivo). | El motor posee reglas estrictas para evitar enviar correos innecesarios al cliente. Si el sistema detecta que ya existe un registro más nuevo para ese mismo CUIT e impuesto (con fecha de vigencia posterior), asume que la renovación ya ocurrió y aborta la alerta. También omitirá el envío si la alícuota cargada es mayor a 0.00% (ej. 1.50%) o si el impuesto está en la lista de exclusiones del BProc. | 1. Ingresar a “Admin. de retenciones y percepciones”. 2. Filtrar por el CUIT del tercero. 3. Verificar si existe un registro duplicado o renovado con fechas superpuestas. 4. Confirmar que el registro por vencer tenga el origen “Excepción Manual” y su alícuota sea exactamente 0.00%. |
| El log de ejecución registra el error: “Se produjo un error al enviar mail pidiendo certificado…”. | Este mensaje evidencia un fallo técnico y crítico en la comunicación saliente. El motivo principal es que la cuenta del servidor de correos (SMTP) del sistema se encuentra desconfigurada, o bien la casilla de destino contiene errores tipográficos severos. | 1. Contactar al administrador del sistema para validar las credenciales de la cuenta SMTP configurada. 2. Revisar la ficha del cliente/proveedor y confirmar que el correo no posea espacios en blanco o caracteres inválidos. |
| El log de ejecución omite el envío para un tercero registrando una advertencia (Destinatario IS NULL). | La lógica de búsqueda en cascada no encontró ninguna dirección de correo válida para despachar la alerta. El tercero no está asignado al Grupo de Difusión y tampoco posee un correo cargado en el campo principal de su maestro. Para evitar que el proceso colapse, el sistema ignora al proveedor y continúa con el siguiente. | 1. Ingresar al maestro del Cliente/Proveedor afectado. 2. Navegar a sus datos de contacto. 3. Cargar una dirección válida en el campo “Email” general, o preferentemente, asignar el contacto al Grupo de Difusión configurado en el BProc (ej. “Avisos Impositivos”). |
| El reporte histórico ignora registros con fecha de caducidad en blanco. | Para calcular la ventana de días de preaviso, el sistema realiza cálculos matemáticos (Fecha Actual + Días configurados). Si un registro histórico o mal migrado tiene el campo “Fecha Hasta” vacío, la fórmula matemática falla. Por seguridad, el sistema excluye automáticamente estos registros. | 1. Filtrar en el padrón de retenciones aquellos registros que posean la “Fecha Hasta” nula. 2. Actualizar los registros colocando una fecha de fin válida o marcarlos como inactivos, manteniendo así la higiene de la base de datos. |
| Una empresa no envía reclamos de certificados para un impuesto específico. | Para que el correo se dispare a nombre de una empresa particular, esta debe validar que actúa como agente de retención. Si la solapa de impuestos de la empresa carece de una cuenta contable en el campo “Emisión” para ese tributo, el sistema asume que no le corresponde reclamarlo y omite el envío. | 1. Acceder al maestro de la Empresa emisora. 2. Ir a la solapa “Contabilidad e Impuestos”. 3. Asignar la cuenta contable pertinente en el campo “Emisión” para el impuesto que se desea comenzar a reclamar. |
Buenas Prácticas de Uso y Mantenimiento
Para maximizar la eficiencia del proceso de recordatorios y minimizar el soporte operativo, se sugiere adoptar las siguientes metodologías de trabajo en el área de Administración y Finanzas:
Mantenimiento del Grupo de Difusión
Es altamente recomendable centralizar todos los envíos a través del Grupo de Difusión (por ejemplo, “Avisos Impositivos”) y evitar depender del campo de correo electrónico genérico del maestro del proveedor. Al utilizar el grupo, se garantiza que el requerimiento impositivo llegue directamente al departamento contable del tercero, en lugar de impactar en las casillas generales de ventas o logística.
Carga Estructurada de Múltiples Correos
El sistema está preparado para procesar y limpiar múltiples direcciones de correo cargadas en un mismo campo de texto. Si un cliente requiere que la alerta se envíe a más de un analista de su empresa simultáneamente, se deben ingresar todas las casillas separadas únicamente por comas (,) o puntos y comas (;). Ejemplo numérico/texto correcto: impuestos@proveedora.com; contaduria@proveedora.com .
ATENCIÓN: Evitar el uso de conectores textuales (como la letra “y”, guiones o barras) para separar direcciones, ya que esto invalidará la cadena de texto y provocará que el correo no se envíe.
Auditoría Semanal de la Bitácora (Logs) Dado que el proceso se ejecuta automáticamente (típicamente los días lunes a primera hora), es una excelente práctica operativa que un usuario del área de Impuestos revise la bitácora de ejecución al inicio de la semana. Esta revisión rápida permite identificar proveedores que no fueron notificados por falta de datos e instigar la corrección inmediata en los datos maestros del sistema antes del próximo ciclo de ejecución.