[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: reposting invoices

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 <..hidden..> 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
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel