On Tue, 2016-10-11 at 11:21 +0200, Geert Janssens wrote: > On Tuesday 11 October 2016 10:33:26 José JORGE wrote: > > hi, > > > > I am a Gnucash end user for years, and also it's packager for the > > Mageia Linux distro. > > > > French law now requires to be able to export in a well defined XML > > format following an XSD structure file : > > https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT0000 > 277 > > 88276&dateTexte=&categorieLien=id > > > > I wonder if it would be easy to add this export to Gnucash, as I > can > > see in gnucash-fr ML this is a big problem. > > > > I could try myself if someone points me where to start, as I am > myself > > in the need of this function. My structure could also donate some > > money to gnucash to make this happen. > > > > Thanks for your attention > > > > José > > Hi José, > > First off, thank you for the time you spend on packaging GnuCash for > the > Mageia Linux distro. That work is highly appreciated! > > Right now GnuCash doesn't have any xml export functionality so > achieving > this from within gnucash means writing it from scratch. Ideas about > exports can be taken from the other export functions, which are > written > in C. I couldn't readily determine which data is required in the xml > from the link you provided, partly because I don't know what all the > terms mean on that page, and partly because it seems it's only a > summary > of changes. It does look like more data may be required than gnucash > stores. > > One way you may approach this would be to check whether one or more > of > the included reports in gnucash provide the needed information. The > reports are formatted as xhtml. which at least follows a similar > syntax. > You may be able to make a variation of such report (or combine > information from several reports) that outputs an xml file instead. > It > would surely require source code changes for the custom report. The > reports are written in the guile scripting language so some knowledge > of > that language is a must for this approach. > > A variation would be to save the report(s) that contain(s) the > needed > data and then write an xslt filter that translates the report(s) > into > the required xml file. > > If you can afford to limit your support to linux-like platforms > only, > you could also investigate the python bindings and check if you can > gather the needed documentation via python code. > > Yet another way may be to explore piecash, which is a project that > allows to extract data from a gnucash data set in sql format. This > requires your data file to be saved in sqlite format instead of xml. > > And the last possibility I can think of would be to write an xslt > filter > that parses the gnucash data file (when saved as xml) directly to > gather > the necessary data and generate the xml file you need.
I think part of the problem with using XSLT to convert the XML data file directly, is the cross references in the GC XML file, and its generic nature. This is particularly true of the slot data (which may not matter in this case). I took a look at a (google translated) version of the referenced french website. I like the concept in principle. Too bad there is not an ISO standard format (that would be the way to go if there were one). I did not see an actual XSD referenced -- :-( It would be nice to see an actual sample of what the data is supposed to look like. That would help one understand the best approach to take. It maybe that converting an existing report or building a new one would do it. Along the lines for the Python suggestion, though, I can think of one other way of doing it, though it is not ready for generic use. A while ago, I decoded a good bit of the GC XML data file format, in order to write some perl scripts to remove "orphaned" account matching Bayes slot data, and also to move specific transactions to another account in the hierarchy (downward which is not supported in the UI). I used libxml to read the XML data into an in memory structure, I then wrote routines to operate on the XML structure in memory before writing out the modified data as XML to a new file. At the suggestion of Chris Good, I was planning to put these scripts up in github (and maybe CPAN) so that they would be easy for others to use (and collaborate on). But, I wanted to make the GC data operations object oriented with a wrapper on the data structure, so that the business logic of the scripts is more object oriented, easier to understand, and more reusable. This would enable consolidation the code currently cloned across the various scripts I had written, and centralize it to a single GC data object that supported reporting and other manipulation operations. This would make the scripts themselves much smaller. They would all basically become: 1) Read GC data into a Perl object, 2) Operate on it by calling methods on the GC Object, and 3) write a new GC file (or other report files). The details of the operations on the GC structure and referencing it would be encapsulated in the higher level (and easier to understand) GC object. (This is my plan for this). I started the conversion, but hadn't finished when other things in my life distracted me. If such an OO perl object existed and the methods existed to traverse it (and modify it) in object oriented terms, I think it would be relatively trivial to use to extract any file format wanted. If so, I could raise the personal priority of my conversion effort. If no interest, fine too, :-) I'll get to it sooner or later (at the latest, the next time I decide I need a script to do something the UI does not support). I would note that I have NOT looked at the business functions and business data in the GC data file, because I don't use them. This may be morphing this topic a bit too far, but, does a C++ object model and method specification exist for wrapping the data? I would hope such a model could/would be designed to be independent of the the UI code that would operate on it. (If such a spec exists, I would like to look at it, and potentially imitate it in what I was planning. This might be very useful for prototyping a separation of the UI from the object model, or, at least, providing another reporting framework and scripting capability for performing functions the UI does not support today. Lincoln _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
