savoirfairelinux-openerp team mailing list archive

[Pedro Manuel Baeza <pedro.baeza@xxxxxxxxx>]

> Then that will indeed work relationally speaking.
> Now, Vauxoo, Savoir Faire and us would probably need to use the zip (the 6
> millions of them in Brazil) as the input and derivate the res.better.zip and
> the related data from it.
> 
> So I have 2 questions:
> 1) will that zip input scenario be doable the way better_zip has been
> designed? (by overriding I imagine)

If you want to use the 6 million of ZIP codes, you can already do it with this module. You will have 6 millions of records of res.better.zip. In Spain, we have this case: one city, many ZIPs.

> 2) you are calling a res.better.zip what we are calling a city. Are we going
> to really talk about the same thing when we will be using res.better.zip in a
> vertical?

Exactly, for all the effects, res.better.zip = city. In v8, I will rename the model and make a migration script to avoid this ugly name (I would do it now, but I don't want to bother camp2camp guys, because it was their module).

For the localization module, you only need an XML file with city data. You can see Spanish example (http://bazaar.launchpad.net/~openerp-spain-team/openerp-spain/7.0/view/head:/l10n_es_toponyms/wizard/l10n_es_toponyms_zipcodes.xml) with ~54000 records. We have made a wizard to avoid load direct of the file.

If you want, we can chat and see any doubt you have, but please tomorrow, because today it is very late here in Spain (about 1:00 a.m.).

Regards.

-- 
https://code.launchpad.net/~savoirfairelinux-openerp/partner-contact-management/city-move/+merge/196023
Your team Savoir-faire Linux' OpenERP is subscribed to branch lp:~savoirfairelinux-openerp/partner-contact-management/city-move.