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
