Update: Ouch, on the vaporware remarks below. My interest has not waned, but divorce and single-parenthood has put my bookkeeping system on a backburner. (Oct. 2007)
Don't get a Perl system without use strict;
just don't.
Update: Maintenance and extensibility are the reasons.
I chose the last system based on:
-
Hundred-plus longtime similiar-to-me user base.
This is a proof of viability.
-
On supportable, affordable, scalable platform, meant *nix here, then.
This has saved much in OS support, admin and license costs.
-
Required features. Don't over spec up front, just what
accounting issues have to be handled.
-
Ease of customization. Cause you'll need
specialisations to make everyone happy.
-
Accountant okays reports. Given item one this should
be easy.
Though I have some complaints with my
choice, I'd do it
again the same way.
(People usually hate change so expect aggravation.)
One large problem I have with this system is convincing
the accountant or the bookkeepers that some function
can be written in. Simple UI interfaces may help create
this rather nice problem.
Warning! Warning! Vaporware alert!
I am working on a beast like you request. The core of it, aside from
the UI is getting close to releasable. A few weeks work equals
several months lag, though.
After General Ledger and General Journal come together,
A/R, A/P, Inventory should benefit from much reuse.
Purchasing, Receiving, and Sales will follow thereafter.
I have vague intentions on Payroll as no one seems to be interested
unless you provide annual tax updates.
No current plans for Depreciation, Job Costing, Bill of
Materials or Fixed Assets journals.
There is SQLedger and GNU has a couple of accounting (GNU-Cash?)
products. Those all seem oriented toward one or two person offices.
Don't believe me on this I have not been following those
projects.
SQ-Ledger seems to have a solid following, it runs through a
browser interface.
My project is being targeted at businesses like wholesalers,
auto-parts stores, lumber-yards, etc. Businesses with large
inventories with moderate transaction rates. It should scale up
pretty well. With all the journals it would suit cities.
When I have the GL ledger and journal okay, I'll release.
As everything else can pretty much be a report against
the data base.
At present I'm only planning on supporting Average Costing.
I am willing to hear, or be aimed at literature, about
tracking batches or individual items; and fifo, lifo, etc.
costing. Now I might consider factoring such in, later
I'll probably want to push such issues into the distant future.
I'm using Linux, Perl, Tk, DBI, and Postgres. My code is
fairly portable but *nix-centric. Without bribes I won't
be dealing with other platforms. Perhaps other UIs, though.
When you see any practical questions from me it will be
to support this bookkeeping system.
