For example, I want to make sure that entries balance, but they can’t balance all the time - especially when they are works in progress, i.e. they are not posted. The model has a posted attribute, so I’m doing something like this:

validate :credits_and_debits_must_balance, :if => :posted?

The problem is that the posted attribute must be set before the validation is run. As such, I’m planning on changing the posted attribute to be a part of the state machine setup. I’ll have to create a posted? accessor to check the state, not a problem.

The issue with that is that I’m planning to use the state machine differently for different classes, and the entry model uses single table inheritance (STI). I wonder if its possible to have more than one status column for different states on different classes. Not sure if I want to do that though.

UPDATE: Whoa - looks like state_machine supports namespaces. AWESOME! So for the base Entry class:

  state_machine :initial => :draft do

    event :post do
      transition :draft => :posted
    end 

    event :reconcile do
      transition :posted => :reconciled
    end 

  end 

and for the Invoice class:

  state_machine :initial => :open, :namespace => :invoice_state do

    event :issue do
      transition :matched => :sent
    end 

    event :reconcile do
      transition :posted => :reconciled
    end 
  end 

After reviewing these factors, another great aspect of Rails comes to mind: the testing frameworks!

Take a look:

# Xact = transaction
class Xact
  include DataMapper::Resource

  property :id,Serial
  property :posted_on,Integer
  property :memorandum,String
  has n, :assets
  has n, :liabilities
  has n, :equities
  has n, :expenses
  has n, :revenues
  has n, :banks

end


# Postings are the individual account changes
class Posting
  include DataMapper::Resource

  property :id,Serial
  property :type,Discriminator
  property :xact_id,Integer
  property :commodity,String
  property :quantity,BigDecimal, :scale => 2, :precision => 5

  belongs_to :xact
end

# Single table inheritance for every account
class Asset < Posting; end
class Liability < Posting; end
class Equity < Posting; end
class Revenue < Posting; end
class Expense < Posting; end
class Bank < Asset; end

The idea here is that each account is an object. The code above has the account types and then a bank account. This is obviously pre-alpha code, but the idea is there.

Its a big departure away from the way I've traditionally modeled accounting databases, so why bother?

I like this model because its super simple, and because it leverages some quality work that's already been done with datamapper, and it supports the sort of quick, instant reporting that is core to ledger-cli, especially the balance feature.

I'm interested in aligning Regdel with ledger to add to the traction its established. Open source accounting and bookkeeping software could use a little unity in my humble opinion. For awhile I felt that the single plain text file was a serious limitation, but those limitations might be alleviated with the combination of a SQLite and git, but that's a topic for another day.

Feedback about this new data model is much appreciated!

In the process, I've come to realize how much I like developing with Ruby, and some Ruby libraries are incredibly helpful. Concurrently, I've been focusing on managing my time better and trying to get more done in less time by automating repetitive tasks, planning my work, and setting goals.

For instance, I've started to use Rake for organizing tasks, more specifically running tests, generating documentation, and automating the deployment of redgel to the demo.

Now I need to start doing some planning, but I'm a little hesitant. I get frustrated with plans because they often don't happen as I expected. If I don't update my written plans, events diverge and the plan becomes totally out-of-date. Frustrations aside, I recognize the value of planning, so I'll start with a broad stroke.

Planning the Regdel Plans
I'm not going to jump directly into the plans just yet! I want to put a little planning into how I will approach the process. I'd like to have a simple plan reference so that it will be easy to keep updated, but where should it be?

Options:

• In the repository, alongside the README.md and CHANGELOG.
• A page in this blog.
• Github.com wiki

I like the idea of keeping it in a plain text file in the repository, but then again I'm concerned it won't get enough visibility. I'm experimenting with the automation of publishing documents like these that occasionally and irregularly update. If that works well, maybe keeping Regdel plans in the repository is the right choice.

Redgel Demo

There are several things broken at the moment, but its nice to have something public!