O código do fornecedor não é o vosso: traduzir referências linha a linha
A fatura traz a referência do fornecedor, e o ERP só conhece a vossa. A tradução entre as duas é uma tabela que quase sempre já existe algures na empresa. O que decide se a automação aguenta é o que acontece à linha que não está lá.
A mesma peça, três nomes
Um parafuso sextavado M8 com 30 milímetros, zincado. Para um fornecedor é o 0083321. Para outro é o PSZ-M8X30. No vosso ERP é o PAR-M8-30, porque foi assim que alguém o criou um dia, e é por esse código que o stock, o custo e a margem o conhecem.
A fatura traz o código do fornecedor, porque é o único que ele conhece. Quem a lança traduz cada linha para o vosso: de memória, quando é um fornecedor de todos os dias; com uma folha de Excel aberta ao lado, quando não é; à procura pela descrição, quando a folha não tem aquela linha.
É a parte mais lenta de lançar uma fatura com artigos, e a mais traiçoeira, porque o erro não se vê. Um artigo trocado entra no stock, no custo e na margem com tudo certo à vista, e só aparece no inventário, ou no dia em que alguém estranha um preço.
Três linhas da mesma fatura. As duas que a tabela conhece saem com os vossos códigos; a que não conhece pára o documento, em vez de entrar sem artigo.
Porque é que a descrição não chega
Parece mais fácil procurar pelo nome. Não é. O mesmo parafuso chega como «Parafuso sext. M8x30 zinc.», como «PARAF HEX 8X30 ZN» e como «Paraf. DIN 933 M8x30», às vezes do mesmo fornecedor, em faturas diferentes. Uma descrição é escrita para uma pessoa ler, e cada pessoa abrevia à sua maneira.
A referência é o contrário: é escrita para um sistema, e o fornecedor raramente a muda. O problema é só ser a dele. E há uma armadilha que convém conhecer cedo: o mesmo código pode ser artigos diferentes em fornecedores diferentes. O 1020 de um é uma broca; o 1020 de outro é uma lixa. Por isso a chave da tradução não é a referência sozinha: é o NIF do fornecedor e a referência dele, juntos.
A tabela já existe, só não está num sítio
Em quase todas as empresas que compram com referência, a correspondência já foi feita, aos bocados: um campo na ficha do artigo do ERP, uma folha de Excel de quem lança as compras, a memória de quem as lança há dez anos. O trabalho não é inventá-la. É juntá-la num sítio onde um sistema a possa consultar.
Na forma mais simples são três colunas: o NIF do fornecedor, a referência dele e a vossa. Pode levar mais, e é aí que começa a render: a conta, a unidade, o centro de custo, o que o ERP pedir para lançar aquela linha. A tabela entra por um ficheiro CSV, que é o que qualquer Excel exporta, e depois mantém-se no ecrã, linha a linha.
O que acontece a cada linha
Com a fatura lida, cada linha é procurada na tabela pela chave do fornecedor e da referência. Há três desfechos, e é o terceiro que decide se a automação aguenta.
1. Está na tabela
A linha sai com o vosso código e com o resto do que a tabela diz. É o caso da grande maioria das linhas de um fornecedor habitual, e não precisa de ninguém.
2. Está quase na tabela
A leitura de um documento por IA às vezes perde um carácter: o 0083321 sai 008321. A referência certa está na tabela, a um carácter de distância, e seria tentador ficar com ela. Só que dois artigos diferentes também podem estar a um carácter um do outro, como uma broca BRC-2040 e outra BRC-2046, e escolher o vizinho seria adivinhar.
Por isso a recuperação tem duas condições. Tem de haver um só vizinho a essa distância: com dois, não se escolhe nenhum. E a descrição da mesma linha tem de o confirmar, porque na linha em que a referência saiu estragada a descrição quase sempre saiu certa: se o «M8x30» que a tabela tem para aquele artigo aparece na descrição da fatura, a linha é recuperada, e fica registado que foi. Para isto a tabela precisa de uma coluna com a descrição; sem ela não há com que confirmar, e a linha segue para o terceiro caso.
A leitura perdeu um carácter. Na tabela há um só código a essa distância, e a descrição da mesma linha confirma-o: a linha é recuperada, e fica registado que foi. Com dois vizinhos, ou sem confirmação, pára para alguém ver.
3. Não está na tabela
Uma referência nova: um artigo que o fornecedor passou a vender, ou que nunca lhe tinham comprado. Aqui a escolha errada é a que parece mais prática, deixar a linha entrar sem artigo, ou com um artigo genérico, para não parar o circuito. A linha entra, o ERP aceita, e o buraco só se descobre no inventário.
O que fazemos é o contrário: o documento pára, com o motivo escrito («0077410» não está na tabela de correspondência), e fica marcado como «artigo por mapear». Alguém decide uma vez a que artigo corresponde, acrescenta a linha à tabela e aprova. Ao aprovar, a tradução volta a correr, e a linha já encontra o artigo.
Duas coisas não contam como falta. Uma linha sem referência nenhuma: uma fatura de electricidade não tem artigos, e as suas linhas sem código são o comportamento certo, não avisos. E um artigo por omissão decidido de propósito: quando o artigo não interessa, como em alguns serviços, pode escrever-se na regra qual usar, e aí a linha não pára.
A tabela cresce com o uso
A tabela nunca começa completa, e não precisa. Nas primeiras semanas pára muita coisa: cada fornecedor traz as suas referências, e cada referência nova é uma linha a acrescentar. Mas cada uma só se acrescenta uma vez. Os documentos que esperavam pela mesma linha saem juntos, porque a marca os junta numa lista e aprovam-se de uma vez, e a fatura seguinte com essa referência já não pára por ela.
Ao fim de algum tempo as paragens passam a ser raras, e por isso passam a querer dizer alguma coisa: um artigo novo, um fornecedor novo, ou uma leitura que correu mal. Quantas paragens há por semana é a melhor medida de quão completa está a tabela.
Onde isto encalha, e vale a pena saber antes
Fornecedores que não imprimem referência. Há quem fature só com a descrição. Sem uma chave estável, ou se aceita a descrição como chave, sabendo que muda, ou essas linhas ficam para uma pessoa. Costumam ser poucos fornecedores, e convém sabê-lo antes de contar com eles.
Unidades diferentes. A tradução trata do código, não da quantidade. Se o fornecedor fatura à caixa de cem e o vosso stock conta à unidade, a tabela pode dizer qual é a vossa unidade, mas a conta das quantidades decide-se com quem mantém o ERP, e não deve ficar escondida numa tabela.
A leitura estragada que calha a ser outro código. É o pior caso, e é raro: se o carácter perdido transformar uma referência noutra que também existe na tabela, a correspondência é exacta e o artigo é o errado. A descrição é comparada também quando o código bate certo, e o que não confirma fica registado no documento, mas não o pára.
A decisão é vossa. Não decidimos por vocês a que artigo corresponde uma referência nova. Sugerir pelo nome seria voltar a adivinhar, que é exactamente o que a tabela existe para evitar.
A regra, dita inteira: a referência do fornecedor é dele, a vossa é vossa, e a tradução é uma tabela que se decide uma linha de cada vez. O que não está na tabela não se adivinha: pára, decide-se uma vez, e da vez seguinte já entra sozinho.
Por onde começar
Pela tabela que já existe. Se o ERP guarda a referência do fornecedor na ficha do artigo, a primeira versão sai de uma exportação. Se não guarda, sai das faturas do último mês: as referências que lá aparecem são, por definição, as que importam, e são muito menos do que o catálogo inteiro.
Comece por um fornecedor, o que traz mais linhas por fatura. Ao fim de um mês sabe quantas paragens a tabela dá por semana, quanto tempo leva cada uma a resolver, e se vale a pena estender aos outros.
O resto do circuito é o de qualquer fatura: chega por email, é lida e verificada, e entra no ERP pela porta que ele expõe, sem escrever na base de dados por baixo dele.
Veja o seu caso em concreto
Uma demo de 20 minutos com os seus documentos reais vale mais do que qualquer artigo.
Pedir uma demonstração