BC Blueprint - Posting Groups

Un análisis funcional y técnico en profundidad sobre cómo Business Central convierte clientes, proveedores, productos, IVA, almacenes, bancos, activos y proyectos en cuentas contables; qué tablas y codeunits participan; cuándo se resuelven las cuentas; qué queda grabado para siempre; y cómo evitar que una combinación inocente envíe media empresa al lugar equivocado del mayor.

Nota de versión: los nombres e identificadores de objetos, campos, procedimientos públicos y eventos de este artículo se han contrastado con la documentación pública de Microsoft disponible el 30 de agosto de 2026. La arquitectura descrita corresponde a las versiones actuales de Business Central, incluido el nuevo Invoice Posting Buffer de la tabla 55. Comprueba siempre los símbolos de la versión exacta contra la que compila tu extensión, porque el motor de registro también envejece, aunque lo haga escondido detrás de siete mil eventos.

La configuración que decide dónde termina el dinero

Business Central permite crear un pedido de venta sin seleccionar manualmente una cuenta de ingresos, una cuenta de clientes, una cuenta de IVA, una cuenta de existencias y una cuenta de coste de ventas en cada línea.

Esto es fantástico.

También significa que alguien tuvo que decidir esas cuentas antes. Ese alguien fue la configuración de posting groups, probablemente durante una implantación, delante de una matriz con cuarenta columnas y con la sensación creciente de estar intentando desactivar una bomba utilizando exclusivamente desplegables.

Los posting groups suelen explicarse así:

Sirven para indicar a qué cuentas de contabilidad se registran las operaciones.

La frase es correcta, pero se queda corta. Es como describir un reactor nuclear diciendo que calienta agua.

En realidad, los posting groups forman un sistema distribuido de clasificación y resolución de cuentas. La clasificación viaja desde los maestros hasta los documentos, se combina en varias tablas de configuración, participa en el cálculo de IVA, alimenta buffers temporales, termina en movimientos de distintos submayores y queda registrada como parte de la trazabilidad histórica.

Una factura de venta de una sola línea puede utilizar, como mínimo:

Un Customer Posting Group para la cuenta de clientes.
Un Gen. Bus. Posting Group para describir con quién se hace negocio.
Un Gen. Prod. Posting Group para describir qué se vende.
Una combinación en General Posting Setup para resolver ingresos y coste de ventas.
Un VAT Bus. Posting Group para la situación fiscal del cliente.
Un VAT Prod. Posting Group para el tratamiento fiscal del producto.
Una combinación en VAT Posting Setup para calcular el IVA y resolver su cuenta.
Un Inventory Posting Group y un Location Code para resolver la cuenta de existencias.

Ocho piezas de contexto para una línea que, visualmente, solo decía “Artículo, cantidad 1”. El ERP es una criatura reservada. No le gusta presumir.

Este artículo va a responder tres preguntas:

Qué problema funcional resuelve cada familia de posting groups.
Cómo viajan y se combinan técnicamente durante el registro.
Qué impacto tienen en contabilidad, inventario, IVA, auditoría, rendimiento y extensibilidad.

Primero, el modelo mental

Un posting group no es una cuenta contable. Es una clave de clasificación.

Una tabla de configuración de registro no es un grupo. Es una tabla de decisión que relaciona una o varias claves con cuentas y reglas.

Y registrar no significa “copiar el posting group al mayor”. Significa utilizar el contexto del documento para localizar configuración, validar cuentas, calcular importes y construir los movimientos correspondientes.

El modelo puede reducirse a cuatro preguntas:

Pregunta	Contexto	Configuración principal	Resultado típico
¿Con quién hago negocio?	`Gen. Bus. Posting Group`	`General Posting Setup`	Ingresos, compras, descuentos, COGS, ajustes y cuentas aplicadas.
¿Qué estoy vendiendo, comprando o consumiendo?	`Gen. Prod. Posting Group`	`General Posting Setup`	Completa la combinación que decide las cuentas de resultados y costes.
¿Qué submayor debe recibir la contrapartida?	`Customer Posting Group`, `Vendor Posting Group`, `Bank Account Posting Group`, `FA Posting Group`, etc.	Setup específico de la entidad	Clientes, proveedores, bancos, activos, mantenimiento, WIP de proyectos y otras cuentas de control.
¿Qué tratamiento fiscal corresponde?	`VAT Bus. Posting Group` + `VAT Prod. Posting Group`	`VAT Posting Setup`	Tipo de cálculo, porcentaje, cuentas de IVA, inversión del sujeto pasivo e información para declaraciones.

Para inventario existe además una quinta pregunta:

Pregunta	Contexto	Configuración	Resultado típico
¿Qué valor físico hay y dónde está?	`Inventory Posting Group` + `Location Code`	`Inventory Posting Setup`	Existencias, existencias provisionales, WIP y desviaciones.

La distinción importa porque evita el error conceptual más común: intentar que un único posting group explique todo.

Gen. Prod. Posting Group = RETAIL puede determinar la cuenta de ventas y de COGS cuando se combina con el negocio. No sustituye a Inventory Posting Group = RESALE, que determina la cuenta de existencias según la ubicación. Tampoco sustituye a VAT Prod. Posting Group = VAT21, que define el tratamiento fiscal.

Mismo artículo, tres ejes diferentes. Uno explica el resultado, otro el balance de inventario y otro los impuestos. Si utilizamos el mismo código para los tres puede ser por comodidad, pero el sistema no los considera la misma cosa. Son tres desconocidos vestidos igual en una película de espías.

El flujo completo en una imagen

Las rutas financiera y de inventario comparten contexto, pero materializan movimientos diferentes.

El diagrama muestra dos rutas que colaboran:

La ruta financiera del documento construye importes contables, IVA y movimientos de cliente o proveedor.
La ruta de inventario crea movimientos de cantidad, aplicación y valor. Su reflejo definitivo en contabilidad puede ser inmediato o posterior, según la configuración de costes.

Los posting groups atraviesan ambas rutas. No existe un único “posting group engine” central que reciba una factura y pronuncie una cuenta desde una nube. Cada dominio conoce sus claves, consulta su configuración y aporta una parte del asiento.

Mapa de objetos que merece la pena conocer

Tablas de grupos y matrices

ID	Objeto AL	Responsabilidad
250	`table "Gen. Business Posting Group"`	Clasifica la parte empresarial de la transacción y puede proponer el grupo de IVA empresarial.
251	`table "Gen. Product Posting Group"`	Clasifica el producto, servicio, recurso o cuenta y puede proponer el grupo de IVA de producto.
252	`table "General Posting Setup"`	Matriz `Gen. Bus.` × `Gen. Prod.` que devuelve cuentas de ventas, compras, descuentos, COGS, ajustes, prepagos, costes aplicados y otras.
92	`table "Customer Posting Group"`	Resuelve clientes, redondeos, tolerancias, intereses, recargos y descuentos relacionados con cobros.
93	`table "Vendor Posting Group"`	Resuelve proveedores, redondeos, tolerancias y descuentos relacionados con pagos.
94	`table "Inventory Posting Group"`	Clasifica el inventario. Por sí sola prácticamente solo contiene código y descripción.
5813	`table "Inventory Posting Setup"`	Matriz `Location Code` × `Invt. Posting Group Code` para existencias, provisionales, WIP y desviaciones.
277	`table "Bank Account Posting Group"`	Relaciona una cuenta bancaria de Business Central con su cuenta de mayor.
323	`table "VAT Business Posting Group"`	Clasifica la situación fiscal de cliente, proveedor o transacción.
324	`table "VAT Product Posting Group"`	Clasifica el tratamiento fiscal del bien o servicio.
325	`table "VAT Posting Setup"`	Matriz de IVA: cálculo, porcentaje, cuentas, IVA no realizado, inversión del sujeto pasivo e informes.
5606	`table "FA Posting Group"`	Determina cuentas por tipo de movimiento de activo fijo: adquisición, amortización, baja, revalorización, mantenimiento y contrapartidas.

