Las retenciones forman parte de la gestión fiscal y contable de muchas empresas en España, especialmente en operaciones con profesionales, arrendamientos, administradores o determinadas actividades económicas. Para dar respuesta a estas necesidades, los sistemas ERP han incorporado tradicionalmente diferentes soluciones, en muchos casos mediante desarrollos y adaptaciones específicas. Sin embargo, la evolución de las soluciones estándar está cambiando este escenario, Business Central dispone ahora de herramientas que permiten abordar buena parte de estas necesidades mediante parametrización.

Esto plantea una cuestión especialmente interesante para aquellas organizaciones que ya disponen de una solución personalizada:

¿Tiene sentido mantener un desarrollo específico cuando Business Central ya ofrece una alternativa estándar?

Como suele ocurrir en los proyectos ERP, no existe una respuesta universal. La decisión dependerá de las necesidades de cada organización, de la solución actualmente implantada y del grado de cobertura que ofrezca la funcionalidad estándar.

En este artículo analizamos cómo funciona este enfoque y qué aspectos deberíamos valorar.

¿Qué aporta realmente la funcionalidad estándar?

A primera vista, podríamos pensar que el principal objetivo de esta funcionalidad es simplemente calcular una retención. Sin embargo, el aspecto más interesante va más allá del cálculo del porcentaje.

Business Central proporciona una estructura específica para clasificar y parametrizar las diferentes casuísticas fiscales, permitiendo separar la naturaleza fiscal del proveedor de la naturaleza de la operación realizada.

La solución se basa principalmente en:

• Grupo contable de negocio de retención.

• Grupo contable de producto de retención.

• Reglas de cálculo.

• Porcentajes de retención.

• Tipo de ingresos.

• Configuración de cuentas contables.

Esta estructura permite construir una solución más parametrizable y, sobre todo, más alineada con la funcionalidad estándar del producto.

El reto: representar las distintas casuísticas fiscales

La normativa española contempla numerosas situaciones en las que pueden existir retenciones.

Por ejemplo, podemos encontrar diferentes claves relacionadas y el reto para cualquier implantación no consiste únicamente en aplicar correctamente el porcentaje.

También es necesario conseguir que la solución sea:

• Fácil de entender.

• Sencilla de mantener.

• Trazable.

• Adaptable a cambios normativos.

• Compatible con futuras actualizaciones de Business Central.

Aquí es donde la parametrización estándar puede aportar un valor considerable.

¿Cómo podríamos plantear la parametrización?

Una buena opción consiste en utilizar las claves fiscales como identificador principal de la naturaleza del proveedor.

• Grupo contable de negocio de retención

Este grupo podría utilizarse para representar la naturaleza fiscal del proveedor. Por ejemplo:

Una de las principales ventajas de este planteamiento es la trazabilidad.

Cuando un usuario consulta la ficha de un proveedor, puede identificar directamente su tratamiento fiscal sin necesidad de interpretar códigos internos adicionales.

• Grupo contable de producto de retención

Mientras que el grupo de negocio puede representar la naturaleza fiscal del proveedor, el grupo contable de producto de retención puede utilizarse para identificar la naturaleza de la operación. Por ejemplo:

Estos grupos pueden asociarse a artículos, recursos o cuentas de compras, dependiendo de la estrategia definida para cada implantación.

La combinación de ambos grupos permite separar dos conceptos que tradicionalmente pueden haber terminado mezclándose dentro de desarrollos personalizados:

¿Quién realiza la operación? y ¿Qué tipo de operación estamos realizando?

• Configuración de las retenciones

Una vez definidos los grupos, la configuración puede simplificarse considerablemente.

Por ejemplo: C_03 + FORESTAL = 2%

De esta manera, el porcentaje deja de estar asociado exclusivamente a un producto o servicio concreto y pasa a determinarse mediante la combinación de la naturaleza fiscal del proveedor y la naturaleza de la operación, dando como resultado un sistema más clara tanto para usuarios financieros como para consultores funcionales.

¿Qué función tiene cada elemento de configuración?

• Grupo contable de negocio de retención: representa la naturaleza fiscal del proveedor. Por ejemplo, permite diferenciar entre un profesional, un administrador, un arrendador o una actividad agrícola.
• Grupo contable de producto de retención: representa la naturaleza de la operación. Permite diferenciar, por ejemplo, entre un servicio profesional, un arrendamiento o una actividad agrícola.
• Regla de cálculo de retención: permite establecer las condiciones bajo las cuales se aplica la retención. Entre las posibilidades encontramos operadores como: Mayor /o igual que, igual a, menor /o igual que.
• Importe mínimo de factura: permite establecer un umbral mínimo a partir del cual se activa el cálculo de la retención. En determinados escenarios el valor es: 0,00 €
• Tipo de retención realizada: determina el momento en el que se genera la retención: factura, pago o el primero. Para determinados escenarios relacionados con IRPF, la retención se gestionará normalmente sobre la factura registrada.
• Configuración contable: la funcionalidad también permite definir las cuentas contables relacionadas con las retenciones, incluyendo conceptos como: retenciones por pagar, prepagadas o ajustes de retención.
• Tipo de ingresos: una herramienta interesante para clasificar las operaciones. Por ejemplo:

Esta clasificación puede resultar útil posteriormente para diferentes necesidades de reporting, cuadros de mando, informes fiscales o integraciones con otras soluciones. Es decir, el dato puede aportar valor más allá del propio cálculo de la retención.

Entonces, ¿merece la pena sustituir una solución personalizada?

La respuesta dependerá de cada proyecto, sin embargo, podemos establecer una regla bastante sencilla:

Si el estándar cubre las necesidades actuales y permite reducir personalizaciones, merece la pena estudiarlo seriamente.

Puede significar empezar a utilizar el estándar en nuevas implantaciones y mantener temporalmente la solución existente en clientes con desarrollos consolidados.

En cambio, si la solución personalizada contiene una lógica de negocio específica que el estándar no puede cubrir, puede seguir estando plenamente justificada.

El objetivo no debería ser «utilizar siempre estándar», sino utilizar el estándar siempre que sea capaz de cubrir correctamente las necesidades del negocio.

Conclusión

La incorporación de una funcionalidad estándar de retenciones en Business Central representa una oportunidad interesante para replantear cómo gestionamos este tipo de necesidades en las implantaciones españolas.

Su principal valor no está únicamente en calcular un porcentaje.

Está en proporcionar una estructura de parametrización que permite clasificar, relacionar y gestionar diferentes casuísticas fiscales dentro del propio ERP.

Para aquellas organizaciones que mantienen soluciones personalizadas desde hace años, esta funcionalidad puede ser una buena oportunidad para revisar si todos esos desarrollos siguen siendo necesarios.

No se trata de sustituir personalizaciones por estándar de forma automática.

Se trata de analizar cada caso, comparar ambas alternativas y determinar cuál ofrece el mejor equilibrio entre funcionalidad, mantenibilidad, trazabilidad y evolución futura.

Y en un entorno como Business Central, donde las actualizaciones del producto son constantes y reducir el código personalizado puede facilitar considerablemente la evolución de una implantación, esta comparación merece, al menos, un análisis detallado.