Категорія: Автоматизація

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

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

Що таке ПРРО простими словами

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

В Україні два найпоширеніші сервіси ПРРО — Вчасно.Каса і Чекбокс. Обидва роблять одне й те саме: приймають дані про продаж, реєструють чек у Державній податковій службі й віддають назад фіскальний чек, який можна перевірити в реєстрі ДПС.

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

Чому каса і облік окремо — це зайва робота

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

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

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

Як це працює в ERPJS

В ERPJS фіскалізація вбудована в сам продаж. Ви оформлюєте продажу так, як робите це завжди, а система сама відправляє чек у ПРРО — Вчасно.Касу або Чекбокс на ваш вибір — і реєструє його в податковій. Жодного другого застосунку й жодного ручного перенесення.

Що відбувається за один крок:

• продажа проводиться в обліку — товар списується зі складу, виручка потрапляє у фінанси;
• чек автоматично йде в податкову через ваш ПРРО;
• система отримує назад фіскальний номер і QR-код, за яким покупець може перевірити чек у реєстрі ДПС.

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

Паперовий чек у магазині, електронний — для інтернет-замовлень

Той самий механізм закриває два різні сценарії.

У офлайн-магазині покупець отримує звичний паперовий чек — з фіскальним номером і QR-кодом, як вимагає закон.

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

При цьому фіскалізуються всі форми оплати: готівка, картка через термінал і комбінована оплата, коли частину суми платять готівкою, а частину — карткою.

Не лише чек: уся касова зміна

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

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

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

Якщо чек пробили поза системою

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

Головне

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

Менше програм, жодного подвійного введення і завжди узгоджена картина: що продали, що списали зі складу й що зареєстрували в податковій.

Чи обов’язковий ПРРО для мого бізнесу?

У більшості випадків, якщо ви продаєте товари кінцевому покупцю за готівку чи картку, закон вимагає видавати фіскальний чек. Є окремі винятки для деяких категорій підприємців, тому конкретно ваш випадок варто звірити з чинними вимогами ДПС. Якщо чек потрібен — ERPJS дозволяє видавати його прямо із системи обліку.

Чи потрібен касовий апарат, якщо є ПРРО?

Ні. ПРРО (програмний реєстратор) замінює класичний касовий апарат: чек реєструється в податковій через інтернет-сервіс — Вчасно.Касу або Чекбокс. Окреме «залізо» купувати не потрібно.

Чим Вчасно.Каса відрізняється від Чекбокса?

Обидва — це сервіси ПРРО, які реєструють чеки в податковій. Для роботи з ERPJS принципової різниці немає: ви обираєте зручніший вам сервіс і підключаєте його. Інтеграція працює і з тим, і з іншим.

Як покупець перевірить, що чек справжній?

На фіскальному чеку є QR-код і посилання на чек у реєстрі Державної податкової служби. За ними будь-хто може відкрити чек і переконатися, що він зареєстрований офіційно.

Чи можна видавати електронні чеки для інтернет-магазину?

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

Що з поверненнями і закриттям зміни?

ERPJS реєструє в ПРРО не лише продажі, а й повернення товару, відкриття та закриття зміни з Z-звітом, службове внесення й видачу готівки — повний касовий цикл в одній системі.

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

Чому ручна робота з кабінетами маркетплейсів з’їдає прибуток?

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

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

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

Що таке інтеграція ERP з маркетплейсом і як вона працює?

Інтеграція ERP з маркетплейсом — це прямий обмін даними між вашою обліковою системою і майданчиком через його API. Замість ручного копіювання дані ходять автоматично: замовлення з маркетплейсу потрапляють в облік, а залишки і ціни зі складу виганяються назад на майданчик.

ERPJS підтримує два ключові для українського ринку маркетплейси — Rozetka і Prom.ua. Тут важливо розрізняти два потоки даних, бо вони працюють по-різному. Замовлення і нові покупці потрапляють в облік у реальному часі — менеджер бачить їх у системі одразу, без ручного введення. А каталог товарів, залишки і ціни синхронізуються за налаштованим розкладом: це не миттєвий обмін, але теж повністю без ручної праці. Ручної роботи немає в жодному з напрямків.

Важливо розуміти межу відповідальності. Маркетплейс — це вітрина: він показує товар покупцеві і приймає замовлення. ERP — це облік: він зберігає реальний склад, собівартість, фінанси і зводить усі канали продажу в одне місце. Інтеграція — це міст між вітриною і обліком.

Як автоматичний імпорт замовлень розвантажує менеджера?

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

У ERPJS повний цикл роботи із замовленнями реалізований насамперед для Prom.ua: нові замовлення підтягуються автоматично разом зі статусами, а покупці, яких ще немає у вашій базі, створюються самі. Для Rozetka акцент зроблено на синхронізації товарної частини — каталогу, цін і залишків (про це далі).

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

Що дає синхронізація залишків між складом і маркетплейсом?

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

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

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

Навіщо вести маркетплейси через ERP, а не у вбудованих кабінетах?

Тому що кабінет маркетплейсу бачить лише свій канал, а ERP зводить усі канали разом зі складом і фінансами. Кабінет Rozetka не знає про ваші продажі на Prom і в роздробі; кабінет Prom не знає про собівартість і витрати на доставку. Тільки в обліковій системі ви бачите реальну маржу по кожному товару з урахуванням комісій маркетплейсу, логістики і закупівельної ціни.

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

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

Що варто врахувати перед впровадженням інтеграції?

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

Друге — інтеграція потребує налаштування під ваш склад і прайси. Базовий каркас обміну універсальний, але тонкі правила — з якого складу брати залишки, який прайс-лист виганяти, як саме створювати нових клієнтів — налаштовуються під ваш процес. Це не «увімкнув і працює з коробки», це проєкт з налаштування, хай і невеликий.

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

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

Уявіть: ви три роки користуєтесь ERP-системою. Усі процеси налаштовані, працівники навчені, історія угод і документів — все там. А одного ранку отримуєте лист: «Сервіс закривається через 30 днів». Що ви робите?

Це не теоретичне питання. SaaS-сервіси для бізнесу закриваються регулярно — від невеликих українських стартапів до великих міжнародних продуктів. Для одних користувачів це означає 2-3 місяці хаосу й перенавчання. Для інших — повну зупинку роботи. У цій статті розберемо, як «відкритий код» в ERP захищає ваш бізнес від такого сценарію — і чим наша модель відрізняється від класичного open-source.

Що зазвичай означає «open-source ERP»?

Коли ви чуєте «ERP з відкритим кодом» — зазвичай маються на увазі великі публічні проекти: Odoo Community, ERPNext, Dolibarr. У них спільна модель:

• Публічний репозиторій на GitHub або GitLab — будь-хто може скачати код
• Ліцензія (GPL, AGPL, MIT) — формально дозволяє користуватись, модифікувати, поширювати
• Спільнота — тисячі розробників по всьому світу
• Самостійна установка — ви ставите систему на свій сервер, налаштовуєте, підтримуєте

Звучить ідеально — але є нюанси. Класичний open-source ERP вимагає сильної IT-команди для впровадження й супроводу. Для бізнесу на 10-50 людей це часто непідйомно: потрібен DevOps, БД-адміністратор, розробники під вашу галузь. Або ви наймаєте інтегратора — і знову залежите від одного виконавця.

Тому багато українських компаній обирають SaaS — швидко, без своєї IT-команди, з підтримкою «з коробки». Але SaaS повертає вас до того самого vendor lock-in: ваші дані й процеси у вендора, і якщо щось трапиться — ви знову у ситуації, з якої починали.

