The general approach is to migrate invoices first, creating them as they exist in the current accounting solution. Then, differences with the intended balance can be calculated and the remainder posted at-once. For more comprehensive explanation see How do I migrate my existing books to LedgerSMB?
Short answer: Due to differences in the database schema in relation to storing foreign currency transactions.
Long answer: The database schema before 1.7 required 2 database rows in the acc_trans table to store functional currency and foreign currency amounts. As of 1.7, the schema stores these two amounts - which relate to the same journal line - into one database row. When migrating data from the old schema to the new one, the migration routine tries hard to identify pairs of rows which can be combined into a single row in the new schema.
Upgrading tarball installations
There are two steps to upgrading a LedgerSMB 1.5.x installation to 1.5.y (x smaller than y):
- Upgrade the software
- Upgrade the company database
The last step has to be executed for each company database that's set up.
Note that all the steps below are prefixed with the 'sudo' command, but these can be executed as 'root' directly as well.
Upgrading the software
This is by far the easiest part. These are the steps to go through, assuming an installation from tarball:
Before starting to update to 1.5, the following are differences to be aware of between 1.4 and 1.5:
- Additional data constraints
- PSGI / Apache configuration
- Printed document templates (e.g. invoice templates)
- Database schema maintenance
See below for explanations of each of these differences.
Important note: before trying to migrate your database to a new version of LedgerSMB, create a backup of the database!
The table below lists the compatibility of LedgerSMB versions with Perl versions. Products for which support has ceased due to End-of-Life date being reached are not listed and should not be used.
Useful Starman commands.
Using the perl based Starman webserver is the easiest way to run LedgerSMB locally (and quite possibly for production use as well).
## At the terminal, and from your LedgerSMB directory:
### Start Starman
Default port is 5000.
starman -l :8080 tools/starman.psgi
Start with 8080 specified as the port.
Note: some documentation specifies the switch
It has been sugggested that this may give performance advantages in a production environment but isn't recommended while developing.
The manpage has more to say on this.
First of all, you need to backup all your company databases followed by an upgrade of your PostgreSQL installation. There are plenty of places on the web to explain how to do that. The high-level process is to install the two versions in parallel and run the pg_upgradecluster command.
When the technical upgrade has succeeded, however, you're not ready to see the performance improvements promised by the 8.4+ versions of PostgreSQL with respect to the menu-generation. This is because the database doesn't automatically use the new 8.4+ code definitions.
In general: neither. The advice is to have the full source tree in /opt/ledgersmb/<version>.
The default configuration limits access to the /ledgersmb/login.pl page to connections from localhost (127.0.0.1) only for maximum security.
If you want to allow connections from other locations, it's highly advisable to use encrypted (VPN) connections to access your ledger in order to maintain good security.
Q: This particular merchant runs Windows. I don't think they have a pole display, though I can check. Ideally, it would be great to accommodate, with or without pole display. If it runs better on Linux, going forward I would propose Linux workstations for new merchants.
Ok. Let's first explain what the problems we have to solve are, then discuss the solutions that are bundled.