Типовий рушій інтернет-магазину зберігає ціну товару як одне число. Щойно з'являється другий склад із власною закупівельною ціною чи гуртовий рівень для постійного клієнта, ця модель ламається. Розбираємо, чому так і що довелося порахувати в ядрі власного рушія LiteShop.
У більшості рушіїв інтернет-магазинів ціна товару — це одне число в одному полі бази даних. Працює бездоганно, поки магазин має один склад і продає всім за однією ціною. Проблема виникає, щойно з'являється другий склад із власною закупівельною вартістю або гуртовий покупець, якому потрібна інша ціна за той самий товар.
Ця стаття про те, чому «один товар — одна ціна» ламається саме в цій точці, і що довелося порахувати в ядрі власного рушія LiteShop, щоб цього уникнути.
Уявімо магазин з двома складами: один у Києві, товар туди завезли за старою закупівельною ціною, другий у Львові — та сама позиція, але завезена пізніше й дорожче. Класичний рушій, у якому ціна прив'язана до товару, а не до пари «товар + склад», змушує вибирати: або тримати два різні товарні записи для однієї й тієї ж позиції (і плутати покупця вибором «однакового» товару двічі), або продавати з одного складу собі в збиток, поки не вирівняється середня закупівельна.
Та сама проблема з гуртовими рівнями: постійний клієнт із замовленнями на суму понад певний поріг має отримувати іншу ціну за той самий артикул, ніж роздрібний покупець. Якщо ціна — одне поле, це потребує або ручної системи знижок поверх стандартного рушія, або окремого прайсу, який синхронізується вручну і розходиться з основним каталогом за перший же тиждень.
Правильне рішення — не косметичне (додати поле «знижка» в картку товару), а структурне: ціна має належати парі «товар + склад» і додатково модифікуватися рівнем покупця. Це означає окрему таблицю цін, а не одне поле, і логіку вибору правильного ряду цін під час кожного перегляду картки товару й кожного розрахунку кошика — без сповільнення сторінки, бо цей розрахунок відбувається на кожному запиті.
Ми будували цю логіку в ядрі власного рушія LiteShop: кілька складів із різною закупівельною ціною одного товару, рівні гуртових цін і складський облік — не надбудова поверх типового рушія, а частина того, як побудована модель товару з самого початку. 42 модулі ядра (доставка, оплата, склад, лояльність, SEO) вмикаються перемикачем в адмінці, а не встановлюються окремими плагінами, які потім конфліктують одне з одним.
Додаткова логіка розрахунку ціни на кожен перегляд — природне питання про швидкість. На проді одного з магазинів, побудованих на цьому рушії (Hetzner cx43), перша відповідь головної сторінки холодна дорівнює теплій — 167 мс, замір 19.05.2026. Це можливо саме тому, що розрахунок ціни за складом і рівнем клієнта кешується в Redis: заміри 12.06.2026 показали 98,3% влучань у кеш при нулі витіснених ключів — тобто кеш не встигає переповнюватися й видаляти актуальні дані навіть під живим навантаженням.
Резервування товару з таймером у кошику відсутнє: залишок списується під час оформлення замовлення, не в момент додавання в кошик. Імпорту каталогу напряму з OpenCart немає. Інтеграції з Rozetka Delivery і Meest поки заглушки, не робоча функція. Ці обмеження — не приховані дрібним шрифтом, а прямо озвучені: рушій молодий, і множинні склади з гуртовими рівнями — це та частина, яку зробили міцною з першого дня, а решту добудовують послідовно.
Якщо у вас один склад, кілька сотень товарів і немає планів на гуртові рівні чи доробки — типовий рушій чи оренда конструктора обійдуться дешевше, і чесний розбір задачі скаже це першим листом, а не після оплати. Потреба у структурному рішенні виникає від двох складів чи постачальників, від необхідності в гуртових рівнях цін, або коли типовий конструктор уже впирається у власні обмеження.
Ваша думка допомагає нам створювати кращий контент
Допоможіть іншим дізнатись про це — поділіться статтею в соціальних мережах
Дякуємо, що допомагаєте нам рости
Пише про те, що робить руками: інтернет-магазини на OpenCart, застосунки на Next.js, інтеграції та швидкість сайтів. У статтях — заміри й перевірки, які читач може повторити на своєму проєкті, а не загальні поради. Комерційна розробка з 2015 року.
Відповіді на популярні питання по темі
Поле «знижка» вирішує лише одну ситуацію — одну знижку для всіх. Щойно потрібна різна ціна залежно від складу (через різну закупівельну вартість) і одночасно різна ціна залежно від рівня клієнта (роздріб/гурт), одного числа-знижки не вистачає: потрібна таблиця, яка враховує обидва фактори одночасно, а не одне поле поверх іншого.
На проді одного з магазинів на цьому рушії перша відповідь головної сторінки — 167 мс, холодна дорівнює теплій (19.05.2026), а Redis-кеш дає 98,3% влучань при нулі витіснених ключів (12.06.2026). Розрахунок кешується, тож повторні перегляди не перераховують ціну щоразу заново.
Наразі прямого імпорту з OpenCart немає — це чесно зазначена межа поточної версії рушія, не прихована дрібним шрифтом.
Ні, резервування з таймером у кошику відсутнє: залишок списується в момент оформлення замовлення, а не при додаванні в кошик.
Якщо склад один, товарів кілька сотень і гуртових рівнів чи доробок не планується — типовий рушій чи оренда конструктора обійдуться дешевше. Структурне рішення має сенс від двох складів чи постачальників або від потреби в гуртових рівнях цін.
Підпишіться на нашу розсилку та отримуйте корисні поради, інсайти та новини про веб-розробку, маркетинг та бізнес.
Веб-розробка21 вересня 2026 року, у першу добу обліку запитів за маршрутами, службовий /api/health отримав 13 666 запитів — 60 % трафіку застосунку, і кожен ішов у спільну базу. Розповідаємо, які два налаштування це прибрали, яку ціну маємо за них і як перевірити свій healthcheck.
Веб-розробка21 вересня 2026 року перевірка типів на нашому сайті показала 154 помилки, хоча збірка щоразу була зеленою: результат перевірки просто викидався. Усередині знайшлись нулі в статистиці посилань і в експорті аналітики, сортування, що не сортувало, і тести, які не запускались. Розповідаємо, як розбирали, що змінили і як перевірити свій проєкт.
Веб-розробка22 вересня 2026 року ми перевірили HTTPS-сертифікати на 116 сайтах, які вже міряли для ринкових вимірів, і для 104 з них порівняли стан із серпневим. Усі 116 пройшли перевірку, 108 стоять на 89- і 90-денних безкоштовних сертифікатах, і лише в одного сайту сертифікат досі не продовжився, хоча за типових налаштувань уже мав би. Розбираємо заміри, межі методу й показуємо, як перевірити свій сайт однією командою.
