BC Blueprint - Dimensions

byFer Artigas -
0
BC Blueprint - Dimensions

BC Blueprint - Dimensions

Un análisis funcional y técnico en profundidad sobre cómo Business Central clasifica cada movimiento sin multiplicar el plan de cuentas; cómo nacen, se heredan, se validan y se almacenan las dimensiones; qué objetos participan; qué significa realmente Dimension Set ID; y por qué una dimensión aparentemente inocente puede mejorar el análisis de la empresa o convertir cada documento en un pequeño interrogatorio administrativo.

Nota de versión: los nombres e identificadores de objetos, campos y procedimientos públicos de este artículo se han contrastado con la documentación pública de Microsoft disponible el 31 de agosto de 2026. Los textos funcionales están en español, pero los objetos y referencias de AL conservan su nombre original en inglés. Comprueba siempre los símbolos de la versión exacta contra la que compila tu extensión: Business Central evoluciona, incluso cuando la tabla sigue llamándose Dimension Set Entry y parece llevar allí desde antes de que existieran las nubes.

El problema que resuelven las dimensiones

Una empresa quiere saber cuánto vende.

Después quiere saber cuánto vende por departamento. Luego por zona, proyecto, canal, campaña, vendedor y línea de negocio. Poco después alguien propone crear una cuenta contable distinta para cada combinación. La conversación empieza con entusiasmo y termina con un plan de cuentas que parece el catálogo de una ferretería industrial.

Las dimensions existen para evitar esa explosión.

Una cuenta contable responde principalmente a qué naturaleza económica tiene el movimiento: ventas, alquileres, bancos, clientes, existencias o coste de ventas. Una dimensión responde a desde qué perspectiva queremos analizarlo: departamento, área, proyecto, canal o centro de coste.

La separación es fundamental:

Pregunta Mecanismo principal Ejemplo
¿En qué cuenta debe registrarse? Posting Groups y configuración contable Cuenta 7000, ventas nacionales
¿Cómo quiero clasificar ese importe? Dimensions DEPARTMENT = SALES
¿Qué tercero, producto o documento originó el movimiento? Ledger entries y campos de trazabilidad Customer C-10000, Item 1896-S
¿Cómo quiero agruparlo para análisis recurrente? Filtros, Analysis View, informes o modelo analítico Margen por AREA y PROJECT

Esta distinción conecta directamente con BC Blueprint - Posting Groups: los posting groups deciden el destino contable; las dimensions describen el movimiento que llegó allí. Una responde “dónde”; la otra, “desde qué ángulo quiero mirarlo”. Mezclarlas suele producir cuentas con apellidos kilométricos o dimensiones que intentan arreglar una contabilización incorrecta. Ninguna de las dos cosas termina bien.

Microsoft define una dimensión como una categoría que permite analizar y organizar los movimientos sin ampliar innecesariamente el plan de cuentas. Esa definición funcional es correcta, pero debajo existe una arquitectura bastante más interesante: valores predeterminados distribuidos por maestros, reglas de prioridad, restricciones, combinaciones normalizadas y un identificador compartido que viaja por documentos y movimientos. Microsoft Learn: Work with dimensions

Primero, el modelo mental

Antes de abrir una página de configuración, conviene separar cinco conceptos que en conversación suelen mezclarse como si fueran la misma cosa.

1. Dimension

Es el eje de análisis. DEPARTMENT, AREA, PROJECT o CHANNEL son dimensiones.

La tabla Dimension (ID 348) contiene el código, nombre, captions, información de consolidación e intercompany y el estado Blocked. Una dimensión no contiene todavía la clasificación concreta de un movimiento; define la pregunta que podremos hacerle a los datos.

2. Dimension Value

Es una respuesta válida dentro de una dimensión. Para DEPARTMENT podrían existir SALES, ADMIN y PROD. Para AREA, NORTH, SOUTH y EUROPE.

La tabla Dimension Value (ID 349) almacena esos valores. También permite jerarquías mediante tipos como Standard, Begin-Total, End-Total, Total y Heading, además de indentación y totalización. Los valores de total sirven para presentar y agregar; los valores Standard son los que normalmente se asignan a transacciones.

3. Default Dimension

Es una regla asociada a un registro maestro. Por ejemplo: el Customer C-10000 propone AREA = NORTH; el Item 1896-S propone DEPARTMENT = SALES; el G/L Account 6110 exige que exista un valor de DEPARTMENT.

La tabla Default Dimension (ID 352) une Table ID + No. + Dimension Code y puede guardar Dimension Value Code, Value Posting y Allowed Values Filter. No es una dimensión del documento. Es una fuente y una regla para construir y validar la dimensión del documento.

4. Dimension Set

Es una combinación única de valores de dimensión:

AREA       = NORTH
DEPARTMENT = SALES
PROJECT    = BC-2027

Business Central representa esa combinación mediante varias filas de Dimension Set Entry (ID 480), todas con el mismo Dimension Set ID.

5. Dimension Set ID

Es el entero que identifica la combinación completa. El documento, la línea o el movimiento no necesita repetir tres, cinco o doce pares dimensión-valor: guarda un número, por ejemplo 108, que apunta al conjunto.

Dos registros con exactamente la misma combinación reutilizan el mismo ID. Si cambia un valor, falta una dimensión o aparece una nueva, la combinación es distinta y corresponde otro ID. Dimension Set ID = 0 representa el conjunto vacío, es decir, ninguna dimensión.

La idea central: una dimensión es el eje; un valor es una opción; un default propone o impone; un dimension set es la combinación efectiva; y Dimension Set ID es la referencia compacta que viaja por el sistema.

El viaje completo: del maestro al movimiento registrado

Flujo funcional y técnico de las dimensiones Los maestros aportan dimensiones predeterminadas, las reglas resuelven conflictos, un documento obtiene un Dimension Set ID y el proceso de registro lo copia a los movimientos. De la intención analítica al dato registrado Fuentes Customer · Vendor Item · G/L Account Location · Job · Employee Table 352 · Default Dimension Resolución y control Priorities · Value Posting Allowed Values Dimension Combinations Codeunit 408 · DimensionManagement Documento o diario Header y Lines Global Dimension 1/2 Dimension Set ID Instantánea editable antes de registrar Almacenamiento común Dimension Set Entry (480) Dimension Set Tree Node (481) Reutiliza combinaciones idénticas Registro G/L Entry · VAT Entry Cust./Vendor/Item Ledger Entry El ID viaja; la combinación permanece La dimensión efectiva se valida antes de registrar y se conserva para análisis posterior.
El flujo combina herencia funcional, validación y una arquitectura de conjuntos compartidos.

El diagrama contiene tres momentos diferentes que conviene no confundir:

  1. Propuesta. Los maestros aportan defaults. El usuario también puede introducir o cambiar valores.
  2. Resolución. Business Central combina fuentes, aplica prioridades y comprueba reglas.
  3. Persistencia. La combinación final obtiene un Dimension Set ID, que se copia al documento y después a los movimientos.

Cambiar el default de un Customer no reescribe mágicamente todos los documentos abiertos ni todos los movimientos históricos. El default es una regla de origen; el documento contiene una instantánea; el movimiento registrado representa lo que finalmente se contabilizó. Son capas distintas, y tratarlas como una sola es una fuente muy eficiente de reuniones.

Mapa de objetos que merece la pena conocer

La arquitectura central vive principalmente en el namespace Microsoft.Finance.Dimension.

Tipo ID Objeto Responsabilidad
Table 348 Dimension Maestro de ejes de análisis
Table 349 Dimension Value Valores, jerarquías y estado de cada dimensión
Table 350 Dimension Combination Restricción entre pares de dimensiones
Table 351 Dimension Value Combination Pares concretos de valores bloqueados cuando la combinación es limitada
Table 352 Default Dimension Defaults y reglas por registro maestro
Enum 353 Default Dimension Value Posting Type , Code Mandatory, Same Code, No Code
Table 354 Default Dimension Priority Precedencia entre fuentes para un Source Code
Table 356 Dim. Value per Account Valores permitidos para un maestro concreto
Table 480 Dimension Set Entry Filas que componen cada conjunto único
Table 481 Dimension Set Tree Node Árbol optimizado para localizar o crear conjuntos
Codeunit 408 DimensionManagement Biblioteca central de combinación, validación, edición y defaults
Codeunit 480 Get Shortcut Dimension Values Lectura cacheada de las ocho shortcut dimensions
Page 480 Edit Dimension Set Entries Editor temporal que devuelve un nuevo ID
Table 17 G/L Entry Movimiento contable con global dimensions y Dimension Set ID
Table 363 Analysis View Definición de análisis preagregado con hasta cuatro dimensiones
Codeunit 2580 Dimension Correction Mgt Orquestación de correcciones sobre G/L entries

La lista completa es mayor. Existen buffers, páginas de matrices, objetos para cambiar global dimensions, queries para expandir conjuntos, lógica específica de fabricación y las tablas del subsistema de correcciones. Pero los objetos anteriores forman el esqueleto que explica la mayoría de los comportamientos estándar y de las extensiones razonables.

Global, shortcut y todas las demás: tres nombres, un solo modelo

Business Central permite configurar dos global dimensions y ocho shortcut dimensions en General Ledger Setup. Las dos primeras shortcut dimensions son, a la vez, las dos global dimensions.

No son tres familias diferentes de dimensiones. Son posiciones con distinto grado de optimización y visibilidad.

Categoría Cantidad Dónde se usa Cómo se almacena habitualmente
Global dimensions 2 Filtros muy frecuentes, páginas, informes y movimientos Campos dedicados Global Dimension 1 Code y Global Dimension 2 Code, además del conjunto
Shortcut dimensions 8 Entrada rápida en documentos y diarios Las posiciones 1-2 tienen campos físicos frecuentes; 3-8 suelen resolverse desde Dimension Set ID según el objeto
Otras dimensions Sin límite práctico de configuración Página completa de dimensiones, filtros y análisis Dentro de Dimension Set Entry, accesibles por el ID

La razón de los campos físicos para las global dimensions es rendimiento y comodidad. Filtrar millones de G/L Entry por dos columnas indexables es más directo que expandir cada conjunto. El precio es que cambiar qué dimensión ocupa una posición global obliga a actualizar datos en múltiples tablas.

Microsoft advierte que cambiar global o shortcut dimensions puede ser costoso, bloquear tablas y requerir actualización de movimientos; para bases grandes existe un modo paralelo con sesiones en segundo plano. La conclusión de arquitectura es sencilla: elegir global dimensions no es personalizar una vista. Es una decisión de modelo de datos con factura operativa. Microsoft Learn: global and shortcut dimensions

Qué debería ocupar las posiciones globales

Normalmente, dimensiones que cumplen tres condiciones:

  • Se usan en una gran parte de las transacciones.
  • Se filtran constantemente en contabilidad y reporting.
  • Su definición será estable durante años.

DEPARTMENT y AREA suelen ser candidatas. CAMPAIGN-OF-THE-WEEK no suele serlo. Tampoco conviene colocar una dimensión en posición global porque el director financiero la preguntó tres veces durante una reunión especialmente larga.

Shortcut Dimension 3 Code no siempre es una columna

En páginas estándar, las shortcut dimensions 3-8 se muestran mediante variables, arrays y lógica de página. Algunos ledger entries sí incluyen campos físicos Shortcut Dimension 3 Code a Shortcut Dimension 8 Code; otros objetos se apoyan principalmente en Dimension Set ID. No asumas uniformidad entre tablas.

La fuente de verdad transversal es el conjunto. El codeunit Get Shortcut Dimension Values (ID 480, SingleInstance = true) expone GetShortcutDimensions(DimSetID, var ShortcutDimCode) y usa caché de General Ledger Setup. Esto permite presentar las ocho posiciones sin inventar ocho joins manuales por cada línea.

Dimension y Dimension Value: diseñar un idioma analítico

Crear dimensiones no consiste en copiar cada columna del CRM o del data warehouse. Consiste en definir un vocabulario estable para clasificar movimientos.

Una buena dimensión tiene:

  • Una pregunta empresarial clara.
  • Valores mutuamente comprensibles.
  • Un propietario funcional.
  • Una regla de asignación.
  • Una expectativa de estabilidad.
  • Un uso analítico que justifique el coste de captura.

Jerarquías de valores

Dimension Value permite construir grupos con Begin-Total y End-Total, de forma parecida a la estructura del plan de cuentas. Esto puede facilitar informes como Europa → UE / No UE o Comercial → Norte / Sur.

Pero una jerarquía de presentación no sustituye a una dimensión independiente. Si COUNTRY y SALES_REGION cambian con reglas diferentes, aplastarlas en una sola jerarquía puede ahorrar configuración hoy y fabricar ambigüedad mañana.

Bloquear no es borrar

Cuando una dimensión o valor deja de ser válido, bloquearlo conserva los movimientos históricos y evita nuevas selecciones. Borrarlo puede estar impedido si ya se utiliza y, aunque fuera técnicamente posible en algún contexto, sería una forma excelente de romper la semántica histórica.