Як працює доступ до коду в ERPJS

У ERPJS дві опції роботи, і кожна по-своєму вирішує питання незалежності:

Опція 1: SaaS на erpjs.biz. Ви реєструєтесь, отримуєте свою компанію в нашій хмарі, починаєте працювати протягом 15 хвилин. Код бізнес-логіки на наших серверах — ви до нього прямо не маєте доступу. Це швидкий старт, але повного контролю над системою у вас немає — ви залежите від нас як від SaaS-вендора.

Опція 2: On-premise установка на ваш сервер. Ми переносимо ERPJS на ваш сервер — фізичний або хмарний. І ось тут починається головне: код бізнес-логіки — документи, процедури, реєстри, звіти, форми, валідації — автоматично опиняється у вас на диску. Не як «доступ за запитом», не «пришлемо архів коли захочете» — а як просто файли на сервері, до яких у вас прямий доступ.

Бізнес-логіка — це повноцінний читабельний JavaScript. Не мінімізований, не обфускований. Будь-який JS-розробник може відкрити файли, прочитати логіку, зрозуміти що відбувається. Системне ядро (фреймворк) при цьому поставляється як зібрана бібліотека — як прийнято в Node.js-екосистемі. Це не обмеження: всю специфіку вашої галузі та процеси ви можете адаптувати без втручання в ядро.

Це не «open-source ERP» в класичному розумінні — у нас немає публічного GitHub з тисячами контриб’юторів. Але це — технічна доступність бізнес-логіки в ваших руках, що по факту дає вам той самий рівень контролю над вашими процесами.

Що це дає вам на практиці?

Перейдемо від теорії до конкретики. Ось 4 наслідки того, що код бізнес-логіки у вас на сервері:

1. Будь-який JS-розробник може працювати з бізнес-логікою. Не потрібен «сертифікований ERPJS-консультант». Файли .js бізнес-логіки на вашому сервері — це звичайний JavaScript. Наймаєте розробника-фрілансера, штатного, аутсорсингову компанію — будь-який варіант робочий.

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

3. Маєте план Б на випадок будь-яких подій з ERPJS. Сервіс закрився, нас купила інша компанія, війна, — не важливо. Ваша система продовжує працювати на вашому сервері. Підтримку забезпечує той розробник, який у вас є зараз — або новий, якого ви знайдете.

4. Дані + код = повний контроль. Це принципова різниця від чистого SaaS, де у вас є тільки дані, але без коду ви не можете нічого змінити. І від чистого open-source без вендора, де ви маєте код, але вся відповідальність на вас.

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

SaaS чи on-premise: який варіант саме для вас?

Це не два етапи одного шляху, як часто пишуть. Це два різні продукти для різних сегментів — і обрати треба на старті.

SaaS підходить вам, якщо:

• Ви самозайнятий, фрілансер, або у вас 1-3 людини в команді
• Одна точка: кав’ярня, салон, невелика крамниця, сервіс
• Простий продуктовий каталог, прості процеси
• Питання контролю над кодом для вас не актуальне — вам потрібен швидкий старт, а не довгострокова стратегія

На цьому рівні vendor lock-in — теоретичний ризик: процеси у вас стандартні, обсяг даних обмежений, переключитись на іншу систему за потреби не буде катастрофою. Реєструйтесь, починайте за 15 хвилин, працюйте.

On-premise — це правильний стартовий вибір, якщо:

• У вас виробництво, дистрибуція, мережа магазинів, СТО, склад
• 10+ працівників і кілька юросіб
• Складні процеси, специфічна галузь, можливо — інтеграції з іншими системами
• Регуляторні вимоги (фарма, медицина, фінанси) або корпоративна політика безпеки
• Ви розумієте, що залежність від одного SaaS-вендора — це бізнес-ризик

Тут on-premise — це не «наступний рівень коли дозрієте», а правильний вибір з самого початку. Чим раніше ви на власному сервері, тим менше переробляти при зростанні. І тим менше ризик, якщо щось зміниться у нас.

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

Хто може робити вашу ERP крім нас?

Ось тут історія стає цікавою для IT-компаній та розробників. Якщо у клієнта on-premise — код у нього, отже потенційно його може супроводжувати й розширювати будь-яка зовнішня IT-компанія. Це створює простір для співпраці. Три формати, які ми бачимо реальними:

Формат 1: Реферал. Ви приводите клієнта на ERPJS, ми його ведемо. Ваша роль — продаж і первинна консультація.

Формат 2: Впровадження та кастомізація. Ви як IT-підрядник: впроваджуєте ERPJS у клієнта, налаштовуєте під його процеси, дописуєте специфічні модулі. Гроші отримуєте з клієнта прямо за свою роботу. Код бізнес-логіки у вас в руках через on-premise установку.

Формат 3: Self-hosted SaaS. Ви берете код, розгортаєте свій SaaS під своїм брендом — наприклад, спеціалізовану ERP для аптек, СТО, або салонів краси на базі ERPJS. Це white-label варіант.

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

Часті запитання

Керівник IT-студії в кінці кварталу зводить дані по проекту, який «йшов нормально». Виставлено клієнту 800 000 грн. Витрачено на нього: зарплата команди 540 000, субпідряд дизайнера 120 000, інфраструктура 25 000, переробка двох фіч 85 000. Маржа — 30 000 грн, або 3,7%. А планували 30%.

Проблема не в проекті — проблема в тому, що цей розрахунок зроблено через три місяці після старту. Якщо б керівник бачив реальну маржу на 5-му тижні, він би переоцінив скоуп, переніс субпідряд або зупинив переробку. Але цифри жили в трьох системах: тайм-трекер для годин, Excel для бюджету, 1С для рахунків. Звести їх — це окрема робота на 4 години в кінці місяця, яку завжди не встигаєш зробити вчасно.

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

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

У IT-студій, агенцій, консалтингу, інженерних бюро є типовий стек:

• Toggl / Harvest / Clockify — облік часу команди
• Excel або Google Sheets — кошторис проекту, бюджет
• 1С / SAP / окрема бухгалтерія — рахунки клієнтам, ЗП, податки
• Jira / Asana / Trello — задачі

У кожній системі — свої дані, свої формати, свої власники. Раз на місяць хтось (зазвичай керівник або фінансист) збирає це в зведену таблицю — і там виявляється, що проект, який «здавався в плюс», насправді на межі. Або вже минув її.

Конкретні проблеми, які створює розрізнення систем:

• Запізніла діагностика. Маржа порахована через 3-6 тижнів після фактичних витрат. На цей момент уже неможливо щось виправити — лише зафіксувати.
• «Невидимі» витрати. Закупили субпідряд 50 000 грн — це пройшло через бухгалтерію, але не потрапило в кошторис проекту в Excel. У звіт по проекту ці гроші не лягли.
• Подвійний ввід. Менеджер вводить години в Toggl, потім переносить їх у звіт для клієнта, потім бухгалтер створює інвойс. Одна година — три введення, помилки на кожному кроці.
• Час непомітно тече в «не оплачуване». Code review, мітинги, переробка — годин багато, а в інвойс клієнту вони не йдуть. Без класифікації часу неможливо побачити співвідношення продуктивний/непродуктивний.
• Виставлення T&M-рахунку — окремий ритуал. Експорт з Toggl, фільтрація, копіювання сум, ручний інвойс. 30-40 хвилин на проект на місяць.

