[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Collaboration/merger with Ledger-SMB compatible Java project?

Hi Chris,

I have no problems with keeping up with your changes to the DB schema. I have been moving past first impressions as I have been coding for compatibility/trying to use SQL-Ledger and have reached the same conclusions you have. I see no reason to maintain compatibility with SQL-Ledger if there is an alternative Open Source project that works better. I'd like to gain the advantage of learning the corner cases you have hit and getting them into my code.

I foresee my Java code base going through a lot of changes. I'd very much like to ditch the broken architecture of the DB schema. I'm currently going through and trying to import transactions from QIF files and I keep hitting stuff that doesn't make a whole lot of sense (example: Accounts Payables invoices & purchase orders require that you have part numbers for everything you get from a supplier in your DB. You can use AP transactions for things that don't have part numbers but you can't use the same sales tax account in both AP transaction and AP invoices/purchase orders?!?). Unfortunately since everything was so undocumented you have to get in fairly deeply before you can start to understand how broken things are (and I am sure I do not understand how broken things are yet :-) )

If I can understand where you're going with the DB schema I can get my object level abstractions in line with that and then switch the DB backend over as the DB schema becomes available.

I think there's some major advantages for having a Java codebase as well as the Perl codebase available.

1) The heavy (Swing) client can be a lot more responsive than anything you're going to get without rewriting the whole front end as AJAX and sort of works now. For use on a secure network in a trusted environment it's pretty handy (it's talking directly to the DB so security is kind of sucky).

2) For some people, integration with Java is a lot easier than integrating with Perl or even XML through a web server.

3) It may be very worthwhile to look at things from the POV of a couple of different languages while driving the algorithms and DB schema.

As I said I'm happy to add the codebase to the Ledger-SMB project and maintain it there. I'm also happy to give my help on the Perl codebase where I can though that's more likely to be in the form of small patches rather than large swatches of code.

I'm not a DB or Accounting person and I wanted to be able to keep the reporting capabilities of SQL-Ledger as well as be able to verify that my code's ideas about how all the numbers add up match with something else's so I have not been mucking with the schema though I can see room for improvements in a lot of places. I'm really looking forward to Sourceforge fixing the mailing list archive so I can read the discussions that have taken place so far.

Dave Smith
p.s. I go by Dave. David is what my mom calls me and I'm hoping to break her of it but haven't had any luck yet. :-)

On May 7, 2007, at 1:54 PM, Chris Travers wrote:

Hi David;

We are always interested in collaboration and helping people
interoperate with our software.  Hopefully that will be getting easier
rather than harder.

Unfortunately, I think that your approach is likely to run into
difficulties with where we are headed for a couple of reasons:

1)  Contrary to first impressions the db design stinks and has many
deep flaws forcing us to re-engineer the entire db schema between now
and 2.0.  Josh Drake will probably say I am being generous ;-)

2)  Contrary to first impressions, the SQL-Ledger codebase doesn't
handle corner cases very well, and a large amount of the code (and
data storage logic) is deeply flawed.  We are likely to diverge quite
quickly from SQL-Ledger in the coming months and next few years.

On a positive note, we are taking the interop question very seriously.
 Interoperability will be supported on two different levels:

1) XML documents will be accepted to the web server via a RESTful interface.
2)  The main db logic will be exported via stored procedures.

If you are interested in helping us in this area, please feel free to
contribute both to a discussion and even perhaps to the code if you
are able.  However, I am fairly certain your approach will require
some minor tweaking for 1.2, and more major rewrites for later
versions.  Unfortunately, this is the price to pay for getting rid of
a broken architecture.

Best Wishes,
Chris Travers

On 5/6/07, David L. Smith-Uchida <..hidden..> wrote:
Hi all,

I have been working for a while on a Java implementation based on SQL-
Ledger.  It's not finished yet but it does do a lot of things.  I
wanted to see if there was some way that we could collaborate.