Objetos del flujo de registro

ID	Objeto AL	Papel en la historia
80	`codeunit "Sales-Post"`	Orquesta el registro de documentos de venta y crea movimientos de clientes, artículos, recursos, activos y mayor.
90	`codeunit "Purch.-Post"`	Orquesta el registro de documentos de compra.
815	`codeunit "Sales Post Invoice"`	Implementa la interfaz `Invoice Posting` para facturas de venta.
816	`codeunit "Purch. Post Invoice"`	Implementa la interfaz `Invoice Posting` para facturas de compra.
55	`table "Invoice Posting Buffer"`	Buffer temporal que acumula y agrupa importes por cuenta, dimensiones y características de registro.
12	`codeunit "Gen. Jnl.-Post Line"`	Motor central que crea movimientos de mayor, cliente, proveedor, IVA y registros auxiliares desde el contexto de diario general.
22	`codeunit "Item Jnl.-Post Line"`	Crea `Item Ledger Entry`, `Value Entry`, aplicaciones y el resto de la arquitectura de inventario.

Un detalle importante para desarrolladores: la antigua table 49 "Invoice Post. Buffer" está eliminada desde la versión 27.0. El modelo actual utiliza table 55 "Invoice Posting Buffer", que es temporal y trabaja con Group ID, tipo de línea, cuenta, dimensiones, grupos y cantidades. Si una extensión todavía busca la tabla 49 como si nada hubiera pasado, no está haciendo arqueología; está intentando invocar a un objeto muerto.

Una factura de venta, desmontada pieza por pieza

Vamos a utilizar un ejemplo simplificado:

Cliente

Campo	Valor
`Customer Posting Group`	`DOMESTIC`
`Gen. Bus. Posting Group`	`NATIONAL`
`VAT Bus. Posting Group`	`NATIONAL`

Artículo

Campo	Valor
`Gen. Prod. Posting Group`	`RETAIL`
`VAT Prod. Posting Group`	`VAT21`
`Inventory Posting Group`	`RESALE`

Documento

Ubicación: MAIN.
Importe neto: 1.000 EUR.
IVA: 21 %, es decir, 210 EUR.
Coste del artículo: 600 EUR.

Configuración relevante

Setup	Combinación	Cuenta resuelta
`Customer Posting Group`	`DOMESTIC`	`Receivables Account = 430000`
`General Posting Setup`	`NATIONAL` × `RETAIL`	`Sales Account = 700000`
`General Posting Setup`	`NATIONAL` × `RETAIL`	`COGS Account = 610000`
`VAT Posting Setup`	`NATIONAL` × `VAT21`	`VAT % = 21`, `Sales VAT Account = 477000`
`Inventory Posting Setup`	`MAIN` × `RESALE`	`Inventory Account = 300000`

El resultado conceptual de una factura completamente valorada sería:

Cuenta	Debe	Haber	Origen de la decisión
Clientes `430000`	1.210		`Customer Posting Group`
Ventas `700000`		1.000	`General Posting Setup`
IVA repercutido `477000`		210	`VAT Posting Setup`
Coste de ventas `610000`	600		`General Posting Setup`
Existencias `300000`		600	`Inventory Posting Setup`

La tabla demuestra por qué “¿qué posting group usa la factura?” es una pregunta incompleta. Usa varios, porque está respondiendo a varias preguntas contables diferentes.

También contiene una trampa temporal: los movimientos de ingresos, cliente e IVA pertenecen a la factura. Los movimientos definitivos de COGS e inventario proceden de la arquitectura de costes y de los Value Entry. Si el coste todavía es esperado, se ajusta más tarde o Automatic Cost Posting no está activo, el momento exacto en que aparecen las cuentas definitivas puede ser diferente.

La doble partida sigue cuadrando. Solo que algunas de sus piezas viajan en trenes distintos y una de ellas tiene costumbre de llegar después.

Familia 1: General Posting Groups, la matriz del “quién” y el “qué”

`Gen. Business Posting Group`: con quién estamos haciendo negocio

table 250 "Gen. Business Posting Group" suele asignarse a clientes, proveedores y determinadas cuentas de mayor. Funcionalmente puede representar:

Nacional, Unión Europea y exportación.
Venta minorista, mayorista o intercompany.
Particulares y empresas.
Cualquier separación empresarial que realmente deba conducir a cuentas diferentes.

La última frase es el filtro importante. Si la empresa solo quiere analizar ventas por región, pero todas deben ir a la misma cuenta, probablemente estamos ante una dimensión, no ante la necesidad de multiplicar posting groups.

La tabla contiene, entre otros, estos campos:

Code.
Description.
Def. VAT Bus. Posting Group.
Auto Insert Default.

El grupo general puede proponer el grupo de IVA empresarial. Esa relación reduce errores de mantenimiento, pero no fusiona ambos conceptos. NATIONAL puede ser a la vez el código general y el código de IVA, aunque continúan viviendo en tablas distintas y participan en matrices distintas.

`Gen. Product Posting Group`: qué estamos moviendo económicamente

table 251 "Gen. Product Posting Group" suele asignarse a artículos, recursos, cargos de producto, cuentas de mayor y otros maestros que pueden ocupar una línea.

Ejemplos habituales:

RETAIL para mercancía de reventa.
RAW para materia prima.
SERVICE para servicios.
RESOURCE para capacidad o trabajo.
NONINV para productos no inventariables.

Sus campos Def. VAT Prod. Posting Group y Auto Insert Default permiten proponer el tratamiento fiscal de producto. De nuevo: propuesta no significa identidad.

`General Posting Setup`: aquí aparecen las cuentas

table 252 "General Posting Setup" tiene como clave funcional la combinación:

Gen. Bus. Posting Group × Gen. Prod. Posting Group

Para esa combinación puede almacenar:

Sales Account y Sales Credit Memo Account.
Purch. Account y Purch. Credit Memo Account.
Cuentas de descuento de línea y factura.
Cuentas de descuento y tolerancia de pago.
COGS Account y COGS Account (Interim).
Inventory Adjmt. Account.
Invt. Accrual Acc. (Interim).
Cuentas de prepagos.
Direct Cost Applied Account.
Direct Cost Non-Inv. App. Acc..
Overhead Applied Account.
Purchase Variance Account.
Purch. FA Disc. Account.

No todos los campos son visibles por defecto en la página. La aplicación oculta cuentas poco frecuentes y filtra los lookups por categoría. View All Accounts on Lookup y las acciones de la página permiten acceder al resto. Que una columna no esté en la rejilla no significa que haya dejado de participar en el universo.

La combinación es exacta, no un comodín

Una fila con Gen. Bus. Posting Group vacío no significa “cualquier negocio”. Vacío es un valor concreto utilizado en determinadas operaciones cuyo contexto empresarial realmente está vacío.

No diseñes la matriz esperando una resolución jerárquica de este estilo:

NATIONAL × RETAIL
if missing -> blank × RETAIL
if missing -> NATIONAL × blank
if missing -> blank × blank

Ese no es el contrato general. Las rutinas estándar conocen la combinación que necesitan y esperan encontrar la configuración correspondiente. Una línea vacía puede ser necesaria, pero no es un asterisco con capa.

La explosión combinatoria

