I'm working on a multi-terminal POS system. Inventory levels and availability is quite straightforward when dealing with physical goods, but how would we handle this when dealing with virtual inventory? I mean, what if the stock level for item X is 1, and two, or more, operators are trying to place an order for it? Or, even if the balance available quantity is more than just 1, should the quantity be deducted or locked from the inventory file when an operator is processing an order for it, and then reinstated if the order is cancelled?
Thanks in advance.
Related
I've got a few products where I need the quantities for a specific product to start at a number, 240 for example and then the customer can select in intervals of 240, and for a different product, say 100 units. I need a way to separate a list of quantities for separate products.
You can examine the documentation related to InventoryItem endpoints which leads to InventoryLevel endpoints. Once you get a handle on Locations, you are free to set inventory levels. Note that setting explicit amounts is no longer the fashion, instead you ask how much is there, and then modify that amount with a delta change.
So if you ask for a product's variant level, and it tells you the current availability is 0, your delta might be +240.
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.
I am designing a database for an app to sell parking spot use. Customer can order n number of uses of parking spot uses or pay a flat rate and use it for monthly/weekly or yearly. They can do mix of those also. Like they can buy 9 parking spot uses and later decide they will pay for the whole month - in which case their charges are kind of pro-rated.
For this, I have a Customer table, an Order Table and then an order type table. However, I am having a slightly hard time with the order-type table.
Can some one please shed light on how to model the rate and get available spot-uses for a customer?
I'm new to optaplanner and im trying to tweak the VRP example to solve a "similar" problem... but with some differences:
We have a central depot, n customers and a fleet of one or more vehicles.
Each customer has a certain "maximum capacity" (not the same for all of them).
Same for each vehicle.
Initial conditions from the problem include:
"actual capacity" and "desired capacity" for each customer, so that:
actual capacity is >=0 and <=max capacity
desired capacity is >=0 and <=max capacity
"actual depot capacity" is the amount of items available at the depot
We want to REDISTRIBUTE some items so that each customer gets his "desired capacity".
(Tipically most items will be redistributed from one customer to another)
Hard constraints are "maximum capacity"s cannot be excedeed
Soft constraints are vehicle distance (minimize) and difference from "desired capacity" (minimize)
I started by generating a data file for the VRP example with negative customer demand (to simulate desired capacity < actual capacity) but quickly discover that constraint in drl that sums up all customers demands to satisfy vehicle capacity restriction is not what we need here.
¿Do you think that this problem is "similar enough" to worth modifying VRP example?
Yes, it's definitely worth taking the OptaPlanner VRP example (with or without the example GUI) and customizing it to these needs. Start from OptaPlanner 6.0.0.CR1 or better yet CR4 which will be released next week normally. Don't use CR3 because it might have a bug related to shadow variables in VRP.
A) Let's presume customerDemand = customerDesired - customerActual. This can be positive (need more items) and negative (need to get rid of items).
Question: How do we validate the Vehicle capacity? We can't just sum it, because it fluctuates from customer to customer. Answer: We use a shadow variable (let's call it freight) on Customer to calculate how many items the vehicle is transporting from the previous customer to the current. This is very similar to how arrivalTime works for the TimewindowedCustomer example. Then use a score constraint rule to verify freight on every customer is lower than the vehicle's maximum capacity. And also that freight is >= 0 at every customer.
Now, A) works well if there are plenty of vehicles. Even if there aren't enough items, checking the soft constraint is pointless because it's a fixed constant number (the number of items lacking). You could even decide to spread that shortage fairly over the customers and adjust their customerDesired accordingly, before scheduling.
B) However, if there aren't plenty of vehicles, relative to the number of customers, then A) might be insufficient. We 'll want to allow to deliver/pickup less than customerDemand, making it more flexible (and therefore complex :). In this case, a Customer has 2 genuine (=non-shadow) planning variables (instead of just 1): the previousStandstill (~ previous customer) and the deliveryPickup (<= demand * 2).
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.