On 7/7/07, Victor Sterpu <..hidden..> wrote:
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.
You are of course welcome to make modifications to your system, and
you can turn off transaction reversal enforcement. This however, has
known issues with COGS (particularly when prices are volitile) and so
we are working on a more comprehensive solution.
Also I suspect your problem is related to a COGS bug recently filed
(you filed it, I assume)? I expect to have that fixed shortly. When
I do, I will be sending you a hotfix and that may even address your
issue.
Also, if you are interested, the work on debit/credit invoices for 1.3
may also address your issue. We could work on this as well and it
should be backward-compatible with 1.2 so backporting shouldn't be a
problem as long as you are willing to make db schema changes.
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.
That is the idea of the debit/credit invoice structure, except that
this allows one to display positive values for reversing invoices by
setting a flag in the record.
As I say, it might be a good idea to create a solution for this that
could be an add-on patch for 1.2 and a part of the solution for 1.3
:-) I would be glad to help.
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