El código NORTH registrado hace tres años debe seguir significando algo dentro de tres años. Renombrar el Name para mejorar la descripción es distinto de reutilizar el Code para una realidad diferente. Los códigos de dimensión son claves analíticas, no matrículas reciclables.

Default Dimension: propuesta, obligación y prohibición

La tabla Default Dimension tiene una doble personalidad:

  • Sugiere valores al crear documentos o diarios.
  • Valida qué está permitido registrar para un maestro.

El campo Value Posting está basado en el enum Default Dimension Value Posting Type (ID 353):

Valor Qué exige al registrar Uso típico Riesgo habitual
En blanco No añade una obligación específica Default orientativo o dimensión opcional Creer que el valor no puede cambiarse
Code Mandatory Debe existir algún valor para esa dimensión Centro de coste obligatorio, pero variable Configurarlo sin proceso para decidir el valor
Same Code Debe existir exactamente el valor del default Un activo o cuenta pertenece siempre a una unidad Usarlo en maestros cuya clasificación sí cambia por operación
No Code La dimensión no puede aparecer Evitar una dimensión irrelevante o prohibida Bloquear documentos por una herencia inesperada

Code Mandatory no significa “usar el código configurado”. Significa “algún código no vacío”. Same Code sí fija el valor. Y No Code no es lo mismo que dejar el default vacío: es una prohibición explícita.

Allowed Values Filter: obligatorio, pero no libre

Un caso intermedio muy útil es exigir una dimensión y limitar sus valores. Por ejemplo, la cuenta de gastos 6110 requiere DEPARTMENT, pero solo admite ADMIN|SALES. El filtro se almacena en Default Dimension."Allowed Values Filter"; la tabla Dim. Value per Account (ID 356) mantiene los valores permitidos utilizados por la interfaz y la validación.

Esto evita crear veinte cuentas contables solo para controlar qué departamento puede usar una naturaleza de gasto. También evita depender de una instrucción escrita en un documento llamado Normas_final_v7_AHORA_SI.pdf.

Defaults de tipo de cuenta

Business Central también permite definir defaults para un tipo de cuenta, no solo para registros individuales. Es potente y, por eso mismo, merece pruebas. Una regla amplia puede afectar cientos de maestros y entrar en conflicto con reglas específicas.

La validación final no pregunta si el usuario vio el default. Pregunta si el Dimension Set ID que se intenta registrar satisface las reglas de todas las fuentes relevantes.

Cuando varias fuentes quieren mandar

Una línea de venta puede recibir dimensiones del Customer, del Location, del Item, de la cabecera y de valores introducidos manualmente. Si todas aportan dimensiones distintas, se combinan. Si dos fuentes aportan valores diferentes para la misma dimensión, existe un conflicto.

Default Dimension Priority (ID 354) resuelve la precedencia por Source Code. Las prioridades no son universales: una política útil para ventas puede no ser la apropiada para compras o diarios.

Si dos tablas tienen la misma prioridad para el mismo Source Code, Business Central elige la tabla con el ID menor. Es determinista, pero “ganó Customer porque 18 es menor que 27” rara vez es una política contable que alguien quiso escribir conscientemente. Microsoft Learn: default dimension priorities

El orden de entrada también importa

Las dimensiones de una cabecera se heredan a nuevas líneas. Cambiar después un campo de cabecera puede provocar una pregunta para actualizar líneas existentes. Añadir un Item puede aportar otro default. Por eso dos usuarios pueden llegar a resultados diferentes introduciendo los mismos datos en distinto orden si la política no está bien definida.

No es aleatoriedad. Es herencia sobre un documento vivo.

Para sales y purchase documents, Microsoft señala una sutileza importante: las dimensiones de cabecera se consideran provenientes del Customer o Vendor, incluso si se introdujeron manualmente, lo que afecta a la prioridad frente a Item o Location. La única defensa sensata es probar escenarios en el orden real en que trabajan los usuarios, no solo rellenar una matriz de configuración y contemplarla con optimismo. Microsoft Learn: priority example

Qué hace DimensionManagement

El codeunit DimensionManagement (ID 408) ofrece el núcleo reutilizable:

  • AddDimSource(...) construye la lista moderna de fuentes como List of [Dictionary of [Integer, Code[20]]].
  • GetDefaultDimID(...) combina defaults, prioridades e herencia y devuelve un ID.
  • GetRecDefaultDimID(...) añade el contexto de un registro y campo.
  • GetCombinedDimensionSetID(...) fusiona hasta diez conjuntos; los posteriores sustituyen dimensiones repetidas de los anteriores.
  • GetDeltaDimSetID(...) recalcula un hijo cuando cambia el conjunto del padre, conservando diferencias propias.
  • CheckDimIDComb(...) comprueba restricciones entre dimensiones.
  • CheckDimValuePosting(...) comprueba las reglas de los maestros y valores permitidos.

La extensión que crea documentos con dimensions debería reutilizar estas primitivas. Reimplementar la precedencia con tres if y una esperanza no es una optimización; es una bifurcación funcional.

Restricciones: evitar combinaciones que no deberían existir

Los defaults responden “qué valor propongo o exijo para este maestro”. Las combinaciones responden “qué pares no pueden convivir en el mismo movimiento”. Son controles diferentes.

Dimension Combination

La tabla Dimension Combination (ID 350) trabaja por pares de dimensiones:

  • No limitation: ambas dimensiones pueden coexistir.
  • Limited: pueden coexistir, salvo determinadas parejas de valores.
  • Blocked: ambas dimensiones no pueden aparecer juntas, independientemente de sus valores.

Si PROJECT y CAMPAIGN representan dos mecanismos excluyentes de atribución, la combinación completa podría bloquearse. Si DEPARTMENT y PROJECT pueden convivir pero el proyecto FACTORY-01 no pertenece a SALES, la combinación será Limited y se bloqueará solo esa pareja de valores.

Dimension Value Combination

La tabla Dimension Value Combination (ID 351) almacena las parejas concretas bloqueadas para combinaciones limitadas. La interfaz utiliza matrices simétricas: la regla DEPARTMENT/SALES con PROJECT/FACTORY-01 es la misma aunque la mires desde la fila o desde la columna.

La validación estándar pasa por DimensionManagement.CheckDimIDComb. Si devuelve false, GetDimCombErr() proporciona el error. Normalmente no deberías llamar a la tabla 350 directamente desde un proceso de posting personalizado; usa el motor para que también se evalúen los valores limitados.

No conviertas la matriz en un motor de reglas universal

Las combinaciones son pares. Si una regla depende simultáneamente de cuatro dimensiones, fecha, usuario y color de la luna, la matriz no es el lugar natural. Podrías terminar manteniendo cientos de bloqueos parciales sin que nadie pueda explicar la política completa.

En ese caso, documenta la regla empresarial y aplica una validación explícita mediante eventos o en tu dominio. Las dimensiones sirven para clasificación y controles razonables; no necesitan convertirse en un lenguaje de programación accidental.

Dimension Set ID: la pieza que lo cambia todo

Antes de la arquitectura de dimension sets, almacenar dimensiones significaba repetir pares dimensión-valor en tablas auxiliares para cada documento y movimiento. Business Central normaliza la combinación y la reutiliza.

Supongamos este conjunto:

Dimension Set ID Dimension Code Dimension Value Code Dimension Value ID
108 AREA NORTH 41
108 DEPARTMENT SALES 73
108 PROJECT BC-2027 105

En Dimension Set Entry, la clave lógica de una fila incluye el ID del conjunto y el código de dimensión. El campo Dimension Value ID es el identificador entero interno del valor y participa en la búsqueda optimizada. Los nombres se recuperan desde los maestros; los códigos son la semántica funcional.

La documentación de diseño confirma que, cuando se cierra Edit Dimension Set Entries, el sistema busca si la combinación ya existe. Si existe, reutiliza su ID; si no, crea un conjunto y asigna el nuevo ID al header, line o journal line. Microsoft Learn: Dimension Set Entries Overview

Un conjunto es inmutable desde la perspectiva de negocio

Imagina que 85.000 movimientos apuntan al ID 108. Si modificases directamente una de sus filas de AREA = NORTH a AREA = SOUTH, no habrías corregido un documento: habrías reescrito el significado de los 85.000 registros que comparten el conjunto.

Por eso el patrón correcto es:

  1. Cargar las filas del conjunto en un record temporary.
  2. Añadir, cambiar o eliminar valores en ese buffer.
  3. Pedir a GetDimensionSetID el ID de la combinación resultante.
  4. Asignar ese nuevo ID al registro que quieres cambiar.

El conjunto original permanece igual. Si la nueva combinación ya existía, se reutiliza. Si no, se crea.

Regla de supervivencia: no hagas Modify o Delete sobre filas persistentes de Dimension Set Entry para cambiar las dimensiones de una transacción. No estás editando un detalle privado; estás serrando una rama compartida mientras otros registros están sentados encima.

El árbol de conjuntos: cómo evita Business Central los duplicados

Buscar una combinación comparando todas sus filas contra todos los conjuntos sería caro. Dimension Set Tree Node (ID 481) mantiene un árbol cuyos caminos se construyen con Dimension Value ID ordenados. Es conceptualmente parecido a un trie.

Árbol de búsqueda y reutilización de dimension sets Los identificadores internos de valores forman caminos compartidos. Una combinación existente devuelve su Dimension Set ID; una rama nueva crea otro. Una ruta canónica para cada combinación Ejemplo conceptual: los números son Dimension Value ID, no códigos visibles. Raíz Parent Set ID = 0 Value ID 41 AREA = NORTH Value ID 42 AREA = SOUTH Value ID 70 DEPT = ADMIN Value ID 73 DEPT = SALES Value ID 73 DEPT = SALES Set ID 108 Ruta existente: reutilizar Set ID 149 Ruta distinta: otro conjunto
Los prefijos se comparten. La ruta completa identifica una combinación normalizada, sin depender del orden en que el usuario introdujo los valores.

La tabla 481 guarda Parent Dimension Set ID, Dimension Value ID, Dimension Set ID e In Use. Dimension Set Entry.GetDimensionSetID o el wrapper equivalente de DimensionManagement recorren la estructura para detectar duplicados y crear ramas cuando es necesario. Microsoft describe esta tabla como una estructura optimizada para creación y detección de combinaciones duplicadas. Microsoft Learn: Dimension Set Tree Node

Consecuencias prácticas

  • El orden de introducción no define la identidad. AREA y después DEPARTMENT debe producir lo mismo que el orden contrario.
  • La reutilización ahorra espacio cuando muchas transacciones comparten clasificaciones.
  • El crecimiento depende del número de combinaciones únicas, no solo del número de dimensiones.
  • Un atributo de altísima cardinalidad —por ejemplo número de serie, GUID de integración o documento único— puede crear un conjunto nuevo casi por transacción y reducir el beneficio.
  • Copiar un Dimension Set ID es barato, pero solo es correcto si la combinación completa debe heredarse.

Un ejemplo completo: de tres defaults al ID 108

Tenemos la siguiente configuración:

Origen Default Value Posting
Customer C-10000 AREA = NORTH Same Code
Item 1896-S DEPARTMENT = SALES En blanco
Job BC-2027 PROJECT = BC-2027 Same Code
G/L Account de ingresos DEPARTMENT Code Mandatory

Al crear el documento, la cabecera recibe AREA = NORTH. La línea del Item aporta DEPARTMENT = SALES. Si la operación está vinculada al Job, aparece PROJECT = BC-2027. El motor combina las fuentes y produce:

AREA=NORTH | DEPARTMENT=SALES | PROJECT=BC-2027

Supongamos que el árbol devuelve Dimension Set ID = 108.

El número 108 no significa “Norte” ni “Ventas”. Solo significa esa combinación exacta en esa company. No lo integres como un código empresarial estable, no lo compares entre compañías y no lo hardcodees. En otra base de datos, el ID 108 puede describir otra combinación completamente distinta.

Si otra factura tiene exactamente los mismos tres pares, reutiliza 108. Si el usuario cambia DEPARTMENT = ADMIN, la factura recibe otro ID. Las filas del 108 no se tocan.

¿Y si header y line tienen IDs distintos?

Es normal. La cabecera expresa el contexto común; la línea puede combinarlo con su propio origen y sus excepciones. Al registrar, cada movimiento se genera desde el contexto dimensional de la línea o de la parte del documento que corresponda. No existe una promesa de que todas las líneas deban compartir el ID de la cabecera.

Una comprobación funcional que solo mira las dimensions del header puede declarar perfecto un documento cuyas líneas cuentan otra historia.

La vida de las dimensiones dentro de un documento

Creación de la cabecera

Al validar Sell-to Customer No. o Buy-from Vendor No., el documento obtiene defaults del tercero y otras fuentes de cabecera. Bill-to Customer No. o Pay-to Vendor No. pueden introducir contexto adicional según el flujo.

Creación de líneas

