When enter correct postal code for destination in Argentina, system populates City and State/Province which are causing errors:
DHL Express - no service available
USPS: Does not activate the Print International Label & Documents button. All required fields are completed and no error been displayed.
UPS: Error for missing or invalid shipper number, attaching screenshots confirming the sender details, shipments details with active Print label button, error received while trying to print the label.
Submitted For | All |
Criticality | Must Have |
Date to complete work by | Nov 6, 2024 |
Must have for US Launch | Yes |
At Georgi's request we are changing focus of this to disabling DHL Strict Address Validation in order to allow shipments to Argentina to work with minimal address errors. Attached are sample addresses that cause issues as things are now.
At this point the carrier errors are no longer part of this issue. This issue is all about the Postal Codes that are accepted or not accepted, and the values returned for City and State/Provence code.
History: Argentina first implemented a four-digit postal code system in 1958, in 1998 Argentina adopted the CPA (Código Postal Argentino, Argentine Postal Code). The CPA is not mandatory for private use, but companies that do mass mailings benefit from a discount if they use the CPA. Despite this, the CPA is still not in wide use by private persons, and even government sources and private businesses often list only the base code (the old system).
Functional Issue: The CPA Postal Code (Ex. C1051Aba) that is being passed by JPMC is not recognized by our system and cannot validate City or State/Provance code (See attached screen shot with proper City and State/Province Code).
If we strip this CPA Postal code down to the base code 1051, the system re-populates the City and State/Province fields with inaccurate values (See Attached Screen shot with invalid values being auto populated based on the base code).
This data will not process via DHL, but if we correct the City and State/Province we can process the transaction (See Attached Screen Shot).
This is not a singular postal code there are others we have seen and believe there are more that need to be corrected.
Ex. C1092Aaj, C1106Acv,
We need to determine a couple of things with the core postal code are we mapping the correct data being returned from the Precisely API to the correct fields. If so, we need to engage Precisely regarding the problematic return results and get them corrected so our users can ship properly.