We've configured an on-premises Magento store with sample data, operating on version 2.4.6. Our goal is to insert orders using the REST API. Although we've successfully inserted orders, we've encountered an issue where the product inventory isn't being deducted as expected when utilizing the "Check / Money order" (checkmo) payment method.
Interestingly, when attempting the same process through the storefront interface, the deduction of inventory functions properly.
The deduction of inventory kind of depends on lots of different configurations. What actually happens when you do it through the storefront and what happens when you do it through the API?
In which state is the order when you do it from the front end and in which when you do it through the API?
In both cases (Storefront & REST API), When an order is placed the initial order state is "new" and the order status is "pending"
Attaching Screenshots for inventory configuration in the Magento admin panel.
So when you ship the order does the quantity decrease then?
I mean, you have sellable quantity and quantity. My best guess is your sellable qty decreases and your quantity remains the same as quantity goes into inventory reservation and once you ship the order the reservation is released and your quantity decreases.
When we use the REST API to insert orders, the Salable quantity isn't decreasing as expected, unlike orders inserted through the storefront.
We're trying to figure out if there's a specific setting in the Order Creation Payload that controls the salable quantity.
To troubleshoot, we copied the payload of an order placed through the storefront and used it to create another order via the REST API. However, the salable quantity still isn't being updated correctly.
Order Creation & Validation: When an order is created through the API, validate the details such as item IDs, quantities, and user credentials before processing.
Inventory Deduction Logic: After validating the order, ensure the requested items are available in the inventory. Deduct stock based on the quantity ordered in a synchronous or asynchronous transaction.
Atomic Operations: Use atomic operations for inventory updates to avoid conflicts, especially with high order volumes. This can prevent overselling by locking or reserving stock as soon as the order request is received.
Error Handling & Rollback: If any issue arises during the order process or inventory update, have a rollback mechanism. For example, if the deduction fails, cancel the order and notify the user.
Status Updates: Provide order status updates (e.g., pending, confirmed, shipped) through the API, ensuring the client is informed of each stage, particularly when stock levels change due to an order.
Concurrent Requests & Load Management: For high-traffic systems, use queuing mechanisms or optimistic locking to handle concurrent order requests, avoiding double-counting or multiple deductions for the same item.
Logging & Monitoring: Track each order transaction and inventory change for auditing and debugging, providing insights into stock levels, API performance, and potential issues.