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

Re: Thoughts on Voiding Invoices

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

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.



Ok, but then you have to enter every serial number at time of
purchase.  I would actually like to support this tracking as an
option, but have it turned off by default.  I.e. if you want to flag a
part as noncomparable then you cannot purchase one without attaching
the serial number to the invoice, one part per line item.

For obvious reasons this is not generally applicable to most
businesses or workflows.  Also, there might be times when doing things
this way might actually violate tax laws in various countries, so the
part would need to be truly noncomparable (i.e. like a custom-built
computer, not like a 1GB stick of PC2700 RAM).


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.


No argument there, but it is not applicable to most environmnets.  I
have added a feature request for the *option* of flagging parts with a
non-comparable flag that would be used to track by serial number, one
to a line item.  Again, few businesses are likely to need it, but
those that do are likely to really need it.


>
> 2)  The proper way
I think that is is bit strong. I might say 'One commonly recognised good
way'


Ok.  Let me rephrase this.  The way mandated by the US-based FASB and SEC....


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


See my points above.  If you are arguing for the option of being able
to track noncomparable items, I am all for that.  If you are arguing
that such should be the default, I don't see how you are likely to get
people to accept the added data entry involved when there is no
regulatory compliance reason to do so.


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



No.  This is a different problem and has to do with cost and inventory
accounting when assemblies are stocked.  It is a limitation of the
current codebase, which is why I said that it was a matter of not
being able to handle it at the moment.

Hope this is clear,
Chris Travers