RELEASE NOTES
LedgerSMB 1.3

Latest Revision:  1.3.14, March 28, 2012.

1:  Welcome to LedgerSMB

LedgerSMB is an accounting and ERP program initially aimed at small to midsize
businesses.  Currently the financials and supply chain management modules are
fairly complete, while other modules such as project management exist in a
rudamentary form.  The initial features are identical to SQL-Ledger 2.6.17 from
which it was derived, but the feature set is starting to diverge rapidly.

1.1 System Requirements:

* Perl 5.8.
* Apache, IIS, or other web server that supports CGI.
* PostgreSQL 8.3 or higher.
* Any operating system that supports the above environment.
* The following CPAN modules:
	* Data::Dumper
	* Locale::Maketext
	* Locale::Maketext::Lexicon
	* MIME::Base64
	* Digest::MD5
	* HTML::Entities
	* DBI
	* DBD::Pg
	* Math::BigFloat
	* IO::File
	* Encode
	* Locale::Country
	* Locale::Language
	* Time::Local
	* Cwd
	* Config::Std
	* MIME::Lite
        * TemplateToolkit
	

2:  What's New in 1.3?

2.1:  Framework Changes
All new code has been moved to a new MVC-like framework.  This means that Perl,
SQL, HTML, CSS, and Javascript are also now largely in separate files.

The new code is also far more modular (and hence manageable) than the old code, 
though it is expected that further improvements will occur in the move from 1.3
to 1.4.

With this we hope to make LedgerSMB into a stable platform for more agile business 
application development.  With an ERP system it is often about the platform, not about
the out-of-the-box functionality.

2.2:  Security

Prior to 1.3, security was not pervasively enforced in any real way through the
database.  In 1.3, all user permissions are orchestrated via ROLES in the
underlying database, and permissions are rigorously enforced in this way.

Role-based security provides a far better approach to security than the previous methods
and since the permissions are now rigorously enforced, the overall security of the 
application is much better.

2.3:  New Features

LedgerSMB 1.3 now supports separation of duties for transaction entry and bank
reconciliation.  This means that permissions for data entry and posting of
transactions are now separate.  By default, this means that a transaction now is
entered first and then approved, and it only posts to the books when it is
approved.  Bank reconciliation works on a similar principle.

Bank reconciliation also has been entirely redesigned to provide multi-user-safe
workflows, and an ability to reasonably handle a much larger transaction load
than was previously possible.  This includes a new user interface design, and a
framework for building parsers for bank upload files.

The single payment interface has been fully redesigned to provide a number of 
additional features including the use of prepayments which are properly tracked.

The multiple payment interface has been redesigned to handle a much larger 
transaction load.

2.4:  Database Changes

The contact management and reconciliation portions of the database have been
fully redesigned to provide more flexibility for customization.

2.5:  Multicompany operations

LedgerSMB 1.3 continues to use multiple physical databases for separate companies as
did 1.2.  The major difference is that now users are database users, and since database
users are global to the database cluster, they can now be shared (or not) between 
companies.

Global users can be imported into new companies (though first and last name, 
and employee number need not be shared between the accounts).  Permissions can be 
assigned separately on different databases.

2.6:  Fixed Asset Handling

LedgerSMB 1.3 comes with a fixed asset module, meaning you can now define your assets,
depreciate them, and dispose of them either entirely or partially.

The fixed asset system is designed to be extensible.  Currently only time-based, 
straight-line depreciations are included.  However the system is designed to allow the 
creation of new depreciation methods including time-based and production-based methods.

3:  Known Issues

3.1:  Reposting Invoices

Reposting invoices is known to cause inaccuracies cost of goods sold and
inventory accounts.  This problem has been confirmed to affect SQL-Ledger 2.6.x 
as well and is caused by problems involving the de-allocation and trasaction
reversal routines.  It will be corrected (by removing the ability to truly
repost invoices) in an upcoming version as we continue to re-engineer the
application.

3.2:  Foreign exchange and payment reversals

The current design of foreign exchange handling means that if you reverse a
payment, the foreign exchange gains and losses will not be exactly reversed 
unless you are able to reverse on the same day.  If reversed on different days the 
gain/loss will be realized per the time when the payment was in effect and 
not reversed.

3.3:  Missing Annual Daily Straight Line Stored Procedure

Apparently the stored procedure for handling asset depreciation where the annual
daily straight line method is selected is missing.  More typically, the annual
monthly method is used.  For now, use that method instead.

The differences between these methods do not result in financial differences
over the course of a year.  Rather they affect how that annual depreciation is
spread out over the year.  In daily, the year is divided into equal parts per
day so we depreciate less in February than in August.  In monthly, we depreciate
1/12th of the annual depreciation amount each month, so February and August show
the same depreciation values.

4:  Differences between LedgerSMB and SQL-Ledger(TM)

4.1: Login name restrictions
Logins in SQL-Ledger can contain any printable characters.  In LedgerSMB these
are restricted to alphanumeric characters and the symbols ., @, and -.

4.2: Session handling
SQL-Ledger as of 2.6.17 uses session tokens for authentication.  These tokens
are based on the current timestamp and therefore insecure.  Furthermore, these
tokens are not tracked on the server, so one can easily forge credentials for
either the main application or the administrative interface.

LedgerSMB 1.3 dispenses with sessions altogether except for handling
discretionary locks (where they are stored in the db).  LedgerSMB uses http auth
instead (preferably wrapped with Javascript to hide the credentials dialog from
the end user).

As of SQL-Ledger 2.8, the discretionary locking system can become stale,
requiring manual cleaning.  In LedgerSMB 1.3, discretionary locks are tied to 
active login sessions and cleared automatically after a period of inactivity.

4.3: Template Changes

SQL-Ledger uses custom routines for processing templates.  We use
TemplateToolkit. As we move forward, the format of data sent to the templates
will change accordingly.

We have also dispensed with the old pagebreak functionality, moving instead to 
the longtable package in LaTeX.

5:  Roadmap
This project has a losely defined roadmap and a set of statements and 
objectives contained in the documentation manager and trackers of sourceforge.
In general, our development is focused around the following principles:

* LSMB as infrastructure:  LSMB should be accessible from other applications.

* Universal applicability:  LSMB should be usable by any business and should
always do the right thing in the background.  Businesses should never find that 
they have outgrown the software.

* Focus on Small to Midsize Businesses:  LSMB's core market will remain in the
small to midsize market.

The above being said, we have a set of targets for the next major release 
(1.4.0).  There is no guarantee we will reach these targets but we have them
anyway.  These include:

* Integrated budgetting module (included already)
* Rewritten reports
* Rewritten project/department handling to include nested departments (already included)
* Funds accounting (already included)
* Rewritten Sales Orders (may be deferred)
* Framework for web services
* A framework for implementing payroll solutions

6:  Get Involved
Contributors should start by joining the LedgerSMB users and devel lists.  Code
contributions at the moment must be committed by either project maintainer and
should be submitted either using the patches interface at Sourceforge or the
devel mailing lists.

Additionally, we can use help in QA, documentation, advocacy, and many other
places. 

SQL-Ledger is a registered trademark of DWS systems and is not affiliated with 
this project or its members in any way.
