BigCommerce con Dynamics NAV o AX, cuando el ERP ya tiene sucesor.

Estas salen una por una de las propias páginas de ciclo de vida de Microsoft, porque las versiones se diferencian por meses y los resúmenes que circulan por el ecosistema de socios las equivocan.

• Dynamics NAV 2016: el soporte extendido terminó el 14 de abril de 2026. Ya quedó atrás.
• Dynamics NAV 2017: el soporte extendido termina el 11 de enero de 2027. Es la fecha viva más cercana de esta página.
• Dynamics NAV 2018, la última versión de NAV: el soporte extendido termina el 11 de enero de 2028.
• Dynamics AX 2012 R3, la última versión on-premise de AX: el soporte extendido terminó el 10 de enero de 2023.

Dos de ellas merecen destacarse.

Si estás en NAV 2017, te quedan meses y no años. No es una emergencia, pero está lo bastante cerca como para que cualquier trabajo de integración planeado para este año se planee pensando en la migración, y no después de ella.

Si estás en AX, ya estás sin soporte, sea cual sea tu versión. AX 2012 R3 fue la última versión que llevó el nombre AX y salió de soporte en enero de 2023. El sucesor, Dynamics 365 Finance and Operations, es la misma línea de código con otro nombre, y Microsoft sí admite una actualización hacia él desde AX 2012 R2 o R3, que trae el X++ personalizado mediante un servicio de actualización de código y todo tu historial transaccional mediante una actualización de datos. Lo que no tienes es un AX con soporte donde quedarte mientras lo planeas, y conviene decirlo derecho: nada ha dejado de funcionar, pero tampoco se está arreglando nada.

Verifica cualquiera de estos datos en las páginas de ciclo de vida de productos de Microsoft. Si un socio te cita otra fecha, ahí se resuelve.

El instinto cuando un ERP tiene fecha de fin es congelar todo a su alrededor hasta terminar la migración. Normalmente esa es la opción cara, porque la migración se recorre y la tienda pasa dos años sin generar lo que podría.

La tienda y el ERP son decisiones separadas. Lo que la fecha de fin cambia en realidad es una sola cosa: cuánto de tu integración tiene permitido saber que está hablando con NAV o con AX.

Constrúyelo de modo que la tienda le hable a tu propia capa de integración, y esa capa le hable al ERP. Cuando NAV se convierta en Business Central, o AX en Finance and Operations, reescribes un adaptador y corres una suite de pruebas. Constrúyelo como se construyeron casi todas estas, con nombres de campo y tipos de documento del ERP repartidos por el código de la tienda, y la migración del ERP se arrastra consigo una reconstrucción completa de la tienda.

Ese es todo el argumento, y hace el proyecto más chico en vez de más grande, lo cual vale la pena decir considerando quién lo está haciendo.

NAV es el más fácil de los dos para integrar y también para migrar después, porque Business Central es genuinamente el mismo linaje y no otro producto usando el apellido de la familia.

Las vías de entrada:

• Servicios web de páginas y codeunits. La respuesta correcta. NAV expone páginas y codeunits como SOAP y, desde NAV 2013, expone páginas y consultas como OData. En NAV los codeunits son solo SOAP; llamar a uno por OData es una capacidad de Business Central, no de NAV. Publicar un codeunit escrito a propósito es mucho mejor que exponer una página estándar y confiar en que su forma no cambie.
• OData para lecturas. Directo, cacheable, y lo más parecido a una superficie moderna que tiene NAV. Prefiérelo para leer catálogo, precios y disponibilidad.
• Lecturas por SQL directo. Funcionan, con la precaución de siempre: la estructura de tablas de NAV no es un contrato público y se mueve entre versiones.
• Escrituras por SQL directo. No. La lógica de negocio de NAV vive en el código, no en la base de datos, así que escribir rodeándola produce registros que se contabilizan mal o no se contabilizan.

Por qué la migración es más amable aquí: Business Central conservó el mismo modelo de datos y la misma lógica de contabilización, y el cambio es en buena medida de C/AL a extensiones AL. Una integración de NAV construida contra servicios web publicados, y no contra las tripas de las tablas, se porta a Business Central reescribiendo el adaptador y dejando los contratos intactos. Eso no aplica en el camino de AX.

AX es el caso más difícil, por ambos lados. Las superficies de integración son más viejas y el destino está más lejos.

Las vías de entrada:

• AIF, el Application Integration Framework. El camino oficial en AX 2012, con servicios de documento y servicios personalizados sobre varios transportes. Verboso de trabajar, y sí respeta la lógica de negocio de AX, que importa más que la ergonomía.
• Servicios personalizados. Normalmente la elección pragmática: escribe un servicio que responda la pregunta concreta que hace la tienda, en vez de doblar un servicio de documento hasta esa forma.
• El .NET Business Connector. Presente en muchas integraciones viejas, obsoleto, y no algo sobre lo que construir trabajo nuevo.
• Lecturas por SQL directo. Comunes, y más riesgosas que en NAV porque el layout de tablas de AX es genuinamente hostil para quien viene de fuera, con llaves suplentes y separación de datos por compañía que es fácil equivocar de forma sutil.

Por qué la migración es más difícil: Microsoft sí la tiene herramentada, con un servicio de actualización de código que convierte el X++ existente y una actualización de datos que arrastra todo el historial transaccional. Aun así es un proyecto de actualización y no un cambio de versión, y Microsoft lo dice: describe las herramientas como un marco de trabajo y no como una solución completa, las compañías virtuales y las particiones de datos bloquean la actualización por completo, y AX 2012 RTM ni siquiera es un punto de partida admitido. El modelo de datos está reelaborado a fondo y AIF desapareció en favor de OData y el Data Management Framework, así que la superficie de integración que construiste no te acompaña. Una integración de AX tiene por tanto una vida útil más corta que una de NAV, lo que refuerza mantener la parte específica del ERP tan pequeña y aislada como se pueda.

Si esto suena al mismo argumento que hacemos sobre las aplicaciones .NET heredadas en general, es el mismo argumento. Lo escribimos en modernización de .NET heredado, y las empresas con AX suelen cargar además con varios de los otros sistemas que ahí se describen.

Las mismas seis que toda tienda B2B le pide a su ERP. Escribirlas en tu vocabulario y no en el de NAV o AX es la forma concreta de todo lo anterior, y hoy no cuesta nada.

1. Quién es este cliente. La cuenta de cliente detrás del login, más las direcciones de envío. En AX, además qué entidad legal, porque la separación de datos por compañía te va a morder si no.
2. Cuánto paga. Precios de venta y descuentos de línea en NAV, o acuerdos comerciales en AX. Más abajo.
3. Qué puede llevarse. Disponibilidad por ubicación o almacén, neta de reservas, no solo cantidad en existencia.
4. Colocar el pedido. Devolviendo el número de pedido real del ERP, no un id de la tienda con la promesa de conciliar después.
5. Dónde va. Estatus de embarque y contabilización, con rastreo donde la paquetería lo provea.
6. Cuánto debe. Facturas contabilizadas, movimientos abiertos y posición de crédito. Sigue siendo por lo que los compradores B2B entran, y sigue siendo lo último que se dimensiona.

De las tres páginas de este conjunto, el precio es lo que de verdad decide el costo de la integración, y NAV y AX caen en medio.

NAV usa precios de venta y descuentos de línea de venta, y no se resuelven por lo mismo. Los precios se resuelven por cliente, grupo de precio de cliente, campaña, todos los clientes y fecha. Los descuentos de línea se resuelven por cliente, grupo de descuento de cliente, campaña y fecha, contra un artículo o un grupo de descuento de artículos. Grupo de precio de cliente y grupo de descuento de cliente son campos distintos en la ficha del cliente, y tratarlos como uno solo es la mala configuración de precios más común que encontramos en NAV. Escalas por cantidad, unidad de medida y moneda están todas en la mezcla, y NAV toma el precio más bajo con el mayor descuento de línea permitido. Eso es más que una consulta plana y mucho menos que un cálculo completo. Para una configuración simple, sincronizar a listas de precios de BigCommerce funciona. En cuanto entran campañas y descuentos que se traslapan, pregúntale a NAV.

AX usa acuerdos comerciales, los más capaces de los dos: diarios de precio, de descuento de línea, de descuento multilínea y de descuento total, referidos a un cliente, a un grupo de precio o de descuento de cliente, o a todos los clientes, con rangos de fecha y escalas por cantidad. Las combinaciones no son intercambiables, y ahí es donde se equivoca el alcance. Un precio tiene que nombrar un artículo específico, porque un precio es un valor absoluto y no una regla. Los descuentos multilínea funcionan solo a nivel de grupo. Los descuentos de línea y multilínea sí pueden combinarse, según cómo esté configurado el parámetro de descuentos de cuentas por cobrar. Trata el precio de AX más como tratamos el de SAP: pregúntale al ERP al momento del carrito y cachea la respuesta.

La regla que aplica para ambos, y para GP:

• Catálogo y búsqueda pueden mostrar un precio cacheado o indicativo. A nadie se le factura desde una página de listado.
• Carrito, cotización y checkout tienen que ser el número vivo del ERP, porque eso es lo que se contabiliza.
• Sin precio resuelto no hay agregar al carrito. Ni NAV ni AX rechazan un pedido cuando no existe un precio específico para ese cliente. NAV recurre al precio unitario de la ficha del artículo y AX al precio base del producto liberado, o a cero si nunca se configuró. Esos pedidos se contabilizan sin problema y aparecen como un problema de margen meses después, y por eso la tienda debe bloquearlo en vez de dejar que el ERP adivine.

• La integración se construyó contra las tripas de las tablas. Va bien hasta una actualización, y luego queda silenciosamente mal. Es además lo único que convierte una migración a Business Central o F&O de reescritura de adaptador en reconstrucción.
• El contexto de compañía en AX es implícito. Alguien asumió una sola entidad legal, y la segunda produce precios y existencias equivocados con toda confianza.
• La disponibilidad ignora las reservas. Se sincroniza lo existente en vez de lo disponible, así que la tienda promete lo que ya está comprometido en otro lado.
• Los pedidos se duplican. Sin llave de idempotencia, un reintento crea un segundo pedido, descubierto en el almacén y no en el log.
• Todo pasa por un solo middleware envejecido que una sola persona entiende, en una calendarización que nadie ha revisado desde que se configuró.
• Nadie registró qué devolvió el ERP. Cuando un precio se discute meses después, no hay respuesta sobre qué dijo NAV o AX en ese momento.