O cenário é comum em distribuidores e indústrias: o cliente envia um pedido de compra por e-mail, alguém abre o PDF, procura cada código no Protheus e redigita cabeçalho e itens na rotina MATA410. A automação não deve simplesmente transformar texto em teclas; ela precisa preparar um pedido compatível com as regras comerciais e fiscais do ambiente.
Um fluxo seguro separa leitura, correspondência de cadastros, validação e gravação. Assim, documento bem reconhecido pode seguir automaticamente, enquanto divergência de unidade, preço, CNPJ ou produto vai para uma fila de revisão antes de chegar ao ERP.
Fluxo técnico recomendado
A entrada pode ser uma caixa de e-mail, pasta monitorada ou upload. O arquivo é identificado, passa por extração de texto ou OCR e gera campos estruturados: número do pedido do cliente, CNPJ, endereço de entrega, datas e linhas com código, descrição, quantidade e unidade. O documento original e o resultado extraído recebem o mesmo identificador para manter rastreabilidade.
Depois vem o de/para. Código do cliente e loja são reconciliados com o cadastro; os itens são procurados por código produto-cliente, código interno ou atributos; e as unidades são convertidas apenas por regras aprovadas. Similaridade de texto pode sugerir um produto, mas não deveria confirmar sozinha um item fiscalmente sensível.
Como o pedido entra no Protheus
No Protheus, o pedido de venda é tratado pela MATA410 e envolve cabeçalho SC5 e itens SC6. A própria TOTVS documenta a execução automática da rotina por MSExecAuto, com arrays de cabeçalho e itens e opções de inclusão, alteração ou exclusão. Em ambientes com serviços REST adequados, uma API homologada ou customizada pode encapsular essa regra.
Gravar diretamente em SC5 e SC6 é uma má ideia: isso contorna validações, pontos de entrada e regras do ERP. O conector deve usar o mecanismo suportado no ambiente, devolver o número criado e registrar a mensagem de erro de negócio quando a inclusão for recusada.
Validações que evitam pedido errado
Antes da gravação, vale conferir cliente e loja, condição de pagamento, vendedor, tabela de preços, TES, saldo, quantidade mínima e unidade. O preço trazido pelo PDF não deve sobrescrever automaticamente o preço calculado pelo Protheus sem uma política explícita. Desconto fora da alçada, cliente bloqueado e falta de estoque são resultados operacionais, não falhas do OCR.
A chave de idempotência pode combinar remetente, número do pedido do cliente e hash do arquivo. Se o mesmo PDF chegar duas vezes, o fluxo aponta o pedido já processado em vez de incluir uma duplicata.
Revisão e retorno para a equipe
A tela de revisão deve mostrar o recorte do PDF ao lado do campo extraído, a correspondência sugerida e o motivo da dúvida. Depois da confirmação, a integração tenta criar o pedido e retorna número, status e eventuais bloqueios de crédito ou estoque.
Para dimensionar o projeto, separe amostras por cliente e layout. Vinte PDFs idênticos provam pouco; o piloto precisa incluir digital, escaneado, tabelas quebradas, múltiplas páginas e os clientes que mais geram exceção.
O que precisamos avaliar no diagnóstico
A análise começa pela release do Protheus, módulos utilizados, customizações da MATA410, forma atual de autenticação e possibilidade de executar rotina automática ou API. Também precisamos de pedidos reais anonimizados, volume mensal, cadastros de produto-cliente e regras de preço e aprovação.
Um bom primeiro escopo cobre um canal de entrada, os principais layouts e criação em ambiente de homologação. A meta não é prometer leitura perfeita; é reduzir digitação mantendo as exceções visíveis e auditáveis.