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