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: 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 <..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