Hi i have this tables
Sales
id_sales (pk)
amount
payments
payment_id (pk)
payment_type_id (fk)
id_sales (fk)
payments_type
payment_type_id (pk)
detail (example:cash, debit card, credit card, direct credit)
how can i manage that on sale can have two types of payments, for example: a sale is $100.00 i pay $50.00 with cash an another $50.00 with debit card, and the tables record it.
do you think it's a better approach to put two payment_type_id on the table payments and have it like that and when is just one payment let the other in NULL
Add a new "Amount" column to the "payments" table. Now you can store the split amounts with the payments.
When you have a split amount, you insert 1 record to sales and 2+ records to payments, one for each payment per sales transaction. You don't need to put null records into payments, only a record for each legitimate payment. You can now even put multiple payments of the same type if someone paid with 2 different credit cards etc.
All the payments relate to 1 sales transaction (id_sales). Each payment has 1 payment type and you don't have to put in blank records or NULL into any column.
Related
I’m learning SQL and have a basic question. I have a transactions table which contains payments and commissions.
A payment:
ID
Date
Amount
Type
Referrer ID
Balance
number
date
number
‘commission’ or ‘payment’
number
number
A commission has the same fields as payments, plus two additional fields: qualified and customerPaymentId
Qualified
Customer Payment ID
boolean (presumably 0 or 1)
number
Whenever a payment is made, the balance decreases, and vice versa whenever a commission occurs.
I have a user table too, where a user can have payments but not commissions. Should I separate the transactions table to be 2 tables (commissions and payments), or keep a single transactions table where the user table has a relation with it (rather than a relation to a separate payments table)?
Any advice or pointers would be great too, thank you.
UPDATE:
Sorry, I don’t think I have been very clear at all here. This is the transactions table, that contains both payments and commissions:
ID
Date
Amount
Type
Referrer ID
Balance
Qualified
Customer Payment Id
1
20/1/22
5.00
COMMISSION
5454
5.00
0
0001
2
28/1/22
4.00
COMMISSION
5454
9.00
0
0002
1
20/1/22
5.00
PAYMENT
5454
4.00
NULL
NULL
1
20/1/22
4.00
PAYMENT
5454
0.00
NULL
NULL
The type of ‘commission’ or ‘payment’ is there to determine whether a record is a commission or payment. A commission would have data for the ‘qualified’ and ‘customer payment id’ columns (but payments wouldn’t).
The Customer Payment ID column actually represents a different type of payment - a payment that a user makes for a product. Conversely, the transaction payment is a different payment that pays towards an affiliate’s balance.
The commission.balance and payment.balance represent an overall balance - commissions add to a user’s total balance while payments deduct from it.
To give some better context, this is for an affiliate system - when a customer buys a product, a payment (different - NOT a transaction payment; it’s from another table) is made, with a Customer Payment ID. An affiliate might have earned a commission from that sale, hence a commission record is made (in the transactions table). The amount they are owed is added to the affiliate’s balance. After 3 months, the commission becomes qualified, and the affiliate is paid their commission at the end of that month, hence a payment is made (a payment from the business to the affiliate), which deducts from the affiliate’s balance. It’s not simple to explain, but that is the gist of it if that makes somewhat sense :) I may not have constructed this the best way.
It's a little difficult to follow what's happening, but it seems you have a bunch of things which have some overlap in their fields but aren't actually the same. But sometimes you want to look at them all together.
I would suggest making separate tables for each kind of thing, and then a create a view to bring them all together.
For example...
create view transactions as
select created_on, amount, 'COMMISSION' as type, balance
from commissions
union all
select created_on, amount, 'PAYMENT' as type, balance
from payments
We use union instead of union all for performance. union removes duplicate rows which means the database has to do more work and operations are slower and more complicated. There are no duplicates in this instance.
Demonstration
I'm using an SQL Server database which has Order table contains a foreign key called invoice_id, this attribute belongs to Invoice table. Also, I have another table called "Receiptwhich also includesinvoice_idandamount_paid` attributes.
Many items can be assigned to the same invoice (customer may make many orders at once), also many receipts can be assigned to the same invoice (customer may make different payments to the same invoice as for example they can pay 50% and then pay the rest later).
So the problem I'm facing is when I try to select the total paid amounts from the Receipt table taking the order_id as a condition, the result will be multiplied according to the number of orders that have the same invoice_id
For example, customer A placed three orders at once, each order cost is 100 USD, which should be 300 USD in the invoice and he already paid that invoice. Now if I query the Receipt table for the paid amounts, the result will be 900 USD (300 USD * 3 orders), which is obviously incorrect.
I'm stuck at this issue, I believe there are some mistakes in my database logic, so please provide me your suggestions to solve this problem and also what should do with the database if the logic is incorrect.
Below is the query i'm using to get the result:
select sum(r.amount_paid), o.invoice_id from RECEIPT r, INVOICE i, ORDER o
where r.invoice_id = i.invoice_id
and o.invoice_id = i.invoice_id
group by o.invoice_id;
Here's three answers to three slightly different questions you might ask of your database.
Amount paid per invoice
If you are trying to get the total amount paid per invoice, all you need is
SELECT SUM(Amount_Paid) Total_Paid,
Invoice_ID
FROM Receipt
GROUP BY Invoice_ID
Amount paid per order
If you want to know the total paid per order, this is not quite possible in your data model as you have described it. If a invoice has three orders on it, and the invoice is only partly paid, there is no way to tell which of the the orders is paid and which is not.
You need some additional data structure that indicates how payments are applied to orders within an invoice, e.g. an Allocation or Split table.
Amount paid on invoices that pertain to one or more orders
On the other hand, if you want to know how much payment has been received on invoices that contain one or more order IDs, you could write this:
SELECT SUM(Amount_Paid) Total_Paid,
Invoice_ID
FROM Receipt
WHERE Invoice_ID IN (SELECT Invoice_ID
FROM Order
WHERE Order_ID IN (1,2,3,4)) --Edit these IDs for your specific case
GROUP BY Invoice_ID
Notice none of the queries above required any joins, so no multiplying :)
Please, try this:
SELECT SUM(r.amount_paid), r.invoice_id FROM RECEIPT r
JOIN INVOICE i ON r.invoice_id = i.invoice_id
JOIN ORDER o ON r.invoice_id = o.invoice_id AND r.order_id = o.order_Id
GROUP BY r.invoice_id;
I have an invoice management system. It has quotation, sales order, purchase order
The user has the option to generate invoices from multiple places
quotation when it is approved
sales order when it is accepted by the customer
purchase order directly can be converted to invoice
I have a table and there subtables likes this
quotations, quotations items
sales order, sales order items
purchase order, purchase order items
invoice, invoice items
How can I keep record of where the invoice is generated without breaking the relationships?
In the Invoice table created two new columns:
InvoiceSource VARCHAR(100)
InvoiceSourceID INT
Modify your code to store the source and Id of what created the Invoice. For example, if an invoice is generated from a quotation with primary key 1009. The following will exist in the invoice table:
InvoiceId|InvoiceSource|InvoiceSourceID|...
----------------------------------------
1200| 'QUOTATION'| 1009|...
Subsequently if a Sales Order with Id 1346 is converted to an Invoice the following will exist in the invoice table:
InvoiceId|InvoiceSource|InvoiceSourceID|...
----------------------------------------
1200| 'QUOTATION'| 1009|...
1201| 'SALESORDER'| 1346|...
i am trying to make database schema for a shop they have stock of products and walk in customers (so no need to record customers).
1 - need to record for stock .
2 - products
3 - selling products
i made tables for category , products , stock
now i am thinking for table for bill , i need to indicate all products with their price and quantity sold on bill slip.
so how to implement that ,
should i record each product with price and quantity for separate row with same bill no , or is there any better way.
simply finding solution to generate list of item sold with quantity and price for each item and sum up of total bill .
thanks in advance
Typically you would use two tables.
Invoices : InvoiceID, InvoiceDate, CustomerID, EmployeeID
and
LineItems : LineItemID, InvoiceID, ProductID, Name, Qty, UnitPrice
See how LineItems contains a foreign key to Invoices...
this is my invoice table:
Invoice Table:
invoice_id
creation_date
due_date
payment_date
status enum('not paid','paid','expired')
user_id
total_price
I wonder if it's Useful to have a payment table in order to record user payments for invoices.
payment table can be like this:
payment_id
payment_date
invoice_id
price_paid
status enum('successful', 'not successful')
If you want to allow more than one payment for an invoices, then yes a payment table would be useful.
It's also a good idea to keep your database normalized as much as possible.
Yes. Sometimes they might not pay in full or overpay, or pay in multiple transactions. Having the separate table allows you to keep track of this.
With just one table, all you can see is the original amount and the amount remaining to be paid, but not the history of payments.
Could a payment span multiple invoices?
Could an invoice be payed via multiple payments?
My guess is you will need a payment table and probably an account table and some sort of transaction table as well.
Many accounting applications have invoice_header, invoice_line, account_ledger, ledger_application and account tables.
The account_ledger table typically contains the items on the customer/vendor accounts. These items could be invoices, payments, or whatever.
The ledger_application table holds the information on the many-to-many relationship between payments and invoices.
The invoice_header table contains all information associated with an invoice which does not belong in the account_ledger table.
The invoice_line table has the data pertaining to the individual items/quantities/amounts on the invoice.
The account table stores data about the customer/vendor such as address, contact info, etc.