Hi Hans, On Sep 29, 2008, at 1:08 PM, Hans Bakker wrote:
hi Jacopo, please see my comments below.... On Mon, 2008-09-29 at 09:22 +0200, Jacopo Cappellato wrote:Yes,I'd really suggest at least the following in order to make the processmore canonical: 1) the invoice should be created in the currency that the customer expects, the same of the orderThis is required from a commercial point of view and that is how we do it here.2) after that an invoice is generated in one currency, don't convert it....3) if the point #1 is not possible (why?) and the customer reallywants to see the invoice in a different currency, then you can providea PDF version of the invoice in a different currency; the conversion is done on the fly (not stored in the db) for the report, but theconversion rate is dated so that you will get the same numbers even ifthe conversion rate changes over timePoint #1 is fine and required. The Thai government however requires thatall currency in the company is in the Thai currency also the foreign invoices. We also only book into the ledger if the payment is received so we do not have any ledger problems.
Ah, this is an important point: the GL is done in Thai currency (this is very common requirement, not just in Thailand). There is already support for this in OFBiz: accounting transactions originated by events in different currencies from the one of GL are automatically converted using the currency exchange rate of the date of the transaction.
4) if we receive a payment in a currency different from the one of theinvoice: I'll have to think more about the proper solution, but onecould be to convert the payment in the invoice currency and then applyit to the invoiceI cannot convert the payment because everything in the books should be in the Thai currency.
The payment will be posted in the Thai language; howevet it can be applied after conversion to the invoice (but there could be many other options).
Invoices are official documents, and I would be very surprised if there are countries that require you to modify an invoice if you receive a payment in a different currency: this could cause confusionand, as Enrique suggested, GL issues and we should try to implement inOFBiz the most standard processes, especially in areas like invoicing and accounting.we actually do not change the invoice because it can still be printed inthe foreign currency, we only change the internal representation....
Well, you actually change the invoice!
let me also emphasize that this is a facility which is optional and doesnot have to be used.....
Yes, but this is, in my opinion, a common process implemented in a very customer specific way, and I am not sure it is a good idea to have it in the trunk. By the way, maybe I am the only one that is worried... let's see if there are other opinions.
Kind Regards, Jacopo
Regards, HansJacopo On Sep 29, 2008, at 5:19 AM, Enrique Ruibal wrote:Hello Hans, Jacopo I am not familiar with Ofbiz accounting rules yet, but from what I understood I would have to agree with Jacopo in that an invoice (document)shouldn't have to be converted to a different currency in order for apayment in that currency to be applied to. From previous knowledge I can tell you, it is a general practice in ERP systems that the base currency is pretty much tied to an initial setup oraccounting schema, it doesn't depend on a specific party's currency oranything else, rather an accounting gain/loss transaction should be set up in order to keep track of such payments when the currencies are different from the original document. Regards, -Enrique Ruibal -- View this message in context: http://www.nabble.com/Re%3A-svn-commit%3A-r699817---in--ofbiz-trunk-applications-accounting%3A-config--script-org-ofbiz-accounting-invoice--servicedef--src-org-ofbiz-accounting-invoice--webapp-accounting-WEB-INF-actions-payment--webapp-accounting-payment--widget--tp19712499p19717891.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.-- Antwebsystems.com: Quality OFBiz services for competitive prices
smime.p7s
Description: S/MIME cryptographic signature