Когда у компании есть свой склад, продажи ограничивает не витрина, а рассинхронизация: сайт показывает одно, учёт содержит другое, сборка узнаёт о заказе последней. Мы проектируем контур, где остаток имеет один источник истины, а правила отгрузки и самовывоза заданы до запуска, а не выясняются на первых заказах.
Страница для компаний со своим складом или несколькими точками хранения. Если узнаёте несколько пунктов, задача сформулирована верно.
Наличие на сайте и фактический остаток на складе расходятся, и никто не может сказать, какая цифра верна.
Заказы на отсутствующий товар приходится отменять вручную, объясняясь с покупателем.
Товар хранится в нескольких местах, но сайт этого не различает.
Самовывоз есть, но покупатель не видит, в какой точке товар доступен именно сейчас.
Заказ попадает на сборку через мессенджер, письмо или устно.
Цены и наличие обновляются вручную, поэтому обновление происходит не тогда, когда меняются данные.
Если основная задача — регулярный обмен данными с учётной системой, точнее подойдёт страница про интеграцию с 1С
Основная проблема
Склад и сайт живут отдельно
Собственный склад — сильная сторона: товар физически есть, отгрузить можно быстро, самовывоз возможен в день заказа. Но эта сила реализуется только тогда, когда сайт знает о складе правду. Без единого источника остатка появляются два независимых представления о наличии, и расхождение между ними неизбежно — вопрос лишь в том, как быстро оно проявится.
Дальше проблема разветвляется. Заказ на отсутствующий товар приходится отменять, и цена этой отмены — не только возврат, но и доверие покупателя. При нескольких складах добавляется вопрос, откуда отгружать: разные точки дают разные сроки и стоимость доставки, а если сайт этого не учитывает, решение принимает человек уже после оформления. Самовывоз без данных по точкам превращается в обещание, которое приходится уточнять по телефону.
Мы решаем это как задачу проектирования, а не настройки. Сначала фиксируем, где находится мастер-источник остатка и по какому регламенту он обновляется. Затем описываем правила: как ведёт себя позиция с нулевым остатком, как выбирается точка отгрузки, что доступно к самовывозу и в каком виде заказ уходит на сборку. Только после этого начинается реализация — и проверка конфликтных сценариев до запуска, а не после.
Что происходит без изменений
Что следует из рассинхронизации
Только логические следствия из отсутствия единого источника данных. Мы не приводим выдуманных цифр потерь.
Заказы приходится отменять
Проданная позиция может отсутствовать физически, и отмену объясняет покупателю менеджер, а не система.
Наличию на сайте не доверяют внутри компании
Сотрудники перепроверяют остаток вручную перед подтверждением, и время обработки заказа растёт.
Самовывоз не работает как преимущество
Без данных по точкам покупателю нельзя обещать конкретное место получения, поэтому канал остаётся недоиспользованным.
Отгрузка выбирается вручную
При нескольких складах точку определяет человек после оформления, что удлиняет цикл и допускает неоптимальные решения.
Сборка узнаёт о заказе с задержкой
Передача через мессенджеры и письма означает потери заявок и отсутствие единой истории по заказу.
Цены обновляются не тогда, когда меняются
Ручной перенос данных привязывает актуальность прайса к графику сотрудника, а не к моменту изменения.
Что создаётся
Что создаётся
Результат — не просто магазин, а согласованный складской контур с зафиксированными правилами и проверенными сценариями.
Определённый мастер-источник остатка
Фиксируем документально, какая система является источником истины по остаткам и ценам, и что происходит при расхождении.
Снимает: Исчезает спор о том, какой цифре верить: правило задано до запуска.
Регламент обновления цен и наличия
Согласуем периодичность и способ обновления, поведение при недоступности источника и правила для позиций без данных.
Снимает: Актуальность перестаёт зависеть от того, вспомнил ли сотрудник обновить прайс.
Защита от продажи отсутствующего товара
Реализуем блокировку заказа при нулевом остатке, проверку доступности при оформлении и поведение при изменении остатка в момент покупки.
Снимает: Отмена заказа из-за отсутствия товара перестаёт быть регулярной ситуацией.
Модель нескольких складов и точек выдачи
Описываем структуру: склады, точки выдачи, что считается общим остатком, а что — наличием в конкретном месте.
Снимает: Сайт различает места хранения так же, как их различает компания.
Правила выбора точки отгрузки
Задаём приоритеты: близость к покупателю, полнота комплектации заказа из одного места, приоритет склада, поведение при разбиении заказа.
Снимает: Решение об отгрузке принимается по правилу, а не вручную после оформления.
Сценарий самовывоза
Реализуем выбор точки с учётом наличия, сроки готовности, условия хранения заказа и информирование покупателя.
Снимает: Самовывоз становится предсказуемым способом получения, а не поводом для звонка.
Передача заказа в учёт и на сборку
Настраиваем передачу заказа в согласованный приёмник — учётную систему, CRM или оба, с составом полей, нужным для сборки.
Снимает: Заказ доходит до склада в структурированном виде и с историей.
Набор проверяемых сценариев
Составляем перечень конфликтных ситуаций, которые проверяются до запуска, с описанием ожидаемого поведения.
Снимает: Проблемы обнаруживаются на тестах, а не на реальных покупателях.
Схема работы
Где решение работает в цепочке продаж
Центр этой услуги — звено «Склад» и всё, что от него зависит: доступность позиции, выбор точки отгрузки и способ получения.
ТрафикЛокальный и товарный спрос: наличие в городе, самовывоз рядом.Общий контур
КаталогОтображение наличия по складам и точкам, фильтрация по доступности.Зона этой услуги
Карточка товараНаличие, срок готовности, доступные точки самовывоза.Зона этой услуги
КорзинаПроверка доступности при оформлении и поведение при изменении остатка.Зона этой услуги
ОплатаПодключается по договору клиента; влияет на момент резервирования.Зависимость
СкладЯдро услуги: мастер-источник остатка, мультисклад, правила отгрузки.Зона этой услуги
ДоставкаВыбор точки отгрузки, зоны, самовывоз и передача на сборку.Зона этой услуги
CRMПриёмник заказов с составом полей, необходимым для сборки.Зависимость
Повторная продажаИстория заказов и наличие влияют на повторные покупки.Общий контур
Техническая настройка регулярного обмена с 1С или МойСклад описана на страницах интеграций; здесь фиксируются правила и модель данных.
Состав решения
Состав решения
Каждый модуль закрывает один из вопросов, которые обязательно возникают при работе магазина со складом.
01
Определение мастер-источника остатка
Входные данные
Перечень систем, где сейчас хранятся остатки: учёт, таблицы, складская программа, данные точек.
Работа
Определяем единственный источник истины, описываем приоритеты и поведение при расхождении данных.
Результат в системе
Документированное правило: какая система является источником остатков и цен.
Зависимость
Готовность клиента признать один источник главным и поддерживать его актуальность.
Проверка готовности
Клиент подтверждает источник; тестовое расхождение обрабатывается по описанному правилу.
02
Регламент обновления цен и наличия
Входные данные
Технические возможности источника, требуемая частота обновления, объём номенклатуры.
Работа
Согласуем периодичность, способ передачи, поведение при недоступности источника и правила для позиций без данных.
Результат в системе
Регламент обновления с понятным допустимым отставанием.
Зависимость
Доступность источника и стабильность формата данных на стороне клиента.
Проверка готовности
Изменение цены и остатка в источнике доходит до сайта в согласованный интервал.
03
Защита от продажи отсутствующего товара
Входные данные
Правила компании по нулевым остаткам, допустимость предзаказа, порядок резервирования.
Работа
Реализуем блокировку заказа, повторную проверку доступности при оформлении и поведение при изменении остатка в процессе покупки.
Результат в системе
Заказ отсутствующей позиции технически не оформляется.
Зависимость
Решение клиента о допустимости предзаказа и о моменте резервирования.
Проверка готовности
Контрольный сценарий: остаток обнуляется во время оформления — заказ не проходит, покупатель получает понятное сообщение.
04
Модель складов и точек выдачи
Входные данные
Перечень складов и точек, их роль, режим работы, доступность для покупателей.
Работа
Описываем структуру хранения, определяем, что показывать как общий остаток, а что — как наличие в конкретном месте.
Результат в системе
Схема мультисклада, соответствующая фактической логистике компании.
Зависимость
Полнота данных по точкам и наличие остатков в разрезе складов.
Проверка готовности
Наличие позиции корректно отображается по каждому складу и в сумме.
05
Правила выбора точки отгрузки
Входные данные
География доставки, приоритеты складов, допустимость разбиения заказа, стоимость отгрузки.
Работа
Задаём алгоритм выбора: близость к покупателю, полнота комплектации из одного места, приоритет склада, поведение при нехватке.
Результат в системе
Точка отгрузки определяется правилом, а не решением сотрудника.
Зависимость
Готовность клиента зафиксировать приоритеты и правила разбиения заказа.
Проверка готовности
Контрольные заказы из разных зон отгружаются с ожидаемых складов.
06
Самовывоз и готовность заказа
Входные данные
Адреса и режим работы точек, сроки подготовки, правила хранения готового заказа.
Работа
Реализуем выбор точки с учётом наличия, отображение срока готовности и информирование покупателя.
Результат в системе
Предсказуемый сценарий самовывоза без уточнений по телефону.
Зависимость
Актуальные данные о наличии в точках и дисциплина подготовки заказов.
Проверка готовности
Точка без наличия позиции недоступна для выбора; срок готовности отображается.
07
Передача заказа в учёт и на сборку
Входные данные
Схема обработки заказов, состав полей, необходимый для сборки, доступный приёмник данных.
Работа
Настраиваем передачу заказа в учётную систему, CRM или оба приёмника с полным составом полей.
Результат в системе
Заказ доходит до сборки структурированно, с историей и без ручного переноса.
Зависимость
Наличие приёмника данных и согласованный формат обмена.
Проверка готовности
Тестовый заказ полностью попадает в приёмник, поля сборки заполнены.
08
Проверяемые сценарии перед запуском
Входные данные
Перечень конфликтных ситуаций, реальные данные для тестов, доступ к приёмникам.
Работа
Составляем и прогоняем сценарии: нулевой остаток, изменение остатка при оформлении, заказ из нескольких складов, самовывоз без наличия, недоступность источника данных.
Результат в системе
Протокол проверок с ожидаемым и фактическим поведением.
Зависимость
Возможность тестировать на данных, близких к реальным.
Проверка готовности
Все сценарии из перечня отработаны, отклонения устранены или зафиксированы как принятые.
Сценарии использования
Типовые исходные ситуации
Обезличенные схемы. Аудитория страницы — компании, у которых есть собственный склад или несколько точек хранения.
Компания с одним складом и ручным обновлением наличия
Начинаем с мастер-источника и регламента обновления: до этого любые улучшения витрины не снимают расхождений.
Компания с несколькими складами в разных городах
Приоритет — модель мультисклада и правила выбора точки отгрузки, включая поведение при разбиении заказа.
Розница с точками выдачи и активным самовывозом
Строим наличие в разрезе точек и сценарий самовывоза со сроком готовности и правилами хранения заказа.
Компания, где заказы передаются на сборку вручную
Фокус на передаче заказа в учёт с полным составом полей, чтобы сборка перестала зависеть от переписки.
Компания, продающая и на сайте, и во внешних каналах
Согласуем общий остаток для нескольких каналов и регламент, исключающий двойную продажу одной позиции.
Интеграции и зависимости
Что участвует и где границы
Складской контур опирается на учётные системы клиента: сайт отражает их данные, но не заменяет их.
1С или МойСклад
Наиболее частый мастер-источник остатков, цен и номенклатуры.
Граница: Настройка регулярного обмена — отдельная услуга; здесь определяется роль источника и регламент.
Складской учёт и адресное хранение
Определяет фактическое наличие по складам и точкам.
Граница: Ведение учёта и корректность данных остаются полностью на стороне клиента.
CSV / YML и файлы клиента
Резервный способ передачи остатков и цен, когда прямой обмен недоступен.
Граница: Актуальность и достоверность файлов обеспечивает клиент.
CRM
Приёмник заказов и история обращений покупателей.
Граница: Выбор CRM за клиентом; мы настраиваем передачу данных с нужным составом полей.
Службы доставки и перевозчики
Отгрузка со складов и доставка до покупателя или ПВЗ.
Граница: Договоры, тарифы и фактическая логистика — зона клиента.
Платёжный оператор и онлайн-касса
Приём оплаты и фискализация; влияет на момент резервирования товара.
Граница: Договор, тарифы, касса и налоговый режим — зона клиента.
Этапы работы
Этапы работы
Порядок принципиален: правила остатка фиксируются до реализации витрины, иначе логику придётся переделывать.
01
Диагностика
Разбираем, где сейчас хранятся остатки, как они обновляются и где возникают расхождения.
02
Модель данных
Определяем мастер-источник, структуру складов и точек, состав передаваемых данных.
03
Правила
Фиксируем регламент обновления, поведение при нулевом остатке, приоритеты отгрузки и условия самовывоза.
04
Реализация
Собираем каталог с наличием по складам, корзину с проверкой доступности, выбор точки получения.
05
Передача заказов
Настраиваем передачу в учёт и CRM с полным составом полей для сборки.
06
Тестирование
Прогоняем перечень конфликтных сценариев на данных, близких к реальным.
07
Запуск
Открываем магазин с согласованным регламентом и протоколом проверок.
08
Наблюдение
Отслеживаем расхождения и отмены заказов, корректируем правила по фактическим данным.
Сроки заранее не фиксируем: они зависят от числа складов, состояния учётных данных, технических возможностей источника остатков и объёма номенклатуры.
Что проверяется при сдаче
Что проверяется при сдаче
Приёмка подтверждает не только работу витрины, но и корректность складской логики.
Мастер-источник остатков и цен зафиксирован документально и согласован с клиентом.
Регламент обновления описан, допустимое отставание данных известно и принято.
Позиция с нулевым остатком недоступна для заказа во всех точках входа: каталог, карточка, корзина.
Обнуление остатка во время оформления не позволяет завершить заказ, покупатель получает понятное сообщение.
Наличие корректно отображается по каждому складу и в суммарном виде.
Контрольные заказы из разных зон отгружаются с ожидаемых складов согласно правилам приоритета.
Точка самовывоза без наличия позиции недоступна для выбора, срок готовности отображается.
Тестовый заказ полностью попадает в согласованный приёмник, поля для сборки заполнены.
Поведение при недоступности источника данных проверено и не приводит к продаже отсутствующего товара.
Перечень конфликтных сценариев отработан, результаты зафиксированы в протоколе.
Изображения в формате WebP, имеют alt и заданные размеры, сдвига вёрстки при загрузке нет.
Нет пустых или ведущих в никуда ссылок в перелинковке раздела.
Нет горизонтальной прокрутки на 1440, 1280, 1024, 768, 390 и 360 px.
Кому подходит
Кому подходит
Компании со своим складом или несколькими точками хранения
Решение имеет смысл при таких исходных данных
Товар физически хранится у вас, а не только у поставщика.
Есть система или файл, где остатки ведутся и могут быть источником данных.
Есть готовность признать один источник остатков главным и поддерживать его.
Есть понимание, какие точки доступны покупателям для получения заказа.
Есть ресурс на сборку и отгрузку заказов с сайта.
Есть готовность зафиксировать правила приоритета отгрузки, а не решать каждый случай вручную.
Когда нужен другой формат
Когда точнее подойдёт другая страница
Мы указываем это прямо, чтобы вы не платили за более широкий объём работ, чем нужно.
Основная задача — настроить регулярный обмен с учётной системой.
Определение мастер-источника остатков и документирование правил приоритета.
Проектирование модели складов, точек выдачи и структуры передаваемых данных.
Реализация защиты от продажи отсутствующего товара во всех точках оформления.
Алгоритм выбора точки отгрузки и сценарий самовывоза с отображением готовности.
Настройка передачи заказов в учёт и CRM с составом полей для сборки.
Составление и прогон перечня конфликтных сценариев, протокол проверок.
Клиент
Актуальные остатки в источнике данных и дисциплина их обновления.
Перечень складов и точек выдачи, их режим работы и роль в логистике.
Решения по приоритетам отгрузки, разбиению заказов и допустимости предзаказа.
Договоры с перевозчиками, платёжным оператором и решение по онлайн-кассе.
Сборка, упаковка и фактическая отгрузка заказов, подготовка заказов к самовывозу.
Доступы к учётной системе и CRM для настройки передачи данных.
Стоимость
Что влияет на оценку
Стоимость определяется сложностью складской логики, а не количеством товаров в каталоге.
Число складов и точек выдачи
Каждая дополнительная точка добавляет данные, правила приоритета и сценарии для проверки.
Состояние источника остатков
Готовый и стабильный источник данных требует меньше работы, чем разрозненные таблицы и ручные списки.
Строгость требований к синхронности
Чем меньше допустимое отставание данных, тем больше работы по регламенту, обработке сбоев и проверкам.
Правила разбиения заказа
Отгрузка одного заказа с нескольких складов усложняет алгоритм, отображение и передачу в учёт.
Сценарий самовывоза
Наличие в разрезе точек, сроки готовности и правила хранения заказа оцениваются отдельно.
Состав передачи в учёт
Объём полей и требования учётной системы к формату заказа влияют на трудоёмкость настройки.
Расчёт формируем после диагностики складского контура: именно она показывает, где данные готовы, а где их предстоит привести в порядок. Ценовая лестница интернет-магазинов на странице цен на эту услугу автоматически не переносится.
Вопросы и ответы
Вопросы о работе со складом
Там, где остаток меняется физически и где за него отвечает конкретный процесс — как правило, в учётной или складской системе. Сайт мастер-источником быть не должен: он не знает о приёмке, списаниях, инвентаризации и продажах в других каналах. Если сейчас источников несколько, мы выбираем один и описываем, что делать при расхождении с остальными.
Частота определяется техническими возможностями источника и оборачиваемостью товара. Мы не заявляем «мгновенно» — вместо этого фиксируем допустимое отставание данных и правило поведения на этот интервал. Для быстро расходящихся позиций дополнительно закладывается повторная проверка доступности в момент оформления.
Это отдельный проверяемый сценарий. Доступность перепроверяется при оформлении: если остатка уже нет, заказ не завершается, а покупатель получает понятное сообщение и варианты — другая точка, другой вариант товара или уведомление о поступлении. Молча оформить заказ и отменить его потом система не должна.
Мы описываем структуру хранения и решаем, что показывать покупателю: суммарное наличие или наличие в конкретном месте. Оба варианта корректны, но подходят разным моделям. Для самовывоза почти всегда нужен разрез по точкам, для доставки часто достаточно общего остатка с правилом выбора склада отгрузки.
По зафиксированному алгоритму приоритетов: близость к покупателю, возможность собрать заказ целиком из одного места, приоритет конкретного склада, стоимость отгрузки. Отдельно описывается поведение, когда ни один склад не покрывает заказ полностью: разбиение на отгрузки, частичная отгрузка или предложение альтернативы. Без этого правила решение каждый раз принимает человек.
Можно, но это требует регламента и признания рисков. Общий остаток означает вероятность двойной продажи в интервале между обновлениями. Обычно применяют резервирование части остатка под каждый канал или сокращают интервал обновления для быстро расходящихся позиций. Решение принимает клиент, а мы описываем последствия каждого варианта.
Нет. Сайт — канал продаж, а не система учёта. Он отображает данные согласованного источника, защищает от продажи отсутствующего товара и передаёт заказ на сборку. Приёмка, списания, инвентаризация и адресное хранение остаются в учётной системе клиента.
Перечень согласуется заранее и обязательно включает: заказ позиции с нулевым остатком, обнуление остатка в момент оформления, заказ из нескольких складов, выбор точки самовывоза без наличия, недоступность источника данных, полноту передачи заказа в приёмник. По каждому сценарию фиксируется ожидаемое и фактическое поведение.
Следующий шаг
Спроектируем логистику магазина
Напишите, где сейчас ведутся остатки, сколько у вас складов и точек выдачи и нужен ли самовывоз. Предложим модель данных и перечень сценариев для проверки.
