Linux.com

Feature: Enterprise Applications

SQL-Ledger: Impressive capabilities, but needs polish

By Mayank Sharma and Conrad Canterford on November 09, 2006 (8:00:00 AM)

Share    Print    Comments   

SQL-Ledger is a popular free accounting application with a rich set of features. It's written in Perl and stores your accounting information in a PostgreSQL database, which makes deployment much easier when you have users who work on different machines. Like GnuCash, supports double-entry accounting. Unlike GnuCash, however, it appears to be squarely aimed at the small business community, boasting multiple user support, multiple company support, point-of-sale entry, accounts receivable and payable, and stock tracking. It has a good list of supported languages (29, according to the Web site), and by virtue of its HTML interface is usable on practically any modern operating system -- or indeed a whole range of different operating systems simultaneously.

Installation is straightforward; just download a tarball to /usr/local/sql-ledger and run the setup.perl script. It automatically downloads and installs the latest version of SQL-Ledger and updates Apache's configuration file. The script doesn't check for dependencies -- you'll need to do that beforehand. On an Ubuntu Dapper box, one of the authors runs it with Perl 5.8.7, along with the libwww-perl library, which provides an API to the Internet, PostgreSQL 8.1, and Apache 2 with the libapache2-mod-perl module to make it process Perl code. SQL-Ledger also needs a Perl database interface library, libdbi-perl, and a database driver for PostgreSQL server, libdbd-pg-perl, which is available under the universe repository.

The setup script prompts for the user and group running the Web server. In Ubuntu, Apache 2 is run by the www-data user and group. Upon completion, the script adds the necessary Alias directives to a sql-ledger-httpd.conf file placed under /etc/apache2 and makes appropriate changes to Apache's httpd.conf. Although Apache 2 uses the new apache2.conf file, it maintains the old one for backward compatibility and to support third-party applications that look for it, including SQL-Ledger.

Once the automated script has done its work, you need to refer to the included README to prepare your installation by adding a user and database to PostgreSQL. The document will then guide you to the administration panel of SQL-Ledger, where you are asked to create a dataset for your company. Next you need to associate this dataset with a Chart of Accounts. SQL-Ledger includes several account templates for various kinds of businesses. There are general charts for several countries, including Austria, Hungary, Poland, Spain, Italy, UK, US, and Canada. Then there are business-specific charts such as Sweden_Church_Society, Sweden_Agriculture, US_Service-Company, and US_Manufacturing.

Finally, you must add a user and associate it with a dataset.

When you log in into SQL-Ledger as a user, you'll be greeted with an interface divided into two frames. The left frame houses the navigation menu, broken down into several sections and sub-sections. The right frame contains the main screen where you can enter data. This works well enough on a screen at 1400x1050 resolution, as there is plenty of room on the screen for the full display of data in the right-hand pane, but space in the data pane might get a bit cramped at 1024x768 or lower resolutions. If you are switching over from a fancy Windows-based accounting package, SQL-Ledger might look too plain for you, but for what it lacks in looks, it more than makes up with its functionality.

The bigger hassle (for us, at least) is that the data pane was almost completely unused for navigation. It displayed nothing until you had drilled down through the menu system -- anything from two to four clicks in the menu. In their defense, the menus do expand and stay expanded, so you only need to drill down once per session for each screen or report, but it was still annoying. This is certainly not an interface you can use without a mouse. We could happily live without the pretty graphs and the command-line-only imports, but that menu system is just horrible.

For example, to get a list of all vendors you have to click on AP -> Vendors -> Reports -> Search before finally clicking on the Continue button in the data pane to access the list. It would be sensible to use the data pane much earlier in the process. For example, you could show a list of active vendors (or the last 20 used, or something) when clicking the Vendors menu. That would save a lot of clicking. Similar logic applies to Customers and products too.

There are some nice features, but they seem to be a little inconsistently applied. Take the selection of Customers, Vendors, or products. In most places where you need to enter a customer or vendor ID, the software will offer you a drop-down box to select from a list. That's a good solution where there is only a small selection to choose from. A nice innovation in the selection of product IDs was the ability to enter a partial code. You are then presented with a screen where you can select which product you want from those matching the partial. If you didn't match anything, it assumed that you were entering a new product and went through a new product entry process, which may not be what you want, but apart from that it was very nice. Unfortunately, it was really overkill when we were testing with just four products -- a dropdown box would have sufficed. What we would have liked to see was a combination of the two (for Customers, Vendor, and products, at least). Use the dropdown box for small numbers (perhaps a user-configurable level?) and use the partial match functionality for larger numbers.

