magento2 icon indicating copy to clipboard operation
magento2 copied to clipboard
verified publisher icon magento

Customers Receiving In-Stock Product Alerts for Backordered Products

Open nikoelgatito opened this issue 1 year ago • 5 comments

Preconditions and environment

  • Magento 2.*

Steps to reproduce

  1. Create a product with 0 qty
  2. Set the Stock Status to "Out of Stock"
  3. Set the Backorders value to "Allow Qty Below 0"
  4. Visit the frontend product page and register to the In-Stock Product Alert
  5. Set the Stock Status to "In Stock"
  6. Wait for the Product Alert CRON job to execute

Expected result

No in-stock alert is sent, as even though the product is available for purchase/saleable, it is not actually in stock by definition.

When customers visit the product page, the stock status displayed is backordered.

Actual result

The In-Stock Product Alert email is sent, misleading the customer by indicating that the product is in stock.

When customers visit the product page, the stock status displayed is in stock.

Customers are then complaining that the product is not actually in stock, which causes unnecessary friction, and may result in both reputational and monetary losses.

Additional information

Please note that this issue may have important legal implications, as in many regions merchants have obligations to meet when a product is in stock.

In Stock != Backordered

By definition "In stock" means that the merchant has units readily available. While this may apply to both units stored locally and in different warehouses, it may not apply to other types of backorder which must be sourced from an external supplier.

Most, if not all customers, will expect a product advertised as in stock to be available from the merchant immediately. A customer receiving an alert stating that a product is in stock will rightfully expect the merchant to have units on hand.

Therefore, it is crucial to be able to handle both internally and externally sourced backorders properly.

Another aspect worth considering is that it is currently impossible for customers to register for In-Stock Alerts for a product that is available as a backorder. Since it is quite common for customers to wait for a product to come back in stock before placing an order, even when it is available as a backorder, this restriction may directly affect sales. Along with the other proposed changes, the change 5. below addresses this issue, without impacting existing functionalities.

There is another issue affecting the "Allow Qty Below 0 and Notify Customer" Backorders option, which would deserve its own report. Right now, if the the "Out-of-Stock Threshold" is -25 and there is -10 qty for a product having its "Backorders" attribute set to "Allow Qty Below 0 and Notify Customer", the customer will see "in stock" displayed for this product and, when adding the product to its cart, he will be notified that the product will in fact be backordered, which is contradictory. Along with the other proposed changes, the change 7. below addresses this issue, making all backorder behaviors consistent.

It is worth mentioning that, in 2017, I had invested a considerable amount of time on a similar issue; #10304. The Magento documentation has been greatly improved since then to better describe the intended behaviors and my current report is taking this into consideration.

After carefully reviewing potential implications, the approach stated in the proposed solution below has been elaborated in a way that makes it relatively easy to implement, while maintaining compatibility with the existing workflows and intended behaviors. This solution should also be compatible with the vast majority of use cases, allowing the utmost flexibility.

Proposed Solution:

Using three different Stock Status options to properly handle different use cases.

Stock Status List: 0 = Out of Stock 1 = In Stock 2 = Backordered

In the same way that the "Out of Stock" Stock Status is not directly tied to the quantity, the new "Backordered" Stock Status will not be directly tied to the quantity and will not affect how actual backorders are handled by the inventory management system.

Purposes of the Existing "In Stock" Stock Status:

  1. Display the "In Stock" availability on the frontend, independently from the actual inventory.
  2. Manually allow purchases, independently from the current inventory.
  3. Automatically allow purchases, depending on a configurable inventory threshold.
  4. Hide the "Notify me when this product is in stock" link on the product page.
  5. Send In-Stock Product Alerts.

Purposes of the Existing "Out of Stock" Stock Status:

  1. Display the "Out of Stock" availability on the frontend, independently from the actual inventory.
  2. Manually prevent purchases, independently from the actual inventory.
  3. Automatically prevent purchases, depending on a configurable inventory threshold.
  4. Display the "Notify me when this product is in stock" link on the product page.
  5. Do not send In-Stock Product Alerts.

Purposes of the New "Backordered" Stock Status:

  1. Display the "Backordered" availability on the frontend, independently from the actual inventory.
  2. Allow purchases, independently from the actual inventory.
  3. Automatically allow purchases, depending on a configurable inventory threshold.
  4. Display the "Notify me when this product is in stock" link on the product page.
  5. Do not send In-Stock Product Alerts.

The goal of the "Backordered" Stock Status is to clearly define the frontend availability and the features associated to it.

List of Changes:

  • [ ] 1. Add a "Backordered" Stock Status Description: In addition to the existing "In Stock" and "Out of Stock" Stock Status, a third "Backordered" Stock Status is added. Since this is a completely new status and most existing functions should not be affected, backward compatibility should not be an issue.

  • [ ] 2. Add a global "Backordered Threshold" Configuration Field: Description: This field would be displayed under the "Out-of-Stock Threshold" field in the "Product Stock Options" configuration section and would allow to control the threshold at the global level. Default: Use Out-of-Stock Threshold

  • [ ] 3. Add a "Backordered Threshold" Product Attribute: Description: This product attribute would be displayed under the "Out-of-Stock Threshold" attribute in the "Advanced Inventory" product edit section and would allow to control the threshold at the product level. Default: Use Out-of-Stock Threshold

  • [ ] 4. Update the ProductAlert Module's isSalable() Function Description: The Magento\ProductAlert\Model\ProductSalability::isSalable() Class::Function should be renamed isInStock() and updated with the proper logic using the new configuration field and product attribute described above.

  • [ ] 5. Allow Registering for In-Stock Product Alerts when Backordered Description: Display the "Notify me when this product is in stock" link on product page when the Stock Status is Backordered.

  • [ ] 6. Display "backordered" in Templates Description: Add conditions to replace the "in-stock" string by "backordered" in various frontend templates, where applicable. This ensures that the customer does not see "in stock" for products that are actually backordered, should the "Out-of-Stock Threshold" be lower than the "Backordered Threshold".

  • [ ] 7. Base "Notify Customer" on "Backordered" Status: Description: In order to ensure consistency among the various functionalities, when the "Allow Qty Below 0 and Notify Customer" option is selected for the "Backorders" field, the customer should only be notified when the Stock Status is "Backordered".

  • [ ] 8. Update Other Affected Functions: Description: Every other function relying on the Stock Status product attribute should interpret the "backordered" Stock Status as if it was the "In Stock" Stock Status by default.

