c2c-oerpscenario team mailing list archive

["Fabien \(Open ERP\)" <fp@xxxxxxxxxxx>]

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

-- 
Mechanism required for handling US addresses
https://bugs.launchpad.net/bugs/505701
You received this bug notification because you are a member of C2C
OERPScenario, which is subscribed to the OpenERP Project Group.

Status in OpenObject Addons Modules: Invalid

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.