I'm developing a simple invoice system using PHP and MySQL.
My initial thought was to use ID (auto incremented) for invoice ID. But that will not work.
A temporary invoice is created when user commits an order to my Payment Service Provider.
If the transaction fails, I need to delete the temporary invoice.
The problem is that the invoice has been created and given and ID - and by law, I'm not allowed to delete any invoices that has been given a invoice number. So I need to add another column 'invoice_id' and add an ID after successful transaction.
Multiple users may do a purchase at the same time.
My question is, how can I make sure to retrieve the last created invoice ID and increment this?
Should I use a $_SESSION[]for storing invoice_id? Or should I retrieve latest ID from DB? If retrieving from DB, should I lock the table for this transaction?
Any guidance much appreciated.
Create a temporary table for invoices which have not been processes.
Once the invoice has been processed, move over to permanent table and assign an invoice id using the AUTO_INCREMENT option in mysql
This will allow for two tables, one for unprocessed and the other for processed. You can also place an id field to keep track of the movement from temp -> perm
I wouldn't delete it, I would just cancel it. Additional usually after a failed transaction the trader reminds the customer to pay, which is not possible, when the invoice doesn't exist anymore.
One approach would be to keep the invoice in session until the payment has been approved. If the payment is not approved, the invoice will die with the user's session.
Another approach would be to create a holding table for pending invoices. When payment is approved, simply move the data into the invoice table.
And the last approach, go ahead and create the invoice in the invoice table, but soft delete it if the payment fails. Just set a flag, deleted = 1 and in all your procs add "where deleted = 0".
I would generate purely random invoice numbers. Simplest strategy:
md5(uniqid())
But still – storing unfinished invoices in the database sounds more sane.
Also the random factor will make guessing the invoice number more difficult.
Related
I am developing an online inventory management system. I have one table for the main inventory which consists of the product names, quantity and barcodes etc. I want users to log into the system each morning and log the quantity of each item they take. I then want to store this information for the admin to view. I have developed the system so that a new table gets created each morning based on the users name and date. This is allows the user to input the quantity for each product, i then subtract that column from the main inventory table when the user clicks submit. I want to know if this is a bad practice, is it necessary to create a new table each morning? If not what method should i use?
I think you should maintain a single table for inventory, and then after a create a temporary table to store the list of items the user takes which will contain the user id, inventory id, qty etc, and then update the quantity of inventory in inventory table, whenever user picks the inventory.
In short you should create a single table to store the information of inventory which user takes instead of creating a new table each day.
Insert and fetch data according to date + user.
I wonder if you are creating new table everyday, you should not create new table in any case. In the rarest scenario even if your columns are dynamic then create a table with rows representing as column and use pivot to fetch the record. For your use case you just need to have a table which stores a new record and subtract the count from main table.
I am designing as a project a web store (using PHP Laravel and MySQL FYI) and I am at the part where I have to create the logic behind the production system, which goes like this:
-On my Database,
I have 1 ORDER table where I have all the information regarding the shipping, customer, etc.
I have another table called ITEM where are listed all the Items in an order (so if an order has 3 items, there will be 3 lines in the ITEM table with a Foreign Key pointing to the ORDER).
Now I'm creating the PRODUCTION DASHBOARD. Right now I'm able to scan the item ID and get the shipment information on the Dashboard.
After that, for orders with multiple items what I want to do is for the system to tell the user to deposit the item in a numbered box to wait for the rest of the items from the order. That way the user can keep scanning items from other orders and once another item from the ordered stored in X box is produced, he can scan it and the system will then tell him that the other items from the same Order and placed on X box and he can do that until the order is complete.
My question is what would be the best way and logic Database wise (and also Laravel wise if you want to further expand your answer hehe) to implement this BOX system.
I hope my question is clear enough and thank you very much :)
I had a similar system for a project that I was working on. What I did was, was create a database table called temp_orders with a column called items that each item was separated by a line break. Until the order was finalized (100% processed), the order would remain in temp_orders.
Once finalized, it would get deleted from temp_orders and moved over to the orders table. If I needed to check items, I would explode() the data from the items column in temp_orders table using a line break, thus putting them into an array and then using the data however I needed to.
You need to determine when you want to finalize the order. It could be upon credit card payment, or upon user order confirmation, for example.
I am trying to understand the database design for an e-commerce site. I am having trouble understanding on what to do in the following situation. Say the user creates an account for the first time, and makes an order. I can write php code which will add the user_id (primary-key), first name & last name. But what if I want to add the user_id in the orders table (user_id in the orders tables is a foreign key). How do I get the value, as the user_id in the customers table is auto incrementing?
Are you using two tables one for storing user details and other for placing orders ?(which is better) If so my recommendation would be to use username (not first name or last name) as primary key and store the username as SESSION variable for each login and for each order add the username in order table along with orders details
There are couple of ways to do that, you can access the newly generated user_id by LAST_INSERT_ID() and use it in subsequent transaction, or you can store it in session and use it later when inserting in Orders table.
I have a site where users can place an order. The order goes through various stages before it is ready for delivery. I want to be able to log anytime anything happens relating to an order.
Here's an example of what I would like for it to look:
(2/13/12 4:41pm): Order initiated by Customer (2/13/12 4:41pm): Order
sent to Manager for approval (2/13/12 4:43pm): Order approved by
Manager (2/14/12 6:03pm): The order was edited by the user: City: 'Los
Angeles' to 'San Diego' (2/14/12 6:09pm): The order was edited by the
admin: Email: 'gearge#gmail.com' to 'george#gmail.com' (2/15/12
8:41pm): Order ready for Delivery
What is the best approach for me to store this type of order history? I have created a table in the DB called history where I would like to store the history as it pertains to each order. My columns are history_id(primary), order_id(foreign), date added(timestamp), and history_message(varchar).
Ideally I would like to create numbered codes for each step in the ordering process, such as an order approval, order edit, or order delivery and then just assign the number for that row instead of the actual history message, which is more characters. I feel that this way I won't overstuff my DB. The problem with this approach is that I would like to keep a log of the actual data that was changed(as you can see in the edits by the user and admin in the example) and I'm not sure how I can accomplish that without saving the complete history message for each row.
What is the best way to store order history in a database for my situation?
You can use trigger to update a child table keeping track of each order status.
Basically using insert trigger or do manual insert after update in order status by insert query you can copy required data from orders table to a new table we can call trackorders. tracking table will keep track of all changes and record with current status will be in main table.
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.