RELEASE NOTES
LedgerSMB 1.3

Latest Revision:  1.3.46, October 2014

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.
        * As of 1.3.24, FCGI is experimentally supported as is Plack-Starlet
        * As of 1.3.36, an nginx configuration ships 
* 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.

Note that in 1.3.x, AR/AP recurring transactions are saved rather than posted, 
assuming that separation of duties is not disabled.  These are then approved or 
deleted through the normal transaction approval workflows.

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.

2.7:  Tax Changes

As of LedgerSMB 1.3.16, a few changes were made to the Sales Tax API so that it 
is easier to implement local tax rules.  This includes a minimum tax value, 
exposed through  the user interface, and a maximum value which is not yet
exposed.  The handling of these are module-specific.  The Simple tax module 
treats these as operating on the subtotal of the invoice.

AS OF LEDGERSMB 1.3.40 A SALES TAX CALCULATION BUG WAS CORRECTED.  Prior to 
this revision, line items were rounded off unintentionally to a low precision value before sales tax was calculated.  For most users this might alter the amount on an invoice by only a few cents per invoice.   If a significant bias exists, 
since it may be a few cents per line item, this can add up. This issue affected 
all versions of LedgerSMB 1.3 through 1.3.39, and was first corrected in 1.3.40.


2.8:  New CSS hooks

As of 1.3.21, it is now possible to customize the look and feel of transaction,
order, and part screens based on the status of the object.  Screens are enclosed
in a div with an id of statusdiv and a class of either "new" (if no ID is
present), "saved" (if ID is present but not a posted financial transaction) and
"posted (if a posted financial transaction).  This can be used to give feedback
to the user so that it is immediately clear what the status of a given screen
is.  Future versions will include such hooks in at least the ledgersmb.css
provided.

2.9:  Partial Support for Code Caching

As of 1.3.24, LedgerSMB now supports caching of expensive dependencies in some
environments so that response time is minimized.  Currently tested environments
include Plack-based FCGI and the Perl web server Starlet.  Mod-perl might be
possible to support at some point.

The current approach is to daemonize the script, pre-load what can be preloaded,
and then fork/execute/return so that the Perl interpreter does not have to worry
about state issues and variable scopes in running scripts from the inherited 
codebase.  This can increase speed greatly but it is still seen as somewhat
experimental.  Code caching generally poses the possibility of some issues, and
these are magnified in those areas of the code we have not replaced from
SQL-Ledger.

If you run into issues here, please file bug reports.  If there are
showstoppers, you can always run the program via CGI.  Please see our addons
repository or ask on the email lists if you'd like to run this.  The handler
scripts are not includede out of the box but will likely be included in future
versions.

2.9:  Removed support for defaults on ar/ap transaction screen

In SQL-Ledger and LedgerSMB before 1.3.36, the AR and AP transaction screen 
would default the first line based on the first line of a previous AR/AP 
transaction for the same customer.  This never worked too well, and was 
certainly not reliable enough to be relied upon. 

One significant problem is that there is no natural ordering to transaction 
lines so in practice this meant picking a more-or-less random line from the last
transaction and using it as the default for the first line only.   Over time 
other related bugs surfaced.  In the end we decided to remove this "feature"
and to simply call it a bug.  In 1.4, it will be replaced with template 
transactions, currently supported as an add-on.

2.10:  AR/AP Reports Now Default to Details

The AR/AP reports now default to details instead of summary.  This was in 
response to user feedback and was first made in 1.3.38

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:  Invoice unit column throws error when too long.

The unit column in the invoice is limited to 5 characters and will throw an SQl error when it is too long.  The error looks like:

UPDATE invoice
SET trans_id = ?,
parts_id = ?,
description = ?,
qty = ?,
sellprice = ?,
fxsellprice = ?,
discount = ?,
allocated = ?,
unit = ?,
deliverydate = ?,
project_id = ?,
serialnumber = ?,
precision = ?,
notes = ?
WHERE id = ?
ERROR: value too long for type character varying(5)

Due to compatibility issues, a fix for this has been included for 1.4, but is
not planned to be backported for 1.3.

If you need change the maximum length, you can:

ALTER TABLE invoice SET unit TYPE varchar([length]);

3.4: Odd Semantics of Outstanding Summary

In LedgerSMB 1.3, the outstanding report shows the total number of invoices 
received and paid in a given time period.  In 1.4 this will be changing so that only invoices that are outstanding are counted.  The change however is quite 
complex and poses testability issues in 1.3 so we decided to leave the behavior ias it is for now.

3.5: Reconciliation and Adjustments

If you enter adjustments for reconciliation you cannot simply add them with the
same source, etc. on the transaction screen.  You must go through payment,
payment reversal, or gl workflows.  Failure to do so may cause the payment to
fail to be recognized by existing in-process reconciliation workflows.  If this
happens, start the bank reconciliation over and the payment will be recognized.

3.6:  Assemblies and COGS

Assemblies and COGS have a couple of important shortcomings in 1.3 and before 
which are fixed in 1.4.  The two important cases which can cause COGS to be misrecorded are:

1.  BOM changes between when assembly is stocked and when assembly is sold
2.  Selling assembly before all parts necessary to manufacture are in stock

In both these cases, COGS can be misrecorded.  This is a problem going back to 
the SQL-Ledger codebase.  Those who are doing significant work with assemblies 
should move to 1.4 as soon as possible.

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.
