BigCommerce con Business Central, donde el ERP se actualiza estés listo o no.

Casi toda afirmación equivocada sobre el soporte de Business Central viene de responder por un tipo de despliegue pensando en el otro. Son genuinamente distintos, así que empieza por decir en cuál estás.

Business Central en línea no tiene fecha de fin de soporte publicada. Su página de ciclo de vida de Microsoft trae solo una fecha de inicio y una fecha de retiro, y esa fecha de retiro dice "In Support". Ahí no existen columnas de fin de soporte principal ni extendido, que es justo la diferencia estructural con las páginas de NAV y GP, donde esas columnas son toda la historia. Se rige por la Modern Lifecycle Policy, que mantiene el producto con soporte mientras te mantengas actualizado, con licencia, y Microsoft lo siga ofreciendo.

Business Central local sí tiene fecha, versión por versión. Esta es la parte que más se equivoca en los resúmenes de socios. Hoy solo tres versiones locales siguen con soporte:

• v26.x se acaba el 13 de octubre de 2026. Faltan unas siete semanas y es la fecha viva más cercana de esta página.
• v27.x se acaba el 5 de abril de 2027.
• v28.x, la versión actual, se acaba el 12 de octubre de 2027.

Todo lo anterior ya quedó fuera. Trece versiones locales pasaron su fecha de fin, incluida toda la serie de la v15 a la v25 y las más viejas v13 y v14 listadas bajo la política fija.

Vale la pena entender el porqué de la división, más que memorizarla. Microsoft puede actualizar el servicio en línea por su cuenta, así que no necesita ponerle fecha. En local no puede, porque tú controlas cuándo instalas. Entonces le pone fecha a cada versión.

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

Business Central en línea recibe una actualización mayor cada abril y cada octubre, más actualizaciones menores casi todos los demás meses. La versión actual es la 28.x, que salió el 1 de abril de 2026.

Puedes diferir, pero solo dentro de una ventana, y la forma de esa ventana es justo aquello para lo que la mayoría de las integraciones no fueron construidas:

• Un periodo de actualización de cinco meses, dentro del cual un administrador puede reprogramar a cualquier fecha.
• Un periodo de gracia de un mes después de eso, cada septiembre y cada marzo, durante el cual ya no puedes empujar la fecha más lejos.
• Luego un periodo de actualización forzada. En palabras de Microsoft, las extensiones que hagan fallar la actualización "podrían desinstalarse automáticamente del entorno para que la actualización tenga éxito". Sus datos no se borran y vuelven cuando instalas una versión compatible, pero la extensión sí se quita para despejar el camino.

Lee ese último punto como integrador y no como administrador. Si tu tienda depende de una extensión por inquilino, y esa extensión no compila contra la siguiente versión mayor a tiempo, la respuesta de la plataforma es quitar tu extensión, no frenar al inquilino. No hay versión en la cual quedarse ni contrato de soporte que te compre la salida.

Así que la pregunta deja de ser cuándo tienes que moverte. Pasa a ser si tu integración puede sobrevivir un abril y un octubre, cada año, indefinidamente. Esa es una pregunta de pruebas y de propiedad, y es la que de verdad decide el costo de operar una tienda sobre Business Central.

En NAV, en AX y en GP el atajo es siempre el mismo: leer las tablas directamente. Nuestras páginas de esos tres se van casi enteras argumentando en contra. En Business Central en línea el argumento se acabó, porque la puerta no está.

Microsoft es inusualmente directo al respecto. Para Business Central en línea, la única forma admitida de leer datos es a través de APIs. El acceso directo a la base de datos no existe como opción, y Microsoft advierte explícitamente que construir una integración local que dependa de él te va a bloquear la mudanza a la nube más adelante.

Eso retira muchas cosas de golpe y en silencio. Toda extracción por ODBC. Todo reporte contra una réplica de lectura. Todo SELECT nocturno del que una tienda acabó dependiendo. Todo procedimiento almacenado con forma de eConnect, si vienes llegando de GP.

Nos parece lo mejor de la plataforma desde el punto de vista de la integración, y vale decirlo claro porque suena a restricción. Que te obliguen a pasar por un contrato publicado es exactamente el diseño que las otras tres páginas tienen que convencer a la gente de adoptar. Aquí lo obtienes lo quieras o no, y la clase de falla en la que una actualización cambia una tabla por debajo de una integración que funcionaba simplemente no ocurre.

Hay tres tipos de servicio web y no son equivalentes. Dos de ellos tienen una fecha de retiro atada a un patrón muy común.

• La API REST estándar, v2.0. Sigue siendo la versión actual y no hay una v3.0 documentada. Sirve para las entidades comunes y no requiere paso de publicación. No cubre todo, y una de sus ausencias importa lo suficiente como para tener su propia sección más abajo.
• Páginas API personalizadas, escritas en AL y enviadas en una extensión por inquilino. La respuesta correcta para todo lo que la API estándar no cubre. No se pueden mostrar en la interfaz, y ese es justo el punto: existen para ser una superficie de integración estable, no una pantalla que alguien podría rediseñar.
• OData v4 sobre páginas y consultas comunes. Funciona, pero cada endpoint hay que registrarlo a mano en la página de Servicios web y marcarlo como publicado, lo que hace que tu integración dependa de una configuración del inquilino que alguien puede apagar.
• SOAP. Obsoleto. El protocolo en sí no tiene versión de retiro anunciada, así que si alguien te da una, está adivinando.

Las dos fechas. Exponer una página publicada por Microsoft, es decir cualquier cosa de la Base Application o de las apps propias, va a dejar de servir como endpoint:

• Como endpoint SOAP, se elimina en la versión 29.0, que es la ola 2 de 2026.
• Como endpoint OData, se elimina en la versión 30.0.

Si tu tienda lee páginas estándar de Business Central como servicios web, esas son dos fechas límite duras separadas por cerca de un año, y es mucho más probable que te afecten que cualquier cosa de la página de ciclo de vida. El arreglo es el mismo en ambos casos y conviene hacerlo una sola vez: pásate a una página API personalizada dentro de tu propia extensión. La guía de Microsoft dice lo mismo por sus propias razones, que son que una página de interfaz estándar devuelve cosas que no quieres y prepara cosas que nunca pediste, y que quien la modifique no tiene idea de que tú la estabas leyendo.

Los webhooks existen y funcionan sobre páginas API. Los eventos de negocio son el mecanismo más nuevo e interesante, pero siguen documentados como versión preliminar, así que todavía no pondríamos ahí el flujo de pedidos de una tienda.

Las mismas seis que toda tienda B2B le pide a su ERP. En Business Central la plataforma ya te impuso el contrato, así que la única pregunta que queda es si ese contrato habla tu idioma o el de Microsoft.

1. Quién es este cliente. La cuenta de cliente detrás del login, más las direcciones de envío. Ojo: el precio se resuelve contra el cliente de facturación, que no siempre es quien inició sesión.
2. Cuánto paga. La parte difícil en esta plataforma. Ver más abajo.
3. Qué puede llevarse. Disponibilidad por ubicación, neta de reservas, no solo cantidad en existencia.
4. Colocar el pedido. Devolviendo el número de documento real de Business Central, 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.

Escribe esas seis en tu propio vocabulario y deja los detalles de Business Central detrás de ellas. Hoy no cuesta nada y es lo que convierte la actualización semestral en una corrida de pruebas en vez de un proyecto.

En estas cuatro páginas, el precio es lo que de verdad decide el costo de una integración. Business Central parece que debería ser el fácil y no lo es. Cae más cerca de SAP, donde el ERP tiene que calcular, que de GP, donde un nivel de precio suele sincronizarse limpio.

Dos hechos lo explican, y el segundo no lo espera nadie.

La API estándar no expone ninguna entidad de precios. No hay endpoint en la API v2.0 que te entregue un precio resuelto. Un precio en vivo requiere una página API personalizada o un codeunit que llame directamente al cálculo de precios.

El propio conector de comercio electrónico de Microsoft no exporta precios, los calcula. Ante exactamente esta pregunta para su conector de Shopify, Microsoft optó por crear una cotización de venta temporal del artículo y correr sobre ella la lógica estándar de cálculo de precios. También es franco sobre el límite del enfoque de exportación: ese conector no puede exportar precios ni descuentos que varíen por cantidad. Cuando el equipo del propio fabricante miró exportar contra calcular para una tienda real, eligió calcular.

Las reglas de abajo son pequeñas por separado y en conjunto derrotan al código ingenuo. El precio más bajo se acota por moneda y no de forma global. Un grupo de precio puede suprimir un precio más bajo de la ficha del artículo. La coincidencia de unidad de medida es inclusiva, así que una fila con unidad en blanco compite como comodín. El acuerdo se evalúa contra el cliente de facturación, no contra el comprador. Los pedidos resuelven con la fecha de pedido y las facturas con la fecha de registro. Y una fila de precio ganadora que traiga "Permitir desc. línea" apagado va a cancelar legítimamente el descuento que tu carrito iba a aplicar, que es precisamente el error que comete una tienda cuando calcula el mejor precio y el mejor descuento por separado.

Entonces la regla práctica:

• Puedes sincronizar una proyección resuelta, un catálogo por perfil de precios, pero solo donde no haya escalas por cantidad o sean enumerables, no haya campañas en juego, y conozcas la cuenta de facturación y la fecha del documento al momento de construirla. Segmenta por moneda y por si los precios incluyen IVA, o vas a cotizar mal una tienda con precios con IVA incluido.
• El carrito y el checkout deberían preguntarle a Business Central, porque en cuanto falla cualquiera de esas condiciones, y las escalas por cantidad solas bastan para hacerlo, un precio proyectado es una adivinanza.
• Sin precio no hay agregar al carrito. Deshabilítalo en vez de aceptar un pedido que va a fallar al contabilizarse.

Una cosa más a la que hay que estar atento. La nueva experiencia de precios de venta sigue siendo opcional hoy, pero Microsoft ya la señaló una vez para volverla obligatoria y luego recorrió la fecha. Trátala como un riesgo vivo en el mapa de ruta y no como asunto cerrado, y averigua qué experiencia está corriendo realmente tu inquilino antes de que alguien cotice el trabajo.

En NAV y en GP la tienda podía comportarse como un par de la base de datos. En Business Central en línea es un cliente de API con límites publicados, y esos límites son más bajos de lo que la gente supone porque se miden por usuario y no por entorno.

• 6,000 solicitudes por ventana deslizante de cinco minutos, por usuario. Al pasarte recibes un HTTP 429. Si has visto citado 600 por minuto, esa es la cifra vieja por entorno y ya quedó superada.
• Cinco solicitudes concurrentes por usuario, con otras 95 en cola y un máximo de 100 conexiones.

El número de concurrencia es el que muerde. Una tienda que llama a Business Central en vivo en cada vista de producto choca contra el muro de las cinco concurrentes mucho antes de acercarse al techo de solicitudes, y la falla no se presenta como un 429 limpio. Se presenta como solicitudes esperando en la cola, páginas que se cuelgan al renderizar y, al final, un 503. Ocurre durante un pico de tráfico, es decir, durante los minutos exactos que importaban comercialmente.

Dos consecuencias que conviene diseñar. Primera, el consejo de Microsoft ante el límite es encolar y reintentar más tarde, algo disponible para un proceso nocturno e imposible para el render de una página, así que la tienda tiene que cachear en vez de reintentar. Segunda, si de verdad necesitas holgura, la propia guía de escalamiento de Microsoft para un portal de comercio electrónico es repartir la carga entre varias identidades de aplicación, porque el límite es por usuario.

Una corrección a un consejo muy repetido: Microsoft documenta el encabezado retry-after en respuestas 502 y 503 y deliberadamente no lo documenta para 429. No construyas tu reintento asumiendo que está ahí sin comprobarlo contra tu propio inquilino.

Que es todo el argumento a favor de la división que recomendamos en todas partes: catálogo y búsqueda servidos desde datos cacheados, carrito y checkout preguntándole al ERP.

• La integración lee páginas estándar de Microsoft como servicios web. Funciona hoy y tiene fecha de retiro: versión 29.0 para SOAP y 30.0 para OData. Es lo más común que esperamos encontrar en instalaciones existentes.
• Los precios se exportaron en vez de calcularse. Va bien hasta que aparece una escala por cantidad, una campaña o un cliente de facturación distinto del comprador, y entonces queda seguro de sí mismo y equivocado, de una forma que nadie detecta hasta que se disputa una factura.
• La tienda llama al ERP en cada vista de página. Pasa las pruebas con poco tráfico, se encola y expira el día que arranca la promoción.
• Una extensión por inquilino que nadie mantiene. Hoy compila. Contra la siguiente versión mayor no compila, y el remedio de la plataforma es desinstalarla, no retrasar al inquilino.
• 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 contra un endpoint limitado crea un segundo documento, descubierto en el almacén y no en el log.
• Nadie registró qué devolvió el ERP. Cuando un precio se discute meses después, no hay respuesta sobre qué dijo Business Central en ese momento.