According to the specs the company has invested in a state of the art inventory system that predicts demand for components up to one month in advance so that orders can be manually placed into a reverse auctioneering application.
It gives me a bit of a headache what functionality the WS interface of the inventory system must support in order to fully leverage the investment on this "state-of-the-art system". IMHO it's not enough for the system to only validate that a request for a given part and quantity is valid and only update the inventory in use case 5.5 when the work has been scheduled. This could easily result in two-or-more DreamCar employees creating a request for the same part with the total requested quantity of the parts exceeding the demand predicted by the system within the given timeframe. For example, Employee1 sees that according to the inventory system there is a need for 1000 brake pads within the next 3 weeks, so they post a request for this (RQ1). While RQ1 is open and being bid on Employee2 checks with the inventory system and, since it has no information that a request has already been made for the predicted 1000 brake pads, it tells the user that they sill need so many of them within the specified timeframe. So Employee2 post another request (RQ2) for the same parts. Meanwhile RQ1 comes to an end, a PO is issued and the work is scheduled and the inventory system is updated and the demand for brake pads reduced by 1000. Then RQ2 comes to a close and a (effectively duplicate) purchase order is issued, work scheduled and inventory updated again.
If there is noting that would prevent such a scenario then what's the point of investing heavily in a sophisticated inventory control system? The only way to prevent that would be that when a request is posted the parts are "locked" in the inventory system for the duration of the auction and "committed" when the purchase order is awarded or "released" when the auction comes to a close without awarding any bidder.
You can assume also that validation warns if the request is duplicate and let the user to confirm or deny the action or doesn't allow at all posting the same request twice.
The existing system is very important because of the forecasting not because of the validations.
I believe that the system can be also manually consulted to see what parts are needed. What do you think?
I don't see a big problem here. Your inventory system should simply know about the orders created for auctioneering application.
It should use additional property for each part, called : "expected number of items", and make predictions based on this property, not on the real number of parts on stock.
This way, the second user will not make duplicated order.
Similar solution is also used by Banks, where you have "book balance" reflecting balance from accounting system and "available money" which includes all transactions that were executed, but not booked yet.
(For example when you pay with credit card, the transaction is booked after 1-2 days in accounting system, but the amount is immediately included in "available money") .
This way when you try to make new transaction, the "available money" is checked not "book balance". Your account is protected from withdrawing more many then you have on a account.
SCJP 5, SCWCD 1.4, SCBCD 5, SCEA part1
Joined: May 06, 2009
Thanks. I think I' just going take a lil bit from all of you. I should be able to figure something out.
subject: DreamCar: interface with the inventory system dilemma