[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Thoughts on Voiding Invoices



First, I am sorry you are offended.  Sometimes you come across as a
bit... tense... It isn't that your feedback isn't appreciated, but
sometimes that gets in the way.  I meant it as a friendly suggestion,
nothing more.

As for the accounting matters, you are going to have to acually
provide a strong accounting argument that this breaks GAAP.  My
understanding of GAAP FIFO inventory calculation is that a voided
invoice should not break the assumption of first-in, first-out.  I.e.
if the invoice was never valid to begin with, the items sold would
move on to subsequent invoices.  If you pull the prices back out of
the middle, then you are screwing up your inventory calulations.

In the US, both FIFO and LIFO methods are accepted under certain
circumstances, but in many other countries FIFO is the only accepted
method, so that is what we support.

To put it simply, voiding an invoice needs to bring it back to the
values that would have been *if the invoice had never been issued in
the first place.*  That is why last cost matters (and not actually
last cost, but the last cost of the number of items on the invoice,
which could span different purchases and hence it isn't as simple as
bringing it in for the last cost of one item purchased (if you buy in
50 unit incriments, and you mistakenly 100, but the price changed
between the last purchase and its subsequent one, the COGS will be
calculated on the basis of the last two purchases.

You seem to be the only one who disagrees with this.  Perhaps you can
share with us some accounting resources that make your case?

On 9/24/06, David Tangye <..hidden..> wrote:

> IFO invoentory is calculated in a way that assumes your inventory
> on-hand is the last inventory you bought.   So if I void an invoice,
> it needs to return my inventory values to wat they would have been if
> the other invoices had not sold that many parts.
Well I think I see what the upshot of adhering to FIFO accounting is,
based on what you say here, but I do not really care for it. What does
make sense to me is that if I sell various things and they cost
different amounts, the one that gets voided or returned is a real thing
that cost a fixed $ when I bought it. That cost is *fixed*. It does not
change. If anyone wants to book the same thing around at different costs
depending of changes in the price of similar stuff (to adhere to some
fifo theory, phases of the moon, or how they feel that day), well fine,
give them an option to do so if you wish. It just does not make sense to
me.

Ok, let me make this clear to you.  I haven't come across a country
yet that doesn't accept FIFO inventory calculations.  There are many
countries, including the UK, that require it.

We can't change laws through data modelling.

> Make sense?
No.

> See above.  It has to do with strict accounting rules as to how
> inventory on-hand is valued.
You might be right there. This might just be a good example of why
people say that if you let the accountants run a business you will go
bust. In this case, the cost has gone up, so returned product is
rebooked at a higher cost, so inventory is inflated, and the balance
sheet is higher than it should be. Ie we are sitting on old hats that
are not worth what the bean-counters have now declared their value to
be. But that is OK with them: the 'strict accounting rules' concerning
fifo are preserved.

You don't let accountant's run your business.  You let accountants do
what they are supposed to do-- manage your accounting system, provide
financial ananlysis, manage books, and the like.  If that is what you
limit running your business to, then sure, it will go bust.


> Yes it is relevant.  You can't just re-instate inventory amounts out
> of the middle just because the product was returned.
I did not say that. I always state the cost of goods at **what they
actually cost**, not what similar product now costs (If this is what
fifo is doing then fifo is bullsh*t accounting.)

FIFO is a *legal requirement* in many countries and is pretty
universally accepted.  If you don't like the law or the system that is
one thing, but you would do better to take your case to the accounting
standards boards than to this discussion for this reason.

If course, if you think I am doing FIFO accounting incorrectly, then
that is another matter.

And of course, depending on where you are, rules might be subtly
different.  If you do have local requirements that are
substantantially different than most other countries, we can look at
how to help you make your changes maintainable :)

Anyway. I do not intend to debate any further issues with you. You are
developing this app for the benefit of your particular clients, which is
a reasonable thing to do. Its been an interesting insight into how open
source can operate. The end code is open, but the scope, roadmap and
user requirements the app address are not. I never really understood
that before.

THe user requirements are open.  The accounting requirements/standards
are open in most countries.  And as for a roadmap, there isn't really
one.  Sure, there are requirements for the next release.  These are
discussed here on this list, on IRC, and more.  But if you want
something in the next release and we are unwilling or unable to do it,
you can do it yourself or hire a local programmer.  If you discuss
what you need, we can help provide guidance so that your code will be
forward-compatible.

Best Wishes,
Chris Travers