Какво е изграждане на график?
Изграждането на график е планиращият слой на модул Персонал в Ordering.Tools. Отворете го и видите всички смени на екипа за седмицата на един drag-and-drop grid: кой работи кога, каква роля покрива, коя секция от пода е негова. Кликнете празна клетка за добавяне на смяна за 5 секунди; кликнете запълнена клетка за размяна, редактиране или отмяна. Grid-ът е keyboard-навигируем, mobile-friendly на таблет и записва всяка промяна с audit trail.
Повечето мениджъри не мислят в „шаблони“ — те мислят „копирай миналата седмица, нагласи петък“. Затова Изграждането на график е без шаблони по дизайн. Натиснете „Копирай от миналата седмица“ и grid-ът дублира SCHEDULED + CONFIRMED смени към следващата, прескачайки конфликти с (служител, дата, начален час) уникалния ключ. Нагласете промените, натиснете „Публикувай“, готово. Заявки за отпуск се появяват в кутията с засегнатите смени в линия — одобрете и сблъскващите се смени се отменят атомно.
Защо мениджърите спират да се страхуват от деня за график
Копирай миналата седмица, редактирай, публикувай
Най-бързият начин да планирате следващата седмица е да я планирате като миналата. Един бутон материализира пълно дублиране; няколко плъзгания нагласят за отпуски и новото покритие на терасата; публикуване за под 4 минути за заведение с 30 души.
Заявки за отпуск в полезрението
Заявките не седят в отделна кутия, която забравяте да отворите. Те изплуват на rota grid-а за датите, които покриват, с одобрение с един клик и автоматична отмяна на сблъскващи смени в същата транзакция.
Свободни смени, които персоналът може да клейм-не
Анна се обажда болна в 17:00. Постнете слота като свободна смяна, задайте кой може да я види (всички / по роля / по покана) и първият служител, който клейм-не печели — SQL-level guard прави двойно claim-ване невъзможно.
На живо на всяко устройство
Всяка промяна се излъчва до всяко свързано устройство. Mobile екранът „Моите смени“ на екипа отразява новия график в момента, в който публикувате — без Slack съобщение, без обаждания „видя ли новия график?“.
Как работи изграждането на график
Отворете grid-а на тази седмица
Всеки ред е служител, всяка колона е ден от седмицата. Празните клетки са свободни слотове; запълнените показват роля, време и цвят на секция. Grid-ът зарежда за под 1.5 секунди за прозорец 4 седмици × 30 служители.
Кликнете „Копирай от миналата седмица“
Издърпва SCHEDULED и CONFIRMED смени от предишния понеделник-неделя в същите дни от седмицата, която гледате. Резултатният toast показва колко смени са копирани и колко пропуснати поради конфликти.
Нагласете разликите
Плъзнете смяна от петък към събота. Кликнете празна клетка за добавяне на нов слот. Десен клик на смяна за изтриване или размяна. Всяка промяна записва в StaffAuditLog с актьора и before/after снимка.
Одобрете отпуски, публикувайте
PENDING заявки за отпуск се появяват най-горе на rota-та със засегнатите смени откроени. Одобрете заявка — сблъскващите се смени се отменят в същата транзакция и заявителят получава имейл + push известие.
Изграждане на график — детайли
Drag-and-drop седмичен grid
Grid-ът е графикът — без отделен template editor. Всяка смяна е реален, насрочен StaffShiftAssignment ред, не „планиран“ статус, който да публикувате после. Плъзгане за местене, клик за редактиране, десен клик за изтриване.
- Рендерира 4 седмици × 30 служители за p95 < 1.5 секунди
- Keyboard навигация през дни и редове на служители
- Цветово кодирани по секция за бързо визуално сканиране
- Конфликти (припокриващи се начални часове за един служител) предотвратени на ниво unique key
Копирай от миналата седмица
Един бутон дублира публикувания график от предишната седмица в следващата, прескачайки конфликти. Опционален userIds филтър, така че да копирате модела само на един екип, без да притеснявате другите. Всяко дублиране записва StaffAuditLog ред с copied/skipped броя.
- Прескача сблъсъци с (заведение, потребител, дата, startTime) unique ключа — без презаписване
- Опционален userIds филтър за избирателно дублиране
- Резултатен toast казва колко смени са копирани срещу пропуснати
- Audit ред записва източникова седмица, дестинационна седмица и актьора
Кутия за отпуски с автоматична отмяна
Заявките за отпуск носят тип (отпуск / болничен / личен / неплатен / родителски), диапазон от дати, опционален частично-дневен прозорец и опционален URL към сканиран болничен. Одобрението е с един клик; сблъскващите се смени се отменят в същата $transaction.
- Видове отпуск, болничен, личен, неплатен, родителски
- Частично-дневни прозорци — само смени, чието време се припокрива, се отменят
- Атомно одобрение + отмяна: никога половинчато
- Email + web-push известие до заявителя при всяко решение
Маркетплейс за свободни смени
Постнете слот, когато имате нужда от покритие; персоналът клейм-ва от телефона; вие одобрявате един. OpenShift status guard на SQL ниво прави race-а невъзможен за загуба: само едно одобрение успява, другите виждат 409 веднага.
- Видимост: ALL · ROLE · INVITED — съответствайте на правилния пул от персонал
- Атомен OPEN→CLAIMED guard чрез prisma.openShift.updateMany
- Одобряването на claim материализира CONFIRMED StaffShiftAssignment за победителя
- Другите PENDING claim-ове се отказват автоматично в същата транзакция
Къде изграждането на график прави разликата
Седмично планиране на 30 души за под 4 минути
Отворете grid-а в понеделник сутрин. Натиснете „Копирай от миналата седмица“. Нагласете 6 клетки за кетъринг събитието в петък и отпуска на Анна. Публикувайте. Общо време: 3:42. Предишният spreadsheet workflow отнемаше 90 минути.
Анна се обажда болна в 17:00
Отменете смяната ѝ в rota grid-а (един клик), постнете OpenShift с изтичане 17:30. Трима сервитьори я виждат, двама claim-ват за 4 минути, одобрявате тази с по-голям стаж. Готово за под 5 минути — без скрембъл в групов чат.
Заявка на Мария за отпуск, 2 седмици напред
Мария подава 7-дневна VACATION заявка от телефона. Изплува във вашата кутия с 5-те засегнати смени откроени. Одобрявате — сблъскващите се смени се отменят и изплуват като пропуски в rota grid-а за вас да попълните чрез OpenShift постове.
Размяна по средата на смяна с екипа на кухнята
Петър (сервитьор) и Иван (хост) решават да си разменят смените. Мениджърът отваря rota grid-а, избира двете смени, натиска Swap — и двата оригинала се отменят, и двата нови SWAP-source реда се създават с пълна линия, без двойно резервиране някога.
Multi-venue мениджър покриващ 3 локации
Превключете заведения от AdminShell venue picker; същият rota интерфейс се появява за новото заведение със собствения си персонал, секции и смени. Без ментален context switch — всяко заведение използва същия grid, същите потоци.
Персоналът планира своята си седмица
Сервитьорите отварят „Моите смени“ на телефона си (под /admin/profile/shifts), виждат предстоящите 60 дни на пръв поглед, claim-ват свободни смени, които съответстват на тяхната достъпност, и подават заявки за отпуск за периодите, в които им е нужен — без никога да звънят на мениджъра.
Планиране на rota, което уважава начина, по който мениджърите всъщност мислят
Повечето rota инструменти ви натрапват абстракция първо: построете шаблон, запазете го, приложете го към следващата седмица, редактирайте overrides, публикувайте. Това са три стъпки за проблем, който има една форма — повечето седмици са 90% като миналата седмица. Изграждането на график напълно прескача шаблона. Графикът Е данните; копирането на графика Е шаблонът; нагласяне и публикуване е един непрекъснат жест вместо три отделни.
Защо drag-and-drop побеждава форми за планиране на смени
Типична смяна на смяна е 3 плъзгания с мишката: Анна разменя с Мария в петък; Петър взима свободния слот в събота; новият човек се присъединява към обедния пик. Формите ви карат да препишете роля, дата и време за всяка промяна. Drag-and-drop променя времевия компонент (плъзнете колона) и компонента за персонал (плъзнете ред) едновременно — един жест, две промени, sub-second feedback. През седмица редакции, спестеното време се натрупва: формите отнемат 90 минути, drag-and-drop отнема 4.
Отпуски и rota са един workflow, не два
Повечето платформи доставят отпуски като отделна кутия, скрита зад таб. Мениджърите забравят да я проверят; чакащи заявки се натрупват; сблъскващи смени отиват към персонал, който вече е във ваканция. Изграждането на график показва всяка PENDING заявка на същия екран със смените, които биха се отменили. Виждате компромиса в реално време: одобрете и сблъскващите смени изчезват; откажете и служителят получава отказ-имейл и rota-та остава непроменена. Един workflow, един екран, без пропуснати заявки.
Свободните смени затварят пропастта между „някой е болен“ и „някой покрива“
Покритието на болничен ден е моментът с най-голямо триене в планирането в ресторант. Изграждането на график прави пропастта видима в grid-а (отменената смяна става дупка) и ви позволява да постнете OpenShift с 4 клика; персоналът claim-ва от телефона; одобрявате. Race-condition handling е на SQL ниво — `prisma.openShift.updateMany({ where: { id, status: 'OPEN' }, data: { status: 'CLAIMED' } })` — така че дори с трима претенденти, натискащи бутона едновременно, точно един печели. Това е същият атомен guard pattern, който използваме за Bill table-occupancy invariant.