Las líneas parten normalmente del conjunto de la cabecera y lo combinan con el tipo y número de línea: Item, Resource, G/L Account, Fixed Asset, Charge (Item) u otros dominios. Location, Job y variantes funcionales pueden añadir fuentes.

Cambios posteriores

Modificar Customer, Vendor, Location o dimensiones de cabecera puede ofrecer actualizar líneas. El sistema necesita respetar diferencias específicas de cada línea; para ello existen patrones como GetDeltaDimSetID, que trasladan el cambio del padre sin destruir dimensiones propias del hijo.

Copias y documentos correctivos

Copiar un documento o crear un credit memo desde un documento registrado requiere decidir si se conserva el conjunto histórico, se recalculan defaults actuales o se mezcla ambos comportamientos. El estándar tiene reglas por proceso. Una extensión no debería asumir que “copiar campos” y “recalcular dimensions” son equivalentes.

El registro

Antes de registrar, los posting routines validan:

  • que las dimensions y values no estén bloqueados;
  • que la combinación no viole Dimension Combination;
  • que cada fuente satisfaga Value Posting;
  • que los values cumplan restricciones por account;
  • que los global dimension fields sean coherentes con el conjunto.

Después, el Dimension Set ID se copia a los ledger entries correspondientes. El proceso puede generar varios movimientos —G/L, VAT, customer/vendor, item, value, job, fixed asset— y no todos tienen necesariamente la misma combinación, porque representan componentes distintos de la operación.

Qué queda guardado después de registrar

G/L Entry (table 17) incluye Global Dimension 1 Code, Global Dimension 2 Code y Dimension Set ID. Esto permite filtros rápidos para las dos globales y acceso al conjunto completo para cualquier otra.

Muchas tablas de movimientos también contienen Dimension Set ID: Cust. Ledger Entry, Vendor Ledger Entry, Item Ledger Entry, Value Entry, Job Ledger Entry, FA Ledger Entry, VAT Entry y otras. Algunas incluyen además shortcut dimension fields físicos.

Dos matices importan:

  1. Tener el mismo origen no garantiza el mismo ID en todos los ledgers. Reglas de registro, redondeos, cuentas y contextos específicos pueden producir conjuntos diferentes.
  2. La corrección de G/L no reescribe necesariamente subledgers. El modelo permite que la vista contable corregida y el detalle operativo histórico diverjan.

Por eso una conciliación dimensional debe declarar qué ledger considera autoritativo. “He filtrado por dimensión y no coincide” no es todavía un diagnóstico; es el título de la investigación.

Correcciones: arreglar el análisis sin recontabilizar importes

La funcionalidad de dimension corrections permite cambiar dimensions en G/L Entry ya registradas y actualizar analysis views. No cambia importes, cuentas contables, posting dates ni documentos originales.

El codeunit Dimension Correction Mgt (ID 2580), dentro de Microsoft.Finance.Dimension.Correction, gestiona validación, generación de conjuntos objetivo, ejecución, programación y estados. El subsistema utiliza tablas de cabecera, cambios, selección de movimientos, buffers y logs.

La limitación más importante

Microsoft lo indica expresamente: las correcciones se aplican a G/L entries, no a los movimientos relacionados de otros ledgers. Después de corregir, las dimensions del mayor pueden no coincidir con customer, vendor o item ledger entries del mismo registro. Microsoft Learn: Troubleshoot and correct dimensions

Eso no convierte la función en peligrosa; define su propósito. Sirve para corregir reporting financiero cuando la naturaleza económica es correcta y la clasificación analítica no. No sustituye a desregistrar o revertir procesos operativos cuando el error afecta al documento, a existencias, a impuestos o a la cuenta.

Antes de ejecutar una corrección

  • Define exactamente qué G/L entries entran en el alcance.
  • Revisa la vista previa de cambios.
  • Comprueba bloqueos y combinaciones.
  • Entiende qué analysis views se actualizarán.
  • Decide cómo se explicará la divergencia con subledgers.
  • Conserva una evidencia del motivo y aprobación.

Una corrección de dimensión puede mejorar un informe sin alterar el saldo. Precisamente por eso necesita gobierno: es capaz de cambiar la narrativa analítica de movimientos históricos sin una nueva contabilización.

Cambiar las global dimensions: una operación de datos, no cosmética

Modificar Global Dimension 1 Code o Global Dimension 2 Code obliga a sincronizar campos dedicados en múltiples tablas y actualizar el indicador correspondiente dentro de dimension sets. El proceso estándar dispone de páginas, tablas de log y codeunits específicos como Change Global Dim. Log Mgt. y Update Dim. Set Glbl. Dim. No..

Microsoft ofrece dos modos:

  • Sequential: una operación que puede bloquear múltiples tablas; adecuada para compañías pequeñas.
  • Parallel: divide el trabajo en sesiones de fondo y transacciones; recomendada para volúmenes grandes, con restricciones de sesiones activas.

Esto tiene impacto en disponibilidad, duración, bloqueos y plan de reversión. Trátalo como una migración de datos:

  1. medir volumen por tabla;
  2. probar en copia representativa;
  3. calcular ventana;
  4. validar extensiones con campos dimensionales propios;
  5. ejecutar con monitorización;
  6. reconciliar filtros y analysis views.

La mejor optimización sigue siendo elegir bien las global dimensions al principio.

Arquitectura AL para un objeto personalizado

Supongamos una tabla personalizada Service Allocation que debe comportarse como un documento estándar. El patrón mínimo contiene:

  • Global Dimension 1 Code.
  • Global Dimension 2 Code.
  • Dimension Set ID.
  • Validación sincronizada entre shortcut fields y conjunto.
  • Una acción para editar el conjunto completo.
  • Herencia de defaults mediante las APIs estándar.
  • Validación antes de registrar.

Campos y triggers

