Talk:NF1.0 ImportCSV
From iDempiere en
Many people like to have their data in a spreadsheet. This will become a killer feature. :-) I thought about this for a while and have some suggestions:
- We can use this as an multi-purpose im-/exporter by defining a window/tab structure only for this reason - as a kind of "csv format definition"
- It would be good if we can use it for automated im-/export from the menu (or time scheduled)
- for this it should work as a process - not depending on the GridTab (we have to think how informations like the actual record or the actual tab go into the process or if we use one implementation with two APIs for GridTab and for Process)
- If we want to give all information about a record and his subrecords we could use headers like "bpname, location[0].address, location[0].city, location[0].phone, location[1].address, location[1].city, location[1].phone" up to a given number of subrecords (we can count the max and use it only up to perhaps 10 subrecords)
- the importer should let have another selection and/or order of columns
- the importer may use a kind of interpreter so if you write "customer.location[1].city" he will create 2 locations and use the "city" field of the second one
- We have to know whether the record has to be inserted or updated. This can depend on the search key and whether it is already there. Or we use a command column for that?
- Same question for columns: If we update a record and a column is empty does this mean "null" or does this mean "do not touch"??? How can we distinguish these cases? If we use a special Value for this we should see that the export creates a nice document. For export "null" values should become an empty field. So we have to find a special value for "do not touch". How about some seldom used unicode character like "☓"?
- The data should be as human readable as possible. So we use search keys instead if IDs. This will also give better interoperability with not exactly equal databases.
-- User:TBayen
