Cómo añadir una segunda fecha a las facturas de proveedor en Business Central sin tocar la contabilidad

Cualquier consultor de Business Central que haya trabajado con un cliente en el SII se ha topado con la pregunta tarde o temprano: «¿se puede añadir un campo de fecha extra a las facturas de proveedor? El controller necesita registrar cuándo ocurrió realmente el gasto, además de la fecha que va a Hacienda».

La respuesta corta es sí, se puede. La respuesta larga es: hay tres caminos posibles y solo uno de ellos es razonable a largo plazo. Este artículo es para consultores funcionales y key users que evalúan cómo resolverlo en su instalación.

Por qué Business Central estándar no permite dos fechas

El campo Posting Date en Business Central es la fuente única de verdad para varias tablas críticas: G/L Entry, VAT Entry, Item Ledger Entry, Customer Ledger Entry, Vendor Ledger Entry. Cualquier modificación de ese campo impacta simultáneamente en periodo fiscal, conciliación bancaria, declaración del SII, modelos AEAT, y todos los reportes legales que usen el periodo contable.

Por eso BC no expone “una segunda fecha contable” en sus tablas estándar. Sería arquitectónicamente peligroso: cualquier confusión entre las dos fechas podría romper la consistencia con Hacienda. La decisión de Microsoft es coherente: una fecha por asiento, y punto.

La solución, entonces, no es modificar Posting Date. Es añadir una fecha analítica paralela, sin impacto contable ni fiscal, en una extensión que añade el campo nuevo sin tocar el original.

Las 3 vías clásicas (con su trade-off)

Opción A · Usar el campo Description 2 o External Document No. ⚠️ MAL

Cómo se hace: el usuario tipea la fecha real en el campo Description 2 de la cabecera de la factura, o en External Document No., o en cualquier campo de texto libre que esté infrautilizado.

Por qué falla:

• No es indexable como fecha — Business Central trata el contenido como texto.
• No permite filtrar listados por rango (no se puede pedir «todas las facturas con fecha analítica entre marzo y mayo»).
• Los reportes nativos no la entienden — para Power BI es una columna string, no date.
• El usuario puede escribir formatos inconsistentes (05/2026, mayo, 2026-05-15, 15-5-26…) y nadie los normaliza.

Cuándo se usa: nunca, salvo emergencias puntuales del tipo «hoy no puedo instalar nada y necesito anotar algo». Como solución estructural, es un parche que pronto deja de funcionar.

Opción B · Crear una dimensión global “Fecha analítica” ⚠️ REGULAR

Cómo se hace: en Setup → General Ledger Setup se crea una dimensión global con valores tipo 2026-01, 2026-02, 2026-03, etc. (granularidad mensual). Después se asigna manualmente en cada documento desde el campo de dimensión.

Ventajas:

• Se puede filtrar y agrupar en los reportes nativos de Account Schedules y Analysis by Dimensions.
• Power BI la ve como categoría (no ideal, pero usable).
• No requiere extensión: se hace con configuración estándar.

Problemas:

• Granularidad mensual (no día). Pierdes precisión en cierres trimestrales o semanales.
• El usuario tiene que escribirla a mano en cada factura. Sin automatismo desde el albarán o parte previo.
• Power BI ve la dimensión como categoría de texto, no como tipo Date real. No puedes hacer cálculos temporales (mes anterior, año anterior) sin transformaciones adicionales.
• Si tienes 5.000 facturas/año, alguien tiene que crear y mantener los valores de dimensión mes a mes. Cuando llega 2027, alguien crea los 12 nuevos valores. Y cuando se confunde y crea 2027-13 en lugar de 2027-12, nadie lo detecta hasta el cierre.
• Dimensiones globales en BC tienen un coste de rendimiento si se llenan en muchas tablas. No es ideal para alto volumen.

Cuándo tiene sentido: empresas con menos de 500 facturas/año, sin SII, donde el problema es ocasional. Como solución cuádruple optimizada para alto volumen no funciona.

Opción C · Extensión AL nativa ✅ LA BUENA