table 50120 "Service Allocation"
{
    DataClassification = CustomerContent;

    fields
    {
        field(1; "No."; Code[20])
        {
            Caption = 'No.';
        }
        field(20; "Customer No."; Code[20])
        {
            Caption = 'Customer No.';
            TableRelation = Customer;

            trigger OnValidate()
            begin
                CreateDimFromDefaultDim();
            end;
        }
        field(30; "Global Dimension 1 Code"; Code[20])
        {
            CaptionClass = '1,1,1';
            TableRelation = "Dimension Value".Code
                where("Global Dimension No." = const(1), Blocked = const(false));

            trigger OnValidate()
            begin
                DimMgt.ValidateShortcutDimValues(
                    1, "Global Dimension 1 Code", "Dimension Set ID");
            end;
        }
        field(31; "Global Dimension 2 Code"; Code[20])
        {
            CaptionClass = '1,1,2';
            TableRelation = "Dimension Value".Code
                where("Global Dimension No." = const(2), Blocked = const(false));

            trigger OnValidate()
            begin
                DimMgt.ValidateShortcutDimValues(
                    2, "Global Dimension 2 Code", "Dimension Set ID");
            end;
        }
        field(40; "Dimension Set ID"; Integer)
        {
            Caption = 'Dimension Set ID';
            Editable = false;
            TableRelation = "Dimension Set Entry";
        }
    }

    keys
    {
        key(PK; "No.") { Clustered = true; }
    }

    var
        DimMgt: Codeunit DimensionManagement;

    local procedure CreateDimFromDefaultDim()
    var
        DefaultDimSource: List of [Dictionary of [Integer, Code[20]]];
    begin
        DimMgt.AddDimSource(
            DefaultDimSource, Database::Customer, "Customer No.");

        "Dimension Set ID" := DimMgt.GetDefaultDimID(
            DefaultDimSource,
            '',
            "Global Dimension 1 Code",
            "Global Dimension 2 Code",
            "Dimension Set ID",
            Database::"Service Allocation");
    end;

    procedure ShowDimensions()
    begin
        "Dimension Set ID" := DimMgt.EditDimensionSet(
            Rec,
            "Dimension Set ID",
            StrSubstNo('%1 %2', TableCaption, "No."),
            "Global Dimension 1 Code",
            "Global Dimension 2 Code");
    end;
}

El ejemplo ilustra el patrón, no una aplicación completa. El Source Code, los orígenes y el InheritFromTableNo deben representar el proceso real. Una línea debería considerar su header y el maestro de su tipo. Un posting routine debería volver a validar, no confiar solo en los triggers de página.

Editar el conjunto completo

DimensionManagement.EditDimensionSet(...) abre Edit Dimension Set Entries sobre una tabla temporal y devuelve el ID resultante. La overload con variables de global dimensions mantiene sincronizados los campos 1 y 2.

trigger OnAction()
begin
    Rec.ShowDimensions();
    CurrPage.SaveRecord();
end;

La página estándar no edita las filas persistentes del conjunto. Carga un buffer temporal, permite cambios y obtiene un ID nuevo o existente al cerrar. Esa distinción es la arquitectura, no un detalle de interfaz.

Mostrar shortcut dimensions 3-8

Para leer las ocho posiciones:

var
    GetShortcutDimValues: Codeunit "Get Shortcut Dimension Values";
    ShortcutDimCode: array[8] of Code[20];

local procedure LoadShortcutDimensions()
begin
    Clear(ShortcutDimCode);
    GetShortcutDimValues.GetShortcutDimensions(
        Rec."Dimension Set ID", ShortcutDimCode);
end;

En una página de líneas, el patrón estándar decide qué columnas 3-8 son visibles, usa CaptionClass dinámica y llama a ValidateShortcutDimValues cuando se modifica una. Copiar el patrón de un documento estándar cercano a tu dominio suele ser más seguro que diseñar una página genérica desde cero.

Construir o transformar un conjunto sin interfaz

local procedure ReplaceProjectDimension(
    OldDimSetID: Integer;
    NewProjectCode: Code[20]
): Integer
var
    DimMgt: Codeunit DimensionManagement;
    TempDimSetEntry: Record "Dimension Set Entry" temporary;
    DimValue: Record "Dimension Value";
begin
    DimMgt.GetDimensionSet(TempDimSetEntry, OldDimSetID);

    TempDimSetEntry.SetRange("Dimension Code", 'PROJECT');
    TempDimSetEntry.DeleteAll();
    TempDimSetEntry.Reset();

    if NewProjectCode <> '' then begin
        DimValue.Get('PROJECT', NewProjectCode);
        DimValue.TestField(Blocked, false);

        TempDimSetEntry.Init();
        TempDimSetEntry."Dimension Set ID" := 0;
        TempDimSetEntry."Dimension Code" := DimValue."Dimension Code";
        TempDimSetEntry."Dimension Value Code" := DimValue.Code;
        TempDimSetEntry."Dimension Value ID" := DimValue."Dimension Value ID";
        TempDimSetEntry.Insert();
    end;

    exit(DimMgt.GetDimensionSetID(TempDimSetEntry));
end;

En código productivo también debes decidir cómo validar combinaciones, Value Posting, allowed values y global dimension fields. La transformación mecánica del conjunto y la autorización contable para registrarlo son pasos distintos.

Validar antes de registrar

local procedure CheckDimensionsBeforePosting(
    DimSetID: Integer;
    CustomerNo: Code[20];
    GLAccountNo: Code[20])
var
    DimMgt: Codeunit DimensionManagement;
    TableID: array[10] of Integer;
    No: array[10] of Code[20];
begin
    if not DimMgt.CheckDimIDComb(DimSetID) then
        Error(DimMgt.GetDimCombErr());

    TableID[1] := Database::Customer;
    No[1] := CustomerNo;
    TableID[2] := Database::"G/L Account";
    No[2] := GLAccountNo;

    if not DimMgt.CheckDimValuePosting(TableID, No, DimSetID) then
        Error(DimMgt.GetDimValuePostingErr());
end;

Las APIs antiguas basadas en arrays conviven con APIs modernas para defaults basadas en lists y dictionaries. Usa la firma pública disponible en tus símbolos y evita envolver todo el codeunit en una copia local: perderías correcciones estándar y eventos futuros.

El contrato de sincronización

Un objeto con dimensions mantiene varias representaciones del mismo significado. Deben moverse juntas.

Contrato de sincronización dimensional Editar global dimensions o el conjunto completo debe recalcular el Dimension Set ID y mantener consistencia. El posting valida el resultado antes de copiarlo a ledgers. Tres vistas de una misma clasificación Campos visibles Global Dimension 1 Code Global Dimension 2 Code Y variables shortcut 3-8 Referencia canónica Dimension Set ID Identifica la combinación completa Conjunto compartido Dimension Set Entry Un par por dimensión No editar filas persistentes DimensionManagement Validar · combinar · obtener ID Actualiza ambas representaciones Posting validation Combinations · Value Posting Solo entonces copia a ledgers Cambiar cualquier representación sin sincronizar las otras crea datos que parecen correctos hasta que alguien registra.
Los campos globales son accesos rápidos; Dimension Set ID representa el conjunto; DimensionManagement mantiene el contrato entre ambos.

