[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Collaboration/merger with Ledger-SMB compatible Java project?
- Subject: Re: Collaboration/merger with Ledger-SMB compatible Java project?
- From: "Chris Travers" <..hidden..>
- Date: Sun, 6 May 2007 22:59:33 -0700
For what it's worth, I have been trying to push the idea that by 2.0,
it should be possible to have alternate implementations written in
arbitrary languages. There is no reason why a Java implementation
could not exist. Again, the entire data model will be entirely
contained in the db, so the amount of code in your project may be able
to be reduced a bit. Personally, I am not much of a Java fan for this
sort of work, but I also believe in letting people provide whatever
the market wants (i.e. whatever your customers/users/you want, we
should help to support).
We are also planning on moving in the direction of AJAX at least as an
option. Again, the current code structure isn't even close to
supporting this but we can get closer in the next few releases. We
are also trying to keep everything pretty standards-compliant so the
templates could even be shared between implementations.
As for corner cases, hang out on the list for a while and you will see
them. Among the obvious ones:
1) No way to track prepayments against orders (fundamental database
2) Order to invoice conversion is not transactional (i.e. if you
don't complete the process, the order is closed anyway). I looked at
trying to fix this at one point and concluded that it was best to wait
until we could actually tackle the real issues behind shipping and
order management (which are not sanely handled).
On 5/6/07, David L. Smith-Uchida <..hidden..> wrote:
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
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.
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
> 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
>> 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
>> 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
>> 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
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