Support structured address

Feature
1

Rational

There are needs to have structured addresses like SEPA will use in the future a structured address instead of their current schema (#13190) · Issues · Tryton / Tryton · GitLab

Proposal

Using libraries like deepparse or libpostal is not really a solution because we need to provide complete control to the user over the data stored and also those libraries are complexe to install and heavy to run.
I propose to convert the street into a Function fields and to store unstructured data as street_unstructured. The Function will compute the street content based on the structured data (if provided) using the address format of the country otherwise it uses the unstructured data.
The structured data will be street_name, building_name (from name), building_number, unit_number, floor_number and room_number. But also post_box, private_bag and post_office.
The current format data will be extended using https://www.upu.int/en/Postal-Solutions/Programmes-Services/Addressing-Solutions

Implementation

2

Please check the countries for which you now the rule of postal address format.

3

One concern I have is the edit flow.
If the user enters the structured components first, street is generated from them. But if the user then edits that generated street, the structured values are cleared and the address becomes unstructured again.
That behavior is technically consistent, but it is not obvious to users. I think street should be read-only whenever structured fields are used, and only act as a preview of the formatted address.
Otherwise, it is too easy to lose the structured data by editing the rendered string.

4

And this is what has been implemented one year ago.