BigCommerce y Dynamics GP, construido para la migración que ya sabes que viene.

Vale la pena decirlo sin rodeos, porque los resúmenes que circulan en la comunidad GP se contradicen entre sí y al menos una fecha muy citada ya fue revisada.

Si estás en GP 18.x, la versión actual bajo la Modern Lifecycle Policy:

• 31 de diciembre de 2029. Fin de mejoras de producto, actualizaciones regulatorias y fiscales, service packs y soporte técnico. Se recorrió desde el 30 de septiembre de 2029 anunciado originalmente, para que los clientes pudieran cerrar un año fiscal y de nómina completo.
• 30 de abril de 2031. Fin de las actualizaciones de seguridad, y fin de la facturación por suscripción y del uso SPLA.

Si estás en una versión más vieja, bajo la Fixed Lifecycle Policy, las fechas están mucho más cerca y dos ya pasaron:

• GP 2016 y 2016 R2: el soporte extendido terminó el 14 de julio de 2026. Eso ya quedó atrás. Si ese es tu caso, ya estás fuera de soporte.
• GP 2018 y 2018 R2: el soporte extendido termina el 11 de enero de 2028.
• GP 2015 y anteriores: hace mucho que pasaron su fin de soporte.

Un detalle que agarra desprevenida a la gente: instalar cualquier release fiscal o hotfix actual sobre GP 2018 te lleva a 18.5 o posterior, lo que te pone en la Modern Lifecycle y te da las fechas de 2029 y 2031. No hay forma soportada de tomar esas actualizaciones y quedarte en el ciclo fijo.

Fuente: la propia documentación de ciclo de vida de Dynamics GP de Microsoft. Si un socio te cita otra fecha, verifícala ahí.

Tres años o más es mucho tiempo en este negocio. Una tienda sobre GP que funciona, genera ingresos y sirve a un negocio cuya forma no ha cambiado no necesita que la empujen a nada, y no vamos a fingir lo contrario para vender un proyecto.

Pero la pregunta de la tienda es genuinamente distinta de la pregunta del ERP, y es la que la gente resuelve mal. Si integras BigCommerce pegado a GP como se construían las integraciones en 2016, entonces cuando GP se reemplace no migras un ERP: migras un ERP y además reconstruyes una integración de tienda que pagaste dos veces.

Así que la decisión que importa ahora no es cuándo dejar GP. Es cómo construir la costura. Bien hecha, la eventual mudanza a Business Central, o a lo que elijas, toca un adaptador y una corrida de pruebas. Hecha como se suele hacer, se convierte en un segundo proyecto que nadie presupuestó.

Ese es todo el argumento de esta página, y vale más para ti que para nosotros, porque hace el trabajo más chico.

BigCommerce es el extremo sencillo: APIs REST y GraphQL documentadas, webhooks, listas de precios y grupos de clientes, y B2B Edition suma cuentas de empresa y jerarquías.

GP ofrece más rutas que SAP, y difieren mucho en qué tan bien sobreviven a una migración:

• eConnect. La respuesta correcta para escribir en GP. Transaccional, validado, y respeta la lógica de negocio de GP en vez de rodearla. Si se crean pedidos en GP, normalmente es por aquí.
• Lecturas por SQL directo. Rápidas, fáciles y legítimas para leer inventario, precios y datos de clientes. Tan cómodas que la gente empieza a escribir con ellas también, y ahí dejan de ser legítimas.
• Escrituras por SQL directo. No. Saltarse la lógica de negocio de GP produce registros que se ven bien y se comportan mal, y el daño suele aparecer en el cierre de mes, no en el momento en que lo causaste.
• Web Services for Dynamics GP. Era SOAP, sigue presente en campo, rara vez la elección correcta para algo nuevo.
• SmartConnect y similares. Las herramientas de eOne están muy extendidas en el mundo GP y te resuelven buena parte del mapeo y la calendarización. Razonable, con un costo de operación real, y conviene saber que es otra cosa más que habrá que migrar después.

La vista consciente de la migración: eConnect y el SQL directo tienen forma de GP, y ninguno de los dos conceptos existe en Business Central, que usa OData y extensiones AL. Así que elijas lo que elijas, la meta es mantener esa elección contenida en un solo lugar y no dejar que se propague a la tienda.

Las mismas seis que toda tienda B2B le pide a su ERP. Escribirlas en tus términos, y no en los de GP, es lo más barato que puedes hacer hoy para que la eventual migración sea aburrida.

1. Quién es este cliente. El ID de cliente en GP detrás del login, más las direcciones de envío, que en GP son un concepto aparte que la gente olvida mapear.
2. Cuánto paga. Su nivel de precio, o su hoja de Extended Pricing si usas ese módulo. Más sobre esto abajo, porque GP es genuinamente más fácil aquí que SAP.
3. Qué puede llevarse. Cantidad disponible por sitio, no solo cantidad en existencia; y la diferencia entre asignado y en existencia importa en cuanto dos pedidos compiten.
4. Colocar el pedido. En Sales Order Processing vía eConnect, devolviendo un número de documento real de GP y no la promesa de sincronizar después.
5. Dónde va. Estatus de surtido y embarque, con rastreo donde la paquetería lo devuelva.
6. Cuánto debe. Historial de facturas, cuentas por cobrar abiertas y límite de crédito desde Receivables Management. Es la parte por la que los compradores B2B realmente entran, y consistentemente lo último que alguien dimensiona.

Si leíste nuestra página de BigCommerce y SAP, la sección de precios de allá es una advertencia. Aquí se parece más a una tranquilidad, y la diferencia es real, no retórica.

El precio estándar de GP son niveles de precio: al cliente se le asigna uno, y los artículos llevan precios por nivel y por unidad de medida. Eso es una consulta, no un cálculo, y una consulta se puede sincronizar con confianza a listas de precios y grupos de clientes de BigCommerce. Para muchos negocios con GP esa es toda la historia, y la integración sale proporcionalmente más barata que su equivalente en SAP.

Deja de ser simple cuando se activa Extended Pricing. Eso trae hojas de precios, precios con vigencia por fecha, escalas por cantidad y promociones, y empieza a parecerse a un cálculo más que a una consulta. Sigue siendo mucho más simple que la técnica de condiciones de SAP, pero ya es suficiente para que exportar un archivo plano de precios falle en las excepciones.

La regla con la que trabajamos:

• ¿Solo niveles de precio estándar? Sincronízalos. Mantén la sincronización frecuente y por eventos, y reconcilia de forma programada para que la deriva se detecte en vez de que la descubra un cliente.
• ¿Extended Pricing, precios por contrato o sobreescrituras por cliente? Pregúntale a GP al momento del carrito y cachea la respuesta, la misma disciplina que describe la página de SAP.
• En cualquier caso, sin precio no hay agregar al carrito. Si GP no tiene precio para ese cliente y artículo, deshabilítalo en vez de aceptar un pedido que va a fallar más adelante.

Vale saberlo para después: el modelo de precios de Business Central se parece más al de GP que al de SAP, así que una integración de GP construida limpiamente alrededor de “dame el precio para este cliente y este artículo” se porta sin necesidad de repensarla.

Esta es la sección para actuar aunque no contrates a nadie.

• Pon una capa de integración en medio. La tienda le habla a tu capa. Tu capa le habla a GP. Cuando el ERP cambie por debajo, reescribes un adaptador en vez de una tienda.
• Define los seis contratos en tu propio lenguaje. “Dame el precio para cliente y artículo” es una idea estable que va a sobrevivir a GP. “Llama a este procedimiento de eConnect” no.
• Mantén el vocabulario de GP fuera de la tienda. Nada de IDs de cliente con forma de GP, ni códigos de tipo de documento, ni IDs de sitio filtrándose a tu código de front-end. Mapea en la frontera. Ahora es casi gratis y después es caro.
• Registra lo que devolvió el ERP, no solo lo que enviaste. Cuando alguien discuta un precio en dieciocho meses, y lo va a hacer, la pregunta es qué dijo GP en el momento en que ese cliente miró.
• Escribe las pruebas de integración contra los contratos. Se vuelven tu suite de aceptación para la migración a Business Central, que es el mayor ahorro disponible en ese proyecto.

Nada de esto es exótico ni caro en el momento de construirlo. Todo es caro de agregar después, y por eso vale la pena plantearlo antes de que alguien escriba una propuesta.

• Alguien escribió en GP con SQL. El problema serio más común de esta categoría. Funciona en pruebas y produce registros con los que los reportes y el cierre de mes discrepan en silencio.
• Los pedidos se duplican. Sin llave de idempotencia al enviar, un reintento o un doble clic crea dos documentos en Sales Order Processing, y nadie lo nota hasta que surtido lo nota.
• El inventario promete lo que no puede embarcar. Se sincroniza lo que hay en existencia en vez de lo disponible por sitio, así que las asignaciones son invisibles para la tienda.
• Deriva de precios. Niveles sincronizados de noche, cambiados en GP a las diez de la mañana, y la tienda vende al número de ayer hasta la siguiente corrida.
• La integración es una tarea programada en la computadora de alguien. Más común de lo que se admite en el mundo GP, y deja de funcionar el día que reemplazan esa máquina.
• Supuestos con forma de GP dentro del código de la tienda. Invisibles hasta el día de la migración, cuando convierten un cambio de un adaptador en una reconstrucción.