Skip to content

Part 1 of 7 · Stock transfer planner series ~6 min read

A stock transfer planner on AWS for a few dollars a month

Branch three has forty of something that has not sold in two months. Branch one sold out of it last week. The obvious answer is to move some, and for a fourteen-pound item with a four-pound margin, a van trip and two people’s time makes that a way of converting stock into a smaller amount of stock somewhere else. This post walks through a small system that does the arithmetic first.

a semi truck is loaded with white bags
Photo by Zemos on Unsplash

Key takeaways

  • Test the economics before proposing a transfer. Most fail.
  • Real demand at the destination, not merely a low stock level.
  • Never leave the source below its own reorder point.
  • Wait for a vehicle that is going there anyway; it changes the arithmetic entirely.
  • Designed on AWS for about $2 a month.

The whole system on one page

Before any code, here is the shape of what we are designing.

System: stock imbalances tested for worth and batched onto movementsThree boxes across the top sit outside the AWS account. On the left, Stock by site, with what sells where. In the middle, Vehicle movements that are already happening. On the right, Whoever picks, who gets a short list. Each connects by an arrow to the AWS account container below. Levels and sales flow down into the account. The schedule feeds in. A few transfers go back out. Inside the AWS account are three components in a row. On the left, Imbalance, finding surplus here and demand there. In the middle, Worth it, weighing margin against the cost of moving. On the right, When and how, placing it on a van that is going anyway. A note at the bottom says the middle box rejects most of what the first box finds, and that is correct.AWS ACCOUNTStock by siteand what sellswhereVehicle movementsalready happeningWhoever picksgets a short listImbalancesurplus here,demand thereWorth it?margin againstthe cost of movingWhen and howon a van that isgoing anywaylevels and salesthe schedulea few transfersThe middle box rejects most of what the first box finds, and that is correct.
Fig 1. Three things outside the account, three pieces inside it. The imbalance detection is easy; the economic test is what makes the output usable.

The cost of moving a box

Picking it at one end, packing it, paperwork, the vehicle, receiving and putting it away at the other end. For a dedicated trip that is tens of pounds before anybody counts the vehicle; on a movement that was happening anyway it is the picking and receiving, which is still several pounds of somebody’s time.

Against that sits the benefit, which is not the value of the stock. It is the margin on the sales that would otherwise be lost, discounted by the probability those sales actually happen and by whether the item would have sold at the source eventually anyway.

What runs (the inside)

  • Imbalance detection. Finds stock that is in the wrong place relative to where it sells. Part 2.
  • The economic test. Decides whether moving it is worth more than leaving it, and protects the source. Parts 2 and 3.
  • Batching. Holds proposed transfers until a vehicle is going that way. Part 4.

One transfer, end to end

One stock transfer from imbalance detection to a batched movementA horizontal row of five boxes joined by arrows. Branch three has forty, selling one a month. Branch one sells nine a month and has two. Worth it: twenty-eight pounds of margin against nine pounds of cost. Source protected: keep six at branch three. On Thursday's van, going there anyway. A note says the same transfer on a dedicated trip costs forty pounds and does not happen.ONE TRANSFER, END TO ENDBranch 3 has 40selling 1 a monthBranch 1 sells 9a month, has 2Worth it?£28 margin vs £9 costSource protectedkeep 6 at branch 3On Thursday's vangoing there anywayThe same transfer on a dedicated trip costs £40 and does not happen.
Fig 2. The same system as one line. The note is the whole reason the batching step exists.
  • Compute
  • Security & identity
  • Analytics

In plain words

Branch three has forty units of an item and sells about one a month, so it is holding more than three years of cover. Branch one sells nine a month and has two left, which is about a week.

Moving twenty-two units protects roughly two and a half months of sales at branch one. At a margin of a few pounds each and a realistic probability that most of those sales would otherwise be lost, the benefit is around twenty-eight pounds. Picking and receiving on an existing movement costs about nine, so it clears.

The source keeps six units, which is six months of its own demand, so branch three is not left unable to sell the item to the occasional customer who wants it. And it goes on Thursday’s van, which is already making that trip, rather than on a dedicated journey that would have made the whole thing uneconomic.

Design rules that shaped every decision

  • Compare the margin protected against the full cost of moving, both ends.
  • Demand at the destination means sales history, not a low stock number.
  • Never take the source below its own cover requirement.
  • Batch onto existing movements; a dedicated trip needs a much larger benefit.
  • Track in-transit explicitly. Stock in a van is at neither end.
  • Detect and block ping-pong: the same item moving back within a quarter.

Why this shape

Multi-site stock imbalance is genuinely expensive and the standard response makes it worse: a report of imbalances, generated weekly, which somebody works through by moving things. That produces a great deal of van time and picking labour, a fair number of transfers that reverse themselves, and stock that is temporarily missing.

The version that works rejects most of the list. What is left is a small number of transfers that clearly pay, that do not hurt the source, and that ride on movements already scheduled. The value is as much in what it declines to propose as in what it proposes.

The next four posts walk through each piece: when a transfer is actually worth it, how the source gets protected, how transfers get batched onto movements that already happen, and what in-transit stock does to your numbers. One diagram per post, a cost breakdown, and an engineering reference at the end.

All posts