I look at your post #16, and it looks like when you implement all this you'll get some ERP DB for small firm
When you want to include producing part too, then you need:
Producing orders, i.e. an order to produce certain quantity of some article on certain date/date period, which is marked in your database as your product - like
tblProdOrder: ProdOrderID, ProdOrderDate, ProdArtID, Qty, ..., ClientOrderID (ProdOrder will be linked with client order. When client order has several products ordered, for every of them you need separate ProdOrder's. Also when the producing is done stepwise in different workplaces, then you need separate ProdOrders for every such step, where only the final one is producing ordered product - all other are to produce some medium part of it, and you need to register such medium parts a s articles.).
Then you need a BOM list for this product, where all components and their quantities for one unit of product are listed. This may be a simple list, or a structured one where every step of producing is described, with additional table where all operations for every step are described. As example let's it be a simple one:
tblBOM: BomID: ProdArtID, BomComment;
tblBomDetails: BomDetailID, BomID, RowNo, ComponentArtID, Unit, Qty.
Now, based on ProdOrder and BOM list + BOM Details for given product, you get a list of all components, and their quantities, you'll need to produce product(s)/medium part(s) in workplace. In case you have a Storage as unit in your firm, this will be a document for them to assemble all needed components and send them to production unit(s) at wanted date. When yo haven't, then production must simply collect them, and somehow register this.
When the product is produced, then it must be send into storage, or at least registered. Also, when some component is produced, and not used immediately in production, this must be registered as incoming transaction. And when such stored produced component is used later, then it must be included into BOM list.
As you see, it will get very complicated very fast. In case you want to do this anyway, my advice is to create 2 different apps - one for production, and another one for article management. Article management has to take into account all purchases and incoming purchased articles and all sales and shipping of sold articles as external movements, and all component complects sent to production for certain ProdOrder as outgoing articles, and all produced or partially produced articles, and components returned from production for some reason, as incoming articles as internal movements (you'll need a lot of various transaction types for it!).