Cómo se hace: se instala una app desde AppSource que añade un nuevo campo Analytic Date (tipo Date) en las cabeceras y líneas de los documentos de compra, venta, asiento manual y movimiento de stock. El campo se rellena automáticamente desde la fecha del documento previo (albarán, parte de servicio, certificación) cuando existe; manualmente cuando no.

Ventajas:

• Es tipo Date nativo de BC. Indexable, filtrable, exportable a Power BI como dimensión temporal real.
• Toma automática desde el documento previo: si la factura de compra deriva de un albarán con Receipt Date = 2026-04-15, la extensión rellena Analytic Date = 2026-04-15 por defecto. Sin doble tecleo.
• No toca Posting Date — la contabilidad oficial sigue intacta. Hacienda y SII reciben exactamente lo mismo que antes.
• Granularidad diaria, no mensual.
• Sin mantenimiento adicional. Las fechas se rellenan solas.

Cuándo tiene sentido: cualquier empresa con SII, cualquier flujo donde el albarán o parte llega antes que la factura, cualquier instalación con más de 500 facturas/año donde la opción B no escala.

Por ejemplo, dvdata-analysis implementa esta vía para Microsoft Dynamics 365 Business Central, certificada con denominación Co-sell por Microsoft.

Captura: cómo se ve la fecha analítica en una factura de proveedor

En la cabecera de la factura, junto al campo estándar Posting Date, aparece un nuevo campo Analytic Date. La extensión muestra debajo del campo el documento previo desde el que se autocompletó (típicamente «Auto desde Receipt 2026-04-15 — albarán RCP-1234»). El usuario puede hacer override manual con un click si la fecha real es distinta a la del documento previo.

(Captura de pantalla pendiente — ver dvda-screenshot-purchase-invoice.png en /public/blog/)

Qué tablas modifica la extensión (alcance funcional)

Para tener cobertura completa, una extensión bien hecha debe añadir el campo Analytic Date en todas las tablas donde se generan asientos contables:

Tabla BC	Campo añadido	Origen del autorelleno
Purch. Invoice Header	Analytic Date	Receipt Date del albarán de compra
Sales Invoice Header	Analytic Date	Shipment Date del albarán de venta
Gen. Journal Line	Analytic Date	Manual o template del journal
Item Journal Line	Analytic Date	Document Date del movimiento
Job Ledger Entry	Analytic Date	Work Date del parte de proyecto
Service Ledger Entry	Analytic Date	Service Date del parte de servicio
Purch. Cr. Memo Hdr.	Analytic Date	Mismo que la factura original
Sales Cr. Memo Header	Analytic Date	Mismo que la factura original

Si la extensión solo cubre Purch. Invoice Header y se olvida del Item Journal Line, los reportes de costes por proyecto siguen siendo inconsistentes. La cobertura tiene que ser completa.

Cómo navegar el ERP por fecha analítica

Una vez instalada la extensión, el cambio en el día a día del usuario funcional es mínimo:

• Listados estándar: aparece un nuevo filtro “Analytic Date” en Posted Purchase Invoices, G/L Entries, Item Ledger Entries, etc. El usuario puede aplicarlo igual que cualquier otro filtro de fecha.
• Reports nativos: cualquier report que use Posting Date admite ahora Analytic Date como campo alternativo desde el RDLC. Algunos reports clave (Trial Balance by Period, Account Schedules) deberían recibir variantes que filtren por la nueva fecha.
• Power BI: el conector estándar de BC expone la columna analytic_date lista para usar como dimensión temporal en lugar de —o junto a— posting_date.

Power BI: el cambio que más se nota

El cambio se nota inmediatamente en Power BI. La mayoría de mediciones de cierre mensual están atadas a Posting Date. Con la extensión, se pueden duplicar las medidas en una versión “por fecha analítica”:

// Medida original
Ingresos por fecha factura =
    CALCULATE(SUM(GLEntry[Amount]), GLEntry[Account Type] = "Income")

