[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: Announcement: GnuCash 2.6.0 Released
On 31 Dec 2013, at 8:54 AM, Graham Leggett 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 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: cmd line: import of transactions and invoice data
On 01 Jan 2014, at 7:25 PM, John Ralls 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: 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: 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
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: 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
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: 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
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: Credit notes
On 30 Aug 2012, at 18:35, Geert Janssens 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
Re: GnuCash XML spec (for non-C languages?)
On 05 Nov 2012, at 9:58 AM, Colin Law 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: GnuCash XML spec (for non-C languages?)
On 06 Nov 2012, at 12:22 PM, Christian Stimming 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" 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 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: Recommend IDE for coding in "C"
On 20 Mar 2013, at 7:13 PM, Buddha Buck 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: Approval for Introducing Your Software in Japanese PC magazine
On 28 Apr 2013, at 04:45, John Ralls 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: Base And Gnucash
On 29 Apr 2013, at 7:28 PM, John Ralls 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: Bug 336843 - Attach files to Transactions
On 14 Nov 2013, at 7:17 AM, David Carlson 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: Announcement: GnuCash 2.6.0 Released
On 30 Dec 2013, at 5:22 PM, John Ralls 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 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 e
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: 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: 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
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: 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
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: 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: 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 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: 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
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: 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
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: 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: Un-reconciling - how?
Dave Peticolas wrote: > > I am currently in danger of developing advanced RSI trying to fix this > > error - is there a way of switching off the annoying dialog box? It > > should have at least a checkbox on it saying "do not warn me again". > > Sorry, there is no way to turn off the message. But we will add that > to 1.5.x. One bug that makes this problem worse is that when the "yes" option is highlighted as being the default enter selectable key, enter selects cancel instead. This means I have to actually click on yes (1000 times), instead of being able to just hit enter... :( Regards, Graham -- - [EMAIL PROTECTED]"There's a moon over Bourbon Street tonight..." ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Un-reconciling - how?
Hi all, I have a need to cancel all reconciled flags on an account full of transactions (there's an error in there, no I cannot find it, it's quicker to reconcile from scratch). The trouble is that gnucash is hell bent on trying to stop me from doing this - popping up an annoying warning dialog every time I click on the "Y", which I then need to click on, followed by a "this transaction has been changed, yes, no, cancel" message which I need to click on again. I am currently in danger of developing advanced RSI trying to fix this error - is there a way of switching off the annoying dialog box? It should have at least a checkbox on it saying "do not warn me again". Regards, Graham -- - [EMAIL PROTECTED]"There's a moon over Bourbon Street tonight..." ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
New bill crash in gnucash v2.0.5
Hi all, I reported a crash in January where it was not possible to create a new bill with gnucash v2.0.4 on MacOSX Intel (latest version) - I have just tried to upgrade to v2.0.5, and the problem is still there. This time round I have managed to get a proper backtrace out of it, which is included below. I have also managed to create a screenshot of what the gnucash screen looks like when the crash happens. To replicate the problem, try to create a new bill in a mostly empty datafile. After selecting a vendor, gnucash tries to render the new bill window, and at this point it crashes. Any ideas? Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x0004 0x0108b6a4 in uta_union_clip () (gdb) bt #0 0x0108b6a4 in uta_union_clip () #1 0x010905ec in gnome_canvas_request_redraw_uta () #2 0x01090787 in gnome_canvas_expose () #3 0x017d9fdf in _gtk_marshal_BOOLEAN__BOXED () #4 0x01f15bd3 in g_closure_invoke () #5 0x01f269f2 in signal_emit_unlocked_R () #6 0x01f27de7 in g_signal_emit_valist () #7 0x01f2874a in g_signal_emit () #8 0x0190c347 in gtk_widget_event_internal () #9 0x017d8373 in gtk_main_do_event () #10 0x01a9a620 in gdk_window_process_updates_internal () #11 0x01a9a6f0 in gdk_window_process_all_updates () #12 0x0192003e in gtk_window_check_resize () #13 0x01f15bd3 in g_closure_invoke () #14 0x01f269f2 in signal_emit_unlocked_R () #15 0x01f2806e in g_signal_emit_valist () #16 0x01f2874a in g_signal_emit () #17 0x017332b7 in gtk_container_idle_sizer () #18 0x01f83138 in g_main_context_dispatch () #19 0x01f8394b in g_main_context_iterate () #20 0x01f83cd2 in g_main_loop_run () #21 0x017d7c90 in gtk_main () #22 0x0031480c in gnc_ui_start_event_loop () #23 0x346e in inner_main () #24 0x01db0087 in scm_boot_guile (argc=1, argv=0xb970, main_func=0x32e1 , closure=0x0) at init.c:635 #25 0x3614 in main () (gdb) 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 bill crash in gnucash v2.0.5
Derek Atkins wrote: I haven't been able to reproduce this on my Linux system. I'm wondering if it's a MacIntel issue or a broken dependency or some issue with a particular dependent library? Are you using fink or MacPorts? I'm using fink and the instructions at http://captnswing.net/2006/07/10/gnucash20_on_intel_macs.html. I tried to do fink -y update-all; but there have been no updates for a while 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: New bill crash in gnucash v2.0.5
David Reiser wrote: If you're willing to try the whole fink route, 2.0.5 went up a day or two ago. For that you would have to use 'fink install gnucash2' Neither I nor the dev checking my packaging has an intel mac, however. Let me try this, will report back if I have some success. 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 bill crash in gnucash v2.0.5
David Reiser wrote: If you're willing to try the whole fink route, 2.0.5 went up a day or two ago. For that you would have to use 'fink install gnucash2' Neither I nor the dev checking my packaging has an intel mac, however. After lots of fighting with it (fink seems to have quite a few dependency problems) I managed to get fink update-all to run to completion - and now gnucash works. This also confirms, this was on an Intel Mac. 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 bill crash in gnucash v2.0.5
On Mon, March 5, 2007 3:02 pm, Derek Atkins wrote: > Just to confirm what you're saying, after upgrading to 2.0.5 > you no longer see the crash, right? No, after upgrading all the fink packages I no longer see the crash. In other words, if people are to use gnucash under fink, fink needs to be fully up to date. This can be difficult to achieve, as some of the packages in the fink archive are broken / missing - it was quite a song and dance to get everything upgraded. Regards, Graham -- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Gnucash v2.0.5 on Fink - Printing blank invoices
Hi all, Having just installed a completely new installation of fink, followed by "fink install gnucash2", I now have gnucash v2.0.5 installed on MacosX 10.4.9. Unfortunately, any attempt at printing results in a blank page - the lines making up the invoice table appear, and if the technicolour style is selected the yellow backgrounds appear, but no text is visible on the page. Has anyone else seen this problem before, and found any solution? Regards, Graham -- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [dev] Gnucash v2.0.5 on Fink - Printing blank invoices
On Thu, May 17, 2007 4:37 pm, Ariel wrote: > No direct answer for you, but try exporting the report, and printing from > a web browser. You can also edit if necessary in any HTML editor. That was plan B. Unfortunately the HTML export doesn't seem to export any stylesheet information associated with the report, so you get the barebones information, but nothing that you would want to give a customer unfortunately :( Regards, Graham -- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash v2.0.5 on Fink - Printing blank invoices
On Thu, May 17, 2007 4:48 pm, Ariel wrote: > If I'm not mistaken gnucash does not have any stylesheets with reports. So > you are not missing anything - does the export look very different from > what shows up on the screen? Very different, yes. Without a stylesheet, the browser places all the information one item below the other, running down the left of the screen. As a result, it is not clear from reading the invoice which party was the supplier, and to which party were the goods supplied. > Don't forget you can make your own stylesheet. The exported html has no stylesheet line in the HEAD section, meaning that any stylesheet you apply involves manually editing the exported invoice html by hand. I could make the manual changes, but the end game of this process is for my accountant to generate invoices, and my accountant doesn't know html, nor do they want to. Regards, Graham -- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash v2.0.5 on Fink - Printing blank invoices
On Thu, May 17, 2007 5:17 pm, [EMAIL PROTECTED] wrote: > That's a different problem. GktHTML doesn't properly export the > 'align' tags. This is a known bug in GtkHTML but there's no workaround. I remember having this problem in the v1.8 series, this bug has been around for a very long time - is GtkHTML still being maintained? > You're thinking "CSS" Stylesheets, which is NOT what's going on. The > "Stylesheet" isn't CSS based, it's something internal to gnucash, and > it just defines how the HTML gets formed.GtkHTML doesn't support > CSS. Ok, that is making more sense. Internal to gnucash, what is the representation that is used to render and display (and print) the reports? Is this all GtkHTML or something else in addition to it? The question I am leading on to is whether there is a more recent HTML library that supports modern HTML standards that might be used instead - I am willing to get my hands dirty in the code, but I will need some guidance on what the solution should be first. Regards, Graham -- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash v2.0.5 on Fink - Printing blank invoices
On Thu, May 17, 2007 6:00 pm, Derek Atkins wrote: > Well... There are the scheme reports which form a scheme structure > that uses the stylesheets to convert everything into HTML. This HTML > is then fed into GtkHTML for display. GnuCash also adds hooks to > GtkHTML to handle the GoG images and back-calls for things like > opening up account registers or looking at invoices by clicking on > hyperlinks in reports. Ok, makes sense. > Well... We've discussed other options. One potential approach is to > change out GtkHTML for something like Gecko. Granted, this would add > a build dependency on Mozilla, which might suck for those building > from sources.. But it's at least something to think about as an > option. I have no idea how that would affect building on Win32 or > Mac. But if you want to look into that (or other HTML renderers), I'd > certainly encourage you! As would other devs! :) Some introductory digging has uncovered GtkMozEmbed which looks promising: http://www.mozilla.org/unix/gtk-embedding.html Regards, Graham -- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Major timezone breakage
Hi all, Having recently moved from ZA to the UK, I changed the timezone on my laptop to match, moving the timezone back by 1 hour. All of a sudden, all the dates in my gnucash files were out by one day - invoices dated 1 March were now dated 28 February, which is in the previous VAT period and tax year. Moving the timezone back to ZA and forward an hour suddenly fixed things - except for recent transactions, where there is now a confusion of dates in GMT, GMT+1 and GMT+2. Looking inside the xac file, it looks like the timezones are not normalised before being saved: 2006-06-29 23:00:00 +0100 2007-02-20 21:44:24 + Is this a known problem? Is there a straightforward fix for 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
Segfault in customer report on v2.0.5
Hi all, I have found a segfault in gnucash v2.0.5. When you select reports -> business -> customer report, and fill in the various details of which customer to report on, gnucash segfaults. It doesn't do it all the time, but does quite often. The backtrace is below. #0 gw__tmp438_xaccQueryAddGUIDMatchGL_wrapper (gw__scm_arg0=0xa, gw__scm_arg1=0x261d00c, gw__scm_arg2=0x60a78b8, gw__scm_arg3=0x55fc970) at gw-engine.c:17604 #1 0x025acb24 in scm_dapply (proc=0x55a9320, arg1=0x56dc770, args=0x85288b13) at eval.c:3576 #2 0x025abbe8 in scm_deval (x=0x5f3a708, env=0x60a78a8) at eval.c:3042 #3 0x025a8748 in scm_deval (x=0x587ae88, env=0x60a78a8) at eval.c:2017 #4 0x025a8748 in scm_deval (x=0x5f413d8, env=0x60a7a38) at eval.c:2017 #5 0x025a8748 in scm_deval (x=0x584a558, env=0x60a7a38) at eval.c:2017 #6 0x025a92cc in scm_deval (x=0x57621a8, env=0x60a5950) at eval.c:2192 #7 0x025a94d4 in scm_deval (x=0x5fd3688, env=0x60a5be8) at eval.c:2242 #8 0x025a8748 in scm_deval (x=0x5fd37b8, env=0x60a5be8) at eval.c:2017 #9 0x025a94d4 in scm_deval (x=0x575e7b0, env=0x60a5d38) at eval.c:2242 #10 0x025ace24 in scm_dapply (proc=0x60a5dd0, arg1=0x60a5d78, args=0x85288b13) at eval.c:3655 #11 0x025f37f8 in scm_internal_lazy_catch (tag=0x3050800, body=0x25f38c0 , body_data=0xbfffa9b8, handler=0xd, handler_data=0x2b74) at throw.c:281 #12 0x025f3cd8 in scm_lazy_catch (key=0xd, thunk=0x300ac00, handler=0x60a5e60) at throw.c:578 #13 0x025ac028 in scm_deval (x=0x5739648, env=0x60a5de0) at eval.c:3106 #14 0x025ace24 in scm_dapply (proc=0x60a5e40, arg1=0x60a5de0, args=0x85288b13) at eval.c:3655 #15 0x025f3664 in scm_internal_catch (tag=0x3050800, body=0x25f38c0 , body_data=0xbfffaf18, handler=0x25f38d0 , handler_data=0xbfffaf60) at throw.c:205 #16 0x025f3c38 in scm_catch (key=0xd, thunk=0x300ac00, handler=0x60a5e20) at throw.c:549 #17 0x025ac028 in scm_deval (x=0x57396e0, env=0x60a5e68) at eval.c:3106 #18 0x025a8748 in scm_deval (x=0x5fd3e78, env=0x60a5eb8) at eval.c:2017 #19 0x025f13d4 in inner_eval_string (data=0x60a5f68) at strports.c:484 #20 0x025b40ac in scm_c_with_fluids (fluids=0x60a5f60, values=0x60a5f58, cproc=0x25f13b0 , cdata=0x60a5f68) at fluids.c:243 #21 0x025f37f8 in scm_internal_lazy_catch (tag=0x3050800, body=0x6cadb0 , body_data=0x76be590, handler=0xd, handler_data=0x2b74) at throw.c:281 #22 0x025f3664 in scm_internal_catch (tag=0x3050800, body=0x25f3840 , body_data=0xbfffb5f8, handler=0x6cac40 , handler_data=0xbfffb658) at throw.c:205 #23 0x025f38a4 in scm_internal_stack_catch (tag=0x85288b13, body=0x48, body_data=0x4, handler=0xd, handler_data=0x2b74) at throw.c:330 #24 0x006cae04 in gfec_eval_string (str=0x4 , error_handler=0xd8a0 ) at gfec.c:105 #25 0xd934 in gnc_run_report (report_id=-2060940525, data=0xbfffb7c8) at gnc-report.c:146 #26 0xda7c in gnc_run_report_id_string (id_string=0x74caf40 "id=6", data=0xbfffb7c8) at gnc-report.c:172 #27 0x005ce4e4 in gnc_html_report_stream_cb (location=0x85288b13 , data=0xbfffb7c8, len=0xbfffb7cc) at window-report.c:212 #28 0x0103f050 in gnc_html_load_to_stream (html=0x74c5580, handle=0x76af4d0, type=0x108bfb4 "report", location=0x74caf40 "id=6", label=0x0) at gnc-html.c:571 #29 0x0103ff70 in gnc_html_show_url (html=0x74c5580, type=0x74caf40 "id=6", location=0x0, label=0x0, new_window_hint=106475856) at gnc-html.c:1033 #30 0x005cb778 in gnc_plugin_page_report_expose_event_cb (unused=0x85288b13, unused1=0x48, data=0x4) at gnc-plugin-page-report.c:618 #31 0x0215a444 in _gtk_marshal_BOOLEAN__BOXED () #32 0x0273931c in g_closure_invoke () #33 0x0274a09c in signal_emit_unlocked_R () #34 0x0274b528 in g_signal_emit_valist () #35 0x0274b72c in g_signal_emit () #36 0x022a1200 in gtk_widget_event_internal () #37 0x020ac1e0 in gtk_container_propagate_expose () #38 0x0217e19c in gtk_notebook_expose () #39 0x0215a444 in _gtk_marshal_BOOLEAN__BOXED () #40 0x0273931c in g_closure_invoke () #41 0x0274a2c0 in signal_emit_unlocked_R () #42 0x0274b528 in g_signal_emit_valist () #43 0x0274b72c in g_signal_emit () #44 0x022a1200 in gtk_widget_event_internal () #45 0x020ac1e0 in gtk_container_propagate_expose () #46 0x020570b8 in gtk_box_forall () #47 0x020aae60 in gtk_container_expose () #48 0x0215a444 in _gtk_marshal_BOOLEAN__BOXED () #49 0x0273931c in g_closure_invoke () #50 0x0274a2c0 in signal_emit_unlocked_R () #51 0x0274b528 in g_signal_emit_valist () #52 0x0274b72c in g_signal_emit () #53 0x022a1200 in gtk_widget_event_internal () #54 0x020ac1e0 in gtk_container_propagate_expose () #55 0x020aae60 in gtk_container_expose () #56 0x0215a444 in _gtk_marshal_BOOLEAN__BOXED () #57 0x0273931c in g_closure_invoke () #58 0x0274a2c0 in signal_emit_unlocked_R () #59 0x0274b528 in g_signal_emit_valist () #60 0x0274b72c in g_signal_emit () #61 0x022a1200 in gtk_widget_event_internal () #62 0x0215838c in gtk_main_do_event () #63 0x02451b94 in gdk_window_process_updates_internal () #64 0x02451c88 in gdk_window_process_all_updates () #65 0x02451d2c in gdk_w
Special version of automake required?
Hi all, I just tried to run autogen.sh to build the gda-dev tree, and I got the errors below. Is there a specific version of automake / autoconf needed to build gnucash? Machine-Of-Doom:~/src/gnucash/gda-dev 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:51: warning: macro `AM_GCONF_SOURCE_2' not found in library aclocal:configure.in:81: warning: macro `AM_GLIB_GNU_GETTEXT' not found in library aclocal:configure.in:229: 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/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: Special version of automake required?
Derek Atkins wrote: Running aclocal -I macros ... aclocal:configure.in:51: warning: macro `AM_GCONF_SOURCE_2' not found in library aclocal:configure.in:81: warning: macro `AM_GLIB_GNU_GETTEXT' not found in library aclocal:configure.in:229: warning: macro `AM_PATH_GLIB_2_0' not found in library This implies you don't have GCONF, GLIB, and GLIB-GETTEXT installed so aclocal can't find the associated macros. Please read README.dependencies I am trying to build against fink, which is not listed in README.dependencies. Gnucash v2.0.5 was installed from source on this machine, so I am struggling to figure out why this tree doesn't work when gnucash v2.0.5 did. All of glib, glib2, gconf and gconf2 are installed, with their corresponding dev packages. Does anyone know specifically which packages the above messages refer 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
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
Re: Customer payments not working in v2.0.5
Derek Atkins wrote: Sounds like a Currency issue.. Make sure all the currencies are correct and THE SAME! Yes, all the currencies are the same, as they have been for the last 5 years. Digging further, it looks like an invoice belonging to the same customer is also showing up with blank values in the register. In the customer report, the values show up - with the correct currency and value. In the register, which has the same currency, the values are blank. 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. 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. 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. 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
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: 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
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: 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: 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: 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: 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: 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: 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: 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 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
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
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
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
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
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
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: 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
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: 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: 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: 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 ? 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: 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: 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
