Introducing myself

Lincoln A Baxter lab at
Tue Oct 11 16:36:28 EDT 2016

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 :
> >
> 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

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

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


More information about the gnucash-devel mailing list