After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 501497 - Values in Gnucash reports are hard to import in spreadsheets
Values in Gnucash reports are hard to import in spreadsheets
Status: VERIFIED WONTFIX
Product: GnuCash
Classification: Other
Component: Reports
2.2.x
Other All
: Normal minor
: ---
Assigned To: Andreas Köhler
Andreas Köhler
Depends on:
Blocks:
 
 
Reported: 2007-12-04 12:19 UTC by pandya
Modified: 2018-06-29 21:55 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description pandya 2007-12-04 12:19:27 UTC
Aim is to import gnucash reports in openoffice or other spreadsheets for further calculations and modification. It is possible to import gnucash exported reports (html tables) into  openoffice spreadsheets.
But, as values output with special characters as (e.g. Rs 3,00,000.00)
the spreadsheet recongizes this value as a string and not as a number.
Hence no calculations can be done.

Please give an option where all values are reported without currency symbols or commas in reports. 

Thanks.

Other information:
Comment 1 Christian Bjerre Nielsen 2008-01-01 19:53:06 UTC
The question is: what is the data needed for outside of gnucash? And is the data needed as displayed - or do you really need the underlying transactions?

Taking inspiration from siebel you can export a report in two ways:
  - report formatted, i.e. the data that you see on the screen
  - transactions (line items) on which the report is based

Both are exported in a tab separated format and will normally be imported directly into the e.g. Calc or Excel for further formatting or analysis. Depending on the underlying data, there may be issues with formatting of numbers as texts (mainly due to decimal separator and not currency text).

Requirement based on the input from the comments above and the text in the bug:
 - add export options based on tab separated data and not html
 - select to export either
   - report layout or
   - underlying report transactions
Comment 2 mcturra2000 2008-01-03 22:11:11 UTC
I did some investigation work on this. I am using the currency GBP (Great British Pounds): £. I created an advanced portfolio report, and exported the report as an html file.

Using Gnumeric v1.7.11, I could open the html file as a spreadsheet. I found that gnumeric correctly treated an entry like £123,456 as a currency number, and I was able to use its value in formula arithmetic.

Using OpenOffice 2.3.0 Calc, I could not open the html file as a spreadsheet. However, I could copy the report from GnuCash by highlighting the text and pasting it into a Calc. I found that, like Gnumeric, it "did the right thing" with regards to the currency special values and comma separators.

Comment 3 Frank H. Ellenberger 2008-01-04 06:23:14 UTC
If I read Pandya right, the problem is with the representation of the old hindi units Lakh [http://en.wikipedia.org/wiki/Lakh] and Crore. 3 Million in south asia is writen as 30 Lakh or 30,00,000.00 . Some programs understand this and others not. So he wishes an option to export without commas.
Comment 4 Frank H. Ellenberger 2008-01-29 23:13:02 UTC
There was a short discussion on the mailing list https://lists.gnucash.org/pipermail/gnucash-devel/2008-January/021970.html
and in IRC
http://lists.gnucash.org/logs/2008/01/2008-01-04.html#T13:53:49.

AndrewSW thinks, it would be easy to do at the report level by changing the markup from "number cell" to some other format.
Comment 5 Christian Stimming 2008-11-08 20:42:44 UTC
See http://wiki.gnucash.org/wiki/FAQ#Q:_How_can_I_export_data.3F and especially 
http://www.alice-dsl.net/gnuc2ooo/gnuc2ooo_en/intro.html
This is the best solution so far.
Comment 6 John Ralls 2018-06-29 21:55:33 UTC
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=501497. Please update any external references or bookmarks.