[ 
https://issues.apache.org/jira/browse/OFBIZ-12264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17458606#comment-17458606
 ] 

Giulio Speri commented on OFBIZ-12264:
--------------------------------------

Hi,

 

after reviewing the code again to check the status of this patch, I found 
another issue related to this and it involves the service 
{_}reserveProductInventoryByFacility{_}, called in the _reserveStoreInventory_ 
method for the actual reservation of the product.

The problem in _reserveProductInventoryByFacility_  is that is not considered 
the case where requireInventory = Y (and reserveInventory = Y), so for such a 
scenario that service will not fail returning an error, but simply returns the 
value of quantityNotReserved letting an order to be placed also if we do not 
have inventory available.

 

For this reason I decided to move the error raised in my previous version of 
the patch, into the _reserveProductInventoryByFacility :_ I will create a new 
issue where I share more detail on it.

 

In the meanwhile I add the new version of the patch (I call this fix-part1)

Thanks,

Giulio[^OFBIZ-12264_13122021_trunk.patch]

> Multiple Facility Inventory reservation does not consider store facility thru 
> date
> ----------------------------------------------------------------------------------
>
>                 Key: OFBIZ-12264
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-12264
>             Project: OFBiz
>          Issue Type: Bug
>          Components: ecommerce, product
>    Affects Versions: Release Branch 18.12, 17.12.03, Trunk, 17.12.04, 
> 17.12.05, 17.12.06, 17.12.07
>         Environment: Linux/Ubuntu 18.04 LTS, Java jdk 8, OFBiz v13.07.03
>  
>            Reporter: Giulio Speri
>            Assignee: Giulio Speri
>            Priority: Major
>         Attachments: OFBIZ-12264_13122021_trunk.patch, 
> OFBIZ-12264_v130703.patch, OFBIZ-12264_v17.patch, Screenshot from 2021-11-12 
> 01-58-45.png, image-2021-06-24-00-35-10-392.png, 
> image-2021-06-24-00-37-21-890.png, image-2021-06-24-00-40-41-737.png, 
> image-2021-06-24-00-41-56-344.png, image-2021-06-24-00-43-33-640.png, 
> image-2021-06-24-00-46-17-924.png, image-2021-06-24-00-49-23-904.png
>
>
> The ProductStore is set up to reserve inventory from more than one facility, 
> so the flag oneInventoryFacility is set to N. 
>  The we have 8 different facilities configured (each with a specific sequence 
> num from 1 to 8) in the entity ProductStoreFacility.
>   
>  Due to customer requests I had to disable 6 out of 8 facilities associated 
> with the store, so basically only facilities with (sequence) numbers 1 and 2 
> are left. To achieve this I set the thruDate on the other six records.
>   
>  After that, an order came in with a variant product that had only 1 quantity 
> left available in one of the disabled facilities and 0 in both the two 
> facilities left enabled, but despite this the system reserved inventory from 
> the disabled facility: I wouldn't expect that.
>   
>  The service responsible for the reservation is reserveStoreInventory that in 
> our ofbiz version (13.07.03) is minilang and is implemented in 
> ProductStoreServices.xml: I checked that service and I noticed that when the 
> ProductStore is set to multi facility (oneInventoryFacility to N) and the 
> list of productStoreFacility records are retrieved, they are not filtered by 
> date, and this lead to a "bad" reservation.
>  I took a look also at the current revision of ofbiz and the code (groovy 
> script) is basically the same, so the issue is present there also.
>  
> ADDITIONAL NOTE:
> The the reservation should not be done for this product, but this part is 
> only the last step of the ecommerce sales order flow.
> I think that with a scenario like the one above, the specific product variant 
> should not even be added to the cart, so in the item page (productdetail) 
> this particular variant should not have been visible/selected by the user.
> But I have to take a better look at this part.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Reply via email to