Hello Giulio, I thinks it's good to remove hard coded value and move it on the productStore.
Keep the N as default if you didn't found any value. I use your focus on this subject to know if you want to help me to convert the minilang inventory service to groovy. I can realize the conversion without problem, but I like to have some production data to be ensure that I didn't introduce a regression not cover by ofbiz test. My problem, our project don't use the inventory at a correct level, so if you are available to help me on this testing task it would be great :) Nicolas On 08/07/2022 13:05, Giulio Speri - MpStyle Srl wrote: > Hello devs, > > I hope you're doing good! > I write because I think I found a possible issue in minilang service > *reassignInventoryReservation*. > > This service is called as a SECA on createPhysicalInventoryAndVariance > service and at the end it deletes inventory reservation for an order items > that has quantityNotReserved .gt. 0 and then re-reserve the inventory > calling the service *reserveProductInventoryByFacility, *implemented by the > method *reserveProductInventory* > > (applications/product/minilang/product/inventory/InventoryReserveServices.xml). > > The *reserveProductInventoryByFacility has some parameters passed in and > among them there is requireInventory parameter, that is hardcoded to N, to > allow back-orders (negative ATP).* > > In our ecommerce context this is not recommendable and the productStores > are all configured to requireInventory=Y, because we do not want > back-orders, but the hard-coded requireInventory "N", overrides the store > setting, making the order "available" even if stock is not present for an > order item. > > I think that it is better to check the productStore setting of the > requireInventory parameter, and pass that value to the > *reserveProductInventoryByFacility,* instead of a hard-coded "N". > > What do you think about it? > If you agree I could take care of it in a Jira Task and provide a patch. > > Thanks in advance, > Giulio >