Si tienes 8 grupos empresariales y 12 grupos de producto, la matriz potencial contiene 96 combinaciones. Con 20 y 30, contiene 600.

No todas deben existir si el negocio nunca las utiliza, pero cada combinación válida debe estar configurada. Por eso los códigos deben modelar diferencias reales de contabilización, no todos los atributos que alguien quiera poner después en un gráfico.

Regla práctica:

Si cambia la cuenta o el comportamiento de registro, considera un posting group.
Si solo cambia cómo quieres analizar el mismo movimiento, considera una dimensión.
Si cambia el impuesto, utiliza el eje fiscal correspondiente.
Si cambia la ubicación física del valor, revisa inventario y Location Code.

Cuando se utilizan posting groups como dimensiones improvisadas, la matriz crece como una planta alimentada con residuos radiactivos. Al principio parece vigorosa. Después ocupa el edificio.

Familia 2: VAT Posting Groups, una matriz independiente porque Hacienda no acepta metáforas

La arquitectura de IVA repite el patrón “quién” × “qué”, pero sus consecuencias son fiscales:

VAT Bus. Posting Group × VAT Prod. Posting Group -> VAT Posting Setup

`VAT Business Posting Group`

table 323 "VAT Business Posting Group" clasifica la situación fiscal de la parte empresarial. Puede distinguir, según país y localización:

Operaciones nacionales.
Operaciones intracomunitarias.
Exportaciones.
Sujetos exentos o regímenes especiales.
Casos de inversión del sujeto pasivo.

`VAT Product Posting Group`

table 324 "VAT Product Posting Group" clasifica el tratamiento fiscal del bien o servicio:

Tipo general.
Tipo reducido.
Tipo superreducido.
Exento.
Servicios con reglas específicas.

`VAT Posting Setup`

table 325 "VAT Posting Setup" combina ambos códigos y define mucho más que un porcentaje:

VAT Calculation Type.
VAT %.
Sales VAT Account.
Purchase VAT Account.
Cuentas de IVA no realizado.
Reverse Chrg. VAT Acc..
VAT Identifier.
EU Service.
VAT Clause Code.
Códigos de declaración de venta y compra.
Configuración de IVA no deducible.
Blocked.

El mismo grupo de producto VAT21 puede tener un 21 % en operaciones nacionales y un tratamiento de inversión del sujeto pasivo en otra combinación empresarial. Esa es la razón de la matriz: el producto no tiene toda la respuesta y el cliente tampoco.

Los grupos generales pueden proponer los de IVA, pero no los sustituyen

Es posible relacionar:

Gen. Business Posting Group con Def. VAT Bus. Posting Group.
Gen. Product Posting Group con Def. VAT Prod. Posting Group.

Esto ayuda a mantener maestros y documentos coherentes. Sin embargo, el motor continúa utilizando los campos VAT específicos para calcular y registrar impuestos.

Por eso una combinación general correcta no salva una combinación de IVA inexistente. La cuenta de ventas puede estar feliz mientras la factura falla porque NATIONAL × VAT21 no existe en VAT Posting Setup. Dos matrices, dos posibles incendios.

Métodos públicos de resolución

La tabla expone procedimientos como:

VATPostingSetup.GetSalesAccount(Unrealized);
VATPostingSetup.GetPurchAccount(Unrealized);
VATPostingSetup.GetRevChargeAccount(Unrealized);

Estos procedimientos seleccionan entre cuentas realizadas y no realizadas y validan la configuración. También existen eventos como OnBeforeGetSalesAccount y OnBeforeGetPurchAccount.

Eso no convierte cada factura en una invitación a decidir la cuenta mediante un suscriptor que consulta la fase lunar. La extensibilidad existe, pero la trazabilidad fiscal agradece que la regla siga siendo explícita, estable y auditable.

Familia 3: grupos específicos y cuentas de control

Los grupos generales explican ingresos, compras y costes. Los grupos específicos conectan un submayor con sus cuentas de control.

`Customer Posting Group`

table 92 "Customer Posting Group" contiene Receivables Account y otras cuentas para:

Descuentos y tolerancias de pago.
Redondeo de facturas.
Redondeos de aplicación y divisa.
Recargos por servicio.
Intereses y costes adicionales de recordatorios.

La cuenta de clientes no procede de General Posting Setup. Procede de este grupo.

La tabla encapsula la resolución mediante métodos como:

CustomerPostingGroup.GetReceivablesAccount();
CustomerPostingGroup.GetPmtDiscountAccount(Debit);
CustomerPostingGroup.GetPmtToleranceAccount(Debit);
CustomerPostingGroup.GetRoundingAccount(Debit);
CustomerPostingGroup.GetApplRoundingAccount(Debit);
CustomerPostingGroup.GetInvRoundingAccount();

El movimiento Cust. Ledger Entry conserva el Customer Posting Group utilizado. Los movimientos detallados también mantienen el contexto necesario para aplicaciones, descuentos, tolerancias y diferencias de cambio.

`Vendor Posting Group`

table 93 "Vendor Posting Group" es el equivalente para proveedores. Su campo principal es Payables Account, acompañado de cuentas de descuentos, tolerancias, redondeos y gastos.

Métodos como GetPayablesAccount(), GetPmtDiscountAccount() y GetApplRoundingAccount() permiten recuperar las cuentas aplicando las validaciones estándar.

El movimiento Vendor Ledger Entry conserva el Vendor Posting Group utilizado. Esto importa cuando se aplican pagos, se ajustan divisas o se reconstruye la historia de una operación.

`Bank Account Posting Group`

table 277 "Bank Account Posting Group" es deliberadamente sencilla:

Code -> G/L Account No.

La cuenta bancaria operativa genera Bank Account Ledger Entry; el posting group determina la cuenta espejo en contabilidad.

Microsoft recomienda que estas cuentas de mayor tengan Direct Posting = false. La razón no es estética: si los usuarios registran directamente contra la cuenta contable del banco, pueden crear saldo en mayor sin movimiento bancario asociado. Después la conciliación mira ambos saldos, suspira y empieza a redactar su carta de despedida.

La misma regla conceptual se aplica a cuentas de control de clientes, proveedores e inventario: si una cuenta debe reconciliarse con un submayor, permitir movimientos directos rompe la relación.

Grupos alternativos

Business Central permite grupos alternativos para clientes, proveedores y empleados cuando se habilita Allow Multiple Posting Groups en la configuración correspondiente y en el maestro.

El flujo es explícito:

Se activa la funcionalidad en Sales & Receivables Setup, Purchases & Payables Setup o Human Resources Setup.
Se definen los grupos permitidos como alternativas.
Se habilita el uso de múltiples grupos en el cliente, proveedor o empleado.
El usuario puede seleccionar una alternativa permitida en el documento o diario.

La alternativa se copia al documento registrado y sus cuentas se utilizan para la contrapartida. Si se aplica una factura y un pago registrados con grupos diferentes —y por tanto con cuentas de control distintas— Business Central genera la transferencia necesaria entre las cuentas para mantener el equilibrio.

No es un “campo editable porque sí”. Es una excepción gobernada. Y esa diferencia separa una funcionalidad útil de una fiesta contable sin adultos.

Familia 4: Inventory Posting Group y la segunda vida de los costes

table 94 "Inventory Posting Group" apenas contiene código y descripción. Las cuentas viven en table 5813 "Inventory Posting Setup", cuya combinación es:

Location Code × Invt. Posting Group Code

La ubicación forma parte de la clave porque la empresa puede querer cuentas de existencias distintas por almacén, planta, país o régimen operativo.

Cuentas principales de `Inventory Posting Setup`

