• From: Hungary
  • Registered: 02/08/2009
  • Posts: 43

Topic: Document language tied to currency

I personally think this is not such a good idea. It would be probably better to introduce a customer doc language (as part of the customer / branch / invoice data) and then have doctext plus doctext_ger, doctext_ita etc.

Problem today is that there are countries like Switzerland where you have CHF as currency but German (mostly), Italian and French as language.

I am currently re-entering my invoices for this year and I have two cases:
A Korean customer with EUR as currency (creates a German doc by default) but should get one in English. And a Hungarian (HUF) who gets German docs plus a handmade HU invoice but no English one.

Or you choose the easier approach and skip the doc languages alltogether especially since there is - even with the current two languages - the problem with payment terms, item texts, tax texts etc.

rgds
rl

  • Registered: 12/25/2007
  • Posts: 2,447

Re: Document language tied to currency

Interesting. English is anyway most used language in international transactions, so we should support at least two options: english and native descriptions. We should consider the idea of additional selector in customer setup.
Janusz

  • From: Canada
  • Registered: 03/08/2010
  • Posts: 34

Re: Document language tied to currency

Hello,

I fond this interesting and I wantewd to see if being able to tie a language to a customer ever materialized into anything? 

I have half and half French/English customers.  I woudl love to see a langauge tied to a customer.

Joe

  • joe
  • Administrator
  • Offline
  • Registered: 03/15/2007
  • Posts: 5,089

Re: Document language tied to currency

Yes, maybe we should put this information on the customer or the branch. We have doctext and doctext2 at present and they are chosen depending on the customers currency.
If we put this information from a combobox (with available doctext) documents then you can copy existing and name them doctext3 ...
This way you can have all the language you want. Default when creating a customer or branch could be existing method.
We retrieve the correct doctextX when printing the document. A candidate for 2.3.

/Joe

5 Reply by smokinjo (edited by smokinjo 03/09/2010 08:05:08 pm)

  • From: Canada
  • Registered: 03/08/2010
  • Posts: 34

Re: Document language tied to currency

Thanks.

If I understand correctly, if a language selction is applied, the invoice and packign slip would pop out in the language of the client?

My question would be if for the product descriptions, if these will be chosen as well when the language is chosen?  This would be GREAT!  If not, this is somethgn that I woudl definitely get integrated into the software.

Joe

  • From: Canada
  • Registered: 03/08/2010
  • Posts: 34

Re: Document language tied to currency

I am planning on working on this langauge thing for my company, but would be interested if others are interested in helping program, or help pay for the code?

This seems to be a big change, but a very useful change, so please let me knwo the best way to proceed.

Joe (the other one)  smile

  • Registered: 12/25/2007
  • Posts: 2,447

Re: Document language tied to currency

Hello,
We are considering change in report language just now, but multilanguage descriptions for items is more complex thing. This needs changes in database structure on meta level e.g. some convention how store item descriptions for arbitrary number of installed languages. If you have some ideas how to implement it do not hesitate to share them  on developers mailing list.

Janusz

  • From: Canada
  • Registered: 03/08/2010
  • Posts: 34

Re: Document language tied to currency

I am not a programmer, but when discussing this idea with other people in the programming community, one thing that would have to be added would be a language option.

Each "description could be saved in seperate table, or column in a table.  Depending on which language the customer is, the corresponding table/clumn(do not know database lingo)  would be shosen.  I do not see having to add a whole new convention, more like adding a a language bit, and depnding on which language, is chosen, the database would send out the corresponding daata.

In my case, I only for see using 2 languages.

In my mind, the language of the report and the language of the desciption would use the same language "bit". 

When you say French, then the database would send out the "french" report interface and the "french" description.


I also want to say that I can also see this happening in two steps.

1) give the option of the report language.
2) giving the option of language choice of the desciptions.

As for working with the programming team, how would this work?  I woudl get an outside programmer to do work for me, but it makes no sense if they do not work with you, so that we have 1 solution, and not 2 partial solutions.

Thanks

Joe

ps.  As for your developers list, where to I find it?