Difference between revisions of "Express Entry:Global Best Practices"
(Created page with "← Global Express Entry Reference {{CustomTOC}} ==Fielded Search== In the Fielded Search example in the sample code, it is not necessa...") |
|||
| Line 14: | Line 14: | ||
==Encoding with Internet Explorer== | ==Encoding with Internet Explorer== | ||
Internet Explorer does not UTF-8 encode characters with accents and other diacritics (such as à to %c3%a0) when sending them, so to query the service with Internet Explorer, one must manually enter their encodings. | Internet Explorer does not UTF-8 encode characters with accents and other diacritics (such as à to %c3%a0) when sending them, so to query the service with Internet Explorer, one must manually enter their encodings. | ||
==Returning a Parsed Address== | |||
In Global Express Entry a parsed version, according to the standards of each country, of the input is returned when there is no reference data match. This may lead to some confusion as to whether the address is in the reference data. If your response address is the same as the input address, but in a different form, you may be getting a parsed version back, which means your address was not in the reference data. | |||
[[Category:Best Practices]] | [[Category:Best Practices]] | ||
[[Category:Global Express Entry]] | [[Category:Global Express Entry]] | ||
Revision as of 19:27, 19 February 2015
← Global Express Entry Reference
Fielded Search
In the Fielded Search example in the sample code, it is not necessary to pass the locality name. In fact, passing the locality name restricts the system to returning results only within that locality. The Postal Code is sufficient to find the address within the system in this case.
Not every address will be found in Global Express Entry. For example, new addresses and rural addresses may not be available. Your code should allow for the case that Global Express Entry does not have the submitted address and handle it appropriately. For example, you may require in your code that if the address comes up with ‘no results found’, then force the user to fill out the full address with all of line 1, locality, administrative area, and Postal Code – and only then be able to move forward with the application. More addresses will be added in future versions including new and rural addresses.
Address Checking
A Best Practice is to send the address through an address checker if it does not come up in Global Express Entry. Verifying the address using Global Address Check Web Service after attempting a match is useful in those cases that the user is required to type the whole address, since the address is unverified in this case. Also, users should know that when there is only one address showing in the results window, and this is the match, then there is no need to type further since they may choose this address with the mouse (or keyboard, depending on the implementation).
Encoding with Internet Explorer
Internet Explorer does not UTF-8 encode characters with accents and other diacritics (such as à to %c3%a0) when sending them, so to query the service with Internet Explorer, one must manually enter their encodings.
Returning a Parsed Address
In Global Express Entry a parsed version, according to the standards of each country, of the input is returned when there is no reference data match. This may lead to some confusion as to whether the address is in the reference data. If your response address is the same as the input address, but in a different form, you may be getting a parsed version back, which means your address was not in the reference data.