Our logic of orderable & availability status follows the superior logic that orderability of a product has nothing to do with its stock status. A product can be orderable or non-orderable despite if it's currently in stock, ordered or not in stock.
Sadly with the Google Merchants availability statuses we chose ones that don't use this separation, but combine the status. See https://support.google.com/merchants/answer/6324448?hl=en-GB#When_to_use
These are the supported values that you can choose from:
In stock [in_stock]
You're accepting orders for this product and can fulfil the purchase request. You're certain that the product will be dispatched or be in transit to the customer in a timely manner because it's available for sale. You can deliver the product to all of the locations that you support in your product data and delivery.
Out of stock [out_of_stock]
You're not accepting orders for this product or the product isn't available for purchase.
Pre-order [preorder]
You're accepting orders for this product, but it has not been released for sale. You're required to provide the availability date [availability_date] attribute to indicate the day that the product becomes available for delivery. The availability date should be visible on the landing page.
Backorder [backorder]
The product isn't available at the moment, but you're accepting orders and it will be dispatched when it's available again. You're required to provide the availability date [availability_date] attribute to indicate the day that it will be dispatched. The availability date should be visible on the landing page.
Furthermore we should add some more words to explain what "backorder" and "preorder" means. Here's our current implementation:
function commerce_product_availability_get_availability_status_options(): array {
$options = [
'in_stock' => t('In stock'),
'out_of_stock' => t('Out of stock'),
'preorder' => t('Preorder'),
'backorder' => t('Backorder'),
];
// Invoke module alter hook to modify the availability status options:
// @todo Pass a context variable here, so we can alter the options based on
// specific conditions.
\Drupal::moduleHandler()->alter('commerce_product_availability_availability_status', $options);
return $options;
}
Setting orderable=TRUE but availability_status=out_of_stock is valid in our logic but doesn't follow the Google Merchants logic.
Best might be to throw out the Google Merchants status from the selection and instead use our own status. The Google Merchant statuses could then be derived from that logically.
Active
1.0
Code (commerce_product_availability)
Before touching anything here, we first need to discuss the final expected outcome.
As @Grevil just pointed out correctly, in our mental model we have
- In stock
-- [possible other in stock sub-statuses]
- Out of stock
-- Incoming (preorder)
-- [possible other out of stock sub-statuses]And we could then map the result combination for Google Merchants.