Draft:Multi-Currency

This is a draft to describe how a mutli-currency module can be designed.

= Way of working for a Quick feature called "Multi-currency Light" = With this module, user have to convert manually data it will input into lines into its default currency (all input are done in the same currency). It just contains a feature to input another currency and a rate into the "generate document" form to multiplicate values on documents (PDF or other) by this rate and show the new currency.

Rules to build feature That's all.
 * Multi-currency light should be a feature dedicated to a module (we enable feature by enabling a module)
 * A new field called "currency" should be added into table of elements (invoice, order...). It should be linked to table llx_c_currency and contains currency code or NULL (NULL means same currency than default). A code XXX means the currency used to input data was XXX.
 * A new field called "currency_rate" should be added into table of elements (invoice, order...). Value will contains tax rate used when the element was created.
 * An input field is added into the form "Generate invoice" with currency rate and combo list with new currency.
 * Invoice is generated with new values rounded to nearest. We saved the 2 values into the 2 new fields to "remember" and suggest values into the Generate document form later (to be sure to use same values).

= Way of working for Complete feature called "Multi-currency Complete" = With this module, user define the currency of the invoice (and convert rate) when creating the invoice. Then when it enters data, data can be entered into default currency (called DDD) or original currency (called OOO). This occurs when the price must be fixed for foreign currency and must be converted to be into default currency. Data are saved with original values and calculated to be saved into default currency of user. This occurs when the price is fixed into default currency so selling prices is varying according to rate. In both cases, data into original and default currency are stored. Original data are used to build documents and to show information on screens, converted values into default currency are used to make accountancy (accountancy is always made into one currency that is the defautl currency of company).
 * If input is done into original currency:
 * If input is done into default currency:

Rules to build feature:
 * Multi-currency complete should be a feature dedicated to a module (we enable feature by enabling a module)
 * A new field called "currency_rate" should be added into table of elements (invoice, order...). Value will contains currency rate used when the element was created.
 * Two new fields called "currency_input" and "currency_output" should be added into table of elements (invoice, order...). They should be both linked to table llx_c_currency and contains currency code or NULL (NULL means same currency than default). There is two fields because there is two situation to input data:

Situation 1: Data are input into currency OOO:

A code OOO into currency_input means the currency used to input data was OOO, in such case, currency_output should be OOO too (we enter data into currency OOO, and we want to see value into currency OOO too).

=> Question: How to deal with total of payment that may differ from required amount because currency rate was not same ???!!!
 * When a new element (invoice) is created, field currency and currency_rate are asked to user with other information. We suppose user input currency=OOO and currency_rate=0.1234 (currency rate is rate when we enter data).
 * Currency rate can be filled automatically after currency is type (Ajax call), if rate has been defined into "Config - Setup - Currency rates"
 * When a new line is added, we suppose that value entered are of currency OOO and rate 0.1234. New fields called "subprice_orig", "total_ttc_orig", "total_vat_orig" and "total_total_ht_orig" should be added into table of lines of elements (invoice lines, order lines). Values will contains unit price, total, vat amout that was input when added a line (so into currency OOO). We convert input values (so in currency OOO) using the rate 0.1234 and we saved data into lines into _orig field with value of input and into standard fields (total, total_vat...) with values after convertion into default currency. So all data into fields total_xxx with no prefix _orig (fields used for accountancy) use the same currency that is the default currency of company.
 * Value saved into fields _orig must be rounded with same number of decimal than setup defined (setup of unit_price for subprice, setup of total of total_xxx_orig).
 * It is not possible to have some lines into an invoice with a currency and others with another currency. Currency is same for all the invoice.
 * Goal of fields _orig is to generate PDF invoice with currency OOO.
 * It is possible to edit rate, this will reedit value of fields total_xxx of lines and total of invoice but fields total_xxx_orig are not changed.
 * When a payment is done, we have choice to enter data into OOO or DDD and we can input currency rate for the payment (that may differs from currency rate when creating invoice).

Situation 2: Data are input into currency DDD but must be reported into OOO:

