Wednesday, July 9. 2008
Time for an Australian OSS based Accounting & Payroll program
Ask any small business owner in Australia what drives them craziest running their business.
More often then not the answer will be their accounting software.
Why? It's not because they are unable to understand the principles of double-entry accounting or even the tax system imposed on them.
No, its the lack of a decent, flexible and affordable solution.
The two most popular business accounting packages for the SME is either MYOB and QuickBooks. Both have huge hurdles, and it's not uncommon for users to find that they spend more time attempting to work the software than the software working for them.
I have previously blogged about the issue when talking about how Linux is difficult for many Aussie SMEs to take up. (Mainly due to their critical accounting software only available under Windows, though it is possible to run them under WINE if required). Though getting these Windows programs running under Linux doesn't actually solve the problem, it just migrates it. You are still stuck attempting to drive these frustrating accounting packages.
The Australian market is crying out for an alternative! It's something I've pondered over for some time.
An OSS based accounting and payroll system that put the source code directly in the hands of the users would be appealing to many.
I like the idea of a browser-based accounting system. It means end-users aren't restricted to one operating system platform, and in theory it doesn't need to be restricted to just a computer. (3G Accounting anyone?).
Accounting isn't fun, in fact it's dead-pan boring. It is however a required evil if you wish to be paid and be compliant with the taxation law. (Particularly GST, BAS reporting and PAYG).
I've looked at programs like SQL-Ledger and LedgerSMB, though both didn't 'fit right' for an Australian environment.
SYMBOL was promising. But unfortunately has been abandoned. fiveDASH, I played with for several hours, though I found it quite primitive and in it's infancy... it's one that at least has some promise, but it will need to progress quite some way to make it in any real production system for a business.
As such, I've decided to look at writing my own. This is purely selfish, as I would like to ditch MYOB come the 2009-2010 financial year. That gives me just under a year to get something up and running.
I'll run a dummy book up til the time, by running MYOB in parallel to ensure all is working as required. The ATO also has some excellent test suites/scenarios to assist in testing an application.
The big choice now is from what components should I build it?
I think PostgreSQL is probably the most solid OSS database to use, though writing something that can also talk to MySQL (due to it's popularity) is probably also wise. End-users can then elect to run whichever they feel most comfortable for their backend.
I considered many languages, but I'm leaning towards PHP for a few reasons:
I'm interested to hear people's feedback with their thoughts. Do you think a PHP application (backended by your choice of MySQL or PostgreSQL) for your business accounts is feasible? (Obviously if 'approved' by the ATO as compliant).
Do SMB owners prefer the option of paid software with support packs? (like offered by MYOB and Quicken) they can fall back on? Would you not trust your business books to an OSS based accounting package? What other hurdles do you envisage if you used OSS accounting software?
More often then not the answer will be their accounting software.
Why? It's not because they are unable to understand the principles of double-entry accounting or even the tax system imposed on them.
No, its the lack of a decent, flexible and affordable solution.
The two most popular business accounting packages for the SME is either MYOB and QuickBooks. Both have huge hurdles, and it's not uncommon for users to find that they spend more time attempting to work the software than the software working for them.
I have previously blogged about the issue when talking about how Linux is difficult for many Aussie SMEs to take up. (Mainly due to their critical accounting software only available under Windows, though it is possible to run them under WINE if required). Though getting these Windows programs running under Linux doesn't actually solve the problem, it just migrates it. You are still stuck attempting to drive these frustrating accounting packages.
The Australian market is crying out for an alternative! It's something I've pondered over for some time.
An OSS based accounting and payroll system that put the source code directly in the hands of the users would be appealing to many.
I like the idea of a browser-based accounting system. It means end-users aren't restricted to one operating system platform, and in theory it doesn't need to be restricted to just a computer. (3G Accounting anyone?).
Accounting isn't fun, in fact it's dead-pan boring.
It is however a required evil if you wish to be paid and be compliant with the taxation law. (Particularly GST, BAS reporting and PAYG).I've looked at programs like SQL-Ledger and LedgerSMB, though both didn't 'fit right' for an Australian environment.
SYMBOL was promising. But unfortunately has been abandoned.
fiveDASH, I played with for several hours, though I found it quite primitive and in it's infancy... it's one that at least has some promise, but it will need to progress quite some way to make it in any real production system for a business.As such, I've decided to look at writing my own. This is purely selfish, as I would like to ditch MYOB come the 2009-2010 financial year. That gives me just under a year to get something up and running.
I'll run a dummy book up til the time, by running MYOB in parallel to ensure all is working as required. The ATO also has some excellent test suites/scenarios to assist in testing an application.The big choice now is from what components should I build it?
I think PostgreSQL is probably the most solid OSS database to use, though writing something that can also talk to MySQL (due to it's popularity) is probably also wise. End-users can then elect to run whichever they feel most comfortable for their backend.
I considered many languages, but I'm leaning towards PHP for a few reasons:
- Most SMB that have a Linux server for File and Print serving also have a LAMP environment already setup.
- Writing the system using say the Zend Framework ensures a lot of the ground work is already done. Working within their coding standards also ensures the code is reasonably clean and readable (and thus maintainable).
- Python was also considered, but it's more likely a SMB has a Apache/PHP environment over an Apache/Python setup
- I already have quite a number of generic PHP libraries that will mean I can get moving much faster. My Python libraries are no-where as extensive.
- A Java-based web app would be an overkill and likely to confuse many small business owners. (ie: Install a Java Application Server, etc.)
- SugarCRM is already popular in many SMBs. It would be quite easy to have an Accounting + Payroll package integrate into SugarCRM. Sugar is written in PHP, so it would make the job much easier if they both spoke the same language.
I'm interested to hear people's feedback with their thoughts. Do you think a PHP application (backended by your choice of MySQL or PostgreSQL) for your business accounts is feasible? (Obviously if 'approved' by the ATO as compliant).
Do SMB owners prefer the option of paid software with support packs? (like offered by MYOB and Quicken) they can fall back on? Would you not trust your business books to an OSS based accounting package? What other hurdles do you envisage if you used OSS accounting software?
Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
The key for any package isn't just with the ATO or the business itself, it's with the accountants who support the SME. Many SME's essentially hand their accountants a Quicken or MYOB file and they work from there.
I've been thinking about the whole hosted OSS Accounting Package thing, and I think what it would need for wider adoption is the availability of reputable accounting backup.
I've been thinking about the whole hosted OSS Accounting Package thing, and I think what it would need for wider adoption is the availability of reputable accounting backup.
I do agree James.
Without support from Accountants, it's fairly useless.
Though the benefit of a hosted accounting package provides the SME of being able to:
1. Provide the accountant access directly to the books (via a firewall rule or hosting it externally).
2. The Accountant could in theory choice to run say a virtual machine containing a copy of the clients DB and the OSS accounting software.
Speaking to many accountants and a lot aren't overly impressed with MYOB and Quicken themselves.
My own accountant, will basically run what ever we do and is not overly concerned with the software but more that the numbers make sense and are accurate.
YMMV with your own accountant however.
Without support from Accountants, it's fairly useless.
Though the benefit of a hosted accounting package provides the SME of being able to:
1. Provide the accountant access directly to the books (via a firewall rule or hosting it externally).
2. The Accountant could in theory choice to run say a virtual machine containing a copy of the clients DB and the OSS accounting software.
Speaking to many accountants and a lot aren't overly impressed with MYOB and Quicken themselves.
My own accountant, will basically run what ever we do and is not overly concerned with the software but more that the numbers make sense and are accurate.
YMMV with your own accountant however.
As someone just starting to explore Linux as an alternative system for our office I would welcome an open source Aussie accounting package.
I have some programming skills but am out of touch enough to not be familiar with much of the open source movement and most of the programming abbreviations above (PHP, Apache etc).
We use Attache here and whilst it works for us we have written our own software to work with it to present and show data our way (which to us makes a lot more sense than their way). I also have a strong dislike for MYOB and Quicken because of the way they make the user work!
Our accountants couldnt care what we use, we just give them GL data as a .csv file and they can handle that easily!
I detest the pay money each year to use our software schemes which Attache have recently tried to force on us. Dont mind paying for outright "ownership" of software and then a fee for support and updates but I do object to having to upgrade to features you dont need and then having to pay each year just for the right to use your own software!
I would like to see what comes of this both as a "out of date" programmer and maybe give you some input on what is needed from a users point of view - something Attache seem to mostly ignore (cause if they listened they just wouldnt do some things the way they do!)
Open data bases for accounting software are great to because I am always finding new ways to play with collected data (we now have 10 years worth of customer records available!)
I have some programming skills but am out of touch enough to not be familiar with much of the open source movement and most of the programming abbreviations above (PHP, Apache etc).
We use Attache here and whilst it works for us we have written our own software to work with it to present and show data our way (which to us makes a lot more sense than their way). I also have a strong dislike for MYOB and Quicken because of the way they make the user work!
Our accountants couldnt care what we use, we just give them GL data as a .csv file and they can handle that easily!
I detest the pay money each year to use our software schemes which Attache have recently tried to force on us. Dont mind paying for outright "ownership" of software and then a fee for support and updates but I do object to having to upgrade to features you dont need and then having to pay each year just for the right to use your own software!
I would like to see what comes of this both as a "out of date" programmer and maybe give you some input on what is needed from a users point of view - something Attache seem to mostly ignore (cause if they listened they just wouldnt do some things the way they do!)
Open data bases for accounting software are great to because I am always finding new ways to play with collected data (we now have 10 years worth of customer records available!)
Great news! How'd you know I've been searching for this very thing myself over the last month? 
Another idea worth considering: would be be better to fork an Aussie version of an already established package? Say, the abandoned SYMBOL? fivedash? Or perhaps WebERP, which already has some NZ/Aust followers.
Just a couple of initial thoughts.
Anyway, as an Aussie small business owner and PHP programmer I may be able to provide some assistance in coding this.
Another idea worth considering: would be be better to fork an Aussie version of an already established package? Say, the abandoned SYMBOL? fivedash? Or perhaps WebERP, which already has some NZ/Aust followers.
Just a couple of initial thoughts.
Anyway, as an Aussie small business owner and PHP programmer I may be able to provide some assistance in coding this.
This sounds pretty interesting.
Personally, if I was to choose tools to do this in I'd find it very hard to go past Java and PostgreSQL. Why Java? Because:
- People tend to want both reasonably usable rich client interfaces and web interfaces. With a Java application server that's a reasonable goal.
- The Java persistence layer (JPA) is very useful, and the JPA 2.0 enhancements look even better.
- Availability of Jasper Reports and other excellent tools.
As for PostgreSQL, it just seems obvious. It's very robust, stable, fast under complex real-world loads, and takes very little maintainence. It has a solid privileges model and excellent support for in-database programming with triggers, etc. As a result, you can construct a database that does a lot of sanity checking and protects its own state well enough that you can permit access from other applications.
I'm pretty leery of depending on PHP-based software in general. The language just doesn't lend its self to solid, large-scale work and secure programming.
Personally, if I was to choose tools to do this in I'd find it very hard to go past Java and PostgreSQL. Why Java? Because:
- People tend to want both reasonably usable rich client interfaces and web interfaces. With a Java application server that's a reasonable goal.
- The Java persistence layer (JPA) is very useful, and the JPA 2.0 enhancements look even better.
- Availability of Jasper Reports and other excellent tools.
As for PostgreSQL, it just seems obvious. It's very robust, stable, fast under complex real-world loads, and takes very little maintainence. It has a solid privileges model and excellent support for in-database programming with triggers, etc. As a result, you can construct a database that does a lot of sanity checking and protects its own state well enough that you can permit access from other applications.
I'm pretty leery of depending on PHP-based software in general. The language just doesn't lend its self to solid, large-scale work and secure programming.
It's sure nice to know there are others out there.
We were about to trial GNUCash, but it sounds like it'll just trash my hopes again. (Didn't want to install gnome anyway).
I think having the data in SQL is a good idea (my tent is on the MySQL side of the fence). I also think PHP is a good idea - everything seems to be going AJAX, and I think PHP is the easiest to allow room for that potential.
You think it would work to make something like this modular, so people could snap in what they wanted? (A/R / A/P / GL etc. for functions ... maybe even allow easier development of other front-end options (like console
)) -- Maybe that's dreaming too far into the future at this stage...
Regardless; Excellent idea. I like it. I agree. Time for a proper Aussie Accounts Package.
We were about to trial GNUCash, but it sounds like it'll just trash my hopes again. (Didn't want to install gnome anyway).
I think having the data in SQL is a good idea (my tent is on the MySQL side of the fence). I also think PHP is a good idea - everything seems to be going AJAX, and I think PHP is the easiest to allow room for that potential.
You think it would work to make something like this modular, so people could snap in what they wanted? (A/R / A/P / GL etc. for functions ... maybe even allow easier development of other front-end options (like console
)) -- Maybe that's dreaming too far into the future at this stage...Regardless; Excellent idea. I like it. I agree. Time for a proper Aussie Accounts Package.
> The big choice now is from what components should I build it?
PHP + MySQL/Postgres would be ideal I think
Count me in if you need a hand/developer.
PHP + MySQL/Postgres would be ideal I think
Count me in if you need a hand/developer.
PHP has one big issue: It's not well suited to anything but web app development. An accounting system would ideally have at least the potential for a local "rich" GUI. Web apps have some big advantages, but a smooth and fast GUI is very difficult to achieve.
One way to support that and still use PHP is to put most of the business logic in the database its self, so multiple front-ends can be used with the database safely. Appealing, IMO. This does require the use of a powerful database with highly capable triggers, priveleges, etc. Like PostgreSQL.
Personally I'd be leery of using MySQL anyway. While it's improved a huge amount, it's still really designed around "scale-out" web-app deployment rather than for systems that have lots of in-database business logic, rules, checking, etc. As the first thing I'd want in an accounting system would be the knowledge that the database is enforcing very strong rules about the sanity of the data, Pg seems like an obvious choice, especially with PL/PgSQL.
I'm developing a newspaper booking system that has some accounting functions with PostgreSQL at the moment, and I've found its triggers and rules incredibly useful. Being able to do things like make a subsidiary journal append-only except by a batch archival job, so I know alterations can't be made to history, is very appealing. For example, I've implemented an open-item system for customer invoices/payments/etc where records are only ever appended, but for efficiency a trigger updates the balances in a summary table whenever a record is appended. The summary table is not writeable to normal users at all, so all a user can do is append payments/alterations/credits/etc to the customer journal.
Pg also offers excellent concurrency under write loads, flexible locking options when needed, in-database advisory locks, the option of READ COMMITTED or SERIALIZABLE isolation, and other goodies to make concurrent access safer and easier.
Handily, it's also very low maintenance, especially now that 8.3 has built-in autovacuum.
Even if you're not familiar with it, PostgreSQL is well worth the (fairly minimal) effort to learn. Learning to do what you already know how to do with MySQL won't take long, and after that you'll keep on finding things the database can just do for you with no fuss - so much so that you'll wonder why you ever used anything else.
The only disadvantage I see with PostgreSQL is that upgrades from (eg) 8.2 to 8.3 require a dump and reload. That's a pain, but not a problem. The only time I've ever seen issues is with the transition from 8.2 databases using tsearch2 contrib to 8.3 with built-in fulltext search. The migration was well documented and not difficult, but wasn't entirely hands-off.
It's really a no-brainer for roles like accounting databases.
One way to support that and still use PHP is to put most of the business logic in the database its self, so multiple front-ends can be used with the database safely. Appealing, IMO. This does require the use of a powerful database with highly capable triggers, priveleges, etc. Like PostgreSQL.
Personally I'd be leery of using MySQL anyway. While it's improved a huge amount, it's still really designed around "scale-out" web-app deployment rather than for systems that have lots of in-database business logic, rules, checking, etc. As the first thing I'd want in an accounting system would be the knowledge that the database is enforcing very strong rules about the sanity of the data, Pg seems like an obvious choice, especially with PL/PgSQL.
I'm developing a newspaper booking system that has some accounting functions with PostgreSQL at the moment, and I've found its triggers and rules incredibly useful. Being able to do things like make a subsidiary journal append-only except by a batch archival job, so I know alterations can't be made to history, is very appealing. For example, I've implemented an open-item system for customer invoices/payments/etc where records are only ever appended, but for efficiency a trigger updates the balances in a summary table whenever a record is appended. The summary table is not writeable to normal users at all, so all a user can do is append payments/alterations/credits/etc to the customer journal.
Pg also offers excellent concurrency under write loads, flexible locking options when needed, in-database advisory locks, the option of READ COMMITTED or SERIALIZABLE isolation, and other goodies to make concurrent access safer and easier.
Handily, it's also very low maintenance, especially now that 8.3 has built-in autovacuum.
Even if you're not familiar with it, PostgreSQL is well worth the (fairly minimal) effort to learn. Learning to do what you already know how to do with MySQL won't take long, and after that you'll keep on finding things the database can just do for you with no fuss - so much so that you'll wonder why you ever used anything else.
The only disadvantage I see with PostgreSQL is that upgrades from (eg) 8.2 to 8.3 require a dump and reload. That's a pain, but not a problem. The only time I've ever seen issues is with the transition from 8.2 databases using tsearch2 contrib to 8.3 with built-in fulltext search. The migration was well documented and not difficult, but wasn't entirely hands-off.
It's really a no-brainer for roles like accounting databases.
Love the idea.
I've been having to use MYOB on a separate Windows machine for a year now, and can't stand it. Has to be one of the worst desktop apps out there... I used Quickbooks and GNU Cash before that, and I have to say that Quickbooks was probably the best. (mind you, I was using the Business Basics verison), so it was probably a lot simpler than the other versions. Anywhoo... would love to be able to swap to a good OSS accounting package that is Australian based. I've been doing web-development for a couple of years now, and have just started using some of Zend Framework's components. Very nice IMO.
To add my 2cents to the MySQL vs PostgreSQL and PHP vs Java vs Python vs whatever.
All the languages/RDBMSs mentioned can do the job. PHP and Python both have GTK+ bindings, so are capable of handling the stand-alone app side of things.
As for the web-app side of things, you can't go too wrong with PHP. A lot of people bag it from a security standpoint, but that's more to do with poor programming than anything else, so it applies just as much to any other language.
It really all depend on what you're most comfortable with, and whether the tool will do the job.
Count me in if you go the MySQL and PHP route.
I've been having to use MYOB on a separate Windows machine for a year now, and can't stand it. Has to be one of the worst desktop apps out there... I used Quickbooks and GNU Cash before that, and I have to say that Quickbooks was probably the best. (mind you, I was using the Business Basics verison), so it was probably a lot simpler than the other versions. Anywhoo... would love to be able to swap to a good OSS accounting package that is Australian based. I've been doing web-development for a couple of years now, and have just started using some of Zend Framework's components. Very nice IMO.
To add my 2cents to the MySQL vs PostgreSQL and PHP vs Java vs Python vs whatever.
All the languages/RDBMSs mentioned can do the job. PHP and Python both have GTK+ bindings, so are capable of handling the stand-alone app side of things.
As for the web-app side of things, you can't go too wrong with PHP. A lot of people bag it from a security standpoint, but that's more to do with poor programming than anything else, so it applies just as much to any other language.
It really all depend on what you're most comfortable with, and whether the tool will do the job.
Count me in if you go the MySQL and PHP route.
Turbocash works with Wine. It's OSS. I use the V3 branch with Wine quite successfully (and I've never had printing problems). It is localised for Australia, has a good range of sub-ledgers and document support. I like it for being low-frills don't get in my way double-entry system (while originally a developer and H1 computer science graduate, now I'm a CPA).
I haven' t used v4 yet, which moves to the firebird OSS DB backend.
I haven' t used v4 yet, which moves to the firebird OSS DB backend.
We as a small business have migrated to linux apart from the Quickbooks treadmill. Which I truly detest. The latest version of QBi is even worse as I can no longer properly share it on Samba.
I would love to have an Australian OSS books and payroll system. Perhaps the best approach would be like Red Hat ?
The elements in my view that are important for consideration.
a) Accurate and correct payroll with annual / sick leave tracking
b) Time sheets
c) Yearly PAYG Report to ATO - disk file.
d) BAS reporting
e) Accountant Support
If it is online then accountants can then just access the files / system direct - rather than being given a disk. Obviously reports are important then.
f) Finally there are a few "ERP" type systems out there. Rather than re-inventing the wheel perhaps modify an existing system to allow for Aussie conditions. One I have started to look at closely is TinyERP. The accounts are supposedly localised but their is no payroll module.....
Whatever I wish you good luck. If you need a guinea pig ....
I would love to have an Australian OSS books and payroll system. Perhaps the best approach would be like Red Hat ?
The elements in my view that are important for consideration.
a) Accurate and correct payroll with annual / sick leave tracking
b) Time sheets
c) Yearly PAYG Report to ATO - disk file.
d) BAS reporting
e) Accountant Support
If it is online then accountants can then just access the files / system direct - rather than being given a disk. Obviously reports are important then.
f) Finally there are a few "ERP" type systems out there. Rather than re-inventing the wheel perhaps modify an existing system to allow for Aussie conditions. One I have started to look at closely is TinyERP. The accounts are supposedly localised but their is no payroll module.....
Whatever I wish you good luck. If you need a guinea pig ....
I'm using GNUCash; getting GST going was a pain, but for my small needs, it's quite suitable.
I agree with the guy who said that an existing ERP/CRM should be Australianised. ERP/CRM is an absolutely huge project (why do you think SAP guys get paid so much), and if you want to make something that will actually be useful for everyone, you need all those modules.
I once ran across an ERP/CRM set that was more a set of modules from which you could assemble your own ERP/CRM. It's called OFBiz. I had a link, but your filter is blocking me, and I'm trying to get around it.
There are plenty of things based on that toolkit, (ie. opentaps); enjoy
.
I agree with the guy who said that an existing ERP/CRM should be Australianised. ERP/CRM is an absolutely huge project (why do you think SAP guys get paid so much), and if you want to make something that will actually be useful for everyone, you need all those modules.
I once ran across an ERP/CRM set that was more a set of modules from which you could assemble your own ERP/CRM. It's called OFBiz. I had a link, but your filter is blocking me, and I'm trying to get around it.
There are plenty of things based on that toolkit, (ie. opentaps); enjoy
.
For those looking of OFBiz... you'll find OFBiz here.
Quicksearch
Calendar
|
November '08 |
|
||||
| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
My Photos
Syndicate This Blog
Blog Stats
Last entry: 2008-11-18 01:49
228 entries written
255 comments have been made
Blog Tags
alerting apps birthday building coding cricket email entertainment family football friends gnome google hardware health holiday house humour Internet ISP life linksys Linux marriage microsoft monitoring movies mozilla nagios networking news office open source pets play power review security shopping sms snoring software spam sport support sysadmin telephony tennis terrorism tv ups virtualbox virtualization voip web weekend windows wine wireless work