Case Study - A Full ERP with Goldratt Buffers in the Code

01 Context and pain

Three systems, one owner's Excel, and a 60-day supply chain

A fast-growing seller of towels, bathrobes and textile sets. The numbers lived in three disconnected services. The most important decision of the business, what to restock and when, was made by hand.

Data scattered across 3 systems

The marketplace cabinet held orders and ads. MoySklad (an inventory SaaS) held warehouses and set recipes. TrueStats (a seller analytics service) held unit economics. Plus manual file exports. Nobody saw one picture.

Restock planning rested on one person

Which SKU to move to the marketplace warehouse, how much and when: the owner decided this daily, in a personal Excel, across 763 product cards in ~27 categories. The process did not scale and did not survive a vacation.

Seasonal goods, long supply legs

Production takes about 60 days, plus ~10 days of delivery, plus domestic legs. Order too late and you miss the season. Order too early and you freeze cash in stock. The margin for error is small and shrinks in season.

Problems surfaced by eye

Stockouts, order drops, negative reviews and data mismatches were noticed when someone happened to look. With 6,000 orders a day, "happened to look" is not a control system.

02 System architecture

A nightly conveyor in, decisions out, narrow writes back

Every night Celery jobs pull the marketplace, the inventory SaaS and the analytics service into PostgreSQL. Calculation modules turn raw rows into buffers, alerts and forecasts. People work in a React SPA or in a Google Sheets showcase that the backend renders for them. In the daytime, during the warehouse shift, the FBS module polls the marketplace every minute and writes back exactly what it is told to: supplies into the marketplace account and purchase orders into MoySklad, every write with a log entry.

External systems ERP services Data store Self-monitoring

One night in the life of the system

03:00Database backup. Rotation: 14 daily plus 8 weekly copies, restore script tested.
03:30Marketplace sync: orders, sales, stocks, cards, adverts, reviews, supplies, tariffs.
05:00The full autotest suite runs in a clean database. Results go to the Health page.
06:30MoySklad sync: warehouses, items, stock by warehouse, set recipes.
07:10Alert recalculation: 7 types, episode lifecycle, no duplicates.
08:00TrueStats sync behind a data-readiness gate: 98 unit-economics metrics per SKU.
08:30Dashboard aggregates, TrueStats vs WB reconciliation, DBM buffer zones and recommendations.
08:40Set combinatorics, ABC classes, Google Sheets showcase render.
09:00Catch-up pass for anything that failed. A watchdog checks for stuck syncs every 5 minutes.
08-20The warehouse shift: FBS orders and supplies are reconciled with the marketplace every minute, the acceptance log per supplier is recomputed every 30 minutes.

8Docker services behind nginx

110tables, 61 migrations, one head

20backend modules, each with its own README

~70Klines of Python + TypeScript without tests, ~40K more in tests

10UI themes on CSS tokens, zero hardcoded colors

Contracts between modules mean nothing is computed twice: sufficiency comes from one function, the 33/67 traffic light from one settings row, ABC classes from one service. The pulse board, the Google showcase and the alerts all consume the same numbers.

03 Flagship module

Goldratt's Theory of Constraints, running in production

The client asked to verify his own restock formulas and suggest improvements. His classic coverage math stayed in the table as visible columns. On top of it the system runs Dynamic Buffer Management (DBM): every SKU gets a target buffer, the buffer splits into traffic-light zones, and the buffer corrects itself from actual consumption. This is textbook TOC, implemented as code and tests.

B (target buffer) = V_plan × N days × 1.1 × M · V_plan = V30 × trend clamp(V3/V30, 0.5..2.0) × Kseason

The ×1.1 is the client's paranoia margin on every buffer, in the spirit of Goldratt. M is the DBM multiplier: it starts at 1.00 and moves in steps of 1/3.

Green · 67% and up

The buffer is full enough. Do nothing. Twelve green days in a row will suggest shrinking the buffer: capital should not sleep in stock.

Yellow · 33 to 67%

Plan replenishment. The SKU enters the restock table with a computed quantity, not a guess.

Red · below 33%

Order now. Red days accumulate in the 12-day history; a red streak triggers a buffer increase recommendation.

