English עברית Українська Polski Русский
← Назад Кейс Демо

ERP Scheduling System

puzzleerp
Архітектура та функціональність  |  Листопад 2026

1. Про ERP Scheduling System

ERP Scheduling System створена для науково-освітніх центрів, які пропонують поглиблене вивчення окремих предметів (фізика та/або хімія) учням з різних шкіл. У таких центрів є специфічні вимоги до побудови системи розкладу — потрібно узгоджувати дні та час навчання одразу з усіма школами, звідки набрані учні в навчальні групи. Застосунок полегшує різним категоріям співробітників — адміністраторам, вчителям, лаборантам — керувати десятками робочих процесів: від взаємодії зі школами-партнерами до розподілу лабораторій та навчальних кабінетів виходячи з обладнання, замовленого викладачами. Керівництву центру система дає змогу керувати навантаженням викладачів (загальний робочий час, кількість годин викладання, кількість учнів у групах) та приймати різні управлінські рішення. Система також дозволяє збирати, обробляти та аналізувати всі статистичні дані, пов'язані з роботою центру.

У таких освітніх центрів розклад не буває статичним. Він змінюється щодня — переноси, заміни, скасування. Головне завдання Scheduling System — зробити процес керування розкладом та ресурсами освітнього центру прозорим, інтуїтивно зрозумілим та зручним у роботі.
Ключові можливості
Ключові можливості
Технічні гарантії
Незмінність даних
Атомарність транзакцій
Гранулярні права доступу
Токен доступу з автовиходом
Захист від конфліктів на рівні БД
Zero Trust Cloudflare Tunnel

2. Хто працює в системі

У системі вісім ролей. Одному співробітнику може бути призначено декілька ролей одночасно.

Роль Хто це Що робить
Суперадмін Технічний керівник Повний доступ. Керування довідниками, співробітниками, загальними налаштуваннями.
Адміністратор Будь-який співробітник з адміністративними правами — зокрема як додаткова роль Розглядає вхідні запити на зміни в розкладі, уточнює параметри та підтверджує їх. Єдиний, хто реально вносить зміни в дані — approve або reject.
Учитель Викладач Ініціює зміни в розкладі: перенесення, скасування, заміни, замовлення обладнання. Усе оформлюється як запит до адміністратора — учитель нічого не змінює напряму.
Лаборант Співробітник лабораторії Бачить список майбутніх уроків із замовленим обладнанням. Готує та доставляє комплекти. Не створює і не змінює замовлення — тільки виконує.
Директор Директор освітнього центру Повний перегляд розкладу та звітів за будь-який період. Керує навантаженням учителів і призначає заміни. Може також вести уроки (якщо призначений учителем).
Завуч Заступник директора з навчальної роботи Перегляд розкладу та звітів по вчителях свого предмета. Керує навантаженням учителів і призначає заміни. Може також вести уроки (якщо призначений учителем).
Секретар Секретар / адміністратор офісу Тільки читання: повний розклад, усі звіти, будь-який період. Не може вносити зміни.
Координатор центру Співробітник центру Веде взаємодію зі школами з боку освітнього центру. Супроводжує школи, координує організаційні питання.
Права доступу налаштовуються гранулярно — не тільки за роллю в цілому, а й за окремими діями на конкретних екранах (наприклад, "відкрити день для редагування" або "призначити заміну вчителя" може бути дозволено директору та завучу окремо від повного доступу адміністратора). Це дозволяє точково розширювати права без ризику дати зайве.

3. Основні процеси

3.1 Річний шаблон та перестроювання

Розклад побудований у два рівні. Верхній рівень — річний тижневий шаблон: типове навантаження кожного вчителя та групи. Нижній рівень — фактичний потижневий розклад на весь навчальний рік, згенерований на основі цього шаблону.

