¿Qué hace realmente la contabilidad dimensional en Navision / Business Central? Es increíble lo mal (o nada) que algunos formadores intentan explicar esta función turbo de Navision o Business Central, a menudo sin éxito.
Empecemos por lo básico. Hoy en día, en muchas empresas, KPI (Key Performance Indicators) y evaluación de la empresa siguen significando "evaluación de la gestión empresarial" según el formulario de Datev.
En realidad es una pena. Sobre todo si ya tienes Navision & Business Central en funcionamiento. En realidad ya no deberías hacer nada con Datev, suele ser doble y por tanto una pérdida de tiempo y dinero.
Ahora... volvamos a la "evaluación empresarial". Y, por tanto, al primer nivel de evaluación: el plan contable.
Nivel de evaluación / Fase de evaluación: Plan contable
En el plan contable encontrará, por ejemplo, una partida "gastos de vehículos" (skr03 4500/Skr046500). En el caso más sencillo, contabilizamos en esta cuenta todo lo que tiene que ver con los vehículos de la empresa. El resultado sería el siguiente
Sólo tenemos un total de todos los costes de vehículos en Business Central y Navision para todo el año. No sabemos a ciencia cierta a cuánto ascienden los costes de combustible, reparación, adquisición o mantenimiento.
Eso es insatisfactorio. Sería mucho mejor si pudiéramos distinguir, por ejemplo, entre costes de funcionamiento y costes permanentes.
Así que divide las cuentas de mayor:
Ahora ya tenemos 2 cuentas de mayor. ¿Y si ahora queremos distinguir entre costes de combustible y adquisición? Sin pensarlo más, llegamos rápidamente a esas cuentas de mayor para nuestra evaluación empresarial:
...Y la siguiente etapa consistiría en desglosar estos costes de los distintos vehículos:
Llegados a este punto, como muy tarde, todo el mundo debería darse cuenta de que se trata de un camino sin futuro. Con números de cuenta de 4 cifras, nos quedaremos muy rápidamente sin números de cuenta de mayor que intercalar entre los existentes. Si utilizamos la matrícula del vehículo en lugar del "jefe", cada cambio de vehículo da lugar automáticamente a una, dos o n nuevas cuentas de mayor. Esta forma de clasificar o agrupar costes (o incluso ingresos) es... Poco inteligente 🙂 .
Sin embargo, éste era un procedimiento habitual en el pasado, en la contabilidad en papel. La subdivisión de las reservas según otros criterios ("centros de coste", "unidades de coste") no aportaba ninguna ventaja. Al contrario: en lugar de poder leer los totales de cada vehículo a final de mes y a final de año, había que leer laboriosamente los subtotales de cada reserva.
Paso: Introducir la unidad de coste en la reserva
Sólo EDP, y aquí literalmente "Erocesamiento Reglamentode datos" , permitía asignar los llamados códigos de reserva a las reservas individuales. Y evaluarlos posteriormente. A partir de ahí, los procesadores de datos desarrollaron la forma utilizable de centros de costes y unidades de costes. En el mundo general, Datev probablemente introdujo los centros de costes y las unidades de costes como términos.
El truco: A cada asiento se le asigna una unidad de coste (de momento nos concentraremos en las unidades de coste en Business Central o Navision, los centros de coste vendrán en breve). Ya no contabilizamos en 10 cuentas de mayor diferentes, sino sólo en una... y damos a la contabilización un indicador evaluable.
Nota: A partir de aquí he utilizado Business Central y Navision en la versión 2019 Spring release, con el cliente Windows RTC (Role Taylored Client). Por supuesto, todo lo aquí expuesto sigue siendo válido para las versiones anteriores de Navision como 2009, 5, 4, 3.70. Creo que 3.70 introdujo la contabilidad dimensional en Navision. Navision 2.01, por ejemplo, sólo puede hacer contabilidad de centros de coste/unidades de coste... en principio. Pero incluso ahí, se puede hacer más...
En los primeros ejemplos dividimos las cuentas de mayor según las distintas unidades de coste (vehículos, empleados, máquinas, edificios...). Ahora ya no dividiremos las cuentas de mayor en sí, sino que proporcionaremos las contabilizaciones con las unidades de coste.
Tomemos de nuevo el ejemplo de los costes del automóvil y veamos ahora los costes de reparación. Sólo tenemos una cuenta de mayor para esto, 4540 Reparaciones de coches. Pero, ¿cómo obtenemos los costes de reparación individuales del Mercedes del jefe, el Audi de la Sra. Müller y el Skoda del Sr. Thöne?
Con cada reserva registramos directamente a qué unidad de coste pertenece.
A través de "Balance por dimensión", Navision & Business Central puede mostrar los saldos por unidad de coste en cualquier momento con sólo mover un dedo:
...Y por supuesto, como está acostumbrado en Navision, también puede desglosar cada valor total individual en sus valores individuales con un clic del ratón. Inimaginable sobre el papel, algo natural en Business Central o Navision.
Por supuesto, puede utilizar y evaluar esta dimensión/centro de coste/unidad de coste de muchas más formas, pero con esto debería bastar por ahora.
Resumen: Con las unidades de coste, se podría registrar otro nivel de evaluación en un plan de cuentas / plan contable muy reducido, sencillo y ordenado, sin destruir el orden del plan de cuentas.
Nivel: Introducir centros de coste en las reservas
Aunque los "centros de coste" son mucho más conocidos que las unidades de coste, la entrada de unidades de coste es la forma más común de imputación/registro de costes/contabilidad de costes.
Sin embargo, una vez que esto fue técnicamente posible, rápidamente surgió el deseo - tal vez lo conozcas de mis cursos de formación Navison: Si eso es posible, ¿qué más es posible?
Y el deseo más obvio era probablemente que la misma técnica se utilizara también para los centros de costes (¿DÓNDE se originan los costes? ¿Administración, producción, informática, Inglaterra, Alemania, Corea, envíos...?).
Por supuesto, ya no se trataba de un problema técnico. Así es como el término centro de costes se introdujo en la contabilidad financiera.
Técnicamente, además de la "unidad de coste", se posibilitó la entrada del "centro de coste"; las técnicas de evaluación ya existían.
En Business Central & Navision esto se llevó tan lejos que incluso se evaluó una matriz bidimensional con costes por combinación de centro de coste/unidad de coste... todas las evaluaciones más sencillas funcionaron de todos modos.
Tenga en cuenta que he introducido aquí -casi por casualidad- el término dimensión !
Nivel: Dimensiones y contabilidad dimensional
Debe haber sido alrededor de 2002 cuando Microsoft (más precisamente: en ese momento todavía Navision Dinamarca) comenzó a pensar intensamente en estos centros de coste / unidades de coste en Navision (en ese momento todavía no se llamaba Business Central).
¿Qué ocurre si alguien no desea contabilizar cero dimensiones (pura distribución de cuentas de mayor), una dimensión (por ejemplo, sólo centros de coste o sólo objetos de coste), 2 dimensiones (centros de coste y objetos de coste), sino también
- región de ventas
- clase de artículo
- vendedor
- número de proyecto
- encargado
- el clima/la temperatura (¡de verdad! Por ejemplo, en consultas veterinarias o de medicina general, gasolineras, heladerías...)
- Género del cliente (tiendas de moda)
- Tallas de vestido...
?
¿Y cuál fue la respuesta? ¿Por qué no?
Esto introdujo la contabilidad dimensional en Navision (y se mantuvo esencialmente sin cambios hasta Microsoft Business Central 365).
Con esta técnica puedes
- Asignar libremente las denominaciones de las dimensiones (si algo se designa como un centro de coste, una unidad de coste, una talla de zapato, un color, usted lo determina).
- Determinar libremente el número de dimensiones. 0, 1 (unidad de coste o centro de coste), 2 (unidad de coste y centro de coste, o talla de zapato y temperatura exterior en C°), 3, 4, 5 dimensiones... ¡da igual! No hay restricciones en Business Central ni en Navision.
Sólo quedaba un problema por resolver: ¿Cómo llamar a esta nueva forma de clasificación de las reservas?
El centro de coste y la unidad de coste eran ahora demasiado rígidos y anticuados para esta tecnología completamente nueva (no conozco ningún otro sistema contable que permita esta flexibilidad).
Más arriba he utilizado el término dimensión para explicar las diferentes orientaciones de la contabilidad. Vector o Cube también habrían servido. Pero la bidimensionalidad (para centro de coste y unidad de coste) y la tridimensionalidad (por ejemplo, para centro de coste, unidad de coste y vendedor) siguen siendo fácilmente imaginables por todos. Y ahí teníamos la contabilidad dimensional.
Conclusión: la contabilidad dimensional es como el centro de coste y la unidad de coste en éxtasis
Porque, por supuesto, puede aplicar esta técnica no sólo a los "costes". También se puede aplicar a los ingresos. Y en todas partes.
Y... puede dar a cada cliente, a cada artículo, a cada cuenta de mayor, a cada proveedor una o más dimensiones directamente en el maestro. Estas entradas se transfieren automáticamente a cada asiento, a cada pedido, a cada orden de compra, a cada factura. No necesita introducir estos datos manualmente cada vez. Pero... ¡puede hacerlo!!
Español 
Deutsch 
English