Since, by default, the "Out-of-Stock Threshold" value will be used as the "Backordered Threshold", any user not interested into these functionalities could simply ignore them without being impacted by the changes.

A similar problem had already be reported through the issue #27639 in 2020.

Release note

No response

Triage and priority

  • [ ] Severity: S0 - Affects critical data or functionality and leaves users without workaround.
  • [X] Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
  • [ ] Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
  • [ ] Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
  • [ ] Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.

nikoelgatito avatar May 24 '24 07:05 nikoelgatito

Hi @nikoelgatito. Thank you for your report. To speed up processing of this issue, make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, Add a comment to the issue:

Join Magento Community Engineering Slack and ask your questions in #github channel. :warning: According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting. :clock10: You can find the schedule on the Magento Community Calendar page. :telephone_receiver: The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, join the Community Contributions Triage session to discuss the appropriate ticket.

m2-assistant[bot] avatar May 24 '24 07:05 m2-assistant[bot]

@magento give me 2.4-develop instance

nikoelgatito avatar May 24 '24 07:05 nikoelgatito

Hi @nikoelgatito. Thank you for your request. I'm working on Magento instance for you.

magento-deployment-service[bot] avatar May 24 '24 07:05 magento-deployment-service[bot]

Hi @nikoelgatito, here is your Magento Instance: https://1da05d601721983dfa903142809e4c22.instances-prod.magento-community.engineering Admin access: https://1da05d601721983dfa903142809e4c22.instances-prod.magento-community.engineering/admin_30e3 Login: a664980b Password: c8bad74052aa

magento-deployment-service[bot] avatar May 24 '24 07:05 magento-deployment-service[bot]

Hi @engcom-Dash. Thank you for working on this issue. In order to make sure that issue has enough information and ready for development, please read and check the following instruction: :point_down:

    1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).
    1. Verify that issue has a meaningful description and provides enough information to reproduce the issue.
    1. Add Area: XXXXX label to the ticket, indicating the functional areas it may be related to.
    1. Verify that the issue is reproducible on 2.4-develop branch
      Details- Add the comment @magento give me 2.4-develop instance to deploy test instance on Magento infrastructure.
      - If the issue is reproducible on 2.4-develop branch, please, add the label Reproduced on 2.4.x.
      - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and stop verification process here!

m2-assistant[bot] avatar May 24 '24 08:05 m2-assistant[bot]

@magento give me 2.4-develop instance

engcom-Dash avatar May 27 '24 09:05 engcom-Dash

Hi @engcom-Dash. Thank you for your request. I'm working on Magento instance for you.

magento-deployment-service[bot] avatar May 27 '24 09:05 magento-deployment-service[bot]

Hi @engcom-Dash, here is your Magento Instance: https://1da05d601721983dfa903142809e4c22.instances-prod.magento-community.engineering Admin access: https://1da05d601721983dfa903142809e4c22.instances-prod.magento-community.engineering/admin_c68a Login: f2d66dbe Password: 30d236eac91c

magento-deployment-service[bot] avatar May 27 '24 09:05 magento-deployment-service[bot]

Hi @nikoelgatito

Thanks for reporting and collaboration.

We are marking this ticket as on hold. We have reopened the dependent issue - https://github.com/magento/magento2/issues/35602. Will test this issue once the dependent issue is fixed.

Thanks.

engcom-Dash avatar May 28 '24 05:05 engcom-Dash

Hi @nikoelgatito

Thanks for reporting and collaboration.

Verified the issue on Magento 2.4 dev instance but the issue is not reproducable.

No in-stock alert is sent, as even though the product is available for purchase/saleable, it is not actually in stock by definition.

When customers visit the product page, the stock status displayed is back ordered.

Steps to reproduce

  1. Create a product with 0 qty
  2. Set the Stock Status to "Out of Stock"
  3. Set the Backorders value to "Allow Qty Below 0"
  4. Visit the frontend product page and register to the In-Stock Product Alert
  5. Set the Stock Status to "In Stock"
  6. Wait for the Product Alert CRON job to execute

Please refer the screenrecoring attached. Let us know if we missed anything.

https://github.com/magento/magento2/assets/60198592/ce67ab8c-d75c-48fe-9828-ad3f62acb398

engcom-Dash avatar Jun 14 '24 07:06 engcom-Dash

Hi @nikoelgatito

As there is no activity on this issue for a long time, we believe the issue has been resolved, hence closing this issue. Feel free to raise a new issue or reopen this if you need more assistance.

Thank you.

engcom-Dash avatar Jun 27 '24 06:06 engcom-Dash