-----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----- _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
