Ensure order state handles with partial shipment

[digitalrisedorset]

The order flow will set the order to complete only once the order items are dealt with shipment, refund, cancellation. Yet, some edge case with virtual items and with partial shipment, partial refund, partial cancellation can make this flow faulty.

Description (*)

The change in this PR makes the qty to ship calculation to remove the qty refunded, qty cancelled and qty shipped already

Related Pull Requests

Fixed Issues (if relevant)

1. Fixes Order is not complete when mixing virtual, refunded and shipped items #38547

Manual testing scenarios (*)

Test 1: place an order with only physical items
validate the order gets complete when the invoice and shipment are processed and all the items are shipped
Test 2: place an order with only physical items and partial refund
validate the order gets complete when the invoice, refund and shipment are processed and all the items are shipped or refund or cancelled
Test 3: place an order with a mix of configurable, physical items and virtual items
validate the order gets complete when the invoice, refund and shipment are processed and all the items are shipped or refund or cancelled

Questions or comments

This change is not backward compliant. However, like @digitalpianism mentions, the current behaviour is not consistent when the order has only physical items. The latest change in the model \Magento\Sales\Model\ResourceModel\Order\Handler\State is what makes the experience consistent as per the requirements of the issue we are dealing with.

Currently, it is possible to refund an item that has not been shipped or just as well refund an item that has already been shipped without being able to trace either scenarios. Yet, the logic in the method \Magento\Sales\Model\ResourceModel\Order\Handler\State::isPartiallyRefundedOrderShipped assumes the refund and the shipping are separate information that can be cumulated

I have added some changes in the method \Magento\Sales\Model\Order\Item::getSimpleQtyToShip. These turn out to do the same as before. However, I would like to encourage to keep these changes (I am not precious but think they improve the readability of the logic in this method)

Contribution checklist (*)

• Pull request has a meaningful description of its purpose
• All commits are accompanied by meaningful commit messages
• All new or changed code is covered with unit/integration tests (if applicable)
• README.md files for modified modules are updated and included in the pull request if any README.md predefined sections require an update
• All automated tests passed successfully (all builds are green)

[m2-assistant]

Hi @digitalrisedorset. Thank you for your contribution!
Here are some useful tips on how you can test your changes using Magento test environment.

Add the comment under your pull request to deploy test or vanilla Magento instance:

• @magento give me test instance - deploy test instance based on PR changes
• @magento give me 2.4-develop instance - deploy vanilla Magento instance

❗ Automated tests can be triggered manually with an appropriate comment:

• @magento run all tests - run or re-run all required tests against the PR changes
• @magento run <test-build(s)> - run or re-run specific test build(s)
  For example: @magento run Unit Tests

<test-build(s)> is a comma-separated list of build names.

Allowed build names are:

1. Database Compare
2. Functional Tests CE
3. Functional Tests EE
4. Functional Tests B2B
5. Integration Tests
6. Magento Health Index
7. Sample Data Tests CE
8. Sample Data Tests EE
9. Sample Data Tests B2B
10. Static Tests
11. Unit Tests
12. WebAPI Tests
13. Semantic Version Checker

You can find more information about the builds here
ℹ️ Run only required test builds during development. Run all test builds before sending your pull request for review.

---

For more details, review the Code Contributions documentation.
Join Magento Community Engineering Slack and ask your questions in #github channel.

[digitalrisedorset]

@magento run all tests

[Den4ik]

@digitalrisedorset Thanks for contribution.
As I see suggested logic provide non expected logic.

Refund works only with shipped items.
Cancelation works only with non shipped items.

For example,
ordered = 5
shipped = 3
refunded = 2 (refunded from shipped 3)
canceled = 1
I expect to see 1 to ship.

Suggested logic will cause negative value and max(round($qty, 8), 0) return 0.

[digitalrisedorset]

excellent feedback, I will investigate this further. I will try to bring all the scenarios we may have so that we can verify we have all the possible situations in mind to resolve this issue.

Many thanks @Den4ik

[digitalrisedorset]

@Den4ik following your inputs, I was able to identify more use cases but unfortunately, it seems I have been focusing at the wrong end of the stick.

To make sure we understand what we are trying to do, I may recall here the aim of the PR:

• when an order has its physical items shipped, it should ignore the status of virtual items as these do not need to be shipped.
• when an order is refunded, the refund is intuitively thought to be complementary to the shipping data: shipped data + refund data = all data handled
  --> this was something I had in mind until now: currently, we can refund an item independently to its shipping status.

I am yet to ascertain how the refund data should be considered at this time:

• should the refund data and shipment data be considered separate? my suspicion is not and in this case, the method \Magento\Sales\Model\ResourceModel\Order\Handler\State::isPartiallyRefundedOrderShipped may need being revisited

I suggest not to review any further until I have more information with this part of the refund aspect

[digitalrisedorset]

@Den4ik I have now found out a way to fix the problem and I have committed some changes today. However, I see my change has a conflict with the method \Magento\Sales\Model\ResourceModel\Order\Handler\State::isPartiallyRefundedOrderShipped

The 2 lines change that have been made and conflict with my change are sufficient for this issue to be called close. I am more than happy to go with the change that have been provided and discard all my changes.

In short, if we close my PR and the issue and ensure the lines that conflict with my changes get pushed further, then the issue is resolved