Validating the State/Province Field

If Format Address box is ticked when entering a Customer, Vendor or Contact, why can't the system validate the State/Province, making sure at the very least that it's only 2 characters and all letters (and CAPS)?

Or if that's going to cause a problem for some users, make it an option.

Steve

Hi Steve,

That's what the 'North American Address' and 'Uppercase state/province' options in the AR or AP company profiles are for. They validate the state or province in exactly this way.

It doesn't work for Contacts. It really ought to.

Steve

My client showed me that for their data, even with the settings properly set, it still doesn't validate. I replicated this on my computer with their data.

I will upload it to. Let me know what is different between their data and the sample data.

Thanks

Steve

Hi Steve,

Thank you for uploading the data; it was useful.

I do not know if this is by design or not, but the Validate State/Province option does not kick in when the Country field is blank. Your client does not fill in the Country code, but Sample Data customers do. That is the difference.

It doesn't seem like this option should rely on a value in the country code to perform the validation, so I will certainly forward your comments on to R&D.

The workaround would be to put USA into the country field.

Wow, I never would have guessed! I've made it a habit to remove the USA's, even though they are suppressed. Now I have to put them back.

That would explain why the Contacts don't validate - because almost no one goes out of their way to enter the country in a Contact record..

This really needs to be fixed.

Steve

Hi Steve,

I talked to R&D, and they said the Country field (currently) has to be non-blank for this to work, because validation has to know whether the list of US states or Canadian provinces should be used. An error will occur if the country is USA but a valid province code like BC or ON is entered. Or vice versa for a country Canada and a valid state code like PA.

I presume that sometimes/often in US sites, the country code is not used for customers or contacts because it is assumed that all/most customers are in the US. Is this a reasonable assertion?

I have suggested to R&D to use the Home Country field in the Company Profile as a fallback if the customer/contact record has a blank country, for the purpose of state/province validation. I don't know if this is technically possible, but I will find out from R&D.

Support:

I was thinking that in the CP for Vendor Options, if we had a default Country this would go a long ways to solving this problem. Even in Canada, 90% of the vendors are typically in Canada so this would be useful to Canadian users as well.

Also the likelihood of entering BC for a US customer or visa versa is slim. In other apps I've seen North American validation include a combined approach including all states and provinces so that you weren't forced to pick a country first.

I strongly agree with Douglas, both his suggestion to have a default Country in CP, and his suggestion to include a combined approach.

There has to be a way to allow validation without forcing someone to enter a country code. That is just too much to ask of the average data entry clerk.

Sometimes, even if a program works "as intended", the end result is just not acceptable. This is one of those cases.

Steve

Thanks for your thoughts Doug. I'll include these with the original report.

Canada vs US: Just considering accidental typos - eg. MN and MB are both valid, with one character different that are next to each other on the keyboard.

Steve: Would it be acceptable to enter the home country once (in the company profile) as I suggested above, so the data entry clerk doesn't have to enter a country (unless it's different)? This is not functionally different than defaulting a country from a CP value, since they have to edit the 10% others anyway.

I will forward on the comments.

It's not me you have to convince, it's R&D.

I'm assuming you are asking if I'm OK with the system pre-filling the Country field when entering a new vendor, customer, contact, or prospect, I am. Even better would be to make it a required field if the Format Address box is ticked.

Steve

Actually no, I'm asking if for the purposes of state verification, that the Home Country is used if the customer/contact does not have a country. It doesn't require adding any additional options or fields, just a tweak to an existing function.

I can forward your new suggestion to R&D.

I agree with Steve. I've never understood why the Country field for a new Vendor doesn't populate from the Company Profile, Since we have the option to suppress the home country on forms, there doesn't seem to be any downside and now we know there's an upside.

Support's idea seems like a reasonable solution for the thousands of Vendors currently without a country assigned.

Support:

For that matter there are 8 states that start with M. I don't think we need to be too worried about someone accidently entering MN for MB. More likely to be mixed up are states like MI, MO or MS.

Totally understood. My point really was that if someone mistyped a Canadian province for a US state or vice versa by accident, the verification would catch this because it was for the wrong country. We can't prevent or guess at every possible typo.

I'm not trying to rain on the suggestions and comments you all have been making. Just that the more involved the fix and feature is, the less likely it tends to happen.

Receivables 93A will require the Home Country to be non blank if North America Address is selected.
It will validate the State/Prov against the Home Country if it is left blank on the Customer.

I'm confused. Is the first sentence above talking about Company Profile settings? I hope so. Otherwise the second sentence makes no sense.

Steve

Yes, if the AR Company Profile setting for 'North American Address?' is selected, the 'Home country' will be required to be non blank.

Adding new Customers will validate the State/Prov against the Home Country if it is left blank on the Customer.