Just to confuse matters, if there isn't anything that matches the requirements for the field (for example, if you have no vendors configured and you go to the Enter Transaction screen under the Accounts Payable menu), it displays a text box as it does for products, but instead of allowing you to enter a code and commence creating a new record as it does for products, it gives you an error message. If it is going to do that, just displaying a message on the screen that first comes up (the Enter Transaction screen, in my case) would be far better.

SQL-Ledger boasts of support for multiple companies and users. Unfortunately, users are tied to a single company. We would like to be able to log in, then select the company we wish to operate on, but you need a separate user for each company.

While SQL-Ledger does a good job to get you up and running with the charts of accounts, you'll need to remove a few accounts and add a couple of your own by making a visit to System -> Charts of Accounts -> List Accounts, which will not only list the accounts, but will also let you customize them.

Imports, reports

A few issues fairly quickly came to light when we attempted to load some sample data to test with. There are several migration scripts available to import your data from another accounting application into SQL-Ledger, but there are no import options accessible through the online screens. To import data you need to use a command-line tool -- and that completely defeats the whole purpose of a multiuser, platform-independent interface. There are command-line tools downloadable from the Web site to import from GnuCash (which didn't work for me without modification), and for a couple of versions of Quickbooks. There is also a generic script which, from its description, looks like it imports from CSV files. It is certainly not clear to me that it will support QIF. Needless to say, it does not support any form of online banking.

A strong point of SQL-Ledger is its reports. Every account has a report module attached that can be customized to display details of your choice between any time period you choose. The reports can be printed or sent as a PDF, PostScript, or HTML attachment.

The reports are functional, but they lack any of the pretty-picture features (bar charts, pie charts, etc.) that senior managers and venture capitalists like. While the option selections and the range of reports seem quite comprehensive, it's unfortunate that they are scattered all through the menus; that would become tiresome quickly.

If you send bills over email, you can do that right from SQL-Ledger, and with a cover letter. This is also useful for keeping backups. If your business needs to track sale and purchase orders, or make or request quotations, these too can be printed, emailed, or saved through a single click with SQL-Ledger.

The templates for the reports are all editable and can be modified to change placement of a particular item or to carry your company logo. They can be found under the /usr/local/sql-ledger/templates directory in HTML, TeX, or text format.

More than one person in most organizations will need to access an accounting application. Log in as admin to add users and associate them with the company (dataset). But you wouldn't want your clerk that handles sale and purchase to look at your balance sheet or to send reports. A user's activity and access to accounts can be easily controlled by the administrator by removing entire menu headings or only specific items under them. The user privilege levels appear to be flexible and should be able to be adapted to most people's requirements.

Talking of security, SQL-Ledger can be configured to comply with the generally accepted accounting principles (GAAP) by forcing users to post reversing entries instead of deleting transactions. You can also set accounting periods, which once closed cannot be edited.

If you require, there is also a fairly usable point-of-sale (POS) module that can be hooked up with a bar code reader for inputing item details.

Documentation and support

SQL-Ledger is an open source application. There's a FAQ and installation instructions on the download page for various platforms available for free, and there's also a user and several active regional mailing lists on which the developer pops in occasionally with his inputs.

Although this should suffice for most users, if you are using it for a commercial house, it will help if you buy the documentation and the support that comes along with it. This is the catch with this program. While the program is free software, to get the documentation (other than installation instructions), you must purchase it. This is the developers' main source of revenue. Having to pay for the documentation irks us, especially when the documentation is important to make proper use of the program. The developer appears very negative towards community-based documentation, presumably to encourage you to buy theirs:

Community based documentation does exist to some extent however the reader is cautioned not to rely on such information because it may be incorrect. Some of the information we found is really old and if no references that this applies to version so and so appear it's pretty hard to figure out if it can be used. We know but you don't. It is not our job to check wikis and correct mistakes. With over 500,000 pages floating around on the Internet it would be a full time job just to look at everything.

There is a uses mailing list that you can join so you can ask questions of other users, and we have seen comments from users that suggest that the list is active and helpful. If you want more immediate assistance, the Web site has only very superficial information. We did find a couple of helpful third-party Web sites, but none had a great deal of detail. We also found a useful FAQ.

You can try playing around with SQL-Ledger without installing through the online demo.

Conclusion

We were a little disappointed in SQL-Ledger. We were expecting a more polished program. If you need an accounting solution that supports multiple users with configurable access levels, or access across a variety of operating systems, install it and have a play. The basis for a good program is there, it just needs a bit of polishing. It's easy to install and use, is Web-based and secure, can handle multiple users, and is customizable to the core. The biggest thing its been accused of missing is a payroll management module. Additionally, the chances of it hooking up with your bank are quite slim, which is actually a lack of effort on part of the bank than the application.

While SQL-Ledger is multi-lingual and can handle currency conversations, it's best suited for users within the US and EU. Furthermore, though it can handle any type and size of organization or even multiple organizations and manufacturing units, it isn't the ideal application to keep track of an individual's personal finances.

Share    Print    Comments   

Comments

on SQL-Ledger: Impressive capabilities, but needs polish

Note: Comments are owned by the poster. We are not responsible for their content.

Wash behind your code.

Posted by: Anonymous Coward on November 10, 2006 02:43 AM
Would have been better if it had a SOAP interface.

#

Re:Wash behind your code.

Posted by: Anonymous Coward on November 10, 2006 04:24 PM
Well why don't you write one for it?

#

LedgerSmb

Posted by: Anonymous Coward on November 10, 2006 02:59 AM
Ledger SMB is a fork of Sql-ledger. They have a bit more documentation. <a href="http://www.ledgersmb.org/" title="ledgersmb.org">http://www.ledgersmb.org/</a ledgersmb.org>

#

ProjectERP

Posted by: Anonymous Coward on November 10, 2006 02:59 AM
I've been investigating the Open Source ERP projects out there, because our Company wants to offer also a Linux/Open Source Solution.
You can see all the projects I've found and our own project on <a href="http://www.projecterp.de/" title="projecterp.de">projecterp.de</a projecterp.de>

The page is written in german but many links lead to english pages.

BTW: ProjectERP is an ERP-Suite inside of eGroupware. You (Newsforge) <a href="http://www.linux.com/article.pl?sid=06/09/29/1552214" title="linux.com">said</a linux.com> some weeks ago, you would do a testdrive with eGroupware...

#

Re:ProjectERP

Posted by: Anonymous Coward on November 10, 2006 12:02 PM
I noticed that eGroupware supports MySQL as a database backend. Of course this means that although you can sanely deploy it (Oracle or PostgreSQL), you can also install it on MySQL 4 (which will do fun things like truncate numbers for you), and in which case you get what you deserve...

Anyway, best of luck to your project. I would just suggest you document that running an accounting system on MySQL is not exactly advisable.

#

Re:ProjectERP

Posted by: Anonymous Coward on November 10, 2006 12:20 PM
Please be aware, that the above comment is <a href="http://en.wikipedia.org/wiki/Fear%2C_uncertainty_and_doubt" title="wikipedia.org">FUD</a wikipedia.org>. That means, it tries to send you: Fear, uncertainty and doubt.

The author claims, that "running an accounting system on MySQL is not exactly advisable", but lacks to reason his statement.

Why shouldn't it be advisable?

What are the benefits of PostgreSQL and Oracle about MySQL?

#

MySQL v. PostgreSQL for accounting applications

Posted by: Anonymous Coward on November 10, 2006 12:28 PM
<a href="http://sql-info.de/mysql/gotchas.html#1_13" title="sql-info.de">http://sql-info.de/mysql/gotchas.html#1_13</a sql-info.de> is a good place to start.

The correct behavior for any database is to ALWAYS throw an error and do NOTHING when it can't store exactly what you tell it to. This is especially true when you are working with financial data.

What about strict mode? Strict mode doesn't protect your data if applications can turn it off with no help from the admin.

The other gotchas are somewhat serious, but that one is a killer.

#

Re:Missing Department and Product codes for the GL

Posted by: Anonymous Coward on November 10, 2006 09:44 AM
Well, you're probably right. BUT...

First, I wouldn't call a supermarket a "small business", even if it technically fits the standard SMB definition.

Second, your example illustrates the problem with ANY package claiming to do a "standard" accounting job - there IS NO SUCH THING!

Every business is unique in the way they handle their accounting. Any accounting or ERP system needs to be massively modifiable to be usable.

SQL-Ledger is probably usable for very small businesses, but probably would need to be customized and installed by a consultant for anyone larger - or just have the code cannabilized and installed inside a larger system that dealt with the complexities of the business in question.

Over twenty years ago, IBM released the System/32 small business computing system. They said it was perfect for small businesses. It's range of pre-designed accounting packages would eliminate small business having to hire IT staff.

Hah! It started a major boom in consultants writing customized packages for small businesses. The hardware was cheap enough (at the time) to be attractive to small businesses who hadn't been computerized before - but they ate up the cost reduction in consultant fees.

The same will happen here. The advantage OSS has is that improvements and customizations can be returned to the project and thus the project continually improves better and faster than any one proprietary company system can - provided enough people and consultants actually use the system and return the improvements to the project.

#

Re:Missing Department and Product codes for the GL

Posted by: Administrator on November 10, 2006 09:11 PM
I had a girlfriend in collage whose father owned a small general store in a small town. His entire staff of 'help' consisted of two high school boys who mopped and swept. He had the same problems with in store categories and determining if a section or product line was profitable that the supermarket example has. In another response here I listed my 'big system' biases along with other credentials; no reason to repeat them here. But I do disagree on the need to massively modify a system to be usable. We are not talking about support ADB for a bank or even 52/53 week years or 13-period accounting here. Just the ability to configure accounting organizational breakdowns. I have installed systpes repeatedly during my career without modification - any modification. There have been many more with low levels of mods not affecting the issues here. Even a small widget factory will need to know the cost of operating an HR Department separate from the Shipping Department or the Parts Assembly Department. In a total of 39 years in business, I've only seen three basic models in automated General Ledgers;
- No org breakdown (this model, Quickbooks)
- Org breakdown with summary reporting at report time (M&D, MSA, D&B, Lawson, Global, Platinum, Oracle, PeopleSoft)
- Org breakdown with summary reporting at data entry time (Software International, also known as GE and CA Universe).

#

LedgerSMB

Posted by: Anonymous Coward on November 10, 2006 10:25 AM
(the fork) is in a rapid development phase, has fixed some numeric and security concerns, rebuilt the tax handling methods, brought the locales methodology up to snuff, using open standards, and generally cleaned up the code. Look forward to a stabilized API in forthcoming ver. 1.2, and from there, a slew of new features in v 1.3

#

Re:LedgerSMB

Posted by: Anonymous Coward on November 10, 2006 12:05 PM
In case anyone is interested in what is going on with LSMB 1.2, take a look at the changelog: <a href="http://ledger-smb.svn.sourceforge.net/viewvc/ledger-smb/trunk/Changelog?revision=483&view=markup" title="sourceforge.net">http://ledger-smb.svn.sourceforge.net/viewvc/ledg<nobr>e<wbr></nobr> r-smb/trunk/Changelog?revision=483&view=markup</a sourceforge.net>

#

LedgerSMB-- more polish, more features, more...

Posted by: Anonymous Coward on November 10, 2006 11:29 AM
Ok, I am one of the core developers of LedgerSMB, but since this is about SQL-Ledger, I think they missed a few key issues.

We split from SQL-Ledger because we didn't find the author's response to security issues to be adequate (and that is putting it kindly). Even today, we have notified him of a number of serious security issues we have fixed in our fork and these remain unpatched...

LedgerSMB is also a truly open project. We have open documentation, a diverse development community, a lot more polish (the setup.pl detects and downloads dependencies, for example), better security, better data integrity controls, and quite a number of other features not found in SQL-Ledger.

Our development is proceding at a very rapid rate. LedgerSMB 1.1 has been available for a bit over a month and our next version is already around the corner (with credit card processing, better tax handling and more). This is in large part due to a top-notch team of developers from across North America and a community of contributors from around the globe.

#

Wrong limitations

Posted by: Anonymous Coward on November 10, 2006 11:54 AM
Actually everything you mentioned is somewhat out of date and is supported.

- Keeping the produce, grocery, meat, frozen food, and non-foods departments separate without multiplying the number of accounts exponentially.

Partsgroups could be used here. Plus you can always generate custom reports from the database based on arbitrary criteria...

- Keeping two or more stores distinct without having to have multiple companies and all the I/C accounting that would be needed. Especially if not required legally.

Multiple warehouses are supported and this is what you would use.

- distinguishing products within departments, like beef, lamb, pork, chicken within the meat dept.

See partsgroups above.

- different types of items with different labor, profit, spoilage rates - all of which needs to be managed fianancially.

What do you need out side of goods, services, customers, vendors, labor/overhead, assemblies, etc. Granted working in the manufacturing sector leaves a lot to be desired.

The real limitations are not feature but design issues:

1) Security: Secunia lists 50% of SQL-Ledger vulnerabilities unpatched (after over a month). These include an arbitrary code execution issue. Also from some error messages, it looks like there might be SQL-injection issues too.

