Re: Why does reposting an invoice affect COGS ?

On Wed, 2006-05-10 at 10:04 -0400, C. Duncan Hudson wrote:
> GeorgeOsvald wrote: 
> > On Wed, 10 May 2006 10:28 pm, Ed W wrote:
> >   
> > > Well, I guess that there is probably an issue with breaking the logic
> > > into two transactions, but it would appear that the logic that:
> > >    "re-posting a committed transaction does *not* release the items back
> > > to stock and then allocate new items"
> > > ..is at least as correct as the current situation of putting them back
> > > into stock and then looking for the oldest items in stock *excluding the
> > > ones which were on the invoice a moment ago*
> > > 
> > > It seems to be the last part which feels like a bug to me?
> > > 
> > > So to be clear: if you repost an invoice then the invoice looks for the
> > > oldest item in stock *without* putting the current items back in stock,
> > > links the things together and *then* puts the old items back into stock
> > > to be available for another invoice?  This appears to guarantee COGS
> > > problems if you ever post an old invoice?
> > >     
> > 
> > Why would a sale invoice put anything back into stock? Sale invoice only 
> > removes/sells items from stock. If you want to put anything back you will 
> > have to make a vendor/purchase invoice.
> > 
> >   
> The items are being put back into stock so that when the invoice is
> reposted you don't consume double the inventory quantity on the
> invoice.  The issue at hand is when should the items be returned to
> stock - before or after they're used again for the repost.
> > > What are the barriers (both coding and ethos) against leaving the
> > > transaction hooked against the same inventory when reposting, OR putting
> > > the inventory back into stock before reselecting on a FIFO basis?
> > > (nested transactions?
> > >     
> > 
> > Do you expect this to be done only for old invoices that you will decide to 
> > re-post or for all invoices including the new ones? How would the system know 
> > the difference? If every invoice places items into stock before removing them 
> > you will never sell anything and the inventory will stay the same.
> > 
> > The solution is very simple: "DO NOT REPOST!" Make a correction invoice 
> > instead.
> I wish that was an option for me, but there are just far to many
> changes that require reposting.  Now, if there was an easy / automated
> way to void or reverse transactions I'd be all for not reposting.
> Unfortunately, when you're dealing with invoices that are many pages
> long reposting is the easiest solution.  I'm all for adding 

This means you seem willing to accept errors in COGS.  Reposting an
invoice is the issue here, which is *not* AFAIK in accordance with
"Generally Accepted Accounting Practices (GAAP)".   If the software
follows GAAP and you do not, then you have to accept errors that are a
result of your doing something it is not designed to do.

Easy has nothing to do with accuracy, and in many cases has everything
to do with errors. Maybe the fact it is hard to fix would encourage
someone to do it correctly the first time, every time.

Software that is used as designed with no errors cannot be blamed for
errors that occur when it is used in a way it is not designed for.
Admittedly, there could be hard coded into the software a strict
requirement to use it only the "correct way" and thus an inability to
use it the "easy way", but education, strict policies, and adhering to
standards would solve most of these problems.

> $dbh->commit() mid transaction - that would be wonderful as it would
> finally make the COGS figure something that I could use.
> 
> Duncan