| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| v:2.0:inventory_management [2018/02/26 04:52] – [Basic Inventory Tracking] adam | v:2.0:inventory_management [2018/02/26 05:04] (current) – [Intermediate Inventory Tracking] adam |
|---|
| ===== Intermediate Inventory Tracking ===== | ===== Intermediate Inventory Tracking ===== |
| |
| The next step up for inventory tracking would be to add in an additional check right before the customer completes their checkout to confirm that inventory is still available at that point. This way, if a customer added a product to the cart but only attempted to complete the checkout hours (or even days) later, they can be prevented from doing so if another customer has purchased the remaining stock in the meantime. | Taking the basic tracking a step further, you can also add in the ability to limit how long a single product is allowed to be in the customers cart for, and perform a final inventory check right before the transaction is sent to the gateway for payment. |
| | |
| | ==== Limiting Product Lifetime In The Cart ==== |
| | |
| | Along with the ''quantity_max'' attribute noted in the basic inventory tracking above, there is also an ''expires'' [[.:products|attribute for products]]. This can either be an amount of time in minutes, or a future date/time represented as an epoch timestamp in seconds. If a product is added to the cart with an expires parameter set, it will automatically be removed from the customers cart if that date/time passes before the customer has completed the transaction. |
| | |
| | Depending on your product requirements, there is also a configuration setting available on the "Advanced" settings page to require that all products within your store make use of an ''expires'' attribute. This can be a way to ensure that a product never accidentally ends up in the cart without the ''expires'' value set - meaning that a customer could have that product in their cart indefinitely. |
| | |
| | ==== Confirming Inventory Before Final Checkout ==== |
| | |
| | One downside of the basic inventory tracking approach is that there is a potential for the stock level to have changed between the customer adding the product to the cart and them finally completing the checkout. To minimise the chances of that happening, you can add in a check right before the customer completes their checkout to confirm that inventory is still available at that point. This way, if a customer added a product to the cart but only attempted to complete the checkout hours (or even days) later, they can be prevented from doing so if another customer has purchased the remaining stock in the meantime. |
| |
| To achieve that, this will make use of the [[.:pre_payment_webhook|pre-payment webhook]] functionality. This feature sends a request right as the customer attempts to complete the checkout to an endpoint of your choosing. This endpoint receives a payload with all of the details of the transaction - including the products in the cart, the address the customer has entered and custom fields from the checkout. | To achieve that, this will make use of the [[.:pre_payment_webhook|pre-payment webhook]] functionality. This feature sends a request right as the customer attempts to complete the checkout to an endpoint of your choosing. This endpoint receives a payload with all of the details of the transaction - including the products in the cart, the address the customer has entered and custom fields from the checkout. |
| |
| You can also make use of [[https://api.foxycart.com|our API]] to quickly modify the cart for the customer - removing or updating products dynamically as required before sending them back to the checkout. The payload sent to the endpoint includes data from the API already - so you can use the URI's included within the payload to be able to interact with those resources straight away. | You can also make use of [[https://api.foxycart.com|our API]] to quickly modify the cart for the customer - removing or updating products dynamically as required before sending them back to the checkout. The payload sent to the endpoint includes data from the API already - so you can use the URI's included within the payload to be able to interact with those resources straight away. |
| |
| By adding in that extra check with the pre-payment webhook right before the customer completes the checkout, you can minimise the potential for a customer completing the checkout when stock may have decreased since they added the product to the cart. | |
| |
| ===== Advanced Inventory Tracking ===== | ===== Advanced Inventory Tracking ===== |
| ==== Add To Cart ==== | ==== Add To Cart ==== |
| |
| Along with the ''quantity_max'' attribute noted in the basic inventory tracking above, there is also an ''expires'' [[.:products|attribute for products]]. This can either be an amount of time in minutes, or a future date/time represented as an epoch timestamp in seconds. If a product is added to the cart with an expires parameter set, it will automatically be removed from the customers cart if that date/time passes before the customer has completed the transaction. | When setting the ''expires'' attribute that was detailed in the intermediate tracking section above - we'd recommend setting it to be before the inventory lock within your database is set to expire. That way you can give a little bit of breathing room between the cart product expiring and the lock clearing in your database to prevent any possibility of overlaps between stock becoming available again before it has actually expired in the cart for the customer that has that specific stock. |
| | |
| Depending on your product requirements, there is also a configuration setting available on the "Advanced" settings page to require that all products within your store make use of an ''expires'' attribute. This can be a way to ensure that a product never accidentally ends up in the cart without the ''expires'' value set - meaning that a customer could have that product in their cart indefinitely. | |
| | |
| When setting the ''expires'' attribute - we'd recommend setting it to be before the inventory lock within your database would expire. That way you can give a little bit of breathing room between the cart product expiring and the lock clearing in your database to prevent any possibility of overlaps. | |
| |
| ==== Tracking Cart Changes ==== | ==== Tracking Cart Changes ==== |
