La mayoría de proyectos de integración NetSuite Salesforce no fracasan el día que se conectan los dos sistemas. Fracasan tres semanas después, cuando el equipo comercial sigue trabajando en Salesforce, finanzas cierra en NetSuite, y nadie entiende por qué hay clientes repetidos, pedidos sin IVA o importes que no cuadran. Hemos entrado a arreglar varias de estas integraciones después del go-live, y los problemas se repiten. Este artículo recoge los seis que más nos encontramos y cómo se evitan desde el diseño.
Antes de hablar de errores conviene fijar el mapa. Salesforce es el sistema donde vive el ciclo comercial: cuentas, contactos, oportunidades. NetSuite es el sistema de registro financiero y operativo: clientes, pedidos, facturas, cobros. La integración tiene sentido cuando una oportunidad ganada en Salesforce se convierte en un pedido en NetSuite sin que nadie reescriba los datos a mano.
El error de partida es querer sincronizarlo todo. No todo tiene que cruzar la frontera. Las cuentas y contactos comerciales, sí. Las oportunidades en estado "Closed Won", sí, convertidas en pedido o presupuesto. Pero el histórico de actividades de Salesforce, las notas de los comerciales o los campos internos de previsión no aportan nada en NetSuite y solo añaden ruido y puntos de fallo. Cuanto más estrecho es el contrato de datos entre los dos sistemas, menos cosas se rompen.
Es, con diferencia, el problema número uno. Toda integración necesita un campo de correspondencia —un identificador externo— para saber que la "Cuenta Acme" de Salesforce y el "Cliente Acme" de NetSuite son la misma empresa. En NetSuite ese campo es el External ID de la entidad; en Salesforce suele ser un campo personalizado tipo NetSuite_Internal_ID__c.
Cuando ese mapeo no está bien configurado, la integración no encuentra la coincidencia y crea un registro nuevo en cada sincronización. El resultado es el clásico: tres clientes "Acme S.L." en NetSuite, cada uno con una parte de las facturas. A partir de ahí, cualquier informe de antigüedad de saldos o de riesgo de cliente queda inservible, y conciliar es un trabajo manual. La regla es sencilla: ningún registro debe poder crearse sin que la integración haya buscado primero por External ID. Si la búsqueda falla, el flujo debe parar y avisar, no improvisar un duplicado.
Parecen equivalentes, pero no lo son. En Salesforce, una empresa es un Account y las personas son Contacts. En NetSuite, la entidad comercial es un único registro que cambia de estado a lo largo de su vida: Lead, Prospect y Customer son fases del mismo objeto, no objetos distintos. Si la integración vuelca cada Account de Salesforce como Customer sin decidir en qué estado entra, acabas con clientes activos que en realidad eran solo oportunidades frías, y con un libro de clientes inflado.
El segundo matiz es la jerarquía. NetSuite permite sub-clientes (sub-customers) para modelar grupos de empresas o delegaciones; Salesforce usa la relación padre-hijo entre Accounts. Si no se decide cómo se traduce esa jerarquía, la facturación consolidada de un grupo se rompe. Esto hay que definirlo en el diseño, no descubrirlo en producción.
Si la empresa usa NetSuite OneWorld, cada cliente y cada pedido pertenecen a una subsidiaria. Salesforce, en su configuración estándar, no tiene el concepto de subsidiaria de NetSuite. Si la integración no resuelve a qué subsidiaria pertenece cada oportunidad —por país, por unidad de negocio o por un campo dedicado en Salesforce—, el pedido no se puede crear o se crea en la subsidiaria equivocada, lo que arrastra el plan contable, el IVA y la divisa funcional.
La divisa es la otra trampa. Una oportunidad en Salesforce puede estar en euros mientras la subsidiaria de NetSuite trabaja en otra divisa funcional, y el importe que viaja debe respetar el tipo de cambio y la divisa de la transacción, no convertirse por defecto. Hemos visto pedidos entrar con el importe correcto en el número pero en la divisa equivocada, y eso solo se detecta cuando alguien mira el margen y no cuadra.
Este error conecta la integración con la localización española, y es el que más caro sale. Una oportunidad de Salesforce no tiene código de IVA español: no es su trabajo. Pero el Sales Order que se crea en NetSuite sí necesita el tax code correcto (por ejemplo, IVA 21% nacional, o el código intracomunitario que corresponda) para que después la factura alimente bien el libro de IVA, el modelo 303 y el SII.
Si la integración deja el código de impuesto vacío o pone uno por defecto, el problema no se ve el día del pedido: se ve en el cierre trimestral, cuando los importes de IVA no cuadran con la AEAT. La regla práctica es que la determinación del impuesto debe resolverla NetSuite con sus reglas fiscales españolas a partir del cliente y del artículo, no heredarse de un Salesforce que no sabe de fiscalidad española. Si quieres profundizar en cómo NetSuite construye esos importes, lo tratamos en nuestro artículo sobre la configuración del modelo 303 en NetSuite.
Cuando la integración se construye con código a medida en lugar de un middleware, muchas veces el punto de entrada en NetSuite es un RESTlet. Conviene conocer un número concreto: un RESTlet dispone de hasta 5.000 unidades de governance por ejecución (documentación oficial de Oracle NetSuite). Cada operación consume unidades —crear un registro cuesta más que leerlo—, y cuando una sincronización masiva de oportunidades intenta crear cientos de pedidos en una sola llamada, el script supera el límite y aparece el error SSS_USAGE_LIMIT_EXCEEDED ("Script Execution Usage Limit Exceeded").
El síntoma para el negocio es que parte de los pedidos entra y parte no, sin patrón aparente. La solución no es subir nada —el límite es fijo—, sino diseñar el flujo para procesar por lotes y, si el volumen lo exige, mover la carga pesada a un script de tipo Map/Reduce, que está pensado para procesar grandes volúmenes respetando el governance. Es una decisión de arquitectura, no un parche.
La última trampa es de criterio. No todo necesita sincronizarse al instante. Que una oportunidad se marque como ganada y el pedido aparezca en NetSuite en segundos tiene valor. Que cada cambio menor en un campo de notas dispare una llamada a la API no aporta nada y multiplica el consumo y los puntos de fallo.
Nuestra recomendación es decidir, objeto por objeto, qué va en tiempo real y qué va en batch nocturno. Pedidos ganados: tiempo real. Altas y modificaciones de cuentas: cada pocas horas o en batch. Histórico y datos de análisis: nunca, o una carga puntual. Esta decisión, que parece menor, es la que marca la diferencia entre una integración que se mantiene sola y una que genera una incidencia cada semana.
Si lo que estás decidiendo es con qué herramienta construir todo esto —iPaaS como Celigo o Boomi, NetSuite Connector o desarrollo a medida con SuiteTalk—, lo comparamos en detalle en nuestro artículo sobre Celigo vs Boomi para integrar NetSuite. Y si la integración tiene que tocar cobros y remesas, conviene leer antes cómo funciona la integración de NetSuite con bancos españoles.
¿Con qué herramienta se integra NetSuite y Salesforce?
Hay tres caminos: una plataforma de integración (iPaaS) como Celigo o Boomi, el NetSuite Connector para casos estándar, o desarrollo a medida con SuiteTalk y RESTlets cuando la lógica es específica. La elección depende del volumen, de cuánta lógica de negocio hay en medio y de quién va a mantenerlo después. Ninguna opción es "la mejor" en abstracto; lo es en función de tu caso.
¿Por qué se crean clientes duplicados al integrar NetSuite con Salesforce?
Casi siempre porque falta o está mal configurado el campo de correspondencia (External ID). La integración no encuentra el registro existente y crea uno nuevo en cada sincronización. Se corrige obligando a que todo flujo busque primero por ese identificador y se detenga si no hay coincidencia, en lugar de crear un duplicado.
¿Se puede integrar NetSuite y Salesforce sin programar?
Sí, con un iPaaS o con NetSuite Connector se cubren los casos estándar mediante configuración. Ahora bien, las reglas de subsidiaria, divisa e IVA español casi siempre requieren decisiones de diseño que ninguna herramienta resuelve sola: la configuración no sustituye al criterio.
¿Qué pasa con el IVA cuando un pedido entra desde Salesforce?
El código de IVA debe asignarlo NetSuite con sus reglas fiscales españolas, no heredarse de Salesforce, que no conoce la fiscalidad española. Si el pedido entra sin tax code o con uno por defecto, el problema aparece en el cierre del IVA y en el SII, no el día del pedido.
¿Cada cuánto debe sincronizarse la información?
Depende del objeto. Las oportunidades ganadas que se convierten en pedido tienen sentido en tiempo real; las altas y cambios de cuentas pueden ir en batch cada pocas horas; el histórico y los datos de análisis, normalmente, no deberían cruzar. Sincronizarlo todo en tiempo real es la causa más común de incidencias recurrentes.
¿Tu integración NetSuite–Salesforce ya está en marcha pero genera duplicados, descuadres de IVA o pedidos que no entran? En Flying Lemons hemos sido usuarios internos de NetSuite antes que consultores, así que sabemos dónde mirar. Cuéntanos tu caso y revisamos cómo está montada la integración y qué se puede estabilizar.
Gratuito
