Калькулятор конструкції під панелі: як із рядів панелей виходить специфікація матеріалів

Монтажник телефонує із запитанням, яке в цій галузі звучить щодня: скільки всього цього треба на дах, де стоятимуть 24 панелі. Повну специфікацію можна скласти в таблиці, тільки потім хтось мусить перенести її в систему, перевірити ціни саме цього клієнта й переконатися, що нічого не закінчилося на складі. Калькулятор конструкції під панелі робить це за один прохід, а результат одразу стає готовим кошиком. У цьому тексті описано принцип його роботи; це не інструкція користувача й не рецепт, як побудувати власний.

Що саме рахується

Цей калькулятор не підбирає потужність установки чи кількість модулів — це робить калькулятор потреби в енергії. Він також не оцінює несучу здатність даху чи снігове навантаження; це залишається в компетенції проєктувальника. Він відповідає на одне дуже конкретне торговельне запитання: які елементи й у якій кількості треба відвантажити, щоб на цьому даху, з цією покрівлею, стала саме така кількість панелей.

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

Вхідні дані: ряди, а не кількість панелей

У формі немає поля «кількість панелей». Є список рядів, і кожен ряд має орієнтацію та кількість модулів. Кількість панелей — це сума рядів, і вона з’являється в заголовку розділу як інформація, а не як поле для введення.

Так випливає з того, що алгоритм насправді рахує. Конструкцію визначає геометрія рядів: від неї залежить, скільки метрів рейки треба, скільки з’єднувачів скріплює відрізки й скільки кронштейнів передає навантаження на дах. Окреме поле «кількість панелей» дозволяло б ввести значення, що не збігається з рядами, і результат перестав би бути правдою про цей дах. Тому 24 панелі у трьох рядах — це зовсім інший комплект матеріалів, ніж 24 панелі в одному ряду, що тягнеться через пів схилу.

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

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

Панель — це товар із каталогу, а не запис у довіднику

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

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

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

Звідки береться результат

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

Складніше те, чого по дорозі не видно. Обрізки рейок не округлюються окремо для кожного ряду — вони складаються в межах усього розрахунку, бо на об’єкті теж складаються: відрізок, що лишився з одного ряду, іде на наступний. Кронштейнів завжди виходить парна кількість, бо їх монтують парами, по одному на кожну з двох рейок ряду. До комплекту додається запас на підрізання. Саме ці три речі відрізняють розраховану специфікацію від оціночної, і саме від них залежить, чи бригаді чогось забракне.

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

Чому комплект рахується в кількох варіантах

Монтажні профілі продають товарними довжинами, і той самий ряд виходить по-різному на коротшій і на довшій рейці. Різниця не зводиться до арифметики: довший профіль — це менше стиків, тобто менше з’єднувачів, але й більший обрізок, тобто більше матеріалу на викид. З коротшим — навпаки.

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

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

Покрівля визначає кріплення — і тільки вона

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

Найцікавіший випадок — профнастил. Панелі там ставлять безпосередньо на містки, тож рейок і з’єднувачів у специфікації немає взагалі. Це не виняток, дописаний збоку, — специфікація має зовсім інший вигляд, ніж для черепиці. У списку збережених розрахунків це виглядає як щось, що на перший погляд нагадує помилку: цех на 40 панелей на профнастилі виходить дешевшим, ніж будинок на 24 панелі на керамічній черепиці. За це відповідає покрівля, а кількість панелей говорить про вартість конструкції значно менше, ніж здається.

Дві покрівлі без розрахунку — свідомо

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

Калькулятор, що відповідає на будь-яке запитання, втрачає довіру у відповідях на ті, які справді знає. Межу краще визнати прямо.

Звідки беруться елементи

Монтажні елементи не є в системі окремою сутністю. Це звичайні товари компанії — із власним SKU, ціною, ставкою VAT, фото та залишком на складі, — додатково описані кількома технічними параметрами, за якими їх розпізнає алгоритм.

Завдяки цьому кошик, замовлення, рахунок, відправлення та кількісні знижки працюють без жодного додаткового шару, а калькулятор займається лише підбором позицій і кількостей. Компанія, яка підвищить ціну гака, підвищує її в одному місці — у картці товару, — і відтоді кожен новий розрахунок рахує по-новому.

Для запуску модуля не треба вводити вручну кілька десятків позицій. Стартовий каталог імпортується однією командою (або кнопкою, якщо в компанії ще немає жодного елемента) і є ідемпотентним: наступний запуск зіставляє позиції за SKU й не перезаписує цін, які компанія встановила в себе. Фото потрапляє лише до товару, у якого його ще немає, тож власні фотографії переживають повторний імпорт.

Ціни: той самий механізм, що й у магазині

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

