Hi
I'll stick my two penny worth in too if you don't mind
Your design looks good, just watch the naming of the fields, it's not good practice to have field names with spaces in.
I'd be awfully tempted to have a way of specifying a default address for a customer. As it stands to get the invoice/delivery address for a customer you would need to also know the correct contact, when you have multiple contacts for one customer in multiple locations how will you establish this?
Address types is an interesting one and could be taken either way, extra fields in the address table for each type or a separate table. Theoretically having them in the same table would be faster as there's one less join, but you'd need to add an extra field to the address table if you needed to add any additional address types. I wouldn't have them as you have set them up though since you can only have one address type per address.
As you seem to be taking normalisation right down to the nth degree
or I'm assuming you are if there are tables missing and all the fieldnames suffixed with ID are Foreign keys, you should theoretically have a table of regions also for the address table. Whether you want to bother doing that is up to you, there are pros and cons, it makes reporting by region better, but could be a nightmare for entering new customers - I'd be tempted to handle this client side with address validation (same with the cities) but that's up to you.
I'm not sure if indexes exist in Access, it's been a long time since I've used it, but as many-many join tables tend to get quite big it's worth indexing them both ways to increase performance.
Out of interest how many users would be using this concurrently?
Hope some of this helps,
Cheers
Kyle