Now, given my previous comments, here is how YOU can decide if what you are doing is right.
Remember, you are building a model of your business that will run inside the computer through Access. So, old programmer's rule #1 says, "If you can't do it on paper, you will never do it in Access."
Get a big dry-erase board and some markers, then get a box (not a pad... a BOX) of sticky notes. Look at your business model. Identify entities within that model. Think of methods that would have been used before you had MS Office as a tool. Draw table names (as you find them) on the board. Use sticky notes to "populate" the tables with sample records.
Here, it would help if you study a bit on issues of normalization. A good web search on the key phrase "database normalization" will catch, oh, maybe a gazillion references that will give you excellent on-line explanations free of charge regarding normalization. It would behoove you to learn about at least first, second, and third normal forms. Fourth and fifth exist, and Access will allow you to apply them, but the issues you hit MOST often are based on the first three forms of normalization. OK, let's analyze your model.
Got a list of customers? Probably in a RoloDex? Candidate for a table in the model!
Got a list of suppliers? Probably in same or other RoloDex? Another candidate for a table! BUT here is where the "Apples and Oranges" rule comes in. You rarely make fruit salad here, so if they look different or are used differently, they go in SEPARATE tables. (Yeah, there ARE ways to combine them anyway, but they are kind of advanced and not always productive or inuitive.)
OK, back to analysis... You have products. So there is a product table. You pick the ID for each product.
Now, the question is how you get that product. You have a list of suppliers already, so you can define a relationship - BUT... here is where a uniqueness rule comes into play. If your model says you can NEVER EVER IN A TRILLION YEARS get the same product from more than one supplier 'cause each supplier offers non-overlapping products, you COULD put the supplier ID in the product table. BUT I'm betting that you aren't so lucky. What you need here is called a linking table. You make a list of products you get from each supplier. Add the lists together. (Don't remove overlaps.) This becomes a table that lists supplier ID number and product ID number in the same table, so that an entry in the table means "this supplier offers this product."
This thread and your other thread mention prices and talks about price changes, discounts, and the like. Here is where you look for paper trails. Did you ever hand out discount sheets to your sales folks, to carry or to post near a sales terminal or however your business works? That discount sheet is another candidate for a table. It has a discount ID number and the info on the discount.
You list markups as a table. This could make sense if what you have is some raw price (wholesale price) for an item and you want to dynamically compute its selling price.
The problem, of course, is that prices NEVER stay constant, so your price info can change even if the item being sold doesn't change. Remember the old "apples and oranges" rule? This includes date-variant data. Your price table has to be marked with a product ID, price, and the dates between which the price is valid. The latest price on anything should have a future date somewhere like 1-Jan-2100 or something equally bizarro. You would update that price entry with a termination date when a new price gets posted. This table, if complete, lets you recompute prices for any product sold at any date. If your markups and discounts are ALSO date-variant, the same concepts apply to them.
I have started the analysis for you. You must finish this yourself because only you know your business rules. We cannot possibly know them. OK, now as you define each part of your business, populate your dry-board tables. Practise the actions associated with your rules. Mechanically run each possible transaction type to see what tables are affected. Manually gather data for your reports to see where to look for each datum.
When all of this is done, you can perhaps begin to implement your Access solution for your business model. If you have any sticky notes left, you can use them - and the dry board and markers - in some other part of your business. (Which is why I always suggest dry board, markers, and sticky notes - they are usable for other purposes later!)
I know this seems like a daunting task, but there is NO substitute for problem analysis resembling this type of problem breakdown. No less an authority than Nicklaus Wirth, creator of the Pascal language, once said that no less than 80% of all programming problems stemmed from poor data design. Which is why you need to spend time up front to get your table design right.
