Which is the functionality provided by this module?
What I will like to have is what is explained on the title: “Set the country and the subdivision based on zip”. As we have the information on the system, I think Tryton should be smart enought to pick the right values for the user.
This is false. Nothing tells you that ‘39450’ is not a zip code in Belgium or US or what ever country. It is very much probable that it is a zip code somewhere else.
No it is not correct tho think that. We have partial information (not all the zip code of the world).
Indeed I always wondering if filling order of the address form was right. In some way, it should be just the reverse order from global to local. Unfortunately it is the not usual order of postal format so it may confuse users.
Well google tells me that this code is also available on other countries
We can load all tine world information on the system in case we are interested on all the zip codes.
In my case I loaded the zip codes of Spain in my database to indicate Tryton that I’m only interested on searching this zips. If I want the system to guess codes on other countries I can just load all the countries zips (and then use the country as filter for searching on the zip database).
I understand that the system may guess a wrong country in some cases. If this is the case the user may change the country and then the system will be smart enought to guess the correct subdivision.
This will force the user to enter all the values that can be guessed from the zip (which is already the current situation). So nothing will improve, we will just cause more confusion to the user.
This is the worst thing the system can do.
I already showed that the system can not guess from the zip because it is not a unique code (otherwise we will not put the country on the addresses).
The user experience will be improved because each field to fill will be limited by the preceded values so completion will be more accurate.
I disagree. I think it’s better to have a correct guess for high percentage than nothing. It’s easy to explain:
Furthermore, once the user is used to the guessing behaviour he may start to set the country first to make the system guess the correct value or stop the guessing by set a country with zips not loaded. We let the user give the right information to have the right guess.
Guessing the country will also help local bussines (only one country loaded in zip) while it won’t hurt for global companies (multiple countries loaded in zip table) as the system will leave the code empty when there are multiple countries/subdivions for the same zip.
If you use the following layout:
The user will need to fill the all the values becase:
On the other hand, if we start by the zip and loookup for single entry in zip model we have the following:
Indeed, when there is a unique city for the zip (which is my first example) we can also set the city. Which will be a very big improvement by setting all the address details with a single code.
When it is not unique the user will just pick the city from the autocomplete.
Wrong, in such case the behavior of the user is random. He will maybe notice that wrong data was filled unwittingly so he may correct it (and grumble against the system). He may not notice it and so wrong data will be stored in the system as truth.
So this is exactly what I said. The country should be filled first.
This is not the way to build a general purpose system.
They are never unique. So it will never happen.
This is the same problem as we do no have all the zip code in the world, you can not guess that the value is unique.
If you really want to simplify the address filling, the best option is to implement an autocomplete for addresses as a single input using for example: https://developers.google.com/maps/documentation/javascript/places-autocomplete
And when the system guesses the right value he may adore the system. 
Correct is exactly the same as setting the values. On selection fields (which are country and subdivision) there is no extra click required to clear the value, you just have to pick the right one.
This is the same as if the user enters wrong data without guessing. Nothing that we can prevent.
So it seems we only agree about setting the country first. So if we set the country and then the zip do you think we can automatically set the subdivision?
Shouting negative sentences without any reasoning is neither the way to improve a system. At least it will be great if you give your reasoning why a solution for diferent audiencies does not solve a general purpose system.
I do not see any limitation on the system that prevent somebody to have all the zip in the world.
As already said, for me the system should use the information that it has to help the user.
I see good this way and I don’t think it is gonna to be so confuse for the users…
I agree.
By the way, there are some countries where addresses are written this way on the letters (I know at least Russia)
And because it is a generic problem, I saw several cases where order was reversed.
Just to add some extra information.
Here in the UK, for addresses, it is common for companies to just ask for a postcode and house/building number. From this they can then fill out all the remaining address information including the street name, as each full postcode covers, on average, just 15 addresses.
This means we have quite a lot of different postcodes (approximately 1.7 million). The standard geonames zip file for Great Britain contains just the first part of the postcode which covers a much wider area, but there is also a GB_full.csv.zip file that contains the full postcodes.
Here is the wikipedia article about UK postcodes for anyone who is interested.
This comment make me thought if the best soultion is to let the user choose the values before perfoming the autocompletion.
I’m thinking in implementing the Record creation helper but instead of creating a new record it will update values of the current one.
So the idea is to shown a dropdown whenever the user adds a zip (or a city) which will be populated from the record of the country zip table (it should be possible to extend it to include external source, like the google api posted before). If the user clicks on the dropdown the other fields will be completed, otherwise we leave the values empty as we do now.
What do you think?
To add to @dave’s comment: In The Netherlands we have an even more fine grained system. When you enter a postcode, you can get a whole bunch of data like, street name, city, house numbers, GPS data, Geolocation data etc. We have a public open data service with API’s where you can query for this data for free called PDOK. You can download the dataset of the addresses, but that’s a 1.7 GB file.
Although I’m not fond of Sergi’s proposal, I don’t think your arguments here match those expressed in Default currency for a party - #11 by 2cadz
Default values always have the risk of being wrong (otherwise those fields wouldn’t even be necessary), and may be specially annoying when the system tries to guess them.
I like this proposal more than the original one That’s more or less what you get when you use the party_zip module but there you use a M2O field (which works great when you find what you’re looking for but sucks if you don’t). We use the module only in case the company wants to enforce the use of the zips database.
It is not the same guessing from static data and guessing from past behavior of the user. The second one evolves and learns.
From this discussion, I think it is clear that:
I’m not sure what will be the best layout for the view. If we have the autocomplete feature in my we may use:
Country Zip
City Subdivision
But this does not feel very natural to me.
On the other hand if we invert the rows:
Country Subdivision
Zip City
This will make the user enter the subdivision without the zip so we will never autocomplete the subdivision.
If one could set a default country, within that country, the zip code would need to be unique. But I don’t know how to set a default country, eg. when adding parties, so I have to do this manually.