Thanks tm, I also will have to remember that little poke to the system. I have about 13,400 products to sync!
2 10/19/2012 06:57:52 pm
Re: Import csv or xml or text file in Bnaking en General Ledger (7 replies, posted in Banking and General Ledger)
I'm just starting with frontaccounting but I have been using mysql for years. You don't make it clear whether you want to import just a couple of bank accounts, or a large number of bank account transactions. You can probably do some bank accounts, but NOT the transactions.
You will also need a little experience with mysql tables.
This is definitely a DBF experience: DO BACKUP FIRST!
Export your data from whereever, to a spreadsheet ( libreoffice-calc, excel etc).
In mysql, use 'describe table bank_accounts;' (or bank_trans) to get a list of the table columns and data-types associated with those columns.
Adjust your spreadsheet accordingly, by adding/deleting columns and formatting them as neccessary.
Export from the spreadsheet as, say 'export.csv'.
Edit the csv to remove the header line and any blank data lines which the export added.
Then, in mysql:
'load data local infile 'export.csv' into table bank_accounts fields terminated by ','
enclosed by '"' lines terminated by '\n'
(account_code, account_type,bank_account_name,bank_account_number, ...(other fields)...,inactive);'
(that's all one line, btw) The enclosed by and lines terminated by are actually optional but take care of columns with double-quotes.
From a quick glance, the bank accounts table is a reasonably standalone reference table. so this would load the data. Fine for database use, but not so much for accounting. The id and and a couple of other fields are keys referenced by other tables, which almost assuredly DO NOT MATCH UP in FA with what you are exporting from. So you might get away with it, for the bank accounts data but NOT for transactions.
Loading the bank account data, instead of re-typing it, will probably work for setup. But if you want it import a bunch of transactions, then you would have to do the same sort of adjusting, for EVERY table which any transaction 'talks' to. That could include supplier transactions, tax transactions, sales orders....etc.
The only way to track that would probably be to start with a no-transactions database, create the bank accounts, and enter one of each type of bank transaction, credit and debit (creating suppliers, customers etc. as you go) and then examining the tables to see what went where.
And the id's will all likely change. It CAN be done, but it is not likely to be easy.
I'm presently loading an Opencart instance and creating some 475 odd categories and (ATM) 6800 product entries...going for 15,000 plus. I have what are basically csv files, and I create insert statements in a sql file. It ain't easy.
Last time I asked about something like this, my more-IT-aware friend scribbled a little map for me. The map for this had a big section marked "Here be dragons!"