Re: Thoughts on Voiding Invoices

[David Tangye <..hidden..>]

On Sun, 2006-09-24 at 00:35 -0700, Chris Travers wrote:
> There are *good* accounting reasons for making these assumptions.
I can argue the same.

> I
> am not a CPA, but I have had to learn a great deal about accounting in
> the course of working with this sort of software.
So can I.
> If I may say so, you need to relax a little.
I was relaxed til you said that. Now I am somewhat offended.

> > That assumption represents an bug due to faulty analysis.
> 
> Howso?
Because its a dangerous assumption.

>   The only case I can think of is where an invoice is issued by
> mistake and then discovered later (either by the customer challenging
> it or so forth).  In this case, I think it is reasonable to assume
> that an accontant may be involved in adjustments.
I would not make that assumption.
> 
> Let me make this clear-- voiding is something you do to invoices that
> were never valid in the first place.  It is like writing "VOID" across
> the surface of a check-- it isn't something that you get to go back
> and do after the fact.  So I think that the assumption that the
> invoice was recently issued is sufficiently valid as to require an
> accountant's oversight when that is broken.
Actually, I am sorry to say, but you have been starting to sound just
like Dieter in the way you make assertions about how you think a company
ought to be run. I don't think a really good accounting package is
likely to come out of that, even though I acknowledge the improvements
you are making within the constraints of your customers having SL based
systems up and running in production.

> 
> > >  so the cogs
> > > numbers are taken from the most recent purchases.
> > COGs should be the reverse of whatever the COGS for that invoice was.
> > Its irrelevant what changes have since been made. If I sell you an old
> > hat, and realise I should not have/didn't actually sell it after all,
> > its irrelevant that the new hats cost me twice as much.
> 
> The problem is that you screw up FIFO accounting if you do things that
> way.
This seems to be a case of a technical tail wagging the requirements
dog.

>   In short, your COGS might be wrong on your tax return.
I still do not see this. Maybe its just me.

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

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

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

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.

Now I must turn my time away from here to something very immediate. I
shall head off and do what you are doing: go out and satisfy the needs
of real clients in the attempt to get a $ in my (very empty) pocket.