Resposta curta. Sí, NetSuite s'integra amb Dynamics 365 (Business Central o Finance & Operations) i amb SAP (Business One, ECC o S/4HANA). La via depèn del producte de Microsoft o de SAP que vostè tingui, de quins registres s'han de moure i de qui és el propietari de cada registre. Un primer flux en producció sol trigar setmanes, no mesos; un programa híbrid complet amb diverses societats triga més.
L'híbrid és una estratègia, no un fracàs
Pocs grups trien tenir dos ERP. Els passa. Un grup amb NetSuite compra una empresa que treballa amb Dynamics 365 Business Central. Un entorn corporatiu SAP escindeix una unitat de negoci que passa a NetSuite. Els serveis compartits de finances es consoliden en un ERP mentre les operacions locals mantenen el sistema que coneix els seus magatzems, les obligacions legals i les regles fiscals.
Hi ha molt material bo sobre com migrar de Dynamics o SAP a NetSuite, i de vegades migrar és la resposta correcta. Però una migració feta amb presses, abans d'entendre el negoci adquirit, és la manera més segura d'acabar amb un ERP nou ple de dades dolentes. Si la convivència ha de durar dos o tres anys, tracti-la com el pla i construeixi bé el pont.
Això no descarta un únic ERP més endavant. Un pont ben dissenyat facilita el tall definitiu, perquè obliga a respondre les mateixes preguntes que una migració: quin sistema és el propietari del client, com es mapegen els comptes, quins codis d'article són reals. Quan arribi aquell dia, la disciplina de la migració de dades és el projecte continua sent vàlida.
Què sol haver de moure's entre els ERP
La primera decisió de disseny no és l'eina. És quins registres travessen la frontera, en quina direcció i quin sistema té l'última paraula sobre cadascun.
| Àmbit | Direcció habitual | Què decideix el disseny |
|---|---|---|
| Clients i proveïdors | De l'ERP propietari a l'altre, rarament en tots dos sentits | Un propietari per registre, una clau comuna i què passa quan tots dos costats editen el mateix camp |
| Articles i preus | Des de l'ERP que gestiona el catàleg | Mapatge de codis d'article, unitats de mesura, quins atributs necessita de debò el costat receptor |
| Comandes de venda, comandes de compra, factures | D'on passa la transacció a on se serveix o es comptabilitza | Estats que tornen, enviaments parcials, abonaments |
| Posicions d'inventari | Resums, rarament cada moviment | Com d'actualitzada ha d'estar la xifra i si n'hi ha prou amb una foto diària |
| Operacions intercompanyia | Tots dos costats, com a assentaments que quadren | Que les dues potes coincideixin en import, moneda, data i contrapart |
| Pla de comptes i dimensions | Mapatge, no sincronització | Una taula de correspondències mantinguda entre els comptes locals i el pla del grup; vegi un pla de comptes per a diverses filials i monedes |
| Enviaments de consolidació | De l'ERP de la filial a l'ERP que consolida | Calendari de tancament, balanç de sumes i saldos o nivell d'assentament, tipus de canvi |
De vegades també hi ha un CRM al mig: Salesforce enviant comandes a tots dos ERP, o custodiant el mestre de clients. Això canvia qui és el propietari del client, no la lògica anterior. Mantenir un únic registre de client coherent en dos sistemes és un problema en si mateix, tractat a un registre de client, dos sistemes.
Dynamics 365 amb NetSuite: Business Central i Finance & Operations
«Dynamics 365» designa dos ERP diferents, i la integració és diferent en cadascun.
Business Central és el que més veiem al costat de NetSuite: una filial o una empresa adquirida treballa amb BC mentre el grup treballa amb NetSuite, o al revés. Business Central exposa una API REST estàndard (v2.0). Un detall importa per dimensionar el projecte: la documentació de Microsoft indica que les API estàndard no es poden ampliar amb camps addicionals; si vostè necessita un camp personalitzat, cal copiar el codi AL de l'API i publicar-ne una de pròpia (Microsoft Learn, API v2.0 de Business Central, consultat el 29 de setembre de 2026). Qualsevol personalització del costat de BC apareix, per tant, en l'estimació de la integració.
Finance & Operations (Finance, Supply Chain Management) és un sistema més gran amb una altra superfície. Les entitats de dades marcades com a públiques s'exposen a través d'un endpoint OData per crear, llegir, actualitzar i esborrar (Microsoft Learn, OData, consultat el 29 de setembre de 2026). Per a escenaris amb fitxers i càrregues massives, Microsoft ofereix l'API de paquets de Data management i l'API d'integracions recurrents (Microsoft Learn, Data management package REST API, consultat el 29 de setembre de 2026). Quina encaixa depèn del volum i dels terminis, i per això els projectes amb F&O comencen amb una fase de descoberta.
Pel que fa a plataformes, Celigo indica que dona suport tant a Business Central com a Finance & Supply Chain Management, i publica una plantilla d'integració Business Central – NetSuite els fluxos inclosos de la qual són factures de BC a factures de NetSuite i comptes de BC a clients de NetSuite (Celigo, plantilla Business Central – NetSuite, consultat el 29 de setembre de 2026). És un punt de partida, no un disseny híbrid complet: articles, comandes, intercompanyia i enviaments de consolidació continuen sent abast per definir.
MuleSoft és excessiu aquí?
Sovint, sí. Si l'abast és un flux acotat Business Central ↔ NetSuite o Business Central ↔ Salesforce i el seu grup encara no fa servir MuleSoft, una plataforma empresarial orientada a API hi afegeix més pes operatiu del que el problema necessita. Si MuleSoft ja és l'estàndard del grup, amb l'equip i el contracte en marxa, construir-hi al damunt pot ser el més assenyat, i l'hi direm. Ajusti el pes de l'eina al paisatge. La versió llarga d'aquest equilibri és al nostre marc de decisió Heroku Connect vs Celigo vs MuleSoft.
SAP amb NetSuite: Business One, ECC i S/4HANA
SAP també són diversos productes, i cadascun té una forma d'integració diferent.
- SAP Business One és habitual en filials més petites. Se sol integrar a través del seu Service Layer, una API web sobre els objectes de Business One, o de la DI API, més antiga.
- Els entorns SAP ECC intercanvien dades normalment mitjançant IDocs, BAPI i RFC, sovint darrere d'un middleware que el grup ja té.
- SAP S/4HANA hi afegeix un catàleg publicat d'API OData i SOAP, recollit al SAP Business Accelerator Hub (consultat el 29 de setembre de 2026).
El que no fem és presentar-nos com a partner de SAP. No ho som. El nostre punt fort és el costat de NetSuite (registres, filials, intercompanyia, SuiteScript, els serveis web REST i SOAP) i la mateixa capa d'integració. Al costat de SAP treballem amb el seu equip o el seu partner de SAP, contra interfícies que ells exposen i mantenen. Quan un entorn SAP no té una interfície estable per a les dades que vostè necessita, l'hi diem abans de començar el projecte, no a la sisena setmana.
Aquí hi ha menys integracions predissenyades que per a Business Central. La pàgina de SAP de Celigo recull integracions com SAP Business Network – NetSuite i Loop Returns – SAP Business One (Celigo, integració amb SAP, consultat el 29 de setembre de 2026), no un flux empaquetat ERP de SAP ↔ NetSuite. Compti que els fluxos NetSuite ↔ ERP de SAP es construiran sobre els connectors genèrics de la plataforma o s'escriuran contra les API.
Quatre maneres de construir el pont
Construïm integracions de quatre maneres, i l'elecció depèn del cas: el volum, la latència que de debò necessita, si les dades poden sortir de la seva infraestructura i què mantindrà el seu equip després (el nostre enfocament d'integració).
| Via | Encaixa en un pont d'ERP híbrid quan | Compte amb |
|---|---|---|
| Celigo (iPaaS) | Vol connectors amb el suport del fabricant i monitoratge per a fluxos d'ERP programats o per esdeveniments | Les plantilles en cobreixen una part; la resta es configura al damunt |
| n8n (orquestració) | El procés té passos, branques i aprovacions entre diversos sistemes, o s'ha d'executar a la seva pròpia infraestructura | Orquestra; no és un motor de sincronització de dades |
| A mida, contra les API | Cap plataforma no encaixa, o no vol una llicència de tercers al mig | El codi és seu, així que la documentació i el monitoratge s'han de lliurar amb ell |
| Stacksync (sincronització en temps real) | Un CRM o una base de dades necessita sincronització bidireccional per sota del segon al costat dels ERP | Sol ser secundari en un pont entre ERP |
Si el seu grup ja té un iPaaS empresarial com MuleSoft o Boomi, la comparació es fa a nivell de capacitats: cobertura de connectors per al seu producte concret de Dynamics o SAP, com es mostren i es reintenten els errors, qui del seu equip pot canviar un mapatge i quant costa operar-lo. No puntuem plataformes que no implantarem per a vostè. Per a l'equilibri general entre plataformes, codi punt a punt i middleware, vegi iPaaS, punt a punt o middleware.
Un matís sobre el «temps real»: no tots els objectes de l'ERP el necessiten, ni totes les vies l'ofereixen. Els canvis en clients i articles sovint poden anar per esdeveniments; els enviaments de consolidació segueixen normalment el calendari de tancament; l'inventari sol funcionar bé com a resum programat. Indiquem la latència per flux, no per projecte.
Governança: font de veritat, conflictes i tall
Les integracions híbrides fallen més per governança que per codi. Abans de construir, acordem i deixem per escrit:
- Un propietari per tipus de registre. Els mestres de clients, proveïdors i articles tenen cadascun el seu sistema de referència. L'altre costat en rep una còpia, i les edicions allà es bloquegen o es retornen a l'origen.
- Regles de conflicte. Què passa quan tots dos ERP canvien el mateix camp en la mateixa finestra: quin costat guanya i a qui s'avisa.
- Rèplica de només lectura o doble escriptura. Una còpia de només lectura és més senzilla i més segura. Escriure des de tots dos costats de vegades és necessari, i llavors cada flux necessita idempotència i un informe de conciliació.
- Taules de mapatge amb responsable. Comptes, dimensions, codis d'impost, unitats de mesura i societats viuen en taules mantingudes, no dins de la lògica dels fluxos.
- Monitoratge des del primer dia. La gestió d'errors, els reintents i les alertes es lliuren amb el primer flux, i algú del seu costat els veu.
- Un pla de retirada. Si un dels ERP ha de desaparèixer, cada flux té data de fi i un pas de tall, i el pont manté netes les dades mestres per a aquell dia.
El go-live no és el final. Les integracions necessiten algú que les vigili mentre els ERP continuen canviant al seu voltant, que és el tema de la vida després del go-live.
Forma del projecte i per què Atypical
Un projecte típic segueix aquest ordre:
- Descoberta. Quin producte de Dynamics o SAP, quines entitats, interfícies actuals, regles de propietat i volums.
- Via i disseny. Celigo, n8n, a mida o una combinació, amb les decisions de governança anteriors per escrit.
- Primer flux en producció. Normalment dades mestres o factures, en producció en setmanes, no en mesos.
- Ampliació. Comandes, intercompanyia, enviaments de consolidació, en l'ordre que elimini més feina manual.
- Operació. Monitoratge, reintents, alertes i canvis a mesura que evolucionen tots dos ERP, operats per nosaltres o lliurats al seu equip amb documentació.
Som enginyers d'integració en tot l'stack que fan servir de debò els grups europeus del mid-market, no un implantador de NetSuite que intenta substituir el seu altre ERP. Som partner d'implantació de Celigo i partner de Stacksync, construïm directament contra les API quan cap plataforma no encaixa i treballem des d'Espanya en anglès, castellà, portuguès i català. Hi ha més informació sobre l'equip a qui som.