// Medida nueva
Ingresos por fecha devengo =
    CALCULATE(SUM(GLEntry[Amount]),
              GLEntry[Account Type] = "Income",
              USERELATIONSHIP(GLEntry[Analytic Date], DateTable[Date]))

En un dashboard del comité financiero esto se traduce en un toggle o dos curvas superpuestas: ventas por fecha factura vs ventas por fecha devengo. La diferencia entre ambas curvas a final de año tiende a cero (los desfases se compensan), pero mes a mes la diferencia es significativa. El CFO ve ambas y decide cuál usa para qué decisión: la del SII para el reporting fiscal, la del devengo para la gestión interna.

¿Cuánto tarda implantar dvdata-analysis?

• Instalación: instantánea. Es una app de AppSource. El usuario administrador la instala con un click en Extension Management.
• Configuración inicial: una sesión de 1 hora con un consultor para definir, por cada flujo, qué fecha de origen usar para el autorelleno (albarán de compra → fecha de recepción; parte de servicio → fecha de servicio; certificación → fecha de emisión; etc.).
• Formación: autoformación 24/7 desde el primer día con materiales en español.
• Día siguiente al pago: el equipo financiero está usando la fecha analítica en el cierre.

Para un caso típico (empresa de servicios profesionales o industria con subcontratas), el ROI se nota en el primer cierre mensual completo: desaparece el Excel paralelo del controller y la cuenta de resultados de gestión refleja la realidad operativa del mes.

Las preguntas que hacen siempre los consultores

¿La extensión es compatible con todas las versiones de BC?

Sí. Funciona en Cloud y On-Premise sobre todas las versiones soportadas por Microsoft, incluyendo el “Modern Lifecycle” actual. Las actualizaciones automáticas de BC no rompen la extensión: Davisa publica una nueva versión compatible antes de cada release mayor de BC.

¿Modifica el código fuente de Business Central?

No. Es una extensión AL pura: añade tablas, campos y páginas sin tocar el código base de BC. Microsoft lo certifica como Co-sell precisamente porque cumple con el modelo de extensiones AL recomendado.

¿Puedo desinstalarla sin perder datos?

Sí. Al desinstalar, los campos Analytic Date desaparecen pero la contabilidad oficial sigue intacta porque la extensión nunca tocó Posting Date. Recuperar los datos analíticos requeriría reinstalar y re-vincular, pero los movimientos contables originales no se ven afectados.

¿Se actualiza con cada versión nueva de BC?

Sí, automáticamente. Davisa mantiene la extensión alineada con las versiones de BC publicadas por Microsoft. Cuando hay una release mayor (W1, W2 al año), Davisa publica una nueva versión de dvdata-analysis compatible antes de que la actualización de BC sea obligatoria. La actualización se aplica en background sin intervención del usuario.

En resumen

• BC estándar usa una sola fecha por movimiento (Posting Date) que cumple a la vez función fiscal, contable y analítica. Es coherente, pero deja sin resolver el desfase fecha factura ↔ fecha devengo.
• Hay tres vías para añadir una fecha analítica adicional:
  • A: campo de texto libre tipo Description 2 → no funciona como solución estructural.
  • B: dimensión global → funciona en empresas pequeñas, no escala.
  • C: extensión AL nativa → la única recomendable para cualquier empresa con SII o con flujo albarán→factura habitual.
• La extensión bien hecha cubre Purch., Sales, Gen. Journal, Item Journal, Job Ledger y Service Ledger. Cobertura parcial = reportes inconsistentes.
• Power BI gana inmediatamente: medidas duplicadas «por fecha factura» vs «por fecha devengo» que se comparan side-by-side.
• Implantación: 1 día (instalación instantánea + sesión de 1 hora de configuración + autoformación).

¿Eres consultor de BC y quieres probar la extensión en sandbox?

Si quieres ver dvdata-analysis funcionando en un sandbox de BC antes de proponérselo a tu cliente, podemos darte acceso a una instalación de prueba. Agenda una conversación rápida con el equipo técnico de Davisa.

Solicitar acceso a sandbox →