Concurrent multi-user support has been part of our long-term goals for a while now:
Time to update the status of this feature request…
Note it still says “long-term”, which currently means several years ahead of us.
I would agree that such "feature" will make us see GnuCash 3. Current code base clearly had no intention to become multi-user system. But I will agree with OP also: this feature is REQUIRED for GnuCash to move onto serious business scene.
My business is small but I'd like to have GnuCash running on my notebook and on my desktop in the office simultaneously. I found it relatively simple: as I am only user I can reload book from open DB over VPN and ignore warning that DB is already open. So it does the job but if I have someone else working on the same DB in my office it may throw things out of balance quickly and may be even corrupt DB.
Something tells me that POS is beyond scope of GnuCash. I run small online retail myself and have PHP script which acts as GnuCash to modify MySQL DB directly. Works for me. All I need to do is to reload GnuCash each time I need to get my teeth into book keeping: GnuCash does not have any way to detect that MySQL DB was modified externally.
So in the end it calls for multi-user editing of DB where one of the users is POS system.
Well, it does. But as I commented in mini-inventory suggestion GnuCash has all necessary data structures and so fixed asset management may be relatively easily implemented.
Even without fixed asset management subsystem depreciation schedules still have a place in GnuCash.Vladimir Bashkirtsev shared this idea ·
I’m reopening this feature request because currently it’s not possible to attach items to an invoice. It’s only possible to attach items to regular transactions (not associated with invoices/bills).
This as a separate corresponding bugzilla item: https://bugzilla.gnome.org/show_bug.cgi?id=735408
You think? To me both of these approaches are the same: just consider DB table which will hold BLOBs as file system (actually a subdirectory where images are held). So if XML file is open call to fetch an image will load file <invoice_guid> from BookName-Images directory, if DB is open image will load from "SELECT image FROM images WHERE guid = <invoice_guid>".
Clearly file system is not the best way to keep images as XML file itself may be easily parted with corresponding images and so relevant check is needed: if image cannot be loaded then image GUID in invoice record should be cleared. In case of DB parting of data and images is unlikely but such check still should happen.
In both cases images should be loaded on demand - not the same way as with data where whole DB or XML is loaded on start.
Actually I am more concerned with "how to get images into GnuCash". Under Linux it is extremely simple with sane. I have tried sane under Windows quite some time ago and it was not doing well. But I think it is relatively easy to make GnuCash to be platform independent sane client. Under Windows TWAIN prevails still but in reality I do not see how to get it to GnuCash nicely. So for Windows users it may be an option to get something like Twain2Sane and then configure GnuCash sane client to pickup images from local sane source.
Of course we can have a "pick file" dialog to get pre-scanned image file attached to the invoice but it is quite inconvenient: put paper invoice in the scanner, run program XYZ to scan an image, store image in the temporary location, open GnuCash, open "pick file" dialog, find file, select, click OK, don't forget to delete file from temporary location. Much easier just to have a button which will execute sane scan from pre-selected sane source directly from GnuCash and then stick resulting image into file system or DB. However option to attach image through dialog should exist as well as sometimes invoices do come by email as scanned images.
Fairly easy: generate document GUID and save image alongside with xml file. Obviously images should be copied along for backup. When reading files if no file is found (data integrity problem) then just cleanup associated GUID from xml file. In case of DB blob may be stored directly in DB.