Originally, I was looking for an accounting system to replace our
mish-mash of Java code for the web store, Excel spreadsheets for
reporting and Quicken Home and Business (don't laugh) for the
ultimate recording, balancing, etc.  We do business in both the US
and Japan and multiple currency support and the ability to integrate
with our online shop (so that we don't have to manually enter all the
transactions again) were key features for me.  Being able to keep the
business from being dependent on a Windows system was also a plus.
When I looked around for systems that I could use and afford SQl-
Ledger looked like the best bet.  I installed it, did a few
transactions, it looked reasonable.  I started trying to figure out
how to integrate it with the web store and ran into the (lack) of
documentation.  I sent Dieter some money and got his manual and it
was quite unhelpful.  When I finally did figure out his solution for
getting SQL-Ledger to post an invoice automatically (if I remember
right it involves generating the equivalent of the HTML post that
comes back from the sales order form) I gagged.  I'm primarily a Java
hack, the database schema didn't look too bad and so I started
writing some classes that would let me smack sales orders/invoices
into the database.  One thing led to another and I found myself
painting the whole house and wound up with a pretty sizable portion
of SQL-Ledger implemented in Java and once I had that, well, heck,
making a Swing UI to the thing seemed pretty logical.

Since Dieter seemed to be pretty hostile to anyone asking questions
or doing anything with his system I was going to wait until it was
more finished before announcing it since it didn't look like I would
get any help/advice on the development.  But, now that Ledger-SMB is
going it looks more worthwhile to toss it out.

Here's what I have so far:

Core code:
        Compatible with SQL-Ledger 2.6 on Postgresql
        JDBC->Java object mapping
        Chart of accounts
        Invoices, sales orders, bills, payments

Swing UI:
Create new parts, new sales orders, new vendors, new customers
        List parts
        List sales orders
        Show chart of account
        List transactions in accounts (doesn't let you change/enter
transactions yet)

QIF file import:
        QIF file format Java implementation
        QIF file importation into SQL-Ledger 2.6 database

Most of this stuff works but is still in a pre-alpha state.  The
project got backburnered for a while so that I could finish and
release other, paying projects but the pain of the lack of an
accounting system has gotten strong enough to bring this back to the
top of my project list. I am currently in the process of
transitioning my company from Quicken Home & Business  over to this
so I expect the parts that we use to mature rapidly.  My plan has
been to release this as GPL'd code but I haven't done so yet, mainly
just out of lack of time to put GPL notices in the software and get
things checked into Sourceforge.  I created a Sourceforge project
(http://sourceforge.net/projects/ledgerdemain/) for it but have never
really had time to get it going as an Open Source project.

So, I wanted to see if there were any ways that we could help each
other.  If you would like to have a Java version of Ledger-SMB being
developed in parallel, I'd be happy to put the code into the Ledger-
SMB tree.  Or we could keep the projects separate but work to keep
the schemas in sync.  Since I've been reimplementing things and
transitioning from another accounting system I've been finding a lot
of idiosyncracies in the SQL-Ledger schema.  I'm not primarily an
accounting/database person and they seemed like things that Dieter
wouldn't answer or would take as criticisms.  I see that you have
ditched doubles in the database for Numerics which is a pretty big
step forward.  I would really like to fix the schema to handle
multiple currencies as true multiple currencies rather than the
continual conversions back to a base currency that seem to be going on.

If you're interested in seeing the code let me know and I will check
it in either to the Ledgerdemain project or the Ledger-SMB project as
you like.  If there's no interest in the Java code at the moment I
will probably hold off checking it in until I get it more working but
I hope that you'll let me ask some dumb questions and make
suggestions here. I've been trying to look through the archives of
the mailing list but Sourceforge seems to be broken there at the moment.

I'm looking forward to getting to know everyone here.

Dave Smith-Uchida
President & Head Geek
iGeek, Inc.
Tokyo, Japan

--------------------------------------------------------------------- ----
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
Ledger-smb-devel mailing list

---------------------------------------------------------------------- ---
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
Ledger-smb-devel mailing list

Attachment: smime.p7s
Description: S/MIME cryptographic signature