You are right, my solution is not GAAP-compliant. I'll try then to define why COGS is wrong in my opinion. 1) I create a new product. 2) I insert a ap invoice witch contains a quantity of 1 from that product at a price X. 3) I insert a ap invoice witch contains a quantity of -1 from that product at a price X(resulting price -X). 4) I insert a ar invoice witch contains a quantity of 1 from that product. This invoice should have no COGS, but it does. The COGS is X. The problem is that the "allocated" field is not updated at step 3), for the ap invoices. And this way the product will be allocated on the ar invoice.
I must find a solution as fast as posible to this problem, so I'm willing to make the necesary modifications if you agree. Can you please detail about how you see the solution for this? I don't know exactly what you mean here: "This means: that one essentially creates a reversing invoice and then creates a new one automatically." Following GAAP-compliant I see it like this: 1) A ap invoice is posted with a negative value for a product. 2) The post_invoice function automaticaly searches for unallocated entries(qty!=allocated) in the "invoice" table for the same product, at the same price. The "allocated" field is updated to match that 2 entryes. Thank you. Chris Travers wrote: > On 7/7/07, Victor Sterpu <[EMAIL PROTECTED]> wrote: > >> I must implement a way to repost invoices, mentaining the correct COGS. >> I'm thinking to do this by creating a new table where too keep all the >> necesary information. >> Are you interested in adding this functionality in ledgersmb? >> > > No. Reposting is not GAAP-compliant under any interpretation of GAAP. > You lose too much of a paper trail this way. > >> Why do I need to repost a invoice? >> Suppose there is a wrong date, invoice number or even a price on a >> vendor invoice. >> To correct this I should make a reverse invoice, and then insert the >> correct invoice. >> But this will rezult in some wrong COGS posted. >> > > It shouldn't. You should get two reversing entries that cancel > eachother out (the new invoice and the reversing invoice). Any other > behavior (even in 1.2) is a bug. The reversing numbers are > meaningless in 1.2 but they should cancel eachother out. > > >> So the easiest way is to make it possible to repost invoices. >> > > I am working on a solution for 1.3. My general plan at the moment is > to try to create a more generic system. This means: that one > essentially creates a reversing invoice and then creates a new one > automatically. > > However, I guess the issue at the moment is that we need to define > what correct COGS behavior is when an invoice is partially or > completely reversed (yes, you could issue a credit invoice, reversing > part of a sales invoice due ot goods being damaged in shipping, or > example). > > My own sense (IANACPA) is that a credit invoice should essentially > reverse COGS from the back of the queue except when using serial > numbers to identify noncomparable items (which we don't upport yet). > > Best Wishes, > Chris Travers > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Ledger-smb-devel mailing list > Ledger-smb-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel > > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
