Бакшиш пул — разпределяйте бакшиш по роля и отбити часове, атомно
Отворете бакшиш пул за период, дефинирайте процентни разделения по роля (60% сервитьори / 30% кухня / 10% бар) и платформата разпределя сумата между персонала пропорционално на отбитите им часове във всяка роля. Една транзакция, един audit ред, нула spreadsheets.
Какво е бакшиш пул в Ordering.Tools?
Бакшиш пул е едно distribution събитие за дефиниран период — типично смяна, ден или седмица. Отваряте пула с periodStart и periodEnd; платформата сумира всеки COMPLETED BillPayment.tipAmount в този прозорец; връзвате TipDistributionRule (конфигурируем процент на роля, сумиращ до 100); и при Distribute платформата записва per-staff TipPoolDistribution редове пропорционално на отбитите часове на всеки служител в неговата роля през периода. Пулът се мести OPEN → DISTRIBUTED → LOCKED.
Цялата транзакция е атомна. Сумата, правилото, per-staff разделенията и StaffAuditLog ред кацат в една $transaction — няма half-distributed състояние, няма partial редове, няма „бакшиш пулът е в странно състояние“ бъгове. След distribution lock-нете пула за предотвратяване на бъдещи мутации. Данните, които заведението експортира за payroll съответстват на това, което персоналът вижда на собствената си My Wages страница, по дизайн.
Защо това е tip-pool слоят, на който екипът ви ще се довери
Атомна distribution, без half-states
Пулът се мести OPEN → DISTRIBUTED в една $transaction с per-staff редовете. Ако нещо се провали, нищо не се прилага. Без half-distributed пулове, без orphan редове, без ръчни почиствания.
Distribution по часове-в-роля, не по headcount
Двама сервитьори са работили един петък — единият за 4 часа, другият за 8. Headcount-based разделенията им дават еднакъв дял, което е нечестно. Hours-in-role разделенията дават на 8-часовия сервитьор два пъти дяла. Математиката е прозрачна; персоналът може да верифицира собствения си ред.
Конфигурируеми правила, без preset bias
Процентни разделения на роля (SERVER, KITCHEN, BAR, HOST) са venue-конфигурируеми. Сумата на роли трябва да е 100 — наложено на API ниво. Не зареждаме „по подразбиране“ разделение, защото tip-pool етиката се различава по държава и тип заведение.
Източник от BillPayment.tipAmount, никога измислен
Сумата на пула е сума на завършени BillPayments в периода — същият каноничен източник, който операторът вече използва за payment отчети. Бакшишите стигат до персонала точно както клиентът ги е платил; без двойно броене, без пропуснати канали.
Как работи бакшиш пулът
Дефинирайте distribution правилото
Отворете Персонал → Бакшиш Пул → Правила. Създайте правило с име (напр. „Стандартно 60/30/10“), applies-to филтър (ALL / DINE_IN / DELIVERY) и per-role процентите. Сумата на редовете трябва да е 100; API отказва 99 или 101.
Отворете пул за периода
Отворете Персонал → Бакшиш Пул, кликнете + Open period. Изберете periodStart, periodEnd и правилото за прилагане. Пулът тръгва в OPEN статус с totalCents = 0 — реалната сума се изчислява в момента на distribution.
Distribute
Кликнете Distribute на картата на пула. Платформата сумира BillPayment.tipAmount за COMPLETED плащания в прозореца, агрегира отбити минути на служител на роля от ClockEvents, изчислява per-row процентни дялове и записва всичко атомно. Пулът се мести в DISTRIBUTED.
Lock и експорт
След като сте прегледали distribution-а, кликнете Lock — пулът се мести в LOCKED и не се позволяват по-нататъшни мутации. Експортирайте per-staff разделенията като CSV за payroll provider-а; персоналът вижда собствения си дял на /admin/profile/wages.
Бакшиш Пул — детайли
Атомна distribution чрез $transaction
Пълната distribution математика + per-staff row inserts + StaffAuditLog запис кацат в една Prisma транзакция. Всичко се commit-ва или нищо не се commit-ва — няма „half-distributed“ състояние за ръчно почистване.
- Pool status guard: трябва да е OPEN за distribute
- Правилото трябва да сумира точно до 100 (±0.01 толерантност за decimal аритметика)
- All-or-nothing — TipPoolDistribution редове + pool.status flip в една txn
- Audit ред записва totalCents, allocated, rowsCreated и актьора
Hours-in-role изчисление на дял
Във всеки role bucket (напр. SERVER: £498 от £830 пул при 60%), дялът се разделя пропорционално на отбитите минути на всеки служител в тази роля през периода. Last-row residual обработва центове закръгляване, така че сумата да е равна на bucket-а точно.
- Чете от същия ClockEvent поток, който захранва timesheets
- Резолва ролята на всеки потребител от последния му StaffShiftAssignment в периода
- Last-row residual обработва центове закръгляване (без orphan стотинки)
- Празни role buckets (нула часове) пропускат чисто без грешки
Конфигурируеми distribution правила
Правилата са first-class entities — наименувайте ги, маркирайте едно по подразбиране, архивирайте стари. Applies-to филтърът (ALL / DINE_IN / DELIVERY) ви позволява да пускате различни разделения за dine-in вечери срещу delivery смени.
- Множество правила на заведение — превключвайте по период или източник
- isDefault флаг — едно правило автоматично се прилага към нови пулове
- Sum-to-100 наложено на API и DB ниво
- Soft-archive (isActive=false) запазва исторически правила, използвани от минали пулове
LOCKED статус за приключени пулове
След като сте уверени, че distribution-ът е правилен, lock-нете пула. Статусът на реда става LOCKED и не се позволяват по-нататъшни мутации. Минали пулове, които вече са изплатени трябва винаги да бъдат lock-нати — това е audit най-чистият сигнал.
- Status guard: трябва да е DISTRIBUTED за lock
- LOCKED пулове не могат да бъдат re-distributed или редактирани
- Различно визуално представяне в admin UI (lock иконка)
- Audit log записва lock събитието с актьора
Къде бакшиш пулът си заслужава
Distribution на бакшиш в петъчна вечеря
Петъчната вечер свършва с £830 в общи бакшиши. Отворете TipPool за периода на смяната, distribute-нете срещу 60/30/10 правило. Петима сервитьори си разделят £498 по часове, трима кухня по £249, един бар по £83. CSV експортът отива на счетоводителя в понеделник сутрин.
Седмичен бакшиш пул, всички източници
Някои заведения разпределят седмично през всички източници (dine-in + delivery + pickup бакшиши). Отворете 7-дневен пул с правило, чийто appliesToSource = ALL. Distribute-нете в неделя вечер; персоналът вижда дяла си в понеделник в My Wages.
Отделни dine-in срещу delivery разделения
Доставчици получават 100% от delivery бакшиши (правило A); dine-in сервитьори/кухня си разделят dine-in бакшиши 60/40 (правило B). Отворете два пула на период, един с всяко правило, и системата разпределя двата правилно без смесване на източници.
Catering събитие с фиксирана служебна такса
200-човешко catering събитие включва автоматична 18% служебна такса, която тече в общите бакшиши. Отворете еднократен пул за това събитие, връзнете стандартното правило, distribute. Catering екипът получава дяла си наред със служебния екип.
Преглед в края на месеца
Отворете Персонал → Бакшиш Пул, видете всеки distribute-нат пул от месеца с суми, имена на правила и per-staff разделения. Lock-нете тези, които сте прегледали; разследвайте тези с изненадващи разделения преди заключване.
Self-service за персонала
Персоналът не трябва да пита „какъв е дялът ми?“. Отварят My Wages на телефона си и виждат всеки TipPoolDistribution ред, приписан на тях. Математиката е прозрачна; процентният дял е показан; доверието е изградено.
Бакшиши, на които персоналът се доверява, защото може да верифицира математиката
Проблемът с бакшиш пула не е „как да изчислим разделението?“ — а „как да направим разделението вярно?“. Black-box payroll софтуер, който дава на сервитьор число без разбивка, ражда подозрение („как знаеш, че е правилно?“). Бакшиш пулът на Ordering.Tools отговаря на това с прозрачност: всеки distribution ред носи часовете на служителя, ролята му, процентния дял и резултантните центове. Персоналът вижда математиката; мениджърите не трябва да я защитават; audit log прави всяка минала distribution възпроизводима.
Защо hours-in-role побеждава headcount
Headcount-based разделенията на бакшиш са най-простият ментален модел — „трима сервитьори, разделете еднакво“. Но те наказват служителя, покривал допълнителен час и награждават този, който е тръгнал в 21:00 точно. Hours-in-role разделенията възстановяват пропорционалната справедливост: clocked-in време е каноничната мярка за присъствие и системата вече я има от ClockEvents. Имплементацията е една SQL агрегация на пул — без ръчно броене, без spreadsheets.
Sum-to-100, наложено на всеки слой
Ако мениджър създаде tip правило с редове, сумиращи до 99% (забравил една роля), следващата distribution тихо оставя 1% от пула неразпределена — объркващо за персонала, неудобно за мениджъра. Ordering.Tools налага sum-to-100 на три слоя: rule-creation API отказва 99 с 400; distribution API ре-проверява преди изчисляване на разделения; unit тестове го твърдят. Резултатът е без тихи rounding грешки, без orphan стотинки, без „къде отидоха £8?“ Slack съобщения.
Източник: BillPayment.tipAmount, статус COMPLETED
Откъде всъщност идват бакшишите? В Ordering.Tools всяко плащане от клиент записва BillPayment ред с tipAmount като отделна decimal колона. Бакшиш пулът агрегира COMPLETED BillPayments само — refunded плащания са изключени автоматично. PENDING и AUTHORIZED състояния не се броят, докато не завършат. Това означава, че клиент, дал бакшиш на карта, която после bouncne не влиза в пула, и refunded поръчка също. Бакшиши, стигнали до персонала, са бакшиши, които заведението всъщност е получило — chain of custody е една заявка дълбока и напълно reproducible.