Sana Commerce sobre Business Central, más allá del folleto.

Toda página que leíste abre con la misma afirmación: tiempo real, sin sincronización, sin middleware. Es exacta para el lado del pedido y no es el cuadro completo para el catálogo, y la propia guía de administración de Sana es donde te enteras.

Sana publica una tabla de caché por defecto para datos del ERP. Los datos en caché son, en palabras de Sana, "product details, prices and stock". Detalles de producto, listas de producto, datos masivos de producto, el carrito y el historial de pedidos vienen por defecto en veinte minutos. El menú del sitio, en sesenta.

Aparte, el catálogo de la tienda no se lee del ERP en absoluto. Lo construye una tarea programada de importación de productos que mantiene un índice, y Sana indica que "Webstore search functionality, sorting and filtering of products, phonetic search and product sets configuration depends on the product information that is indexed."

Así que el modelo exacto es este. Los precios específicos por cliente, impuestos, cargos, crédito y validación del pedido se calculan en vivo en Business Central al momento del carrito y del checkout. Todo lo que navegas, buscas y filtras es un índice que se refresca según una programación. Ambas mitades importan, y solo una está en el folleto.

Sana es franco sobre el porqué, y esa parte vale citarla completa porque te dice qué tipo de decisión estás tomando: "Performance of your application will drop when the duration is set less. This is because the amount of calls to your ERP system will increase, which is much slower then retrieving the cache." La ortografía es de ellos.

Eso replantea la pregunta para tu proyecto. No es si la integración es en tiempo real. Es qué tan fresca necesita ser tu visualización de stock y precio, porque eso es una perilla con un costo de rendimiento documentado del otro lado. Si vendes inventario escaso donde una cifra de stock de veinte minutos causa un problema real, esa es una conversación para antes del contrato, no para las pruebas de aceptación.

Sana Commerce Cloud se describe como SaaS que se actualiza solo, y por separado como personalizable. La propia documentación de Sana dice que son alternativas y no compañeras: "Customizing Sana Commerce Cloud using the SDK means abandoning SaaS and thus no automatic upgrades."

La línea cae en dónde se hace el trabajo. Sana indica que "custom projects cannot be automatically updated to a newer Sana version because customizations are done in the Sana core code", y que "If all customizations can be done using the extension points of Sana, you can still receive updates automatically."

Lo que convierte a una pregunta en la más consecuente de cualquier conversación de alcance con Sana, y hay que hacerla sobre cada requerimiento de la lista:

• Te mueves a una rama de soporte de largo plazo que no recibe actualizaciones automáticas.
• Arranca un reloj de soporte. Sana soporta activamente una versión del framework durante tres años desde su lanzamiento, y luego pasivamente dos más, con el soporte pasivo limitado a hotfixes de problemas críticos y, en palabras de Sana, "always on time and material".
• Pierdes la administración autoservicio. En proyectos personalizados, los usuarios "need to contact their Sana Commerce representative" para instalar una app que un cliente estándar instala solo desde Sana Admin.

Sana no documenta ninguna ruta de regreso de un proyecto personalizado a la vía estándar. No nos consta que exista, y querríamos eso por escrito antes de que alguien firme.

No eres dueño de ninguno de los dos calendarios de versiones, y hay más de los que suele contemplar un proyecto.

• El framework de Sana sale más o menos cada dos semanas, y su despliegue tarda hasta dos semanas después de la fecha de lanzamiento. Eso no lo programas tú.
• El conector de ERP de Sana va en su propio tren, más o menos trimestral.
• Las apps de Sana se versionan por separado otra vez.
• Microsoft saca una actualización mayor de Business Central cada abril y cada octubre, y avanza a la fuerza la extensión instalada. No existe una configuración que fije una app de AppSource durante una ola mayor.

Sana incluye una opción de Compatibility Level dentro de Business Central justamente para absorber el desfase entre su conector y la versión de Microsoft de abajo, lo que te dice que el desfase es esperado y no excepcional.

También hay una obligación contractual que normalmente no sale en la etapa comercial, y vale leerla completa: "All standard Sana Commerce Cloud customers have the obligation in their license agreement to update the Sana ERP connector at least every two years." Sana no documenta ninguna consecuencia por incumplirla en ningún lado que hayamos encontrado, así que no vamos a inventar una. Pero es una obligación que estás firmando, y existe porque la dirección sin soporte es un conector viejo contra un framework más nuevo.

Una corrección a algo que quizá leíste, incluido un borrador anterior de nuestro propio análisis. Una actualización forzada de Business Central no deja a un cliente Cloud en estado sin soporte. Hay una excepción para Business Central Cloud, y la obligación de actualizar el conector cada dos años es justo el mecanismo que previene la falla que la gente teme. Los hechos operativos reales son más acotados y aun así vale planearlos: una ola aplicada con éxito no se puede revertir, las extensiones que bloquean una actualización forzada pueden desinstalarse automáticamente, y el ensayo realista contra tus propios datos no empieza hasta la disponibilidad general, salvo que tu socio tenga una licencia de Partner Sandbox, que sí da acceso anticipado.

