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 <[EMAIL PROTECTED]> 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: 322 > > >> Then 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 <[EMAIL PROTECTED]> 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 >>> 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 >> >> > > ------------------------------------------------------------------------- > 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
