[TRUNK] We have already all states in modules for 4 countries.

Please let me seize this occasion to mention that last year I started a
project regarding all sorts of official lists and nomenclatures :
https://launchpad.net/openerp-nomenclatures.
For the moment it only hosts tha EU's activity nomenclature, but it
would be a good place to hold "big" datasets like states and postal
codes worldwide.
I'll be happy to share ownership of this project if someone feels like it.
Lionel Sausin.

Le 08/12/2012 08:11, Nhomar Hernandez (Vauxoo) a écrit :
> New question #216251 on OpenERP Addons:
> https://answers.launchpad.net/openobject-addons/+question/216251
>
> Hello.
>
> OpenERP by default has states just for EEUU, we can make a merge proposal for 4 more countries (All latinamerican ones) where we develop the toponymous for our customers.
>
> What is the correct way to make a merge proposal, it is really sad that Just EEUU appear in data ;-)
>
> I think in we have options what is the most correct way to do that:
>
> 1.- Propose a new module l10n_ISO_states just with this data.
>
> GOod point:
> THis is cool because you will be able to install JUST the data you need.
> Bad Point:
> Openerp will increase them number of modules just for data it is not usefull at all.
>
> 2.- Propose a base_states module, with some kind of wizard "Ala languages" where states are installed asking first what you need.
>
> 3.- Propose an extension to base (adding a new xml file to server) with the states per country and develop a wizard like point 2 or simply install it.
>
> 4.- Have a community project called "states_in_the_world" and we the community will add all states taking off this feature from core.
>
>
> With the new way to customize how addres will looks like in reports i think is a good oportunity to have this improvement.
>
> What do you think?
>
>
>

Hi Nhomar,

in the first place, it seems to me that OpenERP only contains states for the US, and for no EU country at all[1]. But that is no less sad, of course.

IMHO it would be better to contribute the data in the base module through merge requests. You probably will not want to have to install 187 modules just to get the states of all countries, or having to install another module simply because your business gets a contact in a new country.

Regards,
Stefan.

[1] http://bazaar.launchpad.net/~openerp/openobject-server/trunk/view/head:/openerp/addons/base/data/res.country.state.csv

Oh, if the choice is between one community module and 187 community modules then a single community module is fine too. No need to bother OpenERP devs with a miriad of trivial merge requests on the base module for this purpose.

I think OpenERP should not contain any states by default. It might already be too much data for a company to have the whole list of countries, when their customers and suppliers are national.

Regarding each module providing the list of states, there is already a de facto standard for their name: l10n_XX_toponyms. Search for toponyms on http://apps.openerp.com and you'll see.

Hello maxime I know the typonomous facto srandard.

But several inconvenience are if we dont have inside the core or a minimal
base of data structure.

I passed 4 options. Im totally agreed about all data preloaded is bad.

In the list a good option appear. But what im looking for is that the base
modules manage in the best possible way this generic minimal data and avoid
to as much people as we can expend time in this no-brain need.

Thanks for your opinion
On Dec 8, 2012 12:31 PM, "Maxime Chambreuil (http://www.savoirfairelinux.com)"
<email address hidden> wrote:

> Your question #216251 on OpenERP Addons changed:
> https://answers.launchpad.net/openobject-addons/+question/216251
>
> Maxime Chambreuil (http://www.savoirfairelinux.com) posted a new comment:
> I think OpenERP should not contain any states by default. It might
> already be too much data for a company to have the whole list of
> countries, when their customers and suppliers are national.
>
> Regarding each module providing the list of states, there is already a
> de facto standard for their name: l10n_XX_toponyms. Search for toponyms
> on http://apps.openerp.com and you'll see.
>
> --
> You received this question notification because you asked the question.
>

I think that 1 module should contain all the data of all countries and allow the user to load any country's datas through a wizard that can be run as many times as needed.

Having everything in core by default sounds overkill for businesses working locally only.
Having each country in a separate module sounds overkill from a number of modules perspective.

@Fabrice, its better load data from each module, like account chart is specific by country, like states.
IMO another *_data.xml in l10n_ec solves the problem.

The l10n_XX has data context oriented but not only in account chart way.

Regards,

Hello.

After talk with other community members, and after read several comments, some points come out.

1.- Use l10n_xx to load data for states is a wrong a dirty solution, it make us install a COA that we will not need.
2.- Some l10n_xx modules have already data for states, until now it has been good, but not well documented and even we see this data just until now.
3.- ONE module that ask for the country you want to load states is good enought.
4.- This module can be feeded from some generic origin of data, BTW some options come, we have until now just one, but for ca it is buggy, i think we need more options.
5.- We have already data for something like 20 countries, someones already in core (a bzr "mv" solve the problem) and other ones in some community branches.
6.- The best option here is load data in english and manage translations : i.e. l10n_cn has data in chinese, it is incorrect from some points of view, the state name must be managed from translations, BTW there are just 20 or 50 states per country, It is not to much dadta to translate.
7.- Some members of community offered build the module.
8.- Other members offered audit them own countrys, with just a good policy about data format is enought i think, to avoid csv mixed with xml or yaml.
9.- IMHO it can be a base module with the server (like translations), but a module base_data_states is enought.
10.- It can be a the first step to other thing deeper, like lower level country divisions,but this is other history [not for this topic, i think we must go step by step].
11.- In migrations, (info for openerp and other community migration plataforms) you just need to manage the no-load for this data in old databases because probably every company solved in differents ways this things.

Then, We estimate 4 hours to build the base_data_states module, we can start with it, i just need the opinion from OpenERP R&D team to be sure it will be merged, or the official opinion of it will not to manage our own way to do thing in community, both answers should be cool, BTW probably introduce a new feature like this just before the release they can consider dangerous and we can expect the merge for next release too.

This module estrategically will be signed by us as:

Author: "Openerp Community"

We will not sign as Vauxoo, because we will make just the base and VE - MX - CO states, and copy the actual ones we find in the community.

If Odony or Fpopnerp has some different opinion or think the actual platform has some better solution we are all eyes to read.

Regards and thanks for the feedback.

@Nhomar: +1 for everything you said.

I would add a few remarks:
- I don't think relying dynamically on an external source (eg. the webservice from geonames) is good, because we then depend on something we don't control. The day it stops or disappears or if it's down, the users are stuck and we have to do everything all over again. It doesn't prevent to copy from it though. I think that if the structure of that 1 module is clean, it will be very easy for any other contributor to add his own country/states/... to it by copying existing ones.
- It would be sane to wait for a "go ahead" from OpenERP R&D to make sure it fits in the big picture. But nobody should care about whether it will be merged considering it will be available through the Apps platform, and if it is good and used, it will be visible and maintained (thanks to the new Apps platform).

About this:

>>- I don't think relying dynamically on an external source (eg. the webservice from geonames) is good, because we then depend on something we don't control. The day it stops or disappears or if it's down, the users are stuck and we have to do everything all over again. It doesn't prevent to copy from it though. I think that if the structure of that 1 module is clean, it will be very easy for any other contributor to add his own country/states/... to it by copying existing ones.

+1 Thanks for the remark, i forgot said this explicitly, but this is the main idea, pull first commit with first XML from some web-service available, there are 2 or three i think, we must just decide the besst and make the first bunch of xml files.

After this by bug reports and MP we can manage the updating.

About this:

>> - It would be sane to wait for a "go ahead" from OpenERP R&D to make sure it fits in the big picture. But nobody should care about whether it will be merged considering it will be available through the Apps platform, and if it is good and used, it will be visible and maintained (thanks to the new Apps platform).

Am agreed, the only issue i see with this option is that the evolution of OpenERP will not consider this "Community Module" and if it is not merged in the core respecting OpenERP policies, it can be forgotten for future versions and the official migration platform, and being a core data system i really prefer in this case that it can be merged.

But BTW as you say, we will wait the R&D team PoV ..

Thanks again Fabrice for your comments.

+1 for a base module Nhomar, Thank for the initiativ !

This question was expired because it remained in the 'Open' state without activity for the last 15 days.