Modelação e automação do processo — da fatura em papel ao pagamento rastreado, com ERP, RPA, low-code e uma camada de serviços.
Micael Alves34613Gestor de Projeto
Flávio Fernandes33215Analista de Integração
Henrique Fernandes33393Analista ERP e RPA
Alexandre Franchyshyn33387Analista Low-Code
Avaliação intermédia · 3 de novembro de 2026 · Docente: Luís Barreiros
Micael · 30 s. “Boa tarde. Nós escolhemos automatizar as contas a pagar de uma pastelaria típica de Viana do Castelo. Hoje é tudo à mão: as faturas chegam em papel ou por email, os dados são copiados para uma pasta e o pagamento acaba por depender da memória de quem gere a pastelaria. O que vamos mostrar é como é que isto pode funcionar de forma automática — com um robot a ler as faturas, um ERP onde ficam registadas, um portal para o gestor aprovar e um serviço de banco simulado para os pagamentos.”
01 · Contexto
O processo funciona — mas custa tempo, erros e dinheiro
10
fornecedores regulares — farinha, ovos, lacticínios, café, embalagens, energia
40–80
faturas por mês, recebidas em PDF por email ou em papel
100 %
do processo atual é manual: papel, memória e folhas de cálculo — sem dados para negociar
—Faturas guardadas em pasta física; dados escritos à mão, com erros de lançamento
—Pagamentos dependem da memória do gestor: atrasos, juros e sanções
—Saber o gasto por fornecedor obriga a reabrir as faturas uma a uma
—Subidas de preço dos artigos passam despercebidas — sem dados para negociar
Micael · 1 min. “Só para dar noção do tamanho: são cerca de dez fornecedores e quarenta a oitenta faturas por mês — farinha, ovos, café, embalagens, energia. E o problema não é só o tempo que se perde. É que, sem dados, também não se consegue negociar com os fornecedores: quando a farinha sobe, ninguém dá por isso até ser tarde. Portanto temos quatro dores: horas perdidas, erros de lançamento, pagamentos atrasados com juros, e zero visão de custos.”
02 · O processo
Sete etapas — e um único ponto de passagem
Sete diagramas BPMN 2.0 modelados no Bizagi — um por etapa, com todos os intervenientes.
1Entradaportal Mendix ou anexo de email
2Extraçãorobot UiPath OCR com confiança
3Validaçãoduplicado · fornecedor · qualidade da leitura
4Lançamentofatura em rascunho no Moloni ON
5Aprovação<150 € automática senão o gestor decide
6Pagamentoordem SEPA na data de vencimento
7Arquivopesquisa e histórico de preços
Tudo converge na camada de serviços — nenhum canal fala diretamente com o ERP.Foi isso que permitiu trocar o ERP a meio do projeto sem mexer nos canais nem nas regras.
BPMN 3 · validação — Figura 4 do relatório
Micael · 1,5 min. “Modelámos o processo em sete passos, todos em BPMN no Bizagi. A fatura entra pelo portal ou pelo email; o robot lê; depois validamos três coisas: se é duplicada, se o fornecedor já existe e se a leitura está boa. Lançamos no ERP em rascunho, o gestor aprova — abaixo de 150 euros é automático — o banco paga na data de vencimento e, no fim, fica tudo arquivado e a alimentar o painel de custos. Reparem numa coisa: há sempre um sítio por onde tudo passa, que é a camada de serviços. Foi isso que nos deixou trocar de ERP a meio sem mexer no resto.”
03 · Arquitetura
Três camadas, um ponto de passagem obrigatório
Flávio · 1,5 min. “Esta é a arquitetura, vista de cima para baixo. Em cima estão os canais: o portal e o email. No meio está o n8n, que é a nossa camada de serviços — é ele que recebe tudo, aplica as regras e fala com os sistemas. Em baixo estão o robot, o Moloni e o banco simulado. As etiquetas I1 a I5 são os pontos de integração: o email entra por IMAP, o portal fala por REST, o robot recebe o PDF numa fila e devolve JSON, o Moloni é GraphQL e o banco é um serviço REST que nós construímos. E o mais importante: nenhum canal fala diretamente com o ERP — é sempre o n8n que faz a ponte.”
04 · Integração
Decisões que sustentam a arquitetura
ID
Ligação
Tecnologia
I1
Canais → serviços
REST interno e IMAP
I2
Serviços → UiPath
fila Orchestrator · resposta JSON
I3
Serviços → Moloni ON
GraphQL sobre HTTPS, token Bearer
I4
Serviços → banco
REST próprio: ordem, estado, callback
I5
Portal → serviços
REST interno: upload e aprovações
BANCO SIMULADO
As APIs PSD2/PISP exigem intermediários licenciados. O contrato é real — ordem SEPA, estados, callback —, só a execução é simulada.
N8N SELF-HOSTED
Docker, sem limites de SaaS. A API interna é única para todos os canais; as regras vivem em JavaScript, visíveis e auditáveis.
POSTGRESQL
Fonte de verdade do estado do processo e histórico de preços — alimenta os alertas de variação e o comparador entre fornecedores.
Flávio · 1 min. “Aqui estão as decisões que tomámos. O banco é simulado porque, em Portugal, as APIs bancárias a sério só estão acessíveis através de intermediários licenciados — mas o contrato é o mesmo: ordem SEPA, estados e callback. O n8n é nosso, corre em Docker e dá-nos uma API interna única, com as regras em JavaScript. E o PostgreSQL guarda o estado do processo e o histórico de preços, que é o que permite os alertas de subida e o comparador entre fornecedores. Se perguntarem se o n8n é tipo Zapier: não — é self-hosted, tem API própria e as regras são código nosso.”
05 · ERP
O ERP que entrou quando o Jasmin saiu
—Solução portuguesa, certificada pela AT, do grupo Visma
—API pública e documentada — GraphQL, com Explorer para testar
—Faturas e recibos de fornecedor com anexo: o PDF fica arquivado no ERP
—Validámos o fluxo na interface — fornecedor e fatura criados à mão (Figuras 9–11 do relatório)
Jasmin (Cegid)→Moloni ON · Jasmin descontinuado a meio da análise
Rascunhoeditável · sem número uso interno
aprovação · P5
Finalizadobloqueado · numerado comunicado à AT
O ciclo de vida dos documentos encaixa no processo: a fatura entra em rascunho no lançamento (P4) e só é finalizada depois de aprovada — nunca se lança diretamente para o registo definitivo.
Henrique · 1,5 min. “O ERP que usamos é o Moloni ON. Começámos com o Jasmin, que era o sugerido na unidade curricular, mas o Jasmin foi descontinuado pela Cegid a meio do projeto — por isso mudámos. O Moloni é português, está certificado pela Autoridade Tributária e tem uma API pública, que é o que nós precisamos. Há uma coisa que encaixa muito bem no nosso processo: os documentos têm dois estados — rascunho, que se pode editar, e finalizado, que fica bloqueado e é comunicado às Finanças. Então lançamos a fatura em rascunho e só a finalizamos depois de aprovada.”
06 · API do ERP
Um endpoint: query para ler, mutation para escrever
POST https://api.molonion.pt/v1
Query · ler
supplierspesquisar o fornecedor pelo NIF (GW2)
supplierInvoicesdetetar duplicados (GW1) e consultar o arquivo
getSupplierRelatedDocumentshistórico por fornecedor para o dashboard
Mutation · escrever
supplierCreatecriar fornecedor depois de aprovado (RN3)
supplierInvoiceCreatelançar a fatura em rascunho, com o PDF anexado
supplierReceiptCreateregistar o pagamento quando o banco confirmar
Autenticação por API Key (Bearer apik:…) — integração máquina-a-máquina: é o n8n que fala com o Moloni, em nome da pastelaria.Os erros de validação vêm no corpo da resposta — verificar só o código HTTP não chega.
Henrique · 1 min. “A API é GraphQL: há só um endereço, e os pedidos são queries, para ler, ou mutations, para escrever. Por exemplo, o suppliers serve para procurar o fornecedor pelo NIF; o supplierInvoiceCreate lança a fatura em rascunho com o PDF anexado; e o supplierReceiptCreate regista o pagamento quando o banco confirma. Usamos uma API Key porque é o n8n que fala com o Moloni, sem ninguém a clicar. Uma coisa que aprendemos: os erros vêm no corpo da resposta, por isso não basta ver se o pedido falhou pelo código HTTP.”
07 · Prova de conceito
A prova: as mesmas operações, feitas à mão
Documento de fornecedor gerado na conta de testes — Figuras 9–11 do relatório
Fornecedor criado na ficha de fornecedores, com NIF e contactos.
Fatura lançada em rascunho com linha de artigo, IVA e data de vencimento — e o PDF anexado.
São exatamente as operações que o n8n vai executar: supplierCreate e supplierInvoiceCreate.
Lista de fornecedores na conta de testes
Henrique · 1 min. “Isto é a prova de que o processo funciona mesmo antes de estar automatizado. Entrámos na conta de testes do Moloni e fizemos à mão exatamente o que o n8n vai fazer: criámos o fornecedor, lançámos a fatura em rascunho com o PDF anexado, e o ERP gerou o documento. Ou seja, não estamos só a dizer que a API permite — mostrámos que o processo faz sentido de ponta a ponta. O que falta é ligar as peças pela API, e isso é a fase de implementação.”
08 · RPA
Robot UiPath — da caixa de email ao JSON
01Caixa de emailIMAP da caixa dedicada às faturas
02Fila Orchestratoritem criado com o PDF original
03Document UnderstandingOCR e extração com confiança por campo
Henrique · 1 min. “Do lado do robot, o UiPath lê a caixa de email, mete o PDF na fila do Orchestrator e usa o Document Understanding para fazer o OCR. O resultado é este JSON, com os dados da fatura e um grau de confiança por campo. Se o NIF não se ler ou a confiança for baixa, a fatura não segue sozinha: vai para revisão no portal, onde o gestor compara com o PDF. E o PDF original fica sempre anexado — o JSON nunca anda sozinho.”
09 · Low-code
Portal Mendix — o gestor no comando
Upload rápidosubmeter o PDF ou a foto
Revisão de extraçãoPDF e campos lado a lado, corrigir e seguir
Aprovaçõesfaturas ≥ 150 €: aprovar, agendar ou rejeitar
Arquivopesquisa por fornecedor, data e valor
Dashboard de custostotais, histórico de preços e alertas
FaturaProcesso1 → NLinhaFaturaestado, canal de entrada, confiança da extração
Fornecedornif, nome, IBAN — espelho do Moloni ON
HistoricoPrecoartigo × fornecedor × preço — alimenta alertas e comparador
O portal consome apenas a API interna do n8n — nunca fala com o Moloni nem com o robot. Certificação Mendix Rapid Developer concluída.
Alexandre · 1,5 min. “O portal é feito em Mendix e é a interface do gestor — é a lane do gestor nos BPMN, é ali que o humano entra. Tem cinco páginas: upload, revisão da extração com o PDF ao lado dos campos, aprovações acima de 150 euros, arquivo pesquisável e o dashboard de custos. Do lado dos dados temos a fatura com as suas linhas, o fornecedor e o histórico de preços. O portal só fala com o n8n — nunca diretamente com o Moloni nem com o robot. E a certificação Rapid Developer ficou feita dentro do prazo, a 15 de outubro.”
10 · Regras de negócio
Seis regras, todas na camada de serviços
RN1
Fatura sem NIF legível segue obrigatoriamente para revisão humana.
RN2
Duplicado — mesmo número e fornecedor — é rejeitado automaticamente, com alerta.
RN3
Fornecedor novo exige aprovação do gestor antes do lançamento.
RN4
Aprovação automática apenas abaixo de 150 € — valor configurável.
RN5
O pagamento nunca é executado depois da data de vencimento.
RN6
Artigo que suba mais de 5 % face à média de 3 meses gera alerta no portal.
As regras estão no n8n, não nas interfaces: qualquer canal que se acrescente no futuro herda-as automaticamente.
Alexandre · 45 s. “Estas são as regras que o gestor vê no portal. Sem NIF legível vai a revisão; duplicados são rejeitados automaticamente; fornecedor novo tem de ser aprovado; acima de 150 euros o gestor decide; o pagamento nunca passa do vencimento; e se um artigo subir mais de 5 por cento face à média dos últimos três meses, aparece um alerta. E como as regras estão no n8n, qualquer canal que se acrescente no futuro herda-as logo. Se perguntarem porque 150 euros: é um valor típico de pequeno comércio — matéria-prima diária fica abaixo, equipamento fica acima — e é configurável.”
11 · Gestão do projeto
Planeamento até janeiro, 90 horas já registadas
S1 novS2S3S4S1 dezS2S3S4S1 janS2
Modelação BPMN
Portal Mendix
Robot UiPath
Workflows n8n
Integração Moloni ON
Testes fim-a-fim
Relatório final
Vídeo demonstração
Horas por elemento · diário, 5 semanas — 90 h no total
21
Flávio
21
Alexandre
26
Micael
22
Henrique
Marcos
3 novintermédia — hoje
nov–dezimplementação
10 janrelatório final
11 janvídeo
12 janapresentação
Coordenação assíncrona no Discord · repositório único no GitHub, uma pasta por componente · contratos de integração acordados antes do código · ciclos semanais de planificação e balanço.
Micael · 1,5 min. “Sobre a gestão do projeto: este é o Gantt da fase de desenvolvimento, de novembro até à entrega final. A implementação é em novembro e dezembro, com menos carga no Natal, e os testes ficam antes do fecho. Em baixo, as horas do diário: noventa horas em cinco semanas, equilibradas entre os quatro — vinte e uma, vinte e uma, vinte e seis e vinte e duas. Como é que trabalhamos: falamos no Discord, o código e a documentação estão no GitHub e cada um escreve a sua parte do relatório, que eu junto no fim.”
12 · Próximos passos
Do desenho à execução
nov–dezrobot, workflows n8n, API do Moloni, portal
deztestes fim-a-fim: fatura → pagamento → alerta
10 janrelatório final (secção 5, implementação)
11–12 janvídeo e apresentação pública
Obrigado.
Perguntas — respondemos todos os elementos.
Micael · 30 s. “Para terminar: o que falta é a implementação — o robot, os workflows, a API do Moloni e o portal — e depois os testes de ponta a ponta. O relatório final é a 10 de janeiro. Obrigado, ficamos por aqui para as perguntas.”