1Адміністратор редагує шаблон — переставляє вчителя, час або день слота шаблону.
2Система перебудовує розклад — за секунди оновлює тільки ті тижні та слоти, яких стосується зміна: змінені — оновлюються, нові — додаються, скасовані — знімаються. Весь розклад ніколи не перебудовується з нуля.
3Поточна робота не втрачається — усе, що вже накопичилося навколо уроків, яких перестроювання не торкнулося — замовлення обладнання, коментарі, запити вчителів — залишається без змін.
Кабінет для уроку підбирається не довільно — він відповідає реальній потребі: витяжна шафа, раковина, можливість затемнення або вже замовлене обладнання.
Урок, знятий разовим скасуванням, залишається в розкладі перекресленим — учитель і учні бачать, що цього дня уроку не буде. А якщо урок прибрала перебудова самого шаблону (зміна слоту, скорочення навчального року) — він переходить в окремий статус archived: повністю зникає з усіх розкладів і вітрин, щоб до кінця року не накопичувались «уроки-привиди», але фізично залишається в таблиці — зовнішні ключі історії заявок та аудиту не дозволяють його видалити.

3.2 Зміни в розкладі

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

1Учитель подає запит — вказує, що саме потрібно змінити: перенести урок, скасувати його, скоригувати замовлення обладнання або змінити кабінет. Директор і завуч, якщо вони також викладають, користуються тією ж системою, що й звичайні вчителі.
2Система перевіряє конфлікти — під час подання показує, чи зайнятий кабінет або вчитель у цей час. Учитель бачить попередження і може скоригувати запит або все одно подати його з позначеним конфліктом — тоді адміністратор вирішує це вручну.
3Адміністратор розглядає запит — бачить чергу вхідних запитів, за потреби уточнює деталі з учителем і підтверджує зміну.
4Розклад оновлюється — після кожної підтвердженої зміни розклад одразу оновлюється, і всі одразу бачать актуальний стан.
5Урок завершується — система автоматично позначає його завершеним після настання часу закінчення уроку.
Повна історія змін зберігається автоматично — адміністратор завжди може побачити, яким був розклад до зміни і хто її зробив.
Кабінет уроку можна змінити трьома способами: призначити напряму, витіснити урок із зайнятого кабінету (система сама підбирає новий, а якщо вільного немає — залишає урок без кабінету, не блокуючи дію) або поміняти місцями кабінети двох уроків. Лист про зміну кабінету надходить не на кожен рух усередині сесії редагування, а один раз при закритті дня — і тільки тим, у кого кабінет за підсумком реально змінився.

3.3 Підготовка обладнання

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

3.4 Заміна вчителя

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

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

3.5 Наповнення системи даними (робочий процес)

Дані вносяться в суворому порядку — кожен крок залежить від попереднього.

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

4. З чого складається система

Система побудована з кількох незалежних компонентів, кожен відповідає за свою частину:

Компонент Що робить
База даних Зберігає всі дані та забезпечує виконання всіх правил: перевірку, блокування, історію змін
API-сервер Приймає запити, перевіряє, хто що може робити, і передає команди в базу даних
Веб-інтерфейс Scheduling System, повністю на івриті (RTL)
Коридорні табло Окремі екрани для коридорів центру — актуальний розклад дня для вчителів і спрощена версія для учнів, без особистого входу (автентифікація за статичним ключем пристрою)
Сповіщення Подієвий конвеєр: кожна дія (запит подано/схвалено/відхилено, замовлення обладнання, заміна викладача, обслуговування сервера) записує подію в чергу всередині тієї самої транзакції — збій запису ніколи не блокує саму дію. Фоновий відправник визначає отримувачів за роллю, предметом і учасниками події з таблиці правил, формує лист і надсилає його через транзакційний поштовий сервіс — з автоматичними повторами та вимикачем у адміністратора. Месенджери (Telegram, WhatsApp) залишаються можливим напрямом розвитку.
Інфраструктура Розгорнута в Docker-контейнерах на сервері AWS, з автоматичним щоденним резервним копіюванням бази даних

5. Надійність і безпека