Thread: State/County question regarding UK

If you look at a formatted customer address in storefront Account or similar you will see that the address is wrongly formatted for the UK in that it uses the State abbreviation right next to the postcode. This is because the state abbrevs mean something in US (NY for example) but not in the UK (SXE = East Sussex). So you get something like:

Brighton, SXE BN3 3TN

It's the abbrev that is stored in the Address table and is assigned to the State property of the Address object.

There's no easy fix to this (which is why it has ended up on live sites in the UK ) since it is the Address.DisplayString method in source code which does the formatting.

The simplest solution would be to modify that method to omit the State (based on a config option) or, more complicated, to modify the SQL to bring back the State Name as well and have a config option to use that rather than the abbreviation.

Probably the easiest easiest option is to change the State table's Abbreviation column and make it long enough to hold the full name, but that will have performance implications since it is involved in join and select conditions.

Anyone else have any thoughts on this?

Cheers, Rob

As a bit of feedback for the developers - counties are very much optional in the UK. Royal Mail require the POST TOWN and POST CODE and apparently prefer not to have a county as part of the address

UK counties are also a much debated topic. I live in 'North Somerset' which is not a county but an administrative area of a unitary authority! Thus, there is no county in my postal address but many websites force me to enter one or choose from a list which doesn't include 'North Somerset'. Some sites still include AVON which existed from 1974 until 1996. NB The SQL provided in this post http://forums.aspdotnetstorefront.co...ead.php?t=9625
is not a complete list and also makes this mistake

I have used custom code to hide the billing/shipping state drop downs for UK addresses

Perhaps there could be an additional column on the countries column to determine whether the state fields are displayed/used? Can't be just the UK which has this problem?

Yes, it's confusing. One site I looked at still lists Rutland, which I thought was only kept alive by Eric Idle. A friend of mine was working for a client who also insisted Avon was kept in the list but I decided to remove it.

I might eventually do what you suggested and drop the County requirement altogether.

On a related subject: as this is my first ADNSF site: have you done shipping rates by postcode? My client says his shipping company provide a list of zones by postcode but they use the significant letters, eg BN for Brighton. But we have the full postcode for the customer (BN3 3TN for example). I could use a regex to match so long as the prefixes are unique. Any experience of that?

It's also my first implementation of this software. Thankfully, my client has a fixed shipping fee per order regardless of location, so I haven't got involved in any of the complexity there, though I did add in some custom code to actually add the shipping fee to the order (couldn't find a way of doing that natively)

Checking the first one/two letters of the postcode shouldn't be too difficult. I have done similar in other non-Windows software. Presumably you'd create a SQL table with the postcode prefix and charge rate (which you client could maintain) and go and look this up at checkout?

I just intend to use the standard Shipping Zones feature with postcodes but I think it is designed for atomic Zip codes not partial postcodes, which is where I think it will need modifying, ie 'BN3 3TN' equals zone 'BN'.

I coded this up and then discovered that the application has several places that display the address, each one using a separate method. One uses Address.DisplayString, one uses Order.BillingAddress, another uses a bound dataset, etc. So it is pretty messy to fix all of them.

I'm not sure what the best solution is: a) do what you did and drop County altogether, or b) fix it where it is absolutely essential and ignore it where it's not.

The problem is not just the formatting but that the value for State is always the abbreviation, not the full County name.

It might actually be easier to forget about fixing up the objects themselves and writing a StateName lookup function and using it where the output is created. [I just noticed that there is already such a function in AppLogic - Rob]
Looking at two public UK storefront sites, one of them has the problem, the other has gone for a free-format county text box, which is interesting, since all the existing code tries to match on the abbreviation, so that is a bigger modification to source code than not using the abbreviation.

The state problem sucks- I have ended up with a bit of a mishmash where I allow the user to select a county, but don't display it in my delivery notes/receipts etc-

Someday i will revisit and hack it away completely.

I live in Bath, yet another unitary authoriary (Bath and North East Somerset or B&ANES or BANES depending on your mood) and the problem is everyone has a different idea of where they actually live depending (usually) on their age.

Ben

I ended up fixing it throughout the app (about 4 locations) but removed State/County from the receipt, partly because I don't think it matters too much there but also because I didn't want to get into either hacking the embedded sql to join on the State table or write myself a custom XSLT extension to do the lookup.

By the way, if you need to lookup the state name based on the abbrev, you can do it minimally with a method like this:

Code:

    public static string GetStateNameForAbbrev(string stateAbbrev)
    {
        string stateName = String.Empty;
        if (!string.IsNullOrEmpty(stateAbbrev) && stateAbbrev != "--")
        {
            int stateID = AppLogic.GetStateID(stateAbbrev);
            if (stateID > 0)
            {
                stateName = AppLogic.GetStateName(stateID);
            }
        }
        return stateName;
    }

Originally Posted by fooster

...the problem is everyone has a different idea of where they actually live depending (usually) on their age.

You're right. I'm sure this is the nineteen-thirties all over again...

Just wondering if any of you who have struggled with this have had any problems with address matching for processing credit cards etc - is 'county' a required part of the card holders address which if not present could result in failed transactions?

As I understand it the AVS checks any numerics in the first line of the address & the postcode in its entirety.
So the County problem won't cause any issues with cc validation.
That being said however - it's a nightmare when using google checkout - there's another thread about that though.


TTFN

BFG

I implemented postcode validation in about four places to make sure the postcodes are at least in a valid format. I would imagine that with the counties not being standardized that they cannot be relied upon for address checking.

I also added some intercept code for postcodes so that you can use shipping by zone, if anyone needs it. You can use postcode areas instead of zip prefixes in the zipping zone screens and it matches the customer's area code.

Rob

We're nearly complete on launching our new site on the AspDotNetSF platform and are using postcode anywhere to validate address at the checkout. We also have a complete list of the all UK outcodes (the first part, eg CM20), so if any wants it just drop us a line.