Looking at the structure again, I changed my mind about something. You are making a lot of "roll-up" reports but I don't see it likely that you will want to go back and reference anything by the sales ID that would be a PK/Autonumber field. I also don't see any child table depending on the five-field sales record. If there are no child tables and everything you are doing is based on roll-ups, you don't need the SalesID PK field - or any PK. But if you DID need one, you have a natural compound key in the form of the RepID and date.
The thing about PK fields is that everybody thinks you need them. But that ain't so. Sometimes you need them if something is going to depend on something else. When you have dependency, the independent item needs an ID but the dependent item might not. It's all in how you use that dependent item. In this layout, Rep ID depends on a representative table. Prod ID depends on a product table. But what field in what table depends on an individual sales record? At the moment, I don't see one.
So your table changes from 24 bytes to 20 bytes and shrinks from about 250 Mb to a little over 200 Mb. So storing a year of data means 2.4 Gb total before you add in indexes. Which means Access STILL can't fit one year of that data into a single table.
But if your sales were differently recorded, you might get some space back here. I'm going through the exercise to show you that it won't be enough.
You said you had limited group size (<100) and limited subgroup size (<100) and limited attribute size (<100). This question is INCREDIBLY important: How likely is it that the number of groups, subgroups, or attributes will change? BECAUSE you could store the info like this:
RepID: Long, FK to representative detail table - 4 bytes
TheDate: Date, 8 bytes
Group: BYTE, FK to group-name table, 1 byte
Subgroup: BYTE, FK to subgroup-name table, 1 byte
Attribute: BYTE, FK to attribute-table, 1 byte
TheCount: WORD, 2 bytes (unless you have some go-getter sales persons who can sell more than 30,000 units in a month single-handedly)
This would make your group, sub-group, or attribute roll-up queries trivial since there is no JOIN requirement. That would make everything a lot faster and the only time you need do to the lookup is to print some names on your report.
That means one sales record is 17 bytes. Your 10.5 million records now take about 180 Mb. That means you can now fit 5 months into a single table.
The reason I went through this is to show you how really tight for space you would be. You STILL will be unable to fit six months worth of data into a single table with a native Access BE file. You are STILL looking at a data overload situation.
You appear to be desperately seeking an Access solution but I have to say this does not look like Access can do this without a LOT of really hard, complex, and perilously messy work. This is probably a job for an active SQL engine like SQL, ORACLE, MySQL, or one of the other ODBC compliant engines.
Perhaps we can understand your persistence by asking this: Did the boss tell you it HAD to be done in Access? Because I think we are going to do you the greatest favor by suggesting that you would do better with an Access FE and something else for a BE.
AND I have made it a point to include my detailed thinking on the layout in case one of my colleagues sees something I have overlooked. In fact, I would WELCOME anyone else telling me why I'm totally wrong-headed about this one. But at the moment, I don't see it.