Black · zero stock

Stock is zero while sales run. Lost revenue every day. Black counts as red in the streaks and screams at the top of the alert feed.

Daily DBM job Increase branch Decrease branch / human control Stabilizer Buffer math

The constants, and why they are what they are

Constant	Value	Reasoning
DBM window	`12 days`	Three times the replenishment leg to the marketplace warehouse (4 days). A shorter window reacts to noise, a longer one reacts too late.
Increase trigger	`≥80% red of 12`	A buffer that lives in red is not a buffer. Recommendation: +1/3 of the target.
Decrease trigger	`12 green in a row`	A buffer that never leaves green is frozen cash. Recommendation: -1/3, and only a full unbroken streak counts.
Floor	`M ≥ 1/3`	The multiplier never drops below one third. If a step would break the floor, the decrease is not even suggested.
Cooldown	`12 days`	After any correction the system stays silent for a full window, so one decision is measured before the next one is proposed.
Paranoia	`×1.1`	The client's rule: +10% on every buffer. Encoded as a named constant, covered by tests.
Supply legs	`4 / 14 / 74 days`	To the marketplace warehouse / from the producer's stock / from production (60-day cycle + 10 delivery + domestic legs).
TOP rule	`90%`	The client's rule: an A-class SKU below 90% buffer always jumps to the top of the restock table, above any C-class SKU, and restocks to at least 90%.

Seasonality on top of the buffer

Manual beats auto

Each category has a season window and a coefficient. A manual coefficient set by the client always overrides the automatic hint. The hints come from last year's orders: weekly sums, 3-week smoothing, season = the segment above 50% of the peak.

Off-season floor in units

Out of season the speed formula is ignored. The category holds a fixed stock in units, distributed across SKUs by their share of orders over 90 days. No sales history at all: split evenly.

Planned exit deficit

In the closing window of the season the buffer ramps down linearly to a planned deficit. The season ends with empty shelves by design, not with a year of leftovers in stock.

Human in the loop

The system recommends. The person decides.

Auto-apply of buffer corrections ships OFF by default. The daily job only writes a recommendation into the row: a ±1/3 button with a tooltip explaining why. The manager clicks, the change is logged, the cooldown starts. That is Goldratt's own discipline: buffers adapt, humans approve.

Restock table: traffic-light buffer zones, TOP badges, DBM plus-minus one third button and a sticky supplier order block — The restock table: zone traffic lights on every SKU, TOP badges, the ±1/3 DBM button, sparklines with demand spikes over μ+2σ, and the sticky supplier order block on the right.

2,387lines in the TOC module

22REST endpoints

9dedicated tables

17tests on the rules: floor, cooldown, season across New Year

33/67one traffic light shared by buffers and alerts

04 Daily analytics

A pulse board for 763 SKUs and an economics dashboard that forecasts the month

The pulse board is the daily per-SKU control panel: sales funnel, ad economics, stock and prices, about 60 columns per SKU, virtualized so 763 rows scroll like silk. The dashboard answers the owner's question: how does the month end if we keep moving like this?

Pulse board

763 rows × ~60 columns with sticky SKU column and configurable traffic lights. A card mode for working by exception. Each SKU opens into a card: sales, ads, stock, prices and comments in 7 / 14 / 30-day windows.

Smart file import

The marketplace funnel export lands by drag-and-drop. Columns are matched by fuzzy mapping; a renamed column triggers a confirm dialog instead of a silent misread. Broken rows are rejected individually, never the whole file.

Cross-source reconciliation

TrueStats and marketplace revenue are compared daily. A gap over 5% raises a banner. In production this caught a real 13.31% mismatch on the first battle run.

Economics dashboard

Cabinet and category economics from file, API or both merged per SKU. A month-end forecast from the 15-day trend. Expense metrics invert their coloring: growing ad spend is red, not green. Response: 61 ms cached, 101 ms cold.

Adoption trick

Managers kept their Google spreadsheet

The backend renders showcase tabs into the familiar spreadsheet: main board, season view, distribution, price proposals, stock control, alerts. Writes are RAW only, so barcodes do not turn into 2.05E+12. Manual edits flow back by a diff-pull every 10 minutes, and the render never overwrites a human's cell. A button in the sheet posts new prices back through a token-checked webhook.

