BigCommerce restock planner with supplier purchase orders

Build me a restock planning workbench for my BigCommerce store. My ops person opens it every Monday to decide what to reorder. This is a working surface, not a report and not an alert: the whole point is that quantities are editable, decisions get saved, and the resulting orders go out from the same screen.

The main screen is a single planning table with one row per stocked SKU. Columns: product name, SKU, brand, category, supplier, current stock on hand, units sold in the trailing 30 days, trailing 60 days and trailing 90 days, a computed daily sales velocity, days of cover remaining, and a suggested reorder quantity that I can edit inline. Rows are sorted by urgency so the SKUs about to stock out sit at the top, meaning ascending days of cover, with anything already at zero stock but still selling pinned to the very top. Give me filters for brand, category and supplier, plus a free-text search on name and SKU. Let me sort by any column, but urgency is the default.

Handlers pull the catalog and stock with BigCommerce Get All Products and Get All Product Variants, paginating at the maximum page size of 250 until every page is read. Sales velocity comes from BigCommerce Get All Orders over the trailing 90 day window, then List Order Products for each of those orders to get per-SKU unit counts, which are summed by SKU into the 30, 60 and 90 day buckets. Only count orders that actually represent demand: exclude incomplete, cancelled, declined and refunded orders. Note that the orders endpoints are the older V2 style and return an empty response with no body rather than an empty array when there are no more results, so page until you get that empty response instead of expecting an empty list.

Daily sales velocity is units sold in the chosen window divided by the number of days in that window, defaulting to the trailing 30 days with a control to switch the driving window to 60 or 90. Days of cover is current stock on hand divided by daily velocity, shown as unlimited or blank when velocity is zero rather than as an error or infinity. The suggested reorder quantity is target days of cover multiplied by daily velocity, minus current stock on hand, rounded up, and floored at zero so it never suggests a negative order. Show the suggestion and my override side by side so it is obvious when I have changed something.

Once I have set my quantities I select rows and can do three things. First, write corrected stock levels straight back to the store using Update a Product or Update a Product Variant, using Update Products (Batch) and Update Variants (Batch) when I have selected several so it goes out as one call per page rather than one per SKU. Second, send a grouped purchase order email with Gmail Send a Message: group the selected rows by brand and send one email per supplier, addressed to the supplier email I saved for that brand, listing SKU, product name, quantity ordered and current stock, with a clear subject naming the brand and the date. Third, post the finished restock plan to my ops channel with Slack Bot Send a Message, summarising how many SKUs were ordered, the total units, the brands covered, and calling out the most urgent items.

Critical nuance on writing stock back. Stock in BigCommerce lives at either the product level or the variant level, and writing to the wrong one silently does nothing, so check each product's inventory_tracking setting before writing. When tracking is set at the product level, write the stock to the product. When it is set at the variant level, write it to the individual variant and never to the parent product. When tracking is off entirely, exclude that product from the table altogether, because there is no stock figure to plan against. Products tracked at variant level should appear as one row per variant, not collapsed into a single parent row, so a single size or colour about to run out is visible instead of being hidden inside a product-level total. After each write, confirm what actually changed and show a per-row success or failure state rather than one blanket success message.

Persist my planning settings between visits. Save a target days of cover per SKU, so the suggested quantities come back the same way each week without re-entering them, plus a store-wide default target used by any SKU I have not set individually. BigCommerce does not store a supplier against a product, so the app also needs to hold its own supplier list: a supplier name and email address mapped per brand, editable in a small settings view, which is what powers both the supplier filter on the table and the purchase order emails. Keep a record of each plan I send, showing what was ordered, when, and to whom, so the next visit can show what is already on order and I do not accidentally reorder the same thing twice.

On performance: reading 90 days of orders and then the line items for each one is a lot of calls, so do not refetch everything on every page load. Compute the sales figures into a stored snapshot with a visible last-updated time and a Refresh button that rebuilds it, and load the table from that snapshot so Monday morning opens fast. Current stock on hand should be read fresh, since that is the number I am about to correct. Respect the store rate limits when paging and back off rather than failing the whole load if a page is throttled.