Please take my words literally when I say that I wouldn't waste one minute on trying to solve your problem with your current sheet design. You would need VBA, and then extract quantities and prices from each purchase without the ability to filter on columns. (Minute is up.)
What you need is a Purchase database: ItemID, Date, Quantity, Price, maybe Ref#. From that you can pull out the transactions for any item by filtering on the item and the cost by using functions like SUMIF. However, this just brings the real problem within reach without solving it.
The problem is that when you buy 100 pcs @42 your price is 42. Then you buy another 100 pieces @46 your average price is 44. But if you sold 50 pieces with a cost of 42 then the average cost of the remaining 150 is 45. Therefore you can't determine the average cost of any remainder without knowing the quantity sold and the average cost applied to that sale. To solve that problem you will still need VBA but the suggested db format of purchase record would at least support such a solution.
Not so long ago I programmed a solution where there were additional columns in the db and each sale was recorded in 3 columns (much like your present purchase record): date, Qty, Ref. In this way I could trace the sale of each individual purchase (this was for shares trading). The sale of the newer quantity wouldn't start until the earlier quantity was sold out.
Perhaps you don't need to trace where the purchased quantity went to and just need one column to count down the balance to zero. That would be much simpler but has the drawback that you can't roll back errors. In the end the rollback was the reason why I abandoned the design. The key to the ability to abandon it is a similar db for sales: date, qty, price, Ref#.
With such a setup you might design a system to either extract the average or FiFo price from the purchase side and associate it with a sale. If the condition is that it should be done with worksheet functions you could add a column for "current cost" in the purchase db, changing with each purchase, which you look up by date from the sales side using VLOOKUP or SUMPRODUCT, having set a cost price applicable from the day of purchase until the next. If that appeals to you, a method must be found to deal with days on which there are both purchases and sales.
