LedgerSMB
![]() LedgerSMB login screen
|
|
Initial release | 2006-09-06 |
---|---|
Stable release | 1.4.21 / 2015-12-21 |
Preview release | 1.5.0-beta3 / 2015-12-01 |
Development status | Active |
Written in | Perl, PL/SQL |
Operating system | Any Unix-like, Mac OS, Windows, Android |
Platform | Cross-platform |
Type | Accounting, ERP, CRM |
License | GNU General Public License |
Website | ledgersmb.org |
LedgerSMB is a free software double entry accounting and Enterprise resource planning (ERP) system. Accounting data is stored in a SQL database server and a standard web browser can be used as its user interface. The system uses the Perl programming language and a Perl database interface module for processing, and PostgreSQL for data storage. LedgerSMB has Multitenancy support.
LedgerSMB is distributed under the terms of the GNU General Public License.
Contents
Capabilities
LedgerSMB features a full GL, along with inventory management and invoicing capabilities. It also features project accounting and reporting, light manufacturing, and basic MRP. The underlying structures for supporting basic CRM capabilities are in place, but these are not yet exposed to the front-end.
As of version 1.3, separation of duties is now a part of LedgerSMB except for inventory-affecting invoices. However, version 1.3 can use orders and invoices as separate documents in a manner similar to vouchers and transactions in a paper accounting world. Full separation of duties for these documents is currently planned for 1.4.
LedgerSMB supports multiple currencies and per-user language settings. It also supports per-customer language settings and invoices can be translated into various languages when printed, and per-language invoice templates are also an option.
Releases
1.4.0 was released on 2014-09-15 with another sizable change log, and development is continuing at a rapid pace.
The 1.3.0 release came out on 2011-10-11, with a sizable change log, generally focussing on performance, separation of duties and fixing the (design) issues in 1.2.
The 1.2.0 release included a number of very deep security fixes and the beginnings of the refactoring process. The tax and price matrix code was centralized. This release was quite problematic and the core team ended up pulling 1.2.0 and 1.2.1 from public distribution due to a number of issues in integrating old and new code. Many members of the core team have expressed frustration at the level of problems, but Chris Travers has generally likened the problems to those of Apache 2.0,[1] where changes in architecture have caused problematic releases. While it may be too soon to tell, the general hope is that 1.2.x will be the most difficult and problematic release, perhaps of all time.
At the same time, it cannot be denied that a number of the problems in 1.2.0 were the result of trying to do too much too quickly without adequate review. It is difficult to fault the project for this in some cases (removing SQL injection issues) but it remains to be seen whether the project is able to continue to move forward in such a way as to prevent this from being a problem in the future.
The 1.1.0 release merged in many patches that had been done for other customers but did not change the structure of the code in any significant way. By this time, however, most of the core members were unhappy with the current architecture and had decided to work on refactoring the code.
The initial release (1.0.0 on 2006-09-06[2]) and the events leading up to it, are described in the History section.
History
The project began as a fork of SQL-Ledger when Chris Travers, dissatisfied with the handling of security bugs in SQL-Ledger, partnered with Christopher Murtagh to produce a fix for CVE-2006-4244.[3] This bug was apparently reported to the SQL-Ledger author, Dieter Simader, several months prior[4] to the Chris' working on a patch. The initial release of LedgerSMB, along with full disclosure of the bug on the main mailing list,[5] strained relations between SQL-Ledger supporters and the members of the nascent LedgerSMB project.
The forking of LedgerSMB is considered by some[6] to be part of the reason for the anti-forking clause[7] in the short-lived SQL-Ledger Open Source License, which was used for SQL-Ledger 2.8.0.
1.3+ Architecture
Even though LedgerSMB started out as a fork from SQL-Ledger, it has rapidly diverged since its inception as the codebase had a number of shortcomings. The Perl code generated both database queries and web pages by concatenating or printing portions of the text so that it came out as a distinct page. While this functioned reasonably well, it made the interface very difficult to modify, and interoperability with projects written in other languages was particularly difficult.
Faced with these challenges, the LedgerSMB team developed a new architecture which addresses these issues by adding support for templates in the user interface, and moving all database calls into stored procedures. Although closely resembling model-view-controller (MVC) in structure, it is not broken down in precisely the same way as other MVC implementations.[8]
The overall design considerations included a desire to ensure that multiple programming languages could be used cross-platform to access LedgerSMB logic and that security would be consistently enforced across these applications. Thus the LedgerSMB team envisioned a "one database, many applications" environment typical of PostgreSQL. The overall approach heavily leverages PostgreSQL roles (application users are database users, and are assigned roles). Access to the database logic for new code (added in 1.3 or later) goes through stored procedures which act like named queries. Permissions are sometimes granted on underlying relations or on the stored procedures. The stored procedures have semantic argument names, allowing for automatic mapping in of object properties. These are then exposed to the Perl code through fairly light-weight wrappers. User interface code wrapped around Template Toolkit, which is also used for generating PDF's via LaTeX, CSV files, Excel, Open Document etc. Workflow is handled through relatively light-weight Perl scripting.
See also
References
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ The New Architecture Approach