We have an order entry screen that allows the Sales Rep to select a specific serial number for a serialized piece of inventory. The reservation process must honor this selection and reserve that piece (if possible) or produce a reasonable error message.
Question lead in -- if the inventory item is known up-front, most of the hub-bub around figuring out proper facilities and then applying LIFO/FIFO/etc and going through primary/pick locations is not required. It appears while this is being done, "reserveForInventoryItemInline" is called (in a loop) which updates the InventoryItem OR creates an InventoryItemDetail and calls "reserveOrderItemInventory" which creates a OrderItemShipGrpInvRes entity. Question -- as part as reserving inventory is this it? (Ignoring ECAs for quantity thresholds and such). If this is the case, my solution is going to be (as part of order create/update) avoid calling the whole reserveInventory chain, and call a new new service that simply calls reserveForInventoryItemInline (with appropriate parms). This would be in situations where the ShoppingCartItem has the inventoryItemId specified. Anyone see any flaws in this approach? Also, has anyone else had this type of thing to do before? I took a brief look at the POS implementation and this type of logic does not seem to be in place yet. It would seem to me that it would be important for the POS that they sell the actual product the customer brings to the counter. Serialized by serialNumber and Non-Serialized by location (either directly or indirectly). -- View this message in context: http://www.nabble.com/Reserving-a-specific-serialized-inventory-item-tp25208526p25208526.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
