RELEASE NOTES
LedgerSMB 1.3

Latest Revision:  1.3.3, October 28th.

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

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.

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.

3:  Known Issues
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.

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 no defined roadmap but rather 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 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
* Rewritten AR/AP/GL handling
* Rewritten reports
* Rewritten invoices and orders

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.
