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.
Learn about Linux
Download Linux
Get Linux help
Wrong limitations
Posted by: Anonymous Coward on November 10, 2006 11:54 AM- 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.
#