Review: Needs Fixing Hello all,
here in Brazil we also need the city object too and we had our own implementation till now https://github.com/openerpbrasil/l10n_br_core/blob/7.0/l10n_br_base/l10n_br_base.py At first I would reason like Nhomar and tell this simple city model would make the cut for us too, with some convergence to be found later upon base_location (we won't be able to use any base_location without city model first). I also think it's essential to converge around the city model. For instance if there is some real estate vertical or some advance in GIS things, not having different city models is a must. And as we said, in some localization it's just mandatory, here in Brazil I should send the legal fiscal code of the city in an electronic invoice for instance... However, I CANNOT approve even this merge either. Indeed, in this module, we have res.city-m2o-res.country line #428 Well, this annoys me because instead, most of the time (think), I would prefer to have res.city-m2o-res.country.state and have the m2o to the country as a related field eventually. For us the link to the state is absolutely essential, because as a federation, a state is sovereign about most of its fiscality, meaning from the city in the address, we deduce the state_id to pass to our fiscal rule VAT engine to infer the proper VAT's. Nhomar, Sandy, you have no states in the country you work or what? If not, what would be the best way to accommodate? May be have this m2o to country and in our an other module we override this field to say it's a related via the state? Please advise. -- 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. -- Mailing list: https://launchpad.net/~savoirfairelinux-openerp Post to : [email protected] Unsubscribe : https://launchpad.net/~savoirfairelinux-openerp More help : https://help.launchpad.net/ListHelp
