Currently when the user creates an addres after setting a zip it get’s the city autocompleted but not the country nor the subdivision. Tryton has a table to store for each zip it’s country and it’s subdivision but this is not reflected on the user interface.
I’m wondering how can we improve this to make tryton set all the related fields when entering a zip.
Toughts?
It is only auto-completion not selection so I do not see what you mean as there is no proper selection of a zip record.
I live in a village called Sarroca de Lleida, which if of the Province of Lleida in the Country of Spain. It’s postal code is 25175.
When I enter 25175 in the zip field, I get a nice autocompletion about the city so I do not have to write it down. That’s great! On the other hand, the country and the subdivision are leave as empty and I do not have any sugestion for them.
On the country zip table I have the following records:
select * from country_zip where zip = '25175';
id | city | country | create_date | create_uid | subdivision | write_date | write_uid | zip
-------+-------------------+---------+----------------------------+------------+-------------+------------+-----------+-------
44889 | Sarroca De Lleida | 70 | 2020-07-16 16:22:20.183929 | 1 | 1159 | | | 25175
44890 | Sarroca De Lleida | 70 | 2020-07-16 16:22:20.183929 | 1 | 1171 | | | 25175
So the system knows that the zip code 25175 is related to country 70 (Spain) and to subvissions 1159 (Cataluña) and 1171 (Lleida).
With this information I will expect that the System sets the Right country and the Right subdivision based on the zip I introduced.
What information? There is no information that a zip was selected because no zip record was selected at all. It is only an auto-completion.
Your example is a special case where the zip code is unique in the table but it will most of the time not be the case.
I guess Sergi is trying to expose how could the functionality provided by party_zip module be integrated into core.
The module exposes a m2o field in addresses where the user can choose the zip-city-country-subdivision combination they need and with a single search they fill all four fields.
PS: I know that you already mentioned that using country.zip model is not the right way of doing it.
Let me put an example where there are several entries for the same zip. I just found that 39450 is one example in the spanish database:
# select * from country_zip where zip = '39450';
id | city | country | create_date | create_uid | subdivision | write_date | write_uid | zip
-------+------------------------+---------+----------------------------+------------+-------------+------------+-----------+-------
21899 | Arenas De Iguña | 70 | 2020-07-16 16:22:20.183929 | 1 | 1150 | | | 39450
21900 | Arenas De Iguña | 70 | 2020-07-16 16:22:20.183929 | 1 | 1190 | | | 39450
21901 | San Cristobal | 70 | 2020-07-16 16:22:20.183929 | 1 | 1150 | | | 39450
21902 | San Cristobal | 70 | 2020-07-16 16:22:20.183929 | 1 | 1190 | | | 39450
21903 | Pedredo | 70 | 2020-07-16 16:22:20.183929 | 1 | 1150 | | | 39450
21904 | Pedredo | 70 | 2020-07-16 16:22:20.183929 | 1 | 1190 | | | 39450
21905 | San Vicente De Leon | 70 | 2020-07-16 16:22:20.183929 | 1 | 1150 | | | 39450
21906 | San Vicente De Leon | 70 | 2020-07-16 16:22:20.183929 | 1 | 1190 | | | 39450
21907 | Serna, La (Iguña) | 70 | 2020-07-16 16:22:20.183929 | 1 | 1150 | | | 39450
21908 | Serna, La (Iguña) | 70 | 2020-07-16 16:22:20.183929 | 1 | 1190 | | | 39450
21909 | Cohiño | 70 | 2020-07-16 16:22:20.183929 | 1 | 1150 | | | 39450
21910 | Cohiño | 70 | 2020-07-16 16:22:20.183929 | 1 | 1190 | | | 39450
21911 | Santa Agueda | 70 | 2020-07-16 16:22:20.183929 | 1 | 1150 | | | 39450
21912 | Santa Agueda | 70 | 2020-07-16 16:22:20.183929 | 1 | 1190 | | | 39450
21913 | Las Fraguas | 70 | 2020-07-16 16:22:20.183929 | 1 | 1150 | | | 39450
21914 | Las Fraguas | 70 | 2020-07-16 16:22:20.183929 | 1 | 1190 | | | 39450
21915 | Santa Cruz De Iguña | 70 | 2020-07-16 16:22:20.183929 | 1 | 1150 | | | 39450
21916 | Santa Cruz De Iguña | 70 | 2020-07-16 16:22:20.183929 | 1 | 1190 | | | 39450
21917 | Los Llares | 70 | 2020-07-16 16:22:20.183929 | 1 | 1150 | | | 39450
21918 | Los Llares | 70 | 2020-07-16 16:22:20.183929 | 1 | 1190 | | | 39450
21919 | Palacio (Arenas Iguña) | 70 | 2020-07-16 16:22:20.183929 | 1 | 1150 | | | 39450
So in all the cases the country is 70 (Spain) and the subdivision is 1150 (Cantabria Autonomous Comunity) and 1190 (Cantabria Province).
So the system could also guees the correct Country and the correct Subdivision while keeping the autocompletion on the city to pick the right one.
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.