Mechanism required for handling US addresses

Bug #505701 reported by Sam Hartman
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Odoo Addons (MOVED TO GITHUB)
Invalid
Undecided
Unassigned

Bug Description

In OpenERp 5.0.6, the formatting of addresses is hard coded in a huge
number of places: RML reports, XML views, etc.
However, address formatting is locale Dependent.
Canonical formatting of an address in the US looks like
street
street2
city, state_code zip
USA

Obviously, European addresses are formatted differently. I'm told
that the advice for people using Open ERP in the US is to change the
RML files for the reports they acre about. My google skill is not
actually good enough to find that advice. I've done that. However,
it's the wrong solution. I have clients both in the US and Euprope.
I'd like to be able to correctly print both kinds of addresses. So,
there are two user stories that do not work with the current code.
First, a user wants to be able to print addresses for their locale
without modifying the code or RML and without making it difficult to
take updates to reports in the future. Second, users want to be able
to correctly print addresses for partners in different locales.

Proposed design for a solution: make address formatting be determined
by what country the address belongs to. Add a field to country either
giving some sort of formatting architecture or a reference to some
function/object in the code to render the address. Default to the
European format and provide an implementation for the US and other
countries with notable address standards that differ.

This would be a bit tricky. Currently address elemets are expanded in
views and RML. You'd need some way to actually jexpose paragraph
breaks in RML and line breaks in view components, and that would be a
bit tricky. However, long time that will focus localization into one
place rather than scattering address localization throughout the
product.

Revision history for this message
Numérigraphe (numerigraphe) wrote :

I agree this should be done in a generic way. I guess lots of places use different addressing conventions.
Shouldn't this be filed as a blueprint however ?

affects: openobject-server → openobject-addons
Revision history for this message
Fabien (Open ERP) (fp-tinyerp) wrote :

I marked invalid because it's a duplicate of another bug proposed by Ferdinand (a method that compute the address format to be used in all reports).

Changed in openobject-addons:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.