Re: GAAP (was Re: Patch for serious bug in LedgerSMB 1.2.16)

[Chris Travers <..hidden..>]

On Sat, Feb 21, 2009 at 6:23 AM, Ed W <..hidden..> wrote:
> Hi
>
>> In short there is no accepted solution to the problem because the
>> problem does not exist in an accepted process.
>>
>
> Certainly there is an obvious "solution", which is when reposting the
> invoice to use the same COGS values, unless the quantities have
> changed.  Now, ok this still leaves the question about what to do when
> quantities change, but at least we have now solved the main situation

So, if you aren't enforcing directory transversal, what happens when
you delete an invoice?  Also note that, in the inherited codebase from
SL does a repost as a deletion and then a post-as-new.  If we really
want to do a repost, along these lines it will require rewiriting
substantial functionality in the invoice logic.



>
> What to do in the case of changing the quantity is dependent on whether
> we use FIFO, LIFO or average cost.  If we use FIFO and *add* items then
> without reposting invoices all we can do is keep our current COGS and
> add the next fifo cost item.  With FIFO and we remove items then unless
> we tracked the individual item costs then we have to make some assumptions

Given the amount of effort it would take to rewrite the inherited code
to support this, why not just rewrite the entire invoice system (as we
are going to do for 1.4) and provide
draft/1-button-reversal-and-post-new capabilitity?

>
> Does LSMB not tie the sales and purchase invoices together though?

Not directly.  It just tracks allocated items for COGS purposes in
sales and purchase invoices.

>  I
> thought we were actually tracking individual items to generate COGS?

Here is the way it is tracked now (showing both sales-before-purchase
and purchase-before-saes):

I purchase 10 widgets at $0.10.

Records $1 in inventory, etc. in the acc_trans table
Records 10 unallocated, purchased widgets in the invoice table at $0.10

I now sell 15 widgets at $1 each.

Records -$1 in inventory, $15 in income, $1 in cogs.
Allocates the 10 widgets from my purchase invoice.
Adds 5 unallocated sold widgets in invoice

Now I buy 10 more widgets at $0.20 each.
Records $2 in inventory, etc in acc_trans table,
adds 10 unallocated widgets in invoice table

Then it:
allocates five of the widgets from this purchase invoice,
Adds $1 to COGS, -$1 to inventiry, etc.
alocates the unallocated 5 sales invoice widgets

So all that is tracked is how many widgets have been used for cost
calculation, not which invoices they are attached to.
>
>
> Anyway the issue is completely moot because we STILL need to do a very
> similar process if the steps are to reverse the invoice and post a new
> one!  No matter how you cut this, if we need to fix an invoice then it
> makes no odds from a COGS perspective if we repost or reverse out and
> post a new invoice.

Right.  The advantage though to a reversal is that the old invoice is
still on the books so adjustments between the old and new cogs values
can be posted.  :-)

>
>> One option would be to restock the part at the value it was purchased,
>> but you don't always know this value,
>
> I thought in the case of LSMB we *did* know this?

Ok, take the instance I mentioned above, where a 15-item sale hits
parts at two different cogs rates.  This could correspond with 1 line
item (if all 15 were available then), or 2 line items (if not).  You
don't have a 1:1 connection between a sales invoice line, a purchase
invoice line, and a financial transaction line-item.  Also since
direct linkages between sales and purchase lines are not handled, this
means one cannot safely guess which older ones to unallocate.

The only thing that can be done is to reverse the old invoice, post as
new, compare COGS values, and post an adjustment.

>
> Certainly it's only an issue with FIFO if remove quantity.  For same
> quantity or an increase we can at least start with the previous COGS

Correct to an extent.

>
> Actually different countries have different requirements, so at some
> point having the option to choose would be nice to have on the TODO
> list.  I think in many jurisdictions you can pick either though?

Correct on this point, but then one has issues.  If FIFO breaks when
one reposts an invoice and that is supported, than can we support FIFO
inventory handling?

I think the correct approach here is to focus on supporting workflows
and end-user functionality but insisting that the financial side is
handled in GAAP-compliant ways.



> I really think we are missing the point here.  The above is entirely
> irrelevant in the sense that we have the same problem when generating a
> quote, when generating an order and when generating an invoice.

Not at all.  The idea of draft invoices would do EXACTLY what an
order-to-invoice structure does:  Not calculate COGS, etc. until we
are ready to post to the books.  We don't worry about COGS on quotes
and orders because we don't accrue income or expense when those are
entered.

This means you would be able to save an invoice as a "draft" without
doing any financial calculations, etc.  Review it for errors, and once
you are sure there are no errors, post it to the books, calculating
COGS, etc.  At this point, I am within a couple of hours of having
this functional in 1.3.

>  The
> point is at some point in time we need to lock down the inventory and
> allocate some COGS - it's entirely arbitrary that this is done when
> "posting an invoice", it could be done at some later point, or we could
> have a two phase post.

No, it is not arbitrary.  It is the definition of accrual-based
accounting.  Income and expense are accrued when an invoice is posted
to the books, and an invoice is posted to the books when all work has
been done in order to earn that income.

However, this is splitting hairs in one respect because the idea that
one can only POST an invoice and not SAVE a draft for later approval
is entirely arbitrary.  I suspect this is what you mean, so the above
paragraph is really only to clarify the requirements.

I can tell you that by the end of this weekend, it will be possible to
do batches of invoice vouchers and invoice drafts along these lines in
the 1.3 codebase.  Currently 1.3 only supports drafts and batches for
payments, gl, ar, and ap transactions.  Adding invoice support for
this would effectively resolve your issue without running amok with
GAAP.

Once more, to re-iterate how this would work:

You can create an invoice, enter all information and save as either a
draft or a voucher.  Depending on how your system is set up, either
you or someone else can come along, verify the information in the
invoice, and post it to the books.   Invoice drafts can be reviewed
for accuracy or have corrections made prior to posting.  Vouchers
could only be deleted or posted as part of a larger batch.

>  eg it would not be unreasonable for it to be a
> somewhat dynamic allocation which is locked down as part of a monthly
> reporting process, etc...

So you would be proposing going through and, at the end of the month,
backfilling COGS info?

How would the loss of real-time reporting in that case be worth the
gains if we already had draft/voucher stuff for invoices in place?

How would that compare to creating all invoices as drafts and then at
the end of the month reviewing them for accuracy and posting them?

>
> I think if we can collect the use cases here then actually what is being
> asked for is NOT the ability to edit all invoices arbitrarily.  I
> suspect that it's just a case of a bunch of minor edits, and possibly
> some additional workflow steps which could be called "proforma" or
> something similar.

"Draft?"

Ok, at this point, I think we need to postpone this discussion until
1.3 is at least more usable so people can take a look at how we are
looking at addressing this in 1.3.

The basic thing is that the need for error control on invoices will be
addressed in 1.3 along lines which allows folks to be able to edit the
invoices after they are entered but before they are posted.

This isn't just an issue with smaller businesses though.  There are
valid reasons for requiring this sort of thing in the mid-range too.
There are two basic problems:

1)  I enter an invoice, and get the information wrong.  Oops?  Now I
have to reverse?
2)  I hire you to be my bookkeeper.  You enter bogus invoices and
print yourself checks.

The solution we are working on addresses BOTH of the above issues by
allowing one to require:

1)  That an invoice be entered, double-checked, and approved before
being posted to the books and
2)  Depending on the setup, that the original individual who entered
the invoice might not be able to approve it.

Of course, in some environments, you might or might not want to do
things this way.  POS invoices for example, might be posted directly.

Hope this helps.
Chris Travers