Re: Thoughts on Voiding Invoices

[David Tangye <..hidden..>]

Oh heck, I wasn't going to be spending more timed here, but I can't help
it :-). (I am sure one more half hour wont hurt.)

On Mon, 2006-09-25 at 08:27 -0700, Chris Travers wrote:
I agree with all this except where noted.
> 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.
Not a good assumption here.
>   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.
This is how I distinguished discrete to bulk items. Discrete meant
'discretely identifyable' eg had a unique 'serial number', or could be
assigned a 'stock number'. Items were thus uniquely traceable. Generally
any business selling goods with warranties needs this.

I generally found that non-discrete items could be considered bulk. They
were bought, held and sold in multiples of 1 or more, but the item was
not uniquely identified by the business. If it was it could be handled
as a discrete item instead, and thus tracked. This way of looking at
items itself is not perfect, but I found it workable for everything I
thought of.

Parts and assemblies are forward and reverse recursive relationships of
items. In other words everything is an item, and can be separately
expressed as a part and/or component of other items. 
> 
> 2)  The proper way
I think that is is bit strong. I might say 'One commonly recognised good
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.
Sounds right. Allowances are forecasts, and I guess there are limits to
taxes claimable on forecasts. This is likely to vary from country to
country, and at election time :-).
> 
> 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).
Yes, using serial numbers etc: Discrete vs bulk items above.

> 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.
A matter of terminology here. I think you are referring to discrete as
meaning 'not part of an assembly, nor broken down.' I was using it as
meaning 'uniquely identifyable'. This shows the need to define terms as
part of requirements analysis/modelling, and  before design/coding
starts :-).