Meter faturas no ERP do cliente sem escrever na base de dados

O INSERT directo salta a numeração, o stock, a contabilidade e o imposto. Há um desenho melhor, e cinco perguntas que decidem se o projecto é de duas semanas ou de dois meses.

DocFlow · Agosto de 2026 · leitura de ~5 min

O trabalho que fica depois de o ERP estar instalado

Instalou o ERP, desenhou o plano de contas, formou a equipa, e o projecto fechou. Meses depois há alguém, todos os meses, a copiar faturas de PDF para dentro do sistema que você lá pôs.

Esse trabalho não é do ERP e não é seu. Mas é a si que o cliente o vem pedir, porque foi você que lá pôs o sistema. Este artigo é sobre a forma certa de o resolver, e serve-lhe mesmo que nunca fale connosco.

Porque é que escrever na base de dados é a solução errada

A tentação é óbvia: já conhece o esquema, sabe em que tabela vive o documento de compra, e um INSERT resolve numa tarde o que de outra forma leva semanas. Funciona na demonstração.

E rebenta no fecho do mês, porque um INSERT directo salta tudo o que o ERP faz por si quando um documento entra pela porta da frente: a numeração sequencial do documento, o movimento de stock, os lançamentos contabilísticos, e o apuramento do imposto. O documento existe na tabela e não existe para o negócio.

Em cima, a fatura passa pelas regras do ERP. Em baixo, o INSERT directo salta-as todas.

Há um segundo custo, mais lento: a partir do momento em que escreve por baixo, fica preso à versão do esquema. Uma actualização do ERP que mude uma coluna parte a integração, e a culpa é sua, não do fabricante.

A porta que o ERP já expõe

O desenho alternativo é entrar antes do ERP e entregar pelo mecanismo que ele publica: web service, API, ou a importação que ele já sabe consumir. Quem valida as regras de negócio continua a ser o ERP, que é quem as conhece.

Isso muda o que a peça de automação tem de fazer. Ela não lança nada: lê o documento, verifica o que consegue verificar, e entrega no formato que o ERP aceita. O lançamento continua a ser do ERP.

O que tem de acontecer ao documento antes de lá chegar

Ler os campos é a parte fácil e é a que toda a gente demonstra. A parte que decide se o projecto sobrevive ao primeiro mês é outra: o que acontece quando a leitura está errada.

Há verificações que se fazem sem saber nada do negócio do cliente. O NIF do fornecedor tem um dígito de controlo, e um NIF mal lido não passa. A soma das linhas tem de bater com o total impresso, ao cêntimo, e quando não bate é quase sempre uma quantidade lida na coluna errada. O mesmo ficheiro submetido duas vezes é um duplicado.

Em faturas portuguesas há ainda uma segunda leitura que quase ninguém usa: o código QR que a lei obriga a imprimir. Ele traz o NIF do emitente, o do adquirente, a data e o total, já estruturados. Quando existe, é uma verificação determinística da leitura, e não uma segunda opinião.

A fatura que chega sem saber a que encomenda responde

Este é o ponto que separa uma integração de um depósito de ficheiros, e é o que mais vezes se descobre tarde.

A fatura chega ao ERP com o fornecedor certo, os valores certos e as linhas certas. E sem qualquer ligação ao processo que a originou: a encomenda, a requisição, a obra, o processo interno. Alguém, do outro lado, tem de a casar à mão. Que é exactamente o trabalho que a automação existia para tirar.

A solução é a peça de automação aceitar uma referência sua na submissão e devolvê-la intacta na entrega:

O campo viaja com o documento e sai no payload entregue, ao lado dos campos lidos do papel.

Os dois primeiros campos são lidos da fatura. O terceiro não: foi o integrador que o enviou, e atravessa intacto.

Repare na diferença: o fornecedor e o total foram lidos, com tudo o que isso tem de incerto. A encomenda não foi lida de lado nenhum. Foi enviada por si e devolvida por nós, e por isso não pode estar errada.

O que perguntar antes de aceitar o trabalho

Se o cliente lhe pedir isto amanhã, estas são as perguntas que decidem se o projecto é de duas semanas ou de dois meses. Valem para qualquer ferramenta que venha a escolher.

• O ERP expõe um web service de entrada de documentos? Se não expuser, qual é o caminho suportado: importação de ficheiro, script, tabela intermédia? Nunca a tabela final.
• Que campos são obrigatórios para o lançamento passar? Costuma haver dois ou três que não vêm no papel e têm de sair da configuração, como o centro de custo ou a conta.
• Há tabela de correspondência entre as referências do fornecedor e as do cliente? Se não houver, é preciso construí-la, e isso é trabalho do cliente e não seu.
• Onde vive o documento digitalizado? Muitos ERP guardam o caminho para uma pasta no servidor. Se o ficheiro aparecer lá, o utilizador vê o documento onde sempre viu.
• Quem revê o que for duvidoso, e em quanto tempo? Sem resposta a esta, a fila de excepções cresce até alguém desligar a automação.

Como encaixamos nisto

O DocFlow é a peça que faz a parte de cima: recebe o documento por API ou por email, lê-o, aplica as verificações, e entrega no formato que o sistema do cliente aceita. Um pedido HTTP assinado ao endpoint que indicar, um script para a base de dados de testes, ou um ficheiro.

A configuração dos fluxos é feita connosco e não num portal: diga que campos quer, onde, e com que regras. É a forma honesta de o dizer, e é a que cumprimos.

Há uma página para quem integra com o detalhe técnico, e um guia com o contrato da API que entregamos a quem avança.