Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shipping Method incorrectly assigned and blocking checkout #6768

Closed
lbwright22 opened this issue Jan 29, 2021 · 10 comments
Closed

Shipping Method incorrectly assigned and blocking checkout #6768

lbwright22 opened this issue Jan 29, 2021 · 10 comments
Labels
bug-s3 The bug is stopping a critical or non-critical feature but there is a usable workaround.

Comments

@lbwright22
Copy link

Description

Enterprise: The Tree- St Andrews (no other reports of this issue)

Customer unable to complete purchase (error message 'Items Cannot Be Shipped') if only one shipping method is 'active' for the enterprise: Delivery
tree_orderone

They have one other shipping method: Collection. If this is set to 'Active' for the enterprise but backoffice only then order goes through- customer selects 'delivery' at checkout (as it is the only option visible).
BUT:
-information displayed on order confirmation screen is that for the 'Collection Delivery method'
tree_ordertwo

-Visit Edit order after it has been placed and shipping methods is unassigned.
treeshippingorder

Problem: misleading to the customer (they are being told after ordering that they must collect their shopping when they wanted it delivered) and logistically difficult for hub (they can't do pick up at the moment due to COVID)

Shipping categories of both methods have 'frozen, refrigerated and default' boxes checked.

Expected Behavior

  1. with one active shipping method and all three shipping categories checked for this method the order should succeed at checkout.
  2. Information displayed under 'shipping' on order confirmation confirmation screen this that selected by the customer at checkout
  3. Shipping method chosen by customer at checkout is documented in order details (Orders -> edit order)

Actual Behaviour

  1. two shipping methods (one backoffice and one checkout and backoffice) (both with all three shipping categories checked) are required for an order to succeed.
  2. Information displayed under 'shipping' on order confirmation confirmation screen differs from that selected by the customer at checkout
  3. Shipping method chosen by customer at checkout is not documented in order details (Orders -> edit order)

Steps to Reproduce

Unable to reproduce for a different hub

Scenario one

  1. set 'Delivery' shipping method as 'active' (back office and checkout)
  2. make sure all three shipping categories are assigned to this shipping method
  3. Place an order
  4. Observe the order does not succeed

Scenario two

  1. set 'Delivery' shipping method as active (backoffice and checkout) and 'collection' as backoffice only#
  2. make sure all three shipping categories are assigned to this shipping method
  3. Place an order
  4. Observe the order confirmation screen does not display the correct information
  5. Edit order and observe no shipping method assigned.

Animated Gif/Screenshot

Workaround

Severity

Your Environment

  • Version used:
  • Browser name and version:
  • Operating System and version (desktop or mobile):

Possible Fix

@andrewpbrett
Copy link
Contributor

This looks similar to #5950 and may be fixed at the same time, potentially with #6039

@lin-d-hop
Copy link
Contributor

@lbwright22 Am I correct that this is not due to tagging but do to a bug in shipping categories?

Can you confirm if this error remains when only 'default' is checked rather than all three?

If not, then this would be an S1 bug blocking checkout.
If so, then this will be an S3 bug and we know to be careful on shipping categories to be sure only 'default' is checked.

@lbwright22
Copy link
Author

This is not a tagging problem

Error is the same if change the 'Delivery' shipping method to 'default'.
(ie scenario described above- checkout goes through if 'Delivery' is a checkout and backoffice shipping method if there is also another back office method (collection). Customer is informed after payment that they selected 'Collection' which is incorrect.

If 'Delivery' shipping method is set to 'default' category only, trying to remove the 'collection' option is not possible. Unselecting the 'active' box results in another random 'pick up ' collection method being assigned to the enterprise.

NOTE this bug does not block checkout per say. It does block checkout with the correct shipping method though. This is highly confusing to customers in the current climate when people are specifically NEEDING delivery and not collection.
@lin-d-hop @andrewpbrett

@lbwright22
Copy link
Author

@lin-d-hop I'm wondering if the severity of this can be looked at again.
Under the work around the customer selects 'Delivery' at checkout (which is the only checkout option), completes their shipping and billing addresses, but the shipping method becomes un-selected in their orders and reports (as well as the customer being sent an email to state they need to collect, which is wrong).
This means the enterprise has no address information for the customer on where they want their order taken to. It is a bit more severe to their business (especially in time of covid when deliveries are essential)

@lin-d-hop
Copy link
Contributor

@lbwright22 Am I understanding correctly...

IF the hub has a collection and delivery method
AND the collection method is set to backoffice only
AND the delivery method does not check all three shipping categories

THEN the shopper is randomly allocated a collection shipping method at checkout
??

If the above is true this is an extreme edge case.
Has it been reported by more than one hub?
Can we do something with their shipping methods to prevent all three of the prerequisite conditions from being true to stop this from happening?

@lbwright22
Copy link
Author

@lin-d-hop no.

This particular hub there is a problem:

  1. Delivery is the only shipping method chosen (delivery = checkout and backoffice, no collection) -> not able to checkout (same result independent of which shipping categories are selected- just default or all three).
  2. Delivery is checkout and back office, collection = backoffice -> checkout not blocked but shipping method becomes unassigned. No shipping/delivery address collected, customer sent miss-information on their order confirmation email. (same result irrespective of shipping categories selected- just default or all three).

@lin-d-hop
Copy link
Contributor

Louise sorry I still don't understand. Is the below correct?

One hub is experiencing a problem.
They have tried two different combinations of shipping methods.

First they tried having only one shipping method available - Delivery. When they did this no shoppers were able to checkout.
Second they tried having a collection shipping method in the back office only, alongside a Delivery shipping method available for front and back office. When they did this the delivery shipping method still didn't work. It was displayed at checkout but when shoppers selected it it was treated as a collection shipping method.

If that understanding is correct (and this issue is not about categories or tags) then it seems odd it is only impacting one enterprise.

Have you tried making new shipping methods for this enterprise? Perhaps something broke in the earlier stages when there were shipping category issues happening.

@lbwright22
Copy link
Author

@lin-d-hop fixed.
closing issue

@lbwright22
Copy link
Author

I am re-opening this issue as after a short time the same scenario happened for The Tree- St Andrews with the new delivery shipping method which I created.

I have created another delivery shipping method (which is the only one visible at checkout) and that correctly captures customer billing and shipping address details and shows on their customer order confirmation.

The fact that a shipping method for this enterprise seems to keep getting corrupted warrants further investigation,

@sigmundpetersen sigmundpetersen added the bug-s3 The bug is stopping a critical or non-critical feature but there is a usable workaround. label Mar 3, 2021
@lin-d-hop
Copy link
Contributor

Closing as this is now old and seemed to be an edge case

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug-s3 The bug is stopping a critical or non-critical feature but there is a usable workaround.
Projects
None yet
Development

No branches or pull requests

4 participants