Bproc "Agregar retenciones IIBB en Clientes y Proveedores": Automatizar la carga de Jurisdicciones y Retenciones

Carolina_Benitez · 9 Enero, 2026 12:52

Propósito del proceso dentro del negocio

El alta de nuevas entidades comerciales (clientes y proveedores) requiere la configuración precisa de sus datos impositivos para operar legalmente. Tradicionalmente, la asignación de las jurisdicciones de Ingresos Brutos (IIBB) y los tipos de retención o percepción asociados era un procedimiento manual. Esta carga manual no solo consume tiempo operativo valioso, sino que expone a la organización a errores humanos u omisiones que pueden resultar en inconsistencias fiscales o multas durante la facturación y los pagos.

Para resolver esta problemática, el sistema cuenta con el proceso automático (BProc) denominado “Agregar retenciones IIBB en Clientes y Proveedores”. El objetivo de esta automatización es garantizar que, en el instante exacto en que se crea un nuevo cliente o proveedor, el sistema le herede automáticamente la configuración fiscal correcta (jurisdicciones y tipos de retención/percepción) que ya se encuentra definida de forma centralizada en el Maestro de Empresas.

Esta asignación inteligente contempla dos escenarios empresariales cotidianos:

Entidades Privadas: Si la entidad se da de alta de forma exclusiva para una unidad de negocio (compartición “Privada”), el sistema solo asigna los impuestos de la empresa en la que el usuario está trabajando actualmente.* Entidades Públicas: Si la entidad se configura como “Pública” (compartida por todas las empresas del grupo económico), el sistema recorre todas las empresas activas, unifica las jurisdicciones y tipos de retención, y consolida la información en el cliente o proveedor sin duplicar datos. Esto evita que el usuario deba ingresar a cada empresa individualmente para actualizar la ficha fiscal.

Requisitos previos en el sistema

Para que el proceso automatizado opere correctamente al momento de dar de alta a un sujeto, es mandatorio que el sistema cuente con las siguientes configuraciones previas.

ATENCIÓN: El proceso automatizado de asignación fiscal solo se ejecutará si la localización de la empresa es “Argentina” . En cualquier otro caso, el sistema finalizará el proceso sin realizar acciones.

Tabla 1. Configuraciones de Datos Maestros y Entorno

Componente	Requisito Operativo	Justificación (Para qué)

Maestro de Empresas	Tener configuradas al menos dos Jurisdicciones IIBB activas (Ejemplo: CABA, Buenos Aires) en la solapa de Contabilidad e Impuestos, apartado “Jurisdicciones Impositivas”.	El sistema utiliza esta configuración como “molde” para replicar las jurisdicciones correspondientes a la nueva entidad.
Tipos de Retención	En la empresa, configurar los Tipos de Retención/Percepción del motor Argentina con “Modo Múltiple” (nuevo motor de IIBB, Ganancias o IVA)	Permite al sistema identificar qué impuestos específicos (Retención para proveedores; Percepción para clientes) deben asignarse automáticamente.
Permisos de Usuario	El usuario debe contar con un rol que le otorgue permisos explícitos para “Crear Clientes y Proveedores”.	Es el evento de creación ejecutado por el usuario el que dispara el webhook automatizado.
Diccionario de Datos	Definir correctamente el nivel de compartición (Tipo de Alta) de los registros: “Público” (Global) o “Privado” (Por Empresa).	Determina si el sistema buscará datos impositivos solo en la empresa logueada o si consolidará la información de todo el grupo económico.

Por su parte, se debe activar y configurar el Bproc “Agregar retenciones IIBB en Clientes y Proveedores”:

Cabe recordar que el Bproc se activa y configura desde el ícono de engranaje ()

Configuración de Parámetros del BProc: El BProc debe figurar como Activo. Además, requiere un parámetro numérico obligatorio llamado Situación IIBB default .

Este parámetro define qué código de situación frente a Ingresos Brutos se asignará por defecto a las nuevas jurisdicciones creadas en la ficha. Se utiliza un widget numérico donde los valores de referencia son:

0 = Local
1 = Convenio Multilateral (CM)
2 = Exento
3 = No Inscripto
4 = Régimen Simplificado

Ejemplo práctico: Si el Administrador del Sistema define el valor 3 en este parámetro, el sistema asumirá que, de forma predeterminada, la mayoría de las nuevas entidades son “No Inscriptos” en IIBB, agilizando la puesta en marcha inicial.

ATENCIÓN: El sistema está diseñado para proteger la base de datos de configuraciones erróneas. Si al momento de crear la entidad, el usuario le asigna una Categoría Fiscal que no tributa Ingresos Brutos (Ejemplos: Consumidor Final, Cliente/Proveedor del Exterior, IVA no Alcanzado, Monotributista Social, IVA Liberado Ley N° 19.640, entre otros), la automatización se detendrá intencionalmente y no insertará ninguna jurisdicción fiscal.

Flujo Operativo Principal

El proceso del Bproc está diseñado como un Webhook de tipo Maestro. Esto significa que el usuario final no debe ejecutar un proceso manual para asignar los impuestos; la automatización opera de manera transparente e inmediata en segundo plano al confirmar la creación del registro (cliente o proveedor).

A continuación se detalla la secuencia operativa paso a paso y la lógica que el sistema aplica en cada instancia.

Paso 1: Creación de la Entidad (El Disparador)

El flujo comienza cuando el usuario da de alta a un nuevo cliente/proveedor en el sistema. Esta acción puede realizarse por ingreso manual en pantalla, mediante un importador masivo o a través de una integración vía API.

Al completar la solapa General del Cliente o Proveedor, existen dos campos críticos que el usuario debe completar correctamente, ya que de ellos depende el comportamiento del automatismo:

Categoría Fiscal: Define el tratamiento impositivo general del sujeto.
Nivel de Compartición (Público/Privado): Determina el alcance del registro dentro del grupo económico (generalmente predefinido en el Diccionario de Datos).

ATENCIÓN: Es imperativo asignar una Categoría Fiscal que tribute Ingresos Brutos (ejemplo: Responsable Inscripto). Si el usuario selecciona categorías exceptuadas (como Consumidor Final, Cliente/Proveedor del Exterior, IVA No Alcanzado, Monotributista Social, o IVA Liberado Ley N° 19.640), el sistema abortará el proceso de asignación fiscal para mantener la ficha limpia y evitar retenciones indebidas.

Paso 2: Evaluación del Nivel de Compartición

Una vez que el usuario guarda el nuevo registro, el sistema lee el nivel de compartición del sujeto para determinar dónde buscar los datos impositivos.

Escenario A (Alta Privada): El sistema consulta exclusivamente la configuración de la empresa en la que el usuario tiene la sesión activa (empresa logueada).
Escenario B (Alta Pública): El sistema ignora la sesión actual del usuario y recorre todas las empresas activas del grupo económico. Realiza una unificación para evitar duplicados.

Ejemplo práctico: Si la Empresa “Norte” tiene configurada la jurisdicción CABA y la Empresa “Sur” también tiene CABA y además Córdoba, el sistema insertará en el nuevo registro público únicamente CABA (una sola vez) y Córdoba.

Paso 3: Sincronización de Jurisdicciones (Acción 1)

Una vez identificadas las empresas correspondientes (Paso 2), el sistema navega a los Datos Maestros de dichas empresas, copia todas las jurisdicciones activas y las inserta automáticamente en la ficha del nuevo sujeto.

Ubicación en pantalla: Solapa “Datos Impositivos” → Sección “Jurisdicciones IIBB” del Cliente o Proveedor.
Asignación de Situación: En la columna “Situación IIBB” de cada jurisdicción insertada, el sistema colocará el valor predefinido en el parámetro Situación IIBB default (por ejemplo, “No Inscripto”). Esto se realiza para asegurar que la jurisdicción nazca con un estado válido para el motor de cálculo.

Paso 4: Asignación de Tipos de Retención y Percepción (Acción 2)

Inmediatamente después de insertar las jurisdicciones, el sistema se dirige a la solapa “Contabilidad e Impuestos” del maestro de empresas para ver qué retenciones del Nuevo Motor se tienen configuradas en la Empresa. Una vez definido esto, se dirige nuevamente al maestro de Clientes/Proveedores y les agrega la retención/percepción. La inserción se realizará con reglas estrictas dependiendo del tipo de entidad creada.

Tabla 2. Lógica de Asignación de Retenciones y Percepciones

Tipo de Entidad Creada	Condición de Búsqueda en Empresa	Configuración Aplicada Automáticamente	Justificación (Para qué)

Proveedor	Modo = Múltiple Tipo = Retención	Momento de Aplicación: Ambas.	Asegura que la retención de impuestos se calcule correctamente desde la primera orden de pago sin intervención manual.
Cliente	Modo = Múltiple Tipo = Percepción	Momento de Aplicación: Operación.	Garantiza que la percepción se incluya de forma automática al momento de emitir la factura de venta.
Cliente y Proveedor (Ambos checks activos)	Se buscan ambos tipos (Retención y Percepción).	Se aplican ambas lógicas detalladas en las filas superiores.	Permite operar con la entidad en un circuito de cuenta corriente integral (compras y ventas) bajo la normativa correcta.

Nota Operativa: Durante este paso, el sistema únicamente completa el campo “Tipo de retención”. El campo específico de “Retención” quedará vacío de manera intencional, permitiendo que el motor impositivo resuelva la alícuota específica durante la transacción.

ATENCIÓN: Si el usuario, antes de guardar por primera vez el registro, carga manualmente una jurisdicción o tipo de retención en las solapas impositivas, el sistema activará un Control de Duplicados . La automatización detectará la existencia previa del dato y omitirá su inserción automática. Esto se diseñó para proteger personalizaciones manuales previas o datos traídos por interfaces externas (Integraciones API).

Impacto, Cierre o Interacciones Externas

El proceso en segundo plano finaliza una vez que consolida y transfiere los datos al nuevo registro. A continuación, se detalla el impacto directo de estas acciones en el ERP, cómo interactúa con herramientas externas y cómo el sistema registra estas operaciones de forma transparente para el usuario final.

Impacto Contable y Operativo

La finalización exitosa de esta automatización tiene un efecto preventivo inmediato sobre los módulos de Compras, Ventas y Tesorería, asegurando el cumplimiento fiscal desde el minuto cero:

En Proveedores: Al asignar automáticamente el tipo de retención con momento de aplicación en “Ambas”, el sistema asegura que al emitir la primera orden de pago, el motor impositivo calcule y aplique las retenciones correspondientes de manera exacta, sin requerir intervención ni ajustes manuales previos por parte del sector de Cuentas por Pagar.
En Clientes: La asignación automática de los tipos de percepción con momento de aplicación “Operación” garantiza que todas las facturas de venta emitidas a dicho cliente incluyan inmediatamente los recargos impositivos estipulados por ley, previniendo errores de facturación, notas de crédito correctivas o multas.

Interacciones Externas: APIs e Importadores Masivos

El BProc (Webhook) no está limitado a la operatoria manual a través de las pantallas del sistema. Su diseño de ejecución en la capa de negocio garantiza que las reglas fiscales se apliquen independientemente de la vía por la cual ingrese la información.

Tabla 3. Comportamiento del Proceso según el Origen de los Datos

Origen de la Creación	Comportamiento del Sistema	Justificación (Para qué)

Carga Manual (Pantalla)	Se ejecuta en tiempo real tras la confirmación de guardado.	Agiliza el alta individual por parte de analistas de impuestos o ejecutivos de cuentas, reduciendo clics operativos.
Importador Masivo (Excel/CSV)	Se dispara secuencialmente por cada registro creado en la importación.	Garantiza la integridad fiscal al migrar grandes volúmenes de padrones o bases de datos externas.
Integración vía API	Se activa automáticamente al recibir el request de creación en el servidor.	Permite que sistemas de terceros (como un e-commerce o CRM externo) den de alta sujetos que queden listos para facturar al instante.

ATENCIÓN: En escenarios de integración vía API o uso de importadores masivos, es común que la fuente de origen ya envíe ciertos datos impositivos. Para proteger estas integraciones, el sistema aplica un estricto Control de Duplicados . Si detecta que la API ya incluyó una jurisdicción o retención específica durante la creación, el sistema prioriza la información externa, omite la sobreescritura y continúa con las jurisdicciones faltantes. Esto evita errores de clave duplicada y pérdida de datos personalizados.

Registro de Auditoría (Logueo)

Dado que el proceso inserta información crítica sin interacción visible, el sistema requiere dejar un rastro auditable. Al finalizar la inserción de datos, el sistema genera automáticamente un registro en el historial (Log) del Cliente o Proveedor. Puntualmente, se asienta una traza de auditoría por cada nueva provincia o jurisdicción IIBB que la automatización haya agregado exitosamente. Esto le permite al Administrador del Sistema consultar el historial y verificar exactamente cuándo y bajo qué evento se inicializó el perfil impositivo del sujeto.

Escenarios comunes y Buenas Prácticas

Incluso con un alto nivel de automatización, las configuraciones previas o las omisiones humanas en los datos maestros pueden generar comportamientos inesperados durante el alta de registros. A continuación, se detallan los escenarios de error más frecuentes, sus motivos y los pasos exactos para su resolución.

Tabla 4. Escenarios de Error Comunes y Resoluciones

Síntoma / Escenario Operativo	Causa Raíz (Por qué ocurre)	Solución Paso a Paso (Para qué y Cómo)