Inventory Account.
Inventory Account (Interim).
WIP Account.
Material Variance Account.
Capacity Variance Account.
Mfg. Overhead Variance Account.
Cap. Overhead Variance Account.
Subcontracted Variance Account.
Mat. Non-Inv. Variance Acc..

Sus procedimientos públicos incluyen GetInventoryAccount(), GetInventoryAccountInterim(), GetWIPAccount() y los getters de desviaciones.

Cantidad y valor no son el mismo movimiento

Una operación de inventario crea dos capas principales:

Cantidad, representada por Item Ledger Entry y enlazada mediante Item Application Entry.
Valor, representado por uno o varios Value Entry relacionados con el movimiento de artículo o de capacidad.

codeunit 22 "Item Jnl.-Post Line" crea y coordina estas entradas. En una compra puede existir un Value Entry de coste directo y otro de coste indirecto. En una venta, el coste puede propagarse desde la entrada aplicada. En producción aparecen WIP, capacidad, indirectos y desviaciones.

El inventario financiero no se decide leyendo solo el artículo. Para una compra valorada, por ejemplo:

La cuenta de existencias viene de Inventory Posting Setup, utilizando ubicación e inventory posting group.
La contrapartida Direct Cost Applied Account viene de General Posting Setup, utilizando los grupos generales.
El coste indirecto puede utilizar Overhead Applied Account.
Una desviación de compra puede utilizar Purchase Variance Account.

Una misma partida de valor cruza dos configuraciones. Si solo revisas una, estás investigando la mitad del crimen.

Coste esperado y coste real

Con Expected Cost Posting to G/L, los costes esperados utilizan cuentas provisionales:

Inventory Account (Interim).
Invt. Accrual Acc. (Interim).
COGS Account (Interim).

Cuando llega la factura y el coste se convierte en real, las entradas provisionales se revierten y aparecen las definitivas.

Con Automatic Cost Posting desactivado, los Value Entry pueden existir sin que el valor se haya llevado todavía al mayor. En ese caso se utiliza Post Inventory Cost to G/L, preferiblemente después de Adjust Cost - Item Entries.

El proceso manual calcula la diferencia entre:

Cost Amount (Actual) - Cost Posted to G/L

y, si corresponde:

Cost Amount (Expected) - Exp. Cost Posted to G/L

Cuando se registra por grupo, la agregación utiliza la combinación de fecha, Gen. Bus. Posting Group, Gen. Prod. Posting Group, Inventory Posting Group, Location Code y signo. Por eso esos campos permanecen en Value Entry: no son decoración histórica, son el contexto que permite resolver y agrupar el registro posterior.

La relación final entre Value Entry y G/L Entry queda en G/L - Item Ledger Relation.

Producción y ensamblado

En producción, el mapa crece:

La salida puede enfrentar Inventory Account con WIP Account.
La capacidad utiliza WIP contra Direct Cost Applied Account y Overhead Applied Account.
Las desviaciones de material, capacidad, overhead y subcontratación proceden de Inventory Posting Setup.
Los grupos generales pueden venir de la orden de producción, el producto terminado, el componente, el centro de trabajo o el proveedor de subcontratación, según la parte del asiento.

En ensamblado no se utiliza el mismo concepto de WIP que en producción y los costes se registran como reales. Las cuentas siguen repartiéndose entre Inventory Posting Setup y General Posting Setup.

Este es el punto en el que una tabla de posting groups deja de parecer una configuración contable y revela su verdadera forma: una red logística-financiera con tentáculos.

Familia 5: activos fijos, proyectos y dominios especializados

`FA Posting Group`

table 5606 "FA Posting Group" no es una matriz sencilla de dos ejes. Es un catálogo de cuentas por tipo de movimiento del activo:

Coste de adquisición y contrapartida.
Amortización acumulada y gasto de amortización.
Deterioro, revalorización y operaciones personalizadas.
Cuentas utilizadas durante la baja.
Ganancias y pérdidas por enajenación.
Mantenimiento y su contrapartida.

El grupo efectivo se mantiene por libro de amortización en FA Depreciation Book. Esto permite que distintos libros representen finalidades contables o fiscales diferentes.

Una compra de activo fijo puede implicar simultáneamente:

Vendor Posting Group para proveedores.
Grupos generales para determinados importes y descuentos.
Grupos de IVA.
FA Posting Group para el coste de adquisición.

Una línea, cuatro universos. Business Central no desperdicia oportunidades para introducir otra tabla de configuración.

Project o Job Posting Groups

La interfaz moderna habla de Projects, mientras muchos objetos AL conservan Job por compatibilidad. El campo continúa llamándose Job Posting Group en objetos como Job y Job Task.

Su función es conectar proyectos y tareas con cuentas de WIP, costes aplicados, ventas acumuladas, costes reconocidos y otras contrapartidas del ciclo de proyecto. El grupo puede establecerse por defecto en Jobs Setup y modificarse en proyecto o tarea.

Lo importante no es memorizar cada campo, sino reconocer el patrón: cada submayor especializado añade su propio contexto, pero termina generando movimientos de mayor mediante el mismo ecosistema de registro.

De los maestros al documento: valores predeterminados, validación e instantáneas

Los posting groups comienzan normalmente en los maestros:

Cliente o proveedor: grupos empresarial, específico e IVA.
Artículo o recurso: grupos de producto, inventario e IVA.
Cuenta bancaria: grupo bancario.
Activo y libro de amortización: grupo de activo.
Proyecto o tarea: grupo de proyecto.

Al validar entidades en un documento, Business Central copia esos valores a la cabecera y las líneas.

En ventas, el contexto financiero suele seguir al cliente de facturación (Bill-to Customer). En compras, al proveedor de pago (Pay-to Vendor). La parte logística puede seguir a Sell-to, Ship-to, Buy-from o Order Address, pero quien recibe la mercancía y quien mantiene la deuda no tienen por qué ser la misma entidad.

El documento contiene una fotografía editable

Una vez copiados, los grupos viven en el documento abierto. Esto tiene varias consecuencias:

Cambiar el posting group del maestro no garantiza que documentos ya creados se actualicen.
Revalidar el cliente, proveedor, artículo o tipo de línea puede volver a calcular campos relacionados.
El documento puede permitir cambios explícitos, sujetos a validaciones y permisos.
El documento registrado conserva los grupos utilizados en sus cabeceras, líneas y movimientos.

Pero hay una segunda fotografía, tomada más tarde:

Los códigos de posting group suelen estar ya copiados en el documento.
Las cuentas se resuelven desde las tablas de configuración durante el registro.

Por tanto, cambiar el grupo de un cliente y cambiar la cuenta dentro de Customer Posting Group no tienen el mismo efecto:

Si cambias el grupo del maestro, una factura abierta puede seguir conservando el grupo anterior.
Si mantienes el código, pero cambias su Receivables Account antes de registrar, el documento puede resolver la cuenta nueva al registrar.
Los movimientos ya registrados no cambian porque edites la configuración después.

Esta diferencia es esencial en despliegues. Un cambio de configuración no reescribe el pasado, pero puede cambiar el futuro de documentos que ya estaban esperando en la cola.

El registro por dentro

1. `Sales-Post` y `Purch.-Post` preparan el documento

codeunit 80 "Sales-Post" y codeunit 90 "Purch.-Post" realizan comprobaciones, copian líneas a tablas temporales, calculan cantidades, coordinan expedición o recepción, crean documentos registrados y llaman a los procesadores financieros y de inventario.

La copia temporal importa. El motor no recorre ingenuamente la tabla de líneas y va improvisando asientos. Prepara un contexto coherente que puede dividir importes, gestionar cargos de producto, descuentos, prepagos, tracking, proyectos, activos y redondeos.