Pulse board: virtualized SKU table with traffic lights and card mode — The pulse board: card mode by default, full virtualized table one click away, traffic lights with thresholds the client tunes himself.

Economics dashboard with month-end forecast and category filters — The dashboard: cabinet economics, category breakdown, month-end forecast from the 15-day trend, filters recomputed on the fly.

~60columns per SKU on the pulse board

13.31%real data gap caught by reconciliation

61 / 101 msdashboard response, cached / cold

10 mindiff-pull cycle for manual sheet edits

05 Control loop

Seven alert types, and an ERP that tests itself every morning

Problems should find people, not wait to be found. Seven deterministic alert types watch the business; a health page with traffic lights watches the system itself.

Alert	Trigger	Detail
Urgent restock	≤100 units left on the marketplace	Always red, always pinned to the top of the feed.
Low sufficiency	coverage below threshold	Uses the same sufficiency contract as the restock table. One formula, one truth.
Orders drop	3-day speed vs 10-day speed, ≥30% down	Catches a dying SKU in days, not weeks.
Orders spike	3-day speed sharply up	A spike is a restock signal too: sell it while it flies.
Negative reviews	new 1-3 star reviews	Popup with the review texts, server-side pagination. 1,447 negatives were on file at acceptance.
Production start	<90 days of runway	Counts the 60-day production cycle backwards from the projected stockout, softened off-season.
Data mismatch	TrueStats vs WB gap >5%	The system distrusts its own inputs before it lets you trust its outputs.

Episode lifecycle

An alert is an episode: active, resolved, reactivated same-day if the condition returns. Zero duplicates by design. Acknowledgements are per user, so one manager's "seen" does not hide the problem from another.

Stale-data gate

If marketplace data is older than 24 hours, the whole alert recalculation is skipped. No alerts computed on stale data: silence is more honest than noise.

388 episodes on day one

The first production run surfaced 388 active alert episodes. That is the backlog of problems that used to be invisible. The feed sorted them; urgent restock came first.

Trust by construction

The client sees the tests, every day

A cron job re-runs every autotest, 1,286 backend and 440 frontend, every morning at 05:00 in a clean, separate database. The result lands in a table and shows on the Health page, next to traffic lights for containers, memory, disk and backup freshness. The ERP proves to its owner daily that it still works. Not a promise, a green light.

Health page with system traffic lights and daily autotest results — The Health page: container, memory, disk and backup traffic lights, plus this morning's autotest run, visible to the client.

7alert types, one 33/67 traffic light

388active episodes surfaced on day one

1,286+440autotests re-run daily at 05:00

5 minhost status refresh on the Health page

06 Revenue engineering

Set combinatorics: 1,813 sell paths computed in 3.0 seconds

Towels sell alone and in sets. The same raw item can go out a dozen ways, each with its own price per unit, margin and stock cap. The client used to hold this combinatorics in his head. Now the system computes it, and explains every suggestion in a "Why" column.

Stage 1: every existing path

For each raw towel: all its sell variants, single or inside any of 349 set recipes pulled from MoySklad tech cards. Per variant: price per unit, margin, cap by current stock, the limiting component, and a greedy allocation plan. 294 raw items × 349 recipes = 1,813 variants, computed in 3.0 seconds and verified by hand against SQL on production data.

Stage 2: new combinations

The client's merchandising rule, encoded: pink does not sell alone, but alongside grey it flies. The engine parses the model base from the article, pairs a top color with a slow mover (same base), crosses bases, and estimates the economics of each candidate from analogs.

The "Why" column

Every candidate carries a human-readable rationale: which color pulls, which stock it unfreezes, what the expected per-unit economics are. Optimization is deliberately greedy, not an LP solver: the client can follow every step, and trust beats the last percent of optimality.

Set combinatorics: variants per raw item and new combination candidates with a Why column — Set combinatorics: variants per raw item on one tab, generated candidates with the "Why" rationale on the other, plus a manual set constructor.

1,813variants in one run

3.0 sfull recomputation

294 × 349raw items × set recipes

100%of candidates explain themselves

07 Focus

