Sometimes we need to group countries (by continents, members of European community, members of an international organization, …) for reporting or statistical purposes.
Why is the country group code required/usefull for?
We need to add some start_date and end_date to the relation of countries of a group.
This allows some countries to leave a group on a given date (we had a recent example with Brexit).
I think its interesting to give some defaults values. Could you give more info on how such module can be used to fill the data?
Also I’m not sure if it’s worth having a separate module. I’m wondering if it won’t be better to just add the models on the country module and extend the import_countries module to fill such data. This way we will avoid having two separate script for loading the same data.
Not sure is useful. We don’t predict the future. Brexit is an isolated case. Most of the time groups exists and there’s no validity date. I mean, a country will not leave a continent and also there’s no versioning on the group. (European community V1 with Great Britain, EC V2 without Great Britain). Seems easier to manage manually such cases (which, i think, are not so frequent). You don’t know if Belgium will leave NATO or if spain will join OPEC…
Some defaults values could be the continents and doing the association of countries on each continent. This could be done in a script like import_countries and with python-restcountries · PyPI which allows to get continents and the countries related. Some other regional blocs are also referenced on this API (European Union, Pacific Alliance, …)
Code could be useful for reporting (using EU, OCDE, is shorter) but I don’t think it should be mandatory.
I tend to agree with @pokoli here a starting and ending date of membership is useful. A part from the continent case where for obvious reasons countries won’t leave them (at least until the tectonic plates crash one into the other) I don’t see organization that can not be joined or left by a country on some dates.
Indeed but most of the time you don’t know the dates. So those fields will most always be empty or there’ll be more work to renew all the ending dates than adding/deleting a country from a group.
I have the impression that the starting year is usually known in advance (because there is a process to join those supranational instances), the ending year could be a bit more blurry (eg Northern Ireland is still part of the EU for some stuffs while the rest of the UK isn’t).
For me the country groups we are looking for, we know precisely the dates. For example we know the date each country entered in the CEE/EU. And we know exactly the date when UK left it.
Why renewing ending dates? If there is no ending date, it will be empty and there is nothing to do.
For me it can not be a Many2Many because a country can be in a group over different periods.
For example France left the executive integration of NATO in the 70th and join it again in 2009.
I’m wondering if “Organization” is not a better name.
Agreee, it should be a One2Many with the dates. And we should allow the country to join/leave multiple times and also setting a relation with empty start and end dates (this will be the case of continents).
One question that it raises. Do we need to have an active field that hides the countries that are not applicable to the current date?
Indeed a continent is also an Organization, a geographical organization but a organization.
As the target of the relations will be CEU/EU, NATO and other country organiztion it make sense for me.
It depends on the company and the business, many of our statistics are based on continents… Some shipping costs could be also linked to continent or reports about exportations. So continent should be considered in this group otherwise we need another feature to add continents but it’ll be similar to this feature.
Such reporting is not really based on geography because many countries are on at least 2 continents (Turkey, France, Egypt etc. more) so there need to be choices.
And I do not think it can be used the organization design because it requires uniqueness for each country.
So for me it should be an upper level to country for example region which could be included in the sale reporting per region (which can not done with organization).
Could you provide examples? For me the shipment cost is based on the carrier and the addresses.
For me legal reports are not based on geographical properties but on commercial organization like intrastat is based on CEU.
IMHO the geographic aspects of grouping countries are not important for everyone.
What we are looking for are trade agreement zones or trade blocs.
IMHO this is the best description, but not restricted to reporting.
here I would expect different shipping costs coming from the carrier e.g.:
Inland (e.g. Italy)
European Union (here are all countries of EU collected, but not from geographical Europe)
North America (e.g. only USA and Canada)
…
But this grouping can vary from carrier to carrier.
The country grouping can also be useful for matching countries in country groups. E.g. on applying the correct taxes and accounts used in tax rules account_tax_rule_country.
I did not yet see a carrier that follow existing country organization for their cost.
It seems logical that the cost is mainly based on geographical distance. So for me the current “From/To Country” is good enough for the majority of case.
I guess we could complete the model to include country organization as rule criteria.
