Integrar o SAP S/4HANA com o PrestaShop é usar o ERP como retaguarda de uma loja PrestaShop: o SAP guarda artigos, preços, stock e documentos, e a loja vende e envia as encomendas de volta. A ligação apoia-se nos serviços OData do SAP e no webservice do PrestaShop, que é uma API própria com chave de acesso e permissões por recurso.
É uma combinação menos comum do que SAP com Adobe Commerce ou Magento, e por isso mal documentada em português. O PrestaShop é leve e flexível, mas tem particularidades de formato e de permissões que condicionam o desenho. Tratamos estes projetos dentro da nossa área de integração de SAP com ecommerce.
Neste artigo vê quando esta combinação faz sentido, como funciona o webservice do PrestaShop, que fluxos montar, que limites existem e uma lista de verificação para validar antes de arrancar.
Quando faz sentido usar o SAP S/4HANA com o PrestaShop?
Faz sentido quando a loja é de dimensão média, o catálogo está no SAP e a equipa quer evitar uma plataforma de comércio mais pesada. Os cenários mais comuns são estes:
- Empresas com SAP que abrem um canal online B2C ou B2B simples.
- Lojas PrestaShop que já existiam e agora precisam de stock e preços do ERP.
- Marcas que vendem em várias lojas e querem um único catálogo no SAP.
- Projetos em que o custo de uma plataforma empresarial não se justifica.
Se o negócio exige regras de preço muito complexas, vários países com impostos distintos ou milhares de encomendas por hora, convém comparar com plataformas mais robustas antes de decidir.
Como funciona o webservice do PrestaShop
O webservice do PrestaShop é uma API REST que expõe os recursos da loja (produtos, encomendas, clientes, stock) com uma chave de acesso e permissões por recurso e por método. Segundo a documentação oficial do PrestaShop, a chave é usada como nome de utilizador, sem palavra-passe, e o método recomendado é enviá-la num cabeçalho de autorização Basic.
Cada recurso indica quais dos métodos get, put, post, patch, delete e head estão permitidos para essa chave. Isto permite criar uma chave só com as permissões necessárias para a integração, em vez de uma chave com acesso a tudo. Quem tiver a chave tem os direitos dela, pelo que deve ser tratada como uma credencial.
| Tema | O que a documentação indica | Impacto |
|---|---|---|
| Formato | XML por omissão | Camada de integração converte |
| JSON | Só na saída, desde a versão 8.1 | Escrita continua em XML |
| Filtros | filter, display, limit e sort | Leituras seletivas |
| Cache | Content-Sha1 desde a versão 8.0 | Evita descarregar sem mudanças |
O ponto que mais surpreende as equipas é o formato: a escrita faz-se em XML, e o XML enviado em PUT não deve ter espaços de formatação dentro das etiquetas. Uma resposta limitada com display que não seja full também não pode ser reenviada num PUT.
Que fluxos montar entre SAP e PrestaShop
Cada fluxo deve ter um dono, um sentido e um mecanismo de repetição. A matriz de arranque que usamos é esta:
| Fluxo | Sentido | Recurso PrestaShop | Cuidado |
|---|---|---|---|
| Artigos e preços | SAP para loja | products | Variantes e combinações |
| Stock | SAP para loja | stock_availables | Stock vendável, não físico |
| Encomendas | Loja para SAP | orders | Chave única |
| Clientes e moradas | Loja para SAP | customers, addresses | NIF e IVA |
| Estados | SAP para loja | order_histories | Aviso por email |
O parâmetro sendemail pode enviar emails ao cliente quando se atualiza o histórico ou o transportador de uma encomenda. Se o SAP atualiza estados em lote, convém decidir se quer mesmo que cada atualização gere uma mensagem.
O lado do SAP S/4HANA
O SAP expõe os dados por serviços OData, e as escritas exigem normalmente um token CSRF obtido com um GET prévio que leva o cabeçalho x-csrf-token com o valor fetch. Nas versões em cloud, o acesso externo define-se com utilizadores, sistemas e acordos de comunicação. Para produção, o método de autenticação mais indicado é o OAuth 2.0.
Como o PrestaShop não tem fila nativa para integrações, a camada intermédia ganha mais importância. É ela que guarda as mensagens, tenta de novo quando um dos lados falha e regista o que aconteceu.
Passos para um arranque seguro
- Criar uma chave do webservice só com as permissões que cada fluxo precisa.
- Usar o parâmetro schema=synopsis para ver os campos de cada recurso e schema=blank para obter o modelo de criação.
- Importar um subconjunto de artigos para uma loja de testes e comparar com o SAP.
- Enviar encomendas de teste e validar o documento criado no SAP, incluindo IVA e portes.
- Simular falhas de um dos lados e confirmar que não se perdem nem duplicam encomendas.
- Passar a produção por fases e rever diariamente as diferenças nas primeiras semanas.
Dados mestre: o que limpar no SAP antes de ligar
A maioria dos problemas de uma integração nasce nos dados e não nas APIs. Antes de ligar o SAP ao PrestaShop, reveja o que vai aparecer na loja, porque tudo o que estiver incompleto ficará à vista do cliente.
- Descrições comerciais: o texto técnico do ERP raramente serve para vender, e o PrestaShop precisa de nome, descrição curta e descrição longa por idioma.
- Unidades de medida: caixas, paletes e unidades têm de ter conversão clara, ou o cliente compra a quantidade errada.
- IVA e categorias fiscais: a taxa do artigo no SAP tem de coincidir com a regra de impostos da loja.
- Referências: uma referência única por artigo, igual nos dois sistemas, é a base de todos os fluxos.
- Artigos descontinuados: decida se saem da loja, ficam ocultos ou continuam vendáveis até acabar o stock.
Se o catálogo vive num PIM em vez de no SAP, o PIM passa a ser a origem das descrições e o SAP fica com preços, stock e documentos. Essa divisão deve ficar escrita antes de se desenhar qualquer fluxo.
Riscos mais comuns
- Variantes e combinações do PrestaShop que não têm correspondência direta nos artigos do SAP.
- Módulos de terceiros que alteram o checkout e mudam os dados enviados.
- Chaves do webservice com permissões a mais, que ficam em ficheiros de configuração.
- Stock partilhado entre a loja e outros canais sem uma regra de reserva.
- Falta de monitorização: o fluxo pára e só se nota quando alguém reclama.
Lista de verificação antes de contratar
- Está definido qual sistema manda em artigos, preços, stock e clientes.
- Os artigos do SAP têm referência única e unidades de medida coerentes.
- Há loja de testes e ambiente de testes do SAP.
- As permissões do webservice estão limitadas ao necessário.
- Existe regra para variantes, combinações e kits.
- Está definido o que acontece quando uma encomenda falha e quem a resolve.
- A versão do PrestaShop e dos módulos instalados está suportada.
Como trabalhamos na Avafa
Antes de escolher ferramentas, mapeamos os dados, os responsáveis e os casos de erro. Depois definimos os fluxos prioritários e o plano de testes. Pode ver como organizamos estes projetos na nossa página de integração de SAP com ecommerce.
Outras plataformas ligadas ao SAP
- SAP S/4HANA e Magento: pedidos, stock e preços
- SAP S/4HANA com Adobe Commerce
- SAP S/4HANA com BigCommerce
- SAP S/4HANA com WooCommerce
- SAP Business One e PrestaShop: stock e preços
Perguntas frequentes
O PrestaShop aceita JSON no webservice?
Apenas na saída. Segundo a documentação do PrestaShop, desde a versão 8.1 é possível pedir respostas em JSON, mas a entrada de dados continua a fazer-se em XML.
Como autentica o webservice do PrestaShop?
Com uma chave de acesso usada como nome de utilizador, sem palavra-passe. A documentação recomenda enviá-la num cabeçalho de autorização e avisa que quem tiver a chave tem os respetivos direitos.
Posso limitar o que a integração pode fazer?
Sim. A chave tem permissões por recurso e por método, pelo que se pode dar acesso de leitura a uns recursos e de escrita a outros.
Preciso de uma camada intermédia?
É o desenho mais seguro. Concentra filas, repetições e registo de erros, algo que o PrestaShop e o SAP não resolvem sozinhos numa ligação direta.
Qual o primeiro fluxo a automatizar?
O stock e as encomendas. São os que mais erros visíveis causam e permitem validar a ligação antes de tratar clientes, estados e preços especiais.