Yes. Thank you. Chris Travers wrote:
BTW you are correct on the patch you submitted :-) I am applying the patch now and putting through some final testing. Is it OK to include your email in the CONTRIBUTORS file? Best Wishes, Chris Travers On 7/7/07, Victor Sterpu <..hidden..> wrote:I'm sure that a change at line 322 in IR.pm can't solve the bug 1748895. To solve this bug a extra update is needed. I added this : "$form->update_balance( $dbh, "invoice", "allocated", qq|id = $invoice_id|, $qty );" at line 393. The problem is that when a ap invoice is posted and COGS are allocated on ar invoices, the "allocated" field is not updated on the ap invoice. And this way they can be reallocated. Chris Travers wrote:On 7/7/07, Victor Sterpu <..hidden..> wrote:It's true I reported a bug at COGS, but it was a diffrent one. :) I also send the patch for that bug.I am still evaluating what exactly is going on with that one. I just want to understand the patch before I apply it (and this code isn't always the easiest code to understand what a change will do... But that is why we are moving to the new architecture...).As you suspected this bugs are also in sqlledger.Almost certainly. It actually looks like this may be corrected by a a change to the SQL query starting at LedgerSMB/IR.pm: 322Then I will fill in another bug report for what we discussed. I will send a patch for the solution using GAAP(I prefer respecting GAAP also). And this solution is more simple. :) Chris Travers wrote: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------------------------------------------------------------------------- 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------------------------------------------------------------------------- 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------------------------------------------------------------------------- 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------------------------------------------------------------------------- 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