Склад и синхронизация с ERP

01Склады, уровни остатков и движения

Склад — это любое место, где хранится товар: центральный склад, филиал магазина, остатки поставщика для дропшиппинга. Уровень остатка — текущее количество одного варианта на одном складе. Ключевая идея в том, что это число никогда нельзя просто перезаписывать. Каждое изменение — это движение остатка: строка «+20 получено по заказу поставщику 118», «−2 продано в заказе 5531», «−1 брак», «+3 корректировка по инвентаризации». Уровень остатка — это сумма движений, закэшированная для скорости. Как банковская выписка, история движений объясняет каждое число, позволяет пересобрать уровни после бага и даёт отчёты: стоимость запасов, неликвиды, оборачиваемость. Инвентаризации сравнивают физический подсчёт с системой и создают корректирующие движения на разницу.

1CREATE TABLE stock_movements (
2  id            BIGSERIAL PRIMARY KEY,
3  variant_id    BIGINT NOT NULL,
4  warehouse_id  BIGINT NOT NULL,
5  quantity      INTEGER NOT NULL,          -- positive in, negative out
6  reason        TEXT NOT NULL,             -- sale, receipt, transfer_out, count, waste
7  reference     TEXT,                      -- order or purchase order id
8  created_by    BIGINT,
9  created_at    TIMESTAMPTZ NOT NULL DEFAULT now()
10);
11 
12-- Rebuild or verify cached levels from history
13SELECT variant_id, warehouse_id, SUM(quantity) AS on_hand
14FROM stock_movements
15GROUP BY variant_id, warehouse_id;

02Доступный остаток и резервы

«В наличии» (on hand) — это то, что физически лежит на складе. «Доступно» (available) — то, что вы ещё можете пообещать: наличие минус резерв. Резерв создаётся, когда заказ оформлен и оплачен (или пока оплата ожидается, со сроком истечения), и превращается в реальное исходящее движение, когда заказ собран и отправлен. Если заказ отменён или оплата не прошла, резерв освобождается. Витрина должна показывать доступный остаток, просуммированный по складам, которые могут обслужить покупателя. Правила исполнения выбирают источник: ближайший филиал, основной склад, поставщика, который отправляет напрямую, или backorder (продать сейчас, доставить после пополнения). Сделайте эти правила явными, потому что вопрос «какой склад это отправляет?» влияет на сроки доставки, стоимость и бухгалтерию.

03Перемещения, заказы поставщикам и поставщики

Перемещение переносит товар между складами в два шага: исходящее движение, когда товар уезжает, и входящее, когда он прибывает. В промежутке товар находится «в пути» и не принадлежит ни одной полке — смоделируйте это состояние, иначе остатки будто бы исчезают. Заказы поставщикам (purchase orders, PO) — это то, как товар попадает на склад: вы заказываете у поставщика, у PO есть ожидаемые количества и стоимость, а приёмки фиксируют, что реально пришло, — это может быть частичная поставка или отличаться от заказа. Каждая приёмка создаёт входящие движения и обновляет себестоимость, которая питает отчёты о марже и стоимости запасов. С хорошими данными можно генерировать рекомендации по дозаказу: средние дневные продажи, умноженные на срок поставки поставщика, плюс страховой запас — в сравнении с доступным и ожидаемым остатком.

• Статусы PO: черновик → отправлен → частично получен → получен → закрыт.
• Записывайте себестоимость единицы при приёмке; от неё зависит маржа.
• Отслеживайте качество работы поставщиков: опоздания и расхождения в количествах.

04Синхронизация с бухгалтерией и ERP

ERP (enterprise resource planning) или учётная система — это бэк-офис бизнеса: товары, цены, клиенты, счета и остатки для налоговых целей. Сначала определите владельца для каждого типа данных. Типичное разделение: ERP владеет кодами товаров, ценами и официальными остатками; магазин — описаниями, изображениями, SEO и онлайн-заказами. Затем синхронизируйте в направлении владения. Большинство API ERP медленные или ориентированы на пакетную обработку, поэтому синхронизируйте задачами по расписанию: забирайте изменённые цены и остатки каждые несколько минут, отправляйте новые заказы и возвраты по мере появления через очередь, а ночью запускайте полное сравнение. Делайте каждую задачу идемпотентной, сопоставляя записи по стабильным внешним ID, обрабатывайте данные пакетами и ведите лог синхронизации с количествами и ошибками. Дайте администраторам возможность включать и выключать отдельные задачи в настройках — это бесценно во время обслуживания ERP.

1// Laravel scheduler: each sync is a separate, non-overlapping job
2use Illuminate\Support\Facades\Schedule;
3 
4Schedule::job(new SyncPricesFromErp)->everyFiveMinutes()
5    ->withoutOverlapping()->when(fn () => settings('erp.sync_prices'));
6 
7Schedule::job(new SyncStockFromErp)->everyTenMinutes()
8    ->withoutOverlapping()->when(fn () => settings('erp.sync_stock'));
9 
10Schedule::job(new CompareCatalogueWithErp)->dailyAt('03:00')
11    ->withoutOverlapping();
12 
13Schedule::job(new CheckErpHealth)->everyFiveMinutes(); // alerts admins on failures

05Конфликты, health checks и страховочные сетки

Синхронизации ломаются тихо: ERP недоступна, код товара переименовали, импорт цен содержит ноль. Защищайтесь. Health checks отслеживают время последнего успешного запуска каждой задачи и поднимают алерт, если оно слишком давнее или резко вырос процент ошибок. Правила здравого смысла отклоняют подозрительные изменения — цена упала на 90%, все остатки стали нулевыми — и откладывают их на проверку. Сохраняйте предыдущие значения, чтобы администратор мог откатить неудачный импорт цен одним кликом. В конфликтах побеждает владелец: если поле изменили обе стороны, берите значение из системы-владельца и логируйте перезапись. Ночной отчёт сравнения перечисляет товары, которые есть только на одной стороне или отличаются, чтобы люди исправляли данные в источнике, а не латали магазин.

06Фискальные чеки

Во многих странах каждая продажа должна регистрироваться в налоговой через фискальное устройство или облачный сервис, который возвращает номер фискального чека (часто его печатают или показывают как QR-код). Для возвратов нужны собственные фискальные чеки возврата, связанные с исходным. Относитесь к этому как к платёжной интеграции: создайте запись чека со статусом, отправляйте её через очередь с повторами, храните фискальный номер в заказе и поднимайте алерты при сбоях. Повторяйте только тогда, когда это безопасно: если сервис мог зарегистрировать чек до таймаута, сначала проверьте, чтобы избежать дублей. Филиалам или кассам, которые могут работать офлайн, нужен офлайн-режим, который ставит чеки в очередь и отправляет их, когда связь вернётся, в пределах срока, разрешённого законом.

07Согласованность движений и закэшированных остатков

Движения — это история, а остатки — это кэш, поэтому они никогда не должны расходиться. Записывайте и то и другое в одной транзакции: вставляйте движение и обновляйте остаток условным запросом, который не может уйти в минус, если только не разрешён backorder. Порядок блокировок важен, когда одна операция затрагивает несколько строк, например перемещение или заказ из нескольких строк: всегда блокируйте строки в одном и том же порядке (например, по variant_id, затем по warehouse_id), чтобы избежать deadlock-ов. Держите ночную задачу проверки, которая суммирует движения по варианту и складу и сравнивает их с закэшированным остатком; любое расхождение — это баг, который нужно расследовать, а не молча исправлять. При большом объёме записей движения можно партиционировать по месяцам, а старые месяцы сворачивать во входящие остатки.

