Quando uma fatura está em atraso e ninguém faz o acompanhamento
Abre a sua caixa de correio: várias confirmações sem resposta, uma fatura em atraso, lembretes enviados tarde — e ninguém consegue dizer rapidamente se um pagamento foi recebido. Situações do dia a dia assim custam tempo e fluxo de caixa. Uma forma simples de mudar isso é uma ligação direta on‑premise entre o seu sistema Debentra e a contabilidade financeira interna (FiBu) — sem prestadores de serviços em cloud.
Porque um Connector local?
Um On‑prem‑Connector liga o Debentra e a sua FiBu através da rede interna (LAN). Vantagens em resumo:
- Plena soberania dos dados: Sem terceiros, sem armazenamento intermédio na cloud.
- Troca direta de dados: deteção mais rápida de pagamentos e menos trabalho manual posterior.
- Controlo fino: mantém o controlo sobre autorizações, p.ex. em lembretes de pagamento.
Opções de arquitetura – três padrões práticos
Escolha a variante adequada conforme a infraestrutura existente e as políticas de segurança:
1) Exportação de ficheiros baseada em SFTP
O Debentra exporta ficheiros CSV/JSON regulares para um servidor SFTP interno, que o software da FiBu importa automaticamente.
- Vantagens: Fácil de implementar, compatível com muitas ferramentas de FiBu.
- Desvantagens: Latência devido a processamento em batch (p.ex. a cada 5–15 minutos).
2) Webhook interno via LAN
O Debentra envia HTTP‑POSTs em eventos (p.ex. novos saldos em aberto, entrada de pagamento) para um endereço interno protegido, que a sua FiBu recebe.
- Vantagens: Notificação em tempo real, menor atraso.
- Desvantagens: Exige um endpoint permanentemente acessível e uma camada de autenticação.
3) Bridge de API local (middleware)
Uma pequena bridge auto‑hospedada lê exportações do Debentra ou endpoints de API e transforma os dados no formato da FiBu; frequentemente executada num contentor Docker.
- Vantagens: máxima flexibilidade no mapeamento e nas regras de validação.
- Desvantagens: maior esforço de desenvolvimento, mas ajustável a longo prazo.
Preparação: requisitos e verificações
Antes de começar, esclareça estes pontos:
- Quais as opções de exportação que o seu sistema Debentra oferece? (Exportação de ficheiros, Event‑Webhook, API local)
- Que métodos de importação a sua FiBu aceita? (Ingest SFTP, API HTTP, importações manuais de ficheiros)
- Políticas de segurança: segmentação VLAN, regras de firewall, procedimentos de autenticação (SSH‑Key, mTLS, API‑Keys).
- Responsabilidades: Quem autoriza lembretes de pagamento? Quem verifica transferências falhadas?
Implementação prática: passo a passo
1. Definir o caso de uso e o mapeamento de dados
Defina quais eventos e campos devem ser transmitidos. Campos típicos:
- ID da fatura, número do cliente
- Data da fatura, data de vencimento
- Saldo em aberto, pagamentos parciais / estado das prestações
- Estado do pagamento e referência de contabilização
- IDs de documentos ou caminho do PDF (para arquivo na FiBu)
Crie um documento de mapeamento: Campo Debentra → Campo FiBu. Adicione regras de validação (p.ex., campos obrigatórios, valores permitidos para códigos de estado).
2. Exemplo: Configuração SFTP (Exportação baseada em ficheiros)
Passos em resumo:
- Crie um utilizador de sistema dedicado no servidor SFTP interno (p.ex., debentra_sync) e force a autenticação por chave SSH.
- Configure o Debentra para periodicamente (p.ex., a cada 5 minutos) colocar CSV/JSON com itens em aberto numa pasta definida no SFTP.
- Na FiBu, configure um job de importação que consuma ficheiros novos, valide e contabilize. Ficheiros falhados são movidos para uma pasta de quarentena e reportados por e‑mail à equipa.
Dicas práticas:
- Gerar a chave SSH no host do Debentra: ssh-keygen -t ed25519 -f /var/lib/debentra/keys/debentra_sync
- Registar a Public Key no servidor SFTP em ~/.ssh/authorized_keys do utilizador debentra_sync.
- Permissões: pasta de destino apenas gravável por debentra_sync, permissões de leitura para o processo de importação da FiBu.
3. Exemplo: Webhook interno (Tempo real via LAN)
Passos:
- A FiBu disponibiliza via uma interface interna (p.ex., http://fibu-internal.local/api/sync) um endpoint.
- O Debentra configura um webhook que envia payloads para esse endpoint para eventos definidos.
- Proteja o canal: mTLS ou uma API‑Key forte, lista de IPs permitidos e curta duração dos tokens.
Dica de design: Implemente na FiBu um processamento idempotente (p.ex., com base na ID da fatura), para que chamadas repetidas do webhook não gerem duplicados.
4. Exemplo: Ponte de API local (Middleware)
Conceito:
- Desloque uma pequena aplicação ponte (p.ex., Node.js, Python) na sua LAN como um container Docker.
- A ponte consulta exportes do Debentra ou endpoints API, faz o mapeamento de campos e chama a API da FiBu ou grava ficheiros.
- Inclua logging, tentativas de reenvio e uma Dead‑Letter‑Queue (DLQ) para casos de erro.
Componentes de exemplo:
- Scheduler / Event‑Listener
- Módulo de mapeamento com validação
- Módulo de transporte (cliente SFTP, cliente HTTP com mTLS)
- Monitorização: estatísticas de exportação e alertas de erro por e‑mail/Teams
Segurança e operação
- Rede: Permitir apenas IPs internos, aplicar regras de firewall em pontos críticos.
- Autenticação: Chaves SSH, mTLS, tokens de API de curta duração.
- Registos & conservação: Manter logs de exportação e protocolos de transferência pelo menos pelo período exigido pelas suas políticas internas.
- Backups: Versionar configurações e templates de mapeamento, arquivar o container bridge como imagem.
- Monitorização: Health checks dos componentes do conector e notificações automáticas em caso de falhas.
Integração de processos: manter aprovações e controlo
Mesmo com automação, o controlo permanece com o utilizador. Defina regras que desencadeiem uma aprovação manual antes de enviar lembretes de pagamento (por exemplo, para valores elevados ou itens em disputa). Debentra permite preparar lembretes e enviá‑los para aprovação às pessoas responsáveis — a sua solução de conector deve encaminhar e respeitar essa informação de aprovação.
Casos de erro e recuperação
Planeie para problemas típicos:
- Falha de rede: Enfileiramento no export do Debentra ou na Bridge, tentativa automática de reenvio.
- Erro de mapeamento: Quarentena com notificação à equipa de contabilidade.
- Duplicados: Processamento idempotente com base em IDs únicos.
Exemplo prático resumido
Uma empresa de médio porte utiliza o Debentra. Escolhem a variante SFTP: o Debentra exporta a cada 10 minutos os itens em aberto como JSON para /outgoing/openitems/. Um timer systemd no servidor da contabilidade recolhe novos ficheiros, valida‑os e lança automaticamente as contabilizações ou marca para verificação manual. Em casos disputados, o ficheiro é movido para uma pasta de quarentena e entregue à equipa via ticket. Assim reduz‑se o trabalho manual de reconciliação e a contabilidade mantém controlo total dos dados.
Conclusão
Uma ligação de contabilidade on‑prem entre o Debentra e a sua contabilidade é tecnicamente viável e melhora a transparência e a segurança dos processos, sem colocar dados em clouds externas. Escolha a arquitetura (SFTP, webhook interno, bridge de API local) conforme as suas necessidades e documente o mapeamento, as regras de segurança e os cenários de falha. Importante: automatize, mas mantenha pontos de aprovação para ações críticas.
Interessado numa solução que combine visão central, controlo de processos e soberania dos dados? Debentra está disponível como software self‑hosted nas edições BASIS, PRO e PREMIUM — PRO reduz a reconciliação manual, PREMIUM oferece integração contabilística adicional. Edition wählen
Próximo passo
Experimentar o Debentra
Visão central e controlo de processos para itens em aberto e pagamentos com total soberania dos dados; reduz o trabalho de reconciliação manual (PRO) e permite contabilidade integrada (PREMIUM); modelos de instalação e licenciamento à escolha.