Introducing myself

[Geert Janssens]

On Tuesday 11 October 2016 12:14:15 José Jorge wrote:
> Le 11/10/2016 à 11:21, Geert Janssens a écrit :
> 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.
> Thanks for the fast and detailed answer. In fact, I thought that XML
> export would be easy as it is Gnucash format file. As you said, all
> other options would be suboptimal, as this is a need to be able to
> use Gnucash in french structures. Some users have gone to Odoo which
> is a PHP+POSTGRES open source solution that also provides accounting
> and L47 file export. Maybe it's code could be interesting?

I understand. I'm in Belgium and for my company I have to use something 
else than gnucash as well for the same reasons (and that something else 
happens to be Odoo as well:). So I'm very interested in a better 
solution here.

> 
> So the good road would be to :
> - ensure we have all data needed in gnucash.
> - create a xml export as it is done for csv.
> 
> For the first point, I will try to detail where I think Gnucash has
> the data : L47 name
> XML name
> data type
> Gnucash
> 1. Le code journal de l'écriture comptable
> JournalCode
> Alphanumérique
> Does gnucash internaly have a journal code for each line?

Alas no. GnuCash doesn't really have journals in the sense that you 
require.

If you use the business features, you could say it has 6 implicit 
journals:
One for each of:
- customer invoices
- customer credit notes
- vendor bills
- vendor credit notes
- employee vouchers
- employee credit notes

They are hard-coded and there is currently no way to list all the 
entries in each such journal. They do provide unique numbers for each 
piece in there if you like. These numbers can be configured using
File->Properties->Counters, which would also solve your number 3 
requirement.

Since these "journals" are hard-coded, you could choose to provide fixed 
journal codes in the xml report. Or you could make the journal code part 
of the counters to make them more explicit.

The most important missing journal is one to collect miscellaneous 
accounting entries that are not associated with any document, such as 
corrections or end-of-year processing. I don't have a solution for that 
currently.

Also, to be useful you'd need to gather date from different objects. The 
"journals" as I mentioned above only group invoices and their entries. 
For your report you would need to find the post transaction for each 
invoice, because only that will hold the actual accounting data (income 
amount, rebate amount, tax details,...)

The gui won't (currently) allow to extraxt all this easily in a way 
that's convenient to get it into an xml format, but the code has 
everything it needs to create such queries.

> 2. Le libellé journal de l'écriture comptable
> JournalLib
> Alphanumérique
> Description
> 3. Le numéro sur une séquence continue de l'écriture comptable
> EcritureNum
> Alphanumérique
> Does gnucash have an incremented single number for each line?
When using the business features, this is provided yes.

...

> 10. La date de la pièce justificative
> PieceDate
> Date
> Here we need a new date (of the Num piece) but it can be the single
> Date for now.
That would be your invoice/bill/... post date.

> 
> As you can see, I think Gnucash can do with it's data for now, even if
> some could be improved for big structures.
> 
> For the second point, I wonder if the xml serializer for gnucash save
> could be reused for the export?

I don't know the nitty-gritty details of the xml serializer, but I doubt 
it. It's a highly specialized piece of code focusing only on the objects 
in gnucash. There is nothing generic about it (AIUI) that can be used in 
a different way. It also doesn't verify against an XSD.

It is about to be rewritten somewhere soonish. Perhaps at that point 
making it more generic could be evaluated. I don't see how though right 
now.

Someone else may have more insight in this part.

Regards,

Geert