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.
Cheers, Dave Smithp.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 AR/AP/GL Invoices, sales orders, bills, payments Vendors Parts Customers Swing UI:Create new parts, new sales orders, new vendors, new customersList 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 thecontinual 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 ofthe mailing list but Sourceforge seems to be broken there at the moment.I'm looking forward to getting to know everyone here. Regards, 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. http://sourceforge.net/powerbar/db2/ _______________________________________________ Ledger-smb-devel mailing list ..hidden.. https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel---------------------------------------------------------------------- ---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. http://sourceforge.net/powerbar/db2/ _______________________________________________ Ledger-smb-devel mailing list ..hidden.. https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
Attachment:
smime.p7s
Description: S/MIME cryptographic signature