Власник студії з 10 розробниками і 5 паралельними проектами втрачає 8-12 годин щомісяця тільки на звірку цих систем. І все одно отримує запізнілу картину.

Як ERPJS структурує проект?

Проект у ERPJS — це окрема картка з обов’язковими атрибутами і живим зв’язком з усім обліком компанії.

Що зберігається в картці:

• Код і назва — для швидкого пошуку і прив’язки документів
• Клієнт — посилання на картку контрагента; для внутрішніх проектів поле залишається порожнім
• Тип проекту — налаштовується вами (наприклад: розробка, підтримка, маркетинг, дослідження)
• Фази / етапи — окремий довідник, з яким працює бюджет (про це далі)
• Команда — список учасників і до п’яти менеджерів (керівник проекту, технічний лід, аккаунт-менеджер, головний дизайнер тощо)
• Контактна особа клієнта — щоб не шукати в CRM
• Дати — старт, плановий фініш, фактичний фініш
• Статус — активний / завершений
• Ієрархія — проект може бути підпроектом іншого (для великих програм)

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

Як планувати бюджет проекту з нуля?

Бюджет у ERPJS — це окремий документ з матрицею робіт і матеріалів. Не таблиця в Excel — повноцінний обліковий документ з історією, версіями і затвердженням.

Що йде в бюджет:

• Послуги / роботи (рядки з кількістю годин і ставкою)
• Товари і матеріали (з ціною закупки і продажу)
• Розбивка по фазах — кожен рядок прив’язаний до етапу проекту
• Знижки для клієнта

Система автоматично рахує по бюджету:

• Сума робіт
• Сума товарів і матеріалів
• Загальна сума контракту
• Очікуваний прибуток
• Маржа у відсотках
• Націнка

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

Окремий статус «Затверджено» — поки бюджет не затверджений керівником, він є чернеткою. Затверджений — стає базою для порівняння план/факт.

Як побачити який час реально йде клієнту, а який ні?

Це питання задає собі кожен власник IT-студії або агенції. Команда списала 200 годин на проект, інвойс на 200 годин клієнту — а маржа все одно мала. Чому?

Тому що з тих 200 годин:

• Частина — мітинги і обговорення (не завжди оплачується клієнтом)
• Частина — code review і переробка дефектів (рідко оплачується)
• Частина — час на затримки, очікування відповіді клієнта (накладні витрати)
• Частина — навчання нового розробника на проекті (інвестиція, не дохід)

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

Найпоширеніші приклади того, як компанії розрізняють час:

• Продаваний час — години, які підуть в інвойс клієнта
• Непродуктивний / не визнаний клієнтом — переробка, помилки, час за межами скоупу, які клієнт не оплатить
• Внутрішній — мітинги, навчання, R&D, написання документації, корпоративні події
• Невикористаний — простій, очікування доступів або відповіді клієнта

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

• Скільки годин з тих 200 реально пішли в інвойс
• Скільки «з’їлося» на переробку — це сигнал переоцінити проект або переучити команду
• Скільки часу на внутрішку — це інвестиція, не збиток, але треба знати скільки

Окремо — внутрішні проекти. Для часу, який не йде клієнту взагалі (R&D, внутрішня автоматизація, ваш власний продукт) заводиться проект без клієнта. Час на нього списується тими ж табелями, але в клієнтську аналітику не потрапляє. Так ви точно розрізняєте: робота на клієнтів окремо, інвестиції в компанію — окремо.

Класифікацію визначаєте ви, а не нав’язана структура. Дрібна агенція може мати 2 класи (оплачуваний / неоплачуваний), велика IT-студія — 5-7 (розробка, code review, мітинги, навчання, support, презейл тощо). Табелі затверджуються керівником — у звіти йдуть тільки затверджені години.

Які витрати автоматично потрапляють у проект?

Витрати по проекту збираються з трьох джерел і автоматично потрапляють у звіт рентабельності:

1. Час команди. Усі затверджені табелі помножуються на ставки працівників і дають загальну вартість праці на проекті. Якщо у вас різні класи часу — у витрати ідуть усі (бо праця — це факт), але у звіті можна побачити розбивку.

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

3. Матеріали зі складу. Якщо в проекті використовуються матеріали (обладнання для клієнта, серверне залізо, witnesses kits) — їх рух фіксується через списання зі складу з прив’язкою до проекту.

Все це збирається автоматично у звіт «Інформація по проекту» — без додаткових вивантажень, без ручної звірки.

Як виставляти рахунки клієнту — Fixed Price чи Time & Materials?

ERPJS підтримує обидві моделі.

Fixed Price (фіксована вартість по фазах). Бюджет містить рядки робіт, прив’язані до фаз. Коли фаза завершена — створюється інвойс із цих рядків. Поле «Виставлено» фіксує номер інвойсу — потім видно, які рядки бюджету вже виставлені, а які ні. Підходить для проектів з чітко визначеним скоупом і поетапною оплатою.

Time & Materials (за годинами). Інвойс формується із затверджених табелів за період, помножених на ставку. Окрема процедура збирає всі години з класом «продаваний» за обраний місяць (або тиждень) і створює інвойс із розшифровкою по днях. Цю процедуру можна викликати вручну в кінці місяця або поставити на крон — раз на місяць T&M-інвойси генеруються автоматично з затверджених табелів, керівнику залишається лише подивитися перед відправкою клієнту.

Можна змішувати моделі в одному проекті — наприклад, fixed price за основні фази + T&M за окремий пул годин на підтримку.

Який звіт показує рентабельність проекту в реальному часі?

Звіт «Інформація по проекту» — основний інструмент для керівника. Він показує по конкретному проекту або зведено по всіх:

• Дохід — сума виставлених і запланованих інвойсів
• Витрати — час команди × ставки + закупівлі + матеріали
• Маржа в грошах — Дохід мінус Витрати
• Маржа у % — наскільки прибутковий проект

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

Можна побудувати звіт по фазах — і побачити, що перша фаза в межах бюджету, а друга вже перевищила план на 20%. Це сигнал діяти зараз, поки треті і четверті фази не повторили історію.

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

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

Окремий інструмент — Менеджер ресурсів, календарний планувальник з трьома режимами:

• Місяць — огляд завантаженості команди на 30 днів вперед
• Тиждень — деталізація по днях тижня
• День — розбиття по годинах усередині робочого дня

Як це працює:

1. Працівники заводяться в системі як ресурси — кожен має свій код, графік роботи, інформацію про роль
2. На проектах створюються задачі — з датами початку, дедлайном і списком виконавців (один або кілька на задачу)
3. Кожна задача має тип — розробка, тестування, мітинг, дизайн, code review — типи налаштовуються з кольорами
4. Менеджер ресурсів автоматично відображає календарну сітку: рядки — працівники, колонки — дати, кольорові блоки в клітинках — задачі по типу

Що видно одразу:

• Хто перевантажений на наступний тиждень (рядок забитий блоками)
• У кого є вільне вікно (порожні клітинки)
• Як розподілений тип роботи по команді (наприклад, чи не все тестування звалилось на одну людину)
• Хто на чому працює саме сьогодні

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

Додатково — робочий процес задач: коли задача закривається з певним результатом, система автоматично створює наступну. Наприклад: задача «розробка» закрилась → автоматично з’являється задача «code review» з іншим виконавцем. Або задача «тестування» закрилась з результатом «потребує доробки» → знову задача «розробка» оригінальному виконавцю. Це базова автоматизація workflow без необхідності в окремому Jira чи Asana для малих команд.

Чесні обмеження:

• Gantt-діаграми з залежностями між задачами «А не почнеться поки не закінчиться Б» — немає. Залежності реалізуються через автоматичні переходи результатів (workflow), не через жорстку прив’язку дат
• Поля «оцінка трудоємності в годинах» на окремій задачі немає — тільки дати початку і кінця. Тривалість обчислюється з них. Якщо потрібна точна оцінка годин на кожну задачу — це обмеження поточної версії

Для команд до 30 людей з 5-15 паралельними проектами цього зазвичай достатньо. Якщо ваш стиль управління вимагає Gantt з критичним шляхом — поки ERPJS не цей вибір.

Як ERPJS інтегрує облік проектів з фінансами компанії?

Це може бути найважливіша відмінність від спеціалізованих PM-інструментів типу Jira або Asana. Облік проектів у ERPJS — не окремий модуль «збоку», а частина фінансового обліку компанії.

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

• P&L по компанії можна побудувати з розбивкою по проектах
• Cash Flow видно як в цілому, так і по проектах окремо
• Дебіторка по проектам — скільки клієнтів винні саме за цей проект
• Не потрібен паралельний облік: одна цифра не може жити в системі проектів і не існувати у фінансах

Це підхід «єдина правда» — на відміну від звичної комбінації Toggl + Excel + 1С, де кожна система знає тільки свою частину, а керівник зводить їх вручну.

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

З чого почати: 30-хвилинний план запуску першого проекту

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

Крок 1 (5 хв): створити проект. Картка — код, назва, клієнт, дати, тип. Заповнити обов’язкові поля, зберегти.

Крок 2 (5 хв): додати команду. Вибрати з довідника працівників, які працюють над проектом. Призначити одного-двох менеджерів.

Крок 3 (10 хв): запланувати бюджет. Створити документ бюджету проекту, додати 5-10 основних рядків робіт (наприклад, «розробка backend», «дизайн UI», «тестування», «менеджмент»). Вказати години і ставки. Система порахує суму, маржу, націнку.

Крок 4 (5 хв): налаштувати класи часу. Якщо ще не заведені — створити 3-5 базових класів («оплачуваний», «внутрішній», «переробка» — назви ваші).

Крок 5 (5 хв): запросити команду на ведення табелів. Показати інтерфейс табелю часу. Працівник списує години по днях з зазначенням проекту, типу роботи і класу часу.

Через тиждень роботи у вас перші затверджені табелі, перші витрати в проекті і перша картина рентабельності. Через місяць — стабільна аналітика по всіх активних проектах.

Часті запитання

Менеджер інтернет-магазину о 9:30 ранку відкриває пошту: 25 нових замовлень за ніч. На кожне треба підготувати товар, упакувати — і створити експрес-накладну на сайті Нової Пошти. По 5-7 хвилин на ТТН: логін, форма, копіювання адреси з замовлення в окрему вкладку, вибір відділення, опис вантажу, оголошена цінність, тип оплати. До обіду менеджер ще не почав пакувати — він тільки створив накладні.

Це типова картина для малого та середнього e-commerce. 25 замовлень × 6 хвилин = 2,5 години щодня, які можна повернути собі — якщо програма обліку інтегрована з Новою Поштою напряму. Розберемо, як це реально виглядає в ERPJS — без обіцянок “все автоматично”, а з конкретикою про те, що автоматизовано, а що ні.

Чому створення ТТН вручну вбиває маржу малого магазину?

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

Скільки часу йде насправді:

• Логін у кабінет НП — 30 секунд (часом доводиться відновлювати сесію)
• Перенести дані з замовлення у форму НП — 2-3 хвилини (адреса, телефон, ПІБ, вага, опис вантажу)
• Знайти потрібне відділення з 38 000+ — 30-60 секунд
• Розрахувати оголошену цінність і накладений платіж — 30 секунд
• Зберегти і роздрукувати маркування — 30 секунд

У сумі 5-7 хвилин на одну ТТН — за умови що нічого не зламалось. Якщо в кабінеті НП виліз новий капча або повільно завантажилось відділення, можна додати ще хвилину-дві.

Типові помилки при ручному введенні:

• Не та адреса. Менеджер скопіював адресу попереднього клієнта — посилка пішла іншій людині. Переадресація коштує гроші й час.
• Неправильна оголошена цінність. Менеджер забув додати ПДВ або вписав ціну однієї одиниці замість всього замовлення — клієнт отримує посилку з некоректною ціною, виникають питання при поверненні.
• Загублений номер ТТН. Менеджер створив накладну, але не вставив номер у замовлення — через тиждень клієнт пише “де моя посилка”, і ніхто не знає, яка це ТТН.
• Дубль ТТН. Два менеджери на одне замовлення створили дві накладні. Одну треба видаляти, гроші повернути.

Для магазину з 30 ТТН на день це 2,5 години роботи менеджера + 1-3 помилки на тиждень. Помилки коштують: переадресація — 50-80 грн, додатковий контакт з клієнтом — 10-15 хвилин менеджера, втрачений клієнт — кількасот або кілька тисяч гривень упущеного LTV.

Як ERPJS створює ТТН з замовлення одним кліком?

В ERPJS експрес-накладна Нової Пошти створюється з замовлення або з документа відвантаження. Менеджер відкриває замовлення → натискає кнопку “Створити експрес-накладну (НП)” → система формує всі поля з даних замовлення і відсилає запит у Нову Пошту. Через 2-3 секунди ТТН готова, номер записаний у замовленні.

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

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

Що заповнюється автоматично, а що треба ввести вручну?

Це питання, де чесна відповідь важливіша за обіцянку “все автоматично”. Розберемо по полях.

Автоматично з даних відправника:

• Місто і відділення відправника (з налаштувань вашого юр.особи в системі)
• Контактна особа, телефон відправника
• Тип вантажу (стандартний — “Товари”)
• Хто платить за доставку (з налаштувань: ви або клієнт)

Автоматично з даних замовлення:

• Оголошена цінність = сума замовлення
• Накладений платіж = сума замовлення (якщо клієнт платить при отриманні)
• Юридична особа клієнта — система розпізнає за наявністю ЄДРПОУ в картці контрагента
• Номер замовлення прив’язується до ТТН — потім видно, яка посилка для якого замовлення

Вручну вводить менеджер:

• Місто отримувача (якщо це новий клієнт, якого нема в базі)
• Відділення або повна адреса (відділення-відділення чи адресна доставка)
• ПІБ і телефон отримувача (якщо немає в картці клієнта)

Якщо клієнт постійний і вже є у базі з адресою та телефоном, менеджеру взагалі майже нічого не треба вводити — натиснув кнопку, перевірив, підтвердив. Створення ТТН займає 20-30 секунд замість 5-7 хвилин.

Як працюють довідники міст і відділень — швидко чи з затримкою?

Це важлива деталь, яку часто не помічають при виборі системи. У Нової Пошти 38 000+ відділень і поштоматів, сотні міст. Якщо кожен раз при виборі система ходить у API НП — пошук гальмує, особливо при слабкому інтернеті.

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

Оновлення довідника — або за натисканням кнопки в адміністративному модулі, або автоматично за розкладом (раз на тиждень-два). Нові відділення з’являються в системі без участі менеджера.

Що це дає на практиці:

• Пошук відділення займає 2-3 секунди замість 10-30
• Інтеграція не залежить від доступності API НП у моменті — навіть якщо у Нової Пошти збій, ви далі можете готувати замовлення, ТТН створиться пізніше
• Менеджер не відволікається від основної роботи на “загрузку довідника”

Як автоматично оновлюються статуси доставки?

Створити ТТН — половина задачі. Друга половина — знати, де вона зараз. У e-commerce це критично: клієнти питають “де моє замовлення”, менеджер відповідає, маркетинг сегментує клієнтів по статусах доставки.

ERPJS періодично звертається до Нової Пошти і опитує статус усіх активних ТТН. Інтервал налаштовується — найчастіше встановлюють раз на 1-2 години. Статус оновлюється в замовленні автоматично: “Прийнято у відправлення”, “У дорозі”, “Прибуло у відділення”, “Отримано”.

Як це виглядає в робочому процесі:

• Менеджер відкриває замовлення — бачить актуальний статус доставки без переходу в кабінет НП
• Можна побудувати звіт “всі посилки, які доставляються більше 5 днів” — і подзвонити клієнтам, попередити
• Маркетинг налаштовує автоматичні листи клієнтам — “ваша посилка прибула у відділення”, “ви її отримали — оцініть, будь ласка, замовлення”
• Бухгалтерія бачить, які замовлення з накладеним платежем уже отримані — гроші Нова Пошта поверне через 2-4 дні

Фінальні статуси (доставлено, повернено, скасовано) система перестає опитувати — навантаження на API мінімальне.

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

Друк маркування — окрема історія. Маленькі магазини друкують на звичайному офісному принтері формату А4 — і це нормально. Магазини з обсягом 50+ посилок на день переходять на термопринтери Zebra (друкують на самоклейних рулонах 100×100 мм), бо це швидше і дешевше — не треба тонера, нема обмежень на роздрукування.

ERPJS підтримує обидва варіанти:

• Друк експрес-накладної (А4) — стандартний друк на звичайному принтері. Підходить для офісу, де відправляють 5-20 посилок на день.
• Друк маркування для термопринтерів (Zebra) — спеціальний формат для самоклейних етикеток. Накладна друкується одним натисканням, ярлик автоматично наклеюється на коробку.

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

Чи можна підключити кілька магазинів або юросіб?

У малого бізнесу часто буває ситуація: одна ФОП для маркетплейсу, інша ТОВ — для B2B-продажів. Кожна — окремий кабінет у Нової Пошти, свій API-ключ.

В ERPJS таких відправників можна підключити стільки, скільки потрібно. Кожен — окремий запис у налаштуваннях інтеграції зі своїм API-ключем, типовим містом, відділенням, налаштуваннями. При створенні ТТН менеджер обирає, від якого юр.особи відправляти посилку — або це автоматично визначається залежно від замовлення (наприклад, B2C → ФОП, B2B → ТОВ).

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

Які типи доставки підтримуються?

Підтримуються всі основні режими Нової Пошти:

• Відділення-Відділення — стандартний варіант для більшості замовлень
• Відділення-Адреса — кур’єрська доставка до дверей клієнта
• Адреса-Відділення — забір кур’єром від вашого офісу або складу
• Адреса-Адреса — повна кур’єрська логістика
• Накладений платіж — клієнт платить при отриманні, ви отримуєте гроші від НП через 2-4 дні
• Передоплата — посилка йде вже оплаченою, без блокування коштів
• Повернення товару — окремий тип документу для рекламацій з боку клієнта

Чесно про обмеження: зміна відділення вже створеної ТТН через API не експонована у формі. Якщо клієнт після відправки попросив змінити пункт отримання — це треба зробити через кабінет НП. Це планується до додавання в наступних версіях.

Що з бухгалтерським обліком послуг доставки?

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

Чому так: проводки залежать від того, хто платив за доставку (ви чи клієнт), яким способом (оплата з картки, з рахунку), як це відображається в реєстрі ПДВ. Універсальної логіки немає — у кожної компанії своя схема обліку послуг доставки.

Що це означає на практиці:

• Менеджер створює ТТН — інтеграція працює автоматично
• Бухгалтер раз на місяць отримує від НП звіт і вносить підсумкову проводку
• Через інтеграцію вже видно, на яку суму послуги НП за період — звіт допомагає звірити з рахунком від НП

Це той самий підхід, що й у більшості ERP-систем — автоматизувати операційну роботу (створення ТТН, статуси) і залишити бухгалтеру повний контроль над тим, що вже потрапляє в Головну книгу.

З чого почати інтеграцію — план на півгодини

Реалістичний план підключення Нової Пошти до ERPJS — менш ніж за робочий день:

Крок 1 (5 хвилин): отримати API-ключ. Зайти у свій кабінет Нової Пошти → Налаштування → API → створити новий ключ. Скопіювати.

Крок 2 (5 хвилин): додати відправника в ERPJS. У налаштуваннях інтеграції вставити API-ключ, обрати місто, типове відділення, контактну особу. Зберегти.

Крок 3 (5-10 хвилин): завантажити довідники. Натиснути кнопку “Оновити довідники НП” — система підтягне всі міста, відділення, типи вантажу. Робиться один раз на установку.

Крок 4 (10 хвилин): тестова ТТН. Створити одне замовлення, спробувати створити ТТН. Перевірити, що номер з’явився, маркування друкується.

Крок 5 (опціонально): додати автоматичне оновлення статусів. У адміністративному модулі поставити оновлення раз на годину-дві. Це робиться один раз.

Після цього інтеграція готова до промислової експлуатації. Менеджери продовжують працювати в звичних замовленнях, але кнопка “Створити ТТН” прибирає 5-7 хвилин ручної роботи на кожну посилку.

Що це дає в результаті

Через місяць роботи з інтеграцією Нової Пошти власник магазину отримує:

• ✅ Економія 2-3 годин роботи менеджера щодня (для магазину з 30 ТТН/день)
• ✅ Менше помилок в адресах і даних — все підтягується автоматично з картки клієнта
• ✅ Прив’язка кожної ТТН до конкретного замовлення — пошук статусу займає секунди
• ✅ Автоматичні статуси доставки в реальному часі — клієнти отримують відповідь швидко
• ✅ Друк маркувань пакетом за день — менеджер працює партіями, а не по одній посилці
• ✅ Підтримка кількох юросіб або магазинів в одній системі
• ✅ Звіти по доставкам для аналізу: середній час, кількість повернень, географія

Якщо у вас більше 10 посилок на день — ручне створення ТТН на сайті НП уже коштує дорожче, ніж інтегрована система. Для 30+ посилок інтеграція окуповується за перший же тиждень.

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

Часті запитання

Прокат техніки без системи живе в Excel-таблиці і блокноті: невідомо, хто має конкретну одиницю, забуто коли проводити регламентне ТО, а спірні випадки про пошкодження залишаються “ваше слово проти мого”. ERPJS має окремий модуль “Оренда”, який закриває весь цикл — від замовлення клієнта до плану обслуговування — і пов’язує всі документи між собою.

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

Excel не відрізняє “10 перфораторів” від “перфоратор Bosch SN-001, SN-002, SN-003”. Неможливо вести історію конкретної одиниці — хто, коли, з якою наработкою. Блокнот фіксує бронювання, але не показує конфлікти і не нагадує про ТО.

5 типових проблем прокатчика з парком у 50 одиниць:

• Подвійні бронювання — заявка прийнята на вже заброньовану дату
• Спір з клієнтом про пошкодження — не задокументовано стан при видачі
• Пропущене регламентне ТО — перфоратор відпрацював 150 годин без обслуговування, ламається у наступного орендатора
• Помилки в рахунках — оренду на 18 днів виставили як 17, або забули
• Рішення “ремонтувати чи списати” наосліп — нема історії одиниці і доходу за рік

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