2) Data integrity: Some time ago, there was a discussion on the SL mailing list about the fact that SL uses float's internally to handle monetary amounts. Perl handles the arithmetic OK, but PostgreSQL represents floats in their IEEE representation (which means round-off errors). The author should be using NUMERIC types but chooses not to for so me unknown reason. Also, it will let you store NULL's in the transaction table's chart id field (i.e. we don't know where the money went...) and there are no protections against duplicate transaction id's (which result in data ambiguity, which is a Bad Thing).

3) The database design and queries are somewhat poorly thought out. I have one customer running SL which was running into performance issues because of issues with left joins and the fact that this was a HUGE table being joined with empty tables. The author is obviously not aware of performance tuning with PostgreSQL (I had to rewrite queries to make this problem go away).

4) The documentation on the SL site is WAY out of date, and somewhat inaccurate. He still lists DB2 and Oracle as supported (they haven't been in 2 years), and he suggests running a 3 year-old DBD::Pg on Windows when newer (less buggy, more secure, etc) versions are available. Furthermore, the process he suggests for upgrading to ActivePerl 5.8 on Windows results in internal server errors/access violations because of binary incompatibilities between ActivePerl 5.8 and DBD::Pg (this is documented by ActiveState, BTW).

The situation is so bad, I am looking at migrating my customers to other forks. Unfortunately all the forks look dead except LedgerSMB. But at least they seem to be taking these problems seriously.

#

Re:Wrong limitations

Posted by: Administrator on November 10, 2006 08:48 PM
Thank you for the technical update on the project. I appreciate the info.
My comments were limited to what I could see in the online documentation as I have no experience with the product. You'll note, I only commented on the GL which is my primary field of knowledge.

I could not see any indication of any of these warehousing categories extending into the GL. There doesn't appear to be any Journal entry capability for these either. Did I miss something?


  I've been a Financials systems implementer for 25+ years, starting with M&D, MSA, SI, Oracle, and PeopleSoft, so I admit to big system biases. But some kind of GL sub-organization breakdown (departments and products) is needed for any but the smallest organizations. I observed the supermarket example first hand watching my father manage a family-owned store for his uncle for many years and have an undergraduate degree in Marketing and Food Distribution (reasons why I'm not in retailing!).