ABC analysis: 134 SKUs hold 80.2% of the profit

A floating ABC classification by three criteria at once: profit, revenue and orders, with configurable 80/95 thresholds guarded by a database-level check.

The first production run put numbers on the intuition: class A is 134 SKUs, 17.6% of the catalog, holding 80.2% of the profit. The classes are cross-checked against the analytics service's own ABC, and SKUs that are loss-making or lack data are shown in explicit buckets with the reason broken down, not silently dropped.

Classes are computed once and served by contract: the pulse board and the restock table pull the letter without recomputing anything. The TOP rule of the restock table feeds on exactly these classes.

Why it matters for restock

An A-class SKU below 90% of its buffer jumps to the top of the supplier order, above any C-class SKU with a worse percentage. The business protects the 134 SKUs that pay for everything else. That priority is a tested rule, not a habit in someone's head.

134SKUs in class A

17.6%of the catalog...

80.2%...holding this share of profit

3criteria: profit, revenue, orders

08 Closing the loop

Producer order in one click. Honestly: checkboxes plus one button.

The buffer says what is missing. The order module says where to get it and by when, then produces the exact Excel file the producer in Uzbekistan expects.

Two-pass quantity. Q(L) = max(0, ceil(V_plan × (N + L) × 1.1 - total stock)). Pass one checks the producer's warehouse: enough there means mode "from stock", lead 14 days. Otherwise mode "production", lead 74 days (60 production + 10 delivery + domestic legs), with a note when part of the quantity is available now.
Urgency by thirds. Buffer coverage below 1/3: order now. Between 1/3 and 2/3: plan. Above 2/3: can wait. Production mode is scored one step stricter: a long leg leaves less room for error.
Checkboxes that survive. The manager ticks rows in a sticky order block; ticks and quantity overrides live in the database, not in the browser tab. Generating the order does not reset them; only an explicit reset button does.
One button, one file. "Create order" builds the Excel in the format agreed with the supplier: producer article from a mapping directory, color, mode, quantity, lead time, purchase cost, totals. Unmapped articles get a highlighted "not in directory" cell instead of a silent blank. The file downloads and lands in the order history with a full item snapshot.
Messy input, clean data. The producer's stock arrives as a semi-structured CSV from the labeling system. A tolerant regex parser rejects broken lines individually; unmatched articles become "create a rule" tasks in the UI, and the mapping directory is maintained by the client, not by the developer.

14 / 74days lead: from stock / from production

90%TOP rule floor for A-class SKUs

1click from ticked rows to the producer file

100%of orders kept in history with snapshots

09 FBS assembly

The marking code check moved to the moment of the scan

The warehouse packed orders by hand: the marketplace account, a pick list, Excel, a scanner into Excel, a manual replacement of hidden separators and an upload of the template back. The real loss of time started after that upload: the marketplace checks every code against the national traceability registry and rejects some of them, and people go looking for those items through the boxes. The module moves the check to the moment of the scan: the picker learns about a bad code while the item is still in their hands. The supplies themselves followed into the ERP: how they are built from the queue is the next section.

Supply screen: orders with statuses and the scanner panel with a verdict on the marking code — The supply page: on the left the orders with statuses and the matched row highlighted, on the right the scanner with a large photo of the item, the scan stages and the verdict on the code. The field always keeps focus: the picker holds a scanner and an item, not a mouse.

Verdict	What the picker sees and does next
Code accepted	green, the order is closed, the label goes to the printer
Accepted unchecked	yellow: the registry did not answer, the code is accepted by setting and rechecked at night
Owned by another company	put it aside, take another item
Already sold	the code has left circulation: put it aside, take another item
Not in circulation	the code was never put into circulation: send it to quarantine
Blocked	quarantine
Unknown to the registry	quarantine
Duplicate	red, with the number of the owning order: the label can be reprinted from there
Extra unit	every order of this size in the supply is already packed: the scanner names the product, the size and the time of the last pack, and asks to put the unit aside
Another product	the scanner names the product and the size and says where its orders wait: in this supply, in another batch or in another supply
Code not read	the code was read only in part: scan again. A cut code tail is never reported as a foreign code

