Posted by: Anonymous Coward
on November 11, 2006 05:26 PM
1) We occasionally get weird roundoff errors when dealing in foreign currencies. This is pretty unsettling in an accounting program!
Rounding is one of the things SQL-Ledger doesn't do to well. One of the people on our team put together a test suite and found that LedgerSMB (and SQL-Ledger) failed key rounding scenarios. Combine that with the fact that monetary amounts are stored in the db as floating points, and you have a recipe for trouble.
I am not saying that LedgerSMB is perfect in this area either. We now pass the rounding tests in the pre-released version but that hasn't even reached beta yet. We also pass a large number of number formatting and parsing tests which the last one didn't. Making progress. Give us a few months....
2) The code itself is pretty ugly. Lots of cut-n-paste, badly organized, difficult to customize and not easy to follow. I haven't looked at Ledger-SMB, but IMO the code needs a major overhaul, not just minor tweaking.
We are painfully aware of that need. But at 60k lines of code (after removing duplicate files) it is taking some time. As most of us in the project are aware, LedgerSMB 2.0 will probably have little to no SQL-Ledger code in it.
Also note that many of these issues don't just require rewriting. THey also require carefully thinking about how things need to work, etc. So we are slowly working through things but it will take some time. Expect 1.3 (maybe 1-2 months away at current progress) to really begin this process in earnest.
3) It would be really nice to have triggers. For example, when a payment is posted, it would be nice if a script could be run that (in our case) renews our customer's download account for another year. In general, we need better integration with our CRM system (Sugar) and our various other bits of back-end infrastructure.
This isn't part of SQL-Ledger or LedgerSMB per se, but PostgreSQL has a pretty good trigger structure that can be integrated with third party scripts either via the NOTIFY framework or by actually running them (the former is preferred for latency reasons).
If you want an example (originally written against SQL-Ledger but now distributed with LedgerSMB), download the tarball and take a look in utils/notify_short. There is a simple Perl script that that listens for a NOTIFY and when received sends out a list of short parts to a contact. Also included is the trigger to NOTIFY when a part becomes short. It should work against any reasonably recent version of SQL-Ledger or LedgerSMB.
Tighter integration with Sugar is largely limited by MySQL in your case (you can pull data from MySQL into PostgreSQL without too much problem, and you can push from PostgreSQL into MySQL, but when you need real-time updates from MySQL, you have a problem). Check out DBI-Link for a nice framework to accomplish this.
Hope this helps, Chris Travers LedgerSMB Core Developer Former maintainer of the SQL-Ledger Wiki
Learn about Linux
Download Linux
Get Linux help
Re:We use it
Posted by: Anonymous Coward on November 11, 2006 05:26 PMRounding is one of the things SQL-Ledger doesn't do to well. One of the people on our team put together a test suite and found that LedgerSMB (and SQL-Ledger) failed key rounding scenarios. Combine that with the fact that monetary amounts are stored in the db as floating points, and you have a recipe for trouble.
I am not saying that LedgerSMB is perfect in this area either. We now pass the rounding tests in the pre-released version but that hasn't even reached beta yet. We also pass a large number of number formatting and parsing tests which the last one didn't. Making progress. Give us a few months....
2) The code itself is pretty ugly. Lots of cut-n-paste, badly organized, difficult to customize and not easy to follow. I haven't looked at Ledger-SMB, but IMO the code needs a major overhaul, not just minor tweaking.
We are painfully aware of that need. But at 60k lines of code (after removing duplicate files) it is taking some time. As most of us in the project are aware, LedgerSMB 2.0 will probably have little to no SQL-Ledger code in it.
Also note that many of these issues don't just require rewriting. THey also require carefully thinking about how things need to work, etc. So we are slowly working through things but it will take some time. Expect 1.3 (maybe 1-2 months away at current progress) to really begin this process in earnest.
3) It would be really nice to have triggers. For example, when a payment is posted, it would be nice if a script could be run that (in our case) renews our customer's download account for another year. In general, we need better integration with our CRM system (Sugar) and our various other bits of back-end infrastructure.
This isn't part of SQL-Ledger or LedgerSMB per se, but PostgreSQL has a pretty good trigger structure that can be integrated with third party scripts either via the NOTIFY framework or by actually running them (the former is preferred for latency reasons).
If you want an example (originally written against SQL-Ledger but now distributed with LedgerSMB), download the tarball and take a look in utils/notify_short. There is a simple Perl script that that listens for a NOTIFY and when received sends out a list of short parts to a contact. Also included is the trigger to NOTIFY when a part becomes short. It should work against any reasonably recent version of SQL-Ledger or LedgerSMB.
Tighter integration with Sugar is largely limited by MySQL in your case (you can pull data from MySQL into PostgreSQL without too much problem, and you can push from PostgreSQL into MySQL, but when you need real-time updates from MySQL, you have a problem). Check out DBI-Link for a nice framework to accomplish this.
Hope this helps,
Chris Travers
LedgerSMB Core Developer
Former maintainer of the SQL-Ledger Wiki
#