I am new to MSSQL and creating a website where Customers can place orders.
Each order may have multiple items with any number of quantity.
I am interested in before saving my order to check if the desired quantity is available for each item, if yes then I will place the order and update the items inventory, otherwise I want to rollback.
But at the same time I want that any other order should wait till first transaction is finished. So that up updates don't overwrite the changes and produce inconsistency.
If each order is processed within a transaction, is it enough or do I have to consider something else too?
If you go on any Online retail website, you will notice that you go through the shop, buying stuff (not actually buying but being added to a basket) and once you have completed your shopping you go to Checkout that is, where you are asked to provide payment details etc.
So the idea is, the website shows everything (that has at least 1 stock item) to every customer, At this point no item inventory is being updated or inserted, at the checkout stage a complete order is compiled and submitted to system, (at this stage you will do the actual updates/inserts to item stock inventory) now how you want to handle the orders is entirely up to you.
Do you want to rollback entire order when any one item has less stock than
the quantity ordered?
Do you want to commit all order lines and only rollback those order lines where the items has less stock than quantity ordered?
Or do you want to place a provisional
order regardless of the stock availability and manipulate the delivery date?
Depending on what path you chose to go with (this should be a business decision a developer shouldn't be making these decisions) there is a lot of flexibility, but one thing you never do is as soon as someone has select to buy an item, you update the inventory. All this should be done right in the end of the Purchase process and all should be done at Once.
Related
I am very new to E-Commerce World.
I have a use case scenario that I want to Implement in Oracle NetSuite.
But I am not sure how to move forward with it.
Use-Case Scenario:
A Sales Order has a few Line Items & Among them, a few are out of stock.
The 3PL currently I am dealing with accepts only one Unique Sales Order ID as an Identifier.
I want to fulfill the items that are currently in stock and Later on, when the Inventory gets updated I want to fulfill the remaining Items back-ordered in the Sales Order.
But the fulfillment should happen only after the customer has paid for the Items.
Can anyone let me know? How can I achieve this?
Thank you.
You will probably need some customisation to achieve this. I don't know the full set of processes you're working with, but as a general approach, I would suggest the following:
Set up a payment term that says the customer must prepay.
Set up a script to run on your fulfilments, handle "prepay" customers.
You'll also want to check your settings in Setup > Accounting > Accounting Preferences > Order Management. Look for the option on sales orders and fulfilment. You'll probably want to default your fulfilment to available quantity only. You may want to prevent overage on your fulfilments.
When the script executes on your fulfilment, it should execute "before load". The script will need to check the sales order it's fulfilling. If the term is "prepay", the script should then check if a payment has been made against the sales order. You'll potentially need to consider deposits and paid invoices. If the script finds no payments, then it should block the fulfilment.
I'm working on the assumption that you will create a fulfilment with a "Picked" status to send to your warehouse. When they confirm the "goods-out", you will want some sort of feedback loop from your 3PL to set the fulfilment to "Shipped" and update your tracking numbers.
I hope this helps.
Mark
My primary business is pre-orders, and this is how it works:
I list an item for sale.
My customers order the item. Their credit card is authorized but not charged.
Once a minimum number of orders are placed, the customers are charged, and the buy is live.
If, after a specified amount of time, the minimum is not reached, all orders are cancelled.
What i would like to do is this:
Specify the minimum number of orders needed for a particular item in the backend. (not 100% needed, but it would be nice).
Display the total number of pre-orders on the product page, so that my customers know how many are left before the buy is live (it would be great to show it in the following format: 23/50 Ordered).
Does anyone know if this is possible? If so, can you please explain to me what I need to do in order to make this happen?
Thanks!
P.S. - In case it doesn't show up, I'm using Bigcommerce
Store the minimum needed as a custom field & set the initial inventory to that same number. You'll also need to allow inventory to be displayed for pre-orders, though you can hide it from display if you'd like (we only want it present in the DOM).
As the products are pre-ordered, inventory will decrement. Use javascript to subtract the number left in inventory from the original number (the custom field) and display in the ProductDetails.html panel.
I am trying to process the orders from certain Amazon store. But was faced with a problem:
I can not get total price (or total amount) for orders with 'Pending' status. This field is empty. This info can not be retrieved even via OrderItems.
Amazon API docs says:
Note: When an order is in the Pending state (the order has been placed but payment has not been authorized), the ListOrderItems operation does not return information about pricing, taxes, shipping charges, gift wrapping, or promotions for the order items in the order. After an order leaves the Pending state (this occurs when payment has been authorized) and enters the Unshipped, Partially Shipped, or Shipped state, the ListOrderItems operation returns information about pricing, taxes, shipping charges, gift wrapping, and promotions for the order items in the order.
But I really need it. In addition I saw some apps, which can 'see' OrderAmount for pending orders.
Maybe anyone have already resolved this question? Any help is highly appreciated.
Thanks.
I use the SellerSKU along with a Amazon price stored in my database to calculate the order value. It is an estimate, though, since the price may have been updated recently (and the order might not reflect the new price) and I cannot calculate the shipping price - neither the price nor the address is known for pending orders.
At least in my usage, I don't see a reason for trying to get the exact amount before the order actually leaves the Pending state. Quantities and SKUs are known, so you can reserve stock accordingly which is the only task I actually need to know pending orders for.
Hi everyone I'm working on a school project, and for my project I chose to create an ecommerce system that can process recurring orders. This is for my final project, I'll be graduating in May with an associates in computer science.
Keep in mind this is no where a final solution and it's basically a jumping off point for this database design.
A little background on the business processes.
- Customer will order a product, and will specify during checkout whether it is a one time order or a weekly/monthly order.
- Customer will specify a location in which to pick up their order (this location is specific only to the order)
- If the value of the order > 25.00 then it is accepted otherwise it is rejected.
- This will populate the orders_test and order_products_test tables respectively
Person on the back end will have a report generated for deliveries for the day based on these two tables.
They will be able to print it off and it will generate a list of what items go to what location.
Based on the following criteria.
date_of_next_scheduled_delivery = current date
remaining_deliveries > 0
Once they are satisfied with the delivery list they will press "Process Deliveries" button.
This will adjust the order_products_test table as follows
Subtract 1 from remaining_deliveries
Insert current date into date_of_last_delivery_processed
Based on delivery_frequency (i.e. once, weekly, monthly) it will change the date_of_next_scheduled_delivery
status values in the order_products_test table can either be active, hold, or canceled, expired
I just would like some opinions if I am approaching this correctly or if I should scratch this approach and start over again.
A few thoughts, though not necessarily complete (there's a lot to your question, but hopefully these points help):
I don't think you need to keep track of remaining deliveries. You only have 2 options - a one time order, or a recurring order. In both cases, there's no sense in calculating remaining deliveries. It's never leveraged.
In terms of tracking the next delivery date, you can just keep track of the day of the order. If it's recurring -- monthly or weekly, regardless -- everything is calculable from that first date. Most DB systems (MySQL, SQL Server, Oracle, etc) support more than enough date computation flexibility so that you can calculate this on the fly, as opposed to maintaining such a known schedule.
If the delivery location is only specific to the order, I see no use in creating a separate table for it -- it's functionally dependent on the order, you should keep it in the same table as the order. For most e-commerce systems, this is not the case because they tend to associate a list of delivery locations with accounts, which they prompt you about when you order more than once (e.g., Amazon).
Given the above, I bet you can just get away with 2 of your 4 tables above -- Account and Order. But again, if delivery locations are associated with Accounts, I would indeed break that out. (but your question above doesn't suggest that)
Do not name your tables with a "_test" suffix -- it's confusing.
What are the best (or perhaps most commonly used) approaches for coordinating actual stock quantities with that shown or offered for sale with a shopping cart?
Thanks in advance,
Matt
Well, you have several problems.
At a basic level, its "easy". Simply use classic transactional processing techniques to maintain the stock numbers and the order entry lines against the stock. If you have 10 available, and someone orders 1, then commit the line item with a qty of 1 at the same time you increment the "committed" qty on the inventory item. When you ship the item, remove one from In Stock, and one from Committed. In Stock - Committed = Available.
So:
In Stock Committed Available
Before: 10 0 10
Ordered: 10 1 9
Shipped: 9 0 9
The down side is that involves a bunch of locking, which can affect concurrency. Depending on your traffic this may or may not be an issue. Then you're work with on the fly counting of ordered items against stock, and you end up with race conditions. But it's really just a fact of life in business.
But, either way, regardless of how you commit the entry in to your database, it doesn't mean that the item will actually ship.
The In Stock number could simply be wrong. It could have been miskeyed, stock may be damaged, "employee shrinkage", etc. All sorts of things can go wrong. So, any commitment you make to a customer that you'll actually SHIP what you've promised has to have that little * next to it as a disclaimer.
Then you get in to the whole back ordering, cancellation and fulfillment issues.