#

Correction: single user, multiple companies

Posted by: Anonymous Coward on November 10, 2006 12:34 PM
Actually, you can use the notation of user@company. When the username is entered, if there are multiple companies associated, it will provide a list for you to use to choose. Works in both LedgerSMB and SQL-Ledger.

Of course this Secret Knowledge and more is only supposed to be yours if you pay $190 for the manual.

#

Business/money

Posted by: Anonymous Coward on November 10, 2006 06:10 PM
I've noticed that lately there are ALOT of business/money-related articles here on Linux.com

#

Re:Wrong limitations

Posted by: Anonymous Coward on November 10, 2006 11:07 PM
Most of the time people use the invoicing system to manage most of what you require. For example, create a customer named "spoilage" and sell him all the spoiled goods at 100% discount... THis way, not only are your books accurate financially but your inventory numbers are updated as well (if you use GL, the number of on-hand items is not reduced by the number of spoiled ones).

Now, as to GL, SL is pretty limited to straight financial information. You do have departments listed, and you could use projects to track some of this, but that is about it. LedgerSMB however, provides a standard way of attatching custom information to any database object, so if you need something like this, it could be implemented pretty easily. I haven't seen this feature in any other fork.

The other big issue with SQL-Ledger is that the documentation is proprietary and hopefully is better than the outdated/flat-out-inaccurate bits on the site, but it is too expensive for people to buy just to see if they might like the software.