El proceso finaliza pero la ficha del cliente/proveedor queda sin impuestos asignados.	La Categoría Fiscal asignada no tributa Ingresos Brutos (Ej: Consumidor Final, Cliente/Proveedor del Exterior, Monotributista Social, etc.). Alternativamente, la empresa logueada no tiene localización “Argentina”.	Paso 1: Ingresar a la ficha de la entidad. Paso 2: Verificar la solapa “General” > “Categoría Fiscal”. Paso 3: Si la entidad sí debe tributar, corregir la categoría (Ej: Responsable Inscripto). Paso 4: Cargar los impuestos manualmente en este caso, ya que el proceso automático opera solo en el alta inicial. Paso 5: Limpiar caché. Muchas veces el proceso parece que no hace nada pero en realidad es porque los datos se refrescan una vez eliminado el caché.
En un alta “Pública”, faltan jurisdicciones de algunas empresas del grupo económico.	El sistema no encuentra la configuración impositiva en la solapa “Contabilidad e Impuestos” de dichas empresas. O bien, se filtró intencionalmente por tratarse de un duplicado exacto.	Paso 1: Ingresar al Maestro de Empresas. Paso 2: Navegar a las empresas donde presuntamente faltan datos. Paso 3: Verificar que las jurisdicciones estén activas y que los tipos de retención tengan el “Modo” configurado en “Múltiple”.
El sistema ignora la configuración automática y prioriza un dato impositivo distinto.	El alta provino de un importador masivo o integración vía API que ya contenía datos impositivos. El “Control de Duplicados” omitió la inserción para proteger la información externa.	No requiere solución, es el comportamiento esperado del sistema para evitar sobreescritura de datos integrados. Si el dato externo es incorrecto, se debe corregir directamente en la fuente origen (archivo importador o request de la API).
Las jurisdicciones se insertan, pero la columna “Situación IIBB” queda vacía o con un código erróneo.	El parámetro `Situación IIBB default` del proceso BProc (AGREGARRETYPERC) está en blanco o tiene un valor numérico no válido (diferente de 0 a 4).	Paso 1: Ingresar a la configuración de BProcs. Paso 2: Buscar el código AGREGARRETYPERC. Paso 3: En la solapa Parámetros, asignar un valor válido al widget numérico (Ej: 3 para No Inscripto) y guardar los cambios.

Buenas Prácticas de Uso y Mantenimiento

Para asegurar que el motor de impuestos y la automatización BProc funcionen con la máxima eficiencia, se recomienda a los Administradores del Sistema y Usuarios Clave seguir estas directrices:

Limpieza de caché: Una vez ejecutado el BProc, se recomienda limpiar caché: Menú → Configuración → General → Limpiar caches.
Auditoría periódica del Maestro de Empresas: El BProc utiliza a las empresas como “molde”. Es mandatorio que cualquier nueva jurisdicción provincial en la que el grupo económico comience a operar sea dada de alta de inmediato en el Maestro de Empresas, configurando correctamente sus regímenes múltiples.* Revisión del Diccionario de Datos: Asegurar que el nivel de compartición (Tipo de Alta: Público o Privado) parametrizado en el Diccionario de Datos refleje la realidad operativa de la organización. Un alta configurada incorrectamente como “Privada” obligará a los usuarios a ingresar empresa por empresa para unificar la fiscalidad de una misma entidad.* Aprovechamiento del parámetro predeterminado: Analizar estadísticamente cuál es la situación frente a Ingresos Brutos más común en los nuevos clientes y proveedores del negocio. Configurar el parámetro Situación IIBB default con ese valor específico (por ejemplo, “No Inscripto”) reducirá drásticamente la carga de modificaciones manuales posteriores.* Manejo de registros nulos: El sistema está preparado para no bloquear la operatoria si no encuentra impuestos para heredar. Sin embargo, utilizar esto como práctica habitual (dejar el maestro de empresas vacío) anula el propósito de la herramienta y aumenta el riesgo de penalidades fiscales por falta de retención.

ATENCIÓN: Se debe instruir al equipo de Cuentas por Cobrar y Cuentas por Pagar para que no intenten cargar manualmente las retenciones o jurisdicciones antes de guardar por primera vez el registro. El “Control de Duplicados” bloqueará el automatismo si detecta intervención manual previa en la solapa impositiva, asumiendo que el usuario desea gestionar esa entidad de forma artesanal. El flujo correcto es: completar la solapa general, guardar el registro, dejar que el sistema asigne los datos en segundo plano, y luego ingresar nuevamente solo si es estrictamente necesario aplicar excepciones específicas.