1BEGIN;
2-- 1. Decrease the cached level only if enough is available
3UPDATE stock_levels
4SET on_hand = on_hand - 3
5WHERE variant_id = 42 AND warehouse_id = 1 AND on_hand - reserved >= 3;
6-- 0 rows → ROLLBACK and report out of stock
7 
8-- 2. Record why it changed
9INSERT INTO stock_movements (variant_id, warehouse_id, quantity, reason, reference)
10VALUES (42, 1, -3, 'sale', 'order:5531');
11COMMIT;

08Оценка запасов и методы расчёта себестоимости

Запасы — это деньги на полках, поэтому финансисты спрашивают, сколько они стоят и какова себестоимость каждой продажи. Это зависит от метода расчёта себестоимости. Средневзвешенная себестоимость пересчитывает стоимость единицы при каждом поступлении: (старое количество × старая стоимость + поступившее количество × новая стоимость) / общее количество. Это просто и распространено в ERP. FIFO (first in, first out) предполагает, что первыми продаются самые старые единицы, поэтому каждая продажа расходует слои себестоимости начиная с самого старого поступления; нужны слои по каждому поступлению, зато растущие цены отражаются точно. Что бы вы ни выбрали, метод должен совпадать с ERP или учётной системой, иначе маржа в магазине и в бухгалтерии будет расходиться. Записывайте себестоимость в движение продажи в момент продажи — так же, как снимки цен в заказах, — чтобы последующие поступления не переписывали историческую маржу.

• Средневзвешенная: одна себестоимость на вариант и склад, обновляется при поступлении.
• FIFO: слои себестоимости по каждому поступлению, расходуются начиная со старейших.
• Возвраты приходуются по той себестоимости, с которой ушли, а не по сегодняшней.

09Паттерны интеграции: polling, события и outbox

Узнавать об изменениях в другой системе можно двумя способами: polling (по расписанию спрашивать «что изменилось с момента T?») и события (другая система присылает webhook-и или сообщения). Многие ERP поддерживают только polling. Опрашивайте с watermark — последним обработанным timestamp или ID изменения, — который хранится для каждой задачи, и слегка перекрывайте окно, чтобы пережить рассинхрон часов, полагаясь на идемпотентные upsert-ы, которые делают повторное чтение безвредным. Для данных, которые вы отправляете, используйте паттерн transactional outbox: в той же транзакции базы, что и заказ, вставляйте строку в таблицу outbox; воркер читает outbox и отправляет данные в ERP, повторяя попытки до подтверждения. Это гарантирует, что закоммиченный заказ рано или поздно будет выгружен, а откатившийся — никогда, и всё без распределённых транзакций.

1CREATE TABLE outbox (
2  id           BIGSERIAL PRIMARY KEY,
3  topic        TEXT NOT NULL,        -- erp.order_created, erp.return_created
4  payload      JSONB NOT NULL,
5  attempts     INT NOT NULL DEFAULT 0,
6  sent_at      TIMESTAMPTZ,
7  created_at   TIMESTAMPTZ NOT NULL DEFAULT now()
8);
9 
10-- Worker: claim a batch without blocking other workers
11SELECT id, topic, payload FROM outbox
12WHERE sent_at IS NULL
13ORDER BY id
14LIMIT 50
15FOR UPDATE SKIP LOCKED;

10Распределение по нескольким складам и раздельные отгрузки

При нескольких складах каждый заказ — это маленькая задача оптимизации: какие локации должны выполнить какие строки? Типичные правила по приоритету: если возможно, отгружать всё из одной локации (одна посылка дешевле), предпочитать локацию, ближайшую к покупателю, не опустошать выставочный запас филиала и использовать dropship от поставщика или backorder только в крайнем случае. Опишите правила как функцию оценки и записывайте решение в заказ, чтобы сотрудники склада и поддержка видели, почему выбрана именно эта локация. Раздельным отгрузкам нужны свои записи: один заказ, несколько отгрузок, у каждой — строки, трекинг и статус, а заказ становится доставленным только тогда, когда доставлены все отгрузки. Резервировать нужно по складам на этапе оформления, а не позже, иначе распределение может провалиться уже после того, как покупатель заплатил.