General Ledger/Accounting Libraries

[Andreas Pauley]

Hi All,

Our company is currently evaluating Python as a language for writing
financial/accounting type software (among others).

What libraries or packages are available in this domain for use?
I've had a look at Quantlib, but it doesn't seem like exactly the type of
library we're interested in.
The programmers are looking for something that can be used as a General
Ledger, or be used to implement a General Ledger.
They're also looking for libraries that can help in the calculation of
various types of interest rates, for example.

On Sourceforge there's a PHP-based application called "Open Accounting"
with all the relevant buzzwords in our domain. Something similar in Python
would be of great help:
"""
An easy-to-use, web-based Accounting and Inventory system that features
Sales, Purchasing, Manufaturing, General Ledger, Accounts Receivable,
Accounts Payable. Additionally, has multi-currency, advanced tax
manipulation and multi-language support
"""

Thanks,
Andreas

 

[Aahz]

Our company is currently evaluating Python as a language for writing
financial/accounting type software (among others).

What libraries or packages are available in this domain for use?

The most important library is the new Decimal package, which hasn't been
released for production yet. You could start by using FixedPoint instead
until Python 2.4. Unfortunately, neither includes support for some of
the more complicated calculations you want to do; the Python community
will welcome your assistance on this (there are other people who also
want to use Python for financial calculations, and Decimal is the first
step).

On Sourceforge there's a PHP-based application called "Open Accounting"
with all the relevant buzzwords in our domain. Something similar in Python
would be of great help:
"""
An easy-to-use, web-based Accounting and Inventory system that features
Sales, Purchasing, Manufaturing, General Ledger, Accounts Receivable,
Accounts Payable. Additionally, has multi-currency, advanced tax
manipulation and multi-language support
"""

They probably use binary floating point, which means that it doesn't
work. :-(

 

[Daniel Dittmar]

Our company is currently evaluating Python as a language for writing
financial/accounting type software (among others).

What libraries or packages are available in this domain for use?

There's GNU Enterprise (http://www.gnuenterprise.org/).

Daniel

 

[Pedro Lima]

You may also want to check this project: custom.sourceforge.net

 

[Frank Millman]

Hi All,

Our company is currently evaluating Python as a language for writing
financial/accounting type software (among others).

What libraries or packages are available in this domain for use?

Hi Andreas

I was in two minds as to whether I should respond to this. I am
working on something that may provide what you are looking for, but it
is still under development. I don't want to waste your time with
vapourware, but if I explain what my ideas are and how far I have got,
you can decide whether to take it any further.

I am developing a generalised accounting/business package using
Python. For the GUI I use wxPython. For the database, I use PostgreSQL
with pyPgSQL on Unix/Linux, and MS SQL Server with Win32/odbc on
Windows.

It is too big to describe in a few lines, but I will list some of my
design goals, and discuss how close I am to achieving them.

Data integrity -

I am an accountant first and a programmer second, so I have this area
well covered. Some programmers are reliant upon input from an
accountant/business analyst, and problems can arise when there is a
communication gap. I wear both hats, so I just *know* what is
required. In 20+ years of writing accounting software, my systems have
received a number of criticisms, but going out of balance is not one
of them.

Performance -

Using a database cursor and a wxPython virtual grid, I can select and
display 10 000 rows out of a table of 260 000 rows in less than a
second. I can scroll up and down the table with no perceptible delay.
I can look for a particular row based on a search string, and it finds
the row almost instantaneously. This is on a 266mhz Pentium II laptop
with 128mb ram and Windows 2000. On my linux box with a 1.7ghz
Celeron, it is even faster. I am reasonably confident that I can
handle large volumes of data without a problem.

Access control -

Full access control is built in from the ground up. Users must log in,
and are authenticated. Each user is assigned to one or more groups,
and each group can have read/write privileges defined on every column
in every table in the database. Full audit trails will be available
(not done yet, but on the to-do list). Obviously I cannot prevent
unauthorised access external to my software, so it is up to the system
adminstrator to control access to the database itself and to the
python programs.

Flexibility -

I used to be a fan of customisation, but with hindsight I believe that
in the long run the benefits are illusory. I am therefore building in
a lot of flexibility in such things as structure of g/l code and
product code, ability to add your own business logic to database
tables and columns, parameters to select things such as ageing
methods, etc. Full source code will be available, so anyone can
customise the programs if they want to, but I will be very open to
requests to fold such customisations back into the main body of code,
possibly selectable by a parameter.

Support -

The source code will be released under an Open Source license. Support
will be available at a modest monthly charge (to be determined).
Although I will have a few sites that I will support directly, my
intention/hope is to develop a network of dealers/consultants, who
will install and maintain the software at end-user sites and provide
first-line support. I in turn will provide backup and support to them,
in addition to continuing ongoing development of the software.

Current state of software -

I am getting close to setting up my first few live installations - say
1 to 2 months. The initial release will include General Ledger, Sales,
Purchasing, Inventory, Accounts Receivable, and Accounts Payable. It
will be multi-company, multi-branch, and multi-currency.

Where to from here -

It all depends upon the success of my business model (see Support
above). If I can get a few dealers to get a few installations, and
start to generate a revenue stream from support fees, I will plough
this back into providing a full support and development
infrastructure, employing staff as needed. My wish-list for ongoing
development of the software is endless, but includes things such as
full context-sensitive help, multi-language support, image support,
web front end, etc. There will also no doubt be many requests for
additional functionality. This can turn into a virtuous circle - the
more I build in, the more people will want to use it, which will
increase the revenue stream, which I can plough back into development,
etc.

However, I have to be realistic, which means I must get this past the
vapourware stage and get a few live installations. My inclination is
to not even release the source code until this has settled down, as
there are bound to be teething problems. I estimate that this will
take up to 3 months. I will me more than happy to discuss
requirements, concepts etc in the meantime.

Any comments will be very welcome.

Frank Millman

 

[Frank Millman]

The most important library is the new Decimal package, which hasn't been
released for production yet. You could start by using FixedPoint instead
until Python 2.4. Unfortunately, neither includes support for some of
the more complicated calculations you want to do; the Python community
will welcome your assistance on this (there are other people who also
want to use Python for financial calculations, and Decimal is the first
step).

I have found that doing accurate decimal arithmetic is fiddly, but not
impossible. This is how I do it in my system.

In my database, I declare the various numeric columns with the maximum
scale that I think will be necessary. Monetary columns have a scale of
2, quantity columns have a scale of 6, etc. When I read the data in, I
scale it up so that I store it internally as an integer. For data
input/display purposes, I have a user-defined scale for each column,
which can either be absolute (eg all quantities are shown to 2
decimals) or parameter (eg get the scale for each product from the
product table, so they can vary). When I write back to the database, I
scale down from the internal integer to the scale defined in the
database.

It does lead to some awkward code. For example, to calculate a value
from a quantity and a price, I have to say

value = int(round(price * value / 1000000.0))

This requires you to know what scale is used for each column, so
mistakes are easy to make. As you say, the Decimal package, when it is
released, will make life much easier.

Frank Millman

 

[Nicolas Chauvat]

Our company is currently evaluating Python as a language for writing

financial/accounting type software (among others).

What libraries or packages are available in this domain for use?

PyCompta works for our (small) company :

An accounting tool that reads entries written in a set of XML files and
computes all reports including income statements and balance sheet.

An accounting tool that reads "double entries" written in a set of XML
files and computes the journal, general ledger, work sheet, income
statements and balance sheet. Accounting records are outputed as XML
files that can be rendered to HTML, XSL:FO and PDF.

http://www.logilab.org/projects/pycompta/