First off, every table should have a blind primary or clustering key. A blind key is a key that has nothing to do with the underlying data. A blind key is usually an auto-incrementing integer or long, or some other unique ID.
List ID is a primary key that contains a prefix like da-34244 pl-453 rs-3432 which identifies what type of list it is.
You should never have combination fields like this in a data base column. You should break the field up into a list code (da, pl, rs) and a number. You combine the fields when you generate an output so the users see their familiar list ID. I'm assuming these numbers are just incrementing integers. Separating the list type from the list number in the database makes it easier to keep track of the numbers used.
Query previous lists of all kinds (PL RS DA lists) by date, by sales man
You don't store a time stamp in any of your tables, so there's no way to query by date. Plus, you need to decide whether the list type is stored as uppercase or lowercase in your database. You've used list type in both lowercase and uppercase.
Query how much stock available in Warehouse
You finally mention a warehouse table that has the quantity values you would need.
Transactions
Edited to add: Sometimes, you have to execute more than one SQL statement to complete a transaction.
You have a transactions header table, a transaction detail table and a warehouse table.
Assuming the transaction detail table is from a return list, which means we're adding the stock quantity back to the warehouse table.
Your program would have to perform the following SQL steps
- insert the information into a transaction header row.
- For each sku in the return list:
- Insert the information into a transaction detail row.
- Select the warehouse row with the same sku_id.
- Add the quantity from the transaction detail row to the quantity of the warehouse row. If this were a pick list, you would subtract the quantity of the transaction detail row from the quantity of the warehouse row.
- Update the quantity on the warehouse row.
- Commit the database changes.
Either all of the above steps happen successfully, or none of the above steps happen successfully. This is what's known as a transaction. That's why you commit (or rollback) changes to a database.
The synchronization of a transaction is what keeps your stock quantities correct. Imagine what would happen in a real warehouse if the transaction detail rows were written to the database, but the warehouse quantity wasn't updated.
And yes, you have to do all of the steps outlined above. There is no shortcut.