6 функцій в одному циклі: каталог одиниць, бронювання з валідацією, договір оренди з періодом і цінами, акти видачі/повернення з фіксацією стану, план регламентного ТО, автоматичні рахунки за періодами. ERPJS закриває це в модулі “Оренда”.

Як виглядає каталог одиниць у ERPJS?

Кожна одиниця оренди (Rental Object) — окрема картка: код + серійний номер, виробник, модель, рік, локація, тип лічильника (HOURS / KM / CYCLES / NONE) і стартове значення. Статуси: AVAILABLE / RESERVED / RENTED / MAINTENANCE / DECOMMISSIONED. Опційно — прив’язка до Основного засобу.

Модуль універсальний — використовується не тільки для обладнання. Квартири, авто, виставкове обладнання, контейнери, зали — будь-яка довгострокова оренда. Базова логіка одна. Для погодинного запису (на послуги) — є окремий модуль бронювання.

Як побачити завантаження пулу — Менеджер ресурсів

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

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

Як влаштовані замовлення і договір оренди?

Цикл починається з Замовлення на оренду (статуси DRAFT → CONFIRMED → CONVERTED → CANCELLED) — м’який документ, фіксує запит клієнта без резервування. При підтвердженні конвертується в Договір оренди — основний документ модуля.

Тип договору: OUTGOING (даємо клієнту) або INCOMING (беремо в оренду від постачальника — модуль двосторонній). Договір має 3 вкладки: Об’єкти оренди (з цінами і періодом), Обслуговування (план ТО), План оплати (графік рахунків).

Статуси: DRAFT → ACTIVE → SUSPENDED / CLOSED / CANCELLED. При підтвердженні (OK) система резервує об’єкти на дати, договір переходить в ACTIVE. Можна призупиняти (SUSPENDED — на час позапланового ремонту) і відновлювати. Договір автоматично закривається (CLOSED) коли всі об’єкти повернені.

З меню документа доступні дії: Створити рахунок, Розрахувати план оплати, Створити Акт видачі/повернення, Призупинити, Скасувати.

Як працює регламентне обслуговування — вкладка “Обслуговування”?

Регламентне ТО — критична фіча для прокатчика. Без нього техніка ламається у клієнта в середині оренди.

У Договорі оренди є окрема вкладка “Обслуговування” зі списком регламентних робіт. Для кожної заповнюються:

• Тип сервісу — наприклад, “заміна щіток”, “чистка повітрозабірника”
• Опис робіт — деталі
• Інтервал — у календарних днях АБО за показанням лічильника (наприклад, “кожні 100 мото-годин”)
• Планова і остання дата
• Статус: PLANNED → IN_PROGRESS → DONE
• Хто платить: CLIENT (клієнт окремо) або INCLUDED (входить у вартість оренди)

Інтервал за лічильником працює на реальній наработці: щоразу при поверненні нове показання порівнюється зі стартом — і коли різниця перевищує інтервал, система сигналізує “пора ТО”.

Виконання сервісних робіт — через окремий модуль “Сервісне обслуговування”.

Як налаштовується вартість і виставляються рахунки?

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

Приклад: ціна 500 грн/день, період “місяць”, оренда на 90 днів → 3 інвойси по місяцю. Або: ціна 200 грн/день, період “тиждень”, оренда на 21 день → 3 тижневих інвойси.

Налаштовується також момент виставлення: на початку періоду (передоплата) або в кінці (постоплата). У вкладці “План оплати” видно графік рахунків зі статусами PLANNED → ISSUED → PAID. Команда “Створити рахунок” формує інвойс зі стандартного модуля Sales.

Оплата — через счёт-фактури і передоплати. POS і фіскальні чеки для оренди не використовуються — оренда не роздрібний продаж. Контроль фінансів — через управлінський облік (план/факт надходжень, заборгованість клієнтів).

Як фіксується стан техніки при видачі і поверненні?

Акт видачі (Rental Issue Act): кондиція при видачі, аксесуари і комплектація, показання лічильника, фото (як attachments документа). Клієнт підписує — юридичний документ.

Акт повернення (Rental Return Act): нове показання лічильника (різниця = наработка), кондиція при поверненні, опис пошкоджень, відсутні частини, цільовий статус — AVAILABLE (в пул для наступних оренд) або MAINTENANCE (одразу в ремонт без проміжних операцій).

Якщо менеджер вказав пошкодження або відсутні частини, або цільовий статус MAINTENANCE — автоматично активується прапор “Є зауваження”. У переліку повернень одразу видно проблемні позиції.

При будь-якому спорі з клієнтом — підписаний акт з фіксованим станом. Не “ваше слово проти мого”.

AI-агент і MCP для прокатчика

ERPJS підтримує MCP-протокол — AI-агент має прямий доступ до системи на читання і запис. Менеджер прокату питає агента в Telegram без переходу в інтерфейс:

• “Які одиниці вільні з 15 травня?”
• “Коли ТО для SN-001?”
• “Створи Замовлення на оренду перфоратора SN-001 з 15 по 17 травня”

Документи створюються як чернетки з підтвердженням від користувача. Реальний кейс — AI-агент створив 3 документи з одного повідомлення в Telegram.

Часті запитання

Власнику магазину часто пропонують два інструменти окремо: касову програму “для пробивання чеків” і програму обліку “для бухгалтерії”. Працює, але кожен продаж треба двічі вводити. У цьому пості розберемо, чому це більше не працює і як виглядає інтегрована POS-каса з онлайн-фіскалізацією через Checkbox у системі ERPJS.

Чому окрема касова програма більше не варіант?

Сценарій з життя: касир пробив чек на 5 одиниць товару. Касова програма надіслала фіскальний чек у податкову — все добре. Але товар на складі не зменшився, бо складська програма — окрема. Бухгалтер увечері імпортує дані з каси через Excel, помилки в SKU, частина чеків загубилась. До кінця місяця залишок розходиться на 30 одиниць.

Окрема касова програма має 4 системні проблеми:

• Подвійний ввід. Кожен продаж треба обліковувати двічі — у касі й у складі
• Розрив у часі. Залишок на складі не оновлюється в real-time, тільки після імпорту
• Втрачені чеки. Якщо щось не імпортувалось — продаж “є в касі, нема в обліку”
• Звіти не сходяться. Бухгалтерські та операційні дані живуть у різних системах

Інтегрована POS-каса вирішує це архітектурно: продаж на касі — це одночасно чек у податкову, списання зі складу і запис у касовій книзі.

Як працює онлайн-фіскалізація через Checkbox?

Checkbox — це сервіс програмних реєстраторів розрахункових операцій (ПРРО), який замінює класичний касовий апарат для українських ФОП і ТОВ.

Логіка роботи:

1. Касир робить продаж у POS-інтерфейсі
2. POS формує дані чека (товари, ціни, ПДВ, спосіб оплати) і надсилає в Checkbox API
3. Checkbox реєструє чек у податковій (ДПС) і повертає фіскальний номер
4. POS друкує чек з фіскальним номером або надсилає клієнту в електронному вигляді

Все відбувається за 2-3 секунди. Без касового апарата, без друкарського стрічки, без пов’язаних витрат на обслуговування. Чек має повну юридичну силу.

РРО vs ПРРО — у чому різниця?

Що дає POS, інтегрована з обліком?

Кожен чек у POS, інтегрованій з обліком ERPJS, одночасно робить три речі:

