I am designing a database for retail business using Sql server as backend. There are some products that can be sold in multiple units, for example, pencils can be sold in ea and dozen, paper can be sold in sheet, ream, and canton. Basically, each product can be sold in more than one unit.
The App needs to supports
Can receive products from suppliers in many unit. Sometime we might
order 1 pencil and the next time we order 2 boxes of pencil.
Can sell products in multiple unit, for example, we must be able to
sell 1 box and 2 pencils in the same bill.
App also need supports for FIFO or LIFO
Below is my initial design
Table: Products
ProductId | Barcode | Name | BaseUnitId
1 | XXXX | Pencil | 1
Table: Units
UnitId | Name
1 | Each / Pieces
2 | Box
Table: UnitConversion
ProductId | BaseUnitId | Multiplier | ToUnitId |
1 | 1 | 24 | 2 | // 24 pencils in a box
Table: Inventories
Id | ProductId | UnitId | Quantity
1 | 1 | 1 | 48 //In pieces
Table Invoices
Id | ProductId | UnitId | Quantity
1 | 1 | 2 | 1.5 //Sold/Purchased 1.5 boxes that means 18 pieces
Is there any flaws in my design? Is there anything that I miss? This can't be a new problem. Does anyone have any ideas (or examples)?
I have a few suggestions:
It seems like you could remove the UnitConversion table and just store the Multiplier value against the Unit record (so you'd store 1 against Each / Pieces and 24 against Box). Then the conversion would just be the 'From' unit's quantity divided by the 'To' unit's quantity.
Is is possible that different units would have different barcodes? If so, the barcode could be stored against the Unit record instead.
In your Inventories and Invoices tables, the ProductId column might be unnecessary as you could get this by joining Units table.
To support FIFO or LIFO, you're going to need to store more specific information about your stock, so there's some way of knowing the date it was booked in, the quantity remaining, and maybe some way of identifying that specific item (or group of items).
Hope this helps!
EDIT: Your Inventories table could look something like this:
Id | UnitId | [identifier] | CurrentQuantity | DateAdded
1 | 1 | ABC123 | 20 | 2017-01-10
2 | 1 | ABC124 | 96 | 2017-01-12
The [identifier] column (name's up to you!) would store some way of identifying the physical stock, this could be something that the users assign on receipt of the item, or maybe their suppliers would already have added some that could be used.
To implement FIFO in a scenario where someone wants to buy 24 pencils, you know you need to take 20 from the group of items labelled 'ABC123' and 4 labelled 'ABC124'.
Related
I'm trying to develop a database for my inventory. But I have no idea how to keep track of multilevel packaging.
For example:
I currently have a products and positions table
products
Id | Name
================
1013 | Metal
1014 | Wood
positions
id | Name
================
1 | 1-1-1-1
2 | 1-1-1-2
And my inventory table I was thinking of doing something like this:
Let's say I stored 1 box with 1000 Metal and 1 box with 500 Wood at position 1-1-1-1
ItemId | ProductId | Quantity | PositionId
==========================================
1 | 1013 | 1000 | 1
2 | 1014 | 500 | 1
So I'll label those two boxes with a barcode 1 and 2 respectively, so if I scan them, I can check this table to see the product and quantity inside them.
But I can also put these 2 boxes (1 and 2) inside another box (let's call it box 3), which would generate a new barcode for it that, if scanned, will show both previous boxes and its items. And store this box 3 in another position
And I can also put this box 3 inside a pallet, generating a new code and so on. So basically I can multilevel package N times.
What is the best table structure to keep track of all of this? Thanks in advance for any help!
I would add another column to the products table, make it a BIT and maybe call it BOM, BillOfMaterials, or whatever makes sense to you
So your products Table would look like this
Then you could create another table called BillOfMaterials
Quantity is how many of your products are needed to make up your new product. So for this example 2 metal and 1 wood make a pencil.
I was able to make a good structure:
My products and positions are the same but I created a stock table like:
id | product_id | amount | parent_id | position_id
=====================================================
1 | 1013 | 1000 | 4 | 1
2 | 1013 | 1000 | 4 | 1
3 | 1014 | 500 | 4 | 1
4 | 1234 | NULL | NULL | 1
The 1234 (random id) is a box that contains 2000 metal and 500 wood. I dont save this box in the product table.
When I scan the box with id 3, I perform a recursive cte query:
with recursive bom as (
select *, 1 as level
from testing.stock
where id = '4' #scanned id
union all
select c.*, p.level + 1
from testing.stock c
join bom p on c.parent_id = p.id
)
select product_id as product, sum(amount), position_id
from bom b
left join testing.product pd on b.product_id = pd.id
where pd.id is not null
group by product_id, position_id
which returns:
sum | product | position
2000 | 1013 | 3
500 | 1014 | 3
to get by position I just run a variation of the above query. To perform an update I get the Ids inside that box and run a
update testing.stock set position = '2' where id in (#variation of above query)
I hope this helps someone. This works for N packaging level
We are combining products, and want to get an idea of what demand may look like for the combined products vs what we had before. Here is some sample data:
A mapping of where products will be going called SKU_Mapping:
Old Product | New Product
1 | 2
3 | 4
Then I have some historical sales information called Sales:
Product | Quantity
1 | 5
2 | 10
3 | 3
4 | 7
I also have a table with all the SKUs to link my two other tables together called Master_SKU
Product
1
2
3
4
I have relationships between 'Master_SKU'[Product] to 'Sales'[Product] and from 'Master_SKU'[Product] to 'SKU_Mapping[Old Product]
I am trying to get an output like this
New Product | Old Product | Original Quantity | New Quantity
2 | 1 | 10 | 15
4 | 3 | 7 | 10
I cannot figure out how to write a formula that says, take the quantity of the new product and add it to the quantity of the old product. I have tried a bunch of different operators but for the life of me I cannot figure it out. Any insights or suggestions will be appreciated. Thank you.
I did this:
Here's how:
I set up three tables exactly as you described, with the relationships as you described. Then I opened the SKU_Mapping table and I added a column:
Old Product Qty = CALCULATE(sumx(Sales,Sales[Quantity]),filter(Sales,Sales[Product]=SKU_Mapping[Old Product]))
...and another column:
New Product Qty = CALCULATE(sumx(Sales,Sales[Quantity]),filter(Sales,Sales[Product]=SKU_Mapping[New Product]))
...and one last column:
Total Qty = SKU_Mapping[Old Product Qty]+SKU_Mapping[New Product Qty]
I do quite a bit of data analysis and use SQL on a daily basis but my queries are rather simple, usually pulling a lot of data which I thereafter manipulate in excel, where I'm a lot more experienced.
This time though I'm trying to generate some Live Charts which have as input a single SQL query. I will now have to create complex tables without the aid of the excel tools I'm so familiar with.
The problem is the following:
We have telesales agents that book appointments by answering to inbound calls and making outbound cals. These will generate leads that might potentially result in a sale. The relevant tables and fields for this problem are these:
Contact Table
Agent
Sales Table
Price
OutboundCallDate
I want to know for each telesales agent their respective Total Sales amount in one column, and their outbound sales value in another.
The end result should look something like this:
+-------+------------+---------------+
| Agent | TotalSales | OutboundSales |
+-------+------------+---------------+
| Tom | 30145 | 0 |
| Sally | 16449 | 1000 |
| John | 10500 | 300 |
| Joe | 50710 | 0 |
+-------+------------+---------------+
With the below SQL I get the following result:
SELECT contact.agent, SUM(sales.price)
FROM contact, sales
WHERE contact.id = sales.id
GROUP BY contact.agent
+-------+------------+
| Agent | TotalSales |
+-------+------------+
| Tom | 30145 |
| Sally | 16449 |
| John | 10500 |
| Joe | 50710 |
+-------+------------+
I want to add the third column to this query result, in which the price is summed only for records where the OutboundCallDate field contains data. Something a bit like (where sales.OutboundCallDate is Not Null)
I hope this is clear enough. Let me know if that's not the case.
Use CASE
SELECT c.Agent,
SUM(s.price) AS TotalSales,
SUM(CASE
WHEN s.OutboundCallDate IS NOT NULL THEN s.price
ELSE 0
END) AS OutboundSales
FROM contact c, sales s
WHERE c.id = s.id
GROUP BY c.agent
I think the code would look
SELECT contact.agent, SUM(sales.price)
FROM contact, sales
WHERE contact.id = sales.id AND SUM(WHERE sales.OutboundCallDate)
GROUP BY contact.agent
notI'm assuming your Sales table contains something like Units and Price. If it's just a sales amount, then replace the calculation with the sales amount field name.
The key thing here is that the value summed should only be the sales amount if the OutboundCallDate exists. If the OutboundCallDate is not NULL, then we're using a value of 0 for that row.
select Agent.Agent, TotalSales = sum (sales.Price*Units)
, OutboundSales = sum (
case when Outboundcalldate is not null then price*Units
else 0
end)
From Sales inner join Agent on Sales.Agent = Agent.Agent
Group by Agent.Agent
I'm trying to build a database with multiple tables for a study/research. This is the first time I'm designing database of this magnitude; the database grows by 100-200 records a day, and so far I have the data since 2010. Out of all the data, Generic Sequence Number, Product Name and the Strength of a drug (prescription) is slightly bothering me. This is what I have done so far:
Generic Seq number is unique to the strength of drug (product name). So, I have a table that contains id, generic seq no, and strength. Another table is for prod_id and product name. Each Generic seq number may have one or more product name, and each product name may have different generic seq number based on the strength. So, I set it up as many-to-many relationship. I created another table for this relationship that contains rx_id, drug_id, and prod_id. Since many patients may be prescribed for the same drug, the drug_id and prod_id may repeat several times in the rx_table.
My first question is, is this design appropriate?
How should I insert the data into rx_table? Should I create new record every time for new data even if the drug_id and prod_id already exist in the rx_table, or should I look for the rx_id where the drug_id and prod_id sequence exist and insert the rx_id into the other main table (not shown) which contains other data.
Or is this question too vague?
Thank you for your help.
I don't know what exactly is your Generic Sequence Number so i'll just use a real life drug example. From your description i think it's pretty similar to your application. Lets say you have Paracetamol as an agent. Then your Generic Sequence Number table would be something like
drug_id | generic_seq_no | strength
--------+--------------------+----------
1 | Paracetamol-100 | 100
2 | Paracetamol-250 | 250
3 | Paracetamol-500 | 500
Your product table would contain the names of the trademarks:
prod_id | prod_name
----------+------------
1 | Tylenol
2 | Captin
3 | Panadol
the rx_table contains the combinations of trademark name, agent and strength:
rx_id | drug_id | prod_id
-------+----------+----------
1 | 1 | 1
2 | 1 | 2
3 | 1 | 3
4 | 2 | 1
5 | 2 | 2
6 | 3 | 2
7 | 3 | 3
So e.g. the first row would be Tylenol, containing 100 mg of Paracetamol. Now you have what can be prescribed by a doctor and that's what you already did so far. So as i said your approach is fine.
Now you need (or have?) another table with all your patients
patient_id | firstname | lastname
-----------+-----------+-----------
1 | John | Doe
2 | Jane | Doe
In the end, you must link your trademark/agent/strength combination to the patients. Since one patient may get different drugs and multiple patients may get the same drug you need another many-to-many-relation, let's call it prescription
prescription_id | patient_id | rx_id
----------------+------------+------
1 | 1 | 1
2 | 1 | 3
3 | 2 | 4
This means John Doe will get Tylenol and Panadol containing 100 mg Paracetamol each. Jane Doe will receive Tylenol with 250 mg Paracetamol. I think the table you will be inserting the most is the prescription table in this model.
Our current database layout for store inventory includes a table that houses a record for each item and includes the item attributes such as price, cost, description, SKU, etc. Each store then has a table that has the SKU and the Quantity, and a few other attributes that are different for each store depending on the SKU.
Although this is better than having a column for each store's quantity in the Items table, it seems that this too is a somewhat ugly solution as when a new store is added, you need to select into a new table and when a new item is added, you have to insert into not only the items table but each individual store table.
Is there a better way to go about this than how I'm seeing it? It feels like there is.
Why not have a stock table with SKU, StoreId and Stock levels?
e.g.
Sku | StoreId | StockLevel
1234 | 001 | 15
1235 | 001 | 16
1234 | 002 | 8
1235 | 002 | 0
so, store 002 is out of stock of sku 1235, but store 001 has plenty. This table layout also allows you to get a group-wide view of your stock levels in a single table using something like
select sku, sum(StockLevel) from stock group by sku
By following the rules of data normalization, you would want to create a table like this:
store_id | sku | quantity | other_attributes ...
---------+--------+----------+---------------------
1000 | 129832 | 234 | ...
1000 | 129833 | 334 | ...
1000 | 129834 | 23 | ...
1001 | 129832 | 0 | ...
1001 | 129833 | 12 | ...
1001 | 129834 | 10 | ...
...
Essentially, it is a store_inventory table. That way, you can filter down to a given store by saying
WHERE store_id = 1000
etc...
You really want three tables as far as I can see:
Product
ProductID
Price
Description
...
StoreProduct
ProductID
StoreID
Quantity
...
Store
StoreID
Address
...
That's a perfectly valid and normalised database design, and sounds basically what you have right now.
It sounds like it started on the right path with having one table for all of the common attributes of the item.
Instead of having an individual table for each store, the inventory counts for all stores should be in a single additional table, using the Item's Key and the Store's Key as a combined Primary Key on that table.
For Example
Items
ItemKey
Name
Price
SKU
Stores
StoreKey
Name
Address
Inventory
StoreKey
ItemKey
Quantity
Using the StoreKey and ItemKey together on the Inventory table will keep your records unique.
This will allow you to not only easily lookup the single item but also lookup such things as:
Quantity of all items at one store by the StoreKey
Quantity of one item at all stores by the ItemKey
What items are low at all stores by Quantity
etc