Como Funcionam os Sistemas ERP: Módulos, Fluxo de Dados e o Diário Subjacente
Uma transação seguida através de cada módulo de um ERP, com os respetivos lançamentos contabilísticos reais e a explicação de por que razão a contabilidade geral é o registo central que tudo o resto consulta.
Um sistema ERP funciona armazenando cada evento comercial uma única vez, numa base de dados comum, e permitindo que cada módulo consulte e atualize esse registo partilhado. Uma encomenda expedida é exatamente o mesmo registo, quer seja consultada pelo armazém, pela equipa comercial ou pelo contabilista. O módulo que garante a integridade de todo o sistema é a contabilidade geral: cada evento com expressão monetária resulta num lançamento contabilístico equilibrado, e todos os relatórios são derivados desses lançamentos.
Este artigo acompanha uma venda através dos vários módulos, demonstra os lançamentos contabilísticos gerados e explica porque razão a integração com um ERP se foca nos eventos e no diário, em vez de nos ecrãs.
A base de dados partilhada
Antes dos sistemas ERP, cada departamento utilizava o seu próprio programa. O inventário ficava num sistema de armazém, as faturas num sistema de faturação e a contabilidade num programa dedicado. O final do mês passava-se a conciliar os três. O artigo O que é o software ERP explica a categoria; o mecanismo que a torna funcional é um modelo de dados unificado em que:
- um registo de parceiro é utilizado de forma transversal pelas vendas, compras e contabilidade,
- um registo de artigo armazena a quantidade em stock, as camadas de custos FIFO, o preço de venda e a conta de proveitos,
- um documento (encomenda, fatura, nota de crédito, compra, ordem de produção) referencia parceiros e artigos, originando exatamente um único conjunto de lançamentos contabilísticos,
- um lançamento contabilístico referencia o documento que o originou, permitindo rastrear qualquer valor num relatório até à sua origem.
Quando os registos são partilhados, deixa de ser necessário reconciliar dados entre módulos. O que resta reconciliar é o mundo exterior: extratos bancários e declarações fiscais.
O mapa de módulos
| Módulo | Escreve | Lê |
|---|---|---|
| Vendas | Encomendas, faturas, notas de crédito | Parceiros, artigos, preços, regras de IVA |
| Compras | Ordens de compra, faturas de fornecedores | Parceiros, artigos, contas de gastos |
| Inventário | Movimentos de stock, camadas de custo FIFO, inventariação física | Artigos, armazéns |
| Produção | Ordens de produção, consumo de componentes, produtos acabados | Listas de materiais, stock |
| Banco | Transações importadas, reconciliações de pagamentos | Faturas em aberto, contas bancárias |
| Salários | Processamentos salariais, contribuições, declarações fiscais | Colaboradores, contratos, tabelas fiscais |
| Ativos | Cadastro de ativos, processamentos de depreciações | Grupos de ativos, vidas úteis |
| Fiscalidade | Declarações de IVA, recapitulativos de clientes intracomunitários, Intrastat, faturas eletrónicas | Documentos emitidos e registados |
| Contabilidade geral | Lançamentos contabilísticos, fechos de período | Todos os anteriores |
| Relatórios | Nada | A contabilidade geral e as subcontas |
Todas as linhas, exceto as duas últimas, terminam com uma gravação na contabilidade geral. Esta é a regra de conceção que distingue um ERP de um conjunto de ferramentas ligadas entre si.
Um fluxo de dados prático
O exemplo seguinte utiliza os pontos de finalização (endpoints) da Nordlet e as contas por defeito do plano de contas lituano fornecido de raiz. Qualquer ERP executa os mesmos passos; os códigos das contas e os nomes dos endpoints variam.
1. Encomenda
Uma loja online cria uma encomenda através de POST /v1/ecommerce/orders/create: um parceiro, linhas com artigos e quantidades, e um país de destino para a entrega. Ainda nada é lançado na contabilidade. Uma encomenda é um compromisso, não uma transação.
2. Reserva de stock
orders/reserve reserva as quantidades para evitar que uma segunda encomenda venda as mesmas unidades. Continua a não existir nenhum lançamento contabilístico: o stock reservado continua a pertencer à empresa.
3. Expedição
orders/fulfill regista a saída das mercadorias do armazém. Ocorrem duas ações numa única transação de base de dados:
- O stock é abatido ao custo FIFO: utilizam-se primeiro as camadas de custos mais antigas para cada artigo, correspondendo ao método descrito na entrada de glossário Validação de inventário FIFO.
- O custo dessas unidades é lançado como um débito na conta de custo das mercadorias vendidas e um crédito na conta de stock.
| Conta | Débito | Crédito |
|---|---|---|
| 6000 Custo das mercadorias vendidas | 600.00 | |
| 2040 Stock | 600.00 |
A expedição cria também uma fatura em rascunho para a encomenda e determina o tratamento de IVA aplicável com base no país de destino, recorrendo ao motor de IVA da UE.
4. Emissão da fatura
A emissão da fatura constitui o momento em que o proveito é reconhecido numa venda de transação única (point-in-time). O documento recebe o seu número sequencial sem saltos e é gerado um único lançamento equilibrado: o montante bruto para clientes, o IVA para a conta de IVA liquidado e o valor líquido para proveitos.
Para uma venda líquida de 1.000,00 € sujeita a uma taxa de IVA lituana de 21%:
| Conta | Débito | Crédito |
|---|---|---|
| 2410 Clientes | 1.210.00 | |
| 5000 Proveitos de mercadorias | 1.000.00 | |
| 4492 IVA liquidado a pagar | 210.00 |
Se uma linha possuir um método de reconhecimento diferido, o valor líquido é direcionado para proveitos diferidos, sendo libertado periodicamente pelo motor de reconhecimento de proveitos. O lançamento nas contas de clientes e de IVA permanece inalterado.
A fatura pode agora ser enviada sob a forma de PDF, de fatura eletrónica Peppol BIS 3.0 ou no formato de faturação eletrónica nacional exigido pelo país da empresa.
5. Reconciliação bancária
Duas semanas mais tarde, dão-se como recebidos 1.210,00 €. O movimento entra através de um feed bancário PSD2 ou da importação de um extrato camt.053. O módulo bancário pontua as faturas candidatas com base no montante, referência de pagamento, nome da contraparte e IBAN, e bank/transactions/match efetua o lançamento da liquidação:
| Conta | Débito | Crédito |
|---|---|---|
| 2710 Banco | 1.210.00 | |
| 2410 Clientes | 1.210.00 |
O estado da fatura passa a pago e é emitido um webhook sale_invoice.paid. A entrada de glossário Reconciliação de pagamentos explica a lógica de emparelhamento com maior nível de detalhe. Um pagamento efetuado noutra moeda regista a diferença de câmbio realizada na respetiva conta de proveitos ou custos no mesmo passo.
6. Declaração de IVA
No final do mês, não é necessário introduzir dados manualmente. A declaração de IVA é calculada a partir dos documentos emitidos e registados: declarations/eu/vat-return/compute para a declaração nacional (FR0600 na Lituânia), e declarations/eu/oss/compute para as vendas transfronteiriças a consumidores ao abrigo do regime do balcão único (OSS). A venda anterior é integrada no campo de taxa normal da declaração doméstica, uma vez que o seu regime de IVA é domestic.
7. Fecho de período
Assim que a declaração é submetida, ledger/periods/lock encerra o mês. A partir desse momento, qualquer lançamento com data pertencente a esse período, incluindo uma reconciliação bancária tardia ou uma chamada de API repetida, é rejeitado com um código HTTP 409. O fecho aciona também o reconhecimento de quaisquer proveitos diferidos previstos até ao final do período, impedindo que um mês feche com proveitos ganhos retidos numa conta de passivo.
Porque é que a contabilidade é o sistema de registo principal
Cada um dos módulos anteriores mantém uma subcontabilidade (subledger): clientes por cliente, fornecedores por fornecedor, inventário por artigo, ativos por ativo. A contabilidade geral contém os totais com os quais estas subcontas devem coincidir. O artigo Subcontas vs contabilidade geral aborda esta relação; na prática, isto significa que um relatório extraído da contabilidade geral e outro extraído de uma subconta devem apresentar exatamente o mesmo valor, e um ERP garante-o gerando ambos a partir dos mesmos lançamentos contabilísticos.
Três propriedades conferem fiabilidade à contabilidade como sistema de registo:
- O equilíbrio é obrigatório. Na Nordlet, a base de dados rejeita qualquer lançamento em que os débitos não sejam iguais aos créditos. Um erro num módulo nunca poderá gerar um lançamento desequilibrado.
- O histórico é estritamente de adição (append-only). Um lançamento contabilístico publicado nunca é editado. Um erro é corrigido através de uma anulação (reversal) e de um novo lançamento, ambos vinculados ao documento original. A entrada Livro-razão imutável explica porque razão os auditores exigem este procedimento.
- Os períodos encerram-se. Um mês bloqueado não pode ser alterado, garantindo que os valores declarados permanecem inalterados no sistema.
Integração: eventos e idempotência em vez de processamentos noturnos
As integrações ERP mais antigas baseavam-se na troca de ficheiros durante a noite: exportar encomendas, importá-las, verificar o registo de erros na manhã seguinte. Os ERPs modernos disponibilizam uma API, transformando a integração numa questão de duas disciplinas fundamentais.
Eventos emitidos (Events out). Quando algo se altera, o ERP notifica o exterior. A Nordlet grava cada evento de webhook numa fila de saída (outbox) na mesma transação de base de dados da alteração, garantindo que um documento revertido nunca emite um evento e que nenhum evento se perde. As entregas são assinadas com HMAC-SHA256 e repetidas com recurso a backoff exponencial. O seu sistema reage a sale_invoice.paid em vez de questionar o ERP a cada cinco minutos para saber se algo foi pago.
Repetições seguras (Safe retries in). As redes falham e um pedido repetido não deve originar uma segunda fatura. A Nordlet aceita um cabeçalho Idempotency-Key em qualquer pedido de alteração de dados: a mesma chave com a mesma carga útil devolve a resposta armazenada, a mesma chave com dados diferentes é rejeitada, e as chaves expiram ao fim de 24 horas. A entrada de glossário Idempotência e as Convenções da API descrevem o comportamento exato.
Uma vez que cada operação se traduz numa chamada do tipo POST /v1/{module}/{resource}/{action} e a aplicação recorre aos mesmos pontos de finalização, uma integração pode executar todo o fluxo descrito sem que ninguém abra um único ecrã. O artigo Como integrar uma API de contabilidade na cloud numa plataforma SaaS ilustra a construção de uma integração deste tipo.
O que os relatórios consultam
Os relatórios não armazenam valores. Consistem em consultas (queries) efetuadas sobre a contabilidade geral e as subcontas a uma determinada data:
- Balancete, balanço, demonstração de resultados e fluxo de caixa consultam os lançamentos contabilísticos agrupados por conta e período.
- Antiguidade de saldos lê os saldos em aberto de clientes e fornecedores por data de vencimento.
- Saldos e movimentos de inventário consultam o módulo de inventário e respetivas camadas FIFO.
- Resumo de IVA lê as linhas de IVA dos documentos emitidos e registados.
- Relatórios por centro de custos leem a dimensão de centro de custos associada a cada linha de lançamento.
Na Nordlet, um relatório é gerado em segundo plano nos formatos XLSX, PDF ou JSON, sendo disparado um webhook assim que o ficheiro estiver pronto. Os valores consolidados resultam do processo de consolidação, que combina as contabilidades de várias empresas aplicando ponderações de participação e conversões de moeda.
Onde o modelo falha na prática
A maioria dos problemas associados aos ERPs resulta de falhas no princípio do registo partilhado e não do software em si. Exemplos comuns:
- Uma folha de cálculo paralela criada para suprir uma funcionalidade que o ERP "não consegue fazer", acabando por divergir dos registos contabilísticos.
- Lançamentos manuais utilizados para corrigir a saída de um módulo em vez de corrigir o documento de origem, o que quebra a cadeia de rastreabilidade entre o relatório e a fonte.
- Integrações que escrevem saldos em vez de documentos, resultando numa contabilidade com totais que ninguém consegue explicar.
- Períodos abertos deixados sem bloqueio durante meses, fazendo com que os valores fiscais do trimestre anterior sofram alterações indesejadas.
O artigo Porque falham as implementações de ERP analisa a origem destes hábitos durante a implementação, e Cronogramas realistas para a implementação de ERP indica em que fases do projeto costumam manifestar-se.
FAQ
Qual é o núcleo de um sistema ERP?
A contabilidade geral e o modelo de dados partilhado que a rodeia. Cada módulo gera documentos que originam lançamentos contabilísticos equilibrados, e todos os relatórios derivam desses lançamentos.
Como flui a informação através de um ERP?
Um evento é registado uma única vez sob a forma de documento (encomenda, fatura, movimento, processamento salarial). O documento gera lançamentos contabilísticos na contabilidade e movimentos na subconta respetiva. Os relatórios e as declarações fiscais são calculados a partir desses registos. Nada é duplicado manualmente entre módulos.
Qual é a diferença entre um módulo e uma integração?
Um módulo escreve na mesma base de dados e no mesmo diário que o resto do sistema. Uma integração é um programa externo que consome a API do ERP. Num ERP com uma arquitetura centrada na API (API-first), esta distinção esbate-se, dado que a integração utiliza exatamente os mesmos endpoints que os módulos nativos.
Um ERP efetua lançamentos contabilísticos automaticamente?
Sim. A emissão de uma fatura, a expedição de uma encomenda, a reconciliação de um pagamento, o processamento de salários ou a depreciação de um ativo geram os respetivos lançamentos contabilísticos sem necessidade de construir manualmente débitos e créditos. As contas utilizadas derivam de regras de lançamento configuráveis por empresa.
Porque é que os ERPs bloqueiam os períodos contabilísticos?
Para garantir que os valores comunicados ou declarados num período não podem ser alterados posteriormente. Um período bloqueado rejeita novos lançamentos, o que protege a trilha de auditoria (audit trail) e força a que quaisquer correções sejam efetuadas no período corrente, onde se tornam visíveis.