If input information were into default currency of company, then currency_input should be DDD and only currency_output should be OOO (we input data into currency DDD but we want to build document into currency OOO). Do we need this situation 2 ?

= Comments for discussion =

I think that in any company the workflow is quite same as proposal, order, delivery & invoicing then accounts consolidation.

Multi-currency module should manage proposal, orders (client & supplier) and invoices (client & supplier), I hope that you agree with that.

For someone (like us) who need multi-currency, that’s because we are in business with foreign clients or suppliers,, so when it comes to talk and to discuss prices, we always talk in the currency that will be used to make the deal (whatever a sale or a purchase), so actually we talk in what you call “OOO”.

So for sales: we send proposals, receive orders, and make invoices all in OOO, we type all amounts in OOO,,, we never type amounts in DDD unless the documents are DDD of course (in this case no need to talk about multi-currency as DDD is the company basic currency) !

It goes in the same way for purchasing.

That means that if you deal for an amount of let’s say USD100 whatever with a client or a supplier, then you will type the current exchange rate to get it stored and you type USD100 to get exactly USD100 displayed on the generated documents (proposal or order or invoice)… You cannot deal on USD100 and then later type DDD EUR80 with exchange rate 1.2489 and finally get USD99.91 displayed on the documents You cannot deal with a foreign client or supplier in your own DDD currency and say that amount in OOO will depend on the exchange rate at the date you’ll place the order or send the invoice


 * So finally we do think that the quick feature “multi-currency light” is useless as we don’t know anybody in international business working like that.

What should be recorded among other information are the OOO amount which is typed, the currency of that OOO amount, the exchange rate and the current date.

Then only the accounting module should show the automatically calculated amount in DDD (calculation based on the exchange rate value used at the date of generation of the invoice), as company accounting is for sure only in DDD.

It should be possible to manage several bank accounts, at least one for each currency. It should be possible as well to have the same account number for several bank accounts as many banks offer multi-currency account facilities (you get a monthly bank statement with the total amount of your company account in DDD with the details of DDD transactions and details of any further OOO transactions). Bank statements report everything for consolidating the bank accounts in Dolibarr.

The difference between OOO invoiced amount and OOO received amount into your bank account is due to the bank fee on any foreign transaction, it depends whether or not the payee took in charge both local and foreign bank fee… so bank account consolidation is quite important feature because finally it happens to have important loss with the bank fees ! (whatever you say, most customers will pay the right amount stated on the invoice but without asking their bank to include both local and foreign bank fee, they are all for you… grrrrrr).

But for each transaction, you get a statement from the bank, so for each transaction you have to manually check the received amount and the bank fees, total should match with the expected amount, if not so you don’t close the invoice as paid until settlement with the customer).

An interesting feature would be to show the difference between proposal, invoice and amount received for operation of the past months (past months only, so after bank account consolidation) all values shown in DDD automatically calculated according to the exchange rate stored at the date of each document and showing the received amount stored after consolidation… so we could easily see and track the exchange losses ! do you get my point ?

Just wanted to share my experience, sorry for not talking llx_ language but I wish this could be helpful.

Thank you very much for offering prior possibility to discuss on that before starting coding, I assume this module will be of a great benefit to Dolibarr.

= More Ideas =


 * We can indicate the currency in the third card.


 * In documents (propals, orders, invoices, etc) if the currency of third is not the same as ours ($mysoc....) we showing conversion rate (editable field) in document tab, always save the currency, linked to table llx_c_currency, and its exchange rate (1 if the currency is the same as ours) in table of document.


 * In document lines we save the price calculated in the currency of third if is a customer, if is a supplier we save the supplier price directly in base.

- If the currency of bank is the same as ours we showing amount of invoice in currency of third, the conversion rate (editable field) and save register in bank into ours currency.
 * For bank payments:

- If the currency of bank is the same as third, we put directly the amount in bank.

- If the currency of bank differs from the two, we showing amount of invoice in currency of third, the conversion rate against the bank currency (editable field) and put in bank into bank currency