Pular para o conteúdo
← Voltar para os cases

RPA fiscal e bancário híbrido, de Power Automate a API própria na AWS

Automação de obrigações fiscais e de rotinas bancárias com a regra dentro do ERP e a execução fora dele, em Power Automate e numa API própria na AWS, com retentativa e observabilidade.

Setor
Produto interno de automação e clientes industriais
Período
2023 — 2026
Atuação
Autoria integral do módulo financeiro e do monitor
Escala
Automação multiempresa em produção

100%

das regras fiscais dentro do ERP

2

frentes automatizadas (fiscal e bancária)

24/7

monitoramento com alerta ativo

Tecnologias

Microsoft Power AutomateAzure Logic AppsInterSystems IRISObjectScriptRESTWebhookAWS API GatewayAWS EC2AWS S3OFX / CNABSUFRAMASMTP

Desafio

Boa parte das obrigações fiscais brasileiras não tem API. O portal existe, o arquivo tem formato definido, mas o caminho entre o ERP e o órgão é um navegador com um humano dentro. Vale para download de documento fiscal em emissor nacional. Vale também para a internalização de mercadoria em área de livre comércio, onde um arquivo específico precisa ser enviado e ter o retorno acompanhado por dias.

Do lado bancário o problema é o mesmo: conciliação e lançamento dependiam de alguém abrindo o internet banking de cada empresa do grupo.

A tentação nesses casos é jogar tudo para uma ferramenta de RPA e deixar a regra de negócio morar dentro do robô. Automação assim ninguém consegue auditar, e ela quebra a cada mudança de layout de tela.

Solução

Adotei uma arquitetura híbrida com uma fronteira explícita: toda regra fiscal e financeira fica dentro do ERP; o Power Automate e as Logic Apps só executam a parte que exige um navegador ou um portal externo.

O ERP monta o pacote de trabalho, dispara um cloud flow por webhook autenticado e volta a acompanhar o processo por polling, porque o retorno do órgão pode levar horas ou dias. O robô não decide nada, ele clica e devolve. Quando o layout do portal muda, quebra o fluxo externo e a regra de negócio continua de pé.

Sobre isso construí a camada de observabilidade: log centralizado de cada execução, alerta por e-mail e por WhatsApp em falha, e um painel interno de acompanhamento das execuções, para a equipe de operação ver o que está travado sem abrir o banco de dados.

Em 2026 a frente bancária ganhou uma segunda geração. O ERP passou a acionar uma API própria hospedada na AWS (API Gateway na frente de EC2), acompanha cada execução até ela concluir, falhar ou expirar, baixa do S3 os extratos em OFX e CNAB e os anexa ao registro, com o detalhe de cada operação. Por cima disso vai um job de fallback que roda a cada 15 minutos: apura o desfecho das execuções que ficaram sem resposta e reaciona as que falharam, até um limite de tentativas e de tempo, guardando a cadeia de tentativas e bloqueando disparo duplicado. Entreguei junto o manual de arquitetura e operação do módulo.

No caso da área de livre comércio, o fluxo vai da nota fiscal até a notificação. O ERP gera o arquivo no formato exigido, o robô o submete, o monitor assíncrono acompanha a mudança de situação e o responsável é avisado quando há pendência.

Resultado

Processos que dependiam de alguém sentado num portal passaram a rodar sozinhos, com registro de tudo que aconteceu. E quando falha, alguém fica sabendo na hora e sabe em que etapa parou. Falha silenciosa é o pior defeito de um projeto de RPA, e o alerta ativo existe justamente para não deixar nenhuma passar. Na frente bancária, a falha transitória nem chega a virar chamado: a retentativa resolve antes.

O que esse case mostra

A decisão que sustenta o projeto é onde a regra mora. RPA entrou como último recurso e a observabilidade foi tratada como requisito desde o começo. No meio disso, integração da stack Microsoft de automação e de serviços AWS com um ERP legado, sem que a regra saísse dele.

Travou em algum termo? Tem um glossário. Glossário