GnuCash XML sched-xaction split amount formatting

[Derek Atkins]

Hi,

Ngewi Fet <ngewif at gmail.com> writes:

> Hi there,
> I also just realized that there are credit-numeric and debit-numeric tags which
> are formatted using the normal way GnuCash formats money amounts in XML, hence
> easier to parse (and more stable). 
>
> Given my experiences so far with the credit- and debit- formulas, I have
> decided to ignore those completely in favor of credit-numeric and
> debit-numeric.
> Now when parsing scheduled actions, if no credit/debit-numeric slots are found,
> the template will just be ignored. 
>
> What do you think of this approach?
> What determines whether *-numeric variants or the *-formula variants are used
> when GnuCash desktop is saving to XML?

What determines what gets written out is how it was read in.  You're
assuming that the slots data is actually parsed and then rewritten,
which is only partially true.  Slots data is read in, stored in the same
tree structure it was read from, and then written back out into the same
tree structure on write.  Indeed, GnuCash does not even need to
understand or know about a particular slots entry for it to be re-saved
on write.

This is very different than the primary objects.  If Gnucash doesn't
know about a particular XML field in, say, a Transaction object then
when it tries to parse the XML it will choke on the unknown xml tag.

However there is no such thing as an "unknown slots" tag.  The slots are
literally loaded as-is and written back out as-is.

As for what determines whether -numeric or -formula variants are used --
that would be a question for how the SX was originally created.  In
particular, ./src/register/ledger-core/split-register-model-save.c has
the following code:

    /* If the value can be parsed into a numeric result, store that
     * numeric value additionally. See above comment.*/
    parse_result = gnc_exp_parser_parse_separate_vars(debit_formula,
						      &debit_amount,
						      &error_loc, NULL);
    if (!parse_result)
        debit_amount = gnc_numeric_zero();

    qof_instance_set (QOF_INSTANCE (sd->split),
		      "sx-credit-formula", credit_formula,
		      "sx-credit-numeric", &credit_amount,
		      "sx-debit-formula", debit_formula,
		      "sx-debit-numeric", &debit_amount,
		      NULL);

... So basically it's parsing the input and assigning the _formula or
_amount based on whether the parser can reduce the input into a single
amount or not.

So no, you cannot just use the _amount...  It will fail in most cases.

-derek

> Thanks for all the feedback so far!
>
> Regards,
> Ngewi
>
> On Mon, May 4, 2015 at 3:57 PM, Derek Atkins <warlord at mit.edu> wrote:
>
>     Ngewi Fet <ngewif at gmail.com> writes:
>    
>     >>> Too bad you can't just incorporate the GnuCash engine (and file
>     >>> backend) C code directly into your App.  ;)
>     >
>     > That would be cool, although I don't know what the effort would be to
>     > hook into it. In what format does GnuCash handle it's data internally?
>     > SQL database? The SQL schema in the Android version is already similar
>     > and could be made even more so. Having the same code generating XML
>     > would definitely ease things. But I guess that's a rather looong term
>     > goal as Geert says.
>    
>     No, it uses QOF internally.
>    
>     One of the medium-term goals is to change it to using SQLite internally.
>    
>     >> One of the long-term goals... However it will be c++ code by then. We'd
>     >> love some more help getting the conversion done btw.
>     >
>     > Does this conversion require extensive knowledge of the Gtk framework
>     > and the scheme language?
>    
>     No, just Glib.
>    
>     >> More on topic though:
>     >> Ngewi, you write that you intend to generate the transactions when an SX
>     >> is due. Knowing that gnucash will also create these transactions,
>     >> independently from GoA when they are due, won't this cause duplicate
>     >> entries when importing back from GoA to gnucash on the desktop ?
>     >
>     > The scheduled transactions XML tracks things like the last run time,
>     > number of executions pending etc etc. We update all of that
>     > information as well.
>     > I assume GnuCash looks at this before deciding if and how many
>     > transactions to generate from the scheduled template. That way there
>     > will be no duplicates.
>     > But please correct me if I'm wrong.
>    
>     It does, provided you are sharing the datafile back and forth with
>     desktop GnuCash.
>    
>     > Regards,
>     > Ngewi
>    
>     -derek
>    
>     --
>            Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>            Member, MIT Student Information Processing Board  (SIPB)
>            URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>            warlord at MIT.EDU                        PGP key available
>

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available