2. La implementación de `Invoice Posting` construye el buffer

Sales Post Invoice (815) y Purch. Post Invoice (816) implementan la interfaz Invoice Posting.

Cada importe registrable se convierte en una entrada conceptual del Invoice Posting Buffer:

Cuenta de mayor resuelta.
Tipo de línea de registro.
Grupos generales e IVA.
Importes base, IVA y divisa adicional.
Dimensiones.
Deferral code y contexto de proyecto o activo cuando corresponde.

La tabla 55 utiliza Group ID para agrupar importes compatibles. Dos líneas que apuntan a la misma cuenta, con las mismas dimensiones y características relevantes, pueden acumularse. Si cambia una dimensión, una cuenta, un tratamiento fiscal o una propiedad que forme parte de la clave lógica, deben permanecer separadas.

Esto explica por qué el número de líneas del documento no coincide necesariamente con el número de G/L Entry. El buffer resume contablemente, no fotocopia visualmente.

3. El buffer se convierte en `Gen. Journal Line`

Invoice Posting Buffer expone eventos como:

OnAfterBuildPrimaryKey.
OnAfterCopyToGenJnlLine.
OnAfterCopyToGenJnlLineFA.
OnAfterSetAccount.

La conversión crea el contexto de Gen. Journal Line que consumirá el motor general. Los posting groups continúan presentes porque el registro de IVA, dimensiones, descripciones y submayores todavía los necesita.

4. `Gen. Jnl.-Post Line` materializa la doble partida

codeunit 12 "Gen. Jnl.-Post Line" es el núcleo financiero para una línea de diario general. Valida y crea:

G/L Entry.
Cust. Ledger Entry y movimientos detallados.
Vendor Ledger Entry y movimientos detallados.
VAT Entry.
Movimientos bancarios y registros auxiliares según el tipo de cuenta.
G/L Register y relaciones necesarias.

No significa que todo Business Central registre exclusivamente con una línea de diario visible. Significa que los módulos convierten su contexto especializado a una forma que el motor financiero entiende.

5. `Item Jnl.-Post Line` materializa cantidad y valor

Cuando existen líneas de artículo, codeunit 22 "Item Jnl.-Post Line" crea los movimientos de inventario y valor. El posterior reflejo financiero utiliza las claves conservadas en Value Entry para consultar General Posting Setup e Inventory Posting Setup.

Los dos recorridos completos se parecen a esto:

Los posting groups sobreviven como contexto porque algunas cuentas se resuelven durante el registro del documento y otras durante el traslado posterior de costes.

Dos flujos, varias matrices y suficientes oportunidades para que una celda vacía arruine una tarde perfectamente razonable.

La resolución de cuentas en AL

Las tablas de configuración contienen procedimientos de obtención que validan las cuentas y, en algunos casos, publican eventos de extensibilidad. Una versión reducida de un resolvedor diagnóstico podría verse así:

using Microsoft.Bank.BankAccount;
using Microsoft.Finance.GeneralLedger.Setup;
using Microsoft.Finance.VAT.Setup;
using Microsoft.Inventory.Item;
using Microsoft.Sales.Customer;

codeunit 50120 "Posting Account Inspector"
{
    procedure ResolveSalesAccounts(
        GenBusPostingGroup: Code[20];
        GenProdPostingGroup: Code[20];
        VATBusPostingGroup: Code[20];
        VATProdPostingGroup: Code[20];
        CustomerPostingGroupCode: Code[20];
        InventoryPostingGroupCode: Code[20];
        LocationCode: Code[10];
        var SalesAccount: Code[20];
        var ReceivablesAccount: Code[20];
        var SalesVATAccount: Code[20];
        var InventoryAccount: Code[20];
        var COGSAccount: Code[20])
    var
        GeneralPostingSetup: Record "General Posting Setup";
        VATPostingSetup: Record "VAT Posting Setup";
        CustomerPostingGroup: Record "Customer Posting Group";
        InventoryPostingSetup: Record "Inventory Posting Setup";
    begin
        GeneralPostingSetup.Get(
            GenBusPostingGroup,
            GenProdPostingGroup);

        VATPostingSetup.Get(
            VATBusPostingGroup,
            VATProdPostingGroup);

        CustomerPostingGroup.Get(CustomerPostingGroupCode);

        InventoryPostingSetup.Get(
            LocationCode,
            InventoryPostingGroupCode);

        SalesAccount := GeneralPostingSetup.GetSalesAccount();
        COGSAccount := GeneralPostingSetup.GetCOGSAccount();
        ReceivablesAccount := CustomerPostingGroup.GetReceivablesAccount();
        SalesVATAccount := VATPostingSetup.GetSalesAccount(false);
        InventoryAccount := InventoryPostingSetup.GetInventoryAccount();
    end;
}

Este código no reproduce el registro estándar. No considera crédito, coste esperado, IVA no realizado, redondeos, descuentos, tipos de línea, activos, proyectos, divisa, dimensiones ni signo. Su valor es enseñar la separación de responsabilidades.

En código de producción, no crees un motor paralelo de account determination porque quieres conocer cinco cuentas. Deja que el proceso estándar registre. Para diagnósticos o validaciones previas, utiliza los getters de las tablas y replica únicamente el contrato exacto que necesitas.

¿Por qué getters y no leer el campo directamente?

Esto:

SalesAccount := GeneralPostingSetup."Sales Account";

parece equivalente a:

SalesAccount := GeneralPostingSetup.GetSalesAccount();

Pero el método puede validar la cuenta, emitir un error más útil y ejecutar eventos de extensibilidad. El acceso directo evita ese contrato.

No todos los campos tienen un método de obtención y no toda lectura requiere uno, pero si Base Application expone un procedimiento específicamente para recuperar una cuenta de posting, úsalo salvo que tengas una razón muy buena para no hacerlo. “Era una línea menos” no es una razón muy buena.

Qué queda guardado después de registrar

Los posting groups sobreviven al documento abierto en distintas tablas:

Sales Invoice Header, Sales Invoice Line, Purch. Inv. Header y sus equivalentes registrados conservan grupos relevantes.
Cust. Ledger Entry conserva Customer Posting Group.
Vendor Ledger Entry conserva Vendor Posting Group.
Bank Account Ledger Entry conserva Bank Acc. Posting Group.
FA Ledger Entry conserva FA Posting Group.
G/L Entry conserva grupos generales y de IVA que permiten análisis y trazabilidad.
VAT Entry conserva el contexto fiscal.
Value Entry conserva las claves necesarias para el registro y conciliación de inventario.

La cuenta utilizada también queda fijada en G/L Entry. Editar General Posting Setup mañana no mueve el asiento de ayer. Esto protege la historia, pero también significa que corregir una configuración no corrige automáticamente los movimientos equivocados.

La reparación normalmente requiere:

Revertir y volver a registrar, si el documento y el periodo lo permiten.
Emitir abono y nueva factura.
Crear una reclasificación controlada cuando la operación original no puede revertirse.
Ajustar IVA o inventario mediante sus procesos específicos, no mediante una línea creativa lanzada directamente contra una cuenta de control.

La corrección debe respetar el submayor afectado. Un asiento de mayor puede hacer que el balance parezca correcto y dejar clientes, inventario o IVA incorrectos. Pintar el salpicadero no repara el motor.

Impacto funcional: mucho más que escoger una cuenta

Estados financieros

Los grupos determinan la clasificación de ingresos, compras, gastos, inventario, WIP, desviaciones, clientes y proveedores. Una mala combinación puede alterar:

Cuenta de resultados.
Balance.
Márgenes.
Aging de clientes y proveedores frente a sus cuentas de control.
Inventario valorado frente a contabilidad.
Resultado por línea de negocio o país.

