Um pedido em PDF não contém os códigos e relacionamentos que o Sankhya precisa para registrar uma negociação. Antes de chamar a API, a automação precisa descobrir parceiro, itens, unidades e contexto comercial, além de separar o que foi lido com segurança do que exige decisão humana.
O melhor desenho mantém o Sankhya como responsável pela regra. Extração e correspondência acontecem numa camada anterior; TOP, preço, impostos, confirmação e faturamento continuam sendo aplicados pelo ERP.
Da caixa de e-mail a itens estruturados
O fluxo monitora uma caixa específica, salva anexo e metadados, identifica o cliente e extrai número, datas e linhas. PDFs digitais usam texto nativo; imagens passam por OCR. Cada campo guarda confiança e posição no documento para a tela de revisão.
O código do cliente pode ser conciliado por CNPJ e o produto por código externo, código interno ou atributos. Descrição aproximada gera sugestão, não confirmação automática, quando há variação de embalagem, marca ou unidade.
Como criar a negociação
A documentação Sankhya descreve o Gateway e serviços do módulo MGECOM, incluindo CACSP.IncluirNota e inclusão ou alteração de itens. Também há endpoints REST para consultar pedidos. O conector usa o serviço liberado para o ambiente e um usuário de integração com autorização apenas para as entidades necessárias.
A TOP e o modelo de nota determinam grande parte do comportamento. O payload deve informar empresa, parceiro, itens e referências, mas não replicar regras tributárias no middleware. A confirmação pode ser uma etapa separada para que a revisão ocorra antes de produzir efeitos.
Preço, imposto e faturamento
Preço contextual pode variar por cliente, vendedor, data e condição. A API Sankhya oferece consulta contextualizada e avisa que a simulação de inclusão tem custo de desempenho; portanto, chamadas são agrupadas e usadas onde a regra realmente exige.
O faturamento transforma pedido em nota e exige pedido confirmado, NUNOTA e TOP de faturamento configurada. Automatizar a entrada não significa faturar automaticamente: essa transição deve seguir alçadas, estoque e processo comercial da empresa.
Duplicidade e exceções
Uma chave combina número externo, cliente e hash do arquivo. O NUNOTA e o número do pedido retornados ficam associados a essa chave. Reenvio do e-mail ou timeout não pode criar outra negociação.
Parceiro inexistente, item sem correspondência, preço divergente e TOP inválida aparecem como categorias distintas. A equipe corrige o dado e reprocessa somente a etapa pendente, sem reler nem recadastrar o restante.
Piloto com pedidos reais
O piloto usa layouts variados, ambiente de homologação e um conjunto limitado de clientes. Medimos taxa de itens reconhecidos, tempo de revisão, pedidos aceitos e causas de rejeição.
Para começar, precisamos dos PDFs, empresa e TOP utilizadas, forma atual de localizar parceiro/produto, políticas de preço e acesso à API. A primeira entrega pode criar pedidos pendentes, deixando confirmação e faturamento fora do escopo até a homologação.