Accounting systems: a rant and a quest [LWN.net]

Accounting systems: a rant and a quest

Posted May 9, 2012 0:03 UTC (Wed) by dskoll (subscriber, #1630)
Parent article: Accounting systems: a rant and a quest

We use LedgerSMB, but we cheat... our accountant re-enters everything into his proprietary system when it comes time to filing official tax returns.

LedgerSMB has another gotcha: We are on 1.2.x and as far as I can see, there is simply no upgrade path to the current 1.3.x. I've tried the upgrade several times and each time it has failed miserably. Also, 1.3.x relies on PostgreSQL to manage users: The application user is expected to be exactly the same as the database user. I understand the LedgerSMB team's motivation (put all the user management in the database and you can ensure one and only one place for permission checking), but it's a real PITA for us to run that way.

(Log in to post comments)

LDAP users?

Posted May 9, 2012 4:38 UTC (Wed) by ringerc (subscriber, #3071) [Link]

PostgreSQL supports getting its user information from an LDAP service, or having the users entirely internal to the DB with no relationship to system users.

If the app provides a basic tool to create/drop/alter Pg users, this should be no hassle at all to manage and no different to using users defined in application tables. I'm guessing they haven't.

LDAP users?

Posted May 9, 2012 13:11 UTC (Wed) by dskoll (subscriber, #1630) [Link]

Yes, I know that. But just because I want to let people log in to an accounting application, that doesn't mean I trust those same people with the psql command-line. Conflating database users with application users is not a good idea, IMO.

LDAP users?

Posted May 10, 2012 2:29 UTC (Thu) by ringerc (subscriber, #3071) [Link]

Good point. I was assuming they'd moved to a design where all rights and permissions checking was done in the DB, such that a command-line user couldn't do anything more than a GUI user can. That's often done with appropriate trigger functions or where they aren't flexible enough the use of SECURITY DEFINER stored procs + access restricted tables.

If they're using DB-level users but not doing strict access control and checking in the DB, so a user can still wreak havoc with DB command-line access, that's not cool.

LDAP users?

Posted May 10, 2012 16:02 UTC (Thu) by dskoll (subscriber, #1630) [Link]

Hmm, I don't really know... I haven't been able to upgrade to 1.3. :(

Even if permission-checking is good, you can still do a lot more damage a lot more quickly with psql than the web interface. For example, you might be able to do a mass update in psql in the blink of an eye where the Web interface will slow you down before you can do too much damage. :)

LedgerSMB... GAAAAAHHH!!!

Posted May 10, 2012 21:03 UTC (Thu) by dskoll (subscriber, #1630) [Link]

So I took another crack at upgrading from LedgerSMB 1.2.x to 1.3.16.

Total, utter failure.

The "setup.pl" script keeps asking for a login/password and rejecting whatever I give. Tracing through a hundred twisty perl scripts, all alike, I got nowhere.

I give up. At this point, we're frozen in amber at 1.2.21. My choices now are to do a clean installation of 1.3.16 at the end of the fiscal year and start fresh, pay someone (anyone out there?) to upgrade us, or switch away from LedgerSMB.

Accounting systems: a rant and a quest

Posted May 10, 2012 0:04 UTC (Thu) by glikely (subscriber, #39601) [Link]

I had a really bad experience with the 1.2.x series of LedgerSMB when I was running my business on it about 4 years ago. Invoices couldn't be reprinted accurately if the sales tax rate changed, and it didn't handle foreign currencies well. My accountant really wasn't happy when I couldn't produce an general ledger report and trial balance that added up to the same values. I haven't looked at the 1.3.x series, so things may be better now.

I switched from that to Postbooks which has worked extremely well. I particularly like that the database logic is implemented as Postgresql stored procedures which means it is safe to use other applications to manipulate the data (like to import transactions). I back the whole thing up with a plain-text dump of the database stored in a git tree. Most importantly, I've not had a complaint from my accountant since. :-)