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

Re: Thoughts on Voiding Invoices

On Sat, 2006-09-23 at 10:10 -0700, Chris Travers wrote:
> Invoices that are posted have no post button, but have a "void" button
> and a "returns" button.
Sounds good so far.
> The purchase is assumed to be extremely recent,
That assumption represents an bug due to faulty analysis.
>  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.
>   I can't think of
> any situation where this will get you in trouble so I am going to
> stick with it. (In those cases where the workflow is sufficiently
> broken to create problems, the void and original invoice are flagged
> so an accountant can easily spot the problem.)  Note though that under
> certain circumstances the reversed COGS numbers will be different than
> the actual invocied COGS numbers if a lot of invoices are issued at
> once and then one in the middle was voided.
This seems contradictory.
> A returns button will bring up a new invoice with all the parts as
> negative.  THe clerk then adjusts he number of the parts and creates a
> new invoice.  These parts are bought back at last cost, and the
> invoices flagged for easy review.
Same bug here being introduced. If I sell you an old hat, and you return
it, its irrelevant that the new hats now cost me twice as much.

>   Long-term, we probably want to have
> additional logic that prevents multiple returns of the same item, but
> baby steps are best.
As I noted earlier today at Discussion Forums: Help, Assemblies
what is the scope of LedgerSMB? How far past general accounting and into
operational support of manufacturing might you want it to go? How about
defining scope and a roadmap for possible extension?