Come vengono mantenuti i saldi dei conti

La maggior parte dei software di contabilità commerciale archivia il saldo del conto, a volte con l'account, ma più spesso in tabelle periodiche (all'anno o al mese).

Il punto di vista tecnico

Ci sono diversi motivi che giustificano questa decisione:

1. Prestazioni : uno dei miei ex clienti ha registrato diverse milioni di transazioni ogni mese. Immagina il carico del database se ogni saldo viene ricalcolato ad ogni query.
2. Volumi elevati : molte grandi aziende affrontano problemi di prestazioni attraverso l'archiviazione di transazioni precedenti su archivi meno costosi e li ricaricano solo quando necessario (ad esempio, controlli fiscali). In questo caso, i totali del saldo del conto non possono essere ricalcolati esclusivamente con i dati rimanenti nel sistema principale.
3. Obblighi legali : la contabilità è strongmente regolamentata e la maggior parte dei paesi in tutto il mondo richiede un periodo minimo di conservazione per i dati transazionali. Ma oltre questo lasso di tempo, le aziende usano per scartare le transazioni non necessarie al fine di evitare costi di archiviazione non necessari. Sempre di più, i requisiti di protezione dei dati si aggiungono a questo come una nuova argomentazione legale verso l'eliminazione dei dati che non è più legalmente richiesta. Quindi le vecchie transazioni vengono discusse, ma i saldi non cambiano a causa di quel motivo.
4. Esigenze di accesso diverse su orizzonti temporali diversi : l'interesse per i dati transazionali tende a diminuire rapidamente nel tempo al termine della transazione. È raro che un contabile debba accedere a transazioni dettagliate di 2 o 3 anni fa. Tuttavia, l'interesse per i saldi mensili e annuali rimane elevato per un periodo più lungo a fini di gestione finanziaria. A proposito, questo spiega perché le tabelle periodiche sono il modo più comune per memorizzare i saldi: una volta effettuato il riporto nel mese successivo, non è più necessario modificare i saldi precedenti.

Il punto di vista del business

Esistono anche ragioni commerciali che giustificano la gestione di un saldo dell'account come valore reale nel modello di dominio.

Il dominio dell'account è interessato principalmente alla categoria 3 di informazioni

• la situazione finanziaria in un determinato momento (ovvero l'ultimo giorno dell'anno fiscale, il trimestre fiscale, il mese di riferimento) documentato dai saldi dei conti a quella data.
• l'evoluzione della situazione finanziaria su un periodo (es. anno fiscale, trimestre, mese). Di solito, questo è documentato confrontando i saldi tra la fine e la data di inizio del periodo di riferimento.
• la transazione di periodi che giustificano il saldo.

Quando un revisore verifica gli estratti conto, non prenderà i 150 anni di transazioni storiche dalla fondazione della società per ricalcolare il valore del bilancio. Il revisore prenderà il bilancio precedentemente sottoposto a revisione, aggiungerà il totale delle transazioni nel periodo controllato e verificherà se corrisponde ai nuovi saldi.

In caso contrario, per ragionieri e revisori dei conti, un saldo, una volta verificato o pubblicato, ha un valore proprio, indipendentemente dalle transazioni che lo spiegano / giustificano.

Conclusione

Qualsiasi sistema di contabilità reale registra i saldi in qualche modo. Memorizzare i saldi non è una denormalizzazione se considerata nella realtà del modello contabile, ma una caratteristica richiesta dalla teoria e dalla pratica contabile. Riconosce la vista, in cui i saldi sono considerati come un valore indipendente (la situazione finanziaria) e le transazioni sono solo una documentazione di come questo valore cambia nel tempo. I sistemi contabili che non memorizzano saldi sono in genere progetti di studio o rivolti a piccole imprese.

Se per "persistente" si intende "memorizzato in un database (non necessariamente relazionale)", in generale non si devono memorizzare valori derivati insieme ai valori primari. Questo è chiamato denormalizzazione e di solito è un cattivo compromesso; i valori derivati dovrebbero essere aggiornati ogni volta che i dati primari cambiano, il che moltiplica lo sforzo per scrivere e non risparmia tutto quel tempo per leggere il bilancio; aggiungere e sottrarre alcune cose è molto, molto economico rispetto all'accesso alla memoria persistente, quindi leggere i valori primari e calcolare un bit è probabile che richieda un tempo simile a quello di un valore di bilanciamento.

(La denormalizzazione viene solitamente utilizzata quando fa spesso si desidera leggere valori aggregati e raramente o mai scrivere nuovi dati primari, ad esempio in data warehouse .)

Se controlli i tuoi estratti conto bancari vedrai che la prima riga è in genere "saldo riportato dal mese precedente"

Ti suggerisco di implementare un sistema simile di "istantanea", in cui arrotoli le transazioni precedenti in un periodo contabile e "chiudi" quel pero, in modo che non cambierà se le transazioni fuori servizio arrivano in un secondo momento.

È quindi possibile utilizzare il saldo contabile avanzato più le transazioni dal periodo contabile corrente per mostrare il saldo corrente.

Durante la segnalazione è possibile utilizzare i saldi alla fine del periodo contabile. Quale sarà risolto e non richiederà alcuna sommatoria delle transazioni.

La segnalazione dei valori correnti sarà imprecisa in ogni caso poiché presumibilmente stai utilizzando il metodo della somma delle transazioni a causa di incertezze nei tempi delle transazioni

Il modo in cui sono andato a fare questo è dividere Transaction da Account . Quindi implementato un servizio che era responsabile del calcolo del saldo dell'account. Sembra qualcosa del genere (mi dispiace per la sintassi C #):

public class Account
{
    public Account(AccountID id, string name)
    {
    }

    public AddSubAccount(Account subAccount)
    {
    }

    public RemoveSubAccount(Account subAccount)
    {
    }
}

public class Transaction
{
    public Transaction(AccountID creditAccountID, AccountID debitAccountID, DateTime date, decimal amount)
    {
    }

    public DateTime Date;
    public decimal Balance;
    // other methods and properties
}

// domain service
public AccountBalanceCalculator
{
    public AccountBalanceCalculator(IAccountRepository accountRepo, ITransactionRepository transRepo)
    {
    }

    public decimal Balance(AccountID accountID)
    {
        // get account from Repo
        // get transactions for account
        // get all subaccounts for account
        // get all transactions for each subaccount
        // return sum
    }
}

Questo è un modo veloce e sporco. Puoi aggiungere un metodo Sum() alla ITransactionRepository che restituisce la somma di tutte le transazioni con uno specifico AccountID , quindi non è necessario caricare tutte le transazioni in memoria.

Quindi, quando viene modificata una Transaction (ad es. la quantità), puoi attivare un evento dal metodo Transaction.ChangeAmount(decimal newAmount) . Questo potrebbe essere usato per far sapere all'IU che una transazione è cambiata.

Se vuoi andare ancora oltre, puoi usare CQRS. Quindi, quando il modello di scrittura (ad esempio il modello di dominio) cambia, come Transazione, è possibile attivare un valore pari, quindi modificare il ReadModel.