Calculating…
Ajanta Traders / Operations workspaceFrom demand
From demand
to delivered.
Ordering, stock, replenishment, billing handoffs and delivery in one workspace. 671 real product descriptions and annual quantities ground the planning baseline. Current orders and stock are an interactive scenario; customer identities are anonymized.
Today 11:20
On the platformOutside the platform (Marg ERP)Numbers are orders at each step. Click a step to open its screen.
1 / 11
Ajanta / Replenishment planning
Plan the next purchase.
01 / Replenishment planning
Preparing forecastAllocate the next purchase.
Preparing the first plan…
Review queue
Operations / Decision support
Checking connectionAsk about the operation.
When you ask, your inventory snapshot and demand history go to this site’s server to verify calculations. The assistant receives calculated planning evidence and your question. In Ajanta mode it also receives the scenario order, purchase and stock snapshot. Real item names and annual sales quantities ground the baseline; current operations remain an interactive scenario. It explains the plan; it cannot place orders or change decisions. Imported operational figures are sent to Gemini only when you enable sharing and ask a question.
Answers will show the products used as evidence. There are no canned AI answers.
02 / Performance and trade-offs
See what the plan changes.
Projections assume one replenishment arrival and no repeat purchases during the chosen horizon. They are not measured company outcomes.
Planner review
Review time counts time spent on reviewed products in this visit, capped at ten minutes per decision. Estimated time saved compares that time with your assumed manual baseline. This is not a controlled productivity study.
Saved scenarios · same dataset
Forecast scorecard
Ajanta uses annual quantity / 365 as a baseline: daily forecast accuracy and seasonality are unavailable from annual data. For imported daily data, models use separate 14-day validation and test periods. WAPE is absolute error divided by observed demand; “Unavailable” means the denominator is zero.
03 / Accountability
Every decision has a reason.
Draft orders are CSV records for review. For the Ajanta workspace, use “Create reviewed purchase draft” to create a purchase draft in the operations dashboard. Active decisions and history are saved in this browser. Recalculating creates a new plan; older decisions remain in the history.
| Time | SKU / location | Decision | Units | Reason and plan |
|---|
Clear this browser's workspace
Download your records first if you need them. This clears imported data, decisions and saved scenarios from this browser.
04 / Data quality
Bring your own planning data.
Import one inventory snapshot and daily demand history. Use the column templates below and supply a genuine daily demand history. The Ajanta annual report cannot substitute for daily observations. Both files are validated together before replacing the active dataset.
Required columns and validation
Inventory: sku, name, location, category, snapshot_date, on_hand, on_order, lead_days, pack_size, unit_cost, unit_price, shelf_days, liters_per_unit.
Demand: sku, location, date, units. Provide 42–366 consecutive days ending on the snapshot date, including genuine zero-demand days. Missing observations are rejected instead of being filled with invented zeros.
Use YYYY-MM-DD dates, INR prices and individual sellable units. Category is Ambient, Chilled or Frozen. Each SKU/location pair must be unique in inventory, and each SKU/location/date must be unique in demand. Maximum 100 inventory records, 40,000 demand rows and 5 MB per file. Current shelf_days is a conservative purchasing limit; batch expiry tracking is not included.
05 / Product decisions
Architecture ↗Prediction → optimization → judgment.
Choose an honest baseline
The Ajanta annual report supplies real item names and annual quantities. Divide by 365 for a transparent average; do not infer seasonality or forecast accuracy. Imported daily history enables four competing forecast models with separate validation and test periods.
Optimize the allocation
Integer case-pack purchases compete for one budget and shared inbound capacity. Maximize recoverable gross margin, or fulfilled units, after a holding-cost penalty. Stock targets, shelf-life caps and lead times bound each purchase.
Explain and decide
The server recomputes the evidence before calling the AI model. Answers cite SKU/location records and expose assumptions. Approval, modification and rejection are separate human actions.
Model assumptions and limits
Ajanta uses FY2024-25 annual sales quantities. Stock, cost, price, category, lead time, shelf life and storage are scenario assumptions. The source does not identify quantity units; one source unit is preserved without assuming pieces or cartons. Annual data cannot support a variability-based safety stock estimate, so the service buffer has no effect in annual-average mode. Confirm daily history and physical units before operational use.
Existing and proposed inbound quantities arrive together at the start of the adjusted lead-time day. Unmet demand is lost, not backlogged. No repeat purchasing occurs during the horizon. Forecasts omit price elasticity, supplier reliability and batch expiry unless their effects appear in historical demand.
The service percentage sets a normal-distribution stock buffer, not a promised achieved fill rate. Free cold and total capacity represent shared inbound liters across the selected network. Location-specific space, temperature compartments and vehicle routing require more granular data and a different model.
The mixed-integer solver has a four-second search limit and a 0.1% target gap. Every returned allocation is checked against budget, pack-size and capacity bounds. A feasible result is not a guarantee of real-world optimality. The app labels zero-demand error metrics as unavailable.
The assistant uses Gemini and cannot execute orders. Without a configured server connection it shows an unavailable state. Operational data stays in your browser until you explicitly share planning evidence with the assistant. Browser persistence is not a shared enterprise database.
The problem
Orders lived on paper and phone calls
Orders were written down, phoned in and re-typed for billing, and dispatch was planned the next day. An order took 4 to 5 days to reach the shop, and nobody could say where it was or which shops a salesperson had actually visited.
What I decided
Fix the business, then build the platform
Client visits, segmentation and collections came first. I built the salesperson ordering app and the dashboard that received orders and tracked dispatch and delivery. Excel export/import connected the dashboard orders to Marg ERP, where invoicing stayed. One status per order, visible to every role.
What changed
4–5 days became same day
Orders booked in the app, Excel orders imported and invoiced in Marg ERP and dispatch the same day on our own fleet, including cold storage vehicles. Every visit, order, vehicle and stuck order is visible in one place.