The order of the checks matters. A foreign sold code has several reasons to fail, and the picker needs to hear one: the one they can act on.

One entry point instead of modes

The server classifies the input itself, barcode, marking code or label, and moves the state of the order. A person holding an item has nothing to switch modes with.

A repeat returns the saved answer

Every press carries its own identifier, and a repeated request returns the same answer instead of a recomputed one. Otherwise the picker would see "this code is already scanned" in response to their own scan.

The import does not undo the shift

A repeated import refreshes the marketplace fields and never touches ours: status, batch, scans and codes. The nightly run does not erase what people did.

Quarantine instead of a silent loss

An order with a bad code goes to quarantine with a reason rather than disappearing from the list. The warehouse lead sees how many orders are stuck and why.

The warehouse lead manages the staff

The module admin right allows adding and disabling pickers without the portal administrator. Disabling only, never deletion: scans and shift reports hang on the person.

The shift report

A shift is a day in Moscow time. Per employee it shows what was picked, which codes were accepted, what is done, how many problems, how many rejected scans, and the first and last scan. The rejected scan count opens a list: time, product, what was scanned and what the scanner answered.

A scanner without Enter

A scanner types its characters within milliseconds, so 300 ms of silence after something that looks like a finished code already means the end of input. The scan is caught anywhere on the page: a click on a tab or a button no longer swallows it.

Any keyboard layout

A scanner presses keys as if the layout were English, so with a Russian layout the code arrives in Cyrillic with the wrong symbols. The repair map runs in one pass and only when the string has Cyrillic in it: a dot and a comma are legal in a serial number.

The product card beats a learned link

A marking code finds its order by the order barcode first, then by the size barcode in the marketplace card, and only then by links learned on the warehouse floor. Whether a product needs a code is also taken from its card. An extra code request costs one scan, a missed one would ship the item without a code.

Silent degradation is unacceptable here. If the registry token dies, the module raises a system alert and keeps working in "accepted unchecked" mode, marking such codes honestly. It is exactly a silent failure that would cost the rejection at the marketplace this whole module exists to avoid.

FBS supplies list with a search across the whole history and a progress bar — The supplies list: one field searches by supply number, article, barcode, name, order and label across the whole history, and the matches show as lines under their supply.

Shift report: who packed how much and how many problems — The shift report with a total row: it tells the warehouse lead who packed how much today without getting anybody up from their desk. Rejected scans open as a list.

10 FBS supplies

A supply is built in the ERP, not with checkboxes in the account

Supplies used to be created in the marketplace account: checkboxes down the list of new orders from the top. One supply ended up with a hundred different articles, and the picker walked the whole warehouse with it. Orders from legal entities carry no mark in the account: you tick a hundred orders, the supply cannot be created, and you hunt for the one that blocks it. Now the queue lives in the ERP, and a supply is made of what is convenient to pick in one trip to the shelf.

FBS queue: a tree of categories, product cards and sizes with checkboxes and a selection bar — The FBS queue: a category, card and size tree for one warehouse. Selection works with category and tag chips, card checkboxes and single sizes. The bar at the bottom counts the selection and builds supplies from it.

One warehouse per queue. The marketplace does not mix warehouses in one supply, so the queue is locked to the chosen FBS warehouse. A consumer and business switch splits it in two: a supply always has one buyer type.
A suggested build. A table row is a future supply. An article with orders above the threshold gets its own supply: one article, one trip to the shelf. Small articles of a category are merged, the rest goes to other. Every row states the rule that formed it.
A human confirms. The suggestions only compute. A supply appears at the marketplace after the checkboxes and a confirmation window: how to split, how to name it, whether to hand it to the pickers at once as one batch. After creation the screen lists which orders did not make it and why.
Handover to delivery. First the marketplace answers whether it accepted the marking codes from the uploaded template. Handover is possible only when that check is fresher than 10 minutes and has no blockers. After the handover the ERP rereads the supply at the marketplace until it sees it closed.

The first exception to the read-only rule

Four write operations, each with a log line

Before this module the ERP wrote nothing into external systems. The exception is narrow: create a supply, add orders, set the shipping parameters and hand it over to delivery. Every write lands in a log with its request and response, visible on the supply tab. If the marketplace loses a supply, there is something to show its support. Marking codes still go through a template that a person uploads: that is an honest limit.

