Proiect realizat · Recepție digitală
Sală de fitness și activitate de aerobic · București
Un card, profilul corect și o evidență clară a ședințelor. Am dezvoltat un CRM custom care conectează cititorul de carduri de la recepție cu membrii, abonamentele și istoricul activității.
Accentul proiectului este operarea zilnică: identificare rapidă, bifare verificată și sold justificat. Citirea unui card, confirmarea prezenței și consumul unei ședințe sunt operațiuni distincte.
Ce am construit
Pentru o sală de fitness, viteza la recepție contează. Dar o scanare rapidă nu este suficientă: trebuie identificat membrul corect, verificat abonamentul și păstrată explicația fiecărei ședințe consumate. CRM-ul reunește aceste operațiuni, fără să transforme automat orice citire de card într-o prezență.
Cardul de proximitate este citit la recepție și corelat cu asocierea activă din CRM. Numărul imprimat, util personalului, este separat de codul complet al cipului. Recepția ajunge la profilul și abonamentele membrului fără să retasteze datele; un card necunoscut cere înrolare, nu creează o prezență.
În modul de bifare, serverul verifică profilul, locația, valabilitatea și ședințele rămase. Automatizarea este permisă numai pentru un abonament eligibil și o opțiune neambiguă, fără o prezență recentă sau anticipată care cere verificare. Pentru mai multe abonamente ori opțiuni posibile, recepția alege explicit ce se înregistrează.
O scanare poate însemna identificare, alegere în așteptare, bifare reușită sau închidere fără consum. Jurnalul păstrează rezultatul și contextul de atunci. Lista prezențelor și mișcările abonamentului arată ședințele înregistrate efectiv; o confirmare de transport nu este raportată drept participare.
Profilul reunește datele, abonamentele, prezențele, programările și comentariile interne. Cardul este legat de persoană, nu de un singur abonament. Înlocuirea, dezactivarea ori eliberarea lui încheie o asociere fără să șteargă prezențele și soldurile; cardurile comune au membri definiți explicit.
Integrare hardware și software
Cititorul USB nu transmite direct o comandă de debitare către baza de date. Un program Windows face legătura cu CRM-ul, iar serverul decide ce operațiune este permisă în sesiunea și locația recepției.
Integrare cu cititor de proximitate EM 125 kHz prin SDK-ul dispozitivului.
Agent Windows conectat cu o cheie proprie a stației, separat de contul operatorului.
Aplicația PHP/MySQL verifică rolul, locația, cardul și abonamentul înainte de consum.
Identifică membrul, verifică abonamentul, asociază carduri și înregistrează prezența în locația autorizată. Cazurile neclare rămân la operator, nu sunt rezolvate prin alegerea primului abonament.
Coordonează operațiunile și lucrează numai în locațiile permise. Accesul la date și la acțiuni este verificat pe server, nu doar ascuns în meniu.
Administrează utilizatorii, drepturile și zonele sensibile de raportare. Rapoartele financiare și setările administrative nu sunt oferite implicit tuturor operatorilor.
Consultă programul și activitatea proprie. Bifarea prezenței cere permisiunea dedicată, iar accesul său nu devine automat acces la întreaga bază de membri.
Portalul poate oferi datele, abonamentele și solicitările propriilor profiluri, potrivit accesului acordat. Existența unui card sau a unei fișe operaționale nu este echivalentă cu autentificarea personală.
Workflow-ul unei scanări
Recepția vede modul de lucru și locația selectată. CRM-ul primește evenimentul, identifică asocierea și verifică starea curentă. Rezultatul depinde de modul activ și de eligibilitate, nu numai de faptul că cititorul a detectat un card.
În modul de identificare, cardul ajută recepția să găsească membrul. Consultarea profilului sau verificarea cardului nu scade o ședință din abonament.
Cazul unic eligibil poate fi bifat automat. Dacă sunt mai multe variante sau există deja o prezență recentă, recepția alege explicit. Operațiunea confirmată leagă ședința de abonament, operator și scanare.
Cardul neasociat, lipsa unei ședințe eligibile ori o asociere care trebuie verificată cer intervenție. Închiderea unei solicitări nu bifează și nu restituie o ședință; jurnalul păstrează rezultatul.
Decizii tehnice
Integrarea hardware este doar începutul. Partea importantă este ce face aplicația cu evenimentul citit: ce verifică, când poate bifa, cum tratează o repetare și ce păstrează dacă un card este înlocuit sau o prezență este corectată.
CRM-ul rulează în PHP, HTML/CSS/JavaScript și MariaDB/MySQL, independent de WordPress. Agentul local citește hardware-ul și comunică cu serverul. În varianta prezentată, validarea prezenței cere conexiune la CRM; reluarea transmiterii unor scanări nu este un mod de operare offline.
Serverul recitește datele curente și folosește blocări tranzacționale la operațiunile sensibile. Prezența, mișcarea de sold și rezultatul scanării sunt corelate. Un identificator unic protejează împotriva reprocesării aceluiași eveniment, iar scanările simultane sunt tratate în aceeași mecanică.
Jurnalul păstrează persoana, numărul cardului și contextul cunoscute la momentul scanării. Reasocierea ulterioară nu atribuie vechile prezențe noului titular. Corectarea numărului imprimat și schimbarea asocierii lasă propriul audit; identificarea folosește codul complet, nu ultimele patru caractere.
Un cod static de proximitate identifică un card, nu autentifică personalul și nu dovedește singur identitatea persoanei. De aceea, bifarea este legată de o recepție activă, un operator autorizat și locația permisă. Proiectul prezentat nu este descris ca sistem de turnicheți sau control al ușilor.
Catalogul diferențiază intrările fitness fără antrenor de serviciile cu instructor și program recurent. La activare sunt acceptate numai variantele cu reguli complete. Pachetele de aerobic care includ invitații rămân blocate la alocare până la finalizarea fluxului de emitere și consum al invitațiilor; această funcție nu este prezentată ca livrată.
Evidența prezenței pornește de la operațiunile confirmate, nu de la simpla trecere a unei ore programate. Comentariile interne păstrează autorul și momentul fără să consume ședințe. Valoarea abonamentelor și încasările efective sunt noțiuni distincte; raportul de valori nu înlocuiește închiderea de casă.
Experiența WebHat
Proiectul Berry Fitness arată cum conectăm o acțiune fizică simplă — apropierea cardului — cu un proces software controlat. Nu ne limităm la afișarea unui profil: verificăm cine operează, ce abonament poate fi folosit, ce se consumă și ce dovadă rămâne. Pentru alte săli, cluburi și servicii pe bază de ședințe, CRM-ul se proiectează după regulile și echipamentele proprii.
