I am trying to design a data structure where the class/table has multiple differentiation's withing it itself. I am not sure what to call this or if I use the right terminology.
Hopefully I can illustrate my problem with the following example:
There is a webshop and somebody buys something and goes to the check out. At the check out they can select their payment type. The customer selects cash and with what currency.
An other customer does the same but pays online with credit card.
Now I have the following mysql scheme for this situation:
**Order**
order_id
customer_id
is_paid
payment_type_id
**payment_type**
payment_type_id
payment_name
And a customer table with the usual information. But where do I save if was paid and if required information about how the customer is going to pay.
How would such a database look like and what would the queries look like?
I am not a fan of a little field within tables where the data could be anything depending on the type (or is that the way to go?) cause of querying problems.
Hopefully I am clear enough in what I am asking.
If you have a single payment for each order you want to have it attached to it, so the 'is_paid' is just fine there, as well as the payment type. In this case you want the currency there also. Cause it is independent of the payment type.
I only see problems if you want to know more info about the payment like when it was paid or if you consider a payment for more than one order at a time or even if a payment don't happen at the same time as the order and you want to separate the concepts.
To solve the 1st instead of is_paid you can have a datetime field that when it's NULL is not paid. For the 2nd and 3rd you would need some Payment entity also. For a richer model with some logic about the payment I would have something like:
**Order**
id
payment_id
...
(all sort of info about the order)
** Payment **
id
customer_id
payment_type (or payment_type_id)
payment_value
payment_currency
payment_date
...
(more info about the payment)
Depending on what you'll do with payment_type you can consider having only a value describing the type or an id for the table with more info about it as you already had.
However this will be an overkill if you just have Order 1..1 Payment, in that case just store payments info as you had, along the order.
This is subjective, but I usually have a payment type (cash, credit card, souls, etc.), a payment amount (100.00) and a payment currency (USD, CAD, MXN, etc.) fields in the order table, alternatively, and if you payment system supports it, you can add conversion factor.
Related
I have done air ticket cancellation service. but I don't know how to refund the amount. If anyone know how to refund the balance amount. Please provide the flow of refund web-service. we used here PHP, and soap API.
Sabre has a webservice for an Automated Refunds (TKT_RefundRQ). However, the list of aircompanies supporting the Automated Refunds flow is very limited, you may find it here.
I guess in most cases you should read fare rules (cat. 16) to find out what penalties apply. You may use either StructureFareRulesRQ for structured or OTA_AirRulesLLSRQ for plain text fare rules.
Step 1:
Save your Ticket order into another table. You need to put the order value (Money) . into the table
step 2:
when somebody orders a ticket you have to Cut that ticket price and save a new price in your amount table
( Now for example You have a amount of 200$ in your amount table)
( You ordered a ticket , store that ticket ID )
(get ticket amount using Join query ) or ( You can store the amount in the order table )
Step3:
Get you amount from amount table and subtract with the order amount
Here you go... got whole idea?
Happy coding ...
I am working on a project, and I am trying to find a way to associate my pricing plans table with a customer.
id name description price days
1 Free the free plan 0.00 0
2 Silver the silver plan 49.99 365
3 Gold the gold plan 99.99 365
My first thought was to add the plan id as foreign key to the customers table. But i also need to know when is the expire date (based on the purchase date and the days of the plan selected).
When attempting to do something like this, it is best to keep tables abstracted from each other.
user_pricing_plans - the table name
pricing_plans_id - the id for the record you want to associate with a user
user_id - the id of the user
date_expiration - the date the plan will expire
date_purchased - the date the plan was purchased
following an approach like this will allow you alter this table if needed to add extra information. you could also follow a similar approach in the future with another table.
the key to all of this is separating your concerns ( the data ) into separate containers.
Edit: to kind of hint at what I'm getting at about why separating the tables is a good idea, I added the date_purchased as a field in the user_pricing_plans table.
a dba I know once said that "mysql is not a place for developers - they try to create tables to work with their code. tables are meant to represent data. your code should be written to work with the data and the schemas that represent them - not the other way around"
I do not know why I can not add a comment to the best answer in the post.
As #Jonathon Hibbard points few years ago, there is another reason to separate the data between pricing plan and user model.
You used to have users who have one plan and choose another later, that is called, "history". To manage that, this third table is very important.
And in my opinion, more important, one thing is your pricing table, an another one is the final price you have with every client. Yo have knownledge people, close clients that you want "special" prices, this third table gives you the oportunity to set diferent prices for one plan with fixed price and a lot of other use cases.
Think about your main plan table like a product, the user is the client, and the third party as the ticket, with "temp pricing" aplied, ocassional discounts or whatever.
I am integrating one of the payment gateway to my site in PHP, Before proceeding further, As I am new to this, I have some doubts (use cases/scenarios), So I need a solution to deal with these scenarios. I have listed them here
1) How to pass unique id to payment gateway, while It considers it as a Order No, But In real scenario Order NO/ID will be generated only on successful transaction. I thought of sending a random number to Payment gateway. On successful transaction i can store in Order table.
Table: Order
1) aID:(unique, Primary, AI)
2) RandomNo(unique)
3) Order Date
Is this a good Idea
2) Which ID to be shown to user As ORDER ID either the aID or RandomNO
3) Do I need to store the Response from the payment gateway in the DB, such as Payment ID(unique), Response Code, OrderNO & Amount. How it will be useful.
4) What are the possible scenarios that can occur after payment gateway integration, And How to deal them
1) How to pass unique id to payment gateway, while It considers it as a Order No, But In real scenario Order NO/ID will be generated only on successful transaction. I thought of sending a random number to Payment gateway. On successful transaction i can store in Order table.
ANS : First of all insert the order in database before redirecting to payment gateway and use the unique id of that insertion as order id.
2) Which ID to be shown to user As ORDER ID either the aID or RandomNO
ANS : The order id as mentioned above can be shown to the user.
3) Do I need to store the Response from the payment gateway in the DB, such as Payment ID(unique), Response Code, OrderNO & Amount. How it will be useful.
ANS : Yes! You must store response from payment gateway as you may need it in future in case of any dispute.
4) What are the possible scenarios that can occur after payment gateway integration, And How to deal them
ANS : I didn't get you in this question.
I'm actually worried about designing the perfect tables to handle transactions and commissions. especially that we really don't want tables to be out of sync in any case.
Basically this is like ebay, where merchants sell to buyers and we get a commission out of each transaction.
The app is already built using Codeigniter, and it has:
Merchants(id,name,balance)
Transactions(id,merchant_id,buyer_id,amount,transaction_id)
Now what other tables to make if needed to make us able to fetch our revenue and the seller's revenue, and what's the best DB mechanism to process a refund?
And should we make another table of each deposit to the merchant's balance rather than +x the balance row.
Whenever you are dealing with any financial tasks, always store as much information about it as possible.
There are two ways of keeping all your tables in sync.
Database level - using options such as stored procedures and triggers
Application level - Use transactions (innoDB) and make sure that the transactions are atomic. (I would suggest to go with this)
Regarding the database design -
Add a column commission to Transactions that tracks your commission. Data for this can be either calculate beforehand when pricing the item or on the fly during the transaction.
The buyer pays product cost + commission, seller gets product cost and you get commission. If your commission is a variable (not a flat rate and changes from item to item), you could have a column in the Items table which stores it. Things should be trivial from now on. You just have to maintain a History table that keeps a list of transactions with respect to the user. It would look something like
AccountHistory(id, transaction_type, transaction_id, amount)
You could split AccountHistory into two - one for incoming money and one for outgoing money.
So everytime a transaction takes place the following happens
Entry into to Transactions table.
Entry into AccountHistory for buyer
Update buyer balance
Entry into AccountHistory for seller
Update seller balance
All this should be atomic.
For rollbacks, you could add a column transaction_type to distinguish rollbacks from normal transaction or you could maintain a separate table.
Having worked with a database where the design had financial transactions scattered around a bunch of different tables, I can tell you that it is much better to have all transactions in a single table. You should add transaction type to your transaction table (and a look up table for the transaction types).
Then each transaction can have a separate line for commission and seller product cost. Transaction that are undone later would get entered in as negative amounts. It is also helpful for these types of things to add a parent transaction field so that you can easily identify which transaction it was changing.
All data entry that forms part of a transaction should be in a stored proc and have transactions so that if one part of the insert fails, the entire thing is immediately rolled back. This is critical. It needs to be in a stored proc so that no one (except systems dbas) has direct access to tables that store financial records.
When you start to think of handling financial transactions the very worst thing you can do is design for the user interface alone. You need to design for the financial reporting you will need to have. You need to consult the people who will be auditing your finances to see what information they need and what internal controls they expect you to have in place to prevent internal as well as external fraud.
i am doing small billing application,
i need some guidance about database design for billing software,
i have product table in this am maintaining below fields,
Product table
Product code , unique ,
quantity ,
price,
vat,
discount ,
and some of few columns like userid, createddate ,
Basket table,
basketid ,
PHPSESSIONID ,
productcode,
quantity ,
and few required details like userid, created date ,
counter people entering bills are initially store into tblbasket table,
when billing is confirmed , Required details are move to tblSale table,
tblSale table:
id AI,PK,
BasketSessionID ,(no foreign key concept but just inserting that tbl basket PHPSESSIONID )
productcose , and few required details,
The above details am holding for billing application,
Now i need some guidence to proceed furtheir,
need to implement reports , daily sale, returns and every thing,
So First step is,
i want to maintain something like below,
Product code Total stockin count,
after sold need some stock out count,
if returns means how to maintain,
So totally i want table design for Stockin, Stockout,Returns , Free CD,
Total idea behind is,
Reporting view for billing application,
Before you make your final decisions on the database schema take some time to look at the Microsoft example data AdventureWorks2008 for SQL Server.
This link points to the availabel samples for SQL Server
This link is a tutorial on creating reports.
This link is a sample web app for Adventure Works
After you have reviewed the database design I believe you will have the answers to your questions mentioned above. If you have additional questions you can reference the AdventureWorks databse to help describe your question or goal.