Like all design questions, you have to first understand your goals and apply the "old programmer's rule". That is, "If you can't do it with paper, you won't do it with Access." You are building a database to help you with part of your business process. It is a model of the process in an obscure way.
Therefore, you have to do some important things.
1. Study normalization rules. They exist for many purposes, but the most important reason is that they prevent you from making common data errors in retention, accessibility, uniqueness (where appropriate), and compactness.
2. Look long and hard at what you want to do. You might guess that you need a table of suppliers. But the next question is what else you need. I'll show you the logic for one case, based on normalization rules. One of the rules is the "thou shalt not mix apples and oranges." Stated another way, put something in a table if it completely and only depends on the key of that table and NOTHING ELSE.
So look at your monthly performance stuff. That depends on the supplier, but it still doesn't go in the supplier table 'cause it ALSO depends on dates! In other words, a supplier's address or name are supplier data - but the performance contributors are supplier/calendar data. See the difference? This is how you apply the "apples and oranges" rule. Be warned that sometimes the information is very subtle and you might initially miss it as being a normalization key.
3. Sometimes it helps to do this on a dry-erase board with markers and sticky notes. Define the tables you THINK you need. Write some sample data on sticky notes under each table name so you "populate" the tables. Now do some of the things you were considering, using this set of simulated tables as the basis for your operation. See what each step implies. Two things will fall out of this.
3.a. You might detect another table because you realize when you go after something that it requires more than supplier or date. For instance, you mentioned "spares" - which probably have their own designator codes. Another "key" and another table right there.
3.b. You will see the interaction of the tables and be better able to write code and queries as appropriate. You will also have a better feel for where everything resides when you get into form building and report building.
4. Your bit about not allowing entry of duplicates for a given supplier for a given month are easy. Make the "report card" have a compound prime key of supplier code, month, and year. You don't want a full date 'cause that would allow someone to enter data for two different days of the month. But if you use supplier ID, year, and month as prime keys in combination, that will lock out subsequent entries for the same supplier in the same month.
