I want to know how to design invoice table.
An invoice include many orders from order table.
Is this invoices table is correctly designed?
order
order_id (PK)
User_id (FK)
total_cost
order_date
status
order_item
order_item_id (PK)
order_id (FK)
item_name
cost
invoice table
invoice_id (PK)
invoice_no
invoice_date
period_start_date
period_end_date
status
invoice_order (an invoice with many orders)
invoice_order_id (PK)
invoice_id (FK)
order_id (FK)
Is invoice_order table necessarry?
I could add invoice_id (FK) field in the order_table instead. The "order. invoice_id" would be updated when I have added a row in the invoice table.
You only need the invoice_order table if:
An order can have one or more invoices
AND
An invoice can be linked to one or more orders
By your suggestion at the end of your question, that's the case. You should not just have invoice_id and get it updated when a new invoice comes in, because you would lose the link between the order and the previous invoice.
Update
By the way, it's good that you have cost and item_name in order items, which is something beginners tend to find weird. You have to have those for historical reasons and to make possible to reprint the order with the same data, say, 3 years later, when the item might have had its name slightly changed and cost has surely been updated.
You need the linking table. An order can be in mulitple invoices (if they didn't pay it!) and an invoice can contain many orders. In a linking table though I would not bother with •invoice_order_id (PK). The PK is a combination of the two FK fields. That guarantees uniqueness and since you are unlikely to have a child table of the link table, you really gain nothing by adding a surrogate key to it. Even if you did the performance difference between joining on two indexed int fields vice one would probably be negligible.
Most invoices will have:
Customer ID
Sales Rep ID
Payment Method
Ship to Address
Billing Address
CheckBox: Shipto same as billing
etc.
Generalisation !! You should consider reducing that to 2 tables: Documents and DocDetails. Just add a DocType field in the Documents table, to differentiate Orders from Invoices.
If you need to track backorders, add a Link field to your DocDetails.
When you add an Order detail line, give the Link field the value of the table PK (counter).
When you add an invoice detail line, give the link the same value as the related order detail.
By the way, did not see any CustomerId in your tables !
Related
I am working on a School Management System. As you can see a student can be registered to multiple Organization. All registrations can be invoiced.
For instance last month Registration 1 has been invoiced for a total of 1000$ and the Parents receive the invoice of their child.
The problem
So : 1 invoice = 1 registration
Now, what if parents want only ONE invoice per month for all their children (1 invoices for 4 registrations) ? (this should be optional just for some parents, not all)
Possible Solution
My idea, as invoice relations are already polymorphic, what if instead of Registration, Parent 1 is billed directly?
What do you think?
PS: please note that every invoices have a reference like: INV-000XXX and should be unique
You can easily solve your scenario by adding another table "Invoice Line Item"
Invoices
id
invoice_no (reference) unique
parent_id
Invoice_line_item
id
invoice_id (Foreign Key of Invoice)
registration_id (FK of Registration) (One -> Many relationship)
Now you can create invoice whether there is a single child or multiple children of a parent.
I believe you understood this relation. Let me know if you need more clarification
there is a website which used to sale physical products ... now they want to sale some king of service which is completely different .... like credit packages to charge user account(to buy products) or buy sms .. stuff like that
so db used to look like this
order : user_id ,date , total_price
order_items : order_id , item_id , quantity , price
invoice : order_id , price , settled
Invoice_transactions : invoice_id , amount , date
basically invoice belongs to orders
now they want to sale services , so we have to create 2 orders table
product_orders (it used to be orders)
service_orders
now i have to choose a design for invoice table
i can add add another field to indicate type pf the order
invoice : order_id , order_type , amount
1 , product , 10000
1 , service , 10000
which somehow doesn't feel right ... or i can add invoice id to orders
invoice : order_type , amount , date
product_orders : invoice_id , date , total_price
service_orders : invoice_id , service_id , date , total_price
which one(if any) seems to be more reasonable design ?
here is products table :
here is what service tables would look like :
here is orders (which should change to product order )
here is what service_order would look like
I presume that both product orders and service orders have more in common than they have in difference. Within the greater business and financial ecosystem, they likely share the same roles/functions. So my first instinct to have a single table for both kinds of orders.
One-To-One tables
Another route is to have simply one order_ table, with a column indicating which type of order named something like order_type_ containing values like sales or products.
Move all the product-related columns to a separate child table, product_info_. Move all the sales-related columns to a separate child table, service_info_. I would make order_ table the parent to both, though technically we have a One-To-One relationship. For any given order_ row we have exactly one product_info_ row or exactly one service_info_ row.
This might minimize duplication of data in the database and coding in your app. Your app code uses the flag field order_type_ to query one or the other child table appropriately when you need the product or service details.
The invoices table links against the orders table. I assume invoicing works pretty much the same for both types of orders.
All fields in Order
Another alternative is simply including all the product and service fields within the order_ table. Simply ignore the product-related fields for the service orders, and ignore the service-related fields for the product orders. Not the most elegant, but if you have relatively few fields, and perhaps prefix the column names with prod_ and serv_, this may be practicable. I have certainly done this more than once.
It all depends on what you want to achieve with it, can a customer buy both in one order? The most common is what you did with invoice with an order_type it will have the least duplication
This is what I would try to do:
Table types
type_id | name
1 | product
2 | service
Table items would have common columns for both - products and services.
items: item_id, type_id FK(types.type_id), price, title, ...
Tables products and services with FK item_id and columns that are not common for both types (like products.weight).
Add type_id column to the orders table:
order : user_id, date, total_price, type_id FK(types.type_id)
Add type_id column to the table order_items:
order_items: order_id, item_id, type_id, quantity, price
The FKs would be:
(order_id, type_id) -> orders(order_id, type_id)
(item_id, type_id) -> items(item_id, type_id)
With those FKs it's not possible to mix different types in one order.
For a purchase-scenario:
I have a table (PRODUCTS) that contain columns like NAME, TYPE, DEFAULTPRICE, ID and a table with sales (SALES) that contain columns like DATE, ID, PRICE, AMOUNT where ID in SALES is a foreign key to primary key ID in PRODUCTS. Very simple, not much to mess up there.
This works fine as long as you insert one row of whichever product (and how many) at what total price.
BUT - let's say I want to design this system to support "basket"-kind of shopping. I.e. a user selects several items that are not the same product ID, but gets a single ORDER ID that contains all the products that were included in the order, the amount of each product, the total price, date etc.
How would one go about creating this? I was thinking maybe creating a table called "ORDERS" and link every row from SALES to an ID from ORDERS - but I'm not sure.
You would create a table called Orders for each order. It would have whatever information you want about the order.
You would then have a table for the products in each order. A common name is OrderLines. This would have an OrderId, linking it to the Orders table and a ProductId linking to the Products table.
Am designing a database schema (orders and bills) for a hotel system.
The attached image shows the tables in the database schema.
The question is how do I design the bills table, so that I can calculate the customer bill from orders the customer has made?
My assumption is that a bill is calculated after the order is made, and not the other way round, e.g. creating a bill before we make an order.
I am considering this answer however it does not solve my problem, since I want to calculate bills from customer orders.
The red rectangle shows the relationship between the orders and bill table this is where am stuck, I don't know how to design the tables.
Some language standardization first:
By Order you mean Sales Order, OrderDetails are called Line Items, and a Bill is usually called a Sales Invoice.
An sales invoice is a request for payment. You issue one when you think someone owes you money.
Depending on the terms of the sales order, someone owes you money:
after the order is completed
after the service is first delivered
after the service is completely delivered
after some period of time based on the terms of the sales order
For a hotel, usually you ask for money after the service has been completely delivered, but perhaps with a deposit, or intermediate payments for a long stay.
An invoice is not necessarily for one sales order. You can combine multiple sales orders into one invoice.
An invoice has line items referencing the sales order line items that you are requesting payment for.
You may have to issue multiple invoices for the same person/sales order.
EDIT 3 added design + cleanup
Every base table is the rows satisfying some statement. Find the statement.
Customer is the rows satisfying: customer [CustomerId] named [CustomerName] lives at ...
Product is the rows satisfying: product [ProductId] is named [Productname] costing [ProductPrice]
OrderDetail is the rows satisfying: orderDetail [OrderDetailId] of order [OrderId] is quantity [quantity] of product [ProductId]
Order is the rows satisfying: customer [CustomerId] ordered [OrderId] on [dateOfOrder]
What rows do you want in Bill? I'll guess...
Bill is the rows satisfying:
Bill [BillId] is for order [OrderId] on [dateOfBill] ... ???
You can find out some things about a bill by using its order. You must determine what else besides its date and order that you want know about a bill (eg to write one) and then what statement bill rows satisfy (ie finish the "...") that gives you that info directly (as with its date) or indirectly (as with its order).
I asked
what else besides its date and order that you want know about a bill (eg to write one)
BillId
dateOfBill
OrderId
order OrderId's customer's CustomerId, CustomerName, CustomerAddress ...
order OrderId's dateOfOrder
for every orderDetailId's orderDetail whose orderID = OrderId
quantity, ProductId, ProductNam,e ProductPrice, (quantity * ProductPrice) as productProduct
sum(quantity * ProductPrice) as total
over every orderDetail with OrderDetailId = OrderId
I asked
what statement bill rows satisfy that gives you that info directly or indirectly
You suggested
For the bills table I intend to have the following fields
Bill BillId (PK) CustomerId (FK) OrderId (FK) dateOfBill
Bill has to directly give us a BillId, dateOfBill and OrderId; they're nowhere else. But everything else can be got indirectly.
Bill is the rows satisfying:
bill [BillId] is for order [OrderId] and was billed on [dateOfBill]
The reason I mention statements is: one needs them to query and to determine FDs, keys, uniqueness, Fks, and other constraints. (Rather than using one vague intuitions.) This is explicit in design methods ORM2, NIAM and FCO-IM.
I determined the content of a bill above by finding what statement its rows will satisfy:
customer [CustomerId] named [CustomerName] at [CustomerAddress] ...
owes us $[total] for order [OrderId]
ordering [quantity] of product [ProductId] named [ProductName] # price $[ProductPrice] = [productProduct]
as recorded in bill [BillId]
This is a statement made from the statements given for each table, except that I need some statements not in any table yet, namely the stuff that (therefore) Bill needs to give. By replacing the statements by their tables we will get the query whose values are the rows we want.
I designed my database for customers, products, and orders... I came up with 5 tables:
1. customers
customer_id
email
password
first_name
last_name
registration_date
2. products
product_id
type_id (refers to type table)
price
size
3. Type
type_id
name
description
4. order
order_id
customer_id (refers to customer table)
total_price
total_tax
date
5. order_item
order_item_id
order_id
product_id (refers to product_id)
quantity
price
I realized that shoes/t-shirt/shirt will have a size, but accessories don't...
Should I add 1 more table like product_description? so in the product table, there will be product_description_id. If the product_description_id is 0, then it doesn't have any more description like size, but if its not 0 then it has...
EDITED
guys guys, i have 1 more problem, because i want to let the customer to buy more than 1 item(more than 1 type) in a time :s does above table can do that? i meant, will it fit that situation? i already edited the table, sry if im asking too much :D
I would add the product descriptions to your product table:
product_id
type_id
size etc
And I would introduce an order table:
order_id
customer_id
total price
total tax
etc
and have your order_description renamed to order_item with
order_id
product_id
quantity
etc
I suggest to consider oneTomany table because one order may contain more than one article.
In this case you need a table that contains Order_Id, Product_Id, possibly a second containing Client_ID and Order_ID and so on ... Try to individuate all cases where you need a one to many or many to many relationships.
Inany case the suggested readings in the previous answers will helps you a lot.