Best inventory database structure

I want to create a small database for my inventory, but I have some problems choosing a structure. Resources will be updated daily at the end of the day.

The problem I am facing is the following.

I have a table for my products that has

id, name, price, quantity. 

Now I have another table for my sales, but there is my problem. What fields do I need. At the end of the day, I want to save the entry as follows:

 20 product_x $ 5,00 $ 100,- 20 product_y $ 5,00 $ 100,- 20 product_z $ 5,00 $ 100,- 20 product_a $ 5,00 $ 100,- ------------------------------------------------- $ 400,- 

So, how do I do this in a sales record. I just create a concatenated product id separated by comma.

Or is there any other way to make the right choice.

+12
database structure
source share
7 answers

I will have a table with a line for an item per day - save the date, product ID, quantity sold and price sold (keep it even if it is also in the product table - if that changes, you want the value you actually sold, preserved). You can calculate the totals for each day of the day and the totals per day in the queries.

Tables:

 create table product ( id integer primary key, name varchar(100) not null, price decimal(6,2) not null, inventory integer not null ); create table sale ( saledate date not null, product_id integer not null references product, quantity integer not null, price decimal(6,2) not null, primary key (saledate, product_id) ); 

Daily Reporting:

 select s.product_id, p.name, s.quantity, s.price, (s.quantity * s.price) as total from product p, sale s where p.id = s.product_id and s.saledate = date '2010-12-5'; 

Reporting for all days:

 select saledate, sum(quantity * price) as total from sale group by saledate order by saledate; 

Good main report for all days, with a summary line:

 select * from ( (select s.saledate, s.product_id, p.name, s.quantity, s.price, (s.quantity * s.price) as total from product p, sale s where p.id = s.product_id) union (select saledate, NULL, 'TOTAL', sum(quantity), NULL, sum(quantity * price) as total from sale group by saledate) ) as summedsales order by saledate, product_id; 
+8
source share

This is a model that supports many aspects,

  • Support sites, locations and warehouses, etc.
  • Support for categorization and grouping
  • General product support (for example, "Desk Clock" and the special product "Citizen C123 Multi Alarm Clock")
  • Also support brand options (by different manufacturers).
  • Has CSM (color / size / model support) Example. Bata Sandles (color 45 inches blue)
  • Product instances with serial numbers (such as televisions, refrigerators, etc.).
  • Batch management / batch management with serial numbers.
  • Package Size / UOM and UOM Conversion
  • Manufacturer and brands, as well as suppliers
  • An example transaction table (purchase order) is also included.
  • There are many other types of transactions, such as "Problems", "Transfers", "Adjustments", etc.

Hope this helps. Please let me know if you need more information on each table.

Hooray!!!...

Wajira Weerasinghe.

Sites

  • ID
  • site_code
  • site_name

Warehouse

  • ID
  • site_id
  • warehouse_code
  • warehouse_name

Product Category

  • ID
  • category_code
  • category_name

Item group

  • ID
  • group_code
  • group_name

General product

  • ID
  • generic_name

Product

  • ID
  • product_code
  • category_id
  • group_id
  • Brand_ID
  • generic_id
  • model_id / part_id
  • product_name
  • PRODUCT_DESCRIPTION
  • product_price (current bid)
  • has_instances (g / l)
  • has_lots (y / n)
  • has_attributes
  • default_uom
  • PACK_SIZE
  • average_cost
  • single_unit_product_code (for packages)
  • size_group (indicating size)
  • lot_information
  • warranty_terms (general non-specific)
  • is_active
  • cross out

product attribute type (color / size, etc.)

  • ID
  • attribute_name

product_attribute

  • ID
  • product_id
  • attribute_id

product attribute value (this product β†’ red)

  • ID
  • product_attribute_id
  • value

product_instance

  • ID
  • product_id
  • InstanceName (as specified by the manufacturer)
  • serial_number
  • brand_id (this is a brand)
  • stock_id (stock record indicating qih, location, etc.).
  • lot_information (lot_id)
  • warranty_terms
  • product property identifier (if applicable)

product series

  • ID
  • lot_code / batch_code
  • date_manufactured
  • date_expiry
  • product property identifier (if applicable)

Mark

  • ID
  • manufacturer_id
  • brand_code
  • BRAND_NAME

Brand manufacturer

  • ID
  • manufacturer_name

A photo

  • ID
  • product_id
  • storage_id, zone_id, level_id, rack_id, etc.
  • amount in hand
  • Product attribute value identifier (if applicable) [we have 4 red elements, etc.]

Product Pricing Report

  • product_id
  • FROM_DATE
  • PRODUCT_PRICE

Purchase Order Header

  • ID
  • supplier_id
  • PURCHASES
  • TOTAL_AMOUNT

Purchase Order Line

  • ID
  • po_id
  • product_id
  • unit_price
  • quantity

Provider

  • ID
  • supplier_code
  • Supplier Name
  • supplier_type

product_uom

  • ID
  • uom_name

product_uom_conversion

  • ID
  • from_uom_id
  • to_uom_id
  • conversion_rule
+34
source share

Try to simulate sales as transactions - using the β€œheading”, that is, sold when sold, invoice # (if applicable), etc. and "positions", i.e. 20 * product_x @ $ 5 = $ 100. The safest approach is to not rely on prices, etc. From the product table - since they are likely to change over time and instead copy most of the product information (if not all) to your position - so even when prices, item descriptions, etc .., information about transaction remains the same as at the time of the transaction.

+1
source share

Inventory can be a rather complex model. First you need to understand that you need to specify the value of the inventory based on what you paid for it. This means that you cannot rely on a product table that is updated to the current price. Although you may need a table to help you figure out what to sell, there are tax reasons why you need to know the actual amount you paid for each item in stock.

So, first you need a product table (you might want to make sure you have an updated date column in this case, it may be convenient to find out if your prices are tired).

Then you need a table that stores the actual location of the warehouse of each part and the price at the time of purchase. If the elements are large enough, you need a way to individually label each element so that you know what was removed. Typically, barcodes are used for this. This table needs to be updated to record that this part no longer exists when you sell it. I prefer to make the record inactive and have a link to my sales data for this record, so I know for sure what I paid for and what I sold each part for.

Sales must have at least two tables. One for general sales information, a custom name (there must also be a customer table most of the time to get this data), the date where it was sent, etc.

Then a sales details table that includes an entry for each line item in the order. Include all the data needed for the part, color, size, quantity, price. This is not denormalization, it is the storage of historical data. The only thing you do not want to do is rely on prices in the product table for everything except the master record in this table. You do not want to make a sales report, and the numbers are not coming out correctly, because the prices of goods have changed the day before.

Do not create an inventory database without consulting an accountant or tax specialist. You should also read some internal control data. It is easy to steal from an unknown company that has not completed its internal control work in the database.

+1
source share

I think you need a table with fields showing the properties of transactions for each client OR a table with fields - date, product (foreign), quantity - so you will not have problems with new products.

0
source share

Try some tables with links

 table_products id name table_product_sales id product_id quantity price_per transaction_time AS DATETIME SELECT table_product_sales.*, table_product.name FROM table_product JOIN table_product_sales ON table_product_sales.product_id = table_product.id GROUP BY DATE(transaction_time) 

Did not try, but will something like this work? This allows you to store each transaction separately so that you can request things like the average number of sold per sale, the total number of sold per day, the total number of sales per day, etc.

0
source share

@Wajira Weerasinghe

You are a good structure, I want to use it in our project. Can you send me an ER chart for inventory management system

0
source share

All Articles