[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 14:14:19 -0800
On Mon, Mar 8, 2010 at 1:58 PM, WK <..hidden..> wrote:
> 2010/3/8 Chris Travers <..hidden..>:
>> If you do that, LSMB will quite happily calculate COGS and tax for you
>> which is probably not what you want.
> I hope i understand you correctly: COGS is something like "how much i
> made money from this particular product" and depending from that LSMB
> calculates some taxes?
Not quite. COGS is "how much the goods I sold cost me when I purchased them?"
> As far i understand, i can't enter purchase (sales too) invoices as
> transaction, because i need them be liabilities not as expenses
> (Purchases etc) in my balance.
Not necessarily. AP accounts are generally liabilities, right? And
you can set up any other account (like an inventory asset account) as
AP/Expense in the account setup screen to make it show up under the
list of expenses.
> There is still stranger procedures to me, but something like that i
> imagined. (Except invoices instead of transactsions.) In 1.2 dataset
> is around 60 tables. Is there some place to get overview of relations
> between them? Or maybe you can just point me which tables are
> neccessary when i need to import for example purchase invoices?
doc/database/ contains database references in a few formats.
Tables I would look at are ap, gl, acc_trans, vendor.
> Btw, what are "batches of GL/AP vouchers"?
In 1.3 you can group GL, AR, and AP transactions into a batch. The
vouchers start out as "unapproved" (and off the books), and are
reviewed prior to posting them to the books. Once posted, they become
visible to the reports. This allows you to review for accuracy the
data before you commit it to your financial system.
>> 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.
> Sounds very much what i wanted, i still need to do some homework to
> understand some termins and getting clear how many Postgres differs
> from MySQL.
PostgreSQL is rather different from MySQL, except that both accept
some variant of SQL.....