Товары под заказ и срок поставки в каталоге Битрикс

Покупатель нашёл нужную позицию, а рядом с ценой — сухое «Нет в наличии». Кнопка заказа неактивна, человек уходит к конкуренту, хотя тот же товар вы спокойно привезли бы за неделю от поставщика. Так магазин теряет продажи не потому, что товара нет, а потому, что в каталоге не настроен статус «под заказ» и не показан срок поставки. В 1С-Битрикс это решается штатными средствами — свойствами каталога, статусами заказа и правилами резерва, — но настроить их нужно так, чтобы остатки не врали, а оплата и обязательства перед покупателем оставались корректными.

Ниже — практическая настройка товаров под заказ с нуля: как построить модель статусов наличия, где хранить срок поставки, как связать предзаказ с резервом и оплатой и как не сломать доступность в каталоге при обмене с 1С. Это выжимка из наших проектов по разработке интернет-магазинов на 1С-Битрикс — с конкретикой по компонентам, свойствам и админке, без общих слов.

Зачем нужен статус «под заказ» и что он даёт бизнесу

Ассортимент магазина почти никогда не совпадает со складским остатком один в один. Часть товаров лежит на своём складе, часть — на транзитном или у поставщика, а часть вообще возится под конкретный заказ. Если каталог умеет показывать только «есть» и «нет», то вся «серая зона» между этими состояниями превращается в потерянные продажи: позиция, которую можно привезти за три дня, выглядит для покупателя точно так же, как снятая с производства.

Статус «под заказ» закрывает именно эту зону. Он говорит покупателю: товара нет на складе прямо сейчас, но магазин готов его поставить за известный срок, и заказ можно оформить. Для бизнеса это даёт сразу несколько эффектов, которые прямо влияют на выручку и на управляемость каталога.

• Расширение продаваемого ассортимента. Можно продавать позиции, которые нет смысла держать на складе: дорогие, редкие, крупногабаритные, сезонные. Витрина показывает весь каталог поставщика, а закупка идёт под подтверждённый спрос.
• Сокращение замороженных денег в остатках. Товар закупается под заказ, а не «на всякий случай». Меньше неликвида, меньше складских расходов, выше оборачиваемость.
• Честная коммуникация со сроком. Покупатель заранее видит дату получения и принимает решение осознанно. Это снижает отмены и претензии по сравнению с ситуацией, когда срок «всплывает» уже после оплаты.
• Данные о спросе. Заказы под заказ — это прямой сигнал, какие позиции стоит завести на склад. Аналитика предзаказов помогает планировать закупку.

Важно понимать, что «под заказ» — это не технический флажок, а бизнес-процесс. За статусом на витрине должны стоять реальные договорённости с поставщиком, реалистичный срок и регламент действий менеджера, если что-то пошло не так. Техническая настройка в 1С-Битрикс лишь оформляет этот процесс так, чтобы он работал без ручного героизма. Дальше разберём его по слоям — от модели статусов до жизненного цикла заказа.

Модель статусов наличия в каталоге

Прежде чем настраивать что-либо в админке, нужно спроектировать саму модель наличия. Ошибка большинства магазинов в том, что они мыслят двумя состояниями, тогда как реальному складу и реальным поставкам нужно как минимум четыре-пять. Чем точнее модель, тем корректнее ведут себя каталог, фильтр по наличию и логика заказа.

Базовый набор состояний, который закрывает большинство сценариев розницы и B2B:

Ключевая мысль: три из пяти состояний — продающие. Из них два («под заказ» и «ожидается поступление») отличаются наличием точной даты. «Под заказ» — срок расчётный, привязан к циклу поставки от поставщика; «ожидается поступление» — срок конкретный, потому что товар уже заказан и есть дата прихода. Для витрины разница в формулировке: «Привезём за 7–10 дней» против «Поступит 15 июля».

Модель наличия должна быть единой для всего проекта: каталог, карточка товара, корзина, оформление заказа и уведомления обязаны понимать статусы одинаково. Если каталог считает позицию «под заказ», а корзина — «нет в наличии», покупатель упрётся в противоречие и уйдёт. Поэтому статус наличия — это не текст на карточке, а вычисляемое значение, единое по всей системе. Тонкости логики самих статусов и связку с предзаказом мы отдельно разбирали в материале про наличие, статусы и предзаказ в Битрикс — там акцент на самой модели состояний, здесь — на сроках и поставке.

Из чего складывается срок поставки

Срок поставки на витрине — это не одно число, а сумма нескольких этапов. Если показывать покупателю только «срок от поставщика», реальная дата получения окажется больше, и вы получите претензии. Честный расчётный срок собирается из цепочки:

• Срок обработки заказа. Время от оплаты до передачи заявки поставщику: подтверждение, комплектация, оформление закупки. Обычно 1–2 рабочих дня.
• Срок поставки от поставщика. Сколько идёт товар от поставщика на ваш склад. Зависит от логистики и того, есть ли позиция у поставщика в наличии.
• Срок приёмки и обработки на складе. Оприходование, проверка, подготовка к отгрузке покупателю. Обычно 1 день.
• Срок доставки покупателю. Курьер, ПВЗ, транспортная компания — уже стандартная логистика магазина.

На карточке имеет смысл показывать честную суммарную дату «получите примерно к…», а не голый срок закупки. При этом внутри системы храните составляющие отдельно: так проще пересчитывать сроки при смене поставщика и анализировать, где именно теряется время. Рабочие дни считайте с учётом производственного календаря — иначе субботние и праздничные дни исказят обещанную дату.

Отдельный вопрос — как показывать срок: диапазоном («7–10 дней»), точной датой («до 15 июля») или обоими способами. Диапазон честнее для товаров под заказ, где есть неопределённость; точная дата уместна, когда поставка уже в пути. Хорошая практика — хранить срок в днях как число, а на витрине рендерить его в дату, прибавляя рабочие дни к текущей. Тогда покупатель видит конкретный день недели, а не абстрактный интервал, и вам не нужно вручную обновлять формулировки.

Архитектура: где хранить статус и срок в Битрикс

Чтобы настраивать «под заказ» осознанно, полезно держать в голове, из каких слоёв 1С-Битрикс складывается вся конструкция. Это не один параметр, а несколько сущностей, каждая со своей ролью.

• Остатки и модуль торгового каталога. Хранят физические остатки по складам и доступное количество. Именно на их основе вычисляется базовое наличие.
• Свойства инфоблока каталога. Хранят «продуктовые» атрибуты позиции: срок поставки, поставщика, флаг «под заказ», признак «возится всегда».
• Вычисляемый статус наличия. Логика, которая на основе остатков, свойств и настроек решает, какой статус показать: «в наличии», «под заказ», «ожидается», «нет».
• Статусы заказа. Отдельная линейка состояний в модуле «Продажи»: «предзаказ», «ожидает поставки», «товар на складе», «готов к отгрузке».
• Резерв. Механизм резервирования модуля торгового каталога: для складских позиций уменьшает доступный остаток, для «под заказ» работает иначе.
• Обмен с 1С. Канал, по которому приходят актуальные остатки, сроки и данные о поставщиках; он же должен пересчитывать статусы.

Логика связывает эти слои так: остатки и свойства дают на вход вычислителю наличия, тот выставляет статус на карточке и в каталоге, а при оформлении заказ получает соответствующую линейку состояний и правило резерва. Понимание слоёв сразу подсказывает, где искать ошибку: если статус на карточке неверный — смотрим остатки и вычислитель, если заказ «завис» — смотрим статусы заказа, если после обмена всё «поехало» — смотрим настройку обмена с 1С.

Предзаказ, резерв и оплата: три разные сущности

Самая частая путаница при внедрении «под заказ» — смешивание трёх понятий, которые кажутся одним. Их нужно строго различать, потому что живут они в разных модулях и подчиняются разной логике.

Предзаказ — это факт оформления заказа на позицию, которой пока нет на складе. Это бизнес-обязательство: покупатель хочет товар, магазин обязуется поставить. Технически предзаказ — это обычный заказ в 1С-Битрикс с особым статусом и признаком, что позиция едет от поставщика.

Резерв — это удержание конкретной единицы товара за конкретным заказом на складе. Классический резерв уменьшает доступный остаток: если на складе 5 штук и 2 в резерве, каталог показывает доступными 3. Для товара под заказ физического остатка нет, поэтому обычный резерв к нему неприменим — резервировать нечего. Реальный резерв включается только в момент, когда товар приходит на склад.

Оплата — это движение денег, отдельное от наличия товара. Можно взять предоплату за позицию, которой ещё нет; можно, наоборот, оформить предзаказ без оплаты и взять деньги по факту готовности. Оплата — атрибут заказа, а не наличия, и настраивается независимо.

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

Настройка статусов и сроков пошагово

1. Спроектируйте модель наличия. Зафиксируйте набор статусов (в наличии, мало, под заказ, ожидается, нет) и правило, по которому статус вычисляется из остатка и свойств. Это делается до любых настроек в админке.
2. Заведите свойства каталога. Добавьте в инфоблок свойства «Срок поставки» (число дней или привязка к справочнику), «Флаг под заказ» (Да/Нет), «Поставщик» и при необходимости «Возится всегда». Именно они питают вычислитель статуса.
3. Настройте правило продажи при нулевом остатке. В модуле торгового каталога включите возможность продажи товара при отсутствии на складе для тех позиций, что помечены «под заказ». Без этого корзина не даст оформить заказ.
4. Создайте статусы заказа. В модуле «Продажи» добавьте статусы «Предзаказ», «Ожидает поставки», «Товар на складе», «Готов к отгрузке» и опишите переходы между ними.
5. Опишите правило резерва. Для складских позиций — обычный резерв, для «под заказ» — виртуальный, который включает реальное резервирование при поступлении товара на склад.
6. Настройте вывод на витрине. В шаблоне карточки и каталога выведите статус наличия и расчётную дату поставки, добавьте статус в фильтр по наличию.
7. Свяжите с обменом 1С. Настройте, чтобы обмен приносил остатки, сроки и поставщиков и пересчитывал статусы после каждой загрузки.
8. Проверьте на боевых сценариях. Прогоните заказ под заказ от оформления до поступления и отгрузки, проверьте, что остатки не уходят в минус и уведомления доходят.

Как это выглядит в админке 1С-Битрикс

Настройки товара под заказ распределены между свойствами инфоблока, карточкой товара торгового каталога и модулем «Продажи». На уровне карточки товара это выглядит как связка «остаток + свойства наличия», которую видит менеджер:

Обратите внимание на связку: остаток равен нулю, но продажа не заблокирована, потому что стоит флаг «под заказ» и включена продажа при отсутствии на складе. Срок поставки и поставщик заданы свойствами, а витрина рендерит из них конкретную дату. На стороне модуля «Продажи» этот заказ пойдёт по отдельной линейке статусов — от «Предзаказ» до «Готов к отгрузке».

Свойства товара для срока и поставщика

Правильно спроектированные свойства инфоблока — половина успеха. Они должны быть машиночитаемыми (чтобы по ним считать и сортировать) и при этом легко заполняться при обмене с 1С. Минимальный набор для товаров под заказ:

Почему срок лучше держать числом, а не строкой. Число легко превратить в дату, отсортировать каталог по скорости поставки, отфильтровать «привезём за неделю» и пересчитать при смене поставщика. Строка «7–10 дней» для человека понятна, но для системы бесполезна — по ней нельзя считать. Оптимальный компромисс: храните минимальный и максимальный срок в днях как два числа, а формулировку для витрины собирайте на лету. Если нужны единообразные тексты («экспресс», «стандарт», «под заказ»), заведите отдельный справочник статусов и привязку к нему, но дату всё равно считайте по числовому сроку.

Поставщика имеет смысл выносить в highload-блок: единый справочник поставщиков со сроками по умолчанию, приоритетом и данными для закупки. Тогда у товара хранится лишь привязка, а сроки и приоритеты редактируются централизованно. Это особенно удобно, когда у одной позиции несколько источников поставки — логика выбора берёт поставщика с минимальным сроком или наивысшим приоритетом и подставляет его срок в расчёт.

Обмен с 1С и актуализация сроков

Каталог под заказ живёт ровно настолько корректно, насколько актуальны данные, которые приходят из учётной системы. Обмен с 1С должен приносить не только цены и остатки, но и сроки поставки, поставщиков и признаки «под заказ», а после загрузки — пересчитывать статусы наличия.

Типовые проблемы обмена, которые ломают товары под заказ:

• Остаток перезаписывается, статус — нет. Обмен обновил количество, но не пересчитал вычисляемый статус наличия. Позиция с нулём остатка и флагом «под заказ» показывается как «нет в наличии». Лечится пересчётом статусов после каждой загрузки.
• Срок не приходит из 1С. В учётной системе срок есть, но не выгружается в свойство каталога. Витрина показывает «под заказ» без даты, что снижает конверсию. Нужно добавить срок в правила обмена.
• Флаг «под заказ» слетает при полной выгрузке. Полный обмен перезаписывает свойства, и ручные пометки теряются. Признак «под заказ» должен приходить из 1С как часть данных о номенклатуре, а не выставляться руками.
• Гонка обмена и заказов. Обмен идёт долго и во время загрузки остатки «мигают». Покупатель может оформить заказ на позицию, которую обмен в этот момент обнуляет. Помогает загрузка в неблокирующем режиме и корректная работа с очередями.

Частота и техника обновления остатков и сроков — отдельная большая тема. Если каталог большой и данные меняются часто, обмен файлами по расписанию перестаёт справляться и на смену приходит обновление по API и очередям. Подробно этот механизм и то, как обновлять цены и остатки без блокировок и тормозов каталога, мы разбираем в материале про обновление цен и остатков по API — для товаров под заказ он особенно важен, потому что устаревший срок хуже отсутствующего.

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

Оплата предзаказа: полная, частичная, постоплата

Оплата товара под заказ — это баланс между интересами магазина (не закупать позицию за свой счёт без гарантии) и покупателя (не отдавать полную сумму за товар, которого ещё нет). В 1С-Битрикс поддерживаются все три сценария, выбор зависит от товара, суммы и доверия к покупателю.

Технически модель оплаты реализуется через статусы оплаты заказа, которые независимы от статусов наличия и поставки. Заказ под заказ может быть «оплачен полностью» и одновременно «ожидает поставки» — это нормальное состояние. Для частичной оплаты в 1С-Битрикс удобно использовать разбиение заказа на несколько платежей: первый — аванс при оформлении, второй — доплата, которую система запрашивает при переходе заказа в статус «Товар на складе».

Отдельно проработайте условия возврата аванса. Если срок поставки сорвётся или поставщик подведёт, покупатель должен иметь понятный механизм вернуть предоплату. Это не только требование добросовестности, но и способ снять большинство споров: когда правила возврата прозрачны и озвучены до оплаты, конфликтов почти не возникает. На витрине рядом с кнопкой предзаказа стоит явно указать модель оплаты и условия возврата — это повышает доверие и конверсию.

Резервирование под заказ и склад

Резерв — самое тонкое место в товарах под заказ, потому что классический механизм резервирования рассчитан на существующий остаток. Разберём, как правильно организовать резерв для позиции, которой на складе пока нет.

Для складского товара всё привычно: при оформлении заказа система резервирует нужное количество, доступный остаток уменьшается, а каталог показывает актуальную доступность. Резерв снимается при отгрузке или отмене заказа. Здесь важно лишь корректно настроить срок резерва, чтобы «зависшие» неоплаченные заказы не держали товар вечно.

Для товара под заказ резервировать нечего — физического остатка нет. Здесь работает другая логика:

1. Оформление предзаказа. Заказ фиксирует обязательство. Реального резерва на складе нет, потому что нет товара. Заказ получает статус «Предзаказ» и «Ожидает поставки».
2. Закупка у поставщика. Менеджер (или автоматика) формирует заказ поставщику на нужное количество под собранные предзаказы. Это движение в учётной системе, а не резерв в каталоге.
3. Поступление на склад. Товар приходит, оприходуется, остаток становится положительным. В этот момент срабатывает «виртуальный резерв»: система привязывает поступившие единицы к конкретным предзаказам и делает уже реальный резерв.
4. Готовность к отгрузке. Заказ переходит в статус «Товар на складе» / «Готов к отгрузке», покупатель получает уведомление, при частичной оплате запрашивается доплата.
5. Отгрузка. Реальный резерв снимается отгрузкой, остаток уменьшается штатно.

Ключевой принцип: доступный остаток в каталоге не должен уходить в минус из-за предзаказов. Предзаказы копятся как обязательства отдельно от складского остатка, а превращаются в реальный резерв только после поступления. Если этого разделения нет, вы получите классический баг — «минус три штуки на складе» и хаос в доступности. Связку резерва с самовывозом и удержанием товара за клиентом мы подробно разбираем в статье про самовывоз и резервирование в Битрикс — там про сроки хранения резерва и точку выдачи, здесь — про резерв под поставку.

Отображение сроков на витрине

Даже идеально настроенная логика бесполезна, если покупатель не понимает, что видит. Отображение статуса и срока — это UX-задача, от которой напрямую зависит конверсия предзаказов. Несколько правил, проверенных на проектах.

• Статус — заметным бейджем, а не мелким текстом. «Под заказ» и «ожидается» должны читаться сразу, цветом отличаться от «в наличии», но не выглядеть как ошибка или запрет.
• Срок — конкретной датой, а не только интервалом. «Получите до 15 июля» работает лучше, чем «7–10 дней»: покупатель видит понятный ориентир и не считает дни в уме.
• Кнопка — продающая. Для товара под заказ вместо «В корзину» уместно «Заказать» или «Оформить предзаказ», чтобы намерение было явным, а ожидание — правильным.
• Условия — рядом с кнопкой. Модель оплаты, возможность возврата аванса, ориентир по сроку — коротко и на виду, чтобы не пришлось искать.
• Фильтр по наличию. Добавьте статус в фильтр каталога: кто-то ищет только «в наличии сейчас», а кто-то готов ждать под заказ. Дайте выбрать.

В каталоге (в списке товаров) статус и срок тоже нужны — покупатель принимает решение ещё до захода в карточку. Здесь достаточно бейджа статуса и короткого срока; подробности оплаты и возврата раскрываются уже в карточке. Важно, чтобы статус в списке, карточке и корзине совпадал: расхождение подрывает доверие сильнее, чем отсутствие срока вообще.

Уведомления о смене статуса и сроков

Товар под заказ — это заказ с длинным жизненным циклом, и покупатель всё это время находится в неведении, если его не информировать. Автоматические уведомления на ключевых переходах статуса снимают основную нагрузку с поддержки и удерживают клиента от отмены «из-за тишины».

Минимальный набор триггерных сообщений для заказа под заказ:

• Предзаказ принят. Подтверждение оформления с указанием расчётного срока и модели оплаты.
• Заказ передан поставщику. Опционально, но повышает доверие: клиент видит, что процесс идёт.
• Товар поступил на склад. Ключевое сообщение: позиция пришла, при частичной оплате — запрос доплаты, приглашение подтвердить доставку.
• Готов к отгрузке / передан в доставку. Стандартное уведомление логистики.
• Срок изменился. Если поставка сдвинулась — новая расчётная дата и предложение выбора: ждать, заменить, вернуть аванс.

Последний пункт критичен. Сорванный срок — главный источник негатива по товарам под заказ, и разница между «клиент узнал сам, позвонив в поддержку» и «система заранее прислала новую дату с вариантами» огромна. В 1С-Битрикс это реализуется через привязку почтовых и мессенджер-уведомлений к переходам статуса заказа: смена даты поставки триггерит письмо или сообщение автоматически. Менеджеру при этом нужен отдельный фильтр «просроченные поставки», чтобы держать проблемные заказы на контроле.

Жизненный цикл заказа под заказ

Сведём всё в единый процесс — от клика по кнопке до отгрузки. Именно этот жизненный цикл нужно реализовать в статусах заказа и автоматизации, чтобы товары под заказ работали без ручного управления на каждом шаге.

Обратите внимание на два узла процесса. Первый — шаг 3 «Поступление»: именно здесь виртуальное обязательство превращается в реальный резерв, и до этого момента остаток не трогается. Второй — шаг 4 «Готов»: при частичной оплате именно здесь запрашивается доплата, а покупатель получает уведомление о готовности. Автоматизация этих двух переходов снимает большую часть ручной работы и ошибок.

Частые ошибки при внедрении товаров под заказ

• Смешали «под заказ» и «нет в наличии» в одном флаге — либо запретили продавать возимое, либо разрешили купить снятое с продажи.
• Показывают статус «под заказ» без срока — покупатель не понимает, когда получит товар, и уходит.
• Хранят срок поставки текстом в описании — его нельзя посчитать, отфильтровать и обновить при обмене.
• Включили обычный резерв для позиции под заказ — доступный остаток ушёл в минус, каталог показывает неверную доступность.
• Обмен с 1С обновляет остатки, но не пересчитывает статусы — позиция с флагом «под заказ» отображается как «нет в наличии».
• Отгружают предзаказ до фактического поступления товара на склад — списание уходит в минус, отгрузка срывается.
• Взяли предоплату, но не прописали условия возврата аванса — при срыве срока получают споры и негатив.
• Не уведомляют покупателя о смене статуса и сдвиге даты — вся коммуникация ложится на поддержку, растут отмены.
• Не показывают срок в списке каталога — покупатель уходит, не дойдя до карточки, потому что видит только «нет в наличии».

Чек-лист внедрения

Сведём всё в практический список, по которому удобно принимать готовность товаров под заказ перед запуском:

1. Модель наличия спроектирована. Зафиксирован набор статусов и правило вычисления статуса из остатка и свойств; статус един для каталога, карточки и корзины.
2. Свойства заведены. Есть числовой срок поставки, флаг «под заказ», поставщик и дата ожидаемого поступления; срок нигде не хранится текстом в описании.
3. Продажа при нуле разрешена. Для позиций под заказ включена продажа при отсутствии на складе, корзина даёт оформить заказ.
4. Статусы заказа настроены. Заведены «Предзаказ», «Ожидает поставки», «Товар на складе», «Готов к отгрузке» и переходы между ними.
5. Резерв разделён. Складские позиции резервируются штатно, «под заказ» — виртуально; доступный остаток не уходит в минус из-за предзаказов.
6. Оплата описана. Выбрана модель (полная, аванс, по факту), прописаны условия и возврат аванса, статусы оплаты независимы от наличия.
7. Обмен с 1С связан. Приносит остатки, сроки и поставщиков; после загрузки пересчитывает статусы наличия.
8. Витрина оформлена. Статус и расчётная дата выводятся в списке и карточке, статус добавлен в фильтр по наличию, кнопка продающая.
9. Уведомления работают. Настроены триггерные сообщения на ключевых переходах, включая сдвиг срока с вариантами действий.
10. Сценарии проверены. Прогнан полный цикл заказа под заказ; остатки корректны, отгрузка невозможна до поступления.

Вывод

Товары под заказ — это не костыль, а полноценный канал продаж, который расширяет ассортимент и снижает замороженные деньги в остатках. Работает он тогда, когда в 1С-Битрикс аккуратно разведены три сущности — предзаказ, резерв и оплата, — построена честная модель статусов наличия, а срок поставки хранится числом и превращается на витрине в понятную дату. Свяжите это с обменом 1С так, чтобы статусы пересчитывались автоматически, добавьте уведомления о смене сроков — и «под заказ» перестанет быть источником багов и претензий, а станет предсказуемым процессом, который приносит заказы там, где раньше было сухое «нет в наличии».