Integrar o SAP Business One com o SAP Commerce Cloud é ligar um ERP pensado para empresas de média dimensão a uma plataforma de comércio eletrónico de grande escala, de modo a que catálogo, preços, stock e encomendas percorram um processo completo, da loja à fatura. As duas soluções são da SAP, mas isso não significa que venham ligadas de origem.
Para a empresa, a questão é perceber que parte da ligação já existe e que parte tem de ser desenhada. Na documentação da SAP que consultámos, o módulo de integração do Commerce Cloud aparece descrito com cenários de SAP S/4HANA; para o Business One não encontrámos um cenário padrão descrito, pelo que a ligação deve ser tratada como um projeto próprio. Tratamos este tipo de trabalho na nossa área de integração de SAP com ecommerce.
Vê aqui como se liga cada lado, que dados percorrem o processo completo, onde estão os pontos de falha e uma lista de verificação para validar antes de arrancar.
Existe uma ligação padrão entre o SAP Business One e o SAP Commerce Cloud?
Não encontrámos na documentação oficial consultada uma ligação padrão descrita entre o Business One e o Commerce Cloud, por isso a prudência é assumir que a ligação é à medida. A documentação de formação da SAP sobre o módulo Integration API do Commerce Cloud descreve a troca de dados com o SAP S/4HANA Cloud, não com o Business One.
Isto não torna o projeto inviável. Ambos expõem interfaces abertas: o Commerce Cloud pelo módulo Integration API e o Business One pelo Service Layer. O trabalho está em ligar as duas interfaces com regras claras, e isso é feito com uma camada intermédia, como uma plataforma de integração ou um serviço desenvolvido para o caso.
Antes de comprar licenças ou fixar prazos, peça confirmação à SAP ou ao seu parceiro sobre a versão exata do Business One e do Commerce Cloud e sobre o que está suportado para essa combinação.
Como funciona o lado do SAP Commerce Cloud?
No Commerce Cloud, a integração faz-se através de objetos de integração, que definem os dados trocados e expõem um serviço OData. Segundo a documentação de formação da SAP, cada objeto de integração descreve uma entidade de negócio para um caso de uso concreto e, ao ser criado, estende o sistema de tipos do Commerce e disponibiliza um ponto de acesso OData.
Os serviços de entrada (inbound) geram-se a partir dos objetos, pela ferramenta de integração do Backoffice ou por ImpEx. Nos serviços de saída (outbound), o conteúdo enviado a um destino externo pode ser definido de forma dinâmica. A preparação dos serviços passa por definir o modelo de dados, criar uma configuração de canal de entrada para a autenticação, atribuir direitos de acesso e testar os objetos.
A mesma documentação refere que o módulo suporta a monitorização dos pedidos de integração, o que é útil para perceber se uma mensagem chegou e foi aceite.
Como funciona o lado do SAP Business One?
No Business One, a integração faz-se pelo Service Layer, que segue o mesmo modelo em todos os objetos de negócio. Segundo a formação oficial da SAP, POST cria, GET lê, PATCH atualiza e DELETE apaga, e os códigos de sucesso são 201 na criação, 200 na leitura e 204 na atualização e na eliminação.
O exemplo oficial mostra o processo completo de uma venda. Uma ordem cria-se com um POST ao recurso Orders, com o código do cliente, a data de entrega e as linhas. Pode fechar-se com uma ação sobre a própria ordem, e a fatura pode ser criada a partir dela, com POST ao recurso Invoices, indicando o tipo, o número e a linha do documento de origem.
A mesma fonte mostra um limite útil de conhecer: tentar apagar um artigo já usado numa ordem de venda devolve o erro 400, porque existem transações associadas. Uma integração que tente corrigir dados apagando-os vai falhar, e deve corrigir por atualização.
Que dados percorrem o processo completo?
O processo completo tem seis passagens, e cada uma deve ter um sistema mestre e uma regra de erro:
- O artigo e o preço saem do Business One para o catálogo do Commerce Cloud.
- O stock disponível sai do Business One e atualiza a loja.
- O cliente compra e a encomenda nasce no Commerce Cloud.
- A encomenda chega ao Business One como ordem de venda.
- A expedição e o estado voltam ao Commerce Cloud.
- A fatura é criada no Business One e fica disponível para o cliente.
A tabela seguinte resume o sentido e o cuidado de cada dado:
| Dado | Sistema mestre | Sentido | Cuidado |
|---|---|---|---|
| Artigos e preços | Business One | ERP para loja | Listas e moedas |
| Stock | Business One | ERP para loja | Definir stock disponível |
| Encomendas | Commerce Cloud | Loja para ERP | Chave anti-duplicado |
| Clientes | Definir | Ambos | Chave por NIF |
| Estado e expedição | Business One | ERP para loja | A loja mostra |
| Faturas | Business One | ERP para loja | Emitidas no ERP |
Onde costumam falhar estes projetos?
Falham quase sempre por decisões não escritas, não por tecnologia. Os pontos que mais vemos:
- Dois sistemas a mandar no mesmo dado. O preço muda nos dois lados e ninguém sabe qual vale.
- Modelos de dados diferentes. O Commerce Cloud trabalha com catálogos e variantes, e o Business One com artigos e listas de preços.
- Dimensão da equipa. O Commerce Cloud exige competências próprias, e o projeto fica parado quando só uma pessoa as tem.
- Duplicados por reenvio. Sem uma chave por mensagem, a mesma encomenda cria duas ordens de venda.
- Sem monitorização. A falha só aparece quando o cliente reclama.
Antes de avançar, convém perguntar se a dimensão do negócio justifica uma plataforma deste porte. Para muitas empresas, uma loja mais simples ligada ao mesmo ERP chega, e o custo total é bastante menor.
Lista de verificação antes de arrancar
Se faltar uma resposta nesta lista, resolva-a primeiro:
- Cada dado tem um sistema mestre escrito e aprovado.
- A SAP ou o parceiro confirmou a combinação de versões que vai usar.
- Os objetos de integração do Commerce Cloud estão definidos e testados.
- O utilizador técnico do Business One tem permissões mínimas.
- Existe uma chave por mensagem para impedir duplicados.
- Há monitorização dos pedidos de entrada e de saída.
- Existe ambiente de ensaio dos dois sistemas.
- Está escrito o que acontece quando um dos sistemas fica indisponível.
Como trabalhamos na Avafa
Começamos por perguntar se a plataforma e o ERP têm a dimensão certa um para o outro, depois mapeamos dados e responsáveis, e só então escolhemos a forma de ligação. Revemos o desenho antes de qualquer desenvolvimento, para que o projeto não arranque com conflitos de fonte. Se quiser ver como abordamos estes projetos, comece pela página de integração SAP com ecommerce.
Guias relacionados do mesmo cluster
Estes guias comparam a mesma ligação com outros ERP e plataformas:
- SAP S/4HANA com SAP Commerce Cloud
- Microsoft Dynamics 365 com SAP Commerce Cloud
- SAP Business One com Salesforce Commerce Cloud
- SAP Business One com Adobe Commerce Cloud
- SAP Business One com BigCommerce
Perguntas frequentes
O SAP Commerce Cloud liga-se ao SAP Business One sem desenvolvimento?
Na documentação oficial que consultámos, o módulo de integração aparece descrito com SAP S/4HANA, não com o Business One. Por isso, recomendamos assumir que há trabalho de ligação e confirmar o âmbito com a SAP ou o parceiro.
Que API se usa do lado do Business One?
O Service Layer, que expõe os objetos de negócio, como Orders e Invoices, com operações de criar, ler, atualizar e apagar.
Que API se usa do lado do Commerce Cloud?
O módulo Integration API, que cria objetos de integração e expõe serviços OData para dados de entrada e de saída.
Posso corrigir um artigo apagando-o e criando-o de novo?
Se o artigo já foi usado numa ordem de venda, o Service Layer devolve o erro 400 ao tentar apagá-lo. A correção deve ser feita por atualização.
Vale a pena um Commerce Cloud para uma empresa com Business One?
Depende da dimensão do catálogo, do volume e da equipa técnica. Para negócios menores, uma plataforma mais simples ligada ao mesmo ERP costuma ser mais proporcionada.