A rejected order is found by halving

Orders are added in batches of 100. If the marketplace rejects a batch, it is split in half until the exact rejected orders are found. They stay in the queue with a reason, the rest get through. One bad order does not bring the supply down.

The trace comes before the write

The supply row is saved right after the supply is created at the marketplace, before the orders are added. If anything fails later, the ERP knows about the empty supply and deletes it. A lock guards against a double click, and queue orders are locked so a parallel poll cannot move them.

One supply, one warehouse, one size class

The system splits a mixed selection itself: oversized goods apart, legal entities apart, and the plan row says so. Nobody has to remember the marketplace rules to avoid a rejection.

Disbanded in the account

If a supply is disbanded on the marketplace side, the ERP notices it on the next poll. Its orders return to the queue, what was packed stays packed, and an empty ERP supply is deleted.

A supply from the ERP is one batch

The scanner works by batch. Orders the marketplace moved to another supply detach themselves from the old batch on every poll, and a banner offers to merge batches if there are several after all.

Topping up an open supply

New orders of the same article can be added to an open supply from the selection bar or from the supply page. They join the same batch, and the picker carries on from where they were.

Hot orders: picking by urgency

Sometimes the warehouse has to pick by the age of an order rather than by product type. The account shows the oldest order, while the queue used to show neither a date nor an age. Now the queue has two tabs: the whole queue and hot orders. The hot tab carries a ladder of orders waiting longer than 20, 24, 36, 48 and 72 hours with counters, and the Waiting column shows the age of the oldest order: amber past the threshold, red past 48 hours.

The Hot tab: an age ladder of orders and a tree of urgent articles — The Hot tab: a ladder by order age, the threshold is edited right on the tab, and the tree is sorted from the oldest orders.

The create supplies window: split mode, supply names, order counts — The confirmation window: one supply, a supply per card or per category, editable names and a handover to the pickers as one batch.

The age filter lives on the server

The tree arrives already narrowed, so selection, the plan and supply creation know nothing about urgency and stay the same. Tick a category on the hot tab, and only the hot orders of that category go into the supply, while fresh ones stay in the queue.

A ladder instead of one button

At a 20 hour threshold half the queue is hot on a weekend. The manager takes the oldest with the 48 hour step rather than by editing a setting. The tab lives in the page address, so it can be shared as a link.

Ghosts do not burn

Orders the marketplace has already given a final status to, but still lists as new, are left out of the age count. Otherwise they would stay the oldest forever and hide the really urgent ones.

Supply page: marking code check at the marketplace and handover to delivery — The supply page: the marking code check at the marketplace, blockers as a red list, and the handover to delivery. Next to it, the WB log tab with every write, its request and response.

4marketplace writes, all logged

100orders per batch, halved on rejection

10 minshelf life of the code check

20-72 hladder of hot orders

11 Warehouse control

Pickers, suppliers and acceptance in numbers

Once supplies and scans live in the ERP, the owner gets answers to questions that used to be settled by eye: what a picker was busy with, which products cause scanner rejections, what is missing on the shelf, and how much of a supplier's goods the marketplace actually accepted.

Picker statistics

Up to four pickers work in parallel. The system has no shifts or quotas, so everything is counted from scans. Presence runs from the first to the last scan of the day. Active time adds up the pauses between neighbouring scans that are shorter than a threshold: 5, 10 or 15 minutes to choose from, anything longer is idle time, lunch or other work. Speed is pieces per active hour, load is active time over presence. Efficiency compares a person with the warehouse average for the same period in one number, and speed and load next to it explain why it is what it is. Only the owner sees the dynamics per person.

Warehouse load over a day: packed pieces per five minutes and scanner rejections — Load over a day: a bar is the pieces per five minutes for each person, a gap between bars means nobody was scanning. Rejections run as a separate row.

Reports do not disagree

The statistics for a day must match the shift report, and a test enforces it. There are no aggregate tables, everything is computed on the fly, and the migration added only indexes, built without locking the hot tables in the middle of a shift.

The product of a rejection, by its code

