Hi Ido,
First an observation - the picker will occasionally go to the picking
face and find that the stock the computer has just allocated to an order
is damaged or has been stolen. For these reasons, even if the computer
is 100% accurate, you will still have a low level of phone calls to the
customer, asking if the customer wants to back-order or accept a refund.
(Most people blame the computer for these errors because it does not
complain.)
Another factor to consider. HTTP is stateless, so if a customer's
machine locks up, reboots or loses power while they are shopping, there
is nothing to tell the server that the shopping cart has been abandoned.
You need to decide if stock in a cart is sold unless abandoned or timed
out, or not sold until checked out.
Conclusion - perfection is impossible. You only need a solution that is
good enough so that it does not significantly add to costs or damage
reputation.
I think you will have more success with stock represented as one record
per stock item, not per stock keeping code. (If you have 20 in stock
create 20 records). Then when you sell them, you will either succeed in
updating the record, or fail, and you can take another and try with
that. Chose randomly, so that you avoid most conflicts.
Replication will still bite you. I have seen many approaches tried.
a) Allocate in a central replica, and use local replicas as read-only
caches.
b) Allocate locally and sort out over-commitments when they happen
c) Pre-allocate a small amount of stock to the local replica, and
replenish this stock very quickly when it is sold.
Generally a) works best but communications costs may make it prohibitive.
Method b) will work acceptably if stock levels are such that stock-out
conditions are rare.
The two problems with c) are that it raises the minimum stock level of
slow items unacceptably, and means there is a short period after each
sale when there appears to be no stock, which results in lost sales.
If live or near live stock levels can be provides, this will help
methods a) and b). If the customer knows stock levels are low, they will
be less disappointed if there is no stock at checkout time.
Regards
Ian
On 22/10/2010 10:40, Ido Ran wrote:
Hi,
I know tx question have been asked, but I never got a straight answer. I
will present an example but I'm afraid that example distract us from the
main issue which is "what is the new way of changing data?"
Suppose I have CouchDB in which each document represent item in my
warehouse. Each item has catalog number and quantity.
I have agents who sale my items all over town, each agent has smart phone
and internet access so they can use my great CouchApp :)
One thing is very important - I don't want agent to sale item I don't have
in stock and have all the items a client order.
So one thing is for sure: We can't simply subtract the quantity client order
from the item document because I might dead-lock myself.
Client 1 order item Ax5, Bx3
Client 2 order item Bx3, Ax10
Suppose I have in stock Ax6, Bx3
If I handle the two client order at the same time, first Client1 item A then
Client 2 item B then Client 1 item B then Client 2 item A
I will get to the last update of item A and find I don't have enough in
stock, but there is no good way of rolling it back, let's say the buttery of
the smartphone is dead I now took only half of the order.
I can create a new document which will represent the order itself. It will
have all the client detail as well as each item and quantity. Further I can
create a validation function to allow only order which have all items in
stock. Does it the way to go?
Let's say I took the solution of order document, how do I actually process
the orders and update the quantity of each item?
I hope I made myself clear, I'm not looking to solve this specific problem
but understand how to use CouchDB as non-transactional database.
Thank you,
Ido
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1144 / Virus Database: 422/3211 - Release Date: 10/21/10
