Results 1 to 6 of 6

Thread: How to handle International Addresses

  1. #1

    How to handle International Addresses

    Looking for feedback on what has been done by others to populate the Country Code and State Code for all international locations. We want to adopt ISO 3166-2 Standard but know that JDE is not capable of doing this. As a workaround what do others do for international address information? To build on the Bug Description Below we have a Country Code of 'US' and a State Code of 'WA'. Currently we have the description 1 in the State Code of WA as "Washington" but technically it could also mean "Western Australia" or "Wasit" in Iraq. If we drop the Description of "WASHINGTON" then we have a gap for reporting or printing of needing the Description of the State. Hope this makes sense.



    Here is the detail of the Bug from Oracle.

    Here's the info for Enh Bug 10859917 - LOC: AU:00/S UDC TABLE & ISO - SAR: 7304710:
    ISO 3166-2 codes for Australia describe 6 States and 2
    Territories. The first part is the ISO 3166-1 code AU for
    Australia, the second part of the code is two-digit-alphabet
    ic. The purpose of this family of standards is to establish
    a worldwide series of short abbreviations for places, for
    use on package labels, containers and such. Anywhere where
    a short alphanumeric code can serve to clearly indicate a
    location in a more convenient and less ambiguous form than
    the full place name. US readers may wish to consider them
    as the equivalent of worldwide zip or postal codes.
    Per the ISO standards briefly discussed above, the abbreviat
    ion for Western Australia is AU-WA, which is the concantenat
    ion of the country and state. However, E1 doesn't seem to
    account for this. In the 00/S UDC table, W.A is used to
    denote Western Australia from Washington state (uses code
    WA). Other Australian locations use similar three character
    value to represent them in this UDC table.

  2. #2
    Senior Member Larry_Jones's Avatar
    Join Date
    Nov 2000
    Location
    Spokane, WA, USA
    Posts
    3,243
    So we're a US based company (ironically from Washington State).
    For US and Canadian customers we use the State field.
    For others we leave the AB State field blank and stick the State/Province value in one of the Address fields.
    Larry Jones
    E1 9.2 - TR 9.2.2.6 on Win 2016 R2. SQL Server 2016
    Wintel, BI Publisher

  3. #3
    New Member
    Join Date
    Sep 2005
    Location
    Sao Paulo, Brazil
    Posts
    12
    Hello,
    We have established a common code for the Country, for instance, all states in AUSTRALIA will end with a . (period)
    So, in this case, the US will have WA as Washington but for Australia WA. as Western Australia - then for India, a WA- for something else, and WA+ for another Country.

  4. #4
    In the State Code field, our Description 1 value for WA is "Western Australia/Washington", and we have similar descriptions for other codes that overlap.
    I'm not aware any reporting requirements our company has to see the full description of the State Code. Having the Country Code in our reporting is enough to help us understand whether WA means Western Australia or Washington.

  5. #5
    Senior Member Larry_Jones's Avatar
    Join Date
    Nov 2000
    Location
    Spokane, WA, USA
    Posts
    3,243
    Must make for funny looking addresses on POs, invoices, etc
    Larry Jones
    E1 9.2 - TR 9.2.2.6 on Win 2016 R2. SQL Server 2016
    Wintel, BI Publisher

  6. #6
    Larry - I'm not sure who you're replying to.
    If you're replying to my post, the addresses on POs, invoices, etc. include the code (e.g. "WA") - not the full state name.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
The legal restrictions and terms of use applicable to this site are available here.
Use of this site signifies your agreement to the terms of use.
JDELIST is NOT affiliated with JD Edwards® & Company, Oracle or Peoplesoft. Contents of this site are neither endorsed nor approved by JD Edwards® & Company and, or Oracle.