Errores típicos de extensiones:

  • Asignar Global Dimension 1 Code sin recalcular Dimension Set ID.
  • Cambiar el ID sin actualizar los dos global fields.
  • Mostrar shortcut dimension variables sin recargarlas al cambiar de línea.
  • Copiar el ID del header sobre líneas y borrar excepciones válidas.
  • Omitir CheckDimValuePosting en un posting routine propio.
  • Insertar directamente en table 480 con un ID inventado.

Estos fallos son incómodos porque la página puede mostrar una cosa, el conjunto contener otra y el error aparecer mucho después durante el posting o en reporting.

Extensibilidad: dónde intervenir

DimensionManagement expone numerosos integration events alrededor de obtención de defaults, creación de conjuntos, validación y actualización de global dimensions. Los documentos estándar también publican eventos en los momentos en que construyen DefaultDimSource, actualizan header/lines o verifican posting.

Una extensión suele necesitar intervenir por una de estas razones:

  1. Añadir un maestro personalizado como fuente.
  2. Introducir una dimensión derivada de un proceso propio.
  3. Propagar cambios del header a líneas personalizadas.
  4. Añadir una validación empresarial que las combinaciones estándar no expresan.
  5. Copiar dimensions a un ledger personalizado.

La estrategia preferible es suscribirse al evento más cercano al concepto. Añadir una fuente cuando se construye la lista conserva prioridades y reglas estándar. Sobrescribir el ID después de que el sistema haya terminado puede saltarse validaciones o eliminar otras dimensions.

Qué no hacer

  • No reemplaces todo el cálculo con IsHandled := true si solo quieres añadir una fuente.
  • No uses códigos de dimensión literales cuando General Ledger Setup o una configuración propia debería definirlos.
  • No supongas que DEPARTMENT siempre es Global Dimension 1.
  • No llames a la interfaz desde un proceso background.
  • No conviertas eventos de posting en consultas masivas repetidas a Dimension Set Entry por cada línea si puedes cachear o trabajar por ID.

Una personalización dimensional buena parece aburrida: usa las APIs estándar, conserva el ID, valida en posting y publica eventos propios alrededor de su dominio. El aburrimiento, en contabilidad, es una característica premium.

Rendimiento y cardinalidad

El modelo de conjuntos ahorra espacio cuando se repiten combinaciones. Pero no elimina el coste de una taxonomía descontrolada.

Si existen 5 valores de DEPARTMENT, 20 de AREA, 300 de PROJECT y 4 de CHANNEL, el máximo teórico ya es 120.000 combinaciones. La realidad suele usar una fracción. Añadir una dimensión EXTERNAL TRANSACTION ID con un valor único por movimiento puede acercar el número de conjuntos al número de transacciones.

Señales de una dimensión demasiado granular

  • Cada documento crea un dimension set nuevo.
  • El valor ya existe como campo de trazabilidad indexable.
  • Nadie agrega por ese valor; solo lo busca individualmente.
  • El valor cambia después de registrar por razones operativas.
  • La lista de dimension values necesita una integración continua solo para mantenerse viva.

Document number, serial number, shipment ID y GUID suelen pertenecer a campos propios. Una dimensión es buena para segmentar; no necesariamente para identificar.

Consultas y reporting

Para pocas dimensiones conocidas, los global fields o queries estándar pueden ser eficientes. Para explotar todas las dimensions, el análisis debe expandir Dimension Set ID contra Dimension Set Entry.

Evita un patrón N+1 que, por cada G/L Entry, ejecute una lectura individual del conjunto. Agrupa por IDs, usa queries o carga una caché. En AL, Get Shortcut Dimension Values ya aplica caché para las posiciones configuradas. En Power BI o un data warehouse, modela una tabla puente Dimension Set ID → pares y considera materializar las dimensiones relevantes en la capa analítica.

El ID no es una dimensión empresarial válida fuera de su company. En una consolidación, la clave técnica debe incluir company/environment o, mejor, expandirse a códigos de dimensión y valor antes de unificar datos.

Analysis View: rendimiento a cambio de una estructura explícita

Analysis View (table 363, namespace Microsoft.Finance.Analysis) permite seleccionar hasta cuatro dimensiones, filtros, fecha inicial y compresión. Analysis View Entry almacena agregados para acelerar análisis recurrentes. La opción Update on Posting decide si se mantiene al registrar o mediante actualizaciones posteriores.

Esto introduce una distinción importante:

  • G/L Entry + Dimension Set Entry contienen el detalle contable dimensional.
  • Analysis View Entry es una proyección agregada preparada para consultar.

Si una analysis view no está actualizada, el análisis puede no incluir los últimos movimientos. Si se cambia su definición, puede requerir reset y regeneración. Si se ejecuta una dimension correction, deben actualizarse las vistas afectadas.

No elijas las cuatro dimensiones de una analysis view porque son las primeras cuatro de General Ledger Setup. Elige las que forman una pregunta recurrente y cuya combinación justifica la preagregación.

Impacto funcional en toda la aplicación

Las dimensions no son un accesorio de General Ledger. Atraviesan:

  • sales y purchases;
  • general, payment, item y job journals;
  • inventory y costing;
  • jobs/projects;
  • fixed assets;
  • service y manufacturing;
  • budgets, analysis views y account schedules;
  • intercompany y consolidación;
  • APIs, migraciones e integraciones.

Un default en Location puede afectar líneas de ventas, compras y movimientos de inventario. Un Same Code en G/L Account puede bloquear postings generados automáticamente donde el usuario nunca ve esa cuenta. Una combinación limitada puede impedir registrar un proceso nocturno que llevaba meses funcionando hasta que apareció un nuevo valor.

El impacto es transversal porque las dimensions acompañan al movimiento, no a una única pantalla.

Errores habituales y lo que realmente significan

Síntoma Causa probable Investigación útil
“Select a Dimension Value…” Code Mandatory sin valor efectivo Revisar todas las fuentes del posting y el set de la línea
“must be …” Same Code no coincide Identificar qué maestro impone el valor
“must not be mentioned” No Code y el conjunto contiene la dimensión Localizar de qué header/default se heredó
“Dimension combinations … can’t be used concurrently” Combinación Blocked o value pair bloqueado Revisar tables 350/351 y el ID completo
La cabecera parece correcta pero no registra Una línea tiene otro set o la cuenta generada impone otra regla Inspeccionar lines y cuentas reales del posting
La página muestra global dimensions distintas del conjunto Extensión desincronizó campos e ID Comparar fields con rows de table 480
El informe no coincide con G/L entries Analysis view desactualizada, filtros o ledger diferente Revisar fecha de update y origen del informe
Corrección visible en G/L, no en Item Ledger Comportamiento esperado de dimension correction Documentar divergencia; no editar subledger directamente

Método de depuración sin adivinación ceremonial

  1. Captura tabla, clave del registro y Dimension Set ID que falla.
  2. Abre todas las rows de Dimension Set Entry para ese ID.
  3. Identifica los maestros que participan: header, line, account, balancing account, job, location.
  4. Consulta sus Default Dimension, Value Posting y allowed values.
  5. Revisa Default Dimension Priority para el Source Code del proceso.
  6. Comprueba Dimension Combination y Dimension Value Combination.
  7. Compara global dimension fields con el conjunto.
  8. Reproduce en una copia y depura CheckDimIDComb / CheckDimValuePosting.

No empieces cambiando el default que “parece sospechoso”. Primero demuestra qué regla participa. El error puede proceder de una G/L Account resuelta por posting groups que ni siquiera aparece en el documento.

Diseñar una estrategia de dimensiones

Empieza por decisiones, no por datos disponibles

Para cada dimensión propuesta, pregunta:

  • ¿Qué decisión cambia al conocer este desglose?
  • ¿Quién es propietario de los valores?
  • ¿En qué punto del proceso se conoce el valor correcto?
  • ¿Es obligatorio, derivable o editable?
  • ¿Puede cambiar después de registrar?
  • ¿Necesita una dimensión o ya existe como atributo del movimiento?

Define una matriz de asignación

Dimensión Propietario Fuente primaria Excepciones Control Global/Shortcut
DEPARTMENT Finanzas Employee/Location Repartos manuales Code Mandatory Global 1
AREA Comercial Customer Venta excepcional Same Code en Customer Global 2
PROJECT PMO Job Gastos previos autorizados Allowed values Shortcut 3
CHANNEL Marketing Document/integration Corrección manual Combinations Shortcut 4

La columna “excepciones” evita convertir un default en una obligación que el negocio no puede cumplir. La columna “propietario” evita que el catálogo crezca por generación espontánea.

Separa captura y reporting

No todas las dimensions necesarias para el data warehouse deben capturarse manualmente en Business Central. Algunas pueden derivarse de Customer, Item Category, Country/Region o Salesperson en la capa analítica. Captura en la transacción aquello que puede variar por operación o cuyo valor histórico debe congelarse.

Derivar siempre desde el maestro actual puede reescribir el pasado analítico cuando cambia la clasificación del maestro. Guardar todo como dimensión puede saturar la experiencia. El diseño correcto decide conscientemente qué atributos deben ser snapshot transaccional.

Migración y gobierno

Una migración dimensional no termina al importar tables 348 y 349.

Orden recomendado:

  1. Cargar y validar Dimension.
  2. Cargar Dimension Value y jerarquías.
  3. Configurar global/shortcut dimensions.
  4. Importar Default Dimension y allowed values.
  5. Configurar prioridades por Source Code.
  6. Configurar combinations y blocked value pairs.
  7. Construir documentos abiertos mediante APIs estándar para obtener sets válidos.
  8. Validar saldos y movimientos migrados con su dimensión efectiva.
  9. Regenerar analysis views.

No es recomendable migrar Dimension Set ID como si fuera una clave maestra compartida entre sistemas. Migra pares código-valor y deja que el entorno destino obtenga sus IDs. Los IDs son internos a la company y dependen de las combinaciones ya existentes.

Gobierno continuo

  • Alta de values con propietario y fecha efectiva.
  • Bloqueo, no reutilización, de códigos obsoletos.
  • Revisión periódica de defaults contradictorios.
  • Auditoría de Same Code y No Code, por su impacto.
  • Control de cambios sobre global dimensions.
  • Seguimiento del crecimiento de sets únicos.
  • Pruebas de posting después de añadir combinations.
  • Proceso aprobado para dimension corrections.

Estrategia de pruebas

Una prueba que confirma que Dimension Set ID <> 0 no confirma casi nada. Hay que inspeccionar el contenido.

Pruebas funcionales

  • Crear documentos con cada fuente por separado.
  • Combinar Customer/Vendor, Item, Location, Job y accounts.
  • Introducir los campos en órdenes diferentes.
  • Cambiar header después de crear lines.
  • Probar defaults iguales, distintos y vacíos.
  • Verificar las cuatro opciones de Value Posting.
  • Probar allowed values y value fuera del filtro.
  • Probar combinations Blocked y Limited.
  • Registrar y comprobar cada ledger relevante.
  • Ejecutar una correction y confirmar la divergencia esperada con subledgers.

Pruebas AL

  • Dos buffers con los mismos pares en distinto orden devuelven el mismo ID.
  • Editar una dimensión devuelve otro ID sin cambiar el conjunto original.
  • ValidateShortcutDimValues mantiene campos e ID sincronizados.
  • GetDeltaDimSetID conserva dimensions propias de la line.
  • El posting personalizado falla con Code Mandatory, Same Code, No Code y combinations inválidas.
  • Copias y reversiones conservan o recalculan según la política definida.
  • Un proceso background no intenta abrir Edit Dimension Set Entries.

Pruebas de volumen

  • Número de sets antes y después de la migración.
  • Sets nuevos por mil documentos.
  • Tiempo de creación y posting con dimensions completas.
  • Tiempo de consultas que expanden table 480.
  • Actualización de analysis views.
  • Ensayo del cambio de global dimensions en una copia representativa.

Checklist antes de producción

Modelo

Configuración

Desarrollo

Operación

La regla que lo conecta todo

Las dimensions de Business Central no son ocho columnas decorativas ni etiquetas pegadas después de registrar.

Son un sistema de clasificación con cuatro capas:

  1. Taxonomía: Dimension y Dimension Value definen el idioma.
  2. Política: defaults, priorities, allowed values y combinations definen qué se propone y qué se permite.
  3. Identidad: Dimension Set Entry y su árbol convierten una combinación en un ID reutilizable.
  4. Persistencia: documentos y ledgers transportan ese ID para conservar la fotografía analítica de cada movimiento.

Si solo entiendes la primera capa, configurarás listas. Si entiendes las cuatro, podrás explicar por qué una línea heredó un valor, por qué un posting se bloqueó, por qué dos movimientos comparten ID, por qué una correction no cambia el subledger y cómo debe comportarse una extensión sin corromper el modelo.

La regla final es esta:

No pienses en Dimension Set ID como el valor de una dimensión. Piénsalo como la huella de una combinación inmutable. Los defaults la proponen, las reglas la validan, el árbol la identifica y el posting la conserva.

Ese es el blueprint.

Referencias oficiales

Tags

You may like these posts

Post a Comment

Previous Post Next Post