#

Re:Missing Department and Product codes for the GL

Posted by: Anonymous Coward on November 10, 2006 11:24 PM
I have a customer who uses SQL-Ledger in a retail management environment, and I am a core contributor to LedgerSMB. We are expecting to migrate them within the next couple weeks as 1.2 stabilizes.

SQL-Ledger out of the box has a lot of issues working with retail environments. Aside from the performance issues (which are resolvable), and the security issues (which reqire rewriting most of the code), SQL-Ledger doesn't support much in the way of POS equipment. Having cash drawers that can be opened without printing in invoice is a pretty major issue.

Aside from the POS customization framework changes (pole display, cash drawer, till reconcilliation, and workflow optimizations), we had to deal with the issues you mention.

What we did was:
1) Divided up the products into 12 categories which mapped to income accounts.
2) Each was had the UPC
3) Added rapid invoice entry and inventory adjustment calculations
4) Added an inventory report that showed (by part) income vs. COGS. We could have done this by category too, but this is what the customer wanted. This report also had income and expense, and the ability to drill down to see the individual invoices involved.

We weren't able to move them before 1.2 because these customizations weren't compatible with the current codebase. We are just starting to test the 1.2 codebase in their environment.

You are absolutely right that SQL-Ledger is inadequate for a retail environment. But even so, the cost of modifying it to do what they wanted it to do was only a couple thousand dollars including all implementation effort (compared to the cost of a proprietary POS application for multiple tills). THese core enhancements are now part of the LedgerSMB codebase, and the version that includes them is scheduled for a Beta 1 release on Monday.