IVA e informes legales

VAT Posting Setup controla porcentaje, tipo de cálculo, cuenta, identificadores, cláusulas y códigos de declaración. Un error puede producir un asiento que cuadra matemáticamente y una declaración fiscal incorrecta. Es la clase más peligrosa de error: la que no grita.

Costing

Los grupos de inventario y generales determinan dónde se registran costes directos, indirectos, esperados, reales y desviaciones. Una inconsistencia puede crear diferencias en Inventory - G/L Reconciliation o distribuir el margen entre cuentas equivocadas.

Operación y bloqueo

Si falta una combinación, el documento puede registrarse parcialmente en algunas capas temporales pero la transacción completa terminará en error y reversión completa de la transacción. Si la configuración está bloqueada, no debe utilizarse para nuevas operaciones. Si una cuenta no permite registro o está bloqueada, el método de obtención o el motor termina fallando.

Los errores de configuración de registro no suelen significar que el codeunit de ventas esté roto. Con frecuencia significan que el documento ha alcanzado una combinación que nadie declaró válida. El mensajero no siempre es el asesino.

Rendimiento y volumen de movimientos

Los posting groups influyen en la agrupación del buffer y de procesos como Post Inventory Cost to G/L. Más combinaciones, dimensiones y diferencias de contexto pueden generar más movimientos de mayor.

Eso no justifica mezclar operaciones distintas para ahorrar líneas. Sí justifica diseñar grupos con intención y entender por qué el mayor contiene diez movimientos donde el documento tenía cien líneas, o cien donde alguien esperaba diez.

Errores habituales y lo que realmente significan

“General Posting Setup does not exist”

La combinación exacta de Gen. Bus. Posting Group y Gen. Prod. Posting Group no existe para la operación.

Comprueba:

Los grupos almacenados en la cabecera y línea, no solo los actuales del maestro.
El tipo de línea: artículo, recurso, cuenta, cargo o activo pueden aportar grupos diferentes.
El contexto de producción, proyecto o inventario que genera la línea de diario interna.
Si uno de los grupos está vacío y existe la combinación vacía exacta.

“VAT Posting Setup does not exist”

La combinación fiscal no existe. Revisar General Posting Setup no va a arreglarla, aunque ambos códigos tengan el mismo texto y nos miren desde páginas casi idénticas.

Inspecciona los campos VAT reales del documento y la línea.

Falta `Inventory Posting Setup`

La combinación de Location Code e Inventory Posting Group no existe. Es común al abrir una nueva ubicación y asumir que hereda mágicamente las cuentas de la anterior.

Una ubicación nueva no solo necesita bins y trabajadores con chaleco. También necesita su cobertura contable.

El documento usa un grupo antiguo

El grupo fue copiado cuando se creó o validó el documento. Cambiar el maestro después no actualizó el documento abierto.

Compara:

Maestro actual.
Cabecera actual.
Línea actual.
Documento registrado o movimientos, si ya se registró.

El asiento utiliza una cuenta nueva aunque el documento sea antiguo

El código de grupo estaba copiado, pero la cuenta de la fila de configuración cambió antes del registro. La resolución se realizó con la configuración vigente en ese momento.

Clientes cuadra, pero la cuenta de control no

Busca movimientos directos en la cuenta de clientes, cambios de grupos alternativos, aplicaciones entre grupos distintos, diferencias de divisa o una configuración incorrecta de Receivables Account.

Inventario valorado no cuadra con mayor

Revisa, en este orden:

Adjust Cost - Item Entries.
Costes no registrados en mayor.
Automatic Cost Posting y Expected Cost Posting to G/L.
Value Entry y campos Cost Posted to G/L.
G/L - Item Ledger Relation.
Inventory - G/L Reconciliation.
Movimientos directos en cuentas de inventario.

No empieces cambiando el saldo de la cuenta 300000. Eso es apagar el detector de humo para concentrarse mejor.

La cuenta de ventas es correcta, pero el IVA no

Las matrices general y fiscal son independientes. Revisa VAT Calculation Type, porcentaje, identificador, IVA no deducible, cláusula y códigos de declaración de la combinación VAT.

Un cargo de producto usa grupos inesperados

Los item charges tienen sus propios grupos y, durante el registro, parte de su contexto puede transferirse a las líneas temporales que distribuyen el coste. Inspecciona el maestro del cargo, la asignación y las líneas temporales en depuración. El artículo original no es necesariamente la única fuente.

Cómo depurar un problema de posting groups sin perder la voluntad de vivir

Paso 1: Preview Posting

Utiliza Preview Posting antes de registrar. La vista previa ejecuta el flujo en modo de simulación y permite inspeccionar movimientos que se crearían sin confirmar la transacción.

Comprueba por separado:

G/L Entry.
Cust. Ledger Entry o Vendor Ledger Entry.
VAT Entry.
Item Ledger Entry y Value Entry cuando corresponda.

Paso 2: identifica la cuenta incorrecta y pregunta qué familia la controla

Cuenta incorrecta	Primera configuración que revisar
Ingresos o compras	`General Posting Setup`
Cliente	`Customer Posting Group`
Proveedor	`Vendor Posting Group`
IVA	`VAT Posting Setup`
Banco	`Bank Account Posting Group`
Existencias o WIP	`Inventory Posting Setup`
COGS o ajuste	`General Posting Setup`
Activo fijo	`FA Posting Group`
WIP de proyecto	`Job Posting Group` / configuración de proyecto

Empezar por la familia correcta elimina el 80 % del ruido. El otro 20 % suele estar escondido en una línea de redondeo con una dimensión diferente, porque el software también necesita aficiones.

Paso 3: inspecciona el contexto del documento

No mires solo las cards de cliente y artículo. Inspecciona los campos reales de Sales Header, Sales Line, Purchase Header, Purchase Line, Gen. Journal Line o Item Journal Line.

En depuración, observa:

Customer/Vendor Posting Group
Gen. Bus. Posting Group
Gen. Prod. Posting Group
VAT Bus. Posting Group
VAT Prod. Posting Group
Inventory Posting Group
Location Code
Dimension Set ID

Paso 4: inspecciona la fila exacta de configuración

Haz el Get() mental o real con la combinación exacta. Comprueba:

Que existe.
Que no está bloqueada.
Que la cuenta está informada.
Que la cuenta existe y permite el uso esperado.
Que Direct Posting tiene el valor correcto.
Que el tipo y categoría de cuenta son coherentes.

Paso 5: baja al buffer

Si la cuenta resuelta parece correcta pero el resultado está agrupado de forma extraña, inspecciona Invoice Posting Buffer:

Group ID.
Type.
G/L Account.
Grupos generales e IVA.
Importes y base de IVA.
Dimension Set ID o dimensiones incluidas.
Contexto de deferrals, proyecto y activo.

Paso 6: sigue las relaciones históricas

Después del registro utiliza:

G/L Register.
Find Entries o navegación de movimientos.
Movimientos de cliente o proveedor y sus movimientos detallados.
VAT Entry.
Item Ledger Entry, Value Entry y G/L - Item Ledger Relation.

La cuenta final es el resultado. Los grupos conservados son las pistas. El registro es una novela policiaca escrita enteramente en tablas con claves compuestas.

Diseño de una estrategia de posting groups

Diseña desde los asientos, no desde los códigos

Antes de crear grupos, documenta los asientos esperados por escenario:

Venta nacional de mercancía.
Venta intracomunitaria de servicio.
Compra de materia prima.
Compra de activo fijo.
Recepción pendiente de factura.
Venta con coste esperado.
Producción y desviaciones.
Proyecto con WIP.
Cobro, descuento y diferencia de cambio.
Baja y mantenimiento de activo.

