Fulfillment Restock Calculator
How many units to ship to the marketplace warehouse, with numbers
Crosses each channel's sales against what sits in fulfilment, your available stock and what is inbound, and returns how many units of each SKU to ship. It separates the ideal from what you can actually cover today.
How you get it
Every development works in all three Odoo environments. The only thing that changes is how we deliver it.
Odoo Online (SaaS)
You do not need the ability to install modules. A Millora consultant comes in with temporary access that you authorize and implements it with Odoo Studio. When they are done, you revoke the access.
Odoo.sh or your own server
You receive the module and the installation guide by email as soon as payment clears. Install it yourself, or we install it with you.
Installation · shell
# 1 · copia el módulo a tu addons_path
cp -r millora_calculadora_de_reabasto_full /mnt/extra-addons/
# 2 · reinicia y actualiza la lista de apps
odoo-bin -u all -d tu_base --stop-after-init
# 3 · instala desde Apps
# busca "Fulfillment Restock Calculator"What it solves
The problem
Fulfilment stock is consigned: it lives in the marketplace's distribution centre, not yours. Ship too little and you run dry on the very channel that sells the most. Ship too much and you freeze cash and pay storage somewhere getting the product back costs time and money.
And the decision comes up every week, SKU by SKU: from memory, or with a spreadsheet that badly crosses four figures living in four different places — the channel's sales, what the marketplace says it holds today, what is available in your warehouse and what is on its way.
How it works
You define one channel per fulfilment — one for each marketplace — with its sales team, its coverage days and its lead time. They do not take the same time to make a shipment sellable, which is why those timings live on the channel and not in a fixed formula.
Demand is measured with a weighted average of two windows: by default 70% over the last 30 days and 30% over the last 90. That is deliberate. With only the short window, one odd week — a sale event, a dead fortnight — drives the result; with only the long one, a product that took off a month ago gets restocked too late.
On that daily rate it computes the target — coverage plus lead time plus safety days — subtracts what is already in fulfilment and what is inbound to it, and rounds to the packing multiple.
Then comes what sets this calculator apart: it does not return one figure, it returns three.
- Suggested — the ideal, without looking at whether you can cover it.
- Shippable today — what the unreserved stock of the warehouses you picked can cover. It does not count stock already reserved for an order: sending that to fulfilment would be taking it from a customer who already bought.
- Shippable with inbound — the same, counting what is coming from suppliers or production.
Whatever still isn't covered lands in Shortfall, in its own column. That column is the purchase or production order, already calculated.
Every SKU also comes out with a status — out of stock, urgent, restock, healthy or overstocked — and a line explaining why it landed there.
One detail that changes the number
Demand can be measured two ways, and the difference is fundamental. By default it counts all of the channel's sales, including those shipped from your own warehouse because fulfilment had run out. A product that ran dry at the distribution centre and kept selling by another route should not look as if it stopped selling — which is exactly the error that turns a stockout permanent.
If you would rather measure strictly what left the channel's warehouse, that is a setting.
It works in Studio too
Even though it ships as a module, it is built within what Odoo Studio can reproduce: plain models, stored fields written by a button, and Odoo's native importer for the marketplace snapshot. If the operation runs on Odoo Online, it gets implemented there without losing anything.
What it does not do
It does not move stock. It is a calculator: it ends in a list. The shipment gets assembled afterwards, with that list in hand.
Fulfilment stock is uploaded by hand. You load the report the marketplace itself provides, by SKU. There is no live connection to the channel's warehouse, so the figure is only as fresh as the last snapshot you uploaded — and the run warns you when it is over a week old. Re-uploading the day's file corrects the figure rather than duplicating it.
A marketplace SKU that does not exist in your catalogue does not count. It is set aside in its own list and the calculation assumes zero in fulfilment, saying so on the row instead of staying quiet about it.
It knows nothing about the channel's own restrictions: shipment caps, blocked categories, warehouse quota. It suggests; validating against the marketplace's rules stays yours.
A launch with no sales history cannot be forecast. For those you enter the expected daily units by hand; the module allows it, but the number is yours.
What changes
The weekly question stops being answered from memory. And above all, it stops being answered with a single figure: you see at once how much you ought to ship, how much you can ship today and how much you need to buy in order to ship it — three separate decisions that until now came tangled together.
Every run stores the parameters it was calculated with, so two months later the question "why did we ship 40 units of this?" has its answer in the same record.
What's included
- Calculates the suggested shipment per SKU, crossing channel sales, fulfilment stock, own availability and inbound
- Measures demand with a weighted average of two windows, so one odd week doesn't drive the result
- Returns three figures per product: the ideal, what is shippable today, and what is shippable counting inbound
- Puts the shortfall in its own column: the purchase or production that is missing, already calculated
- Counts only unreserved stock as available, without taking it from orders that already have it reserved
- Counts as inbound only what arrives from suppliers or production, not transfers between your own warehouses
- Flags every SKU — out of stock, urgent, restock, healthy or overstocked — and explains why, row by row
- One channel per fulfilment, with its coverage, its lead time, its packing multiple and its minimum shipment
- Per-product exceptions for the discontinued item, the bulky one and the launch with no sales history
- Freezes the parameters on every run, so months later you can explain why what was shipped was shipped
Requirements
- Inventory and Sales modules active
- Marketplace orders reaching Odoo with their sales team: that is what Odoo Marketplugin does. The module does not technically require it, but without the channel's sales in Odoo there is no demand to measure
- One sales team per fulfilment channel
- The marketplace's stock report, uploaded as often as you decide to ship
- Marketplace SKUs matched to the product code in Odoo
- Deciding the channel's inventory policy: how many days of coverage you want and how long a shipment takes to become sellable
You might also need
Fulfilment Appointments
So the appointment doesn't fall through over something already known
Inventory & warehouse
Containers
You know what each unit cost you before the ship docks
Inventory & warehouse
Repurchasing
Which month you run out, and how much to order so you don't
Inventory & warehouse