For this kind of messy mixed-bag relationship, the rule is Divide and Conquer. Pick apart the problems of description from the problems of manipulation. That is, it is easy to track how much of something you purchase or consume. It is easy enough to describe variable lots of "things." But you need to keep those questions separate.
From your earlier posts, you very seriously need to study the concept of database normalization. You can web-search that easily. I'm betting that many college sites will have tutorials on the subject.
From post #8 in the thread, you will need to have tables for base accessories, descriptions, purchase orders, suppliers, customers, etc. You will probably need several of what we call "Junction" tables that help you translate your supplier numbers to your internal numbers and to translate your internal numbers to your customer style numbers. You might also have junction tables to give you "component lists" of how much tape, how many buttons, how much cloth, how much other thread you expect to consume to make one shirt or one pair of pants.
Though it might be possible to do this entirely through queries, forms, and reports - with minimal VBA - it might be a good idea to be ready to really get deep in the trenches. What you are describing is NOT a trivial problem, so don't expect it to come together right away.
From the discussion, I have to say that you aren't quite ready to do this yet because you need more problem decomposition analysis (as mentioned earlier). I.e. you have not divided it finely enough to conquer it yet. My simplified "Old Programmer's Rule" is this: If you can't do it on paper then you can't do it in Access. Until you can draw out your tables AND rules for how they change for each function you want to perform, you are going nowhere fast.
Access is not a smart tool. There are times when it is dumber than a box of rocks. It has no idea of what goes into making pants. You have to supply the smarts and the know-how. That leads to the other "Old Programmer's Rule" - Access won't tell you anything you didn't tell it first. You have to be able to gather the data you need to produce the output you want - which means that part of the design phase is to work BACKWARDS. In essence, you say: I want to see a report that lists my consumables shown in a particular way. Then you say: What data must I have gathered in order to product that report? Then you say: How do I gather these items and store them in the database? For every output you need, be it form or report or raw text file, you need to go through that exercise.
I doubt any of us could write any significant parts of this as examples. You are talking about a huge project and make no mistakes in that perception. All we can probably do is (a) offer analysis guidelines and (b) if you have very narrowly-crafted questions about how something works, answer those questions for you.