Para cada cuenta del asiento identifica su propietario:

Cuenta -> Familia de registro -> Campos de origen -> Clave exacta de configuración

Después crea los códigos. Hacerlo al revés produce grupos llamados GROUP1, GROUP2 y OTHER, los tres jinetes del apocalipsis de la mantenibilidad.

Usa nombres semánticos y estables

Un código debería expresar el motivo contable o fiscal:

DOMESTIC, EU, EXPORT.
RETAIL, SERVICE, RAW.
VAT21, VAT10, EXEMPT.
RESALE, RAW-MAT, FINISHED.

Evita incluir una cuenta concreta en el código si puede cambiar. SALES-700000 convierte una modificación legítima del plan contable en una mentira permanente.

Minimiza combinaciones sin ocultar diferencias reales

No se trata de tener pocos grupos a cualquier precio. Se trata de que cada diferencia tenga una justificación:

¿Cambia la cuenta?
¿Cambia el tratamiento fiscal?
¿Cambia el submayor?
¿Cambia la ubicación financiera del stock?
¿Cambian los informes legales?

Si todas las respuestas son no, probablemente no necesitas otro posting group.

Separa el análisis de la determinación de cuentas

Usa dimensiones para departamento, centro de coste, campaña, región comercial o proyecto analítico cuando la cuenta no deba cambiar.

Los posting groups determinan comportamiento. Las dimensiones describen el movimiento. Mezclarlos crea una matriz enorme y aun así deja el análisis pobre.

Protege las cuentas de control

Configura Direct Posting = false en cuentas que deban recibir exclusivamente movimientos desde submayores o procesos automáticos:

Clientes.
Proveedores.
Bancos.
Inventario y WIP.
IVA cuando el proceso fiscal deba gobernar todos los movimientos.
Activos, según el diseño contable.

La finalidad es mantener reconciliación y trazabilidad, no castigar a usuarios que disfrutan demasiado de los diarios generales.

Migración, despliegue y gobierno

Los posting groups son datos de configuración, pero forman parte de la arquitectura de la solución. Deben tratarse como dependencias versionadas.

Orden de despliegue

Un despliegue seguro suele respetar este orden:

Plan de cuentas.
Grupos maestros.
Matrices de configuración de registro.
Configuraciones generales que activan funcionalidades.
Plantillas y valores por defecto.
Maestros.
Documentos abiertos.
Validación mediante vista previa y escenarios de prueba.

Importar maestros antes que las combinaciones necesarias crea registros aparentemente completos que fallan cuando llega el primer usuario con entusiasmo.

No copies solo las filas visibles

Al mover configuración entre empresas o entornos incluye:

Todos los campos de cuentas, también los ocultos en la página.
Combinaciones con grupo empresarial vacío cuando se utilicen.
Todas las ubicaciones relevantes en Inventory Posting Setup.
Cuentas provisionales y de desviaciones.
IVA no realizado, inversión del sujeto pasivo y códigos de declaración.
Grupos alternativos y flags que habilitan su uso.

Control de cambios

Un cambio en la configuración de registro puede afectar inmediatamente a documentos pendientes. Aplica gobierno proporcional al riesgo:

Permisos limitados para modificar la configuración.
Change Log en tablas críticas cuando el volumen lo permita.
Revisión de cambios por Finanzas.
Exportación o instantánea antes de cambios masivos.
Prueba en sandbox con documentos representativos.
Registro de fecha efectiva y motivo del cambio.
Revisión explícita de documentos abiertos y job queues.

No hace falta crear un comité de siete personas para cambiar una descripción. Sí conviene saber quién cambió Receivables Account diez minutos antes de un registro masivo.

Extensibilidad: dónde tocar y dónde mantener las manos en los bolsillos

Las tablas de configuración publican eventos alrededor de la obtención y validación de cuentas. Ejemplos actuales:

General Posting Setup expone eventos OnBeforeGet... para varias cuentas.
Customer Posting Group expone OnAfterGetReceivablesAccount.
VAT Posting Setup expone OnBeforeGetSalesAccount y OnBeforeGetPurchAccount.
Invoice Posting Buffer expone eventos de creación de clave, actualización y copia a Gen. Journal Line.
Los codeunits de ventas, compras, diario general e inventario contienen numerosos eventos de frontera.

Elige el punto de extensión más pequeño

Si necesitas almacenar un atributo adicional que modifica la agrupación del asiento:

Extiende el origen para transportar el dato.
Extiende el buffer si debe formar parte de la agregación.
Participa en la construcción de Group ID mediante el evento adecuado.
Copia el dato al contexto final mediante un evento documentado.
Prueba que movimientos incompatibles no se agregan.

Si solo modificas Gen. Journal Line al final, dos importes que debían permanecer separados pueden haberse agrupado ya. Cambiar la etiqueta de la caja después de mezclar su contenido no vuelve a separar las piezas.

Evita account determination invisible

Es técnicamente posible sustituir una cuenta mediante eventos según cliente, usuario, hora o cualquier condición. El coste arquitectónico es alto:

La página de configuración deja de explicar el resultado.
Preview, soporte y auditoría necesitan conocer código oculto.
Dos documentos con los mismos grupos pueden acabar en cuentas diferentes.
El análisis histórico pierde una clave explícita para explicar la decisión.

Cuando una diferencia es estable y empresarial, modela un posting group o una dimensión adecuada. Utiliza eventos para reglas que no pueden expresarse limpiamente en configuración, no para convertir la contabilidad en una aventura de texto interactiva.

No insertes `G/L Entry` directamente

El motor de registro coordina numeración, registros, IVA, submayores, dimensiones, divisa adicional, trazabilidad y consistencia. Insertar directamente en G/L Entry evita esos contratos.

Para operaciones personalizadas, construye documentos, diarios o contratos de posting soportados y llama a los codeunits públicos apropiados. Si tu solución inserta seis tablas manualmente para “hacer lo mismo que registrar”, no has evitado complejidad. La has clonado sin las pruebas de Microsoft.

Estrategia de pruebas

Una configuración de posting groups debe probarse como una matriz de reglas, no como una colección de páginas bonitas.

Casos funcionales mínimos

Factura y abono de venta por combinación empresarial y de producto.
Factura y abono de compra.
Descuento de línea, descuento de factura y redondeo.
Pago con descuento, tolerancia y diferencia de cambio.
IVA normal, exento e inversión del sujeto pasivo cuando aplique.
IVA no deducible y no realizado si están habilitados.
Recepción sin factura y factura posterior.
Expedición sin factura y coste posterior.
Ajuste positivo, negativo, transferencia y revalorización.
Todas las ubicaciones con todas las familias de inventario válidas.
Compra, amortización, mantenimiento y baja de activos.
Proyecto con consumo, facturación, cálculo y registro de WIP.
Producción con material, capacidad, overhead y desviaciones.
Posting groups alternativos y aplicación entre cuentas de control distintas.
Registro en job queue con la misma configuración que el registro interactivo.

Aserciones técnicas

No valides solamente que “no hubo error”. Comprueba:

Números de cuenta de G/L Entry.
Importes y signos.
Gen. Bus. Posting Group y Gen. Prod. Posting Group almacenados.
Grupos de IVA y VAT Entry.
Cuenta de control frente a Cust. Ledger Entry o Vendor Ledger Entry.
Item Ledger Entry, Value Entry y coste aplicado.
Relación G/L - Item Ledger Relation.
Dimension Set ID.
Número de movimientos cuando la agrupación es relevante.
Ausencia de movimientos si se ejecuta la vista previa.
Rollback completo ante una combinación inexistente.