1. Списує товар зі складу. Залишок оновлюється миттєво. Якщо у вас 2 точки — система фіксує, з якого складу списано.

2. Передає чек у Checkbox для фіскалізації. Податковий номер з’являється в системі, чек має юридичну силу.

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

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

Які функції обов’язкові на касі для роздрібу?

Базовий набір POS-інтерфейсу для роздрібного магазину:

• Швидкі кнопки — топ-20 товарів одним натиском, без пошуку
• Сканер штрих-кодів — пошук товару за EAN/UPC, автододавання в чек
• Пошук по назві — fallback, якщо штрих-код не зчитався
• Знижки і акції — % або фіксована сума на позицію або весь чек
• Декілька способів оплати — готівка, картка, Apple/Google Pay, бонуси
• Часткова оплата — половина готівкою, половина карткою (один чек)
• Повернення товару — окремий тип чека з посиланням на оригінал
• Електронний чек на email/SMS — клієнт отримує копію без папера
• Зміна продавця — у середині дня (підзвітність)
• Z-звіт — закриття зміни в одне натискання

У ERPJS POS-інтерфейс працює як на ноутбуці продавця, так і на планшеті/смартфоні. Один інтерфейс — без різниці на пристрої.

Як налаштувати POS у ERPJS — за один день

Поетапний план для магазину, який має склад в ERPJS і тільки додає касовий шар:

Крок 1 (30 хв): реєстрація у Checkbox. Зайти на checkbox.ua, завести ФОП/ТОВ, отримати API-токен. Документи з податкової — стандартні.

Крок 2 (15 хв): підключення Checkbox в ERPJS. У налаштуваннях ERP вставити токен, обрати касу. Тестовий чек на 1 грн — щоб перевірити фіскалізацію.

Крок 3 (1-2 год): налаштування швидких кнопок. Перетягнути топ-20 товарів у POS-інтерфейс. Один раз — далі редагується по потребі.

Крок 4 (30 хв): підключення обладнання. Сканер штрих-кодів через USB або Bluetooth. Якщо є фіскальний принтер — теж підключаємо.

Крок 5 (1 год): тренування касира. 5-10 тестових продажів, повернення, Z-звіт. Касир освоює інтерфейс за 30 хвилин — він зрозумілий.

Крок 6: робочий день. Перший реальний день — спостерігайте за швидкістю, адаптуйте кнопки. Через тиждень POS працює “невидимо”.

Скільки коштує перехід на онлайн-фіскалізацію?

Запуск: 0 грн. Реєстрація у Checkbox безкоштовна, підключення в ERPJS — стандартна функціональність.

Підписки на місяць:

• Checkbox: безкоштовна модель доступна для ФОП на спрощеній. Платні плани — від ~150 грн/міс
• ERPJS: безкоштовний тариф для старту, платні — за кількість користувачів і модулів

Обладнання (опціонально):

• Сканер штрих-кодів — від 800 грн (USB), 2 000 грн (Bluetooth)
• Принтер чеків — від 2 500 грн (опціонально, можна без — електронні чеки)
• Підставка/тримач для планшета — 500-1 500 грн

Магазин, який стартує з нуля, виходить на робочий стан за 5-10 тис. грн обладнання + підписки від 150-500 грн/міс. Для порівняння: класичний РРО = 10-15 тис. грн + щомісячне обслуговування 500-1 000 грн.

Що це дає в результаті

За три місяці з інтегрованою POS-касою власник магазину отримує:

• ✅ Точний залишок на складі в реальному часі — без щотижневих ревізій “на око”
• ✅ Звіт продажів за будь-який період — одна кнопка, без Excel
• ✅ Маржинальність по товарах і групах — видно, що приносить прибуток
• ✅ Касова книга — без ручного імпорту, готова для бухгалтерії
• ✅ Електронні чеки — клієнти отримують копію навіть якщо втратили паперову
• ✅ Економія на обладнанні — мінус 10-15 тис. грн порівняно з РРО

Для повного огляду — наш недавній пост “Програма обліку для магазину: 5 ознак, що пора автоматизувати”.

Часті запитання

«ERP — це для великих корпорацій, нам це не потрібно». Це найпоширеніший міф серед власників малого бізнесу. Реальність інша: сучасні ERP-системи давно масштабуються під бізнес будь-якого розміру — від 3 співробітників до 500. І часто саме малому бізнесу ERP потрібна найбільше, тому що ресурсів на помилки в обліку у нього менше.

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

Що таке ERP і чим вона відрізняється від звичайної програми обліку?

ERP (Enterprise Resource Planning) — це єдина система, яка поєднує облік, склад, фінанси, продажі, виробництво та інші бізнес-процеси в одній базі даних. Головна відмінність від окремих програм: усі модулі працюють з однаковими даними в реальному часі.

Просте порівняння:

• Окремі програми: складська програма + бухгалтерія + Excel для продажів + CRM. Дані між ними не синхронізовані, треба вручну дублювати, звіти не збігаються.
• ERP-система: продали товар → автоматично списано зі складу → автоматично сформовано проводку → клієнт бачить оновлений баланс у CRM. Одна подія — всі модулі оновились.

У ERPJS 16 модулів: облік товарів, склад, продажі, закупівлі, фінанси, виробництво, CRM, сервіс, POS-каса, бронювання, оренда, проєкти, HR, інтеграції (Нова Пошта, Checkbox), звіти. Усі працюють в єдиній базі.

Чи потрібна ERP малому бізнесу зараз, чи це для великих?

Коротка відповідь: якщо ви впізнали себе хоча б у 2 з 5 ознак нижче — ERP вам вже потрібна. Це не про розмір компанії, а про складність процесів.

5 ознак що ERP вже потрібна:

1. Більше 100 SKU на складі. Ручний облік 100+ позицій перестає бути надійним — залишки розходяться, пересортиця стає нормою.
2. Команда 5+ осіб працює з обліком. Коли один файл Excel редагує кілька людей одночасно — версії починають конфліктувати.
3. Excel-файл з 10+ вкладками. Якщо ваш головний облік — це 15 взаємопов’язаних листів Excel, це вже не таблиця, а хистка саморобна ERP без контролю цілісності.
4. Ви не знаєте реальний прибуток за минулий місяць. Чистий прибуток вважається руками тиждень після закриття періоду — це ознака розірваних даних.
5. Є декілька каналів продажів. Сайт + маркетплейс + офлайн + дзвінки = якщо замовлення збираються окремо, ви втрачаєте контроль над залишками.

Коли Excel перестає справлятися — ми детально розібрали в статті «Excel vs ERP: коли таблиці перестають працювати».

Скільки коштує ERP для малого бізнесу?

Діапазон ринкових цін для малого бізнесу — від 0 до 200 USD на місяць на всю компанію. Конкретні опції:

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

З яких модулів починати впровадження ERP?

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

Етап 1 (місяць 1-2): склад + продажі. Заведіть каталог товарів, внесіть залишки, почніть виписувати документи продажу через систему. Це вже дасть контроль над залишками та чіткі первинні документи.

Етап 2 (місяць 3-4): закупівлі + фінанси. Додайте документи надходжень, контрагентів, банківські виписки. Тепер у вас закритий цикл «закупка → склад → продаж → оплата».

Етап 3 (місяць 5-6): CRM + аналітика. Підключіть облік клієнтів, воронку продажів, звіти. На цьому етапі ви починаєте отримувати реальну картину бізнесу.

