[GNC-dev] UK VAT and "Making Tax Difficult"
Hi all, In the archives there have been discussions over coming up with a way to do the UK’s MTD (making tax digital). The key missing bit is the bridge part - the piece that logs into HMRC and passes the JSON message. Does an open source bridge exist? If an open source bridge does not exist I am going to write one, but if I didn’t have to that would be great. Regards, Graham — ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Gnucash.org DNSSec expired March 14th.
On 14 Apr 2021, at 10:08, Linas Vepstas wrote: > I'm deeply unhappy with dnssec; it's the worst technology I've > ever had the displeasure of using. I'm finding it quite difficult > to avoid writing a tirade. More and more DNS providers are doing hosted DNSSEC - the full you give us the TLSA record you want, we do the rest kind of service. I use https://www.domaindiscount24.com/en, but ymmv. Regards, Graham — ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] [GNC] UK specific: MTD - Making Tax Digital
On 14 Jan 2021, at 16:13, Mike Evans wrote: >>> Is anyone interest in having a MTD bridge for GnuCash for VAT submissions? >>> I >>> have developed a bridge and would be happy to integrate it with GnuCash if >>> there is still any interest. +1 and much appreciated - happy to test it out too. Regards, Graham — ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[GNC-dev] Gnucash and the UK's "Making Tax Digital" initiative
Hi all, I just learned with some shock that the UK wants to force SMEs to submit VAT returns “via external software packages” by 1 April 2019, and presents a list of some 150 packages to choose from. If you’re lucky enough to already be using one of those packages, great. If you’re not, you’re facing some disruption. Gnucash is not on the list (that I could see). We are not in a position to re-engineer our accounts, but we are in a position to submit patches to Gnucash. This email is exploratory - is anyone on the gnucash dev list interested in the UK “Making Tax Digital” initiative, with the aim of getting Gnucash “on the list” of approved software? Has anyone done any work in this area? I am still looking for concrete information on the protocols being used, if anyone has information on that it would be useful too. Regards, Graham — ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: cmd line: import of transactions and invoice data
On 01 Jan 2014, at 7:25 PM, John Ralls jra...@ceridwen.us wrote: Gnucash *probably* writes things to the XML file in the same order that they were read in just because we use linked lists for just about everything internally, but there's no guarantee of that and it might well create excessive churn in a version control system. But we already rename the loaded XML file and write out a new one, so you can easily back up a bit. Gnucash does write things to the XML file in the same order that they were read in, we use this property along with a subversion repository to share the accounts between various people. Regards, Graham -- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Announcement: GnuCash 2.6.0 Released
On 30 Dec 2013, at 5:22 PM, John Ralls jra...@ceridwen.us wrote: The Gnucash 2.6.0 MacOSX package can be downloaded from Sourceforge as well. Has anyone successfully got the MacOSX binary to start up? I download it, I copy it to applications, I double click on Gnucash, the splash screen appears for a brief fraction of a second, and then the application exists, logging the following: 2013/12/31 8:42:25,690 AM com.apple.launchd.peruser.501[285]: ([0x0-0x81e21da].org.gnucash.Gnucash[30105]) Exited with code: 1 Before I go off on another debugging mission, I was hoping to confirm whether anyone had tested this before release and whether this is expected to work at all. Regards, Graham -- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Announcement: GnuCash 2.6.0 Released
On 31 Dec 2013, at 8:46 AM, Graham Leggett minf...@sharp.fm wrote: The Gnucash 2.6.0 MacOSX package can be downloaded from Sourceforge as well. Has anyone successfully got the MacOSX binary to start up? I download it, I copy it to applications, I double click on Gnucash, the splash screen appears for a brief fraction of a second, and then the application exists, logging the following: 2013/12/31 8:42:25,690 AM com.apple.launchd.peruser.501[285]: ([0x0-0x81e21da].org.gnucash.Gnucash[30105]) Exited with code: 1 More information, attempting to run gnucash from the command line fails as follows: Little-Net:Testing minfrin$ Gnucash.app/Contents/MacOS/Gnucash Application Path /Applications/Testing/Gnucash.app/Contents/MacOS/Gnucash-bin (process:30185): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. Backtrace: In /Applications/Testing/Gnucash.app/Contents/Resources/share/gnucash/guile-modules/gnucash/main.scm: 76: 0* [setlocale 0 ] /Applications/Testing/Gnucash.app/Contents/Resources/share/gnucash/guile-modules/gnucash/main.scm:76:1: In procedure setlocale in expression (setlocale LC_ALL ): /Applications/Testing/Gnucash.app/Contents/Resources/share/gnucash/guile-modules/gnucash/main.scm:76:1: Invalid argument Attempting to run the Gnucash-bin binary directly causes the binary to crash as follows: Little-Net:Testing minfrin$ Gnucash.app/Contents/MacOS/Gnucash-bin Application Path /Applications/Testing/Gnucash.app/Contents/MacOS/Gnucash-bin (process:30195): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. Trace/BPT trap: 5 The crash reporter information then pops up, saying the following: Process: Gnucash-bin [30195] Path:/Applications/Testing/Gnucash.app/Contents/MacOS/Gnucash-bin Identifier: org.gnucash.Gnucash Version: 2.6.0 (2.6.0) Code Type: X86 (Native) Parent Process: bash [369] User ID: 501 Date/Time: 2013-12-31 08:49:47.750 +0200 OS Version: Mac OS X 10.8.5 (12F45) Report Version: 10 Interval Since Last Report: 39764 sec Crashes Since Last Report: 2 Per-App Interval Since Last Report: 12 sec Per-App Crashes Since Last Report: 2 Anonymous UUID: 74E6C23D-9424-2DD7-F90F-B15CDEFE9415 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0002, 0x Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libglib-2.0.0.dylib 0x02caf593 g_logv + 755 1 libglib-2.0.0.dylib 0x02caf749 g_log + 41 2 libgio-2.0.0.dylib 0x029aaee8 g_settings_set_property + 344 3 libgobject-2.0.0.dylib 0x02c34a99 g_object_new_internal + 1641 4 libgobject-2.0.0.dylib 0x02c3581b g_object_new_valist + 1115 5 libgobject-2.0.0.dylib 0x02c35c42 g_object_new + 66 6 libgio-2.0.0.dylib 0x029aa60c g_settings_new + 60 7 libgncmod-app-utils.dylib 0x01f19548 gnc_gsettings_get_schema_ptr + 328 8 libgncmod-app-utils.dylib 0x01f1a033 gnc_gsettings_get_float + 35 9 libgncmod-app-utils.dylib 0x01f1c3d8 file_retain_changed_cb + 56 10 libgncmod-app-utils.dylib 0x01f1c420 gnc_prefs_init + 48 11 libgncmod-gnome-utils.dylib 0x002b1e2b gnc_gui_init + 347 12 Gnucash-bin 0x00013369 main + 1001 13 Gnucash-bin 0x00012776 start + 54 Thread 1: 0 libsystem_kernel.dylib 0x93fbf0ee __workq_kernreturn + 10 1 libsystem_c.dylib 0x979d20ac _pthread_workq_return + 45 2 libsystem_c.dylib 0x979d1e79 _pthread_wqthread + 448 3 libsystem_c.dylib 0x979b9daa start_wqthread + 30 Thread 2:: Dispatch queue: com.apple.libdispatch-manager 0 libsystem_kernel.dylib 0x93fbf9ae kevent + 10 1 libdispatch.dylib 0x93f9bc71 _dispatch_mgr_invoke + 993 2 libdispatch.dylib 0x93f9b7a9 _dispatch_mgr_thread + 53 Thread 3: 0 libsystem_kernel.dylib 0x93fbf0ee __workq_kernreturn + 10 1 libsystem_c.dylib 0x979d20ac _pthread_workq_return + 45 2 libsystem_c.dylib 0x979d1e79 _pthread_wqthread + 448 3 libsystem_c.dylib 0x979b9daa start_wqthread + 30 Thread 4: 0 libsystem_kernel.dylib 0x93fbf0ee __workq_kernreturn + 10 1 libsystem_c.dylib 0x979d20ac _pthread_workq_return + 45 2 libsystem_c.dylib 0x979d1e79 _pthread_wqthread + 448 3 libsystem_c.dylib 0x979b9daa start_wqthread + 30 Thread 5: Thread 0 crashed with X86 Thread State (32-bit): eax: 0x ebx: 0x02caf2b1 ecx: 0xbfffeef4 edx: 0x edi: 0x0002 esi: 0x022760f0 ebp: 0xb4a8 esp: 0xb000 ss: 0x0023
Re: Announcement: GnuCash 2.6.0 Released
On 31 Dec 2013, at 8:54 AM, Graham Leggett minf...@sharp.fm wrote: More information, attempting to run gnucash from the command line fails as follows: Little-Net:Testing minfrin$ Gnucash.app/Contents/MacOS/Gnucash Application Path /Applications/Testing/Gnucash.app/Contents/MacOS/Gnucash-bin (process:30185): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. Backtrace: In /Applications/Testing/Gnucash.app/Contents/Resources/share/gnucash/guile-modules/gnucash/main.scm: 76: 0* [setlocale 0 ] /Applications/Testing/Gnucash.app/Contents/Resources/share/gnucash/guile-modules/gnucash/main.scm:76:1: In procedure setlocale in expression (setlocale LC_ALL ): /Applications/Testing/Gnucash.app/Contents/Resources/share/gnucash/guile-modules/gnucash/main.scm:76:1: Invalid argument An attempt to set a locale manually as follows from the command line works and allows Gnucash to start up: Little-Net:Testing minfrin$ LC_ALL=C Gnucash.app/Contents/MacOS/Gnucash Application Path /Applications/Testing/Gnucash.app/Contents/MacOS/Gnucash-bin Preference migration has finished An attempt to set the locale manually directly on the Gnucash-bin binary causes the binary to crash as before, and log the following to the console: Little-Net:Testing minfrin$ Gnucash.app/Contents/MacOS/Gnucash Application Path /Applications/Testing/Gnucash.app/Contents/MacOS/Gnucash-bin (process:30185): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. Backtrace: In /Applications/Testing/Gnucash.app/Contents/Resources/share/gnucash/guile-modules/gnucash/main.scm: 76: 0* [setlocale 0 ] /Applications/Testing/Gnucash.app/Contents/Resources/share/gnucash/guile-modules/gnucash/main.scm:76:1: In procedure setlocale in expression (setlocale LC_ALL ): /Applications/Testing/Gnucash.app/Contents/Resources/share/gnucash/guile-modules/gnucash/main.scm:76:1: Invalid argument I tried to raise this as a bug in bugzilla, but the forgot password mechanism is currently broken, it goes through the complete process of allowing you to change your password, confirms that your password has been changed successfully, and when you try and log in with your new password, tells you your username or password is incorrect. Regards, Graham -- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Announcement: GnuCash 2.6.0 Released
On 31 Dec 2013, at 9:14 AM, Graham Leggett minf...@sharp.fm wrote: I tried to raise this as a bug in bugzilla, but the forgot password mechanism is currently broken, it goes through the complete process of allowing you to change your password, confirms that your password has been changed successfully, and when you try and log in with your new password, tells you your username or password is incorrect. Turns out bugzilla truncates passwords without telling the end user, trying a shorter password got me in. Raised a bug here: https://bugzilla.gnome.org/show_bug.cgi?id=721260 Regards, Graham -- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Bug 336843 - Attach files to Transactions
On 14 Nov 2013, at 7:17 AM, David Carlson carlson...@sbcglobal.net wrote: If there is is a short warning about the fragility of external links within the program including a reference to a more thorough discussion in a help file, I think that users can decide for themselves whether to proceed. The discussion should include suggestions on ways to minimize risks by careful choice of storage locations for example, and how to construct references that are less likely to break if the files are moved to a different location. I think people at this point are quite used to links, as long as it is clearly indicated that you're storing a link to the file (via a URL) and not the file itself you'll have little confusion. Regards, Graham -- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Base And Gnucash
On 29 Apr 2013, at 7:28 PM, John Ralls jra...@ceridwen.us wrote: Because Gnucash isn't that kind of a program. It's an accounting program, the exact domain for which SQL was invented. Basically Available, Soft state, Eventual consistency are all anathema to accountants. Really? I am still waiting for one client's accountant to eventually pay me, and I will eventually capture those invoices piled on my desk. Would you want your bank to treat your account that way? My bank does treat my account this way. If you pay me now, I'll eventually get the money, maybe in two hours, maybe in two days, maybe 7 days if you gave me a cheque. 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: Approval for Introducing Your Software in Japanese PC magazine
On 28 Apr 2013, at 04:45, John Ralls jra...@ceridwen.us wrote: The rules say that you have to distribute all of the source code, but I think that it's become pretty common to rely on the fact that the sources are all readily available via the net. You'll probably want to get an OK from your lawyers. The rules say that if you make changes to the code, you must make those changes to the source available under the same license. If you don't make changes to the code, for example you just publish the binaries as provided, then just link back to the source here. The source doesn't need to be on the same physical medium, but does need to be available. An example might be binaries on an operating system CD, with source available via the operating system website. Regards, Graham -- Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Recommend IDE for coding in C
On 20 Mar 2013, at 7:13 PM, Buddha Buck blaisepas...@gmail.com wrote: Both C and C++ are old enough languages that they have a certain amount of cruft in their design with makes it hard for IDEs to get their hooks into them to provide advanced services. For instance, while there are refactoring tools for Java and C# that work with popular IDEs for those languages, there are none for C/C++. I've been using Eclipse for a number of years for C/C++ development, and while not as polished as the Java stuff, it does the job. Eclipse also provides a similar set of refactoring tools for C/C++ as to Eclipse for Java, I am sure there are differences, but none that I've found insurmountable, so to say there are no refactoring tools for C isn't true. 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: GnuCash XML spec (for non-C languages?)
On 06 Nov 2012, at 12:22 PM, Christian Stimming christ...@cstimming.de wrote: Hence, even though it is still not yet realistic to find a complete specification of data store access independently from our C library, I think it should be possible to do a specification of a subset of the data. And applications that access and work on only that subset should then be possible. Such as, an Android app that access a gnucash SQL data base, and using only those specified features and data store elements. Voila, there we have our multi-user multi-platform gnucash within reach… I think the biggest obstacle to using gnucash over the long term is the unstable data format, and the inability to interoperate. Once the data format is defined, everything flows from there. I think a formal XSD of the XML format would be a good start. I use an XSD that works for me, but this isn't ideal, I want to use an XSD I can trust. 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: GnuCash XML spec (for non-C languages?)
On 06 Nov 2012, at 3:14 PM, Derek Atkins de...@ihtfp.com wrote: Another option would be to have a GnuCash service that runs on a home server and enables remote access to the GnuCash data through a well defined services API. A mobile app would implement the client side of the services API and connect to your running GnuCash service. Less to set up (no https required) but more work for us because we need to implement more. This could also enable a web service.. especially if we decide to use xml or json as the transport framework. But writing an http service might still be easier, even if it is harder to set up for the average Joe. I suspect some people would be willing to use a web service run by someone else.. *ponders* This is an excellent idea. Plucking a random example, iTunes is both a music playing client, and a music serving server. As an end user, I just install iTunes, and without caring how the magic happens, my iTunes magically appears to others on my network. I would love it if gnucash was a service that I could run locally for my own consumption as part of the gnucash client installation, or perhaps (suitably secured) run with people on my network, or (suitably secured again) share it with my accountant. 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: GnuCash XML spec (for non-C languages?)
On 06 Nov 2012, at 3:28 PM, Geert Janssens janssens-ge...@telenet.be wrote: Just for completeness, let me repeat what has been said multiple times before: an XSD can't possibly describe the accounting constraints we impose (eg sum of all splits in a transaction should be zero). So at best an XSD can protect you from writing invalid gnucash-xml, but it can't help with ensuring the data still makes sense. It's not XSD's job to enforce this kind of thing, you're always going to reach a garbage-in-garbage-out problem that XSD won't protect you from. The two key things that an XSD allows you to do is validate the overall structure of the gnucash file, and to generate code. This generate code part is the killer feature, it suddenly becomes very easy (therefore desirable) to develop new gnucash based tools. Also, xml is only one of the data store formats we support. There are also three flavours of SQL databases. Same there. You can formalize the database schema, but that doesn't help enforcing additional accounting constraints. We should formalise the schema too. Without formalised data formats, there is no way to tell whether something is a bug, or a feature. Having said all that, I agree an official XSD/Db schema can be a start. Another layer describing the accounting constraints that have to be adhered to should be added at least though. Certainly. Initially we might insert these as XSD comments and XSD documentation, and then perhaps investigate where XSD might enforce things for us. 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: GnuCash XML spec (for non-C languages?)
On 05 Nov 2012, at 9:58 AM, Colin Law clan...@googlemail.com wrote: I wouldn't go there. Most people, me included, consider their financial data to be extremely sensitive and private. The potential liability from such a cloud storage facility getting hacked is incalculable. That is a valid argument against using cloud storage but it does not apply to a home server. I would add to that that static IPs are readily available for basic broadband connections, meaning a small business placing their accounts online on their own server for the benefit of their customers, or at the very least their accountant, is well within reach. The difficulty in getting our accountant to share access with us is our number one headache with gnucash. 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: Credit notes
On 30 Aug 2012, at 18:35, Geert Janssens janssens-ge...@telenet.be wrote: Anyone who's good with words, can you voice your opinions here please ? A credit note is a type of invoice, the other type of invoice being a debit note. I would recommend not making up out own terms for this this, but rather leaving it as invoice - debit note and invoice - credit note. Same for bills. Sometimes vendors will give us a credit note, and we have no way to capture it apart from editing the XML file directly. Regards, Graham -- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Thoughts on budgeting
Hi all, For a while now I have been capturing transactions up to a year ahead (as opposed to being behind), entering the expected transaction value. When the account is reconciled, the values become actual values. What this allows me to do is know what my bank account will look like in three months time, taking into account things like the VAT return that might be due in two months time, and I can get a clear indication of how much money I really have to spend, as opposed to what my bank balance is telling me on any given day. What I'd really like is a way to mark transactions as draft transactions, perhaps lightly coloured in grey, but otherwise functionally identical to a normal transaction. This would clearly distinguish them from actual transactions that have actually happened. Perhaps in addition to have a reconciliation flag of N, Y or C, there could be a D for draft, and some quick way to toggle the transaction between N and D. You could then have reporting options where draft transactions are included (ie show me my projected income statement for this coming year), or specifically excluded (ie show me actual transactions only). In theory, this would be a low tech, simple way to get a kind of budgeting done. Thoughts on the idea? Regards, Graham -- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: For The Love Of Bitcoin
On 16 Feb 2012, at 7:45 AM, karmicads wrote: I suppose I´d like to see bitcoin supported as a mainstream currency, despite the lack of official ISO recognition. I imagine GnuCash not only I don't know what our policy is on adding non-ISO currencies to the list of currencies. That would be a great start. In revision of this policy, I think it may be poignant to consider the nature of currency, as shared information about what the wider populous values. There are distinct qualitative differences, between the officially supported ISO fiat currencies and that of an online ´viral´ currency like bitcoin. Firstly, bitcoin´s value is derived by direct supply and demand of the marketplace, rather than being authorized by any government mandate that it must be used as legal tender. The most obvious problem with government fiat currencies in general, is that the extent of their value, extends only as far as the legal mandate of their issuing government authorities. [snip] I don't see how any of this has anything to do with gnucash - gnucash is an accounting system, it accounts for money, but doesn't care as to the origin of that money. Am I right in understanding that you want a currency code for bitcoin included in gnucash? The best solution is for bitcoin to get a proper ISO currency code, and then gnucash would just support it as an official code. Is there a reason why bitcoin doesn't have an ISO code? Regards, Graham -- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Add IRS audit capabilities
On 15 Feb 2012, at 6:15 PM, Ted Creedon wrote: Being audited for 2 years, Gnucash is very helpful. Suggestion, it would be helpful if receipts, check stubs and other documents could be scanned in and made part of the transaction record. Binary BLOBS would require a lot of database storage but the generated report would be IRS proof. The IRS wants the data sorted by account date. Ideally you want to store this stuff by reference, and not turn gnucash into a content management system. In other words, if gnucash could store a link to a document, and for extra points display that document if practical or launch an external viewer if not, it would be ideal. This is just an extra metadata field against a transaction. The document could be stored in the cloud, in svn, wherever, it's all just a URL. The customer or vendor statements could then include links to data where present, give that to the IRS, done. Regards, Graham -- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Strategy
On 03 Dec 2011, at 11:40 PM, Donald Allen wrote: Gnucash has been around for a long time, and its life-span covers the development of a lot of tools. If you were going to start with a blank sheet of paper today, I doubt very much whether you would do a lot of the system as it is today. The big question is, when is it worth it to cut your losses and start over? I use gnucash because a) it's been around a long time, and b) because gnucash is likely to be around a long time still. Anyone can start over at any time - that's called a new product - but when people decide to abandon what they have and start over, that's when you lose faith in the project and start to look somewhere else. Sure, new fandangled languages are shiny, but will they still be popular in 5 years? No idea. I am happy to bet that C will be around in 5 years, so investing in the language as unsexy as it might be for me is a good investment. I think gnucash needs a heavy set of refactoring. I'd like to see a proper libgnucash split out as a separate library that I can depend on in other software. I'd like to use a libgnucash library as a basis for a restful service that will allow me to share gnucash with others, like my accountant. But I don't think gnucash needs to be started over. Regards, Graham -- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Building gnucash for MacPorts + Quartz fails
Hi all, Having followed the instructions below in an attempt to install a quartz version of gnucash, the build fails complaining that it cannot find libgtk-x11-2.0.la. It seems that despite being configured for quartz, gnucash still attempts an X11 build. http://wiki.gnucash.org/wiki/MacOSX/MacPortsDetail#Using_MacPorts_to_install_the_native_Quartz_version_of_GnuCash From the logfile for the build: :info:build grep: /opt/local/lib/libgtk-x11-2.0.la: No such file or directory :info:build sed: /opt/local/lib/libgtk-x11-2.0.la: No such file or directory :info:build libtool: link: `/opt/local/lib/libgtk-x11-2.0.la' is not a valid libtool archive Does anyone know of a workaround to make this work? Regards, Graham -- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building gnucash for MacPorts + Quartz fails
On 30 Nov 2011, at 10:53 PM, David T. wrote: My workaround has been to download the dmg off Sourceforge. ;) I had done that already, and found it depended on X11. I wanted something cleaner if that was possible, and it was possible that the people who made the quartz build work didn't know it had stopped working in the mean time. Regards, Graham -- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: New data field for invoice object
On 08 Oct 2011, at 8:18 PM, John Ralls wrote: The way you'd implement an optional type field in an RDB is to create a new table for it with two fields, a key (which would be the invoice GUID) and the type, and the code for handling that table would have to examine the database version and not use it if it's an older version. Similarly, your new credit note code would have to check with the backend to see if it's OK to create the note, because an older version of Gnucash will do the wrong thing with the data. In my experience, I have been forced to manually change debit notes into credit notes when they become necessary by editing the XML directly, and gnucash does the right thing with the data afterwards. What gnucash can't handle is applying payments, because the payment code naively assumes all amounts are positive, instead of handling both the cases of positive payments and negative payments. But the payment is done by this point, so in my case it doesn't matter. 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: Credit notes analysis
On 11 Sep 2011, at 11:26 PM, Geert Janssens wrote: I have spent some time to investigate what is needed to support credit notes in GnuCash. The result of my analysis can be found here: http://wiki.gnucash.org/wiki/Credit_Notes For simplicity I'm using the term credit note as the inverse of all invoice types we support so far (Bill/Invoice/Employee Voucher), not just for customer related transactions. My conclusion would be that it should be possible to support credit notes without any change to the data model, although maybe one internally used field might hold some new values. It will require a minimal set of compatibility fixes the the current stable GnuCash version to avoid some unwanted confusion, but those are minimal. I intend to start with an implementation of this fairly soon. I'm welcoming all feedback, questions, remarks,... At its simplest, credit notes are just debit notes with a negative sign, and it would be ideal if that's all they need to be. In other words, regardless of the amounts on the invoice/bill, the total amount can be negative or positive, and gnucash just gets on with it. Where I've had to fiddle with this before to apply payments, I've discovered that the code that allocates payments to invoices/bills assumes that the payment has a specific sign. We would just need to teach this algorithm to behave sensibly with payments and invoice/ bills of either sign, and it should work fine. In the absence of another way to do it, we modify the gnucash file in a text editor (and version control the gnucash file in svn) to reverse the sign of credit notes, we just haven't had a way of doing it before. 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: gnucash-android implementation (Three projects for Gnucash)
On 06 Feb 2011, at 9:44 PM, Christian Stimming wrote: There is no such interchange file format available as well at the moment. Again: Even though in gnucash we always insisted you have to use the existing C code, the situation now has changed and there is a significant user request which can technically be solved only by re-implementing everything in a different language that will access the SQL directly. So we, the gnucash team, have to reconsider our original point of view and should better get to live with the new changed situation... One of the big downsides of the SQL format in it's current implementation is it's very difficult to share, and people would share the database between a mobile device and say a desktop device, or you might want to share your database with the accountant who does your tax. Sure, you could send them a dump of the whole thing every time, but if they make changes, they have to merge them back with yours, which is less than ideal. We currently keep the XML file in an svn repository, and mandate that anybody who works on the gnucash file must lock the file before making changes. It takes discipline, but everyone has access to the latest version when necessary. It would be very cool if gnucash was available from a restful interface, so that a mobile app, a desktop app, any app could take advantage of it, regardless of where it was. Regards, Graham -- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Three projects for Gnucash
On 05 Feb 2011, at 11:09 PM, Ryan M. Ward wrote: 1) Implementing a way of storing receipt images (scanned or from a cell phone, etc) in a database- referenced by transaction (IE from the ledger, you would have the option of looking up the reciept associated with a particular transaction, and/or querying a collection of transactions and collecting all of their associated receipts- my thought here is mainly for income tax purposes- I do not envision GNUCash being a tax preparer, but this database would be nice for this and other purposes) Something simple and straightforward would be the ability to store the URL of the receipt/invoice against the particular entry, rather than the whole invoice itself. We store all invoices in svn (but invoices could be stored in git, or just as files-on-disk or files-on-webserver), and the corresponding URL stored. Functionality could then exist to display the corresponding document, or to flag which documents are missing (return 404), etc. Regards, Graham -- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Challenging python coders: Who can create a gnucash-like GUI in python in a few weeks?
On 10 Jan 2011, at 12:24 PM, Christian Stimming wrote: We've been discussing various future directions for gnucash, including a switch to a different programming language for the GUI code [1]. GUI coding in C sucks. Because of this, I've experimented with C++/Qt and was able to write up a usable gnucash-like register window GUI in 2-3 weeks which already includes features that are unavailable in conventional gnucash [2]. I chose C++/Qt because I'm very familiar and productive with that platform. Something that would be really awesome would be to look at the GUI code in such a way as to ensure that writing the GUI code for the native platform would be simple and easy to do. In other words, it would be awesome if there was a native MacOSX version of gnucash, that used the Cocoa interface natively, and a native Windows version of gnucash, that used the Windows APIs natively, etc. I think rather than focusing on a GUI, rather focus on a clean API to the gnucash core, that a GUI might call easily. That will free up a python coder to use the python bindings to make a python based interface (as you've suggested), or a Cocoa coder to make MacOSX bindings, etc. Regards, Graham -- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Getting 2.4 Released - Yes!
On 20 Oct 2010, at 12:17 AM, AshokR wrote: By this approach, it is a win-win for both users and developers. The users get the option to save in relational database formats to use third- party reporting tools and integrate with other applications. And the developers get to bake SQLite3 integration code, for a possible future switch to that format as 'native'. +1. I won't be trusting the SQL stuff as a primary source for my data for a long time, but exporting it to a SQL database so I can query against it would be very useful. Regards, Graham -- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Trial balance includes data from previous financial years
Hi all, I am currently struggling with the trial balance report in gnucash v2.2.7. When I attempt to run a trial balance from 2009-03-01 to 2010-02-28, I end up with transactions included in the report from before 2009-03-01. I keep the same gnucash file spanning multiple years, and the income statement and balance sheet are able to show me figures from a specific accounting year, however the trial balance doesn't want to cooperate. Is this normal behaviour for the trial balance, or is this a bug? What is the significance of the start of adjusting/closing date, and how does it relate to the date of report? According to the title of the trial balance, it is implied that only entries after start of adjusting/closing date and on or before date of report are included, or have I misunderstood how this works? Regards, Graham -- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Invoice Importer
On 09 Jun 2010, at 3:33 PM, Phil Longstaff wrote: I've had thoughts of a generic importer, so I'll lay them out here and you can use some or all or none of them. I have used an accounting system in the past which allows CVS files to be imported. You specify the CVS file and which CVS column contains which internal data field and then let it run. What also may be nice to support is the importing of UBL invoices: http://docs.oasis-open.org/ubl/cs-UBL-2.0/xsd/maindoc/UBL-Invoice-2.0.xsd Regards, Graham -- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: We need to prevent multi-user access to the SQL backend (Re: New GnuCash article on LWN)
On 21 May 2010, at 6:04 PM, Derek Atkins wrote: Because a situation arises when both of you need to make writes. Which copy is the authoritative copy? Using svn alleviates this somewhat, but isn't ideal. The authoritative copy belongs to whomever has the write token. Otherwise known as the svn lock. Sharing access is a lot simpler than people think. It is not strictly necessary for gnucash instance A to be 100% up to date with gnucash instance B. The only time it does need to be up to date is when an amendment is made to a transaction, and at that point you construct the update query in that it replaces what gnucash instance A believes was the previous version of the transaction. If the query was successful, we're done. If the query touched no rows, we know there was a conflict, and the user will need to be asked to make their amendment again, resolving the conflict. To keep registers up to date, keep a table containing a last updated timestamp on each account. The timestamp's value isn't important, only that it has changed. Instance A and instance B polls the table from time to time, and reloads any register as necessary. Regards, Graham -- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: We need to prevent multi-user access to the SQL backend (Re: New GnuCash article on LWN)
On 20 May 2010, at 6:32 PM, Derek Atkins wrote: Your solution to block the whole database is good enough for me. It's a real shame that a system fundamentally designed to offer multi user access to data should be crippled in such a fashion. In the process, virtually all reasons to use a SQL database are lost. What was fundamentally designed to offer multi user access? SQL databases. GnuCash most certainly was not, even when it's using a SQL Database for data storage. Repeat after me: GnuCash is NOT a Database Application. It's a standalone application that happens to be able to use a database instead of SQL, but fundamentally it's still a standalone application. The fact that the DATABASE can be accessed multi-user has nothing to do with the fact that GnuCash was NOT designed to handle that and therefore needs to protect its data from users who try to do it. Which over time pretty much renders it useless. In any practical usage, even in it's simplest form, you start off small and simple, and then eventually you reach a point where you want to share the file between two people, or share the file with an accountant, and you can't. Which is a real pity, because in my experience gnucash gives about 95% of what a small business needs, tripping up on that last little bit. The fact that gnucash can be asked to save the file in text/xml helps, because you can version this in something like svn. But versioning a database isn't easy at all. Regards, Graham -- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: We need to prevent multi-user access to the SQL backend (Re: New GnuCash article on LWN)
On 20 May 2010, at 6:55 PM, Derek Atkins wrote: Well, over time one would hope that we can slowly rearchitect gnucash to be more aware of multi-user situations. I'm keen to do some of that work, as I need it directly. In any practical usage, even in it's simplest form, you start off small and simple, and then eventually you reach a point where you want to share the file between two people, or share the file with an accountant, and you can't. Why not? Because a situation arises when both of you need to make writes. Which copy is the authoritative copy? Using svn alleviates this somewhat, but isn't ideal. It is really easy to silently lose transactions, if a mixup occurs over who holds the master copy of the data file. The fact that gnucash can be asked to save the file in text/xml helps, because you can version this in something like svn. But versioning a database isn't easy at all. Why do you need versioning? Versioning is overkill for data sharing. It prevents the situation where I add a transaction, then you add a transaction, silently overwriting mine. Not only is the data wrong, it is silently wrong without warning. On the other hand, once you start going down that road you really start getting well past what GnuCash was designed for: Home Users and Small Businesses. It's a Quicken/Quickbooks replacement, not a Peachtree or SAP replacement. I am a small business, there are two partners and an accountant. We are nowhere even close to needing SAP. Regards, Graham -- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: We need to prevent multi-user access to the SQL backend (Re: New GnuCash article on LWN)
On 19 May 2010, at 11:47 PM, Per Kjeldaas wrote: Your solution to block the whole database is good enough for me. It's a real shame that a system fundamentally designed to offer multi user access to data should be crippled in such a fashion. In the process, virtually all reasons to use a SQL database are lost. We use the XML backend, and share it by versioning it in source control with mandatory locks. It's not perfect, and requires discipline to respect the lock, but it works between three different people sharing the responsibility to keep the accounts up to date. Regards, Graham -- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Why is your Software Free
On 25 Mar 2010, at 11:51 PM, Cam KELLY wrote: My brother speaks highly of your software and I have a question. Why is gnucash available for free and/or donation ? I have a limited understanding of the GNU Software License but if I understand correctly, you are not required by the license to make gnucash available at-no-cost. I am a software developer with mid-career experience (about 3 years) and have read 'The Success of Open Source' by Steve Weber and other on-line commentaries at gnu.org. The police I worked with previously were leery of open-source software and I continue to transition to independent work : www.CambridgeSoftware.biz. There are two components to the cost of software, the cost of developing it, and the cost of maintaining it. Over time, the cost of maintaining the software by far and away exceeds the cost of developing it. The traditional commercial model is to sell you the software outright, however this doesn't cover the ongoing maintenance of the software, so the company needs to find a way to sell you the same software again and again. A common approach is to keep making arbitrary changes to the software to keep coming up with new products to resell, and this is really wasteful. The open source model is based on a focus on recovering the maintenance cost instead of the development cost, so you'll find the key ways open source companies make money is through charging for ongoing support. Because there is no pressure to arbitrarily change software for change's sake to generate new sales, you'll find open source software is far more stable, changes far less frequently, and is as a result far less risky to rely on than traditional commercial software. There is second economic incentive for open source, is that the authors of the open source software are credited directly for their work. Commercial companies generally prefer their developers to remain secret to prevent poaching of staff, but that's bad news for the staff themselves, whose contributions to software projects contributes to the reputations of the developers. A further economic incentive for end users of software is the fit of the software application to their organisation. The chances of a given piece of software fitting the problem is very unlikely to approach 100%, there is always a missing feature of place where the software has to be bent to fit. In the case of commercial software, the feature will have to be custom developed and negotiated by the company who produced the software originally, and this takes lots of time, lots of money, and the company can just say no. And for people without time or money, this can prove a dealbreaker. With an open source project, the end user has the source, and can develop their missing feature themselves, or by using skills on the open market, rather than being forced to use the skills of the company who control the commercial software. A further significant economic incentive in the favour of open source is the quality of code. Open source software is visible warts and all, and the reputation of developers is tied into the quality of the code. Closed source code is hidden, allowing a multitude of sins to remain hidden. Regards, Graham -- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Algorithm for allocating payments
marcus.wolsc...@googlemail.com wrote: Why write it yourself? Because jgnucashlib didn't exist when I started writing this code, it's been around for a while :) That code already exists in jGnucashLib. https://sourceforge.net/projects/jgnucashlib/ I remember that I wrote code to mark transactions as being the payment for invoices and for adding and posting new invoices from java. This is excellent, thank you! Do any javadocs exist for this? I see a todo in the documentation for javadocs. Is there a definitive description anywhere of the link between transactions, lots and customers? transaction and invoice have the same lot-number. orders have invoices. customers have order. What is an order (in the xac file)? How are prepayments handled? Regards, Graham -- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Algorithm for allocating payments
Hi all, I am currently trying to create some code to add a payment to a gnucash xml file in java, and I am struggling to find a proper description of the procedure I need to create the lots that link the transaction in A/R with the customer who made the payment. Is there a definitive description anywhere of the link between transactions, lots and customers? So far, my attempts at loading in the modified file into gnucash have shown the transaction, but no link between the transaction and the customer. Resaving the file in gnucash shows that the transaction and lot are present, but no link exists between them. Is there a way to get gnucash to output any parsing errors while it attempts to laod a file? So far despite the errors in the file, gnucash silently loads the file, not revealing that anything is wrong with the file. Is this possible? Regards, Graham -- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Patch: removed trailing white spaces
Geert Janssens wrote: You can ignore this. I have found how to disable the automatic trailing whitespace removal in Eclipse. +1 to the patch anyway, getting rid of glitches like this prevents other eclipse users running into the same problem. 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: New database backend and multi-user
Phil Longstaff wrote: 1) locking/transactions - db transactions are used whenever an object is written or updated. However, no locking is done, and there are certain cases where related objects are not saved in the same db transaction, because the back-end does not have enough information. For example, when a transaction with multiple splits is saved, each of these is a separate engine object and is saved separately. The back-end API would need to be modified to add start- transaction and end-transaction calls so that multiple objects could be saved/committed/rolled back together. I would say this is a prerequisite whether multi-user or not. We don't want an error to happen half way through the save, and the end up with a corrupt database. This didn't matter in the XML world so much, as if an error occurred that corrupted data you were unlikely to get the opportunity to save the corrupted xml file. 2) Update notification - Most objects are read when the db is opened and not read again. Some databases (postgres? not mysql?) provide a callback when an update is made, so that data can be refreshed. An alternative would be a timer to refresh. A far simpler approach is to just react to errors intelligently. For example, if you have chosen an option from a dialog box, and you attempt to commit a transaction depending on that option, and you discover the option you selected in the dialog box no longer exists (it's been changed, whatever), just tell the user sorry, conflict, please make your change again, as the database changed out from beneath you. No need for sophisticated error handling, but we do need something more than the evil message an error has occurred. 3) Mechanism to handle conflicts - How should the cases be handled when different people make conflicting changes? You simply pop up an error message to the end user, telling them that a conflict has occurred and they must abandon their changes and try again. In theory you won't store up a long list of changes, resulting in a big conflict, you would rather do one small changes at a time, resulting in small conflicts which are trivial to redo. Small conflicts are also extremely unlikely to happen, making the pain both small and seldom. Don't be tempted to offer the end user the option use my changes and ignore the conflicted ones, as this is a recipe for pain and angst for the end user. 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: [PATCH] sort when saving
Jim Radford wrote: The attached patches sort the slots, lots, book accounts, bill terms, customers, employees, entries, invoices, jobs, orders, tax tables and vendors before saving them to the gnucash XML file. This is an attempt to make saves more idempotent thereby facilitating the use of a revision control system on the gnucash XML files. With these patches most of the needless and seemingly random churn is gone. I can now for example add or remove a transaction and expect there to be no other changes to the gnucash file. I'm curious to see if these patches affect save performance noticeably for anyone. They don't for me, but I don't have a very large file. Definitely +1 for this, will make my life considerably easier. 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: GNU Cash question
Caren Langenhoven wrote: This program was recommended to me by my IT guy. We are in South Africa. The business that I want to run on GNU Cash is VAT registered. Will I be able to do my South African VAT(14%) on this program? I use gnucash for a ZA based business. I use the gnucash VAT features for VAT output tax (VAT on invoices), but capture the VAT input tax as a line item on bills (VAT on purchases). This is done to stop gnucash trying to work out the VAT input tax itself, and to account for input and output tax separately (gnucash lumps these two together by default). So in short, yes. Id this program PASTEL compliant? What does pastel compliant mean? (I understand pastel to be a product, rather than a standard). 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: String lengths in the SQL backend
Derek Atkins wrote: Multi-user access is not a goal in the first release, but it is certainly something that would be nice to add. And yes, a SQL Backend is necessary but not sufficient for multi-user. Not addressing the multi user issue now will cause a significant number of bugs to be reported down the line, as there is nothing stopping two people from accessing the same database. 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: install etc
Carol Brown wrote: I am starting a small business and have done some research and most agree that GnuCash is the best accounting program for Linux. But I am dismayed to see that I have to download /source code/, which to me means /compile/ and /build/. Arghhh. I don't do compile and build. I am starting a business and just want to install and use my accounting software. As you can imagine, I have a bazillion other things to do. Gnucash binaries are available by default in most Linux distributions, there is usually no need to try and build binaries yourself. Take a look in the docs for your distribution to find out what software is available, and what it is called, and how to install it. The package you are looking for is probably called gnucash, or potentially gnucash2. 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: String lengths in the SQL backend
Derek Atkins wrote: Uhh, yeah. Sorry. Totally unreasonable. The code in question is a user-input field. Historically accountants used codes instead of names to keep track of accounts. So GnuCash provides a place for you to enter in an Account Code. But it's a string, not a number. Granted, most users probably do only use numbers, but there is no requirement that it be a number. It is for this exact reason that in standard database schema design, codes should not be used as keys. The end user (or an administrator, or an auditor) should have the power to choose the code as they see fit and change the code if they see fit. If you have used the code as a key, changing that code becomes difficult from a sql perspective. The XML file already uses a separation between codes and keys: the user might enter a code, but internally inside the XML file GUIDs are used as keys. Because of this, the code can be changed easily and safely, and the end user doesn't have to know or care what a GUID is or even that a GUID exists. It is perfectly reasonable (and recommended) for the primary key to be something private to the application (an integer, a GUID, whatever), and the code to be just-another-field in the table. 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: String lengths in the SQL backend
Phil Longstaff wrote: I'd have to look back, but I think Derek's reply was the only one. I'd like to open the topic again, because of Rolf's problem. Can anyone think of a reason that account code size limit cannot be reduced to a smaller value (e.g. 32)? Will anyone ever enter an account code longer than that? No matter what you do, any limit that you set will always eventually be too small for somebody. Ideally gnucash should not impose any limit at all - it should be up to the entity that creates the database to decide how wide the columns should be. Doing it this way means that database column sizes become the user's problem. If the user needs a wider column, the user can make the column wider. If the user chooses a database that supports varchars of large size efficiently (like postgres), then gnucash should step out the way and not impose a limit at all. In terms of the UI, if gnucash could query the database and say how wide is this column? and then use that to limit the widths, again it means that widths are the user's problem. 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: Development on Mac Leopard (10.5.5)
Charles Day wrote: 1. Is it readily possible to do GnuCash development, compilation, and testing work from within Leopard, via macports or fink or otherwise? Yes. 2. Is it just easier to do the work in Linux or XP running in a virtual machine, e.g. vmware fusion or parallels? (I would rather not have to dual boot.) No. :) I currently use the macports version of gnucash and it works fine, though a big minus is the excessive time taken installing it. 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
OFX import and cancel
Hi all, I have picked up some strange behaviour with the OFX import code. If you select an OFX file to import, the generic import transaction manager appears. If at this point you click cancel to bail out of the import process, the window closes and everything looks fine - until you try to add a further transaction to the account. At this point, all the transactions that would have been touched by the OFX import suddenly display themselves as unbalanced (square-in-a-box), as the splits have all lost their accounts. To fix this, you have to reload your xac file from a backup. If you click on OK on the generic import transaction manager, it works fine. Has anyone else seen this before? 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: time_t - When does it break?
Ian Lewis wrote: In other words, the timezone in which it was entered needs to be stored to figure out what day it was entered? Otherwise, wouldn't the local timezone be enough to serve as metadata when converting to a date? The local timezone changes over time, and this is the source of the problem. I moved from one country to another and suddenly my VAT returns went haywire because transactions on the 1st of the month were now suddenly on the last day of the previous month, and therefore in a different VAT period. Others might live in NY and fly to LA on business for a few days, updating their timezone while there. They will face the same problem. Base accounting cares about dates and not times because accounting wants to break accounts into periods. If the date is ambiguous, then the period into which that transaction falls is ambiguous, and this affects things like tax and VAT returns, which in turn leaves the end user facing tax penalties. 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: RFC: Timestamps/timezones proposal
Charles Day wrote: ok, though what happens when the user decides to change the timezone for account A? (eg. I ask the bank to transfer my account from their Saint John's branch to their Vancouver branch, 5 timezones apart?) What happens to the timestamps and dates displayed then? The timestamps don't change. Only the value displayed. This breaks double entry accounting. If account A and account B had different timezones, it means the balancing splits within a transaction can fall on different days. If this happened over the start or end of a period of time, your accounts would no longer balance - only half the split falls into the period! In order to be able to trust the data coming out of gnucash, gnucash must be completely 100% and absolutely unambiguous about the data. If the user specified a day, a month and a year, there must be absolutely no way possible at all that circumstances can conspire to have that day month and year changed to a different day month and year without the user's knowledge. The single and only way a date should change is if the user explicitly went in and changed that date, and at no other time. The only safe way to do this is to store a date as a date, and not a timestamp. 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: RFC: Timestamps/timezones proposal
Charles Day wrote: No, splits don't have posting dates or times. The entire transaction uses a single timestamp. That's how it works now. Under this proposal, that timestamp would only be *displayed* differently in different registers, or not, according to your preference. This is still very broken. If the accounts have different timezones, then the split in account A can fall on a different date to the split in account B, even though they have the same timestamp. User confusion results. You can try and kludge it as much as you like: A timestamp will never reliably represent a date no matter what hoops you jump through. I disagree. If GnuCash uses timestamps, but a particular user such as yourself wants to disable the effects of time of day and time zone differences, then GnuCash could be set to use a single time zone for all accounts. I imagine there being a global preference called something like I want to enter transaction times, which would be off by default, causing GnuCash to completely ignore the time zone of your computer, So when you moved your computer between time zones, it wouldn't affect your accounting. Under what circumstances would an end user ever choose the option randomly change the dates on my transactions when I change the timezone on my machine? As I have said before, there are *severe penalties* for getting financial information incorrect. Tax authorities will *fine* you for submitting inaccurate information. This bug exposes gnucash users to non trivial risk during a tax audit. Any fix to this problem must not include scope for a programmer of gnucash to accidentally use the system timezone for date calculations and in so doing introduce subtle to find and dangerous bugs. Using timestamps is begging for trouble. 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: RFC: Timestamps/timezones proposal
Charles Day wrote: Tell me how this proposal would cause random date changes. Only the *display* of the timestamp changes, and only according to settings that you pick yourself. Try this: Enter a transaction dated 1 March 2008 in an account with timezone UTC+02, with its split in a second account with a timezone of UTC. Later, the user notices that in the second account, the transaction appears on 29 Feb 2008, goes that's odd, and corrects the date to say 1 March 2008. Without the user knowing, the transaction on 1 March is now actually on 2 March 2008. Try this: Create a new account. The account is created with the local timezone as a sensible default. User thinks nothing of it and creates an account in timezone UTC+02. Fast forward some time, change your timezone in the mean time. Create a new account. The account is created with the local timezone as a sensible default. User thinks nothing of it and creates an account in timezone UTC. User encounters the first problem above and goes huh? Wastes lots of time, posts it as a bug, and then someone tells the user oh it's supposed to work like that. User ditches gnucash. You ask the impossible. Using a date alone doesn't guarantee freedom from date-related bugs either. Considering the present state, switching to a date alone would actually be a larger coding effort, and therefore probably more bug prone. You misunderstand the risk being faced. If a timestamp is used, it means that every single piece of time related code, must correctly respect the account timezone, at all times moving forward during development. As soon as *one* developer at *any* time in the future makes *one* mistake with regards to the timezone, the bug is back. The core premise behind defensive coding is choosing coding strategies that make it very difficult to make mistakes. It is difficult to get a date wrong, because 1 March 2008 is always and without exception equal to 1 March 2008. 2 March 2008 is always and without exception exactly one day after 1 March 2008. If you want to make life difficult for yourself and for end users, stick with the timestamps. 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: time_t
Stuart D. Gathman wrote: ts:date2008-04-10 18:02:00 -0400/ts:date The issue here isn't the data file (which I assumed we all agreed included the needed info). The issue is that loading the nice ascii timestamp with timezone into just a time_t field in memory (even a 64 bit one) loses critical info: the timezone. Java code has faced this exact problem for many years (java.util.Date isn't a date, but a timestamp with no timezone information), and as a result JSR310 has been proposed, which will see a whole new date and calendar library in Java targeted for JDK7 (as I understand). The work is based on work by the same people who created a date and time handling library called Joda Time: http://joda-time.sourceforge.net/ Gnucash suffers the same date problems as do applications that use the current built in Java date formatting. For those who don't fully understand the implications of date handling, comparing Joda Time to java.util.Date and java.util.Calendar should give an idea of the extent of the problem. 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: time_t
Derek Atkins wrote: Try the string 2008-04-11 00:02:00 +0200. Same timestamp. Different date. * sigh * Are you intentionally ignoring my repeated statement that we need to CHANGE GNUCASH TO USE 1200Z? No, read back what you said, which was For example, what's the difference between 2008-04-10 18:02:00 -0400 and 2008-04-10 15:02:00 -0700? I would argue that there *is* no difference. Both timestamps are talking about the exact same time. And hey look, they both say 2008-04-10. You are claiming, in this sentence, that the change in timezone doesn't cause a change in date. I have showed your assertion to be false for the example you gave. Nah, it's pretty easy to be consistent. Indeed, GnuCash *IS* already very consistent on this already. I have hunted down many bugs, and I can identify bugs that have a high risk of coming back, this is one of them. Remember my point about engineering finance software very carefully? Avoiding bug traps like this is one way you do this. 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: time_t
Derek Atkins wrote: These rules can certainly vary from place to place, locale to locale, or even person to person. Why force the issue? Because the consequences can be expensive. I was lucky in that I found and located the source of the problem relatively quickly. Had I not found it, I would have sent inaccurate VAT returns to the tax authorities, and I would have been hard pressed to explain to the tax authorities why my numbers were bogus had I have been audited. Computer error is a story the tax people have heard before, and it would not have washed. Finance software is important to engineer very, very carefully, because the consequences of getting the numbers wrong are significant and severe. 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: time_t
Derek Atkins wrote: Yes, but how would you like it if we forced the issue and the way GnuCash did it was NOT the way you needed it done? Wouldn't you prefer to be able to set it up for your particular locale in the way YOU need it to be done? I've worked in finance for a long time (first insurance, then investment banking) - a date is a universal concept across the world that is very different from a timestamp. These kind of date problems are not unique to gnucash, banking software suffers from the same pain when timestamps are used instead of dates, particularly in the Java world where there has never been a clear distinction between timestamp and date. Absolutely! Which is why I think the flexibility is IMPORTANT, because what you need and what your neighbor needs are not necessarily the same. But if GnuCash is agnostic then we can let you set it up one way and them set it up differently and GnuCash just doesn't care! You both win. In this case, using timestamps lets this happen. Using day stamps does not. Using timestamps caused my VAT returns to become bogus the moment I moved countries and changed the timezone on my machine. This is not flexibility, this is a severe design flaw. 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: time_t
Nathan Buchanan wrote: I guess the real question is - can we wait a couple years for a 64 bit time_t? Probably, I think. Are there any systems in wide use that aren't yet 64 bit time_t? I was under the impression that OSes had already changed. A quick look under MacOSX Leopard shows time_t is a long, and on RHEL5 it is a long int. 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: time_t
Nathan Buchanan wrote: I'm a bit out of my league here...but I believe a long (or long int) is defined to be a minimum of 32 bits - so if you're still using a 32 bit system(?) (or processor?) you may still get a 32 bit time_t. You're right - the 64 bit RHEL5 system showed sizeof(time_t) to be 8, while Leopard on my Powerbook G4 said 4, as did RHEL4/i386. Looking at what APR (the Apache portable runtime) does with its portable version of time_t, it explicitly defines it as a 64 bit signed type. I suspect gnucash may have to do the same. 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: time_t
Derek Atkins wrote: Different database engines have different column types for storing dates/times, so I'm using a 'MMDDHHMMSS' char string. ... in what timezone?Do you always convert to UTC? The current XML file doesn't convert to UTC, and as a result my computer is stuck in the UTC+02 timezone, when I actually live in UTC (within spitting distance of Greenwich). If I don't do this, transactions report themselves as being one day early, so transactions on the first of the month suddenly appear on the last day of last month, which sends my VAT returns into a spin. I think this is being caused by dates that are actually dates and not times, being stores as times. 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: time_t
Derek Atkins wrote: I think this is being caused by dates that are actually dates and not times, being stores as times. You think incorrectly. There are LOTS of reasons to store times in transactions. There ARE timestamps in the real world. And there are reasons that some people want to actually put time stamps into transactions, too (see bug #89439). I'm not saying that there isn't a bug here, just that your reasoning is flawed. I didn't say that *all* timestamps were unnecessary, what I said was that dates that are actually dates, and not times, are being stored as times, and that this is incorrect. For an example, look at the date entered in a transaction. The UI only allows you to choose a year, a month and a day, and because of this, you should only store a year, a month and a day. A date represents a fixed distance in time, from midnight on the previous day, to midnight on the same day, and width of this distance could be affected by all sorts of things like leap seconds and daylight saving switchover. In contrast a timestamp represents a fixed point in time, and as you vary the timezone, the date could change from yesterday, to today, or today, to tomorrow. If you mix the two up, you get the sorts of weird behaviour that we have now. It is perfectly reasonable to store timestamps for certain things. The point in time at which the transaction was captured should be a timestamp, not a date. But if you ask the user for a date (a range of time approx 24 hours in length), don't change that to a timestamp (a fixed point in time since the epoch), it just generates bugs. 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
Derek Atkins wrote: gncInvoice.c in particular the code that implements the invoice and payment processing and the balancing code to make sure payment are split across invoices properly. I have found that the current implementation of this particular functionality doesn't work that well, as it assumes payments will always follow invoices/bills. In the invoice world this is usually the case, but in the case of bills, the payment will often be entered first (the bank statement gets reconciled to ensure the customer paid before shipping the goods, and both the payment from the customer and the payment to the supplier is captured in the process), the supplier takes their time getting their bill to you so the bill is captured long after the payment was made. On top of this, you may have captured the bills in a different order to the captured payments, so the payment splits end up not making much sense. Then, if you unpost a bill to correct a mistake, it further complicates things, because now the bill total may be different and the payment splits make even less sense. This seems to affect the payable and receivable aging, I have often seen cases of where payable aging says the vendor is owed X, but the final total on the account is zero. As a result I have learned to ignore payable aging entirely. Calculating which invoices are paid and which aren't is a non trivial process, for my purposes I implemented a way to flag an invoice as unpaid if all the payments made to date by the supplier don't exceed the sum of all invoices up until that invoice. Getting that right gave me a headache. I suspect that after an invoice or a payment is posted (or reposted) for an invoice or bill, what should probably happen is that the flags indicating paid / unpaid get reset from scratch each time. This way inaccuracies can get smoothed out over time. In the XML tree, a transaction that belongs to an invoice has slots attached with additional information saying a) that the transaction is an invoice or a payment (from trans-txn-type), and b) which invoice this transaction is associated with. This has nothing to do with the data in the XML file. I honestly forget why the txn-type was created, and I dont remember where it's used. The data is respected though - if you manually change the sign, load it into gnucash and save it again, the invoice stays an invoice, and the payment stays a payment. 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
Derek Atkins wrote: Eh? I receive a bill from my vendor. It's not due for another 20 days. I enter it into gnucash and then later on pay it. Some vendors are COD only, which means the payment will almost always come before the invoice. Or the payment is captured before the bill is captured, either way has the same effect. Your algorithm cannot make any assumptions as to the order that information will be captured into gnucash. In your case you're talking about a completely different paradigm. You're talking POS/Orders, and the gnucash business features don't implement that right now. For that you should probably just forego the business features because you're never in a situation where a customer owes you money. Both our customers and our accountant require invoices regardless of when and how payment is made, again, this is a legal requirement. As a result, using the business features is mandatory for us. You can choose the first item to get paid. yes, if you unpost then it can get confused. There's certainly some post/unpost/pay series that gets it very confused but I haven't been able to reproduce this case in my testing. I have, in three separate sets of accounts, reproducing it is not difficult. 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
Gnucash XAC file XSDs
Hi all, In order to parse the gnucash XAC file from java, I have generated the following XSD files using Trang called from Oxygen XML. The XSD was generated from my company's XAC file, with additional entries added to make sure none of the fields were missed. While it works for me so far, it might need some tweaking to be useful for everyone. In addition, I have added a maven2 project that will turn the XSDs into java code automatically via xmlbeans. This makes the XAC file easily accessible from java, and makes the information within gnucash available to external applications. Would it be possible to find a home for this code in the gnucash repo? Regards, Graham -- xsd.tar.gz Description: GNU Zip compressed data gnucash-xsd.tar.gz Description: GNU Zip compressed data smime.p7s Description: S/MIME Cryptographic Signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash XAC file XSDs
Josh Sled wrote: How does this reconcile with the hand-generated Relax-NG schema in src/doc/xml/gnucash-v2.rnc? An attempt to convert it with trang throws the following errors: Severity and DescriptionPathResourceLocation Creation Time Id [Xerces] cos-element-consistent: Error for type '#AnonType_book'. Multiple elements with name 'count-data', with different types, appear in the model group. @see: http://www.w3.org/TR/xmlschema-1/#cos-element-consistent gnucash-xsd/target gnucash-v2.xsd line 56 1212357352094 8017 [Xerces] cos-element-consistent: Error for type '#AnonType_slotKvpSlot'. Multiple elements with name 'value', with different types, appear in the model group. @see: http://www.w3.org/TR/xmlschema-1/#cos-element-consistent gnucash-xsd/target gnucash-v2.xsd line 265 1212357352120 8019 [Xerces] cos-nonambig: http://www.gnucash.org/XML/gnc:count-data and http://www.gnucash.org/XML/gnc:count-data (or elements from their substitution group) violate Unique Particle Attribution. During validation against this schema, ambiguity would be created for those two particles. @see: http://www.w3.org/TR/xmlschema-1/#cos-nonambig gnucash-xsd/target gnucash-v2.xsd line 56 1212357352111 8018 [Xerces] cos-nonambig: http://www.gnucash.org/XML/slot:value and http://www.gnucash.org/XML/slot:value (or elements from their substitution group) violate Unique Particle Attribution. During validation against this schema, ambiguity would be created for those two particles. @see: http://www.w3.org/TR/xmlschema-1/#cos-nonambig gnucash-xsd/target gnucash-v2.xsd line 265 1212357352146 8020 If we're going to keep a non-authoritative schema, I'd prefer we have just one, and convert to the other formats. Though I don't care much, I'd strongly suggest the much more human-friendly Relax-NG compact syntax for that. It definitely makes sense. Xmlbeans expects XSD though, so before that is practical, we need to make sure the relax-ng schema can be converted to the different formats. I tried to convert the relax-ng to DTD, and got this: SAXException: file:/Users/minfrin/src/gnucash/gnucash-xsd/gnucash-v2.rnc:151:5 - sorry, not handled: duplicate declaration of element value from namespace http://www.gnucash.org/XML/slot; 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
Derek Atkins wrote: 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). Can you confirm in more detail exactly which part of the code makes this assumption? In the XML tree, a transaction that belongs to an invoice has slots attached with additional information saying a) that the transaction is an invoice or a payment (from trans-txn-type), and b) which invoice this transaction is associated with. Changing the sign manually on an invoice and saving the file shows correct figures for that particular customer, both from within gnucash, and from within my web statements (which ignore the sign of the transactions completely). Is the sign check shortcut being used in other reports? 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
Nathan Buchanan wrote: 2. Use GDA V4. We will probably send time fixing bugs here, but we are almost guaranteed that a release will happen. The advantages of this approach is that we will be current with the new GDA and releases will be done for us (or in conjunction with us - depending on how closely we work with the GDA team). Work done here will not be towards a dieing version. The disadvantages are that we will probably be limited to sqlite until the other providers are completed. We may have to distribute pre-release versions of the code until there is a 4.0 release, but after that, we hand it over to the official releases. I agree with this. My personal opinion is that we go with #2, use GDA V4. We will need to do fixes in either #1 or #2. From a maintenance point of view it's better to put those fixes towards a version that has a reasonable chance of a release. (This does, of course, assume that V4 actually gets completed). At best the other providers get implemented and we have all of them available. At worst, we're stuck with sqlite for a while. If we really need mysql/postgres right away - it's going to involve significant work regardless of the option chosen. I would like postgres, but I would prefer a stable and supported library more in the long run even if it mean waiting longer. Use of a library attracts development of that library, I think if gnucash uses V4 it will be an extra reason for V4 to be maintained and supported. 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
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
Derek Atkins wrote: Hahahahahahaha!! Wow, now you're REAY funny! Have you forgotten that GnuCash is a Volunteer effort? *laughs* Users? Come across to Apache sometime. We take our users seriously over there. Last I checked Apache had a whole big funded foundation backing their development. Apples and kumquats, I'm afraid. Having been a member of the foundation for some time (you are using some of my code contributions to host your website), I can confirm to you that Apache doesn't take it's users seriously because of big funding (which Apache doesn't have), but because without users there would be zero point in writing the software at all. 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
Derek Atkins wrote: Hahahahahahaha!! Wow, now you're REAY funny! Have you forgotten that GnuCash is a Volunteer effort? *laughs* Users? Come across to Apache sometime. We take our users seriously over there. 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
Geert Janssens wrote: And I have been looking around, although I didn't migrate yet because of the huge effort it usually takes: there's * Compiere: it does ERP (enterprise resource planning), BPM (Business Project Management) and accounting. It's maintained by a company also called Compiere, the product is open source based, although it seems the company is heading to closing the source. That's why there is now a fork: * Adempiere: this is a fully open source fork of Compiere. It aims to remain as compatible with Compiere as possible, although it seems to merge some additional functionality not yet in Compiere, like Point-Of-Sales system, Manufacturing,... Both are (at least for me) very difficult to grasp. I managed to get them installed, but I never really managed to use them in a way that was useful. I tried to evaluate Compiere, and it failed the stability test - I didn't complete the install before I was running into baffling stacktraces left right and centre. What I am avoiding is the bloated we-try-do-everything software package, that takes forever to learn how to use, forever to fix when it breaks, and forever to pay off the huge bloated computer system required to run it. Instead, I am focusing on finding products that do one thing and do one thing well, and gnucash is an example of a product that does double entry accounting, and does it well. 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. But put it this way, Derek can throw as many tantrums as he likes, we plan to use gnucash to move from a small business to a big business (for now). :) 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: gnucash automation
Christian Stimming wrote: What the developers here mean by the gnucash API is all the source code that lives in src/engine/, also known as the engine here. Most of it is documented by doxygen comments in the source code. The source code in src/engine depends on glib, but it does not depend on gtk, which should underline the fact that this has nothing to do with GUI issues. The gnucash model of programming expects any non-GUI program to use the programming API that is offered by src/engine in order to open a gnucash data file, extract data from it, potentially modify its content, and maybe save it again. Does the API end up in a shared library that I can link to? 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: Another attempt to build gda-dev2
David Reiser wrote: One thing that will be a problem is that to build from svn, you need swig. Fink's swig (the guile parts, anyway) is based on guile 1.8, but there is no slib-guile for guile 1.8. What I did was to build my own version of swig in /opt, pointing it at guile 1.6 (via guile16-build configure, etc.). Hmmm - maybe I can cheat, and run autogen.sh on a Redhat machine, and then transfer the tree over to my mac with the autotools intact. However, you may want to wait a while. I haven't had good experiences with the gda-dev2 branch on my mac. It takes hours to convert a 3-year gnucash file, and I have yet to succeed at opening any file created by gda -- even a newly created file with a single transaction. I'm keen to take a look and see why. 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
Export QSF: Bus error
Hi all, While trying to run export QSF (for invoices), gnucash v2.2.4 bombs out with the bus error like so: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x0028 qof_begin_edit (inst=0x6bd1a30) at qofinstance.c:897 897 qofinstance.c: No such file or directory. in qofinstance.c (gdb) bt #0 qof_begin_edit (inst=0x6bd1a30) at qofinstance.c:897 #1 0x002ce92c in qofTransSetDescription (trans=0x6bd1a30, desc=0x648a970 Rackspace Managed Hosting) at Transaction.c:1417 #2 0x0022a5e4 in qof_instance_foreach_copy (data=0x331518, user_data=0xbfffddc8) at qofsession.c:436 #3 0x028a702c in g_slist_foreach () #4 0x0022afcc in qof_instance_copy_to_session (new_session=0x6c972b0, original=0x6bbf1d0) at qofsession.c:657 #5 0x0022b400 in recurse_ent_cb (ent=0x6be6080, user_data=0xbfffdf58) at qofsession.c:766 #6 0x0287f76c in g_hash_table_foreach () #7 0x00219b3c in qof_collection_foreach (col=0x0, cb_func=0, user_data=0x58) at qofid.c:359 #8 0x0022b628 in qof_instance_copy_coll_r (new_session=0x1, coll=0x6c3b260) at qofsession.c:820 #9 0x02d83264 in gnc_plugin_business_cmd_export_invoice (action=0x0, mw=0x0) at gnc-plugin-business.c:730 #10 0x0282a31c in g_closure_invoke () #11 0x0283b09c in signal_emit_unlocked_R () #12 0x0283c4c8 in g_signal_emit_valist () #13 0x0283c72c in g_signal_emit () #14 0x02143afc in gtk_action_activate () #15 0x0282a31c in g_closure_invoke () #16 0x0283b09c in signal_emit_unlocked_R () #17 0x0283c4c8 in g_signal_emit_valist () #18 0x0283c72c in g_signal_emit () #19 0x0239dbd0 in gtk_widget_activate () #20 0x02266618 in gtk_menu_shell_activate_item () #21 0x02266958 in gtk_menu_shell_button_release () #22 0x02251444 in _gtk_marshal_BOOLEAN__BOXED () #23 0x0282a31c in g_closure_invoke () #24 0x0283b2c0 in signal_emit_unlocked_R () #25 0x0283c528 in g_signal_emit_valist () #26 0x0283c72c in g_signal_emit () #27 0x02398200 in gtk_widget_event_internal () #28 0x0224e6dc in gtk_propagate_event () #29 0x0224f41c in gtk_main_do_event () #30 0x025642d0 in gdk_event_dispatch () #31 0x0288f714 in g_main_context_dispatch () #32 0x028912f0 in g_main_context_iterate () #33 0x028916ec in g_main_loop_run () #34 0x0224ea90 in gtk_main () #35 0x0103e504 in gnc_ui_start_event_loop () at gnc-gnome-utils.c:450 #36 0x302c in inner_main (closure=0x0, argc=0, argv=0x58) at gnucash-bin.c:489 #37 0x026b70d8 in scm_boot_guile (argc=0, argv=0x0, main_func=0x58, closure=0x) at init.c:635 #38 0x3888 in main (argc=2, argv=0xb624) at gnucash-bin.c:623 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
Another attempt to build gda-dev2
Hi all, Just tried again to build gda-dev2, and again I am stuck at autogen.sh. README.dependencies lists lots of dependencies for various Linux distros, but makes no mention of fink for MacOSX 10.4, which is what I am trying to build for. Following the various instructions from here http://wiki.gnucash.org/wiki/MacOSXInstallation#gnucash-2.2.x hasn't helped either, gnucash v2.2.4 works, which seems to be as far as the documentation has gone. I have just successfully built gnucash v2.2.4 from source using fink update, but something in gda-dev2 is either different or missing to gnucash 2.2.4. Does anyone know what magic dependency I am missing? machine-of-doom:~/src/gnucash/gda-dev2 minfrin$ ./autogen.sh Creating /po/POTFILES.in ... Creating /aclocal.m4 ... Running glib-gettextize --force --copy ... GnuCash note: Please ignore the output of glib-gettextize below! Copying file mkinstalldirs Copying file po/Makefile.in.in Please add the files codeset.m4 gettext.m4 glibc21.m4 iconv.m4 isc-posix.m4 lcmessage.m4 progtest.m4 from the /aclocal directory to your autoconf macro directory or directly to your aclocal.m4 file. You will also need config.guess and config.sub, which you can get from ftp://ftp.gnu.org/pub/gnu/config/. GnuCash note: Please ignore the output of glib-gettextize above! Ensure aclocal.m4 is writable ... Ensure po/POTFILES.in is writable ... Running intltoolize --force --copy ... You should update your 'aclocal.m4' by running aclocal. Running libtoolize --force --copy ... Running aclocal -I macros ... aclocal:configure.in:52: warning: macro `AM_GCONF_SOURCE_2' not found in library aclocal:configure.in:82: warning: macro `AM_GLIB_GNU_GETTEXT' not found in library aclocal:configure.in:230: warning: macro `AM_PATH_GLIB_2_0' not found in library Running autoheader... Running automake --add-missing --gnu ... src/business/business-gnome/schemas/Makefile.am:13: GCONF_SCHEMAS_INSTALL does not appear in AM_CONDITIONAL src/business/business-gnome/schemas/Makefile.am:19: GCONF_SCHEMAS_INSTALL does not appear in AM_CONDITIONAL src/gnome-utils/schemas/Makefile.am:13: GCONF_SCHEMAS_INSTALL does not appear in AM_CONDITIONAL src/gnome-utils/schemas/Makefile.am:19: GCONF_SCHEMAS_INSTALL does not appear in AM_CONDITIONAL src/gnome/schemas/Makefile.am:23: GCONF_SCHEMAS_INSTALL does not appear in AM_CONDITIONAL src/gnome/schemas/Makefile.am:29: GCONF_SCHEMAS_INSTALL does not appear in AM_CONDITIONAL src/import-export/hbci/schemas/Makefile.am:13: GCONF_SCHEMAS_INSTALL does not appear in AM_CONDITIONAL src/import-export/hbci/schemas/Makefile.am:19: GCONF_SCHEMAS_INSTALL does not appear in AM_CONDITIONAL src/import-export/qif-import/schemas/Makefile.am:13: GCONF_SCHEMAS_INSTALL does not appear in AM_CONDITIONAL src/import-export/qif-import/schemas/Makefile.am:19: GCONF_SCHEMAS_INSTALL does not appear in AM_CONDITIONAL src/import-export/schemas/Makefile.am:13: GCONF_SCHEMAS_INSTALL does not appear in AM_CONDITIONAL src/import-export/schemas/Makefile.am:19: GCONF_SCHEMAS_INSTALL does not appear in AM_CONDITIONAL **Error**: automake failed. 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 Missing records in SQLite
Derek Atkins wrote: Umm.. I can't imagine ANY workaround that gnucash would perform that would silently break with a gda upgrade. The biggest example is a workaround to escape strings not already escaped through the use of prepared statements. There is no reliable way to detect whether prepared statements are supported (apparently), so there would in turn not be a reliable way to detect whether or not the escaping workaround should be applied. If you apply escaping where it isn't required, you get corrupted strings. If you don't apply escaping where it is required, you get SQL insert failures. Oh, I'm all for getting gda fixed.. But there's a timing issue here. How long does it take to: 1) get GDA to fix the problem 2) get a new GDA release 3) get the new GDA release into the distributions? Significantly less time than: 1) User experiences sudden corruption of their gnucash file 2) User traces it back to a libgda upgrade 3) Get gnucash to remove the workaround 4) Get a new gnucash release 5) Get the new gnucash release into the distributions. Rather take longer and do it right, than be impatient and sow the seeds of angst, drama and future pain. 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 Missing records in SQLite
Derek Atkins wrote: Except SQLite is a requirement. If we can't support SQLite then IMNSHO the project has failed. So by that, if we have to make a workaround to get SQLite working, we should. Note that we can always key the workaround code based on the version of gda we find when we build gnucash. Then someone upgrades libgda, and gnucash silently breaks. If there are issues with libgda support with sqlite, I suggest fixing the issues in libgda. Short term hacks lead to long term pain. 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 Missing records in SQLite
Phil Longstaff wrote: The providers allow it, GDA allows it, but not all of the GDA providers use the facilities. I couldn't find any sqlite3_bind_xxx() calls in the GDA sqlite provider, for example. I agree that the gda backend should change to using the libgda parameter functions, but I shouldn't have to do that to work around this problem, which is a bug in libgda. We should be very careful of coding workarounds in gnucash to fix limitations in libgda. Time passes, libgda is fixed, and suddenly our fix becomes our bug. We should rather sanity check the backend when we start, to make sure that certain basic sane defaults are supported. For example, we might (and probably should) require prepared statement support. If prepared statement support is missing for that backend, that backend should be greyed out (with some hint to the user as to why). Then - as soon as libgda releases a backend that fits our requirements, gnucash suddenly supports that backend. This is significantly safer in the long term. 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 Missing records in SQLite
Phil Longstaff wrote: There is a function to query the backend to see what features it supports, but prepared statements is not in that list. Also, if we require prepared statements, that might cut out the sqlite backend because a libgda modification to use it might not propagate out far enough. I know Derek wants to see the xml gnucash file replaced by a sqlite db, so we need to be really sure it is unusable before we disqualify it. A quick Google search shows a number of references to prepared statement use in sqlite, which suggests to me that prepared statements are supported. Two things worry me at this point about the current behaviour of libgda: - Row inserts are failing, but the error is not communicated back to the caller. As a result, the database is corrupted in the process. - libgda doesn't seem to (yet) guarantee that prepared statements are used, and therefore that parameters do not need escaping. The data being saved is financial data, and people are using this data to file tax returns and various other mandatory stuff that could prove expensive if done incorrectly. Gnucash should be treating this data conservatively, and should only be using backends that can give some kind of certainty that data won't be corrupted for any reason. If we have to temporarily disable a backend until that backend works correctly, it is the safest thing to do, and offers an incentive to get the backend fixed. 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 Missing records in SQLite
Mark Johnson wrote: By examining which transactions, accounts, and splits were missing from SQLite (as compared to MySQL), I was able to determine that anything which had a single quote in a string (description, name, memo fields) failed to be inserted into SQLite. This is a one-to-one correspondence. i.e. anything that had a single quote failed. These were the only records missing as compared to MySql. At the moment, I am guessing that the SQLite provider does not properly escape such strings passed to it. If so, the SQL INSERT statements would be illegal and fail. (I've built just such a bug myself once using MySql.) More study of the SQLite provider is required. I did not find any existing bug reports regarding single quotes and the SQLite provider. If I can confirm my guess, I'll file the bug report. This sounds more like a symptom of not using prepared statements in sqlite. This could be a GDA problem, or it could be sqlite not supporting prepared statements. What is more worrying is that rows are being dropped and no error is being thrown. That looks to me like a more serious bug at this point, it means that strange data corruption errors are likely and the end user will never know. 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 save missing records
Mark Johnson wrote: Do we really want unlimited? I've alluded to this question in the past, but I don't know if there's been a definitive answer. Speaking for myself, I really want unlimited. As the accounting system is most often the system data is sent to, rather than originated from, it would cause all sorts of hassles if it turns out that the description on a transaction was arbitrarily truncated, or worse - the transaction was arbitrary ignored or dropped. I typically cut and paste full text strings from suppliers into invoice descriptions, and my suppliers are not limited by length, nor are their under any obligation to shorten their product descriptions if it causes hassles for me. This is a bit like the 640k is big enough for everybody story, it isn't. :( 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: Feature request from German list: Disable editing of transactions
Thilo Pfennig wrote: Maybe this is a misunderstanding but what I mean is that if I make an entry into the account bank I think this should still be visible, because only if it wont there would be an error. I think oen should distinct the real bank account and the bank account in GnuCash. Sure these two should match, but for GnuCash the authorative one should be the GnuCash bank account, shouldnt it? The authoritative account is the one that is considered right by an auditor, and that would be the bank statement, not the gnucash account. If tentries are falshe the user should correct them but this should be visible. For what purpose? The only thing an auditor is interested in is whether the account matches the bank statement. If the account contains a whole lot of extra entries that doesn't match the bank statement, that makes the auditor's life more difficult, and in turn you will get a bigger auditing bill at the end of the year [1]. It is only after the signoff / locking / reconcilation process that it becomes important to track changes, as this affects external procedures such as interim reporting and VAT returns. Of course if a user wants to implement an all accounts are locked policy, then they should be empowered to do so, but it certainly shouldn't be insisted on for everybody. [1] This I found first hand in a project, one of the basic requirements of the project was to reduce the auditing bill of the company concerned. If they are just editable without being visible this would make all accounts that interact with bank alsio being editable, because only if one can check both accounts for correctness one is able to make a statement about the overall correctness of the book keeping. At least thats what I learned. The problem is that you cannot make a statement about the overall correctness of a transaction until both sides have been reconciled, and that usually happens at different dates. It would be quite valid to lock the split in the bank account after the bank account was reconciled, but keep the option to move the opposite split elsewhere if it was determined that the amount had been allocated to the wrong place. Once it is allocated to the right place, the other side of the transaction is reconciled, and now both splits become locked. 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 save missing records
Keith Bellairs wrote: Speaking as a user and not someone busting his butt on this, I hate the idea of unlimited everything when we go to a DB. Most of our databases have a mechanism (BLOB/CLOB) to store really big things, usually at the cost of indexing or searching (other than with special hacks -- Oracle Text, for example). gnc is not, and should not be, a doc mgmt system. I want fast, fast retrieval and summarization. Having a place to store a reference to a doc is a great idea; plugging up the data with the docs, not so much. Of course, it is unforgiveable to just drop rows. Even silently truncating data is pretty dubious. Don't know Postgres and Mysql; can't we throw an exception so we have a chance to do the right thing (what the user needs)? I'd ask the developers to pick some reasonable size for each column. Then publish the schema. Granted this is a big change from the unlimited everything, but it seems necessary. If I don't like your column size, I should be able to ALTER TABLE and set my own favorites, so please do not hard-code the column sizes into the code. The problem with this is that it introduces inconsistency into the code. The XML backend has no concept of line lengths, and is so unlimited. The problem was originally found when an attempt was made to import this unlimited data into a limited system, such as the current DB system. Suddenly we have introduced the possibility that perfectly valid data in one backend is no longer valid in another. Add to that a user ability to change the line lengths and suddenly all bets are off. Fixed length string widths are an optimisation that helps if you are manipulating fixed length strings, but if you aren't - such as with a description in a register - the fixed length serves no purpose at all. As someone who spends a lot of time tracking down nasty problems in software, I can tell you that this is exactly one of those seemingly harmless issues that can cause some very difficult to find, and therefore very expensive bugs in systems. In this case, it was only found because mysql and postgresql have different behaviour when string lengths are too long, and that was found by a very lucky accident. 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: string lengths (was Re: GDA save missing records)
Phil Longstaff wrote: Well, as I originally said, I can use a TEXT type which allows up to 64K byte strings. Although not unlimited, I assume this is long enough for everyone's purposes. MySQL stores them as 2byte length + chars. I will need to check that that libgda has some good method of creating them. Of course, I could also just try varchar(2048) instead of varchar(50), which should also be sufficient. I assume that the db tries to optimize space so that storing a 1000 char string and storing a 1 char string in a varchar(2048) don't use the same amount of space. Generally, the database doesn't do this - it will allocate 2048 chars, whether you use 1 char or 1000. The upside of this is that it is very quick, the downside is that it wastes a lot of space. Unlimited or large text strings are optimised, only because they have to be to be stored practically. 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: string lengths (was Re: GDA save missing records)
Keith Bellairs wrote: I think that depends on the DB. Using VARCHAR at least gives the engine a chance to optimize storage. CHAR is good for truly fixed length strings. This is true, I mixed up the varchar with the char. Adding a limit to varchar is entirely arbitrary though, if the varchar can support a 2 byte string length, then why not choose the biggest size available? 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: Feature request from German list: Disable editing of transactions
Christian Stimming wrote: Makes sense, but do you have any ideas how such a per-account setting can be implemented in the GUI? Currently, all per-account settings can be set in the Edit Account dialog. However, a setting Make this an inalterable account shouldn't be allowed to be disabled again in the GUI, as this would make the whole setting moot. Do you think the Edit Account dialog should get a button to enable that behaviour? Or do you think this should somehow show up in the Create New File wizard? Both would require GUI actions of a kind that are not yet implemented there. This starts gnucash down the road of having the concept of users, and users having some kind of access level. For example the admin user can log in, and set these kinds of parameters, while a normal user cannot. This isn't a bad thing, but do we want to bite off and chew on so much of the problem at once? There are other parameters other than a lock-date that you would also need to protect from modification, such as the currency of the account, and other metadata. Also, from an implementation point of view it's not clear to me which kind of editing should be allowed for transactions that contain one split in an inalterable account and another one in an editable account. Some fields like the transaction date are a per-transaction field (as opposed to per-split) - should those fields be allowed to be edited or not? I'd say any split in an unalterable account should be unalterable, while any split in an alterable account should remain alterable. For example, if you raise an invoice, you end up with splits in income - sales (unalterable), and accounts receivable (alterable). The transaction has to balance to zero, otherwise the edit won't be allowed to complete. 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: Feature request from German list: Disable editing of transactions
Thilo Pfennig wrote: I think from the acounting perspective every entry consists on som field like the date, the accounts, some text,... I also dont think a mix of inalterable accounts and alterable accounts makes much sense because every entry has two ends, so if one end is inalterable the other one has to be, too. This isn't true - each entry can have more than two ends in the form of splits, the only requirement is that all the splits add up to zero. An example of where one split remaining alterable becomes important is when one side of the split goes to income - sales (for example), and the other side goes to bank account. Gnucash isn't the authoritative source for bank account information (the bank is) and therefore it should remain editable until the bank statement is reconciled, but gnucash is the authoritative source for sales. So it must remain possible to allocate the bank split to say petty cash or overs and unders if a mistake was found. Of course if the end user wanted gnucash to treat the bank account as uneditable, nothing stops the user from locking both the bank account and the sales account. I have the strong feeling that different views would help. So that one can look at all without correcting entries. My guess is that it would be better if all new files where made in the same way but that the view could be changed (default view / strict accounting view or so). I designed a system for an insurance company that worked somewhat like this. Any invoice they raised could be corrected, but this was implemented by automatically reversing out the old entry, and creating a new one. The reversal and the original entry reversed were linked together. This allowed them to view their accounts minus the reversals, while their auditors would view the accounts with the reversals and so have full visibility of what happened. To implement this, you would just need to provide a right-click menu option reverse this transaction, which would add a mirrored version of the transaction for you. This wouldn't be a solution for everyone though, I certainly wouldn't want that on any accounts I was not authoritative for. Keeping it configurable would be important. 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: Feature request from German list: Disable editing of transactions
Christian Stimming wrote: Some German business users brought up a feature request that sounds a bit weird for a programmer: They asked for a gnucash mode of operation where the user can not edit older transactions anymore! Makes perfect sense - wearing my programmer hat on financial systems, making it hard to change historical data is a normal part of financial systems. I'm still not completely sure how the actual implementation would look like. The simplest way to implement this is to define a date: transactions before this date become read only, and it becomes impossible to enter transactions before this date as well. This is enforced by the gui. This date might be set to a fixed point in time, for example to end of the previous tax year - transactions from this year (or this month) can be edited, but not last year. The date would be set when the accountant signs off the tax return, or when a month is signed off and closed. Or, the date might be set to a floating date, such as t-1 (yesterday), ie transactions can only be created today onwards. This would provide a significantly stricter environment, where all incorrect transactions would be forced to be reversed and recreated. You would definitely want to set this per account, because some accounts in gnucash are authoritative (eg accounts dealing with the issuing of invoices), but other accounts track some external account source, such as a bank account. It would be pretty useless if you were prevented from correcting errors while reconciling a bank account. As to trying to go as far as preventing people from modifying the data file and cook the books, that is outside the scope of gnucash, just as it is out of scope of any accounting program. This is easily prevented by taking snapshots of the accounting over time, making it very difficult to hide an attempt to make an unauthorised entry. I use subversion for this (the gnucash source file is checked into source control), but writing the files to read-only DVD or CD solves this problem. 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: empty PostgreSQL table failed workaround
Derek Atkins wrote: I think the question was more: Does every table have to HAVE a primary key? Yes, the primary key must be unique, but what if a table has no primary key? Is that still okay? It's perfectly ok, yes - but primary keys are used heavily for optimisation. Without them, performance will suffer, particularly while generating reports. 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 referential integrity
Mark Johnson wrote: This would certainly cause very slow performance. Here are some sample table sizes to give you an idea of how much data I have in gnucash. I don't think it is especially large. I have seen some users post who have quite a few more years of data in gnucash than I. I suspect this is more a UI problem than a backend problem: the backend is slow, and isn't going to (practically) get any faster, meaning the user must the given some kind of cue that this a) might take a long time, and b) will only take a long time, the first time. Perhaps some kind export wizard idea might work, in other words, if you loaded your data using backend X, under normal circumstances, gnucash will save to backend X. If you loaded your data with backend X, but wanted to save it as backend Y, you would need to select a separate save option (called export?), which would have a progress bar, and would otherwise signal to the user that this is once off and may take a while, and most importantly, gnucash hasn't hung. This will also simplify potential confusion when the user is given lots of options when they click on save. Running further with the idea, save might mean commit any unsaved changes. In the XML world, this means the XML file will be saved in full. In the database world, a long running transaction might be committed. Obviously in the database world, if long running transactions are a bad idea or aren't supported, save could just be greyed out. 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: Building GnuCash 2.2.2 on Mac OS X without Fink or MacPorts
Jeshua Lacock wrote: We have thousands of users and no one has ever reported a problem using /tmp with various binaries. /tmp means exactly what it says on the tin: It's temporary. Don't put anything in /tmp that a user might expect to be permanent. 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: r16624 - gnucash/trunk - Remove the spurious m4/ directory. Use macros/ instead.
Christian Stimming [EMAIL PROTECTED] writes: The whole point of cmake is that it will perform all those platform-checks (more precisely: host and target checks) which used to be done by the autoconf-generated shell scripts which nobody was able to understand. But the price for this is that cmake is required to be installed on the host. I am with Derek on this one. Autoconf is mature, works on a long list of platforms, and does the job. What will cmake do, apart from restrict the build to fewer systems? 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: r16624 - gnucash/trunk - Remove the spurious m4/ directory. Use macros/ instead.
Christian Stimming wrote: I'm sorry, but the last part is some FUD that doesn't need to be redistributed any further. The KDE project explicitly states that already very early into the migration to cmake, it built on more platforms than it ever did with autotools. What kind of adoption does cmake have outside of KDE? Eg Gnome, Windows, MacOSX, etc? 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: The payment amount must be greater than zero
On Mon, August 20, 2007 4:36 pm, Derek Atkins wrote: See, this is where you're not quite right. Gnucash really is a little schizophrenic here; it's not sure if it wants to be a Personal finance program or a Small Business finance program. It's really trying to be both. It's NOT trying to transition to being ONLY a business finance program. There is no reason why Gnucash cannot be both a personal finance program or a small business program at the same time, there is very little difference between the two. Having said that; the business features SHOULD be better; but I have no time to work on them and nobody else has really come forward to spend the many man-months of effort required to bring it up to snuff. But no, as a whole, I cannot say that gnucash is transitioning as you suggest it is. Sorry. My concern is that having spent the many man months of effort, will patches be considered? Gnucash is probably one of the best candidates out there to become a proper business accounting application with a few fixes here and there. What worries me is that when these issues are brought up, invariably someone infers the problem cannot be fixed or solved. Regards, Graham -- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: The payment amount must be greater than zero
Nigel Titley wrote: He does have a point though. Feature enhancements take time. None of us have enough time. Neither do the people who need the features, which is why the very first step is to ensure that no time is wasted - by asking the list whether there is a well understood reason for something being as it is, and whether there is a recommended approach to fix it. There seems to be a perception that every new question on the list is inherently a request for the core developers to do work - this is not the case. The information that core developers give out ultimately expands the core development team, and benefits the project as a whole. 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
The payment amount must be greater than zero
Hi all, I have been trying to make a note of a refund paid back from a vendor, and am trying to make a payment with a negative amount, but I get the error message: you must enter the amount of the payment. The payment amount must be greater than zero If you can't add a refund this way, is there an alternative way that should be used to note a refund? I am using v2.2.0. 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: The payment amount must be greater than zero
Derek Atkins wrote: Create a new Vendor Bill; or unpost the previous vendor bill and put it there. At this point in time GnuCash does not support Credit memos (I guess this would be a Debit memo from a vendor). In this case, the vendor credited an invoice on a credit card, so unposting the previous vendor bill won't work as the credit card statement won't match. It looks like the easiest way to support credit momos, is to just remove the error message. 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: The payment amount must be greater than zero
Derek Atkins wrote: Unfortunately it's not THAT simple. From the UI, yes, but there are underlying assumptions that the UI is helping enforce. Entering a negative amount would break those underlying assumptions. What underlying assumptions? All cashflows can flow in either direction for any number of reasons, the software shouldn't stop figures being negative, that's the user's job, should the user choose to. 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: Customer payments not working in v2.0.5
On Fri, August 3, 2007 5:17 pm, Derek Atkins wrote: If it's been working for the last five years then what changed between the last time it worked and the when it stopped working? What caused the problem was a change made 3 months ago when I started a new business in a new country. The problem was subtle - the transactions made since the change three months ago, some of them were silently incorrect when you looked at the data file, but still worked. I think the vector that caused the problem to become visible was when a customer was added after the currency change from 3 months ago. As soon as an invoice was raised from this particular customer, the problem started. Most of the invoices raised are from long running customers. This implies, to me, that the Customer's Currency configuration is wrong. I bet you have it set to Locale Currency instead of specifying one. Quite possibly - the principle of least astonishment would dictate that when you enter the amount of money in the customer payment dialog, that it would be prefixed with the customer's currency so that this is clear. Right now, if the currency is wrong, the register fields become blanked out, and the end user is given no clue as to what is wrong. The plot thickens... looking inside the XML of the gnucash data file, it looks like gnucash has been ignoring the currencies on each register, and instead been using the the gnucash-wide currency for transactions. Sorry, but that's incorrect. Transactions entered through a currency- based register will use that currency. Transactions entered through a STOCK or MUTUAL register (or the GL) will use the locale currency. How do you enter your transactions? The problems are happening when you raise an invoice, and when you try and pay for an invoice using customer payment. The general ledger works fine. This particular gnucash is responsible for loading two xac files, one in one currency, and a second xac file in another currency, but this should not make any difference to the xac files themselves - it seems they do. Data files don't have an inherent currency, so saying one in one currency and one in another is wrong on many levels. So the real problem is that data file has no inherent currency, but instead relies on the currency that may or may not be present on gnucash installation where the file was opened. In order to be accurate, gnucash needs to rely on a well defined currency, not the currency that happens to be the locale currency on a particular installation. I suspect what is happening is that when the certain transactions are created, the currency of the transaction is being taken from the default currency, instead of the register currency. This is true. There ARE certain cases where it uses the locale currency. In particular: Stock, Mutual, and GL registers, and when configured to do so in the business features. Also keep in mind that many of the currency configurations are stored in GCONF and not in your data file or data metadata file, so things like Report Currency dont stay with the data file. This is definitely broken - an accounting system needs to be repeatable. Regards, Graham -- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Customer payments not working in v2.0.5
Hi all, Out of the blue, I have been having a problem with customer process payments with v2.0.5. Attempts to add a payment causes a transaction to be created, but the value on the transaction stays blank. This is regardless of what you type as the value when creating the payment, and it is regardless of any attempt to change the values in the transaction in the register. Deleting the transaction and trying again results in the same problem. Has anybody seen this problem before? So far it looks like development on the v2.0.x branch has been ended, but the only version of v2.2.x available is v2.2.0, and this isn't backwards compatible. Just how safe is it to upgrade at this point? 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
