Re: At the end of my teather with LSMB

["Chris Travers" <..hidden..>]

On Sat, May 24, 2008 at 2:51 PM, Luke <..hidden..> wrote:
> On Sat, 24 May 2008, beamends wrote:
>
>> On Fri, 2008-05-23 at 14:51 -0400, Luke wrote:
>> > Use an AP transaction.
>> >
>>
>> But how to deal with VAT (sales tax)?  If I have to deal with that
>> separately I'm in danger of missing something.
>
> I don't know how things work with VAT, but here, the vendor puts sales tax
> right on the receipt, and collects it.  So it is an expense to me.
>
> Therefore, on the AP Transaction, it is just another line item, attributed
> to a different expense account.

Actually a liability account, but otherwise what you say is accurate.
>
> I'm guessing that VAT works differently, however, or you would have
> already done that, as indicated below.

Part of the issue has to do with how various taxes are actually
accounted.  In the US, I would track sales tax paid in the total of
the invoice if possible, and if not, track it to a different expense
account.  In some other countries, it would be tracked against the
same account that handles it.  The reason is that in some countries,
tax you pay as a business upstream counts against tax you otherwise
would owe.  So this is something where if, in doubt, you should
discuss with your accountant.

>
>> Sorry to rant, but I've wasted three days now just trying to enter one
>> fuel receipt - all I want to do is:
>>
>> Purchases->Expenses->Vehicle Expenses->Fuel
>
> Oh, how straight forward, and therefore impossible, that would be.

Nothing prevents someone from building screens to automate this sort
of entry, but they are not a part of the current system.  Furthermore,
unless the specific expense is extremely frequent, the only thing that
is accomplished would be menu clutter.  And, unless the expense is
extremely frequent for virtually every user, there is no point
burdening everyone with it.  So I can't imagine this sort of thing
being added to the main application.

This being said, I expect after the next version, we will begin
modularizing the application so that it is easier for people to add
screens (1.3 makes real progress in this area, but the logic in
financail sections is not sufficiently modularized for this).

>
> This needs to be done through AP -> AP Transaction:
> Select the vendor (or create one called "cash" or "misc. Fuel Stations" or
> something);
> Enter the date;
> Enter the first amount, and select the fuel expense account from the
> dropdown;
> enter the vat as another line item (may have to update first), selecting
> the proper tax account or expense account from the drop down;
> hit update; and post.
>
> Of course, that would would work, if VAT was charged like sales tax is
> here.  I'm guessing that you need something more complex, like our use
> tax, wherein you pay instead of the vendor.

Use tax is somewhat beyond what LSMB can currently automate.  To
properly handle use tax, you need to track converting for-sale
inventory to internal use.  This means selling the item to yourself.
I expect we will eventually tackle this, but at the moment there are
more fundamental issues we are working on.  Patches are, of course,
welcome.

> In that case, if your tax calculations are setup correctly, checking the
> box for tax might work.
>
>> Type in the name of the supplier
>
> It has long been a complaint of mine, that a new customer/vendor can not
> be created right on the forms for invoices/transactions.  There is a bug
> report posted, in which someone claims to have made a button for this, and
> posted the code.  Not sure how it works, though.
>
>> I've got 7 days now to get my return in (including the time in the
>> post). I'm afraid I'm dumbfounded that LSMB can't do this, and the same
>> for rent, postage, office supplies, sundries, bits bought as one-off's
>> from rarely used suppliers etc.
>
> It can be done--you just have to either enter every supplier as a vendor;
> or make a misc vendor of some kind, entering the real name in the notes.
> As for VAT: I know plenty of people were doing it with SQL-Ledger, so I
> assume the same techniques would work for Ledgersmb.  I just don't know
> what they are.
> Might check the sql-ledger mailing list archives.
>
>> And how the hell I'm going
>> to work out opening and closing stock balances I have no idea
>
> A vendor invoice is the normal way to set onhand values.  It would mess up
> COGS to enter one with a zero cost, so you might find your true stocking
> invoices, and enter them correctly.

Absolutely correct.  Vendor invoices to enter initial inventory.
Sales invoices for shrinkage/loss adjustments.


> Indeed.  That is why I keep pushing for a true API, so that alternative
> front ends, such as something with a postbooks/tinyerp feel, could be
> made.

We are working on it.

1.3 will make some real progress in that area.  However, to add a real
API, we really have to rewrite the entire application.  In general,
the current sense is that doing this in one iteration would be
disruptive and, from a QA perspective, unworkable.  Hence we are doing
this in sections.

You may want to take a look at:
http://www.ledgersmb.org/node/41

Basically, there will be a consistant database-level API, and an
object-oriented Perl API.  The DB API is designed to be easily usable
from other languages with a minimum of coding.  In 1.3, contact
management (customers/vendors), transaction approval (batch
creation/approval, separation of duties stuff) and payment/receipt
handling uses this system.  We expect to rewrite the rest of the
financial logic for 1.4 to use this framework.

There are some other discussions which also need to occur relating to
1.4 development including:

1)  What levels of dependencies to require  (currently I am leaning
towards requiring PostgreSQL 8.3 for the reason that it makes it far
easier to ensure that a transaction is balanced and DBD::Pg 2.x for
maintainability reasons but this is still an open issue and probably
won't be settled before 1.3's release).

2)  Questions of how best to handle state/provinces in 1.4.  I would
like to see state/province broken off into a separate table for data
enforcement reasons.

Best Wishes,
Chris Travers