Hi > In short there is no accepted solution to the problem because the > problem does not exist in an accepted process. >
Certainly there is an obvious "solution", which is when reposting the invoice to use the same COGS values, unless the quantities have changed. Now, ok this still leaves the question about what to do when quantities change, but at least we have now solved the main situation What to do in the case of changing the quantity is dependent on whether we use FIFO, LIFO or average cost. If we use FIFO and *add* items then without reposting invoices all we can do is keep our current COGS and add the next fifo cost item. With FIFO and we remove items then unless we tracked the individual item costs then we have to make some assumptions Does LSMB not tie the sales and purchase invoices together though? I thought we were actually tracking individual items to generate COGS? Anyway the issue is completely moot because we STILL need to do a very similar process if the steps are to reverse the invoice and post a new one! No matter how you cut this, if we need to fix an invoice then it makes no odds from a COGS perspective if we repost or reverse out and post a new invoice. > One option would be to restock the part at the value it was purchased, > but you don't always know this value, I thought in the case of LSMB we *did* know this? Certainly it's only an issue with FIFO if remove quantity. For same quantity or an increase we can at least start with the previous COGS > Furthermore, rewriting the inventory control structures to use average > cost is not going to be any less work than creating scripts to > automatically handle the GAAP issues in the requested workflows, and > would certainly be more disruptive. > Actually different countries have different requirements, so at some point having the option to choose would be nice to have on the TODO list. I think in many jurisdictions you can pick either though? > The solution is not to say "we don't care about GAAP or about proving > the most useful numbers" but rather "people want to be able to do > something by clicking on a single button, so let's give it to them, > but do so in the right way." > I really think we are missing the point here. The above is entirely irrelevant in the sense that we have the same problem when generating a quote, when generating an order and when generating an invoice. The point is at some point in time we need to lock down the inventory and allocate some COGS - it's entirely arbitrary that this is done when "posting an invoice", it could be done at some later point, or we could have a two phase post. eg it would not be unreasonable for it to be a somewhat dynamic allocation which is locked down as part of a monthly reporting process, etc... I think if we can collect the use cases here then actually what is being asked for is NOT the ability to edit all invoices arbitrarily. I suspect that it's just a case of a bunch of minor edits, and possibly some additional workflow steps which could be called "proforma" or something similar. Also the main complaint that smaller businesses have (me) is that the reversals get in the way of auditing and understanding the history. In my case I sometimes have to correct invoices that were entered wrongly for really minor things, eg no serial number, or a red widget instead of a blue widget. It's nice to have the history show only the "reality" and not all the incorrect invoices in the middle, ie I really don't care about the wrong "red widget" invoice if the reality was that we sold a blue one and it's normally annoying to see the red widget invoice (I don't disagree that we need to be able to reproduce it forever if required under GAAP, but it should at least drop out of the normal workflow) I suspect with the above in mind we can actually solve the use case with a lot less work than a major rework? Regards Ed W > Best Wishes, > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Ledger-smb-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel > ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Ledger-smb-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
