-
1. Re: Address Validator Transformation brings unmatched elements to the front
Hi,
If the Input address consists of any Invalid Data, then you can configure the Address Validator Transformation to include Residue Ports. In the case of Invalid Data, you can make use of Residue Unrecognized Ports which is an output port that contains data that the Address Validator transformation cannot parse to an address data port.
Please refer to: Residue Unrecognized Ports
Thanks,
Namratha
-
2. Re: Address Validator Transformation brings unmatched elements to the front
Hi, Thanks for the response.
I had already configured the Residue ports, it works for a few address but not for all. Unmatched values are coming up in Delivery Address Lines but not as Residue.
If I take an example by using Informatica UK address (found on the website) as the Input address but add invalid data to one of the address lines :
Input:
Address Line 1 : 4 Foundation Park
Address Line 2 : FirView Cottage Roxborough Way
City : Maidenhead
Postcode: SL6 3UD
Output that comes up is :
Delivery Address Line 1 : 4 Foundation Park
Delivery Address Line 2 FirView Cottage
Delivery Address Line 3 : Roxborough Way
City : Maidenhead
Postcode: SL6 3UD
Result Percentage : 100%
But, I would like Roxborough Way to come up in Delivery Address Line 2 and not have FirView Cottage at all.
The same is happening with certain addresses where there is invalid data in Address Line 1 (which is a key field in some operations). The invalid values are pushed to Delivery Address Line 1 (with 100% Result Percentage and Mailability score as 5)
-
3. Re: Address Validator Transformation brings unmatched elements to the front
Hi,
Please confirm the AV Engine version being used along with the last time the reference files have been updated.
Are you making use of the AV Transformation?
What is the Mode of Validation? Also provide the complete set of Output Status Values.
Thanks,
Namratha
-
4. Re: Address Validator Transformation brings unmatched elements to the front
Yes, of course. I am making use of the AV Transformation.
AV Engine Version : 5.14.0.47308
Mode: Batch
Last Update Date of GBR Ref files: 12-Oct-2020
I'm using the Status Info fields:
Match Code, Mailability Score, Address type, Count, Results Percentage
Would you like to know the values for them for the example given ?
-
5. Re: Address Validator Transformation brings unmatched elements to the front
Hello Prinfor matica,
If we see the above example, While vaildating, Address doctor parsed FIRVIEW COTTAGE into Building item 2 port.
Building Item 2 | COMPLETE = FIRVIEW COTTAGE
(In your case, part of Delivery Address Line 2)
At the time of validation, It is parsed to output port because Address doctor database file does not have this reference data(FIRVIEW COTTAGE) and as per design, Address doctor does not drop any of users input if is it not checked because of lack of reference data.
Hope it helps.
-
6. Re: Address Validator Transformation brings unmatched elements to the front
Hi Shubham
Thanks for responding.
Yes, but is there a way I can identify those unmatched pieces of info, so I can exclude that, as it doesn't even come up in Residue ?
The same is happening if there is unmatched address data (or a road/area name) in Address Line 1 for a few addresses . In such cases the unmatched information is coming up as 'Building Complete 1' or 'Delivery Address Line 1' and with Match code as 'V4' and mailability score as 5.
Is there a way I can stop that from happening or identify that piece of info ?
-
7. Re: Address Validator Transformation brings unmatched elements to the front
1 of 1 people found this helpfulHello, Prinfor Matica,
Yes, We can check the status of each address element with the help of the element result status.
Element result status is the 20-character code in which each character refers to a different address data element and the result status.
1. To know the position of each data element, you can follow the - Element Positions
2. For the details of each result status code whether it is verified, corrected, or parsed, you can follow the - Element Result Status
Note that, Delivery address line is a combination of (Street, number building, sub building) but Element result status is only for each discrete field/element so with the help of element result status you can check the status of each element but not for Delivery address line directly.
-
8. Re: Address Validator Transformation brings unmatched elements to the front
Hi Shubham
Thank you. That's really useful to know.
Are there any good practises that I should follow or do you have any tips with regards to address validation ?
I am considering anything with the Match codes of - V2,V3, V4, C3 , C4 as acceptable. (However with C3, I noticed that the input addresses made more sense than the validated ones. So, I am keeping the input as it is).
Along with Delivery Address Lines & Country, I am also using data from Locality complete 1, 2 , Province Country Standard 1 columns.
Now, I'll add the element Result status as well, mainly to verify Element Position -13 which I am most interested in.
So, in general do you think I should take care of anything else that I might be missing here ?
-
9. Re: Address Validator Transformation brings unmatched elements to the front
1 of 1 people found this helpfulHello, Prinfor Matica,
You can follow the Best Practices for the United Kingdom Address Validation for more information specific to UK address validation.Process status describes the result output quality of address verification. You can use the below status description for a better understanding and accordingly you can use result element status.
V4
Verified. The input data is correct. Address Verification checked all postally relevant elements, and inputs matched perfectly.
V3
Verified. The input data is correct, but Address Verification standardized some or all elements, or the input contains outdated names or exonyms.
V2
Verified. The input data is correct, but Address Verification could not verify some elements because of incomplete reference data.
V1
Verified. The input data is correct, but user standardization has adversely affected deliverability. For example, the postcode length is too short.
C4
Corrected. Address Verification has checked all postally relevant elements.
C3
Corrected. Address Verification could not check some elements.
C2
Corrected, but the delivery status is unclear because of absent reference data.
C1
Corrected, but the delivery status is unclear because user standardization introduced errors.
Cx is for the corrections in the input address while validating against the reference database(postal data) and populates the corrected value in the output.
-
10. Re: Address Validator Transformation brings unmatched elements to the front
Hi Shubham
Great, thanks a lot. Much appreciated.