Best Wishes,
Chris Travers
Core developer, LedgerSMB
Former maintainer of the SQL-Ledger Wiki

#

A little more information

Posted by: Anonymous Coward on November 10, 2006 11:44 PM
We are committed to doing LedgerSMB right. We are in the process of re-engineering the entire application. 1.2 will fix all outstanding security vulnerabilities except the lack of real permission management (which will be addressed in 1.3). In addition, every release, we are re-engineering a part of the system.

1.2 addresses defaults handling, tax handling, and a few other issues. 1.3 will, at a minimum, re-engineer the vendor/customer system allowing for multiple shipto's and the like.

Part of the problem is that, as the article implies SQL-Ledger is "almost good enough" but in many, many areas it lacks little bits here and there that are necessary.

Let me take a moment to illustrate a number of the issues we have fixed. THese are real issues that real customers have run into:

1) In places like Ontario where tax rules are fairly contextual (pastries are taxable if they are not individually wrapped, you buy fewer than 6, and the subtotal is greater than $4 CAD). SQL-Ledger and prior versions of LedgerSMB did not handle this correctly.

2) Localization was done in a very non-standard and bug-prone way. Customers in some locales were having bugs in the software caused by lacking translations.

3) THe point of sale system was inadequate for any retailer (even the smallest one). Now it will work at least for small retailers.

4) A huge number of security issues including both SQL injection and arbitrary code execution issues. (Of course, when we started, one could exploit these issues in SQL-Ledger without even logging on. Now at least, the login issue is fixed.)

In fact let me mention this to any readers: If you are running SQL-Ledger from version 2.4.4 through 2.6.17, please upgrade immediately. These versions allow non-authenticated users to hijack sessions, run arbitrary code, etc. through trivial and documented means.

5) The documentation from SQL-Ledger has erroneous information about how to run it on Windows with Perl 5.8. We now fully document this process.

6) We now document how to get server-side printing working on Windows.

7) We fully expect LedgerSMB 1.2 to ship with native OSX installers, rpm packages,<nobr> <wbr></nobr>.debs, gentoo ebuild support and maybe even Win32 installers (depending on how testing goes).

Best Wishes,
Chris Travers
LedgerSMB core team

#

Payroll?

Posted by: Anonymous Coward on November 11, 2006 08:43 AM
It doesn't look like this thing doesn't even do payroll! That's pretty useless.

#

Re:Payroll?

Posted by: Anonymous Coward on November 11, 2006 09:37 AM
Hmmm.... About half of my small business customers use Quickbooks, which offers a payroll solution. Interestingly, less than half of those that use Quickbooks use the payroll module. Some don't want to pay for it. Some find it doesn't match what they want to do, etc.