Two thirds of rejections have no order attached: the scanner refused earlier. So the product is recovered from the code itself, along the same chain the scanner uses. This shows which supplier products cause rejections, and that can be taken to the supplier.

Noise is cut off

An account with no packed piece and fewer than ten scans stays out of the statistics: it is a scanner check or a test login. Marked goods take longer to pack, and the screen says plainly that comparing people on different goods is approximate.

Supplier reorders in MoySklad

A picker used to spot missing stock by eye and by lunchtime wrote it into the supply name. The list went to the supplier, who spent a few more hours collecting it and delivered the next day: a day was lost, and a late pick hurts the seller rating. Now a button in the queue splits unpacked orders by supplier from the MoySklad product cards and creates a purchase order for each. Sets are broken into components by the tech card, packaging is not ordered. This is a different function from the producer order in section 08: that one follows the TOC buffer, this one follows concrete FBS orders.

Supplier orders window: one order per supplier, expanded products and warnings — Supplier orders: a separate order for every supplier, a row expands into its products, sets are already broken down. A warning on top lists products without a supplier: they go into no order until the card is fixed.

Every order is reordered once

100 were ordered, 7 more arrived, and the next order is for 7, not 107. A partial unique index in the database holds that. If an order is deleted or cancelled in MoySklad, its orders go back to be reordered: statuses are reconciled before every preview.

The request to MoySklad goes exactly once

A log row with an external code is saved before the request. On a dropped connection or a timeout the document is first looked up by that code, and only if it is not there are the orders released. Otherwise a retry would create a second purchase order.

The document stays unposted

The order is created unposted and warehouse stock is not deducted yet: people strike out the extra in MoySklad. That is a deliberate first iteration. After creation the document is reread and the number of lines and pieces is reconciled.

One token for the whole ERP

One MoySklad token serves the nightly sync and order creation, and only a superuser can change it. Product cards are read at the moment of the click: a manager fixes a supplier or a barcode during the day, and the button sees the fix at once.

Acceptance per supplier

Some suppliers work as fulfilment: they deliver goods to the marketplace warehouse themselves and get paid for what was accepted. 600 handed in, 599 accepted, 599 paid. The ledger shows how much of each supplier's goods went out in FBS supplies and how much of it was accepted, by acceptance date or by handover date, split by day and by product, with a separate tab for what was handed in and is still not accepted.

Supplier ledger: handed in, accepted by the marketplace and waiting per supplier — The supplier ledger: total cards for handed in, accepted, waiting and cancelled, and below them a split by day that expands into products with its own Excel export.

Accepted never rolls back

The supplier is fixed at the moment of handover, and the accepted mark is sticky. An order cancelled by the buyer after the supply was scanned in at the marketplace warehouse still counts as accepted: the supplier delivered, the warehouse received.

An imprecise date is marked as such

The acceptance date comes from the supply scan at the marketplace warehouse. Without a scan it is the moment the ERP saw the acceptance, marked as approximate and refined later.

A search over the whole history, no index

One field on the supplies screen searches by number, article, barcode, name, order and label in every supply, closed ones included. About 155 thousand orders are scanned in 150-270 ms as measured on the production database, so an index and a migration that locks a hot table mid-shift are not needed yet.

5 / 10 / 15min: idle pause threshold

1document type in MoySklad

30 minrefresh cycle of the acceptance ledger

200+76autotests of the FBS module

12 Warehouses

Exclusion is a date, not a checkbox

There was no warehouse register in the system: the warehouse name lived as a bare string inside the daily stock snapshots, and there was nothing to switch a warehouse off with. The client kept a noticeable share of goods in warehouses that no longer exist, while replenishment, turnover and the daily pulse counted those goods as live stock.

Warehouse register with roles, clusters and the exclusion date — The warehouse register: role, region, cluster, stock and whether it takes part in the calculations. At the top sits the share of stock held in excluded warehouses: before this register those goods counted as live.

A date, not a boolean

The client asked to state from which day a warehouse is off and to recompute the history from that day. Stock snapshots older than the date stay as they were: the past is not rewritten.

The log answers the "why"

Two fields on the warehouse row only answer "who switched it off right now". The client's question was a different one, and the history answers it: who, when, from which date and for what reason.

