Re: At the end of my teather with LSMB

[Luke <..hidden..>]

On Sun, 25 May 2008, Chris Travers wrote:

> On Sat, May 24, 2008 at 2:51 PM, Luke <..hidden..> wrote:
> > On Sat, 24 May 2008, beamends wrote:
> >
> >> 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.

Cases A and C being handled approximately the same way: by posting the VAT 
as a line item on the AP transaction, and unchecking the tax box.  I 
should think, anyway.

> >> 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.

It is straight forward from a usage prospective.  Impossible from a 
practicality one, for the reasons you mention.  Almost every business will 
have a different variation of this need.  Me, for example: doing this for 
fuel would be of no use what so ever, but having a "canned" transaction 
with a few variables which could be changed in the moment, would be great 
for domain name purchases; received interest payments on money market 
accounts and such; and monthly payments to vendors which are always 
identical except for transaction verification number (source/memo) and 
amount.

It would be quite nice to setup some sort of easily configured way to 
arrange transactions like this--filling in several variables in a stored 
manner, giving it a menu selectable name, and leaving a few variables left 
for prompting.  I have been half-heartedly trying to figure a way of 
pulling this off since early days with SL, but the transaction model 
currently in use just does not make this easy.

[.]
> > 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.

As I note below: the idea of "inventory for internal use" is currently a 
foreign concept in LSMB.

> 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.

I try to limit my complaints to things I think can actually be solved in a 
reasonable manner.  This has never been a complaint of mine with either SL 
or LSMB, because I can not think of any way to really automate it more 
than entering a GL or some other transaction, which is the current method.  
Maybe that is my failure of imagination, but the variables in use tax are 
a bit humano-centric.

As I write that, a possible method has sprung fully formed into mind.:)

It would require something I _have_ wanted for a while: a difference 
between acquisition of sales inventory, and capital inventory.

If you record every time the flag is changed from tracking to non-tracking 
(sales to capital inventory), or the inventory is moved between categories 
(depending on how it is implemented), you would be able to run an 
"inventory transition" report, with a use tax option calculated against 
your current sales tax accounts.
You would then at least have the proper amount to apply against the sales 
tax account, and with a per-item check box, you could select which use tax 
line items you actually want turned into a liability.

Rather imperfect, but it seems like a potential method.

Still, for me at least, this is not a huge issue.  The amount of sales to 
capital inventory conversion I do each year is tiny--on the order of ten 
use tax items in a high year.

> > 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.

Seems reasonable.  As long as it is definitely in the queue, incremental 
steps make perfect sense.

Regards,

Luke