AqBanking
Hi guys, Gnucash is great - I think it's one of the killer apps for Linux. Anyway, I've been trying to get OFX support working in Ubuntu, and from what I can tell is that it was working (https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/5973, https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/192031) but now it's not (https://bugs.launchpad.net/hardy-backports/+bug/227732) and is waiting on a port to AqBanking 3. I've read the wiki (http://wiki.gnucash.org/wiki/AqBanking3_Porting) and I was wondering what the status of that is and what can I do to help. This would be my first gnucash project - I was hoping to start with something simple(like making the documentation valid-html) but I really want/need this feature, so it gets moved up the priority list for me. Thanks, Tad ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: Status
Geert Janssens [EMAIL PROTECTED] writes: On Wednesday 28 May 2008, Derek Atkins wrote: Geert Janssens [EMAIL PROTECTED] writes: On Tuesday 27 May 2008, you wrote: Gnucash has some bizaare flaws though: gnucash will actively stop you trying to give your customer a refund by refusing to post an invoice with a negative total. In the mean time we hack the XML by hand (!), but once invoice addition is automated, this problem will go away. Heh, I have been bitten by that one too ! I have chosen to keep credit notes (negative invoices) outside of the business tools for that reason. This works, but my credit notes have to do without the added consistency checks done by the business tools. Currently you can sort of do a credit note through the Process Payment mechanism, but it's not perfect. How does this work ? A link to some documentation is also ok... A Process Payment gives you that Negative number. What you would do is Process Payment to, say, your checking account. Then after the transaction gets posted you can go in and change it from Checking to Income. Make sure you only change the account, not the AMOUNT. Changing the amount will throw off all the numbers. Honestly, I wrote the business features for my own use, and indeed it's worked quite fine for me. The fact that other people can use them at all is just gravy. You're welcome to take the same approach and write the code you need to get your work done. This *IS* the devel list after all! Patches are always welcome. I am aware of that as you could read in my earlier mail in this topic. Alas for several reasons, I am currently unable to provide patches. And I said as well my comments were not meant to complain. Do you prefer I create a bug report for this issue ? I will gladly do so. Sorry, that response wasn't necessarily directed at you. On the other hand this *IS* the -devel list so there's a tacit assumption that questions are development-related and not how do I do X. Geert -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: Status
Daniel, My major concern here is that a year ago you were rallying for GDA and GdaQuery. Phil threw out a bunch of his work to target GDA-3 with GdaQuery. Now here we are, 6 or 9 months later, and the GDA team has moved on to GDA-4 already and are dropping GdaQuery, the very interface you were so adamant was the greatest thing since sliced bread. Phil has found a number of apparently major bugs in GDA-3 which the GDA team seems reluctant to fix, and GDA-4 isn't nearly as usable as GDA-3. So, what's Phil supposed to do? Work with GDA-3 with the known bugs, knowing that those bugs will never be fixed? Work with GDA-4 which is just broken and cant be tested and hope that the GDA team gets it working and makes a release early enough that GnuCash can actually use it? Or would it be more expedient to pick a technology that has a proven track record, proven stability, is NOT a moving target, and is already available in most distributions? Why did the GDA team decide to drop GdaQuery? And why did the move to GDA-4 break all the backends? That seems like a very bad idea to me. -derek Daniel Espinosa [EMAIL PROTECTED] writes: I've read all your other comments and is the same as before I try to re-write most of the GC's core, you don't want to lesen the others, the I don't plan to work on GC's as actualy is. If I can help Phil improving GDA it's Ok. If some others work to modify the GC's core to create a bussiness library and a GUI aplication I'll help. If the bussiness library is written to sue a DB, using GDA or not, I'll help. And please Derek, don't reply this if you want to insult or vociferous. 2008/5/26 Derek Atkins [EMAIL PROTECTED]: Can't you just use CREATE IF NOT EXIST ? Or is that not portable enough across various SQL implementations? Part of me is really thinking that GDA is more trouble than it's worth. I'm sure Esodan will vociferously argue against this, but perhaps we should drop GDA and choose something that actually works? -derek Quoting Phil Longstaff [EMAIL PROTECTED]: Graham Leggett wrote: Phil Longstaff wrote: Well, V4 basically works with the sqlite provider. There were a number of memory leaks and other small issues. However, there are a number of problems with the V4 mysql provider - it's not ready for use. I've decided to switch back to V3 for now. I'll continue to supply patches and if I have to, I'll pull it into the tree under 'lib'. Considering that V3 is not being actively developed, and that bugfixes to v3 won't be accepted, is it not safer to develop for V4, and get the upstream project to fix any problems involved? How far away is the V4 mysql provider? I don't know how far away the V4 provider is. They have a meta-information system which allows you to access info about the db structure (e.g. which tables exist) and the meta-information system has been redesigned for V4. It hasn't been implemented for mysql yet, so when gc starts, it tries to create all of the tables, even if they already exist. Note that it was a meta-information bug which was causing a problem in the gc-V3 code which was not accepted. The bug is that if you delete all db tables and then ask libgda to update the meta-information, it still thinks that the 2nd table exists (usually, billterms) so that it won't be created. This could happen when you are trying to save-as to a db, so billterms won't be saved, and lots of business objects will be screwed up. I see 3 possibilities: 1) Do libgda V3 maintenance ourselves by sending in patches and asking for them to be applied. For the particular bug I found, I didn't send in a patch, but asked for the bug to be fixed. Maybe they won't fix bugs but will apply patches. They would probably not create new tarballs, so anyone who wanted to use gc-libgda would need to check out the V3 trunk from svn and build from source. 2) Pull the libgda-V3 branch into the gc tree under lib. The GC team would maintain it. This has the advantage that it would not be an external dependency any longer, so anyone who wanted to try the gda backend could. The obvious disadvantage is a mess of code that nobody knows but that we need to maintain. Once libgda-V4 is further along, I can switch back to V4. 3) Change my decision and switch back to V4. I have basic operation with sqlite working. There is at least 1 regression (I can't create the index on the slots table) which would have performance implications. I don't know where the problem with index creation is. However, there are some improvements. The libgda-V4 statement structures can represent SQL operations which were not possible in V3, and which would improve performance. However, as I said above, the mysql provider is missing some major functionality. I don't know about postgresql. There are other issues with the whole gda backend which I need to work on and which are independent of which version of libgda is used: 1) some of
Re: GDA: Status
Daniel Espinosa [EMAIL PROTECTED] writes: I just want to point that if you use V4 you may will get inmediatly access to SQLite database, and after the API is stable enough the other database providers will be on the road. How long in the future is this down the road? I'm concerned about your statement: after the API is stable enough. That certainly does not send me warm fuzzies. :( I don't think is a good idea to have a copy of GDA in GnuCash. I agree completely. I really don't think we want a copy of GDA in GnuCash. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: Status
Derek Atkins wrote: A Process Payment gives you that Negative number. What you would do is Process Payment to, say, your checking account. Then after the transaction gets posted you can go in and change it from Checking to Income. Make sure you only change the account, not the AMOUNT. Changing the amount will throw off all the numbers. This doesn't solve the problem of the need to give your customer a credit note. This requirement exists in law, as the credit note contains tax refund details of VAT amounts on the invoice. The real fix it to take out the error check that prevents invoices being posted that have negative totals. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: Status
Quoting Graham Leggett [EMAIL PROTECTED]: Derek Atkins wrote: A Process Payment gives you that Negative number. What you would do is Process Payment to, say, your checking account. Then after the transaction gets posted you can go in and change it from Checking to Income. Make sure you only change the account, not the AMOUNT. Changing the amount will throw off all the numbers. This doesn't solve the problem of the need to give your customer a credit note. This requirement exists in law, as the credit note contains tax refund details of VAT amounts on the invoice. The real fix it to take out the error check that prevents invoices being posted that have negative totals. Unfortunately it's not that easy. That check is in there because the underlying code uses the Value + AccountType to determine if this is an Invoice or a Payment. All the linkage logic is based on the invariant that an Invoice is positive and a Payment is negative (obviously the numeric positive/negative is different for A/R and A/P, but let's not confuse the issue). That check is in place in order to maintain this invariant. Removing the check would cause the underlying logic to get confused and potentially not balance out properly. I suppose one COULD go through an re-work all the logic first to remove the value sign implies transaction type. Then you could remove the negative value check. Keep in mind that the printed note does not have to be a GnuCash Invoice. You just need a some printed note that you can send. At least that's what I'm reading from you, right? So that would imply that you COULD write a *new* Credit Note report that happens to work off of a different type of transaction than an invoice. Regards, Graham -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: Status
[[Sorry, forgot to reply to list]] I have created a feature request for credit notes in bugzilla: http://bugzilla.gnome.org/show_bug.cgi?id=535781 I have added most of the parts of this thread I considered relevant, together with some freewheeling on the implementation. Although I'll probably not be the one to implement it, in this way the information won't get lost. Geert On Friday 30 May 2008, Derek Atkins wrote: Quoting Graham Leggett [EMAIL PROTECTED]: Derek Atkins wrote: A Process Payment gives you that Negative number. What you would do is Process Payment to, say, your checking account. Then after the transaction gets posted you can go in and change it from Checking to Income. Make sure you only change the account, not the AMOUNT. Changing the amount will throw off all the numbers. This doesn't solve the problem of the need to give your customer a credit note. This requirement exists in law, as the credit note contains tax refund details of VAT amounts on the invoice. The real fix it to take out the error check that prevents invoices being posted that have negative totals. Unfortunately it's not that easy. That check is in there because the underlying code uses the Value + AccountType to determine if this is an Invoice or a Payment. All the linkage logic is based on the invariant that an Invoice is positive and a Payment is negative (obviously the numeric positive/negative is different for A/R and A/P, but let's not confuse the issue). That check is in place in order to maintain this invariant. Removing the check would cause the underlying logic to get confused and potentially not balance out properly. I suppose one COULD go through an re-work all the logic first to remove the value sign implies transaction type. Then you could remove the negative value check. Keep in mind that the printed note does not have to be a GnuCash Invoice. You just need a some printed note that you can send. At least that's what I'm reading from you, right? So that would imply that you COULD write a *new* Credit Note report that happens to work off of a different type of transaction than an invoice. Regards, Graham -derek ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: Status
Getting back to the gda stuff, the key question seems to be: Can support for mysql and postgresql wait? If so, then V4 seems like a good choice to me, since Phil has said (I think) that it works well enough with sqlite for our purposes. Support for the other databases can be added as V4 evolves. I got the impression from the various updates over past weeks that V3 wasn't satisfactory for even ONE of sqlite, mysql, or postgresql -- unless we fork it off and customize it. My $0.02, but since I'm not contributing to this part of GnuCash, feel free to ignore it. Cheers, Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
