Integrar o SAP Business One com o PrestaShop é ligar o ERP, que manda no stock e nos preços, à loja que os mostra e que recebe as encomendas. A ligação usa o Service Layer do SAP Business One e o web service do PrestaShop, e o que mais corre mal é sempre o mesmo: stock que não bate com o armazém e preços que não coincidem com a tabela do ERP.
Para a empresa, um erro de stock significa vender o que não existe, e um erro de preço significa vender abaixo da margem ou perder a venda. Tratamos estas ligações na nossa área de integração de SAP com ecommerce, e este guia concentra-se nos dois pontos mais sensíveis.
Vê aqui como funciona a ligação, como tratar o stock, como tratar os preços, que dados vão em cada sentido e uma lista de verificação para validar antes de arrancar.
Como funciona a ligação entre o SAP Business One e o PrestaShop?
A ligação funciona com duas interfaces oficiais: o Service Layer do SAP Business One e o web service do PrestaShop. Segundo a formação oficial da SAP, o Service Layer segue o mesmo modelo em todos os objetos de negócio: POST cria, GET lê, PATCH atualiza e DELETE apaga.
O PrestaShop, segundo a sua documentação para programadores, oferece uma API CRUD chamada web service, protegida por uma chave de acesso. Cada recurso da loja tem permissões próprias por método, e a chamada à raiz da API mostra o que a chave pode fazer. O formato predefinido é XML; desde o PrestaShop 8.1 é possível pedir a resposta em JSON, mas a API não lê JSON na entrada, pelo que os pedidos de escrita seguem em XML.
Entre os dois sistemas costuma haver uma camada intermédia que traduz formatos, guarda o estado de cada mensagem e repete o que falhou. Sem ela, qualquer falha pontual deixa a loja e o ERP em estados diferentes, sem registo de onde começou.
Como tratar o stock sem vender o que não existe
O stock deve ter um único dono, o SAP Business One, e a loja deve limitar-se a refleti-lo. Na API do PrestaShop, a quantidade vive no recurso stock_availables, que, segundo a documentação, tem os campos id_product, id_product_attribute, quantity, depends_on_stock e out_of_stock. Cada combinação de um produto tem o seu próprio registo.
Isto tem uma consequência prática: um produto com tamanhos e cores tem vários registos de stock, e o código do SAP tem de corresponder a cada combinação, não apenas ao produto. Antes de integrar, confirme que cada variante tem uma referência única no ERP.
Há três decisões que devem ficar escritas:
- Que stock se envia: o físico, o disponível depois de reservas ou o de um armazém específico.
- Quando se atualiza: ao movimento de stock, em intervalos fixos ou ambos.
- O que fazer com o stock em trânsito e com as encomendas ainda não processadas no ERP.
O campo depends_on_stock também faz parte deste recurso. Antes de pôr a integração a escrever quantidades, confirme em cada produto como a loja gere o stock, para que a escrita pela API não colida com outra regra da loja.
Como tratar os preços e as tabelas do ERP
O preço de venda deve sair da lista de preços do SAP, e a loja só aplica o que recebe. O SAP Business One trabalha com listas de preços e preços especiais por cliente ou grupo, enquanto o PrestaShop tem um preço base por produto e regras de preço específico para promoções e descontos.
Na API do PrestaShop, essas regras são o recurso specific_prices. A documentação lista campos como id_product, price, reduction, reduction_type, from e to, o que permite representar um desconto com datas de início e fim. Um preço especial por cliente do SAP não encaixa de forma automática: é preciso decidir se se traduz em regras por grupo de clientes ou se a loja só mostra o preço de lista.
Os erros de preço mais frequentes vêm da mistura entre preços com e sem IVA. Escreva, antes de começar, em que base o SAP envia o preço e em que base a loja o guarda, e teste com artigos de taxas diferentes.
Que dados vão em cada sentido?
Cada dado tem um sistema mestre, e o outro apenas o recebe. Esta é a tabela base que usamos nestes projetos:
| Dado | Sistema mestre | Sentido | Cuidado |
|---|---|---|---|
| Artigos e referências | SAP | SAP para loja | Referência única por variante |
| Stock | SAP | SAP para loja | Por combinação do produto |
| Preços de lista | SAP | SAP para loja | Com ou sem IVA |
| Descontos temporários | SAP | SAP para loja | Datas de início e fim |
| Encomendas | PrestaShop | Loja para SAP | Uma encomenda, um documento |
| Clientes | Definir | Ambos | Evitar duplicados por NIF |
| Estado e expedição | SAP | SAP para loja | A loja mostra, não decide |
A linha mais discutida é a dos clientes. Um cliente que se regista na loja e já existe no SAP não deve gerar um segundo registo, por isso a integração precisa de uma chave de correspondência, como o NIF, e de uma regra para os casos em que não há correspondência.
Como enviar as encomendas para o SAP
Cada encomenda confirmada na loja deve gerar um único documento de venda no SAP. Segundo a formação oficial do Service Layer, uma ordem cria-se com um POST ao recurso Orders, com o código do cliente, a data de entrega e as linhas do documento, e a resposta de sucesso é o código 201.
O ponto crítico é a repetição. Se a ligação falhar a meio e o pedido for reenviado, o SAP pode receber a mesma encomenda duas vezes. Por isso guarde, na camada intermédia, a referência da encomenda do PrestaShop e o número do documento criado no SAP, e verifique-a antes de reenviar.
A documentação do PrestaShop indica ainda que a API permite acompanhar se um recurso mudou, através dos cabeçalhos Content-Sha1 e Local-Content-Sha1, devolvendo 304 quando não houve alteração. Isto ajuda a evitar leituras desnecessárias em catálogos grandes.
Erros que vemos com mais frequência
- Variantes sem referência única. O stock acaba atribuído à combinação errada.
- Chave da API com permissões a mais. A chave deve cobrir apenas os recursos que a integração usa.
- Preços com e sem IVA misturados. A loja mostra um valor diferente do SAP.
- Encomendas duplicadas. Um reenvio sem verificação cria dois documentos.
- Sem registo de erros. A falha só se descobre quando o cliente reclama.
Lista de verificação antes de arrancar
Se faltar uma resposta nesta lista, resolva-a antes de começar:
- Cada dado tem um sistema mestre escrito e aprovado.
- Cada variante tem uma referência única no SAP e no PrestaShop.
- Está definido que stock se envia e com que frequência.
- As regras de IVA, moeda e unidades estão escritas.
- A chave do web service tem apenas as permissões necessárias.
- Existe ambiente de ensaio do SAP e do PrestaShop.
- Há registo de erros e uma pessoa que o recebe e resolve.
- Está escrito o que acontece quando o SAP ou a loja ficam indisponíveis.
Como trabalhamos na Avafa
Começamos por mapear dados e responsáveis, e só depois escolhemos a forma de ligação. Revemos as variantes, o stock e as regras de preço antes de qualquer desenvolvimento, porque é aí que estes projetos falham. Se quiser ver como abordamos este tipo de trabalho, comece pela página de integração SAP com ecommerce.
Guias relacionados do mesmo cluster
Estes guias comparam o mesmo tipo de ligação com outras plataformas e outros ERP:
- SAP S/4HANA como retaguarda do PrestaShop
- SAP Business One com WooCommerce
- SAP Business One com Magento
- SAP Business One com BigCommerce
- Odoo com PrestaShop: ERP, PIM e vendas online
Perguntas frequentes
O PrestaShop tem ligação nativa ao SAP Business One?
A documentação do web service do PrestaShop e a do Service Layer do SAP descrevem duas interfaces independentes, não um conector entre ambos. A ligação faz-se por desenvolvimento ou com uma plataforma de integração.
Posso enviar o stock do SAP em JSON para o PrestaShop?
A documentação indica que, desde o PrestaShop 8.1, a API devolve JSON mas não lê JSON na entrada. Os pedidos de escrita devem, por isso, seguir em XML.
Como represento um preço por cliente do SAP na loja?
Não há equivalência automática. Pode traduzir-se em regras de preço específico por grupo de clientes ou a loja pode mostrar apenas o preço de lista. A escolha depende de quantos preços especiais existem.
Com que frequência devo atualizar o stock?
Depende da rotação dos artigos. Os de venda rápida justificam atualizações frequentes; os restantes podem seguir em intervalos maiores. Defina a frequência por tipo de artigo e teste a carga no servidor da loja.
O que acontece se uma encomenda for enviada duas vezes ao SAP?
Sem controlo, cria dois documentos. Guardar a referência da encomenda da loja e o número do documento do SAP, e consultá-los antes de reenviar, evita o problema.