Credit system: based on history or balance sheet?

I am going to write a simple credit system in which the user can " add ", " subtract " loans in the system. I am currently thinking of two approaches.

  • Simple: save the user's credit as balance in the database, and all actions ("add", "subtract") are recorded, but are not used to calculate the last balance.

  • The story is based: Do not store the balance in the database. Balance is calculated by viewing transaction history, for example. (add, subtract)

Both cases will work, I think, but I am looking to see if it is worth interfering with the development of such a system, especially I prefer the History based system.

Or, is there any open source implementation or module that I use?

Update. Or is there any Ruby / Rail-based module like AuthLogic , so I can connect and play my existing code without reinventing the wheel (e.g. transaction, rollback, security, etc.)?

+7
ruby design-patterns ruby-on-rails database-design software-design
source share
3 answers

Use both completely.

  • The balance method gives you quick access to the current amount.

  • Based on the story, you can conduct an audit. The history table should contain the transaction (as described), the time stamp, the balance before the transaction, and, ideally, a way to track the source / address of the funds.

See Ruby Toolbox for Accounting and Pluto Double-entry Paper Pearls .

In addition, if your credit system can affect users, I recommend that you also use logging and, ideally, read about verifying secure verification and provable time stamping.

+12
source share

Adding and subtracting loans implies that you may also need to know where these loans came from and where they went. Every time you find yourself in a similar situation, whether with a currency or some other numerical quantity that needs to be tracked and taken into account, you should consider using a double-entry template.

This template has worked for centuries and gives you all the functionality you need so that you can see what your balances are and how they got that way:

  • An audit trail of all transactions (including sources and sinks of "funds")
  • Launching the balance of all accounts over time (if you decide to record it)
  • Simple validation of records
  • One time recording feature - no updates mean no fakes

If you are unfamiliar with the details, start here: Double Entry Bookkeeping or ask anyone who has taken an introductory accounting course.

You asked for an open source Ruby on Rails solution that you could plug in and use in your application. You can use Plutus . Here is an excerpt from the description of this project on Github:

The plutus plugin provides a complete double-entry accounting system for use in any Ruby on Rails application. The plugin follows the general practice of accounting Double Entry .... Plutus consists of tables that maintain accounts, records and debits and loans. Each entry can have many debits and credits. An entry table in which business transactions are essentially your reporting journal.

+6
source share

yes, use both.

  • Also, will you ever need to reverse transaction / s. In doing so, create a new canceled transaction to indicate a money transfer.
  • Sometimes you need to combine several transactions under one roof. I propose creating a third table called β€œtokens”, which will be the payment manager, and you will combine these grouped transactions under this token.

    token.transactions = (select * from transaction t, where t.token = "123"), for example

+1
source share

All Articles