Arquitetura de extensões
Algumas capacidades são inerentemente locais ou específicas de provedor — mandatos governamentais de fatura eletrônica, feeds de dados bancários. A REDA Financials trata desses casos com uma arquitetura de extensões: o núcleo permanece agnóstico em relação ao provedor, e pacotes de extensão plugáveis fornecem as conexões específicas de cada país ou provedor.
O modelo
- O núcleo fornece as tomadas: objetos de configuração que descrevem onde um provedor se conecta — uma configuração de fatura eletrônica por entidade, uma configuração de feed bancário por conta bancária — além dos objetos de auditoria que registram o que passa por ali.
- As extensões fornecem os plugues: um pacote de extensão de provedor implementa a conexão real (uma câmara de compensação nacional de fatura eletrônica, um serviço de agregação bancária) e se registra nessa configuração.
- Seus documentos nunca mudam: faturas, recibos e extratos permanecem idênticos, seja qual for o provedor por trás deles. Troque de provedor e a contabilidade não percebe.
Quem fornece o quê
Vale explicar a divisão de trabalho entre tomada e plugue, porque ela determina a quem você recorre quando algo precisa mudar:
| Peça | Fornecida por | Exemplos |
|---|---|---|
| As tomadas — configuração que descreve onde um provedor se conecta | O núcleo da REDA Financials | Uma configuração de fatura eletrônica por entidade; uma configuração de feed bancário por conta bancária |
| Os objetos de auditoria — o registro do que passa por ali | O núcleo | A trilha de envio anexada a cada documento com fatura eletrônica |
| Os plugues — a conexão real com um provedor | Um pacote de extensão | Uma conexão com uma câmara de compensação nacional de fatura eletrônica; um serviço de agregação bancária |
| A escolha do provedor — qual plugue preenche qual tomada | Você, na configuração | Apontar a configuração de fatura eletrônica de uma entidade para o provedor instalado |
O que isso significa para cada função
| Função | O que muda com uma extensão | O que nunca muda |
|---|---|---|
| Administrador | Instala o pacote de extensão do provedor e o registra na configuração relevante — por entidade ou por conta bancária. | O Console de Administração, a configuração do núcleo, o calendário de atualização do núcleo contábil. |
| Usuário contábil | Nada. Faturas, recibos e extratos são criados e contabilizados exatamente como antes. | Todas as telas, todos os hábitos — os documentos permanecem idênticos, seja qual for o provedor por trás deles. |
| Auditor / revisor | Ganha uma trilha por documento do que passou pelo ponto de extensão. | A cadeia de evidências do núcleo: Log de auditoria, histórico de campos, livro razão imutável. |
Os dois pontos de extensão de hoje
| Ponto de extensão | O que ele habilita | Detalhes |
|---|---|---|
| Fatura eletrônica | Envio de faturas a plataformas governamentais onde a lei exige, com uma trilha de envio completa por documento. | Extensões de fatura eletrônica |
| Feeds bancários | Entrega automática de extratos bancários por provedores de agregação, alimentando a importação de extratos bancários sem CSVs. | Extensões de feed bancário |
Por que foi construído assim
Mandatos e provedores mudam com frequência — países implantam a fatura eletrônica em etapas, bancos trocam de agregadores. Manter essas integrações em pacotes separados significa que o núcleo contábil é atualizado em seu próprio calendário, as extensões no delas, e uma regulamentação do outro lado do mundo nunca desestabiliza o seu fechamento. Isso também significa extensibilidade orientada por configuração em toda parte: as extensões podem adicionar seus campos a documentos e PDFs sem alterações de código no núcleo.
Um exemplo prático — os dois plugues da Meridian
A organização da Meridian Properties Group mostra os dois pontos de extensão em uso, e o padrão se mantém em ambos os casos:
O Brasil precisa de fatura eletrônica governamental
O Brasil opera um regime de validação de faturas, então o administrador instala o pacote de extensão do provedor e aponta a configuração de fatura eletrônica da entidade brasileira para ele. A partir daí, o envio de cada fatura contabilizada — enviada, aceita ou rejeitada, com a resposta da autoridade — fica registrado na trilha da fatura. O fluxo de trabalho da equipe de contas a receber não mudou nem um clique.
O banco dos EUA oferece um feed
O administrador instala a extensão de um provedor de feed e a registra na configuração de feed da conta bancária operacional. Os extratos agora chegam sozinhos como extratos e linhas bancárias comuns — idênticos às importações de CSV que a entidade do Reino Unido ainda faz manualmente, de modo que a conciliação é lida da mesma forma em ambos os países.
Um provedor muda — a contabilidade não
Se o provedor do Brasil for trocado algum dia, o novo plugue preenche a mesma tomada: documentos, trilhas e contabilidade permanecem idênticos. Essa troca sem retrabalho é todo o argumento da arquitetura.
Erros comuns a evitar
| Erro | Por que prejudica | Faça isto em vez disso |
|---|---|---|
| Construir uma integração personalizada onde já existe um ponto de extensão | Você reimplementa a tomada que o núcleo já fornece — e assume a manutenção para sempre | Use o ponto de extensão; pergunte à REDA quais pacotes de provedor existem para seus países e bancos |
| Esperar por uma extensão antes de configurar o núcleo | Nada na configuração do núcleo precisa de retrabalho quando uma extensão chega — esperar só atrasa a contabilidade | Configure entidades, bancos e documentos agora; conecte os provedores quando estiverem prontos |
| Esperar que os usuários aprendam novos passos quando uma extensão entra em produção | Eles não deveriam — as extensões atuam sobre a contabilização e a chegada de extratos, não sobre novos hábitos | Se um plano de implantação inclui retreinar a entrada de documentos, questione o plano |
| Vincular o calendário de fechamento à atualização de uma extensão | O núcleo e as extensões são deliberadamente atualizados em calendários separados | Trate as atualizações de extensões como pequenos eventos próprios, não como bloqueadores do fechamento |
| Supor que um único provedor cobre todos os países ou bancos | Mandatos e cobertura são regionais por natureza | Verifique a disponibilidade por país e por banco — os dois artigos de detalhe explicam como |
O que vem a seguir
- Extensões de fatura eletrônica · Extensões de feed bancário — os dois pontos na prática.
- Pacotes de extensão (visão do desenvolvedor) — para equipes que vão construir uma.
Perguntas frequentes
Não — essa é a promessa central do design. Os documentos permanecem idênticos, seja qual for o provedor por trás deles; as extensões mudam o que acontece em torno da contabilização e da chegada de extratos, nunca os documentos em si.
A nova extensão se registra na mesma tomada de configuração, e seus documentos e trilhas de auditoria continuam inalterados — a contabilidade não percebe a troca.
Não — deliberadamente. O núcleo é atualizado em seu próprio calendário e cada extensão no seu, de modo que uma mudança de provedor ou de mandato nunca desestabiliza o seu fechamento.
Sim — o design orientado por configuração permite que as extensões adicionem seus campos aos documentos e layouts de PDF sem alterações de código na configuração do núcleo que você já tem.
Dois pontos hoje — fatura eletrônica e feeds bancários. A disponibilidade de provedores evolui por país e região; consulte a REDA sobre a sua.
Isso foi útil?