Розробка скриптів

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

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

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

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

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

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

Бот у Telegram чи Viber — це не «штучний розум», а помічник, який працює за наперед описаним сценарієм і відповідає о третій ночі так само, як опівдні.

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

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

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

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

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

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

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

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

• замовлення з сайту одразу в CRM
• залишки й ціни з 1С або BAS на сайт
• обмін товарами й замовленнями з маркетплейсами
• платіжні системи та служби доставки

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

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

Якщо дію можна описати правилом «якщо сталося оце — зроби ось те», її майже завжди можна віддати скрипту.

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

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

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

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

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

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

Біда в тому, що єдиного формату не існує. У одного постачальника колонка називається «Ціна», у другого «Опт», у третього ціна взагалі в доларах і без ПДВ. Скрипт-імпортер знає ці особливості для кожного файлу й приводить усе до одного вигляду перед завантаженням.

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

• завантаження прайсів у Excel, CSV, XML
• перерахунок цін за курсом і націнкою
• зіставлення чужих категорій із вашими
• вивантаження товарів на майданчики за розкладом

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

Порада на старті: не заливайте новий прайс одразу на живий сайт. Спершу дивимось звіт — скільки товарів додасться, у скількох зміниться ціна й скільки зникне. Дивна цифра в цьому звіті майже завжди означає помилку в файлі постачальника.

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

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

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

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

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

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