1. It is not cool or efficient to name all PKs with the same name. Use a name that reflects the table it is the PK for.
2. You show four tables but only two relationships AND RI is not being enforced.
3. It is poor practice to use embedded spaces or other special characters in ANY object names.
4. Both relationships are incorrect.
5. I do not understand why attributes and prices are separate tables.
Although it is recommended to use autonumbers as the PK for a table, it is not required. You can use any piece of data that is unique. However, when you use an autonumber, it MUST be the PK and it MUST be used in the relationships. You are drawing relationship lines between data fields. The relationships are always FK to PK. Don't confuse relationships with joins. Although joins in queries almost always mimic the defined relationships, there are occasions where they might not. That is too confusing a concept to bother with at this point. If the universe of the EDP numbers NEVER includes duplicates over the entire range of companies, you could use the EDP number as the PK for the tblItemList.
It is time to take off your spreadsheet hat and put on your relational database hat. One thing that will help with the transition is understanding a basic difference between a spreadsheet and a relational database (ANY RDBMS, not just Access). And that difference is that in a spreadsheet, the data and presentation layers are combined. That is why you always use names with embedded spaces and even special characters because these are the names tha users see. In a relational database, the users NEVER see the underlying tables or queries. They see and interact with forms and reports (which have captions that are used to name the data fields rather than their actual field names) because in a relational database application, the presentation and data layers are separate. Because of this, the data layer - Tables, is always separate from the presentation layer - Forms and Reports. That means that tables are organized for efficiency. They eliminate redundancy. You can always go from a properly normalized schema back to your original spreadsheet by using a query that takes the normalized tables and joins them and then presents them using a crosstab query as the matrix you love so much in Excel. But we NEVER work with a table that looks like a matrix. Why? Because each new data value across, requires modification to all the forms, reports, and queries that have to interact with that table. Columns that are just instances of the same piece of data with different values belong as rows in a table. Rows are free. Columns are expensive. It makes absolutely no difference at all to anything how many rows a table contains (within the size limits of an Access database). However, columns are limited to 255 per table and 99% of your tables will be < 50 columns. In all the years I have been designing database applications (> 50), with the exception of the one warehouse application I built, I have never had to create a table with more than 100 columns. Warehouse applications are different because they are never updated by users. They are built on a schedule, weekly, monthly, whatever makes sense. The tables are denormalized to help the user to make queries. They are not optimized for efficiency or to eliminate duplication.
Think of the spreadsheets you've made that deal with monthly data. You just add a month's worth of columns for each new month you want to add and you update all the formulas (except those you forget to update). After a couple of years, the spreadsheet becomes unwieldy. That doesn't happen in a relational database because new months mean new rows and we don't care at all how many rows are in the table. We just use criteria that select the rows we want. So, it is very easy to make a query with a rolling 12 months of data for example. All the old data is still there so we can look at ANY 12 month period by simply specifying the start date or end date. If we want a variable range,we specify both a start and end date. With your spreadsheet, what you see is what you get.