So payroll isn't the killer feature that a lot of customers need.

Also SQL-Ledger has been promising payroll Real Soon Now for about two years. But it never comes. Indeed, it has a half-written but dormant payroll module contained in the HR.pm. Evidently the developer coded himself into a corner and couldn't get out so he decided to abandon that feature for others.

We at LedgerSMB are actually in the process of analyzing the needs of payroll. Like sales tax, it seems simple on the surface until you realize that ever state, province, country, etc. has rules and exceptions which make it anything but simple. For example, in Washington State, agricultural workers have some state payroll taxes waived on certain types of work. If you have a paycheck that mixes types (for example, 4 bins of apples harvested and 10 hours of misc work), you have a problem that even the solutions currently on the market can't handle.

We expect payroll in LedgerSMB to take another couple months. SQL-Ledger will, however, likely never have it.

Best Wishes,
Chris Travers
LedgerSMB core developer
Former SQL-Ledger Wiki maintainer

#

We use it

Posted by: Anonymous Coward on November 11, 2006 10:12 AM
We use SQL-Ledger, and it works reasonably well for us. However, there are annoyances:

1) We occasionally get weird roundoff errors when dealing in foreign currencies. This is pretty unsettling in an accounting program!

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.

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.

In spite of those complaints, I've found SQL-Ledger to be very handy, and have paid for the manual to support its development.

#

Re:We use it

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

#

Re:We use it

Posted by: Anonymous Coward on November 12, 2006 05:29 AM

LedgerSMB 2.0 will probably have little to no SQL-Ledger code in it.



That's good to hear! Good luck with your project; I'm following it keenly.



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).



A push model is fine for me; we already have scads of Perl scaffolding connecting Sugar <-> Asterisk <-> SQL-Ledger <-> Our download authorization database. For example, one of the neat things we have: When a customer calls tech support, we automatically get a new tab in Firefox showing the Sugar data, a list of invoices and whether or not they've been paid, and a list of open RT tickets.



We just need a standard, modular way to add hooks into SQL-Ledger to kick off our push scripts.

#

More details on integration

Posted by: Anonymous Coward on November 12, 2006 08:38 AM
We just need a standard, modular way to add hooks into SQL-Ledger to kick off our push scripts.

Ok, there are two ways to do this, both of which take advantage of PostgreSQL triggers.

The first is that you can add PostgreSQL triggers that don't do anything themselves but just let applications that are listening know that they may need to do something. The example I mentioned earlier uses this mechanism to list a script know that it needs to run a parts-short report and mail it to someone, but really the script could do anything. This is a good way to do things because the processing is asynchronous to the database transactions, so your commit doesn't have to wait for the database transaction in PostgreSQL isn't waiting for the MySQL database transaction to complete.

The second way is using David Fetter's DBI-Link package. This is a set of PL/Perl routines that allow a PostgreSQL database to interact with other datasources as if they were local. WIth this package, you can define your Sugar tables as targets, and then add PostgreSQL triggers to manipulate that database as you need to.

PostgreSQL is an awesome db from the perspective of integration. Right now, its capabilities are the best ones to use for this sort of thing.

Longer-term, I don't know where SQL-Ledger is going. LedgerSMB is likely to be gradually implementing web services (based on RESTful principles) between now and 2.0.

Best Wishes,
Chris Travers
LedgerSMB core developer
Former maintainer of the SQL-Ledger Wiki

#

Re:More details on integration

Posted by: Anonymous Coward on November 12, 2006 10:45 AM

Ok, there are two ways to do this, both of which take advantage of PostgreSQL triggers.



But that's the wrong approach. Integration based on PostgreSQL triggers means I need intimate knowledge of the database schema. If the database schema ever changes, my triggers might break or be inappropriate.



I want triggers like:


  • $X.YY has been received from customer Q and posted as Cash Received.

  • Invoice nnnn has been fully paid.

  • Invoice mmmm is now 30 days past due (this would probably need to be checked from cron)


These high-level actions need an API, something you alluded to.

#

Re:More details on integration

Posted by: Anonymous Coward on November 12, 2006 12:26 PM
But that's the wrong approach. Integration based on PostgreSQL triggers means I need intimate knowledge of the database schema. If the database schema ever changes, my triggers might break or be inappropriate.

