Creating Gnucash invoices with CSV
linux at codehelp.co.uk
Mon Apr 5 12:41:21 EDT 2004
-----BEGIN PGP SIGNED MESSAGE-----
On Monday 05 April 2004 3:16, Derek Atkins wrote:
- From gnucash-users:
> 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()
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:
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:
(Those last three I've never used so I'm unfamiliar with the expected
If the full customer spec and job spec was added to this, wouldn't it be too
> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the gnucash-devel