Етап 4 (за потреби): виробництво, бронювання, POS, HR. Спеціалізовані модулі вмикаються тоді, коли є відповідна потреба в бізнесі.

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

Чим ERP краща за набір окремих програм?

Типовий «зоопарк» у малому бізнесі: 1С для бухгалтерії + Excel для складу + amoCRM для продажів + Google Forms для бронювання + Telegram для комунікації з клієнтами. Виглядає робочо, але має 4 системні проблеми:

• Подвійне введення даних. Замовлення треба внести в CRM, потім вручну списати зі складу в Excel, потім провести в бухгалтерії. 3 входження для однієї події — часу витрачається втричі більше.
• Немає єдиної правди. Скільки у нас на складі? Excel каже 48, склад каже 45, 1С каже 50. Кому вірити?
• Неможлива реальна аналітика. Щоб побачити прибуток по клієнту, треба звести дані з 4 систем — це робота на півдня замість кнопки «звіт».
• Ризик втрати даних. Google Forms може відключити доступ, співробітник звільнився з правами на Excel — частина даних недоступна.

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

Які ризики впровадження ERP для малого бізнесу?

Чесно — ризики є, і про них треба знати заздалегідь. Ось три основні:

Vendor lock-in (прив’язка до вендора). Класичні ERP з закритим кодом тримають ваші дані у пропрієтарних форматах. Якщо ціна виростає вдвічі — вам немає куди піти. В ERPJS бізнес-логіка відкрита: дані ваші, експорт можливий у будь-який момент, партнер або ваш програміст може самостійно дорабатувати систему.

Складність міграції даних. Перенести 500 товарів, 2000 контрагентів та залишки з Excel — це робота на 1-2 тижні. Вирішення: починати з імпорту через Excel-шаблони (ERPJS їх підтримує) та поетапного внесення.

Опір команди. Співробітники звикли до старих процесів і опираються новому. Вирішення: впровадження через «агента змін» (одна людина веде проєкт), поступове підключення модулів, навчання перед стартом.

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

Як обрати ERP-систему для малого бізнесу?

5 практичних критеріїв для вибору:

1. Поступове впровадження. Перевірте чи можна почати з 1-2 модулів і нарощувати. Big-bang впровадження для малого бізнесу небезпечне.
2. Українська локалізація. ПДВ, Єдиний податок, Checkbox, Нова Пошта — усе має працювати «з коробки», а не через костилі.
3. API для інтеграцій. Сайт, маркетплейс, платіжний агрегатор — система має підключатись до ваших каналів.
4. Відкритий код або ясні умови лицензування. Що буде, якщо вендор підніме ціну вдвічі? Ваші дані мігруються? Можете ви або партнер доробити систему самостійно?
5. Підтримка з вашим бізнесом. Малому бізнесу потрібна підтримка, що розуміє українські реалії — не «тікет в Індію на 3 доби».

ERPJS задовольняє всі 5 критеріїв: поступове впровадження (16 модулів вмикаються окремо), повна українська локалізація, відкритий API, відкритий код бізнес-логіки, українська підтримка та партнерська мережа.

Часті запитання

Ваші клієнти записуються через телефон, Viber, Instagram Direct? Ви ведете розклад у блокноті або Google Calendar? Тоді ви точно знаєте ці проблеми: забуті заявки, подвійні записи на один час, працівники не знають про нових клієнтів. Є рішення — автоматизація запису через вебсайт.

У цій статті розберемо, як онлайн-бронювання працює в ERP-системі і чому це ефективніше за окремі додатки для запису.

Чому месенджери та блокноти не працюють для запису клієнтів?

Коли бізнес маленький — 5 клієнтів на день — блокнот справляється. Але при зростанні починаються проблеми:

• Клієнт написав у Viber, а ви забули перенести в розклад. Результат — клієнт прийшов, а його не чекали.
• Два клієнти записані на один час. Ви перевіряли вільні слоти по пам’яті, а не по системі.
• Працівник не знає про заявку. Клієнт записався вчора ввечері через месенджер — а майстер дізнався тільки коли клієнт стоїть перед ним.
• Немає історії клієнта. Що замовляв минулого разу? Які були побажання? Хто його обслуговував?
• Фінанси окремо. Запис в одному місці, оплата в іншому, матеріали в третьому. Неможливо зрозуміти рентабельність послуги.

Знайомо? Тоді час переходити на автоматизований запис. Як ми раніше розповідали — Excel та месенджери перестають працювати при масштабуванні.

Як працює онлайн-бронювання в ERPJS?

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

Крок 1: Клієнт відкриває форму запису на вашому сайті. Бачить вільні дати, час, послуги та спеціалістів. Обирає зручний слот і залишає контактні дані.

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

Крок 3: Працівник отримує сповіщення. Через Telegram, email або всередині системи — в реальному часі. Не потрібно перевіряти розклад вручну.

Крок 4: Клієнт отримує підтвердження та нагадування. Автоматичне нагадування за день або за годину до візиту — менше “не прийшов”.

Подивіться, як це виглядає на практиці, у нашому відео-огляді модуля бронювання.

Що отримує бізнес від автоматизації запису?

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

Чим це краще за окремі додатки для запису?

На ринку є десятки додатків для онлайн-запису: Calendly, Booksy, Altegio. Вони гарно вирішують одну задачу — запис. Але у них є спільна проблема: вони не зв’язані з обліком.

В ERPJS бронювання — це частина єдиної системи:

• Запис → Замовлення на обслуговування. З бронювання автоматично створюється робочий наряд для працівника з переліком робіт.
• Послуга → Матеріали. Система списує витратні матеріали (запчастини, фарба, засоби) зі складу. Ви знаєте собівартість кожної послуги.
• Оплата → Фінанси. Рахунок клієнту створюється з послуги. Оплата потрапляє в Головну книгу. Прибутковість — автоматично.
• Клієнт → CRM. Вся історія взаємодії в одному місці: дзвінки, візити, замовлення, рахунки, оплати.

Окремий додаток для запису — це ще один інструмент, який не зв’язаний з рештою. ERP-система — це один інструмент для всього.

Для яких бізнесів підходить онлайн-запис?

Модуль бронювання в ERPJS підходить для будь-якого бізнесу, де є запис на час + працівник/ресурс:

• Сервісні центри — запис на ремонт техніки, розподіл між майстрами. Детальніше про сервісні послуги.
• Салони краси та барбершопи — запис до конкретного майстра, облік матеріалів (фарба, засоби).
• Медичні клініки — запис до лікаря, історія пацієнта, нагадування про візит.
• Спортивні клуби — бронювання занять, тренерів, залів.
• Автосервіси — запис на ТО, розподіл по підйомниках, облік запчастин.
• Прокат/оренда — бронювання обладнання на конкретні дати та час.

Як підключити онлайн-запис на свій сайт?

Процес налаштування займає кілька годин:

1. Створіть каталог послуг. Внесіть перелік послуг, тривалість кожної, вартість. Наприклад: “Заміна екрану iPhone — 1 година — 2500 грн”.

2. Додайте спеціалістів. Вкажіть хто виконує які послуги та графік роботи кожного працівника.

3. Налаштуйте ресурси. Якщо у вас є обладнання (підйомник, крісло, кабінет) — додайте його як ресурс з розкладом доступності.

4. Вставте форму на сайт. ERPJS надає віджет або посилання на форму бронювання, яке вбудовується на ваш сайт.

5. Налаштуйте сповіщення. Оберіть як повідомляти працівників (Telegram, email) та клієнтів (SMS, email).

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

Часті запитання