Наличие, статусы товара и предзаказ в 1С-Битрикс

Наличие — это первое, что ищет глазами покупатель, открыв карточку товара. Есть или нет? Когда привезут? Можно ли заказать сейчас? От ответов на эти вопросы зависит, нажмёт человек «В корзину» или уйдёт. И если наличие на витрине не совпадает с реальностью — товар помечен «в наличии», а на складе его нет, — магазин теряет дважды: сначала на отменённом заказе и звонке с извинениями, потом на репутации, потому что такой покупатель не вернётся. Честное наличие — это не мелочь оформления, а прямой фактор доверия и конверсии.

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

Честное наличие как фактор доверия

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

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

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

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

Статусы товара: полный список

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

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

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

Где хранятся остатки в Битриксе

Чтобы управлять наличием, нужно понимать, откуда берётся сама цифра остатка. За товарную часть каталога в 1С-Битрикс отвечает модуль «Торговый каталог», который надстраивается над инфоблоком. Именно он добавляет к элементам инфоблока цену, единицы измерения и, главное для нас, количество (остаток).

В простом варианте (без складского учёта) наличие описывается несколькими полями товара или торгового предложения:

• Количество — сколько единиц товара доступно. Это основное число, из которого дальше вычисляется статус.
• Флаг «Количество товара на сайте» — учитывать ли остаток вообще. Если учёт количества выключен, товар считается всегда доступным.
• «Разрешить покупку при отсутствии» — позволять ли класть товар в корзину при нулевом или отрицательном остатке. Это ключевой флаг для «под заказ» и предзаказа.
• Единица измерения и коэффициент — как считается количество (штуки, упаковки), что влияет на отображение и на кратность заказа.

Есть глобальные настройки модуля торгового каталога (учитывать количество, разрешать покупку при отсутствии, вычитать резерв) и есть значения на уровне конкретного товара — они переопределяют глобальные. Такая двухуровневость удобна: по умолчанию задают политику для всего каталога, а для отдельных категорий или позиций настраивают исключения (например, глобально покупку при отсутствии запрещаем, а для группы «под заказ» разрешаем).

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

Остатки по складам и их отображение

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

Отсюда возникает проектный вопрос: что именно показывать покупателю как «наличие»? Вариантов несколько, и выбор зависит от бизнес-модели:

• Суммарный остаток по всем складам. Витрина показывает общее «в наличии», если товар есть хоть где-то. Просто, но скрывает, что товар лежит на дальнем складе и приедет не сразу.
• Остаток выбранного склада/города. Покупатель выбирает город или пункт выдачи, и наличие показывается по этому складу. Честнее для мультирегиональных магазинов.
• Наличие по каждому складу списком. В карточке выводят таблицу «Склад — количество»: удобно для B2B и самовывоза, когда важно, где именно лежит товар.
• Разделение «свой склад / под заказ у поставщика». Остаток на своём складе — «в наличии», позиции со склада поставщика — «под заказ» с большим сроком.

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

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

Как статус вычисляется из остатка

Статус, который видит покупатель, — это не отдельное поле, которое кто-то проставляет вручную, а результат небольшой логики, которая работает в шаблоне карточки. На входе — остаток и настройки; на выходе — подпись статуса и поведение кнопки. Разберём эту логику по шагам, как она обычно строится.

1. Учитываем ли количество вообще? Если для товара учёт количества выключен, он считается всегда доступным — статус «в наличии», кнопка активна. Такое бывает для услуг и нефизических товаров.
2. Остаток больше порога «мало»? Если доступное количество выше порога — статус «в наличии», кнопка активна, без акцента на срочность.
3. Остаток положительный, но ниже порога? Статус «мало осталось» — кнопка активна, добавляется бейдж срочности и, при желании, само число «осталось N шт».
4. Остаток нулевой, но покупка при отсутствии разрешена? Статус «под заказ» (или «ожидается», если задан срок/дата) — кнопка активна, рядом показывается срок поставки.
5. Остаток нулевой и покупка при отсутствии запрещена? Статус «нет в наличии» — вместо кнопки «В корзину» показывают «Уведомить о поступлении».
6. Товар помечен снятым с продажи? Статус «снят с продажи» — кнопки нет, показывают ссылку на аналог или раздел.

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

Реализуют эту логику в шаблоне компонента карточки (bitrix:catalog.element) или в товарной карточке комплексного компонента. Битрикс отдаёт в шаблон готовые признаки доступности (можно ли купить, можно ли докупить), а подписи статусов и сроки берут из свойств. Важно, чтобы одна и та же логика работала и в карточке, и в списке товаров, и в мини-корзине — иначе покупатель увидит «в наличии» в списке и «нет» в карточке.

Порог «мало осталось» и квоты

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

Как задают порог:

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

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

Поведение кнопки «в корзину»

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

Несколько правил, которые важно соблюсти в реализации кнопки:

• Не показывать активную «В корзину» на недоступном товаре. Если купить нельзя — кнопка должна быть заменена, а не просто выдавать ошибку после клика.
• Согласованность с корзиной. Даже если товар попал в корзину, при оформлении Битрикс перепроверяет доступность — важно, чтобы покупатель не узнал об отсутствии только на последнем шаге. Лучше не пускать недоступное в корзину вообще.
• Учитывать кратность и максимум. Если доступно 3 шт, покупатель не должен иметь возможность заказать 5 без пометки «остальное под заказ» или без ограничения количества.
• Единое поведение в списке и карточке. Кнопка быстрой покупки в списке товаров должна вести себя так же, как в карточке: те же статусы, те же ограничения.
• Понятный срок вместо пустоты. Для «под заказ» и «ожидается» рядом с кнопкой всегда должен быть срок или дата — иначе «под заказ» читается как «непонятно когда» и отпугивает.

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

Статус «под заказ»

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

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

• Явная подпись статуса. Не оставляйте пустоту или обманчивое «в наличии» — покупатель должен видеть именно «под заказ».
• Честный срок поставки. «Под заказ, 3–5 рабочих дней» превращает отсутствие в понятное предложение. Срок хранят в свойстве товара или категории и показывают рядом с кнопкой.
• Разные сроки для разных товаров. У ходовых позиций поставщика срок один, у редких — другой; универсальное «под заказ» без срока хуже конкретного.
• Предоплата или подтверждение. Для дорогих позиций под заказ логично брать предоплату или подтверждать наличие у поставщика до отгрузки — это часть бизнес-процесса, которую отражают в оформлении.

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

Предзаказ: заказ того, чего нет

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

Классические сценарии предзаказа:

• Новинка до старта продаж. Товар анонсирован, дата поступления известна, покупатели оформляют предзаказ заранее — магазин собирает спрос и понимает объём закупки.
• Будущая поставка. Ходовой товар закончился, следующая партия придёт к известной дате — предзаказ позволяет не терять желающих купить.
• Ограниченная партия. Товар выйдет ограниченным тиражом — предзаказ распределяет его между теми, кто был готов купить.

Технически предзаказ реализуется той же механикой «покупка при отсутствии», но с важными дополнениями:

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

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

Статус «ожидается» и сроки

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

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

Как показывать сроки честно и полезно:

• Конкретная дата, когда известна. «Ожидается 20 июля» — самый сильный вариант, если поставка подтверждена.
• Диапазон или ориентир, когда точной даты нет. «Ожидается во второй половине месяца» честнее пустоты, если дата плавает.
• Автоматическое снятие статуса. Когда товар поступил (остаток стал положительным), статус «ожидается» должен смениться на «в наличии» автоматически — обычно это происходит по обмену, без ручного вмешательства.
• Обновление при сдвиге. Если поставка задерживается, дату сдвигают, а предзаказчиков уведомляют. «Ожидается» с давно прошедшей датой хуже, чем честное «нет в наличии».

Отдельно стоит связать «ожидается» с механизмом «уведомить о поступлении»: даже если покупатель не хочет оформлять предзаказ прямо сейчас, он может подписаться и получить письмо в день поступления. Так статус «ожидается» работает и как продающий (предзаказ), и как удерживающий (подписка) одновременно.

Резервы и «доступно к заказу»

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

Логика простая: доступно к заказу = остаток − резерв. Именно доступное количество, а не «сырой» остаток, должно определять статус на витрине. Если на складе 3 шт, но 2 уже зарезервированы под оформленные заказы, покупатель должен видеть, что доступна 1 шт, а не 3.

В 1С-Битрикс резервирование настраивается в модуле торгового каталога и в бизнес-процессе заказа:

• Момент резервирования. Резерв можно ставить при оформлении заказа, при оплате или при переходе заказа в определённый статус — выбирают под бизнес-процесс.
• Вычитание резерва из наличия. Настройка «вычитать резерв из доступного количества» — чтобы витрина показывала доступное, а не общее.
• Снятие резерва. Резерв должен сниматься при отгрузке (переходит в реальный расход) или при отмене/протухании заказа (возвращается в доступное) — иначе «зависшие» резервы съедают наличие.
• Срок резерва. Для неоплаченных заказов часто задают срок жизни резерва, после которого он автоматически снимается, чтобы товар не «висел» вечно.

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

Уведомить о поступлении

Товар закончился — но интерес покупателя никуда не делся. Механизм «уведомить о поступлении» превращает отсутствие товара из потерянной продажи в отложенную. Вместо кнопки «В корзину» на товаре без остатка показывают «Уведомить о поступлении»: покупатель оставляет e-mail (или телефон), и когда товар возвращается в продажу, система сама присылает ему письмо со ссылкой на карточку.

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

Как это устроено в 1С-Битрикс:

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

Что важно для конверсии этого инструмента: кнопка «Уведомить» должна быть заметной (а не спрятанной), форма — короткой (в идеале один e-mail), а письмо о поступлении — быстрым (уходить в тот же день, когда пришёл остаток) и вести прямо в карточку. И, конечно, механизм должен корректно связываться с обменом: остаток обновился в 1С → пришёл на сайт → сработала рассылка. Если обмен остатками настроен плохо, уведомления либо не уходят, либо уходят с задержкой, когда товар снова успел закончиться.

Уведомить о снижении цены

Рядом с «уведомить о поступлении» логично стоит родственный инструмент — «уведомить о снижении цены». Механика та же (подписка + событие + рассылка), но триггер другой: письмо уходит не когда товар вернулся в наличие, а когда его цена опустилась. Это работает для аудитории, которую устраивает товар, но не устраивает текущая цена: она подписывается и ждёт скидки.

Как это устроено и чем полезно:

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

Этот инструмент менее универсален, чем «уведомить о поступлении»: он полезен там, где цены действительно меняются и покупатели готовы ждать выгоды (техника, сезонные товары). Для магазинов со стабильными ценами он избыточен. Но там, где он уместен, он превращает пассивных «пока дорого» посетителей в базу, которую можно активировать одним снижением цены. Оба механизма — про наличие и про цену — строятся на одной идее: не терять заинтересованного покупателя, а дать ему способ вернуться, когда изменится то, что его останавливает.

Скрывать или показывать без остатка

Один из самых спорных вопросов работы с наличием: что делать с товарами, которых нет на складе — скрывать их с витрины или оставлять со статусом «нет в наличии»? Неверное решение бьёт либо по SEO, либо по UX, поэтому разберём его внимательно.

Сначала — почему нельзя действовать по принципу «нет остатка — прячем»:

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

Правильный подход — разделять товары по причине отсутствия:

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

Фильтр «только в наличии»

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

Как это реализуется в 1С-Битрикс:

• Через свойство/признак наличия. Удобнее всего завести признак доступности (например, свойство или флаг «в наличии»), который обновляется вместе с остатком, и включить его в умный фильтр как обычную опцию.
• Через фильтрацию по количеству. Фильтр отбирает товары с положительным доступным остатком. Требует, чтобы наличие корректно попадало в фасетный индекс.
• Сортировка «сначала в наличии». Мягкий вариант — не прятать отсутствующие, а опускать их вниз списка, оставляя доступные сверху.

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

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

Наличие на витрине: карточка и список

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

В списке товаров

В каталоге и результатах поиска у каждой карточки-плитки показывают компактный индикатор наличия: цветной бейдж «в наличии» / «под заказ» / «нет в наличии» и кнопку заказа в соответствующем состоянии. Это помогает покупателю ещё на этапе просмотра списка понять, что доступно, и не заходить в карточки отсутствующих товаров зря. Здесь же работает сортировка «сначала в наличии» и фильтр по наличию.

В карточке товара

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

В корзине и оформлении

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

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

Снят с продажи и архив

Отдельный статус, который часто забывают, — «снят с продажи». Это товары, которые больше не продаются и не вернутся: сняты с производства, выведены из ассортимента, замена отсутствует. Их нельзя просто удалить из базы (они нужны в истории заказов), но и держать как обычный товар с кнопкой «Купить» бессмысленно.

Как правильно обращаться со снятыми товарами:

• Отдельный признак «снят с продажи». Свойство или статус, по которому карточка выводится без кнопки заказа, с пометкой «товар снят с продажи».
• Ссылка на аналог. Если есть замена — крупная ссылка «смотрите актуальную модель» или блок с аналогами. Это спасает и покупателя, и продажу.
• Решение по индексации. Для снятого товара с трафиком — 301-редирект на аналог или раздел; для окончательно ненужной страницы — корректный 404/410. Массово плодить «мёртвые» карточки в индексе не стоит.
• Архивные разделы. Товары, которые нужны только для истории, но не для витрины, убирают в служебный/архивный раздел и закрывают от индексации, оставляя доступными в учёте.

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

Обмен статусов и остатков с 1С

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

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

Ключевые вопросы, которые определяют, будет ли наличие честным:

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

Обмен остатками — большая тема сама по себе, особенно когда складов несколько или подключён WMS с адресным хранением. Как собрать корректную цифру наличия из нескольких источников и не рассинхронизировать каналы, мы подробно разобрали в статье про обмен остатками с нескольких складов и WMS. Если же интеграция с 1С только проектируется, надёжный обмен остатками мы закладываем в рамках услуги по созданию интернет-магазина с интеграцией 1С — потому что честное наличие невозможно без правильно настроенного обмена.

Реализация в 1С-Битрикс

Соберём в одном месте, какими штатными средствами реализуется всё описанное, — чтобы было понятно, что где настраивается.

Как это связывается на практике. Остаток и флаг покупки при отсутствии — это фундамент: Битрикс сам решает, можно ли купить товар. Свойства (порог «мало», дата поступления, флаг «снят с продажи», срок «под заказ») добавляют статусам смысл, которого нет «из коробки». Шаблон карточки собирает из остатка, флагов и свойств готовый статус, подпись и состояние кнопки; ту же логику выносят в общий код, чтобы список, карточка и корзина показывали одно и то же. Подписка на товар обеспечивает «уведомить о поступлении». Умный фильтр даёт «только в наличии». А обмен с 1С держит всё это в актуальном состоянии, регулярно обновляя количества. Задача разработчика — связать эти части так, чтобы статус всегда был честным и вычислялся автоматически из свежих данных.

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

Пошагово: настраиваем наличие

Сведём всё в практическую последовательность — так мы настраиваем работу с наличием на реальных проектах, от политики статусов до приёмки.

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

Заметьте, что «включить остатки» — лишь один из одиннадцати шагов. Основная работа — в политике статусов, логике их вычисления, резервах и, главное, в настройке обмена, от частоты которого напрямую зависит, будет ли наличие честным. Наличие — это не галочка, а система, которую проектируют под конкретный магазин.

Частые ошибки

• Продают то, чего нет. Остатки на сайте устарели из-за редкого обмена или отсутствия резервов — покупатель заказывает проданный товар. Лечится частой выгрузкой остатков и резервированием.
• Активная «Купить» на отсутствующем товаре. Кнопка «В корзину» на товаре без остатка и без «покупки при отсутствии» приводит к отменам и потере доверия. Кнопку заменяют на «уведомить».
• Накрученная срочность. «Осталось 2 шт» на всех товарах или фальшивые таймеры подрывают доверие. «Мало осталось» должно быть настоящим.
• «Под заказ» без срока. Статус «под заказ» без указания срока читается как «неизвестно когда» и отпугивает. Всегда показывают срок поставки.
• Массовое скрытие товаров без остатка. Удаление временно отсутствующих товаров рушит SEO-позиции и лишает подписок. Временные — оставляют со статусом, скрывают только снятые.
• Товар без остатка в индексе с кнопкой «Купить». Поисковик и покупатель приходят на карточку, где «Купить» активно, а товара нет — двойной вред. Статус и кнопку приводят в честный вид.
• Игнорирование резерва. Витрина показывает общий остаток, не вычитая зарезервированное, — и последнюю единицу продают дважды. Показывают доступное = остаток − резерв.
• Рассогласование списка и карточки. В списке «в наличии», в карточке «нет» — логику наличия продублировали в шаблонах. Вычисление статуса выносят в общий код.
• Редкий обмен остатками. Обмен раз в сутки не успевает за продажами. Остатки выгружают отдельной частой выгрузкой, чаще, чем каталог.
• Нет разницы «нет в наличии» и «снят с продажи». Временное и окончательное отсутствие обрабатывают одинаково — теряют либо позиции, либо ведут покупателя в тупик. Статусы и политику разделяют.
• Уведомления не уходят. Подписка «уведомить о поступлении» есть, но рассылка не связана с обменом остатков — письма не отправляются. Проверяют цепочку остаток → событие → письмо.

Чек-лист

Сведём в практический список то, что проверяют при настройке и приёмке работы с наличием перед запуском.

1. Статусы определены. Набор статусов подобран под магазин, у каждого понятный смысл и оформление.
2. Наличие честное. Статус на витрине совпадает с реальной возможностью получить товар; ложного «в наличии» нет.
3. Кнопка соответствует статусу. «В корзину» активна только там, где купить можно; на отсутствующем — «уведомить»; на снятом — кнопки нет.
4. Остатки по складам настроены. Витринное наличие собирается по заданному правилу; для самовывоза видно наличие по точкам.
5. Порог «мало» задан осмысленно. Квота подходит под тип товара; «мало осталось» основано на реальном остатке.
6. Под заказ и предзаказ со сроком. У «под заказ» есть срок, у «ожидается» — дата; сроки честные и обновляются.
7. Резервы работают. Доступное = остаток − резерв; резерв ставится и снимается корректно, «зависших» нет.
8. Уведомления функционируют. «Уведомить о поступлении» собирает подписки и рассылает письма при появлении остатка.
9. Фильтр «только в наличии». Признак наличия в фасетном индексе, фильтр быстрый и актуальный.
10. Согласованность везде. Один статус в списке, карточке, корзине; логика вынесена в общий код.
11. Политика скрытия. Временные — на витрине с подпиской; снятые — скрыты с редиректами/404; массового удаления нет.
12. Обмен остатками настроен. Частая выгрузка количеств, привязка по XML_ID, согласование резервов; наличие на сайте совпадает с учётом.

Вывод

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

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