Creating Gnucash invoices with CSV

[Neil Williams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 05 April 2004 7:40, Stuart D. Gathman wrote:
> On Mon, 5 Apr 2004, Neil Williams wrote:
> > > but no code to DO anything with it.  If someone wanted to write a CSV
> > > importer it would:
> >
> > Would that be a generic importer for all kinds of data or a specific
> > importer for invoices? Once it's in memory, isn't just a case of calling
> > set() routines?
> >
> > Business objects: so that could include the customer details, job
> > descriptions, what else?
>
> Script to run through inventory account and generate a depreciation
> transaction.

But that's not an import task. I'm only considering what CSV data would be 
needed in a business import - taking data from other applications, exported 
into CSV and then imported into Gnucash as new transactions.

So far, I've got the CVS code with the CSV test program (now that's 
confusing!), it compiles and I can run it with sample input.

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.

I'm using:
"Date Opened", "Date Posted", "Post Account", "Customer", "Job", "Date of 
item", "Description", "Action", "Income Account", "Quantity", "Price"
for testing purposes.

Subsequent items would repeat the whole thing:
"Date Opened", "Date Posted", "Post Account", "Customer", "Job", "Date of 
item", "Description", "Action", "Income Account", "Quantity", "Price"
"Date Opened", "Date Posted", "Post Account", "Customer", "Job", "Date of 
item", "Description", "Action", "Income Account", "Quantity", "Price"

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.

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.

Why was XML deprecated? It would solve these problems.

> Addon payroll system - generate paychecks, A/P transaction for
> taxes owed, and quarterly payment checks.

Again, isn't that internal rather than an import?

- -- 

Neil Williams
=============
http://www.codehelp.co.uk/
http://www.dclug.org.uk/
http://www.isbn.org.uk/
http://sourceforge.net/projects/isbnsearch/

http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAcbPpiAEJSii8s+MRAuNVAKDD7QbfeI5plc7s/zs8HyPWAL7AZACg3p2n
jAdmr6eT5kI38+7bNi40vTI=
=WYCJ
-----END PGP SIGNATURE-----