Звучить як технічна дрібниця, а насправді це умова довіри до інструмента. Якби калькулятор мав другий прайс, рано чи пізно той розійшовся б із першим — і тоді менеджерові довелося б перевіряти кожен розрахунок, а отже, він міг би з тим самим успіхом рахувати сам. Числа в картці результату — це ті самі числа, які клієнт побачить у кошику, бо вони походять з одного джерела. До того ж покупець B2B насамперед дивиться на суму нетто, і саме вона в картці результату є головним числом.

Специфікація заразом показує те, чого таблиця не покаже: біля кожної позиції стоїть мініатюра фото товару, назва є посиланням на його картку, а якщо компанія веде складський облік і чогось бракує — рядок перекреслено й позначено «немає на складі». Монтажник дізнається про це до того, як перенесе комплект у кошик, а не на етапі оформлення замовлення.

Чого клієнт не побачить

Розкладання обчислень на складові зберігається при кожному розрахунку, але його не показують ні клієнтові магазину, ні компанії, яка його обслуговує. Це ноу-хау калькулятора: ваги окремих параметрів і порядок, у якому вони накладаються.

Цей бар’єр стоїть на боці API, а не в інтерфейсі. Якби розділ «деталі розрахунку» просто ховали на фронтенді, дані однаково приходили б у відповіді сервера, і щоб їх прочитати, вистачило б консолі браузера. Обрізається сама відповідь, тож подробиць у ній немає взагалі. Клієнт отримує результат і повну специфікацію матеріалів — тобто все, що потрібно, щоб замовити, — але не отримує інструкції, як побудувати собі такий самий калькулятор.

Від розрахунку до замовлення

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

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

Розрахунки при цьому зберігаються. Клієнт має в магазині власний список: клік завантажує розрахунок у форму, наступне збереження перезаписує той самий запис, а «Новий розрахунок» починає з чистого аркуша. Він повертається за тиждень, виправляє один ряд і замовляє. Компанія бачить у панелі розрахунки всіх своїх клієнтів — ті самі дані, той самий результат. До збереженого розрахунку можна й поставити запитання: гілка чату прив’язується до конкретного запису, тож розмова «чому тут стільки гаків» точиться біля чисел, а не в окремому листі без контексту.

Що треба підготувати зі свого боку

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

1. Каталог елементів — імпортується однією командою разом із фото; ціни встановлює компанія, і наступні оновлення їх не зачіпають.
2. Позначення панелей — категорія з модулями отримує позначку, товари — розміри. Без цього калькулятор не знає геометрії, і йому немає з чого рахувати.
3. Ціни й цінові групи — тобто рівно те саме, що керує цінами в магазині. Калькулятор не вводить тут жодного нового поняття.

Усе інше — магазин під брендом компанії, замовлення, документи, інтеграції — працює незалежно від того, чи ввімкнено калькулятори. Це, до речі, ширша закономірність, яку ми описуємо в тексті про спеціалізовані інструменти в B2B: галузевий модуль має сенс лише тоді, коли стоїть на працюючій платформі продажів, а не замість неї. Ширша картина трьох калькуляторів ВДЕ й того, як вони вбудовуються в магазин, — на сторінці для галузі ВДЕ.

Найчастіші запитання

Калькулятор рахує на моєму каталозі чи на якомусь еталонному?

Виключно на вашому. Монтажні елементи — це товари вашої компанії: з вашими цінами, VAT, залишками та фото. Модуль додає до них лише технічні параметри, за якими їх розпізнає алгоритм. Стартовий каталог — це відправна точка, а не прайс, нав’язаний ззовні.

Чому немає поля «кількість панелей»?

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

Звідки беруться розміри панелі?

З картки товару. Категорія панелей має позначку, яка додає поля, що описують модуль, — розміри, колір рами й потужність. Товар потрапляє до списку панелей у калькуляторі, коли в нього заповнено розміри; потужність використовує лише калькулятор енергії.

Чому той самий дах виходить то дорожчим, то дешевшим?

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

Чому кількість кронштейнів завжди парна?

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

А що із сендвіч-панелями й покрівлею з пінополістиролу?

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

Чи побачить мій клієнт, як ви доходите до результату?

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

Чи може менеджер зробити розрахунок за клієнта?

Так. У панелі компанії та сама форма рахує тим самим алгоритмом, а розрахунок прив’язують до конкретного клієнта — тоді ціни є його цінами. Кошика в панелі немає, бо замовлення оформлює клієнт; розрахунок із панелі — це кошторис, який клієнт завантажує в себе й переносить у кошик.

Звідки відомо, що результати правильні?

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

Якщо ви продаєте конструкції й хочете перестати рахувати їх у таблиці, наступний крок — два інші калькулятори: потреби в тепловій потужності і потреби в енергії. Створіть безкоштовний обліковий запис і напишіть нам — галузеві модулі ми вмикаємо перемикачем на своєму боці.