No "code" field in "res.currency" object

I am sorry, if there was a field that implements fundamental concept for such a thing as currency, still somebody removes it. And you name it as Wishlist !!! It is a clear regression!

I am sorry, but no, more or less serious financial application would refer to a field holding "Kč" to search for a currency.

What about Japanese currency, why not store the unicode value 円 or 圓 ??? Everybody understands the symbol, isn't it?

I agree with sraps.

We need to export our data to an external accounting software, and there's no way that it will support symbols or custom names.

ISO currency codes are the only viable way to go, and I can't think of any reason why this was changed from v5 to v6.

Hello,

We will consider it to future road-maps.

Thanks.

Sorry, but this is not wishlist / future road-maps.
We need it for interfacing with an external accounting software.

So I went ahead and did it myself.
https://code.launchpad.net/~dieck/openobject-server/6.0/+merge/49239

!!!!!!!!!

What is it, are we talking to a machine or human beings? What road-maps, this is clear regression!

Do you understand the idea:
FIRST - IT WAS WORKING IN SEVERAL PREVIOUS VERSIONS 4.x & 5.x;
SECOND - NOW IT DOES NOT;

c2c_currency_rate_update is dependant on that. It is temporary changed to field name. I hope field code or ISO CODE returns soon and we can revert this change.

Hello Grzegorz

I'm interested in this patch. I will merge the last improvement of the V5 module, and allows it to be python 2.6 compatible.

Regards

Nicolas

Everyone, please calm down, here is the rationale:

It is a convention in OpenERP that all objects that are likely to be linked via a many2one relationship should have a 'name' (or _rec_name) column. For res.currency, we used to have "name", "code", and "symbol". The result was that in many cases, name was equal to code, and any module that needed to refer to a currency had to choose which one to take.. and they did not all pick the same one. But how many different fields do we actually need to describe a currency?
As the bug description is saying, the only way of referring to a unique currency is to use the ISO code. We wanted to avoid the confusion (the "name" was only used as label when selecting a currency) so in v6 the "code" field has been removed, and "name" is now meant to hold the code, while "symbol" is still used to hold the short currency representation to be used in print, usually the currency sign (http://en.wikipedia.org/wiki/Currency_sign).
For example: name="USD", symbol="$" - which should be sufficient for most purposes. This is similar to sale.order's name which is the SO sequence number - the main unique reference to it.

So basically, as part of the migration to v6, modules that used to depend on the "code" of res.currency should now reference the name instead (and those using the name can just stay as they were). If this is what was done for c2c_currency_rate_update, then it's correct.

Therefore this bug should in fact be closed, unless you truly believe that a third field is really needed for describing a currency in OpenERP's core. Maybe we should also convert this bug to a FAQ if you think this is going to confuse many module authors...

PS: we will add a help/tooltip on the "name" field to indicate that it's really meant to hold the code, and double-check all currencies that are shipped with OpenERP to make sure the name really is the ISO code (as not 100% of the currencies had name==code, some codes need to be restored properly).

The additional tooltip was added in server 6.0 with revision http://bazaar.launchpad.net/~openerp/openobject-server/6.0/revision/3348
The following currencies still had their symbol in the name, which was replaced by their code: CZK, HUF, IDR, INR, LVL, PLN, VEB.

On 21. 02. 11 10:43, Olivier Dony (OpenERP) wrote:
> Everyone, please calm down, here is the rationale:
>
> It is a convention in OpenERP that all objects that are likely to be linked via a many2one relationship should have a 'name' (or _rec_name) column. For res.currency, we used to have "name", "code", and "symbol". The result was that in many cases, name was equal to code, and any module that needed to refer to a currency had to choose which one to take.. and they did not all pick the same one. But how many different fields do we actually need to describe a currency?
> As the bug description is saying, the only way of referring to a unique currency is to use the ISO code. We wanted to avoid the confusion (the "name" was only used as label when selecting a currency) so in v6 the "code" field has been removed, and "name" is now meant to hold the code, while "symbol" is still used to hold the short currency representation to be used in print, usually the currency sign (http://en.wikipedia.org/wiki/Currency_sign).
> For example: name="USD", symbol="$" - which should be sufficient for most purposes. This is similar to sale.order's name which is the SO sequence number - the main unique reference to it.
>
> So basically, as part of the migration to v6, modules that used to
> depend on the "code" of res.currency should now reference the name
> instead (and those using the name can just stay as they were). If this
> is what was done for c2c_currency_rate_update, then it's correct.
>
> Therefore this bug should in fact be closed, unless you truly believe
> that a third field is really needed for describing a currency in
> OpenERP's core. Maybe we should also convert this bug to a FAQ if you
> think this is going to confuse many module authors...
>
> PS: we will add a help/tooltip on the "name" field to indicate that it's
> really meant to hold the code, and double-check all currencies that are
> shipped with OpenERP to make sure the name really is the ISO code (as
> not 100% of the currencies had name==code, some codes need to be
> restored properly).
>
> ** Changed in: openobject-addons
> Importance: Wishlist => Undecided
>
> ** Changed in: openobject-addons
> Status: Confirmed => Invalid
>
> ** Changed in: openobject-addons
> Assignee: OpenERP R&D Addons Team 3 (openerp-dev-addons3) => (unassigned)
>
I would dare to say that while you made it confusing, you took out
something which can/could still be useful.

symbol: $
[ISO] code : USD
name: US Dollar. or should I say _(US Dollar) ??

while in my example you might not see the use, just think about chinese,
russian, arabic, hebrew and so on...
not sure that the symbol is "that" useful though... but is nice to have :-)

regards,
bogdan

I'm ok with the solution Olivier described.

But as "name" already get's confused again, wouldn't renaming the field to code (or isocode) and using _rec_name = "code" an option?

When someone needs an additional long name, (like "US Dollar" in addition to USD), that could be done with a module, adding a translatable field like "description". Though I won't argue against having it in base.

Maybe it's worth putting it on http://feedback.openerp.com/, if you need it.

I deleted my merge proposal (see #4) for re-adding the code field.

On 21. 02. 11 13:05, Marco Dieckhoff wrote:
> I'm ok

> with the solution Olivier described.
>
> But as "name" already get's confused again, wouldn't renaming the field
> to code (or isocode) and using _rec_name = "code" an option?
>
> When someone needs an additional long name, (like "US Dollar" in
> addition to USD), that could be done with a module, adding a
> translatable field like "description". Though I won't argue against
> having it in base.
>
> Maybe it's worth putting it on http://feedback.openerp.com/, if you need
> it.
>
this touches deeper levels of thought... :-)

have you heard about the KISS principle? it means just "keep it stupid
simple"!!
of course you can write a "module" for each field actually, but is that
really a solution? i feel that there is already an overkill with over
600 "modules", in the trunk +extra.

however, for a field in a table which NEVER gets large (the no. of
currencies is relatively small and constant) i see no issue in just
adding it.

just a thought, of course
regards,
bogdan

@Olivier Dony (OpenERP)

With all my respect, again and again, I have to note, that such changes should be considered twice, and should be asked a professional tax consultant. Definitely not decided by a programmer.

To sum it up:
1) Name should be real currency name in English (field translatable), eg. "United States dollar";
2) As we see that "ISO code" is a code, then it should be named "iso_code" or "code". As we had it under the name "code", I prefer latest;
3) Symbol is used inside home country only - for local documents, in any other case you HAVE to use currency code;
4) Anyone being familiar with EU tax authority statements, would add the connection to the countries (you know that one currency can be used by several countries), whom official currency it is;
5) If you would have asked any accountant or manager who is familiar with international trade, you would receive an answer that "$" symbol is being shared among several (not to say numerous) currencies, and it is a great value difference between them;
From wikipedia:
http://en.wikipedia.org/wiki/$
/The dollar sign ($), originally called the peso sign, is a symbol primarily used to indicate the various peso and dollar units of currency around the world./

6) Any bank requires an ISO code on any payment order even in homeland transaction, definitely not something like "$" or "Ls";

So you say that any project needing a common fields, should be adding them, do you really think so? Any country that would need basic currency name or correct code, would have to add it? Are you serious, what would happen to module compatibility?

Why regression, because programmer who deleted this field, just had no idea about all of this, one even not bothered enough to take the ISO standard and rename all the currencies according to it.

I am kindly asking, do not disregard this regression!