Estar en AppSource se lee como autoservicio. La extensión por sí sola no hace nada: un sistema funcionando necesita un entorno Sana contratado por separado, y en Business Central local la extensión no se puede obtener sin un socio de Sana.

Lo que sí aterriza en tu tenant conviene saberlo antes de que el administrador de Business Central se entere por un ticket.

• Hay que otorgar conjuntos de permisos a gente que nunca toca la tienda. Sana agrega campos personalizados a la tabla de Artículos, y sin el conjunto de permisos esos campos impiden que el personal de finanzas y almacén edite artículos. Eso es un despliegue a nivel de tenant que aterriza en tu administrador de BC, no en el proyecto de comercio electrónico.
• Pueden faltar productos en el sitio sin ningún error en ningún lado. Los artículos y clientes que contienen caracteres que Sana no permite se excluyen en silencio. Solo se ven en dos ventanas de resumen de Business Central, que nadie revisa a menos que sepa que debe hacerlo.
• La detección de eso tiene un costo de rendimiento. Las verificaciones automáticas de indexabilidad de Sana "can significantly impact performance, especially when there is a large number of items", y las actualizaciones frecuentes del maestro de artículos "may cause session locks". El remedio del propio Sana es desactivar las verificaciones, lo que significa elegir entre un problema de rendimiento del ERP y perder la detección de productos excluidos en silencio.
• Las líneas de pedido que Sana no reconoce se ignoran, no se bloquean. Eso incluye líneas de Cuenta de Mayor, que es práctica común en Business Central para fletes y recargos. Si el total del sitio tiene que cuadrar con el total en BC sin conciliación manual, compruébalo antes del contrato.

Ninguno de estos es un defecto. Todos están documentados. Simplemente están en una página distinta de aquella donde se toma la decisión de compra.

Dos cosas restringen funcionalidad de maneras que aparecen a mitad del proyecto y no durante la evaluación.

La edición. La propia documentación de Business Central de Sana marca como no disponibles en la edición de entrada una lista de capacidades: registro de clientes B2B, representar a un cliente (un agente de ventas pidiendo en nombre de un cliente), pedidos de devolución, pedidos abiertos, prospectos, y mostrar stock en la tienda. Las opciones de agente de ventas dentro de las estrategias de procesamiento de pedidos están solo en los planes superiores. Es perfectamente posible que te coticen un plan que no puede hacer aquello para lo que estás comprando una tienda B2B, así que mapea tu lista de requerimientos contra la edición antes de que se cierre la conversación comercial.

Aquí no publicamos precios ni comparativas de planes, porque Sana publica nombres de planes sin lista de precios y la tabla de planes es una página de marketing renderizada que no pudimos leer con la fiabilidad necesaria para citarla. Pide a Sana la matriz de disponibilidad de funciones por escrito.

La estrategia de procesamiento de pedidos. Existe un modo construido para carritos con muchas líneas, y suele ser el que necesita un distribuidor. Bajo ese modo, Sana no soporta acuerdos de venta, conversión de cotización a pedido, edición de pedidos (el botón de editar desaparece), descuentos mix and match, textos extendidos en líneas de pedido, explosión de listas de materiales, ni cupones en Business Central.

Esa es una bifurcación real y no una opción de ajuste. Si tu flujo necesita carritos grandes y además cualquier cosa de esa lista, la plataforma te obliga a elegir, y sale mucho más barato descubrirlo en el alcance que en las pruebas de aceptación.

"Tu ERP es la fuente única de verdad" se vende como beneficio, y lo es. También es una restricción de gobernanza, y Sana lo dice claramente en el tema donde más pega: "All taxes must be configured in ERP. Sana Commerce Cloud has no influence on tax calculation as it all done by ERP." Sana puede cambiar cómo se presenta el impuesto en el carrito, y nada más.

Generaliza eso y tienes el predictor más confiable de sorpresas de alcance en un proyecto Sana sobre Business Central:

La misma línea atraviesa el soporte. El acuerdo de servicio de Sana apunta a resolver problemas críticos en un día hábil, y señala que "Sana Commerce cannot guarantee a 1 business day fix time for show stoppers caused by 3rd parties (ERP, PSP, etc.)". En una arquitectura cuya característica definitoria es que el ERP sirve a la tienda, la clase más probable de incidente grave es justamente la que no tiene tiempo de resolución garantizado. Eso no es una crítica al SLA. Es una razón para presupuestar un socio de Business Central junto con el presupuesto de comercio electrónico, y no después.

