Neil Williams <[EMAIL PROTECTED]> writes:
>> 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?
I was thinking a generic importer for all kinds of data objects, where
the user can define the mappings from CSV columns to data types in
real-time (or perhaps via a set of saved formats).
> Business objects: so that could include the customer details, job
> descriptions, what else?
EVERYTHING. Customer, Vendor, Job, Invoices... I'm even talking about
transactions!
> 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.
Huh? What do you mean "one format for all objects"? At some level, by
definition, CSV is one format for all objects. The format is:
col1,col2,col3,col4,...,colN
This is the same for all objects. The MEANING of each column is
obviously different, and in fact should be user-changable at runtime
via a GUI configuration.
> What about 3 formats:
> Invoices
> Customers
> Jobs
Not sufficient.
> The format decided upon import by the declarations in the first line - is that
> what is intended for CSV with gnucash?
Sort of, yes. By asking to import a set of, say, Customers, you start
with a default set of column mappings and then should be allowed to
fix the mappings as necessary. This maps column <-> data-parameter.
> To me, invoices just need:
> start date
> customer ID
> billing ID
Note that there are two types of data for an invoice, there are the
invoice items, and then the line-items. The invoice items are
necessarily one-to-one. The line-times are many-to-one. Putting
them into a single CSV table might be problematic.
[snip]
> If the full customer spec and job spec was added to this, wouldn't it be too
> awkward?
Why? they are separate tables, so provide separate CSV column mappings.
>> 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.
Good. I expect most of this to be written in C. As I said we already
have the core CSV parser. It'll take a CSV and provide a
list-of-lists. Each line is a list of strings, and it returns a list
of lines, hense the list-of-lists.
What needs to be done:
* column mapping
* field parsing (we already have a bunch of generic parsers)
* user verification
* transaction matching
* data-checking
* data-insertion
I suspect this could use the new-in-g2-port dynamic druid code for
much of the UI, but the actual importer backend needs to be
implemented.
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
[EMAIL PROTECTED] PGP key available
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
