Skip to content

Billing address parameter 'same_as_shipping' cause error 'The shipping method is missing' #30924

Closed
@OleksiyOleksiyovych

Description

@OleksiyOleksiyovych

Issue

Error after place order: The shipping method is missing. Select the shipping method and try again

Steps to reproduce

  1. Logged in customer
  2. Run mutations setShippingAddressesOnCart and setShippingMethodsOnCart
  3. Check database table quote_address - shipping method is selected for quote address
  4. Run mutation setBillingAddressOnCart with same*as*shipping = true
  5. Check shipping method - shipping method is not selected now

Reason for issue

I think we have an issue in logic after these changes
Replace usefor_shipping with same_asshipping

It can not be a simple rename - use*for_shipping to same_as*shipping as we have in this commit bb25f9a
because these options have a different logic:

  • use*for*shipping - set shipping address based on billing address
  • same*as*shipping - set billing address based on shipping address

Class Magento\QuoteGraphQl\Model\Cart\SetBillingAddressOnCart
$this->assignBillingAddressToCart->execute($cart, $billingAddress, $sameAsShipping);

finally, it calls a function assign($cartId, \Magento\Quote\Api\Data\AddressInterface $address, $useForShipping = false) in class Magento\Quote\Model\BillingAddressManagement which waiting for use*for_shipping parameter instead of same_as*shipping

The implementation needs to be updated to reflect this change in logic for the GraphQL call. The logic should now ignore the passed address if same_as_shipping is true and use the shipping address instead. ** 

Possible fixes

I can see 2 variants of how we can resolve it:

Variant 1
We can remove same*as_shipping from GraphQl schema as it does not make sense for backend logic - we do not have a field in database table quote*address for this option.
We have the field same*as_billing in quote*address table (we use it when we place an order from the admin panel and fill the billing address first).
So, the checkbox on checkout 'My billing and shipping address are the same' will be used only for frontend logic in javascript (as on standard checkout on Luma theme) and do not use in mutation.
use*for*shipping can be removerd from GraphQl schema too.

Variant 2
Add logic for same*as_shipping on the backend side. In this case, we should do billing_address in setBillingAddressOnCart mutation as not required when we set same_as_shipping=true as it does not make sense. We will check same_as*shipping in resolver and if it's "true" - load shipping address from the quote and save to billing address.

As for me, variant 1 is a more correct way.

Acceptance Criteria

  • The implementation for the setBillingAddressToCart mutation is updated to correctly use the same*as*shipping input correctly: to set the billing address to match the shipping address, not vice versa.
  • All existing non-GraphQL flows (admin order checkout, REST calls, etc) are not impacted
  • The new implementation does not have the reported bug of a missing shipping method after execution (this should be eliminated as a consequence of refactoring the implementation)

Test Plan

  • Use input billing address
    Input: valid billing address, same*as*shipping = false
    Expected Result: billing address is set to input address

  • Use shipping address
    Input: empty billing address, same*as*shipping = true
    Expected Result: billing address matches shipping address

  • Use shipping address, ignore input billing address
    Input: valid billing address, same*as*shipping = true
    Expected Result: billing address matches shipping address

  • No provided address
    Input: empty billing address, same*as*shipping = false
    Expected Result: GraphQlInputException

  • No existing shipping address
    Input: any billing address, same*as*shipping = true and no existing shipping address
    Expected Result: GraphQlInputException

Metadata

Metadata

Labels

Priority: P3May be fixed according to the position in the backlog.Progress: doneProject: GraphQLSeverity: S3Affects non-critical data or functionality and does not force users to employ a workaround.

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions