Thanks for your work. I could not test it yet but i'm greatfull nonetheless.
On 19 March 2014 08:13, Jacopo Cappellato <[email protected] > wrote: > Thank you Hans: I have some doubts on the approach you have followed to > implement these requirements but I don't have time to propose and implement > an alternative approach. In the meantime I have committed a fix, in rev. > 1579155 for the aformentioned bug that is in the spirit of your design. > > Jacopo > > On Mar 19, 2014, at 2:55 AM, Hans Bakker <[email protected]> > wrote: > > > Hi Jacopo, > > > > Thanks for your work on this. However i implemented it the following way: > > > > 1. The invoice is in the currency of the related party which can be > foreign and can be shown in local currency by calculation, using the > currency exchange table. > > 2. The payment is always in the local currency as received from the > bank. (Reconciliation should be done in the ledger not payment?), if it was > a foreign payment the foreign value is entered in the original currency > field of the payment. When a payment is entered that way having two > currencies, the currency table is updated accordingly using the invoice > date so they always fully apply. This is wrong if you want to record > loss/gain of exchange rate and should be a configurable option using either > the invoice date or the payment date for the exchange rate. > > This foreign invoice is entered in the ledger using in calculated local > currency however recording the actual foreign currency in the original > value in the ledger. > > > > Matching invoices to payment should match the actual currency (not > calculated) of the invoice with the actual value of the payment and when > not the same use the original currency of the payment. > > > > Regards, > > Hans > > > > On 18/03/14 23:18, Jacopo Cappellato wrote: > >> Hi Adrian, > >> > >> I am reviewing the code and I should be able to commit a fix soon. > >> > >> Hans: could you please clarify the requirements that led you implement > all the overly complicated code around actualCurrencyAmount and > actualCurrencyUomId? > >> The intended purpose of these fields was clearly mentioned in the > entity definitions since the beginning: > >> <!-- The ActualCurrency amount and uomId are for the values coming from > the bank (if known) and are to be used for reconciliation and such later, > and not for PaymentApplication. --> > >> > >> According to this, in order to apply a payment to an invoice the > following conditions must be met: > >> * Invoice.currencyUomId == Payment.currencyUomId == PaymentApplication > currency > >> If the Payment was in a different currency than one of the invoice, the > actual currency and amount (in the foreign currency) should be stored in > the actualCurrencyAmount and actualCurrencyUomId (these fields are for > information only); but the Payment.currencyUomId and Payment.amount fields > should always be filled with the currency of the Invoice. > >> > >> Jacopo > >> > >> > >> > >> > >> On Mar 14, 2014, at 3:27 PM, Adrian Stern <[email protected]> wrote: > >> > >>> Here is the link to the bug for everyone interested: > >>> > >>> https://issues.apache.org/jira/browse/OFBIZ-5576 > >>> > >>> > >>> On 14 March 2014 15:09, Adrian Stern <[email protected]> wrote: > >>> > >>>> Thanks for your support. > >>>> > >>>> The question if it is a bug or not the following: > >>>> > >>>> Do you ever need to create invoices in a currency other then your > >>>> countrys. The payments can always be in a foreign currency but would > one > >>>> need to create an Invoice in a different Currency? Since we can set > the > >>>> currency of the invoice i do beleve that it is a bug. What do you > think? > >>>> > >>>> This patch fixes the problem, however i'm not able to predict it's > further > >>>> influences: > >>>> > >>>> Index: accounting/payment/PaymentServices.xml > >>>> =================================================================== > >>>> --- accounting/payment/PaymentServices.xml (revision 1576834) > >>>> +++ accounting/payment/PaymentServices.xml (working copy) > >>>> @@ -185,6 +185,7 @@ > >>>> <condition> > >>>> <or> > >>>> <if-compare-field > field="invoice.currencyUomId" > >>>> operator="equals" to-field="defaultCurrencyUomId"/> > >>>> + <if-compare-field > field="invoice.currencyUomId" > >>>> operator="equals" to-field="payment.currencyUomId"/> > >>>> <and> > >>>> <if-compare-field > >>>> field="invoice.currencyUomId" operator="not-equals" > >>>> to-field="defaultCurrencyUomId"/> > >>>> <if-compare-field > >>>> field="invoice.currencyUomId" operator="equals" > >>>> to-field="payment.actualCurrencyUomId"/> > >>>> > >>>> > >>>> I will file a bug. > >>>> > >>>> > >>>> On 14 March 2014 13:36, Pierre Smits <[email protected]> wrote: > >>>> > >>>>> Adrian, > >>>>> > >>>>> Given that Jacopo concurs that there is an issue, I suggest you file > one > >>>>> in > >>>>> JIRA. > >>>>> > >>>>> Regards, > >>>>> > >>>>> Pierre Smits > >>>>> > >>>>> *ORRTIZ.COM <http://www.orrtiz.com>* > >>>>> Services & Solutions for Cloud- > >>>>> Based Manufacturing, Professional > >>>>> Services and Retail & Trade > >>>>> http://www.orrtiz.com > >>>>> > >>>> > > > >
