Creating Gnucash invoices with CSV

[Neil Williams]

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

On Monday 05 April 2004 3:16, Derek Atkins wrote:
- From gnucash-users:
> Hi,
>
> This is probably more appropriate for gnucash-devel, so I've forwarded
> it there.
>
> The documentation section you reference really talks about moving data OUT
> of gnucash, not INTO gnucash.

It was just that bit about vice-versa - it got me thinking.

> Honestly, what really should happen is a CSV importer that allows you to
> import business objects.  We've already got the code to read a CSV file,

CSV is just as suitable as XML for me. It really makes no odds. As long as it 
is a plain text output that can be written using Perl or bash, etc., and it 
can deal with alphanumerics and punctuation, I'm really not fussed. It's 
exchanging one set of problems for another - in my situation, all the CSV 
would be on a single line.

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

The problem with CSV is that if you make it one format for all objects, the 
files become very difficult to read or handle except via scripts. Once you've 
got >12 columns with fields or varying lengths, it can be hard to make the 
file human-readable. Invoices themselves can be large enough.

What about 3 formats:
Invoices
Customers
Jobs

The format decided upon import by the declarations in the first line - is that 
what is intended for CSV with gnucash? 

To me, invoices just need:
start date
customer ID
billing ID
Description
Action
Account
Quantity
Unit Price
Discount
Tax
Tax table
(Those last three I've never used so I'm unfamiliar with the expected 
handling).

If the full customer spec and job spec was added to this, wouldn't it be too 
awkward?

> a) be greatly appreciated by many people,
> b) solve most of these import problems,
> c) be gladly accepted into the sources.

I don't mind taking a look but it'll take a little time for me to get used to 
the call/function structure. I'm OK on C.

> I dont know how we could ship an xslt; we could put one into CVS, and
> probably even into the source tarball, but I have no clue where one
> would install it.  And with the XML file going away I see little point
> in distributing it in the long term.

Don't worry about XSLT in that case, as long as there is an import format, I 
can start there.



- -- 

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)

iD8DBQFAcYwyiAEJSii8s+MRAr/TAJ473d//VkfwhgpXNVwKRpuLEBQbeQCbBUL+
2MiHByMKx285UkugBj9mhp4=
=AQmF
-----END PGP SIGNATURE-----