Book conveyor

The challenge

Bookkeeping breaks the usual logic of e-commerce: goods have no batch and no re-delivery. One book is one unit, with its own fortune, its own price and its own set of photographs. Put it manually on three sites is to reprint the output data, find analogues, estimate the price, select the category and attributes, and after the sale do not forget to zero the rest on the other two marketplaces.

The project removes the whole routine. The operator takes a picture of the book – the system does everything else by itself and shows the person only what needs to be solved.

Seven stages of the conveyor

1. Reception and filming

   The party starts with one screen of mass creation: the article is assigned automatically, the photos are loaded with a pack. The role of the “photographer” is deliberately trimmed down to this single screen – the person on reception can’t break anything in the catalog.

   Blade + Alpine · loading and rotating images · Intervention Image

2. Photo recognition

   Vision-model reads the cover and output: title, author, publisher, ISBN, year, series, cover type, age rating. A separate passage checks the names typed caps - the model returns the correct register, but only if the text coincides with the original without taking into account the register and punctuation.

   Dimensions and weight are substituted according to size patterns: the model determines the class of the book, the template gives millimeters and grams suitable for a market place card.

   OpenAI Vision · drivers openai / mock · queue with heartbeat and auto restart

3. Search for analogues on sites

   Two separate Node services on Playwright search for Wildberries and Ozon with a real browser – with session cookies, proxy and health checks. Yandex Market is polled by API. The found cards are compared with the book by title, author and ISBN with a numerical assessment of similarity.

   Express + Playwright in individual containers · Shadowsocks proxy · timeouts and foulbacks

4. Valuation of price

   The price is considered according to the rules of the commodity expert, transferred to the code: only analogues with the same cover are taken into account, electronic publications are discarded, obvious emissions are cut off along the corridor of relations to the median, the minimum price tag is valid. The final sale price is displayed from the price tag at a discount, the author's autograph gives a markup.

   If the range of prices by analogues is too large, the AI arbitrator is connected: he selects the reference group and explains the decision with the text that the operator sees.

   Median and Average · Emission filter · Manual price protected from overwriting

5. Card and publication

   Description and hashtags are generated, the Ozon category is selected along with its mandatory attributes, payload is collected under the format of each site. Publishing is a background task with repeats, dry-run mode and human decoding of site errors instead of raw response code.

   A separate layer monitors duplicates: the same book will not go away with a second card, and the already sold Ozon card can be reused instead of creating a new one.

   Journal of publications with diagnosis · protection against duplicates · cross-publishing between sites

6. Orders

   Orders come in two ways - webhook sites and regular survey of offices. For each, a timeline of events is built, returns and confirmation of the return of goods to the warehouse are tracked.

   Webhooks Ozon / WB / YAM · Polling FBS · timeline and returns

7. Remains

   Unified warehouse accounting: the sale at any site is carried out by movement around the warehouse and immediately extinguishes the balance on the rest. An hourly snapshot of the outsynchron is collected — where the local residue has diverged from the marketplace — and it can be cured by mass synchronization from the interface.

   Warehouse movements with audit · unloading versions · protection against double write-off

Three venues, three different API

Each marketplace is connected by several cabinets, each has its own card format, its own warehouse model and its own moderation rules. The overall domain model is one, the differences are isolated in the site services.

What keeps the system on its feet

Most of the code is not written for the sake of a happy script, but for the sake of what happens after it: the site responded with a mistake, the task fell, the rest went apart, the dimensions did not pass moderation.

• Rassynchron detector - hourly snapshot of discrepancies between local residues and site data, with mass repair and publication of missing cards.
• Audit of dimensions Finds cards with incorrect HGH, builds a correction plan and applies it to the background task.
• Catalog parity - reconciliation of what was published on three platforms: deduplication of goods, search for "missing" cards, cross-publishing of missing ones.
• Health Pipeline Panel Shows books stuck between stages, allows you to restart recognition without going to the console.
• Backup Dump base on FTP every two hours during working hours, photos - once a day incrementally.
• Tests and defense of the battle base 302 tests on the domain logic of publishing, residues and orders; a separate guard does not allow running tests to go to the production base.

The result

A production system in which the operator deals only with what cannot be automated: evaluates the state of the book and confirms controversial decisions. Everything else – recognition, search for analogues, pricing, publication on three sites, taking orders and mixing balances – is on schedule and does not require daily intervention.

A brief description of this work in the portfolio