gferguson78

Just to advise that this issue has still not been rectified as of version 8.1.4.

There was an update to the changelog saying ‘Fixed: Stock status issue’ but backorder statuses are still being set incorrectly for bundle products.

This new bit of code (since 8.1.2) at line 283 in the includes/class-product.php file seems to be stopping the bundle backorder status being set correctly:

if ( WPCleverWoosb_Helper()->is_in_stock( $_product ) && WPCleverWoosb_Helper()->has_enough_stock( $_product, $_qty ) ) {
continue;
}

From what I can see the WooCommerce ‘is_in_stock’ function only checks to see if the product is purchasable and the ‘has_enough_stock’ function only checks to ensure that there is enough stock for the products that are currently in the customers shopping cart. In our case these will always both be returned as ‘yes’ (since the products are purchasable and there would be no bundle items currently in the shopping cart) then the function would never move past this onto the next lines which set the backorder status.

When I’ve tested it removing this line of code then the backorder status is once again set correctly, otherwise all backorders are automatically being set to ‘yes’ rather than ‘notify’.

Ok, thanks for the explanation. I’m not sure why forcing all backorder bundle products to be set to ‘allow’ rather than ‘notify’ would make any difference as to whether they are purchasable though as all products which are on backorder are always purchaseable. The backorder status is purely related to how the product is displayed to the customer on the front end.

The previous V8.1.1 is working correctly for us at the moment anyway so I’ll stick with that and will do some testing when a new update is released.

Thanks!

Thanks for your reply. I appreciate that all items are purchasable, however we use the different types of backorder to differentiate the availability message that is displayed to the user on the product page.

If backorders are set to ‘allow’ then we show the item as being available immediately.
If backorders are set to ‘notify’ then we show them as being available within a certain timeframe (usuallly 10-14 days)

The previous version of the plugin (8.1.1) returned the correct backorder status for woosb products when using the $_product->get_backorders(); command (generally this was always ‘notify’). Now in 8.1.2 – whenever a woosb product is queried for it’s backorder status it is returning it as ‘allow’ rather than ‘notify’ regardless of the backorder status of the items that make up the bundle product. This is an issue for us and I believe it to be a bug.

I can setup a simple bundle product with just 2 items in the bundle, both not having any stock but with backorders being set to ‘allow but notify’. When I save the bundle product then the backorder status is being saved as ‘allow’ rather than ‘notify’. It is impossible to override this, it is always saved as allow. I can provide temporary login details to our dev site if you wish to see this issue.

I notice some additional code has been added to the include/class-product.php file in V8.1.2 and I can only assume that this may be causing the issue.

In the meantime I will stick with version 8.1.1 until this issue is acknowledged and fixed.

I was having the same issue and it seems that disabling this code snippet resolved the error :

add_filter( 'woocommerce.feature-flags.woocommerce_paypal_payments.paylater_configurator_enabled', '__return_false' );

I don’t know if that’s the only issue but I’d wait on an official fix before updating on a live site.

Quick update – I’m having to use this code snippet as the Pay Later messaging system for this plugin doesn’t work correctly:

add_filter( 'woocommerce.feature-flags.woocommerce_paypal_payments.paylater_configurator_enabled', '__return_false' );

It seems that when I disable this snippet it resolves the issue. Have only tested on my staging site for now – I’ll wait until you provide a fix for this before updating on live site.

The issue resolves itself when I disable the PayPal plugin or revert back to the previous version. Surely if there is a conflict then that is being caused by the PayPal plugin and not another plugin?

This sounds like the same issue we’re having. There are other folk reporting it as well – hopefully this can be fixed asap.

I’ve reverted back to V2.40 and this has fixed the issue for now. I’ve been unable to check the fix on our testing site as it’s not linked with Shipstation – that’s only linked to our live site. If I get a chance I’ll upload the fix to the live site and test it later today with a single parcel.

Gordon

Thanks for your help. I have now tried adding the recommended snippet:

add_filter(‘woocommerce_paypal_payments_shipment_tracking_enabled’, ‘__return_false’);

The problem persists though, this doesn’t fix the issue. I’ve tried updating orders and still get the same fatal error every time. I now have a whole load of orders with about 20 tracking links showing on them (it seems shipstation keeps on trying to update WooCommerce until it gets a successful response – the tracking link is stored and then the fatal error with PayPal occurs) and they’ve also all been moved back to processing status.

Please can you publish the fix for this here so we can get this resolved before it does any more damage to our site?

Many thanks,
Gordon

I am currently on the 2.4.1 release. I haven’t seen a 2.4.2 release yet.

How can I disable the tracking feature within the PayPal plugin? I can’t seem to find a setting for this.

If this isn’t possible is it safe for me to revert back to V2.4.0?

Thanks,
Gordon

I am signed up for Slack now if you wish to discuss this there. I have also setup a whole new empty WooCommerce store install with just the Stock Locations plugin setup and am having the same issues as described above with V1.7.1. I’m happy to show you the issues I’m having through Slack or whatever channel suits you best. I have also done some screengrab videos showing the allocation issues.

Thanks,
Gordon

Since this has been added in V1.7.0 I am now unable to save location data without entering details for location and opening times. The fields are marked as being optional on the page but they seem to have been setup as required fields.

• This reply was modified 2 years, 10 months ago by gferguson78.

I’m not on slack but am happy to help. The 2 issues I currently have are:

1. Stock is not being allocated when the item quantity purchased is greater than the quantity available at one single location.

For instance – if I have 2 available at location one and 1 available at location two (3 in total) and then I purchase 3 of these at checkout stock does not get deducted on the order. The total stock level for the product remains the same and the stock levels need to be deducted manually on the order edit page to reduce stock.

The expected behaviour is that stock should be allocated and deducted across both locations by location priority.

2. Stock levels for items which are on backorder are not being deducted from the backorder location or the total quantity available. There is also no option to manually allocate stock to a location on the order edit page.

The expected behaviour is that the stock should be deducted at the selected backorder location. It should show as a minus stock level at that location and the total quantity available should also go to a minus stock level.

The stock priority allocation issue now seems to have been fixed in V1.7.0 with the changes that @firepages provided above but both of the issues I’ve described are still present in V1.7.0. I’m happy to provide a video of the issues or show you them on Zoom or whatever suits you best.

Many thanks,
Gordon

Backorders definitely do not get automatically allocated to despite having a single location set as the backorder location. It seems this may be a bug.

I remember in previous versions (prior to V1.5.3) that the backorder stock would be correctly allocated and deducted from the backorder location but the main stock quantity would not be deducted to a negative value. Since the recent updates though backorders now don’t seem to work at all.

Regards,
Gordon

Thanks! I’ll give this a try.

I’ve done some more testing and I’ve noticed the following results:

When I place an order for items where each individual can be sent from a single branch then the order allocation seems to work correctly.

When I place an order for items where the quantities of each individual item is more than is available at a single branch (but the total can be made up acroess all branches) then order allocation doesn’t work.

When I place an order for an item that isn’t in stock but is available on backorder then the stock level isn’t reduced to -1, despite having a single branch set as the default for backorder.

I’ll make the changes that you’ve made to the code and test again.

Thanks!
Gordon