This is a screenshot of the journal entry form.
]]>For the ORM I’m planning on using ActiveRecord, but I’m not crazy about how it implements single table inheritance (STI), but I am very pleased with how it chains scopes together.
]]>Its been an interesting experience and I usually feel that supporting varied runtime environments results in higher quality code.
The most recent hurdle involved Ruby class variables. I'm not sure why, but Ruby 1.9 did not like how I was using class global variables. You know, the ones like:
@@something = "else"
Instead, I've switched to using attr_accessors, like this:
this.something = "else"
Thankfully, both Ruby 1.8 and 1.9 are cool with attr_accessors.
]]>I like this idea, and took a step in this direction today simply by adding grit as a requirement. It is only being used to display some information about the repository, but its a start!
]]>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:
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.
]]>I've dabbled with ledger in the past, but this time I took a serious look at it, and I'm actually starting to use it to some degree. Not for my main bookkeeping database, but when I want to quickly make a note of a transaction. I simply jot down the transaction into a text based ledger file. I'd considered doing this before but was concerned about managing the file(s), and instead added a feature to PBooks for entering simple notes. Nowadays, however, thanks to git I'm feeling a lot more comfortable with basic file management.
The significance of all this to me is that ledger-cli and its use of static file formats make it easy for a single person to quickly enter a couple of transactions without fear of being able to summarize the contents. The ledger-cli parser and memory model of the data can output the entire dataset as XML, which really liberates the entire kit-and-caboodle. That is really awesome when you think about it, and its importance should not be underestimated.
While ledger-cli can easily handle the processing of hundreds of thousands (millions?) of entries, I loathe to think of the work involved in the data entry. The ledger file format attempts to support faster entry of data with the use of xacts, but I can't comment on those as I've actually never tried using them. With PBooks, I developed a method of importing data from CSV files, but before I get into that, let me explain a tiny issue I have with the name and terminology of ledger-cli.
I find it ironic that ledger calls itself ledger, because in bookkeeping terms, I'd consider the file its centered on a journal. In my experience, a journal is the point of initial data entry, and journal entries contain multiple accounts. Conversely, ledgers are account focused, with references back to the original journal entry.
Not a big deal, but relevant. With PBooks, I wrestled with workflow for awhile because traditionally, data is entered into the journal as transactions take place, but in our technological world, I found it easier to leverage the CSV formatted data exports of my online bank accounts - ledger data.
The solution I came up with was to import CSV account data into the ledger as "unmatched", and then give the user the ability to match each transaction to one or more corresponding account(s). It works well for me in practice, and it was possible to created shortcuts using the transaction memos. I consider that workflow solution to be similar in some ways to how ledger-cli uses xact statements.
While the philosophy of ledger is truly solid, reliable, and even elegant (and its starting to really build momentum and traction in the open source world), I'm not sure how realistic it is for the majority of small businesses to use for their bookkeeping and accounting purposes. True, its possible to use something like GnuCash to manage a ledger file in XML, but I don't think that makes much of a difference for reasons I won't get into right now.
Instead, let me write about Regdel. I've been considering a lot of different ideas but haven't come up with a clear direction. I'm thinking about:
More to come...
]]>There are several things broken at the moment, but its nice to have something public!
]]>The hardest part was the getting ruby-xslt to compile, but thanks to Radar, it was possible. :-)
]]>I've considered also using it for Accounts, something like this:
class Asset < Account; end class Liability < Account; end class Equity < Account; end class Expense < Account; end class Revenue < Account; end
And even further:
class BankAccount < Asset; end
I'm not sure its the right way to go though. There is an incredibly possibility here though: with deep inheritance, account groups would be built defined in the class "family tree", and generating reports based upon account type would be super easy.
The limitation would be, as the name suggests, single inheritance. With PBooks, Account Groups can have multiple parents, though accounts can only belong to a single account group. Its an interesting implementation. Is it overly flexible? Maybe...
]]>Fork it up, y'all!
http://github.com/docunext/regdel
Oh yes, its now officially Affero GPL licensed, too!
]]>Its been awhile, and I'm trying to take advice from Russell to not be disheartened by that specific response. Perhaps that is the reason I chose to blog on opinion I had about the use of Gitorious on the pfSense website instead of contact the pfSense folks directly, who knows? Needless to say, the pfSense folks weren't too happy about my blogging without contacting them first, but I'm not clear about their final statement claiming that I was incorrect.
All that is besides the point, however. I'm posting this because I'm starting to reach out via Github to other Ruby finance developers. Here's a couple of messages I've sent:
I read the Bookkeeper Readme. I agree about Quickbooks and share the goal of writing bookkeeping software for my company to use. However, like many open source developers, I also have an idealistic hope that my contribution to the open source software movement will help save the world. :-)
There are some existing notable open source bookkeeping projects:
Ledger - C++, very much alive and supported (CL and Python ports exist), mainly command line GnuCash - C, desktop, could be compared to Quickbooks / Quicken SQL-Ledger / LedgerSMB - Perl, I found it awkward Phreebooks - PHP, I like it, but not the software architecture PBooks - my project, PHP, XSL, XML - too difficult for people to install Also notable is the XBRL (extensible business reporting language) project. Its more than most companies need, but I found some of the core components useful to build off of.
I got Bookkeeper up and running over the weekend, the main stumbling blocks being my inexperience with Rails. Are you totally committed to Rails? I'm not crazy about Rails due to the use of Prototype and Erb, as I'm hardcore into jQuery and XSL. I'm also becoming a DataMapper fan.
Thoughts?
Albert
XSL has a steep learning curve, and a lot of people don't like it, but for those of us who embrace it, its pure wonderment. Are you OK with XML? I think its great, but also like YAML and JSON. Some people can't stand XML, but I'm not sure why.
Merb and Rails3 both look good, but I'm very keen on Sinatra as its structure is similar to the sitemaps I've used with Nexista (a PHP/XML/XSL/SQL framework) for years.
Regarding bookkeeping, I recently ran into a problem with the Float object that was causing some weird rounding:
http://www.ruby.code-experiments.com/blog/2009/11/ruby-casting-strangeness.html
While researching it, I found a suggestion to store money amounts as US cents, which would preclude floats altogether. What do you think about that? The Money gem does the same thing. So far its working well for Regdel.
I'll take a look at your balance sheet and income statement and let you know if I have any suggestions. Why is the CSV output a priority? Its a useful feature to support a wide range of data transfer, but if you are aiming for something more specific, I might have some suggestions. For example, in PBooks I created a module for creating an OpenOffice spreadsheet download. It was pretty easy, but the implementation is PBooks / Nexista specific.
I will also check out the Invoicing gem, sounds cool.
Hello,
Just found Oaccounts via the invoicing Gem suggested by snl (Hakan Şenol Ensari), author of bookkeeper. I've been working on open source bookkeeping systems for about five years, mostly on PBooks, now more recently with Regdel and EvenBooks.
I'm using XBRL as a guiding base, and am excited to find UBL. Looks like XBRL is more about reporting, and UBL is more about processing.
If you haven't seen XBRL, check it out.
Have a good one!
Albert
I'm curious to see if there is any difference in reaching out via Github. No doubt its easier to do!
DataMapper → Ruby Builder → Sinatra-XSLView → Rack XSLView
So far its working quite well, and I really appreciate how simple it keeps things!
]]>
This is a screenshot of the journal entry form.
]]>Today I spent a lot of time getting into the nitty gritty of datamapper, only to realize after several hours that I was using an outdated version. Frustrating to say the least, but I'm not letting it bother me much.
That's the way software development often goes - you try something new to take advantage of time saving techniques, only to waste several hours because of the learning curve involved with trying something new.
Regardless, developing an accounting and bookkeeping system with Ruby just feels incredibly right, similar to how I feel about developing web applications with XSL.
Double-entry bookkeeping is inherently rich with relationships between accounts, entries, dates, and references, so its a natural fit for Ruby, which gracefully handles objects, and for DataMapper, which handles relationships equally well.
I'm feel like wrestling with javascript more than I need to, though. jQuery is my javascript language of choice, and in many ways its too convenient. I'm not sure if I want to work on having client-side object manipulation. I don't think I do, and while that makes the task easier in some respects, the downside is that it feels less elegant.
There is probably a workaround for the elegance factor! :-)
As for the progress report? The software currently has a basic working framework, with entries, credits, debits, accounts, and a ledger that can be automatically built from the journal.
The to-do list is immense, of course. Before continuing work on it, I plan to refactor the current codebase and make sure the upgrade to the datamapper 0.10 is complete. I'm interested in reviewing what else dm has to offer. Its become a much larger part of Regdel than I originally expected.
]]>