Guía de configuración de TDIGITAL Sync for Zoho & SAPB1

Fecha de actualización: 2026-04-27

Objetivo: describir el setup operativo necesario para pasar de la instalación a un entorno listo para pruebas controladas.

Resumen ejecutivo

El flujo validado hoy en TDIGITAL Sync for Zoho & SAPB1 cubre:

arranque técnico desde post-install
reanudación del onboarding desde el Settings Widget
selección de plan desde el widget
posibilidad de elegir edición Free para escenarios base con límite diario previsto de 100 registros, sujeto a validación final
habilitación de la prueba inicial de 15 días sobre la edición Profesional
provisión o reconciliación del acceso inicial al panel
handoff explícito al panel tenant-local del middleware para la configuración técnica posterior

El build actual todavía debe cerrar el alcance exacto del setup SAP self-service que se enviará al Marketplace, siempre fuera del widget y desde el panel tenant-local del middleware. Por eso este documento separa:

lo ya validado hoy
lo que debe completarse antes del release final

Paso 1. Confirmar el estado de onboarding

Abra el Settings Widget y confirme:

que ZOHO.embeddedApp.init() finaliza correctamente
que el widget puede consultar el estado actual del onboarding
que la organización Zoho se resolvió correctamente
que el administrador actual puede reanudar el flujo

Resultado esperado:

el backend devuelve currentStep y nextStep
si corresponde, el flujo queda listo para selección de plan

Paso 2. Seleccionar o confirmar el plan

Desde el widget:

revise los planes disponibles
seleccione el plan objetivo
confirme el perfil básico del tenant
complete la acción

Resultado esperado:

el middleware persiste o actualiza la suscripción
si se selecciona Free, el tenant queda identificado con el alcance base de Estándar y un límite diario previsto de 100 registros, sujeto a validación final
si corresponde, queda habilitada la prueba inicial de 15 días sobre la edición Profesional
el tenant queda alineado con el estado del onboarding
el próximo paso funcional real es continuar la configuración técnica desde el panel tenant-local del middleware

Paso 3. Verificar acceso al panel

Una vez provisionado el acceso:

ingrese al panel unificado
confirme que el usuario visualiza el tenant correcto
si tiene más de una membresía activa, pruebe el selector de tenant
valide que puede establecer un tenant por defecto

Referencias:

README.md
auth-otp.md

Paso 4. Preparar datos y conectividad SAP

Antes de activar cualquier sincronización, el cliente debe tener disponibles:

URL de SAP Business One Service Layer
compañía objetivo de SAP Business One
credenciales técnicas autorizadas
política de red que permita conectar el middleware con Service Layer
decisión de alcance por módulos y dirección de sync

Paso 5. Definir alcance funcional del release

Antes de publicar en Marketplace debe congelarse:

módulos incluidos
dirección soportada por módulo
prerequisitos por plan
si la configuración SAP y los mapeos se realizan:
desde el panel tenant-local del middleware
desde el panel tenant-local del middleware con acompañamiento de TDigital

Este punto no debe quedar ambiguo en el listing público.

Paso 5.1. Definir la política de activación de cliente en SAP

Antes de cerrar el release y la configuración operativa, debe definirse cómo se tratarán las Accounts y Contacts de Zoho CRM frente a BusinessPartners de SAP Business One.

Regla funcional a documentar:

en Zoho CRM puede existir una base comercial de cuentas y contactos que todavía no deba considerarse cliente activo en SAP
la creación o actualización del cliente en SAP puede quedar sujeta a un hito comercial definido para la implementación
una vez activa la condición de cliente, la información debe poder mantenerse alineada entre Zoho CRM y SAP Business One

Opciones de hito comercial a revisar por producto/release:

confirmación de un pedido
creación de una cotización
oportunidad cerrada ganada

Guardrail de documentación:

no declarar como comportamiento estándar del producto un hito configurable por cliente hasta que el release final confirme si esa elección queda disponible en onboarding/configuración o si la versión base sale solo con una condición por defecto

