Introducing myself

gLETTERyYuMEANSj LETTERyOt gletteryyumeansjletteryot at
Tue Oct 11 07:50:32 EDT 2016


I have made local developments on gnucash, mainly introducing the exact time up
to the second in each date, and arranging colors and font sizes of gnucash
window to have white text on dark background.

I can tell you, José, that there are in the .gnucash xml file some details that
may be useful:

2016-10-11 12:14 UTC+02:00, José Jorge <jose.jorge at>:
>    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?
>    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?

Each line of multi-line transactions and both lines of normal
transaction have their own journal code, e.g.: <split:id

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

I guess no, but the fields (for item number 1, above) <split:id
type="guid"> could be automatically associated to single numbers by

>    4. La date de comptabilisation de l'écriture comptable
>    EcritureDate
>    Date
>    Date
>    5. Le numéro de compte, dont les trois premiers caractères doivent
>    correspondre à  des chiffres respectant les normes du plan comptable
>    français
>    CompteNum
>    Alphanumérique
>    Account Code
>    6. Le libellé de compte, conformément à  la nomenclature du plan
>    comptable français
>    CompteLib
>    Alphanumérique
>    Account Name
>    7. Le numéro de compte auxiliaire (à  blanc si non utilisé)
>    CompAuxNum
>    Alphanumérique
>    Transfer Account Code
>    8. Le libellé de compte auxiliaire (à  blanc si non utilisé)
>    CompAuxLib
>    Alphanumérique
>    Transfer Account Name
>    9. La référence de la pièce justificative
>    PieceRef
>    Alphanumérique
>    Num
>    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.
>    11. Le libellé de l'écriture comptable
>    EcritureLib
>    Alphanumérique
>    Description (yes it is the same for simple accounting)

You also have the field <split:memo>cheque en bois</split:memo> : one
such field for each line.

>    12. Le montant au débit
>    Debit
>    Numérique
>    Expense
>    13. Le montant au crédit
>    Credit
>    Numérique
>    Rebate
>    14. Le lettrage de l'écriture comptable (à  blanc si non utilisé)
>    EcritureLet
>    Alphanumérique
>    leave blank

It is difficult to do better: Gnucash has a common code for all lines
of all lines of a transaction done at the same time, e.g.: <trn:id
type="guid">e74afb47127fcec694e875c0ed72a9bb</trn:id>. But,
unfortunately, nothing to relate lines of a transaction done a
different times, short of creating a sub-account of 411 (account code
of "créances clients") for each transaction, or to fill manually the

>    15. La date de lettrage (à  blanc si non utilisé)
>    DateLet
>    Date
>    leave blank

It is difficult to do better: it is not easy to add a date to each
split (see old mails in this list).

If it is possible to access various daily versions of the .gnucash
file, it could be possible at least to guess that date checking in
which oldest file <split:reconciled-state>n</split:reconciled-state>
has been changed to

This is involved, but feasible.

>    16. La date de validation de l'écriture comptable
>    ValidDate
>    Date
>    Date (yes it is the same for simple accounting)

It would be possible to use the field <trn:date-posted>
<ts:date>2015-01-01 11:00:00 +0000</ts:date> </trn:date-posted>.

>    17. Le montant en devise (à  blanc si non utilisé)
>    Montantdevise
>    Numérique
>    leave blank

You can also use the field <split:quantity>0/100</split:quantity>

>    18. L'identifiant de la devise (à  blanc si non utilisé)
>    Idevise
>    Alphanumérique leave blank

You can use the field <split:account
type="guid">1a63c8f7c0171599ebfccb6ddbd37682</split:account>, and the
account definition contains the field <cmdty:id>EUR</cmdty:id>.

>    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?
>    The XSD file that allows to ensure exported file is correct is here :
>    [1]
>    6/fichedescriptive_6706.xsd
>    Thanks,
>    José
>      __________________________________________________________________
> References
>    1.

More information about the gnucash-devel mailing list