i'm not sure if what i created here is correct, i'm learning access on my own from youtube and i start to realize is way harder than excel. :banghead::banghead:
I isn't harder than Excel but it requires a very different approach. Often being very experienced at Excel can lead the novice database developer in the wrong direction.
Excel is designed to be read by humans so we put the data together on sheets in a grid and have different sheets as the third dimension. This is effectively what you have done by having different table for different Shippers/Services.
Access tables are meant to be read by a database engine. Everything to do with one kind of data goes in the same table. Instead of having another table for a different Shipper or Service we have a field that designates that dimension. The different kinds of data it relates to are in another table and so on.
All the information about one thing we might want to know ends up spread out across multiple tables. The database engine deals with this information incredibly efficiently as whole sets rather than processing individual groups of information as happens in Excel.
Reports and Forms are used to bring all this back together for humans to read and interact with.
Tables tend to be tall and narrow. You are on the right track there with your rates tables but you need a structure that gets all the same kind of data together regardless of the shipper.
I'm struggling a bit because I can't see all your data so I will try to describe in general terms. You will need to adapt the principles for the details. What I have written looks complex. Don't focus on the specifics so much as the principles. There are definitely variations on how this can be done but it is too hard to explain all the differences here.
Table Shipper would have ShipperID (Primary Key) with fields for anything uniquely to do with the shipper such as the contact information etc.
Table Service would have ServiceID (PK), ShipperID (Foreign Key as the ShipperID), ServiceName and any specific information about the service.
Table Countries would have the PK (you could use the IATACode or have a numeric id), CountryName plus anything specific you want to store about the country. Countries are going to be the same regardless of the shippers so you don't want any information in there about shippers, zones or anything but countries.
Shippers might have different Zones for the countries. Even if they don't now they might later so probably best design that way.
There might be a Zone table with ZoneID, ZoneCode, ZoneName. ZoneCode is what the Shipper uses as a code. Because the ZoneCode is a displayed value, using a ZoneID allows the displayed code to be changed at any time without altering the underlying structure. Assuming the Zones are consistent across all Services for the same Shipper you will have a ShipperID field.
Allocate the CountryIDs into the Zones. This uses what is known as a Junction table that stores a many-to-many relationship. It would have fields for ZoneID and CountryID. Each record stores a unique combination of Zone and Country according to the different Shippers.
From a human (Excel) perspective, a junction table looks like a crazy idea but it is the structure the engine needs to work with.
Now from the other end. Table Weights will have a WeightID, WeightDescription (what you will display on Forms and Reports) and fields to designate the range of weights it covers. It is simplest to have WeightLow and WeightHigh fields. When you compare the weight of your package you test for the package weight being between those two and you get a unique WeightID.
Now you need another junction table that connects WeightID, ServiceID and ZoneID. The ServiceID can already be related back though the ShipperID and ZoneID is already related to a ShipperID. (This can get messy because there are two different way to join the tables. There are other ways to avoid this by using composite keys but it is complicated enough already and should work.)
Now you are able to join these few tables together simple queries where you can select on the package weight and destination country and bring back a list of the Shippers and Services available with the prices.
You will need to build forms for operators to ultimately manage the prices because they certainly are not going to be able to write directly into the junction tables. On these forms you will display the human readable names but store ID.
The junction tables will be manged via subforms. There are some really advanced tricks to make these work well but we can worry about that later. The initial focus must be in structuring the data. You are not far from having it right.
Once you have this structure you should be able to write queries to transfer all the information in your existing tables into the new tables.
A note on the Weight table. Having both Low and High weights means it is possible to miss a record and not get a WeightID for a particular weight. In fact it is technically a breach of normalization to have both Maximum and Minimum in a continuous series. More advanced design stores only the maximum weight threshold and returns the lowest weight range that is heavier than the package. However, it requires aggregate subqueries and results in non-updateable query so can be more trouble than it is worth.
BTW Avoid spaces or special characters in any object names . CamelCase is easy to read and you don't have to put brackets around names.
I really hope what I have written helps and doesn't confuse you further. Unfortunately you have taken on something quite complex as your first project but it certainly can be done.