ReSupply-AI

An AI purchasing assistant for small shops that forecasts demand, plans restocking within budget, and tracks owner-approved PayPal Sandbox payments and stock receipt.

Comment

Inspiration

I started with a practical question: how can a small shop decide what to buy next without relying only on guesswork or tying up too much cash in stock?

ReSupply AI connects daily sales, demand forecasting, supplier quotes, purchasing and payment in one workflow. The aim is to make restocking easier to understand while keeping the shop owner in control.

What it does

ReSupply AI helps shop owners:

  • Manage products, inventory and sales, and import confirmed daily sales history.
  • Forecast the next seven days of demand for each product.
  • Review supplier quotes and plan restocking within a product budget.
  • Review an order's quantities, shipping, tax and spending limit before approval.
  • Authorize a PayPal Sandbox hold, then separately confirm capture or void an uncaptured hold.
  • Confirm full stock receiving and inspect a receipt that records inventory before and after.

Separate pages organize the workflow. Supported voice or typed queries let owners preview stock, forecasts and budgets without approving purchases or sending payments.

How I built it

The backend uses Python, FastAPI, Pydantic and SQLite. The interface uses HTML, CSS and vanilla JavaScript, served by the same application.

Demand forecasting uses scikit-learn's RandomForestRegressor. It learns from sales lags, recent averages and weekday patterns. Training requires at least 56 consecutive confirmed same-source days without stockout flags. Earlier dates are used for training and later dates for testing.

The model is compared with a seven-day mean using mean absolute error, or MAE. The app selects Random Forest only when its tested MAE is at least 5% lower than the baseline's; otherwise it keeps the mean. This is a model-selection rule, not a guaranteed accuracy score.

The planner combines reviewed demand with current stock, supplier lead times, coverage, buffer and eligible dated incoming orders. It allocates the product budget by urgency, using exact cents for money calculations.

The official PayPal Python Server SDK handles Sandbox order creation, authorization, capture, void and status checks. Approval freezes the order details. A unique receipt and atomic stock transaction prevent repeated receiving from adding the same units twice.

Challenges I faced

The main challenges were testing forecasts without leaking future sales into training, keeping missing history distinct from zero sales, and separating synthetic data from actual shop records.

Payment handling also required clear boundaries between owner approval, a test hold, capture and stock receipt. Preserving request identity and reconciling uncertain responses were important for recovery.

What I learned

I learned that a complex model should be compared with a simple baseline, and that data quality matters as much as model choice. I also learned to design financial workflows around explicit review, clear states and recoverable actions.

Accomplishments

I built a connected prototype that takes a shop from sales history to a reviewed forecast, budget plan, approved order, PayPal Sandbox payment and stock receipt. An isolated demo shop makes the workflow reproducible, while tests exercise real model fitting and mocked payment recovery.

What's next

Evaluate actual shop histories on later unseen dates, then add authentication, partial deliveries, refunds and verified payment events. A real-shop pilot is needed before claiming business savings or reduced stockouts.

Demo scope

The demo uses synthetic sales data, USD, one PayPal Sandbox merchant and simulated goods arrival. Supplier quotes are local purchasing metadata; the prototype does not split payouts among suppliers.

Built With

Share this project:

Updates

Submission history