Paso 5.2. Confirmar el alcance técnico de productos

Antes de cerrar el release y la configuración operativa, debe documentarse cómo se comporta el proceso de Items entre SAP Business One y Zoho CRM.

Estado técnico validado:

el módulo lógico interno sigue siendo Items
el descriptor canónico actual es products_items
en Zoho CRM, el módulo físico validado es Products
en SAP Business One, el descriptor canónico apunta a Items
los descriptores legacy items_items e items_products no deben usarse como código canónico

Guardrail de release:

aunque el runtime ya tenga soporte descriptor-driven en ambos sentidos, el release base debe presentar productos como flujo principalmente orientado desde SAP Business One hacia Zoho CRM
no declarar públicamente sincronización bilateral de productos como comportamiento estándar hasta cerrar si queda como alcance base o como evolución posterior

Paso 5.3. Definir el flujo bilateral de pedidos

Antes de cerrar el release y la configuración operativa, debe documentarse cómo se comporta el proceso de Sales Orders entre Zoho CRM y SAP Business One.

Estado técnico validado:

el módulo lógico interno sigue siendo SalesOrders
en Zoho CRM, el API name físico validado para el módulo estándar es Sales_Orders
en SAP Business One, el descriptor canónico apunta a Orders
la dirección Zoho -> SAP queda como actualización controlada de documentos existentes con clave técnica SAP_DocEntry -> DocEntry; SO_Number -> NumAtCard puede usarse como referencia, no como clave de alta
la dirección SAP -> Zoho requiere provisionar campos administrados de integración, como SAP_DocEntry y SAP_DocNum, antes de activar el upsert contra Zoho

Flujo comercial base:

desde Zoho CRM, el equipo comercial puede mantener referencias y comentarios de pedidos ya sincronizados con SAP Business One; la creación automática de pedidos SAP requiere reglas comerciales adicionales antes de declararse como alcance estándar

Continuidad operativa:

una vez creado en SAP Business One, el pedido puede entrar en circuitos operativos o de aprobación
la actualización bilateral debe reflejar ese estado en Zoho CRM para evitar ediciones comerciales sobre pedidos ya en curso
la actualización bilateral debe permitir identificar si el pedido fue entregado de forma total o parcial, incluso por línea, ya que la remisión en SAP Business One puede no ocurrir de manera completa en un solo paso

Flujo SAP -> Zoho para consistencia comercial:

cuando el pedido se origina directamente en SAP Business One sin pasar por el proceso comercial en Zoho CRM, la solución debe definir cómo reconstruye el contexto comercial en CRM
la lógica objetivo hoy contempla crear en Zoho CRM:
la oportunidad
la cotización
el pedido
los tres registros deben quedar vinculados al cliente activo

Guardrail de release:

no declarar públicamente como comportamiento estándar la creación automática de oportunidad, cotización y pedido desde un origen SAP hasta confirmar que esa orquestación queda incluida en el release base y no solo como alcance de implementación

Paso 5.4. Definir el flujo de facturación desde SAP hacia Zoho CRM

Antes de cerrar el release y la configuración operativa, debe documentarse cómo se comporta el proceso de Invoices entre SAP Business One y Zoho CRM.

Estado técnico validado:

el módulo lógico interno sigue siendo Invoices
el descriptor canónico actual es invoices_invoices
en Zoho CRM, el módulo físico validado es Invoices
en SAP Business One, el descriptor canónico apunta a Invoices
la dirección SAP -> Zoho requiere provisionar campos administrados de integración, como SAP_DocEntry y SAP_DocNum, antes de activar el upsert contra Zoho
la dirección Zoho -> SAP puede existir técnicamente para escenarios específicos, pero no debe presentarse como flujo comercial base de facturación mientras el release mantenga SAP como origen operativo de facturas

Regla de release base:

la facturación debe tratarse como flujo principalmente orientado desde SAP Business One hacia Zoho CRM
toda factura emitida en SAP debe reflejarse en Zoho CRM

