[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: importing daily data to LedgerSMB
- Subject: Re: importing daily data to LedgerSMB
- From: Chris Travers <..hidden..>
- Date: Mon, 8 Mar 2010 07:45:36 -0800
On Mon, Mar 8, 2010 at 4:09 AM, WK <..hidden..> wrote:
> 2010/3/8 Chris Travers <..hidden..>:
>> I assume your sales and stock solution handles inventory valuation,
>> sales, VAT, COGS, etc, right?
> Yes, i need just GL functionality and analysis/reporting tools for
> accountant, so i can get every month overview of some departments (i
> think, income statement is right termin). I will not use it's
> inventory and stock functionality.
>> Do you plan to use LSMB for any internal business usage that involves
>> customers and vendors?
> For vendors i have need, because i need keep eye on payments and for
> that is LedgerSMB very good. So first i need import all my vendors
> (about 800, about 200 active last year) and then keep them syncro
> For customers i don't have plan to use LSMB, i still have need to
> import sales invoices and enter POS-s daily sums (both with different
> VATs), but they may be as journal entries, not detailed items on them.
> I thought, i create some dummy items like "goods with VAT 9%" and so
> on. On importing invoices (both purchase and sales) i could use them.
> So i can put them on the right accounts and also got taxes handled
> properly. Without needing to convert all my items database to LSMB.
If you do that, LSMB will quite happily calculate COGS and tax for you
which is probably not what you want.
What I would suggest instead is:
1) Create an import schema with tables representing the info to be imported.
2) Use some sort of stored procedures to import these as GL and AP
transactions (if in 1.3, create batches of GL/AP vouchers)
3) Have a nightly job which writes to the import tables and runs the
If this is all you are doing, I would recommend seriously working on
moving to 1.3 even at this point. The vendor/gl and batch-draft
systems are rock solid and well tested, and it would allow you to
review the data before posting it to your books. This keeps you in
control and allows you to handle integration errors before, well, you
insert a lot of data into your accounting db.