LedgerSMB is a libre software double entry accounting and Enterprise Resource Planning (ERP) system, focussed on functionality required by small (self-employment) and medium size businesses. However, companies with millions of journal lines should also feel supported.[2] Accounting data is stored in a free to use database server (PostgreSQL) and a standard web browser can be used as its user interface. The software is suited for hosting locally as well as on various public cloud providers. Commercial support can be obtained from several providers.[3]
 LedgerSMB login screen | |
| Developer(s) | LedgerSMB |
|---|---|
| Initial release | September 6, 2006 |
| Stable release | 1.11.18
/ October 13, 2024 |
| Repository | github |
| Written in | Perl, PL/pgSQL, JavaScript |
| Operating system | Any Unix-like, Mac OS, Windows, Android |
| Platform | Cross-platform |
| Available in | English, Norwegian, Dutch, German, Hungarian, Estonian, Malay, Danish, Russian, ... |
| Type | Accounting, ERP, CRM |
| License | GPL-2.0-or-later[1] |
| Website | ledgersmb.org |
LedgerSMB is distributed under the terms of the GPL-2.0-or-later license.
Features
editLedgerSMB features
- a full general ledger, with multi-currency support.
- accounts receivable & payable, with outstanding & aging reports.
- project accounting and other flexible accounting dimensions.
- financial reports, with multi-period comparisons:
- Income statement (Profit & Loss report)
- Balance sheet
- Trial balance.
- quotations and order management.
- time tracking.
- invoicing capabilities (mailing, printing), with invoices based on:
- orders (which in turn can be based on quotations)
- shipments
- time cards.
- inventory tracking, with activity reports.
- fixed assets.
- full separation of duties for invoices and GL transactions.
LedgerSMB supports multiple currencies, multiple sales or VAT tax rates and per-user language and locale (number formatting) settings. It also supports per-customer language settings, so invoices can be translated into various languages when printed, and per-language invoice templates are also an option.
Releases
edit1.10.0 was released on 2022-10-08 with a wide variety of improvements and fixes. This release saw many small user-visible changes. The larger changes were on the technical side, moving parts of the UI to Vue3 and introducing web services to back the Vue3-based UI.
1.9.0 (End of Life) was released on 2021-09-24 with a wide variety of improvements and fixes, including repair of the ability to send out AR/AP aging reports by e-mail (which regressed in 1.3.42). Where prior releases had a central theme or special focus, this release is more a general cleanup release that touches all parts of the code base.
1.8.0 (End of Life) was released on 2020-09-04 with a wide variety of improvements and fixes; to that extent, this release is different than the thematic releases between 1.5 and 1.7 which sought to improve specific areas of functionality. Notable changes in this release include better support for container images by allowing logos (for inclusion in printed documents) to be stored in the database instead of on disc, allowing the use of standard containers as well as the upgrade of payments to be first order citizens. Where payment data used to be derived from transaction data, this release stores all payments as separate data items specifically, considerably changing reconciliation experience.
1.7.0 (End of Life) was released on 2019-10-04 with improved support for transactions in foreign currencies, much code cleanup and yet more tests again. With the 1.7.0 release, the project continues the trend to shorten the cycle between minor (.0) releases.
1.6.0 (End of Life) was released on 2018-06-10 with a change log focused on stability and a code base to build a future on.
1.5.0 (End of Life) was released on 2016-12-24 with a change log focused on stability and user experience.
1.4.0 (End of Life) was released on 2014-09-15 with another sizeable change log.
The 1.3.0 (End of Life) release came out on 2011-10-11, with a sizeable change log, generally focusing on performance, separation of duties and fixing the (design) issues in 1.2.
The 1.2.0 (End of Life) release (announced on 2007-04-06) 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 compared the problems to those of Apache 2.0,[4] where changes in architecture have caused problematic releases. 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.
The 1.1.0 (End of Life) 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[5]) and the events leading up to it, are described in the History section.
1.5+ Developments
editAs of 1.5, development has taken a direction to move to a heavier (in-browser) client with access to web services in the backend. To that extent, the 1.5 UI has been realized as a single-page web application. The result is a (much) more responsive experience which looks a lot more modern and builds a foundation for much more fundamental separation of front and back end. Massive efforts have gone into developing quality assurance measures during the development 1.5 cycle and continue to be a focus going forward.
1.3+ Developments
editPrior to 1.3, there were numerous challenges in the code base, such as the fact that the Perl code generated both database queries and web pages by using a combination of string-concatenation and string-printing page snippets to compose the resulting HTML. While this functioned reasonably well, it made the interface very difficult to modify, and interoperability with projects written in other languages particularly difficult. Additionally, most state was kept in global variables which were modified all over the place, leading to unexpected results on nearly every code modification.
Faced with these challenges, the LedgerSMB team developed a new architecture that 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.[6]
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 SQL. 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 that 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.
History
editThe project began as a fork of SQL-Ledger when Chris Travers, dissatisfied with the handling of security bugs in SQL-Ledger, joined forces with Christopher Murtagh to produce a fix for CVE-2006-4244.[7] This bug was apparently reported to the SQL-Ledger author, Dieter Simader, several months prior[8] to the Chris' working on a patch. The initial release of LedgerSMB, along with full disclosure of the bug on the main mailing list,[9] strained relations between SQL-Ledger supporters and the members of the nascent LedgerSMB project.
See also
edit
References
edit- ^ "LedgerSMB/COPYRIGHT". GitHub. Retrieved 2021-07-01.
- ^ "Open Source ERP: Accounting, invoicing and more | LedgerSMB".
- ^ "Commercial support | LedgerSMB".
- ^ Travers, Chris (May 31, 2007). "web-based accounting". Retrieved 2008-01-25.
- ^ "Sourceforge.net - LedgerSMB files". Retrieved 2011-10-03.
- ^ The New Architecture Approach
- ^ "The Full Disclosure of CVE-2006-4244". Retrieved 2007-07-08.
- ^ "Tony Fraser's mention of previously reporting the bug". Retrieved 2007-07-08.
- ^ "Full disclosure thread on the SQL-Ledger mailing list (some posts may be hidden)". Retrieved 2007-07-08.