Relaciones que deben conservarse:

la factura debe quedar vinculada al cliente activo
si la factura corresponde a un pedido y ese pedido forma parte del contexto integrado, la relación con el pedido también debe reflejarse en Zoho CRM

Consideraciones de alcance:

el módulo de remitos no forma parte del alcance actual
si la factura nace desde un remito, Zoho CRM debe reflejar la factura y su contexto disponible, sin asumir un módulo de remitos todavía no integrado
si la factura nace desde una cotización originada en SAP y esa cotización no forma parte del alcance integrado, la factura debe reflejarse como documento relacionado al cliente, sin reconstruir automáticamente objetos comerciales fuera de scope

Estado de factura a reflejar:

estado operativo vigente
si quedó cancelada o saldada
cuando la información lo permita, si la cancelación responde a pago o a nota de crédito

Guardrail de release:

no declarar todavía notas de crédito como módulo integrado del release base
si el build final no deja cerrada la causa de cancelación visible en CRM, no prometer públicamente más que el estado operativo general de la factura

Paso 5.5. Definir usuarios comerciales y trazabilidad de propietario

Antes de cerrar el release y la configuración operativa, debe definirse cómo se preserva la referencia del ejecutivo comercial entre Zoho CRM y SAP Business One.

Edición Free y Estándar:

si el ejecutivo comercial también existe como usuario en SAP, los registros pueden conservar su propiedad en ambos entornos
si no existe un usuario equivalente en SAP, los registros creados o actualizados en SAP quedan a nombre del administrador técnico
esto afecta especialmente clientes activos, pedidos y actualizaciones de vuelta desde SAP hacia Zoho CRM
en ese escenario puede perderse trazabilidad directa del ejecutivo que originó la operación en Zoho CRM

Edición Profesional:

la solución puede preservar la referencia comercial sin exigir que los ejecutivos tengan licencias en ambos entornos
para eso conviene mapear el ejecutivo de Zoho CRM contra un identificador comercial en SAP, por ejemplo un campo custom de vendedor o una tabla de personal custom
en Zoho CRM el ejecutivo puede seguir viéndose como propietario comercial del registro
en SAP el owner técnico puede quedar a nombre del administrador, mientras la referencia comercial real se conserva en el identificador de vendedor configurado

Recomendación operativa:

para Free y Estándar, conviene que los ejecutivos que operan desde Zoho CRM tengan usuario equivalente en SAP si se desea preservar la propiedad del registro
para Profesional, la recomendación es resolver la equivalencia desde el panel del middleware y no depender como estrategia base de campos custom sobre usuarios de Zoho CRM hasta confirmar esa viabilidad técnica

Guardrail de release:

no declarar públicamente un modelo completamente configurable de asignación de propietario hasta confirmar cómo queda implementado en el release base

Paso 6. Ejecutar prueba controlada

La primera prueba operativa debe ser acotada:

elegir un tenant de prueba
elegir un conjunto mínimo de módulos
validar autenticación y conectividad
revisar logs y correlación de eventos
confirmar que el flujo no rompe aislamiento multi-tenant

Asistencia opcional para la puesta en marcha

Después del onboarding, el administrador puede continuar la configuración con autonomía usando la guía para administradores. Si el escenario requiere acompañamiento adicional, TDigital puede ofrecer:

asistencia remota opcional
packs de horas para configuración de campos personalizados
packs de horas para configuración de módulos personalizados

Pendientes que deben resolverse antes del submit final

cerrar la guía definitiva de setup SAP para el build de envío
documentar compatibilidad por edición de Zoho CRM
documentar compatibilidad por data center
documentar disclosure completo de datos y transferencias

Qué no debe prometerse todavía

Hasta congelar el release final no debe afirmarse en la ayuda pública que:

el setup SAP es 100% self-service
todos los módulos del documento de arquitectura están disponibles en el build enviado
la compatibilidad aplica a todas las ediciones o data centers