Resposta curta. Sim, o NetSuite integra-se com o Dynamics 365 (Business Central ou Finance & Operations) e com o SAP (Business One, ECC ou S/4HANA). A via depende do produto Microsoft ou SAP em uso, dos registos que têm de circular e de quem é o dono de cada registo. Um primeiro fluxo em produção demora normalmente semanas, não meses; um programa híbrido completo com várias entidades demora mais.
O híbrido é uma estratégia, não um fracasso
Poucos grupos escolhem ter dois ERP. Acontece-lhes. Um grupo em NetSuite compra uma empresa que trabalha com o Dynamics 365 Business Central. Um ambiente corporativo SAP autonomiza uma unidade de negócio que passa para o NetSuite. Os serviços partilhados de finanças consolidam-se num ERP, enquanto as operações locais mantêm o sistema que conhece os seus armazéns, as obrigações legais e as regras fiscais.
Há muito material bom sobre como migrar do Dynamics ou do SAP para o NetSuite, e por vezes migrar é a resposta certa. Mas uma migração feita à pressa, antes de se perceber o negócio adquirido, é a forma mais segura de acabar com um ERP novo cheio de dados maus. Se a coexistência vai durar dois ou três anos, deve ser tratada como o plano, e a ponte construída como deve ser.
Isso não exclui um único ERP mais tarde. Uma ponte bem desenhada facilita o corte final, porque obriga a responder às mesmas perguntas que uma migração: que sistema é o dono do cliente, como se mapeiam as contas, que códigos de artigo são reais. Quando esse dia chegar, a disciplina de a migração de dados é o projeto continua a aplicar-se.
O que costuma ter de circular entre os ERP
A primeira decisão de desenho não é a ferramenta. É que registos atravessam a fronteira, em que sentido, e que sistema tem a última palavra sobre cada um.
| Domínio | Sentido habitual | O que decide o desenho |
|---|---|---|
| Clientes e fornecedores | Do ERP dono para o outro, raramente nos dois sentidos | Um dono por registo, uma chave comum e o que acontece quando os dois lados editam o mesmo campo |
| Artigos e preços | A partir do ERP que gere o catálogo | Mapeamento de códigos de artigo, unidades de medida, que atributos o lado recetor precisa mesmo |
| Encomendas de venda, encomendas de compra, faturas | De onde a transação acontece para onde é expedida ou contabilizada | Estados que regressam, expedições parciais, notas de crédito |
| Posições de stock | Resumos, raramente cada movimento | Quão atualizado tem de estar o valor e se uma fotografia diária basta |
| Operações intercompanhia | Os dois lados, como lançamentos que batem certo | As duas pernas coincidirem em montante, moeda, data e contraparte |
| Plano de contas e dimensões | Mapeamento, não sincronização | Uma tabela de correspondências mantida entre as contas locais e o plano do grupo; ver um plano de contas para várias subsidiárias e moedas |
| Envios de consolidação | Do ERP da subsidiária para o ERP que consolida | Calendário de fecho, balancete ou nível de lançamento, taxas de câmbio |
Por vezes há também um CRM no meio: o Salesforce a enviar encomendas para os dois ERP, ou a guardar o mestre de clientes. Isso muda quem é o dono do cliente, não a lógica acima. Manter um único registo de cliente coerente em dois sistemas é um problema em si mesmo, tratado em um registo de cliente, dois sistemas.
Dynamics 365 com NetSuite: Business Central e Finance & Operations
«Dynamics 365» designa dois ERP diferentes, e a integração é diferente em cada um.
O Business Central é o que mais vemos ao lado do NetSuite: uma subsidiária ou uma empresa adquirida trabalha com o BC enquanto o grupo trabalha com o NetSuite, ou o contrário. O Business Central expõe uma API REST padrão (v2.0). Há um pormenor que conta para dimensionar o projeto: a documentação da Microsoft indica que as API padrão não podem ser estendidas com campos adicionais; se for preciso um campo personalizado, copia-se o código AL da API e publica-se uma API própria (Microsoft Learn, API v2.0 do Business Central, consultado a 29 de setembro de 2026). Qualquer personalização do lado do BC aparece, portanto, na estimativa da integração.
O Finance & Operations (Finance, Supply Chain Management) é um sistema maior, com outra superfície. As entidades de dados marcadas como públicas são expostas através de um endpoint OData para criar, ler, atualizar e apagar (Microsoft Learn, OData, consultado a 29 de setembro de 2026). Para cenários com ficheiros e cargas em volume, a Microsoft disponibiliza a API de pacotes do Data management e a API de integrações recorrentes (Microsoft Learn, Data management package REST API, consultado a 29 de setembro de 2026). Qual encaixa depende do volume e dos prazos, e é por isso que os projetos com F&O começam por uma fase de descoberta.
Do lado das plataformas, a Celigo indica suportar tanto o Business Central como o Finance & Supply Chain Management, e publica um modelo de integração Business Central – NetSuite cujos fluxos incluídos são faturas do BC para faturas do NetSuite e contas do BC para clientes do NetSuite (Celigo, modelo Business Central – NetSuite, consultado a 29 de setembro de 2026). É um ponto de partida, não um desenho híbrido completo: artigos, encomendas, intercompanhia e envios de consolidação continuam a ser âmbito por definir.
O MuleSoft é excessivo aqui?
Muitas vezes, sim. Se o âmbito é um fluxo delimitado Business Central ↔ NetSuite ou Business Central ↔ Salesforce e o grupo ainda não usa o MuleSoft, uma plataforma empresarial orientada a API traz mais peso operacional do que o problema pede. Se o MuleSoft já é o padrão do grupo, com a equipa e o contrato em funcionamento, construir sobre ele pode ser a escolha sensata, e diremos isso mesmo. O peso da ferramenta deve acompanhar o cenário. A versão longa desse equilíbrio está no nosso framework de decisão Heroku Connect vs Celigo vs MuleSoft.
SAP com NetSuite: Business One, ECC e S/4HANA
O SAP também são vários produtos, e cada um tem uma forma de integração diferente.
- O SAP Business One é comum em subsidiárias mais pequenas. Integra-se normalmente através do seu Service Layer, uma API web sobre os objetos do Business One, ou da DI API, mais antiga.
- Os ambientes SAP ECC trocam dados, tipicamente, através de IDocs, BAPI e RFC, muitas vezes atrás de um middleware que o grupo já tem.
- O SAP S/4HANA acrescenta um catálogo publicado de API OData e SOAP, listado no SAP Business Accelerator Hub (consultado a 29 de setembro de 2026).
O que não fazemos é apresentar-nos como parceiro SAP. Não somos. O nosso ponto forte é o lado do NetSuite (registos, subsidiárias, intercompanhia, SuiteScript, os serviços web REST e SOAP) e a própria camada de integração. Do lado do SAP trabalhamos com a equipa ou o parceiro SAP do cliente, contra interfaces que eles expõem e mantêm. Quando um ambiente SAP não tem uma interface estável para os dados necessários, dizemo-lo antes de o projeto começar, não na sexta semana.
Aqui há menos integrações pré-construídas do que para o Business Central. A página SAP da Celigo lista integrações como SAP Business Network – NetSuite e Loop Returns – SAP Business One (Celigo, integração SAP, consultado a 29 de setembro de 2026), não um fluxo empacotado ERP SAP ↔ NetSuite. Conte com fluxos NetSuite ↔ ERP SAP construídos sobre os conectores genéricos da plataforma ou escritos contra as API.
Quatro formas de construir a ponte
Construímos integrações de quatro formas, e a escolha segue o caso: o volume, a latência realmente necessária, se os dados podem sair da infraestrutura do cliente e o que a equipa vai manter depois (a nossa abordagem de integração).
| Via | Encaixa numa ponte de ERP híbrido quando | Atenção a |
|---|---|---|
| Celigo (iPaaS) | Se quer conectores com suporte do fabricante e monitorização para fluxos de ERP agendados ou por eventos | Os modelos cobrem uma parte; o resto configura-se por cima |
| n8n (orquestração) | O processo tem passos, ramificações e aprovações entre vários sistemas, ou tem de correr em infraestrutura própria | Orquestra; não é um motor de sincronização de dados |
| À medida, contra as API | Nenhuma plataforma encaixa, ou não se quer uma licença de terceiros pelo meio | O código é do cliente, por isso a documentação e a monitorização têm de ser entregues com ele |
| Stacksync (sincronização em tempo real) | Um CRM ou uma base de dados precisa de sincronização bidirecional abaixo do segundo ao lado dos ERP | Costuma ser secundário numa ponte entre ERP |
Se o grupo já tem um iPaaS empresarial como o MuleSoft ou o Boomi, a comparação faz-se ao nível das capacidades: cobertura de conectores para o produto Dynamics ou SAP concreto, como os erros são mostrados e repetidos, quem na equipa pode mudar um mapeamento e quanto custa operá-lo. Não pontuamos plataformas que não vamos implementar. Para o equilíbrio geral entre plataformas, código ponto a ponto e middleware, ver iPaaS, ponto a ponto ou middleware.
Uma ressalva sobre o «tempo real»: nem todos os objetos do ERP precisam dele, e nem todas as vias o entregam. Alterações a clientes e artigos podem muitas vezes ir por eventos; os envios de consolidação seguem normalmente o calendário de fecho; o stock funciona muitas vezes bem como resumo agendado. Indicamos a latência por fluxo, não por projeto.
Governação: fonte de verdade, conflitos e corte
As integrações híbridas falham mais por governação do que por código. Antes de construir, acordamos e deixamos por escrito:
- Um dono por tipo de registo. Os mestres de clientes, fornecedores e artigos têm cada um o seu sistema de referência. O outro lado recebe uma cópia, e as edições ali são bloqueadas ou devolvidas à origem.
- Regras de conflito. O que acontece quando os dois ERP alteram o mesmo campo na mesma janela: que lado ganha e quem é avisado.
- Réplica só de leitura ou escrita dupla. Uma cópia só de leitura é mais simples e mais segura. Escrever dos dois lados é por vezes necessário, e então cada fluxo precisa de idempotência e de um relatório de reconciliação.
- Tabelas de mapeamento com dono. Contas, dimensões, códigos de imposto, unidades de medida e subsidiárias vivem em tabelas mantidas, não dentro da lógica dos fluxos.
- Monitorização desde o primeiro dia. A gestão de erros, as repetições e os alertas são entregues com o primeiro fluxo, e alguém do lado do cliente vê-os.
- Um plano de desativação. Se um dos ERP vai desaparecer, cada fluxo tem data de fim e um passo de corte, e a ponte mantém os dados mestre limpos para esse dia.
O go-live não é o fim. As integrações precisam de alguém que as vigie enquanto os ERP continuam a mudar à volta delas, que é o tema de a vida depois do go-live.
Forma do projeto e porquê a Atypical
Um projeto típico segue esta ordem:
- Descoberta. Que produto Dynamics ou SAP, que entidades, interfaces atuais, regras de propriedade e volumes.
- Via e desenho. Celigo, n8n, à medida ou uma combinação, com as decisões de governação acima por escrito.
- Primeiro fluxo em produção. Normalmente dados mestre ou faturas, em produção em semanas, não em meses.
- Alargamento. Encomendas, intercompanhia, envios de consolidação, pela ordem que elimina mais trabalho manual.
- Operação. Monitorização, repetições, alertas e alterações à medida que os dois ERP evoluem, operados por nós ou entregues à equipa do cliente com documentação.
Somos engenheiros de integração em todo o stack que os grupos europeus do mid-market realmente usam, não um implementador de NetSuite a tentar substituir o outro ERP. Somos parceiro de implementação da Celigo e parceiro da Stacksync, construímos diretamente contra as API quando nenhuma plataforma encaixa e trabalhamos a partir de Espanha em inglês, espanhol, português e catalão. Há mais sobre a equipa em quem somos.