Re: On Hand correction

[Chris Travers <..hidden..>]

On Thu, Feb 19, 2009 at 11:08 AM,  <..hidden..> wrote:
> It seems no one has a fix for this COGS thing still, I started using SL
> since 02. It is critical and I can't imagine how many real customers it'll
> bring with a fix. Ideally speaking, if the logics were there, then there
> should not be an issue with COG. However, since there are not, may be the
> whole approach with calculating COG at real time is wrong (or just too
> difficult). We basically had been calculating COGS at monthend and make a
> jorunal entry to correct the number at that time. With the current codes,
> it is suggested that when a part is being returned, perhaps it should be
> returned via a vendor invoice so it won't break the FIFO/COGS logics. That
> just wouldn't do for our business as we do have quite a few returns where
> reversing a sales invoice is often and necessary (these sales/credit
> invoices are also available online as paperless invoice for our customers
> and they are not vendors nor do we want them to be).

We have fixes in place in 1.2 for returned parts COGS calculation.
However, what we REALLY need to do is rewrite the invoice/parts logic.
>
> As for the on hand calculation, we always do a count by comparing the
> vendor and sales invoices and make an adjustment via psql (we no longer
> have the need to do that anymore since we have kept a tight system).
> Keeping the system tight has been nice as it allows us to offer real time
> inventory check from the parts table for our online store.

I haven't tracked down when the on-hand variances occur.  However, I
think that storing this data as a live summary is a bad idea.  What I
would like to see is a checkpoint at last physical count, and a
calculation from there based on sales data.  This makes things a
little more complex in terms of assembly handling, but it would be
preferable to what is there now.

Hope this helps,
Chris Travers