[Woo POS] Always create a new order when checking out

[staskus]

Closes: #15426
Discussion: woocommerce/woocommerce-android#12385

Description

Always create a new order when checking out. This matches the Android solution. Updating the order requires additional diffing logic on the mobile side and sometimes it introduces issues when remote and local orders become out-of-sync.

auto-draft orders are removed by WordPress once 7 days..

We could consider creating checkout-draft orders, that are removed once a day by a cron job.

Steps to reproduce

The original issue I was addressing

Prerequisites: Enable enableCouponsInPointOfSale feature flag in DefaultFeatureFlagService

1. Add 2 products
2. Check out so the order would be created
3. Come back
4. Remove one of the producs
5. Add one invalid coupon
6. Check out
7. Get error
8. Come back
9. Remove an invalid coupon (the Cart should contain only one product now)
10. Check out again
11. Confirm order is created successfully

Regression

The changes affect the checkout flow, which could be triggered in two ways:

1. Tapping Check Out
2. Tapping 'Try Again' if order creation fails

Test with various types of products:

1. Select products -> Check out -> Come back -> Make Changes -> Card Payment
2. Select products -> Check out -> Order creation failure (e.g. no network connection) -> Address Issue (Enable network) -> Try Again -> Card Payment
3. Select products -> Check out -> Come back -> Checkout -> Order is not loading since it remains unchanged

Testing information

I tested various scenarios with different types of products, variations, and coupons. Also, cash payment and emails.

The order creation logic is not changed, I use the same method for adding order items to the order. Order editing works as order creation now.

Screenshots

---

• I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

Reviewer (or Author, in the case of optional code reviews):

Please make sure these conditions are met before approving the PR, or request changes if the PR needs improvement:

• The PR is small and has a clear, single focus, or a valid explanation is provided in the description. If needed, please request to split it into smaller PRs.
• Ensure Adequate Unit Test Coverage: The changes are reasonably covered by unit tests or an explanation is provided in the PR description.
• Manual Testing: The author listed all the tests they ran, including smoke tests when needed (e.g., for refactorings). The reviewer confirmed that the PR works as expected on all devices (phone/tablet) and no regressions are added.

[wpmobilebot]

📲 You can test the changes from this Pull Request in WooCommerce iOS Prototype by scanning the QR code below to install the corresponding build.

	App Name	WooCommerce iOS Prototype
	Build Number	29038
	Version	PR #15427
	Bundle ID	com.automattic.alpha.woocommerce
	Commit	003e42e
	Installation URL	2ec46a9gecvmo

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

[joshheald]

The repro steps don't always work. When I come back at step 11, it sometimes still shows the invalid coupons error. Is that expected at this point, and unrelated to the PR?

I'm guessing that removing the coupon isn't noticed as a change to the cart, so the order isn't recalculated... but it has worked sometimes. Adding a coupon to the cart is reliably noticed as a change, but not removing it.

coupon-error-remains.mp4

Edit: I guess that the coupon.matches(order) check would return true after the coupon is removed – the API removes the coupon from the order itself, right?

[joshheald]

Thanks for this – It's a nice simplification of the logic. Other than the issue mentioned about not reliably recognising invalid coupon removal, I found it worked well in my testing...

[joshheald]

Do we need to call sanitizingLocalItems on these, or is that only relevant for updates?

[staskus]

😨 I missed it.

Great observation. We do need it. As the comment in the sanitizingLocalItems says, not applying it breaks the calculations if prices_include_tax is true.

[joshheald]

Ah, glad I spotted it then! I wasn't sure because it could have been something only required on update... though, our products are all added as an update, aren't they? Rather than in the initial POST request?

[staskus]

though, our products are all added as an update, aren't they? Rather than in the initial POST request?

No. We add them as initial request when creating an order. createGroupedOrderSyncProductInputs turns products into order items. sanitize makes sure totals and subtotals are cleared and don't influence backend calculations.

[joshheald]

Ah, makes sense! Yeah, I'm all for just sending up an ID and a quantity as our input. Factors in to the line/cart-level discount/taxes discussion as well.

Ideally, if we ever allow merchants to add line-level discounts like they can in IPP, we could make a change in the API that lets us specify a discount directly, and whether that's before or after tax.

[staskus]

The repro steps don't always work. When I come back at step 11, it sometimes still shows the invalid coupons error. Is that expected at this point, and unrelated to the PR?

I'm guessing that removing the coupon isn't noticed as a change to the cart, so the order isn't recalculated... but it has worked sometimes. Adding a coupon to the cart is reliably noticed as a change, but not removing it.

Good catch. Why it happens:

1. Create and persist order (Add Product -> Check out -> Sync -> Come Back).
2. Add invalid coupon, API returns error, order doesn't change (Add Invalid Coupon -> Check out -> Sync -> Error -> Come Back).
3. Remove invalid coupon, cart state is equal to order state, sync is not initialized (Remove Coupon -> Check out -> Error).

The way to get around this cleanly is to always sync the next time after an error is returned from the API.