Creating Gnucash invoices with CSV

[Derek Atkins]

Neil Williams <linux at codehelp.co.uk> writes:

> My first problem is the repeat within an invoice:
> The first section needs to deal with the common stuff, customer, start date, 
> job ID. That's then fixed for the rest of that invoice. However, the 
> subsequent data needs to repeat - more than one item per invoice. This would 
> be easier under XML but in CSV, it breaks the standard unless duplicated.

Yes, this is an issue..  How does IIF deal with it?

> The invoice ID won't be known until the import is in progress, the customer 
> field will need to be a lookup, like job. I don't want to have to repeat the 
> first five fields at the start of every line. It's a lot of wasted processing 
> as well as a five-field equality test.

Uh, not necessarily true; the invoice ID is an arbitrary string.  It can be
left blank (so the system will create one), but the user is allowed to set
it directly.

I agree with your second issue.

> Another thing about CSV is that a lot of CSV-capable programs bring up a 
> dialog box for the user to select which value goes into which field - a 
> process that repeats every time the import is run. Are there objections to 
> writing this so that a fixed CSV format is expected? I'm going to be running 
> this every day, I don't want to have to select each field from a dialog - 
> ruins the whole point.

As I said a few minutes ago (crossed in the mail), you should NOT
require a specific column mapping.  It's ok to define a default
mapping, but the user should ALWAYS get the option to change it.

Note that this doesn't mean that they should be required to SET it
every time; if their data matches the default format they should just
be able to hit 'ok'..  But the option MUST exist (this is a firm
requirement).

> Why was XML deprecated? It would solve these problems.

Because XML is a HORRIBLE data format.  It's a great _INTERCHANGE_
format.  So we want to fix that and relegate XML to what it's good at,
exchanging data.  For storing data we should use a real database.

If you wanted to write an importer that took a snippet of a GnuCash
XML file and imported it, that would work too.  Indeed, importing an
XML file would help in multiple ways.  For example, imagine being able
to re-run the Hierarchy Druid in order to add new sets-of-accounts to
your data file!  An XML importer would make this much easier.

Similarly, it would be useful for combining multiple data files.

The downside is the challenge in mapping the GUIDs of an imported data
to an existing data.  How do you know if an account is the same?  Or
an invoice?  or a customer?  It's a huge can of worms to build an XML
importer (which is why it hasn't been done, yet ;)

The choice is yours, tho.

-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