I am sorry but I will reopen this bug, and will keep doing it until you get serious.

On Tuesday 22 February 2011, you wrote:

> Why regression, because programmer who _deleted_ this field,

If you FAIL to read, that is not our problem. The field has never been deleted,
it was renamed.

So, there is no such bug as "missing field for currency code". And I don't
frankly care if it takes you another 4 months to see it. It is there.

About your point 4). There is no difference of EUR between Eurozone countries,
so your argument is invalid. All these countries share just one instance of
the currency, with same iso_code, description and rate.

About 6), I doubt it. It is not required everywhere.

I am sorry, but it seems that there are problems with literacy (if you like to call it so) on your side, because there is no field which holds LVL or PLN or INR or CZK ... should I continue?

Oh you have changed the name field for the currencies, so why is then the bug report so invalid? Or is it common practice not to fix bugs, but deliberately close them?

Four months? I noticed the problem when I tried to examine of it's feasibility for production. What is obvious that it took you a month to pay attention to this fact, but as it seems you'll have another to fully understand what I am saying.

If the code is present, then show it!

No I am talking about various dollars which are not equal in value still all share "$" symbol.

And if you would take care and examine EU tax forms, you would notice the requirement to express sums in the currency of the country you do business with, not the currency of the particular deal. If you do not care about learning a subject, it is your problem, not mine.

About sixth point - it is a requirement, as you are not able to print on your payment order something like "Ls" or "$", because they are not valid for legal tender, they may mean anything.

@sraps:
Thanks for summing up your requirements. Unfortunately, I still don't see a valid reason for keeping this bug open based on your list. The bottom-line is basically that the 'code' field has been renamed to 'name', so it's not actually gone missing.

From your list, here is what I understand:

1) You think a translatable label is needed, which is what I was not sure about. The old "name" was removed to avoid confusion, but it was not translatable. Do you have some real use cases where having such a label would be really *required*, and thus worth it? Most people are familiar with currency ISO codes nowadays, and as you want these to be printed everywhere, I suppose you expect end-users to be able to understand them too... In any case, this does sound like a debatable wishlist, as others have pointed out.

2) The name of the field was chosen according to conventions, and this cannot be called a bug. If anything, this change just makes it more obvious that currencies should only be referred to by their ISO codes in all circumstances, as you pointed out.
Also, changing the database schema is not allowed in point-releases, so this can only be considered as wishlist for 6.1.

3),4),5),6) Nothing changed in 6.0 about these points, as far as I know. Shouldn't these be different wishlists, or suggestions on feedback.openerp.com where the community can vote about them?

Now, I totally understand that you would like to have been asked your opinion on this change beforehand, and this change probably deserved it. I will spread the word again internally about discussing such changes with the community.
However, if you think about it for a minute, the change was limited to renaming a column and removing one that was not used in any critical place (the label, which used to hold a copy of the code in many cases). Not the typical world-breaking change.
Note that you should also join the openerp-expert-accounting mailing-list where such propositions are likely to be discussed. This is one of the places where professional tax consultants can make a difference.

To conclude, I think you understand that there is no "code" field in res.currency in v6.0 anymore, not because it was removed but because it was simply renamed "name", so no bug there.

Thanks for bringing the other issues to our attention, too.

Show me the thread where it was discussed?

@Nicolas Bessi
I got private message from Eric CAUDAL that he is working on that. I have informed him I am only improver of the module and you are first author. He should contact you.

@OpenERP
It is quite funny to name this "convention". I think it is regression to previous convention. Previously we had "name" and usually "code" field. Usually "name" was for longer name (sometimes with translation) and "code" for abbreviation without translation. Now you moved information from field "code" to "name" and added other field named "symbol" removing field "code".

In ver 5.0 we had always field "name" and we had to guess what is the name of abbreviation field.
Sometimes it was named "code" (fe. account, currency), sometimes "ref" (product, partner), sometimes "description" (tax, tax codes).

Now you improved "convention" to have 4th choice "symbol" and moved abbreviated information to field "name". In my opinion it is regression to former convention. I don't think it was any problem to leave it as it was before.

You didn't make so small evident change as you think. You have made mess. IMHO you should ask for it on openerp-expert-accounting group first. Please ask community before you improve any convention in future.