Perfis contábeis e regras de lançamento
Um perfil contábil vincula uma versão de produto ao ledger. Ele define as regras de lançamento: as pernas de que disparam para cada tipo de evento financeiro. Ele também define a organização de ledger e o ledger em que as transações resultantes são contabilizadas. Você cria um perfil por produto:
POST /api/v1/loan-products/{id}/accounting-profiles
O Lender valida as regras de lançamento quando você cria o perfil. Um produto, portanto, não pode entrar no ar com pernas que não balanceariam.
Intenções de lançamento e o relay
O Lender não chama o ledger inline. Quando um evento financeiro acontece, o Lender persiste uma intenção de lançamento durável. Essa gravação acontece na mesma transação de banco de dados que muda o estado do domínio. Um relay então lança a transação balanceada no Midaz de forma assíncrona. Estas propriedades tornam as contabilizações confiáveis:
- A intenção faz commit junto com a mudança de estado: as duas caem em uma única transação de banco de dados, por um outbox transacional.
- Idempotente: cada lançamento carrega uma chave determinística, então novas tentativas colapsam em uma única transação do ledger.
- Falha fechado: se o roteamento não conseguir resolver um destino de ledger não vazio, o Lender recusa o lançamento e não o grava no lugar errado.
Rodadas de apropriação
Uma rodada de apropriação reconhece juros e os demais valores baseados em tempo. Uma rodada fecha o último mês civil que já tinha terminado por inteiro antes da data de referência dela, para cada empréstimo que seleciona. Ela também produz os lançamentos desse mês.
POST /api/v1/accrual-runs começa uma rodada. O Lender seleciona as contas de empréstimo candidatas por conta própria, reconhece juros por conta e grava uma intenção de lançamento por reconhecimento.
Repetir uma rodada
Um reconhecimento fica durável no instante em que a rodada faz commit. A contabilização no ledger não fica durável. Quando um lançamento nunca chega, repita a rodada em vez de começar uma nova.
POST /api/v1/accrual-runs/{id}/retry nomeia os itens a reenviar e recebe o mesmo cabeçalho X-Idempotency que a própria rodada recebe. É uma segunda tentativa sobre a mesma rodada, então o Lender não registra uma segunda rodada.
O Lender remonta o lançamento por trás de cada item nomeado que o ledger não confirmou e o enfileira sob a chave determinística que a rodada original usou. O relay entrega, e o ledger trata uma duplicata como duplicata, não como uma segunda contabilização. O Lender deixa intocados os itens que o ledger já confirmou.
A resposta nomeia, item a item, o que ela não conseguiu reenviar. Ela também nomeia o porquê: o lançamento já tinha sido entregue, ele foi posto em quarentena, o contrato por trás dele sumiu, ou o produto está mal configurado.
Referências de diário
Cada rodada de apropriação registra uma referência de diário, o identificador contábil da própria rodada. O registro da referência também guarda o id de correlação que o Lender derivou para a rodada. O id da referência de diário identifica exatamente uma rodada. Uma leitura por id de correlação retorna a rodada mais recente que compartilha esse modo, essa data de referência e esse escopo de produtos. Uma rodada emite um lançamento por conta de empréstimo, por mês contábil, por tipo de valor. O Lender registra, portanto, o laço de volta com o ledger por lançamento, não por rodada. Assim que o ledger confirma um lançamento, o Lender guarda um recibo sob a chave daquele lançamento. Uma leitura por essa chave responde com a transação do ledger que o contabilizou. Uma referência no nível da rodada não carrega transação de ledger própria: ela nomeia a rodada, e os recibos nomeiam as contabilizações.
Próximos passos
Jurisdições
Veja como a jurisdição ativa molda as divulgações e os endpoints.
Pacote regulatório Brasil
Sobreponha CET, IOF e estágios de PDD ao modelo contábil.