Si tus datos de ERP o tu configuración de precios están desordenados, el sitio lo hereda, y el arreglo es un proyecto de Business Central. Escribimos aparte sobre limpiar el maestro de clientes antes de un replatform, y en esta arquitectura ese trabajo no es preparación opcional, es la tienda.

Esta es la parte que más nos preguntan, porque es donde un brief de diseño se topa con un límite de producto. Nosotros construimos tiendas, así que preferimos fijar la expectativa temprano en vez de descubrirla al aprobar el diseño.

El editor de temas trabaja con tokens: logo, favicon, fondo, colores de encabezado y pie, colores de elementos, tipografías, imágenes de reemplazo. Más allá de eso entras en inyecciones de HTML, que Sana no soporta y de las que se deslinda, y que se restringen todavía más cuando el renderizado del lado del servidor está desactivado, un interruptor que los proyectos estándar no controlan. La página de detalle de producto trae dos diseños, y elegir la matriz de variantes quita el elemento de escribir una reseña.

Si el brief visual es cosmético, el editor de temas está genuinamente bien y es rápido. Si es estructural, estás viendo la ruta del SDK, y la sección de arriba sobre la bifurcación es la que importa.

Sobre headless, la propia nota de arquitectura de Sana es inusualmente directa sobre lo que estás asumiendo: Sana "will not be able to provide support for your custom storefront (web store)", "might be very expensive in terms of money and time", "your project becomes custom", y "may miss out on the benefits of the standard Sana Commerce Cloud product, including regular updates". Tampoco hay una referencia pública de API de tienda de primera mano para evaluar antes de comprometerte, así que pídesela a Sana directamente en vez de suponer que estará ahí.

Una observación de enumerar la documentación pública de Sana, ofrecida como observación y no como declaración de Sana: Sana publica páginas consolidadas de Limitaciones para SAP Business One, Dynamics GP, AX Retail y D365 Commerce, y páginas de Versiones de ERP Soportadas para varios ERPs. Para Business Central no existe ninguna de las dos. Esa ausencia es la mayor parte de la razón por la que vale la pena escribir esta página.

Cada punto aquí se remonta a algo que Sana documenta. Casi todos se resuelven con otro plan, otro alcance u otro orden de trabajo, así que léelos como condiciones de encaje y no como razones para no comprar. Nosotros construimos sobre Sana, y aun así preferimos que los encuentres ahora.

• Necesitas lo básico de B2B y te están cotizando la edición de entrada. Ver arriba. La brecha entre lo que incluye la edición y lo que un comprador B2B asume que es el producto es la sorpresa comercial más común.
• Necesitas carritos grandes y edición de pedidos, cotizaciones o promociones. El modo de pedidos grandes y ese conjunto de funciones son mutuamente excluyentes.
• Tus reglas comerciales deben diferir en línea de lo que hace Business Central. El impuesto es el caso documentado y la regla general se sigue de ahí.
• Tu catálogo depende de contenido de merchandising que el ERP no puede guardar. Descripciones ricas, imágenes, video, atributos de marketing. Eso implica un segundo sistema maestro en la arquitectura, y la gestión de información de producto es una decisión de plan o add-on, no algo incluido por defecto. Escribimos sobre cuándo necesitas de verdad un PIM.
• Necesitas una tienda dirigida por diseño. Si el brief es estructural y no cosmético, cotiza la ruta del SDK y lee primero la sección de la bifurcación.
• Quieres un front end headless. Si es un requerimiento y no una preferencia, esta no es la plataforma sobre la cual comprarlo.
• Tienes requisitos de hospedaje, residencia de datos o aislamiento de red. El self-hosting, las nubes privadas virtuales y el toolkit de actualización de Sana se retiraron todos en el paso a Sana Commerce Cloud.
• Tu control de cambios no puede aceptar actualizaciones programadas por el proveedor. Ninguna configuración fija una app de AppSource durante una ola mayor, una ola aplicada con éxito no se revierte, y el momento del ensayo depende de la licencia de tu socio.
• Operas un catálogo grande y heredado con un maestro de artículos muy activo. Las verificaciones de indexabilidad y los bloqueos de sesión de arriba lo convierten en una disyuntiva real y no en un ejercicio de ajuste.
• Tus pedidos de venta llevan de rutina líneas de flete, cargos o recargos de otros add-ons. Los tipos de línea no soportados se ignoran en vez de bloquearse.
• Estás en Business Central local y quieres controlar tu propio abastecimiento. La extensión solo la pueden descargar socios registrados de Sana, se despliega con PowerShell manual, y la información de compatibilidad vive detrás de un login de socio que no puedes auditar.
• Sigues en Sana 9.3. No hay toolkit de actualización para el paso a Sana Commerce Cloud, lo que lo convierte en una reimplementación y no en una actualización. Esa es una conversación distinta de la renovación que quizá crees estar teniendo, y cubrimos el lado de soporte en soporte de Sana 9.3.