Well, in the long run, I think that both approaches have a great deal of merit in different areas.

The schema is going to change, and this can require changes to the triggers. However for some things that are simple and self-contained (notifying when a part becomes short), they work well. Also they are the only way to ensure that when data is changed in the db, you get real-time notification (what if the modification happens through another application that might be using shared stored procedures?). Also these are very good for areas where you *must* be sure that some change to information happened. For example, if Interchange and LedgerSMB (or SQL-Ledger) are running in different schemas in the same databases, triggers allow you to make sure that when an order is enterd in Interchange, it is definitely entered in LedgerSMB too (i.e. they both succeed or fail as a transaction). No other mechanism gives you this level of control.

The API is ideally when you need rough high-level ways of asking questions. I.e. you want Sugar to be able to list invoices on demand. In the end, it really depends on what you want to do which approach is best.

Long-range LedgerSMB will support both approaches.

Best Wishes,
Chris Travers

#

A few more thoughts on API's.

Posted by: Anonymous Coward on November 12, 2006 03:26 PM
We are actually building APIs at several levels.

Once we get portions of the database schema stable, sane, normalized, and reworked, there will likely be few if any changes to these parts of the schema for a long time and when we do, we are likely to be working with the community on making sure we have a lot of community feedback in. Having the storage schema be considered a stable API is an important thing, I think.

RIght now, the SL schema is relatively poorly thought out. A lot of things need to be fixed and this is going to require a fairly thorough schema rewrite. After that, I don't foresee a lot of changes that break backward compatibility.

Also a lot of data logic is going into the db. Data logic being the logic needed to store, abstract, and maintian the data. So access to the data itself from outside applications can be made through a standard interface.

So there will be a database-level API.

Another plae we will have an API will be via web services and command line tools. The core dispatcher API will use XML as its primary representation format.

The final place is that we are going to have a light-weight CLI API for interfacing through Cron and other places where light-weight scripting is helpful.

So there will be API's available on many levels. These will be far more stable than the SL API has been in the past, but anyone doing their own custom work would do well to join the devel list so we can work with you to discuss how stable various parts are at the moment and give you fair warning before making changes. All API's can change if there is enough reason to, though we all know stability of the API is a good thing.

Best Wishes,
Chris Travers

#

Secure?

Posted by: Anonymous Coward on November 16, 2006 05:55 AM
It's easy to install and use, is Web-based and secure

I can't imagine how the OSTG folks came up with this conclusion. I've had a look at SQL-Ledger's code, and frankly the security aspect of this software is very troubling.


  The code appears to be very disorganized and haphazard, which makes looking for security problems more difficult. Doing a grep for 'exec' and 'system' finds some fun things pretty quickly: In SL/Form.pm (line 314 - version 2.6.19), there is an exec that will execute $script with $args, yet neither are untainted or verified and come directly from user input. SL/AM.pm (line 1535) there is a system call in @args, also with very lax to no checking of input.


  There are appear to be numerous vulnerabilities via XSS and sql injection. This combined with the apparent hostility the developer has toward security reports (check the users list archives for evidence of this) makes SQL-Ledger a fairly dangerous product to use. I would strongly recommend that you either consider another application or at the very least keep your installation away from public networks and any potential malicious users (like your staff). To anyone slightly conscious of security, this essentially makes it a non-networkable, single user product.


  So, my question to the OSTG editors/writers: What did you do exactly to declare this software secure? I would love to know your methodology.

#

Missing Department and Product codes for the GL

Posted by: Administrator on November 10, 2006 04:00 AM
Sorry, this isn't an acceptable system, even for a moderate-sized retailer. Taking a supermarket, as an example (we all buy food);
- Keeping the produce, grocery, meat, frozen food, and non-foods departments separate without multiplying the number of accounts exponentially.
- Keeping two or more stores distinct without having to have multiple companies and all the I/C accounting that would be needed. Especially if not required legally.
- distinguishing products within departments, like beef, lamb, pork, chicken within the meat dept.
- different types of items with different labor, profit, spoilage rates - all of which needs to be managed fianancially.

Don't get me wrong, there is opportunity to improve GREATLY with simple additions, but as is, not acceptable for any but the smallest businesses.

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya