On Sat, Feb 21, 2009 at 6:23 AM, Ed W <[email protected]> wrote: > 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
So, if you aren't enforcing directory transversal, what happens when you delete an invoice? Also note that, in the inherited codebase from SL does a repost as a deletion and then a post-as-new. If we really want to do a repost, along these lines it will require rewiriting substantial functionality in the invoice logic. > > 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 Given the amount of effort it would take to rewrite the inherited code to support this, why not just rewrite the entire invoice system (as we are going to do for 1.4) and provide draft/1-button-reversal-and-post-new capabilitity? > > Does LSMB not tie the sales and purchase invoices together though? Not directly. It just tracks allocated items for COGS purposes in sales and purchase invoices. > I > thought we were actually tracking individual items to generate COGS? Here is the way it is tracked now (showing both sales-before-purchase and purchase-before-saes): I purchase 10 widgets at $0.10. Records $1 in inventory, etc. in the acc_trans table Records 10 unallocated, purchased widgets in the invoice table at $0.10 I now sell 15 widgets at $1 each. Records -$1 in inventory, $15 in income, $1 in cogs. Allocates the 10 widgets from my purchase invoice. Adds 5 unallocated sold widgets in invoice Now I buy 10 more widgets at $0.20 each. Records $2 in inventory, etc in acc_trans table, adds 10 unallocated widgets in invoice table Then it: allocates five of the widgets from this purchase invoice, Adds $1 to COGS, -$1 to inventiry, etc. alocates the unallocated 5 sales invoice widgets So all that is tracked is how many widgets have been used for cost calculation, not which invoices they are attached to. > > > 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. Right. The advantage though to a reversal is that the old invoice is still on the books so adjustments between the old and new cogs values can be posted. :-) > >> 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? Ok, take the instance I mentioned above, where a 15-item sale hits parts at two different cogs rates. This could correspond with 1 line item (if all 15 were available then), or 2 line items (if not). You don't have a 1:1 connection between a sales invoice line, a purchase invoice line, and a financial transaction line-item. Also since direct linkages between sales and purchase lines are not handled, this means one cannot safely guess which older ones to unallocate. The only thing that can be done is to reverse the old invoice, post as new, compare COGS values, and post an adjustment. > > 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 Correct to an extent. > > 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? Correct on this point, but then one has issues. If FIFO breaks when one reposts an invoice and that is supported, than can we support FIFO inventory handling? I think the correct approach here is to focus on supporting workflows and end-user functionality but insisting that the financial side is handled in GAAP-compliant ways. > 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. Not at all. The idea of draft invoices would do EXACTLY what an order-to-invoice structure does: Not calculate COGS, etc. until we are ready to post to the books. We don't worry about COGS on quotes and orders because we don't accrue income or expense when those are entered. This means you would be able to save an invoice as a "draft" without doing any financial calculations, etc. Review it for errors, and once you are sure there are no errors, post it to the books, calculating COGS, etc. At this point, I am within a couple of hours of having this functional in 1.3. > 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. No, it is not arbitrary. It is the definition of accrual-based accounting. Income and expense are accrued when an invoice is posted to the books, and an invoice is posted to the books when all work has been done in order to earn that income. However, this is splitting hairs in one respect because the idea that one can only POST an invoice and not SAVE a draft for later approval is entirely arbitrary. I suspect this is what you mean, so the above paragraph is really only to clarify the requirements. I can tell you that by the end of this weekend, it will be possible to do batches of invoice vouchers and invoice drafts along these lines in the 1.3 codebase. Currently 1.3 only supports drafts and batches for payments, gl, ar, and ap transactions. Adding invoice support for this would effectively resolve your issue without running amok with GAAP. Once more, to re-iterate how this would work: You can create an invoice, enter all information and save as either a draft or a voucher. Depending on how your system is set up, either you or someone else can come along, verify the information in the invoice, and post it to the books. Invoice drafts can be reviewed for accuracy or have corrections made prior to posting. Vouchers could only be deleted or posted as part of a larger batch. > 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... So you would be proposing going through and, at the end of the month, backfilling COGS info? How would the loss of real-time reporting in that case be worth the gains if we already had draft/voucher stuff for invoices in place? How would that compare to creating all invoices as drafts and then at the end of the month reviewing them for accuracy and posting them? > > 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. "Draft?" Ok, at this point, I think we need to postpone this discussion until 1.3 is at least more usable so people can take a look at how we are looking at addressing this in 1.3. The basic thing is that the need for error control on invoices will be addressed in 1.3 along lines which allows folks to be able to edit the invoices after they are entered but before they are posted. This isn't just an issue with smaller businesses though. There are valid reasons for requiring this sort of thing in the mid-range too. There are two basic problems: 1) I enter an invoice, and get the information wrong. Oops? Now I have to reverse? 2) I hire you to be my bookkeeper. You enter bogus invoices and print yourself checks. The solution we are working on addresses BOTH of the above issues by allowing one to require: 1) That an invoice be entered, double-checked, and approved before being posted to the books and 2) Depending on the setup, that the original individual who entered the invoice might not be able to approve it. Of course, in some environments, you might or might not want to do things this way. POS invoices for example, might be posted directly. Hope this helps. Chris Travers ------------------------------------------------------------------------------ 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