Prueba el cambio, no solo el estado final

Incluye escenarios temporales:

Crea un documento.
Cambia el grupo del maestro.
Comprueba si el documento conserva su instantánea.
Cambia la cuenta de la configuración.
Ejecuta la vista previa.
Verifica qué configuración utiliza.

Este caso demuestra mejor que veinte diapositivas la diferencia entre valor predeterminado, documento y resolución en el momento del registro.

Checklist de revisión antes de producción

Estructura

Cada grupo tiene una finalidad documentada.
Los grupos no duplican dimensiones sin necesidad.
Todas las combinaciones válidas existen.
Las combinaciones inválidas no se han creado “por si acaso”.
Los grupos generales y VAT están relacionados mediante defaults cuando corresponde.

Cuentas

Las cuentas existen, no están bloqueadas y tienen el tipo correcto.
Las cuentas de control tienen Direct Posting = false cuando corresponde.
Están configuradas cuentas de abono, descuento, tolerancia y redondeo si las funcionalidades están activas.
Están configuradas cuentas provisionales si se registra coste esperado.
Existen cuentas de desviación para escenarios de producción reales.

Inventario

Cada ubicación operativa tiene combinaciones con los grupos de inventario que puede recibir.
Adjust Cost - Item Entries está programado con la frecuencia necesaria.
Automatic Cost Posting y Expected Cost Posting to G/L responden al diseño contable.
Inventory - G/L Reconciliation se revisa periódicamente.

IVA

Cada combinación utilizada tiene cálculo, porcentaje y cuentas correctas.
Se han validado códigos de declaración, cláusulas e identificadores.
Se han probado crédito, descuento, redondeo y divisas.
Las particularidades de la localización están cubiertas.

Operación

Preview Posting produce los asientos esperados.
Los documentos abiertos se revisan tras cambios de configuración.
Los cambios están gobernados y auditados.
Los tests cubren las combinaciones de mayor riesgo.

La regla que lo conecta todo

Los posting groups no existen para evitar que el usuario escriba una cuenta. Existen para convertir una operación empresarial en un registro repetible, coherente y auditable.

La arquitectura separa deliberadamente varias decisiones:

Con quiénGen. Bus. Posting Group

QuéGen. Prod. Posting Group

SubmayorSpecific Posting Group

ImpuestosVAT Bus. Posting Group + VAT Prod. Posting Group

InventarioInventory Posting Group + Location Code

Después, los motores especializados transforman esas decisiones en cuentas:

Las cuentas se materializan durante el registro; la clasificación queda disponible para explicar el resultado.

El valor funcional está en que ventas, compras, inventario y finanzas utilizan reglas comunes. El valor técnico está en que la resolución se encuentra en tablas y procedimientos extensibles. El riesgo está en que una fila de configuración puede afectar miles de operaciones sin cambiar una sola línea de AL.

Por eso posting groups no es “tema de funcionales” ni “tema de contabilidad”. Es arquitectura de producto expresada como datos.

Trátalos como código:

Diseña contratos.
Controla dependencias.
Prueba combinaciones.
Versiona cambios.
Revisa efectos laterales.
Conserva trazabilidad.

Y, sobre todo, recuerda que NATIONAL × RETAIL no es una pareja de códigos simpáticos. Es una decisión contable esperando a que alguien pulse Post.

En ese momento Business Central dejará de preguntar, consultará sus matrices y hará exactamente lo que configuramos.

Lo cual es tranquilizador hasta que recordamos quién configuró las matrices.

BC Blueprint - Posting Groups

BC Blueprint - Posting Groups

La configuración que decide dónde termina el dinero

Primero, el modelo mental

El flujo completo en una imagen

Mapa de objetos que merece la pena conocer

Tablas de grupos y matrices

Objetos del flujo de registro

Una factura de venta, desmontada pieza por pieza

Cliente

Artículo

Documento

Configuración relevante

Familia 1: General Posting Groups, la matriz del “quién” y el “qué”

Gen. Business Posting Group: con quién estamos haciendo negocio

Gen. Product Posting Group: qué estamos moviendo económicamente

General Posting Setup: aquí aparecen las cuentas

La combinación es exacta, no un comodín

La explosión combinatoria

Familia 2: VAT Posting Groups, una matriz independiente porque Hacienda no acepta metáforas

VAT Business Posting Group

VAT Product Posting Group

VAT Posting Setup

Los grupos generales pueden proponer los de IVA, pero no los sustituyen

Métodos públicos de resolución

Familia 3: grupos específicos y cuentas de control

Customer Posting Group

Vendor Posting Group

Bank Account Posting Group

Grupos alternativos

Familia 4: Inventory Posting Group y la segunda vida de los costes

Cuentas principales de Inventory Posting Setup

Cantidad y valor no son el mismo movimiento

Coste esperado y coste real

Producción y ensamblado

Familia 5: activos fijos, proyectos y dominios especializados

FA Posting Group

Project o Job Posting Groups

De los maestros al documento: valores predeterminados, validación e instantáneas

El documento contiene una fotografía editable

El registro por dentro

1. Sales-Post y Purch.-Post preparan el documento

2. La implementación de Invoice Posting construye el buffer

3. El buffer se convierte en Gen. Journal Line

4. Gen. Jnl.-Post Line materializa la doble partida

5. Item Jnl.-Post Line materializa cantidad y valor

La resolución de cuentas en AL

¿Por qué getters y no leer el campo directamente?

Qué queda guardado después de registrar

Impacto funcional: mucho más que escoger una cuenta

Estados financieros

IVA e informes legales

Costing

Operación y bloqueo

Rendimiento y volumen de movimientos

Errores habituales y lo que realmente significan

“General Posting Setup does not exist”

“VAT Posting Setup does not exist”

Falta Inventory Posting Setup

El documento usa un grupo antiguo

El asiento utiliza una cuenta nueva aunque el documento sea antiguo

Clientes cuadra, pero la cuenta de control no

Inventario valorado no cuadra con mayor

La cuenta de ventas es correcta, pero el IVA no

Un cargo de producto usa grupos inesperados

Cómo depurar un problema de posting groups sin perder la voluntad de vivir

Paso 1: Preview Posting

Paso 2: identifica la cuenta incorrecta y pregunta qué familia la controla

Paso 3: inspecciona el contexto del documento

Paso 4: inspecciona la fila exacta de configuración

Paso 5: baja al buffer

Paso 6: sigue las relaciones históricas

Diseño de una estrategia de posting groups

Diseña desde los asientos, no desde los códigos

Usa nombres semánticos y estables

Minimiza combinaciones sin ocultar diferencias reales

Separa el análisis de la determinación de cuentas

Protege las cuentas de control

Migración, despliegue y gobierno

Orden de despliegue

`Gen. Business Posting Group`: con quién estamos haciendo negocio

`Gen. Product Posting Group`: qué estamos moviendo económicamente

`General Posting Setup`: aquí aparecen las cuentas

`VAT Business Posting Group`

`VAT Product Posting Group`

`VAT Posting Setup`

`Customer Posting Group`

`Vendor Posting Group`

`Bank Account Posting Group`

Cuentas principales de `Inventory Posting Setup`

`FA Posting Group`

1. `Sales-Post` y `Purch.-Post` preparan el documento

2. La implementación de `Invoice Posting` construye el buffer

3. El buffer se convierte en `Gen. Journal Line`

4. `Gen. Jnl.-Post Line` materializa la doble partida

5. `Item Jnl.-Post Line` materializa cantidad y valor

Falta `Inventory Posting Setup`

No insertes `G/L Entry` directamente