Database Design for Product Inventory Stock (SuperMarket)

Question

In my past years, I made simple store app, where I made simple product table like this :

ID,Name,IDCategory,Size,Qty,buyprice,sellprice

the Quantity field is in product table, and when in the transaction, I would just add or subtract it on that table.

And now, in my new supermarket application, I know I need to design more complex table for keeping track of the stock item quantities because the product now has an expiration date, different buyprice (and maybe sell price too). this is the only way to ensure the financial report to be accurate, where we could get the actual profit of each transaction.

My new product table is like

ID,Name,IDCategory,Size,ExpirationDate,SellPrice    '(I remove qty and keep sell price to simplified and sell my item at 1 price only )

The problem with the design is it becomes more complex in database and programming design as well, I think I need to apply FIFO system, and it becomes more complex for me as I think about edit transaction/returning items, etc.

what I could imagine right now is to make the table similar like this :

tblProductQty = BuyInvoiceID,Date,IDProduct,Qty

but then I realize this information already in my tblBuyTransactionDetail ( *table that keeps my buying transaction (like invoiceNo,SupplierID,Date,Total) with the details table like (InvoiceNo,IDProduct,Qty,BuyPrice,ExpirationDate))

now I am really confused, do I really need stockTable ?? but if not, it's meant that I need to do sum and subtract between transaction query to get a quantity of one product.

How you guys actually do this? what is the common design of all the big supermarkets use out there?

note: I currently use access and vbnet

Answer 1

I know for most erp systems there are separate tables for each of the following;

Purchases (note a purchase is not necessarily a product)

Product transactions (you will need this to calculate fifo stock values)

Sales (usually but not always products)

Product details (description etc)

You mention expiry dates. These should be recorded against individual purchases ideally.

Also note that purchases and sales are usually broken down into a header table and a details table (invoices and invoice lines).

Answer 2

Both Ways are used to do this, Some use separate De normalized stock Table and Some Calculate it while reporting. Both are the correct way but below are the pros and cons of using separate Stock table, Please use as suitable to you.

Pros:

1. Reporting will be fast.
2. Reports Logic will be easy.
3. If you provide Stock Closing Functionality after a time period, then same stock table can be used by adding some additional columns in that table.

Cons:

1. Separate Stock Tables Handling is more error prone as there each every transaction related to stock up and down will also need to update this new stock table as well.
2. if there is very Frequent Stock up and Down in your application, then it will effect the performance of system as on each stock add or subtract this table will be locked in transaction and updated.