Re: Thoughts on Voiding Invoices

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

Ok, now I think our discussion is getting somewhere.   You are correct
in your bulk v. discreet item distinction but there are aspects to it
that point to the FIFO accounting for most parts.

Yesterday, I did a bunch of research on the FASB site on this subject.
I came to the following conclusions:

1) One key issue is the ability to abstract one item out of the flow.
Note that on most items you sell, you cannot reliably do this.  I.e.
if you sell 10 items on an invoice of which 2 are from a different
purchase with  different COGS, when one is returned then you don't
really know the cost of the item.  Thus as to both voids and returns,
it is proper to take the last cost approach.  This is the preferred
approach with most commodity items.  On the other hand, for some
items, such as custom-built computers, the approach is a little more
difficult.  And in this case, the correct approach is, as you say, to
revert to actual cost.

2)  The proper way to handle returns is with a contra account similar
to the allowance for bad debts.  In other words, with each purchase,
you add a small portion to the allowance for returns and then when the
return occurs, you treat it against that.  Note that like bad debts
you are not required to use this method, but if you don't your
accountant is required to adjust your income and expense accounts
according to return estimates.  Note that this is probably limited to
financial reporting and not applicable to taxes, but I don't have
appropriate expertise to make that decision.

Note that you cannot abstract the items from the sale because the
information as to which item was being returned and its actual cost
cannot be adequately tracked in the database due to external factors
(actually you could track it in the database by using serial numbers
for parts, but then the workflow gets out of control).

Note that the FASB's work is somewhat limited in scope to the US, so
YMMV outside the US, but this seems pretty standard.

Currently, you can track discrete items as their own parts.  Custom
manufacturing adds some complexities here that the application isn't
able to handle at the moment.

Best Wishes,
Chris Travers

On 9/25/06, David Tangye <..hidden..> wrote:
> On Sun, 2006-09-24 at 08:56 -0700, Chris Travers wrote:
>
> > You seem to be the only one who disagrees with this.  Perhaps you can
> > share with us some accounting resources that make your case?
> I cannot remember all the details now, i looked at it 10 years ago.
> However I thought more today, and remembered that one factor dictating
> how to deal with it was whether it was a discrete or bulk item. The
> bottom line : the way I designed what I did, based on what I was told -
> I recorded every discrete item as a row in the database, so its actual
> cost was directly attached, and irrespective of what happened to that
> item, its cost never changed (unless you returned and repurchased it at
> another price). Bulk items are different, as cost is calculated, as
> units of order-multiple are dealt with.
>
> Anyway, as stated before, you need to decide what the scope of this app
> is, and how far and if/when you are going to add value-add operations
> support to what started as an accounting program.
>
> If this makes no sense to anyone, feel feel to ignore it.
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Ledger-smb-devel mailing list
> ..hidden..
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel