Критическая проблема: отсутствие ограничения количества товара в заказе на платформе Хорошоп

[Евгений]

Добрый день.

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

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

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

2. Падение конверсии и некорректная оценка работы магазина
   Фиктивные или технически невозможные заказы ухудшают реальные показатели бизнеса. Это особенно критично для проектов, которые активно работают с рекламой, CRM, сквозной аналитикой и автоматизированной обработкой заказов.

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

4. Операционные проблемы для команды магазина
   Менеджеры вынуждены вручную проверять, отменять и обрабатывать подобные заказы. Это забирает рабочее время, создает ошибки в отчетности и снижает эффективность работы команды.

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

Считаем, что ограничение максимального количества товара в заказе — это базовая функция для современной e-commerce платформы. Она должна быть доступна на уровне настроек товара, категории или магазина в целом.

Оптимальным решением было бы добавить возможность задавать:

• максимальное количество единиц одного товара в одном заказе;

• глобальное ограничение по количеству единиц товара в заказе;

• отдельные ограничения для конкретных товаров или категорий;

• проверку количества на этапе корзины и оформления заказа;

• корректное сообщение для покупателя, например: «Максимальное количество данного товара в одном заказе — 10 шт.».

На нашей стороне работает восемь проектов на платформе Хорошоп, поэтому проблема имеет для нас не теоретический, а практический и системный характер. Мы неоднократно обращались по этому вопросу в течение года, однако полноценного решения до сих пор нет.

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

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

Просим предоставить информацию, планируется ли внедрение такого функционала и в какие ориентировочные сроки.

решени со складом не предлагайте , по понятным причинам

С уважением,

[FortModels]

@Евгений

5. активацию «склада»

У меня конечно не восемь проектов на Хорошопе, пока 2, но я, честно говоря удивлен, как Вы вообще работаете без активного “склада”, ведь тогда полный бардак с учетом товаров. Возможно у Вас иная специфика, но практическм все описанные Вами выше вопросы решает именно склад.

[Евгений]

Спасибо за комментарий.

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

Но проблема, о которой идет речь, немного другая. Речь не о внутреннем учете остатков, а о возможности ограничить максимальное количество товара, которое один пользователь может положить в корзину и оформить в одном заказе.

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

Поэтому склад и лимит количества товара в заказе — это разные функции.

Склад отвечает на вопрос:
«Сколько товара реально есть в наличии?»

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

Например, если на складе есть 500 единиц товара, это не означает, что один покупатель должен иметь возможность оформить все 500 единиц одним заказом. Для обычной розничной продажи логично установить лимит, например 5, 10 или 20 единиц в одном заказе, в зависимости от специфики товара.

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

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

[Olena.Horoshop.Team]

Дякуємо за детальний опис сценарію та пропозицію щодо розвитку функціоналу.

Можливість обмеження максимальної кількості одного товару в замовленні дійсно може бути корисною для окремих бізнес-моделей, тому такий запит можна розглядати як побажання щодо розвитку платформи.

Водночас хотілося б розділити питання наявності бажаного функціоналу та критичності проблеми.

Більшість наведених у зверненні аргументів стосуються проблеми фейкових або некоректних замовлень загалом. Саме по собі обмеження максимальної кількості товару не виключає можливості створення фейкових замовлень і не може розглядатися як універсальний механізм захисту від недобросовісних дій. Наприклад, замість одного замовлення на 999999 одиниць можуть бути створені десятки або сотні звичайних замовлень з меншою кількістю товару.

Також варто враховувати, що для багатьох магазинів великі обсяги замовлення є цілком валідним сценарієм роботи. Саме тому подібні обмеження відсутні на багатьох e-commerce платформах та маркетплейсах за замовчуванням і зазвичай реалізуються як окреме налаштування, а не як базовий механізм захисту платформи.

Тому наразі коректніше розглядати даний запит як пропозицію щодо нового функціоналу, а не як критичний недолік платформи.

Також було б корисно отримати більше деталей щодо причин, через які існуючі механізми контролю залишків не можуть бути використані у вашому сценарії роботи. У зверненні зазначено, що рішення через складський облік не підходить «з очевидних причин», однак самі причини не описані. Ця інформація допоможе краще оцінити необхідність окремого функціоналу та його потенційні сценарії використання.

[FortModels]

Теперь понятно, Вам нужна защита от недобросовестных пользователей (возможно, конкурентов), которые могут в несколько кликов “опустошить” Ваш склад и сделать его не активным для обычных покупателей. Резонно.

[Shop_Case]

Скриптами ж можна:

gpt за пару хв уточнень зробив.

але хто захоче фейка зробити, той зробить)))

[Евгений]

Согласен с тем, что ограничение максимального количества товара в одном заказе не является универсальной защитой от всех фейковых заказов. Но это не означает, что такая функция не является критически важной.

Здесь важно разделить два разных сценария.

Фейковый заказ как таковой — это одна проблема.
Массовый заказ нереального или чрезмерного количества товара — это отдельный и значительно более опасный сценарий.

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

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

Ни один механизм защиты не решает проблему на 100%, но это не означает, что его не нужно внедрять. Лимит количества — это не единственная защита, но это важный базовый барьер, который существенно снижает возможный ущерб от таких действий.

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

То есть вместо защиты мы получаем другую проблему: фейковый заказ может не просто испортить статистику, а фактически выбить товар из продажи.

Именно поэтому склад и ограничение количества в заказе — это разные функции.

Склад отвечает за то, сколько товара есть в наличии.

Лимит количества в заказе отвечает за то, сколько единиц товара один покупатель может заказать за один раз.

Если на складе есть 500 единиц товара, это не означает, что один пользователь должен иметь возможность оформить все 500 единиц одним заказом. Для розничной e-commerce-модели это часто нелогично и небезопасно.

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

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

Что касается критичности проблемы — для нас это не теоретическое пожелание. У нас уже были кейсы, когда подобные некорректные заказы ломали рекламную аналитику и работу кампаний. Восстановление и стабилизация рекламных процессов после таких инцидентов обходились более чем в 50 000 грн. Это прямые бизнес-потери, а не просто неудобство в работе с админкой.

Для e-commerce рекламные кампании, конверсии, средний чек, передача событий, CRM и аналитика — это часть операционной инфраструктуры. Если из-за отсутствия базового ограничения один фейковый заказ может исказить эти данные, то проблема уже является критической для бизнеса.

Поэтому корректнее рассматривать этот функционал не просто как «пожелание», а как важный инструмент защиты магазина и стабильности e-commerce-процессов.

Оптимальным решением было бы добавить возможность устанавливать максимальное количество одного товара в заказе:

• на уровне товара;

• на уровне категории;

• глобально для магазина;

• с возможностью отключить это ограничение там, где оно не нужно.

Это не помешает магазинам, которым нужны крупные заказы, но даст защиту тем, для кого такой сценарий является риском.

Именно поэтому мы считаем это не просто дополнительной опцией, а необходимой настройкой для современной e-commerce-платформы.

---

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

Также хочу отдельно отметить, что ограничение количества товара в заказе — это не какая-то нестандартная или узкоспециализированная доработка. Для современной e-commerce-платформы это нормальная и ожидаемая логика управления продажами.

Во многих зрелых e-commerce-системах подобный функционал реализуется штатно, через B2B-настройки, правила корзины, складские параметры или официальные расширения. Суть в том, что магазин должен иметь возможность сам определить, сколько единиц одного товара покупатель может заказать за один раз.

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

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

Если магазину нужны крупные заказы — он оставляет возможность без ограничений или задает высокий лимит. Если магазин работает в розничной модели — он устанавливает разумный максимум: например, 5, 10, 20 или 50 единиц одного товара в заказе.

Такой подход не мешает оптовым продавцам, но дает розничным магазинам базовый инструмент защиты от некорректных, фейковых и вредоносных заказов.

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

Да, лимит количества не защищает от всех возможных фейковых заказов. Но он закрывает один из самых простых и разрушительных сценариев — оформление одного заказа с чрезмерным количеством товара.

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

В нашем случае подобные инциденты уже приводили к поломке рекламной аналитики и необходимости восстановления рекламных процессов с затратами более 50 000 грн. Поэтому для нас это не теоретическая дискуссия, а реальный бизнес-риск.

Считаем, что возможность ограничить максимальное количество товара в заказе должна быть доступна как базовая настройка современной e-commerce-платформы: на уровне товара, категории или магазина в целом, с возможностью отключения там, где она не нужна.

[Евгений]

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

Для многих e-commerce-проектов заказ — это не просто запись в админке. Это событие, которое передается в рекламные системы, аналитику, CRM и используется для дальнейшего обучения рекламных кампаний.

Если магазин использует Google Ads со стратегиями, которые ориентируются на ценность конверсии, например на ценность заказа или целевой ROAS, то один фиктивный заказ с аномальной суммой может серьезно исказить данные кампании.

Например, если пользователь оформляет заказ на огромное количество товара и система передает в Google Ads событие «Заказ» с ценностью условно 1 000 000 грн, рекламный алгоритм может получить некорректный сигнал о сверхценной конверсии. Для автоматических стратегий это не просто ошибка в статистике, а искажение данных, на которых строится оптимизация.

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

У нас уже были ситуации, когда подобные некорректные заказы приводили к сбоям в рекламной аналитике и необходимости восстановления рекламных процессов. Потери и затраты на стабилизацию превышали 50 000 грн.

Именно поэтому нельзя рассматривать эту проблему только как «неудобство в заказах» или «пожелание по функционалу». Для магазина, который работает с Google Ads, Meta Ads, CRM, аналитикой и автоматическими стратегиями, корректность данных по заказам — это часть операционной безопасности бизнеса.

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

• много мелких заказов заметнее по поведению;

• их проще отследить и отфильтровать;

• есть больше времени на реакцию;

• они не создают одного резкого аномального события с огромной ценностью заказа;

• их проще отделить от реальных заказов по повторяемости, данным клиента, телефону, email, IP, устройству или другим признакам.

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

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

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

Ограничение количества товара в заказе не решает проблему фейковых заказов на 100%, но на практике закрывает самый простой и самый опасный сценарий примерно на 80%: один заказ с аномальной суммой, который может сломать аналитику, рекламные стратегии и корректность остатков.

Платформа, которая хочет быть не просто конструктором интернет-магазинов, а полноценным e-commerce-партнером, должна помогать клиентам заранее предотвращать типичные риски роста бизнеса, а не реагировать на них только после того, как магазины уже понесли убытки.

[Olena.Horoshop.Team]

Дякуємо за додаткове пояснення сценарію.

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

Обмеження максимальної кількості товару може знизити ймовірність окремих сценаріїв, однак не виключає передачу в рекламні системи інших аномальних замовлень з великою сумою або некоректними даними.

Також було б корисно зрозуміти, які саме e-commerce платформи ви розглядаєте як приклад реалізації такого механізму на базовому рівні. Це допоможе оцінити поширеність підходу та можливі варіанти реалізації.

[Евгений]

Проблема не в том, что лимит количества товара решает все виды фейковых заказов. Он и не должен решать 100%.

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

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

Эта функция никому не мешает: кому не нужна — не включает. Кому нужна — получает базовый инструмент защиты.

Склад не заменяет лимит. Склад показывает наличие. Лимит определяет, сколько единиц один покупатель может заказать за раз. Это разные задачи.

Подобная логика есть у зрелых e-commerce-платформ: Adobe Commerce / Magento, BigCommerce, Shopify B2B, WooCommerce через официальные расширения.

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

Мы говорим об этой проблеме уже около года. За это время поддержка неоднократно получала описание сценариев, рисков и последствий, но по факту вопрос до сих пор остается без решения.

Вместо конкретного ответа — будет ли внедрена настройка, когда и в каком виде — мы снова получаем общие рассуждения о том, что функция не решает все возможные сценарии злоупотреблений. Но это не ответ на основной вопрос.

Основной вопрос простой: будет ли у магазина возможность ограничить максимальное количество одного товара в заказе или нет?

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

Для нас это реальная проблема, которая уже приводила к финансовым потерям. Поэтому мы ожидаем не общих формулировок, а конкретной позиции по внедрению базовой настройки, которая давно является нормальной практикой для e-commerc

[Евгений]

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

[Olena.Horoshop.Team]

ми розглянули ваш сценарій та аргументацію щодо нього.

При цьому на форумі ми не можемо анонсувати функціонал, строки його реалізації або гарантувати появу конкретних можливостей до ухвалення відповідного рішення продуктовою командою.

Щодо наведених прикладів платформ - частина з них реалізує подібну логіку через додаткові модулі, розширення або спеціалізовані B2B-функції, тому сам факт наявності такого механізму не означає, що він є базовим або обов’язковим для всіх e-commerce платформ.

Ми не заперечуємо, що такий функціонал може бути корисним для окремих магазинів. Саме тому побажання передано на розгляд.

На цей момент додаткової інформації щодо можливості та строків реалізації у нас немає.