This site has MANY discussions regarding inventory. Each of us will probably give you a superficially different view on such things. Here is what I would answer as my summary, and this is ONE PERSON'S OPINION, probably to be joined by many others and NONE of us is guaranteed to be right or wrong for you. More likely, you will see some ideas and pick-and-choose from among what you read and synthesize your "perfect" answer for your own situation. (And none of us will feel slighted if you don't pick our main method.)
1. A table of items, with PK of some kind of part or item identifier. If not an autonumber, then perhaps a numeric SKU or a mixed alphanumeric field. Include descriptive data as needed.
2. A table of transactions with an autonumber prime key and a foreign key of the part/item identifier. These transactions will include type, cost, date, and quantity. More about this in a moment.
3. You would have purchase orders and invoices, probably as two tables, and you could have child tables of line items that tie back each invoice or each purchase order. The line items tie back to the transactions for full accounting of where the items originated and where they went.
4. Among all the "definition" and "translation" tables you might have, you would have a transaction type table that converts a transaction code into a longer name AND includes a direction: +1 for stock adds and a -1 for stock removes.
5. You would of course also have customer and supplier tables. The previously mentioned sales invoice and purchase order line items will be linked to the item table and either the invoice or purchase order table. Those tables will be linked to your customer and supplier tables.
A transaction will be a stock add due to a purchase order or a return-to-stock, and those two will have slightly different transaction type codes. You would also have a stock remove due to a sales order or a breakage/shrinkage/whatever. Again, different transaction types for each detail. You can have transactions called InventoryAdjustUP and InventoryAdjustDOWN (or shorter names) if you do a sight inventory and find that your count and your reality are out of sync.
To get a listing of stock-on-hand at any time, you write a summation query of a JOIN between the transaction table and that transaction-type table where you sum the transaction quantity times the direction (+ or - 1, NEVER 0), GROUP BY part-identifier. To get a listing of stock-on-hand as of a given date other than today, take that first query and add a WHERE XActDate < Targetdate.
One last wrinkle... after a while this inventory can get awkward. Sometimes you decide you have too many records and that they go back longer than you need to go for historical purposes. So you run one of those queries to pick a cutoff date and generate "replacement" transactions that are the sum of all transactions prior to the cutoff date. Then you do an insert of the summary transaction which has as its date the chosen cutoff date. Next, you immediately run a delete of all non-summary transactions for that part that have dates earlier than the selected summary date. I.e. the summary replaces all transactions prior to its date INCLUDING any previous summary transaction, of which there would only be one at a time for each part ID.