A row is written on the fact of a change

Saving the same values again adds nothing to the log. Otherwise in a week it fills with noise and stops answering the original question.

Protected rows

Pseudo-warehouses for goods in transit and the drop-off points cannot be excluded: they hold no stock, they mark its movement. An attempt to switch such a row off is rejected by the server, not only by a guard on the front end.

13 How it was built

Nineteen written specs, one pair of hands

Business analysis first. Every stage started as a self-contained written spec with data contracts, formulas and acceptance criteria. Implementation went step by step under iron rules written down after the previous ERP project. Each change lands as a small reviewable step.

Scope agreed. The client spec covered data sources, the five-warehouse stock table, the buffer logic, alerts, the pulse board and set combinatorics. Data contracts and acceptance criteria were pinned down before the first line of code.
All functional stages TZ-00 to TZ-10 were delivered: hardened infrastructure, portal with roles, three API syncs, pulse board, Google showcase, stock control with DBM, alerts, dashboard, sets, exports, ABC.
UI redesign. A dark collapsible sidebar, card mode, 10 themes on CSS tokens. The contrast of every theme is checked by a test, not by eye.
The warehouse became a product inside the ERP: FBS assembly with the scanner, supplies from the queue, urgent orders, picker statistics, supplier reorders and acceptance tracking. Every step started with a walk through the warehouse process and a written spec.
Acceptance is a document. A 630-line acceptance report, a requirements coverage matrix of 187 rows, and an honest section listing 18 shortcomings and deviations. Every claim in this case study traces to that report or to the repository.

Honest limits

What the system does not pretend to know

The automatic seasonal coefficient currently equals 1: the marketplace API keeps only about 6 rolling months of history, so year-over-year seasonality is physically unavailable. The system says "not enough history" and accumulates its own. The Google service key was not yet handed over at acceptance, so that module soft-skips instead of failing. Competitor parsing is coded but waits for a proxy. All three are written in the acceptance report, not discovered later.

Stack

PythonFastAPISQLAlchemy 2 asyncAlembic Celery + BeatPostgreSQL 16Redis 7 Docker Composenginx React 18TypeScriptViteTailwind Radix UIZustandTanStack Queryrecharts

Integrations

Wildberries APIMoySklad API TrueStats APIMarking registry APIGoogle Sheets API

Scale

110 database tables19 written specs ~70K lines of code1,286+440 autotests

14 Outcome

Before and after

Area	Before	After
Restock decisions	The owner's personal Excel, daily, by feel. Held on one person.	TOC buffers with traffic-light zones per SKU, self-correcting by ±1/3, every change confirmed by a human.
Data	Three services plus manual exports. No single picture.	One PostgreSQL, a nightly conveyor with freshness gates and idempotent imports.
Problem discovery	By eye, when someone happened to look.	7 alert types; 388 previously invisible episodes surfaced on day one, urgent restock always on top.
Month economics	Clear after the month ended.	A dashboard with a month-end forecast from the 15-day trend, in 61 ms.
Set planning	Combinatorics in the owner's head.	1,813 computed variants in 3.0 s, each new candidate with a written "Why".
Producer order	Assembled by hand for every order.	Checkboxes plus one button: the producer's exact Excel format, with history and snapshots.
FBS supplies	Checkboxes in the marketplace account from the top down, a hundred different articles in one supply.	A queue per warehouse and a suggested build: one article per supply, urgent orders first, handover to delivery from the ERP with a log.
Missing stock	By lunchtime a picker wrote what was missing into the supply name, and the list went to the supplier.	A purchase order in MoySklad straight from the FBS queue, sets split by the tech card, every order reordered only once.
Warehouse control	Who was busy with what and which products caused rejections was invisible.	Picker statistics from scans and acceptance per supplier: handed in, accepted by the marketplace, waiting.
Trust	"It should be working."	1,286+440 autotests re-run every morning in a clean database, result visible to the client on the Health page.

Kirill Sedov

Business analyst and systems builder. I start with the business process and the data contract, then automate. This ERP went from agreed spec to production, and it runs the client's restock on Goldratt's buffers instead of gut feel.

Connect on LinkedIn