Dave Peticolas <[EMAIL PROTECTED]> writes:
> We don't have a 'text import' function right now, but it shouldn't
> be too hard to come up with a simple one using guile (scheme), which
> GnuCash uses for scripting.
>
> If you'd like to work on this, please feel free to discuss your
> plans on this list and ask questions.
Well, we've already got the "text export" function, and other than
only being able to dump to standard output right now, last time I
checked, it worked fine (though I still need to fix the g-wrap
long-long problem before we release). The reverse of this export
function is similar to what Mike would need, and I'd be happy to go
ahead and finish this up, but after thinking about the problem for a
bit, I think we should step back and consider what we need.
The original point of the "text export" mechanism was to capture a
complete correct snapshot of an account group as text, in a way that
could be easily reversed (via schme) to recreate the account group
later. I think it probably does that now. It's not (as it stands) a
format suitable for the importing that Mike wants since he wants to be
able to specify changes to an account group rather than to specify a
group completely.
The reason that the current export file format (see the end of this
message for an example from data/splitdemo.xac) is just scheme forms,
rather than a set of scheme function calls that when executed would
recreate the account group, is that this allows for more careful
parsing and keeps it from being trivial to insert a nasty trojan horse
into the data file (i.e. putting in '(system "rm -rf ~")' or similar)
but this choice does make things less flexible.
Right now, there's no reason why Mike couldn't just automatically
generate a file that contains the relevant scheme code to add his new
transactions and then fire up gnucash and "load" that file. We could
even define some helper functions that make the "change file" contents
nicer. Say something like this:
(gnc:one-split-transaction-easy-add
'(date "2000-12-02")
'(check-number 1221)
'(source-account "Checking")
'(destination-account "Rent")
'(amount 20.3))
This function could automatically handle all the right account lookups
and date conversions, build the transaction and split, insert it, etc,
and unmentioned, optional fields would just get default values. The
problem here is that load is dangerous for data files if you think
people are ever going to be exchanging them.
An alternate approach would be to define a limited syntax for the
"import" files and write a simple limited evaluator (which is trivial
to write in scheme) to handle the import. You could support something
like this:
(add-account <name> <type> ...)
(add-transaction ...
(split ...)
(split ...))
(delete-transaction ...)
etc.
Right now this seems like the right thing to do. What do other people
think? If this is a good idea, I believe I can implement this quite
quickly, and this same format would be quite appropriate for use in
specifying scheduled transactions...
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
