Cum setează / programează ratingul și facturarea.
Întrebare: „Eu sunt acum interesat de aici este întrebarea Cum acest megamosk numit“ procesul de facturare „este programat în conformitate cu logica necesară Să vină un manager, și a spus că ar trebui să o duc asa ceva aici cu o anumită logică (mai mult de obicei merge ceva? , că o persoană normală nu va veni niciodată în minte.) Și ce fac oamenii în acest caz care susțin facturarea? Nu rescriu același cod de realizare a acestui "vis idiotic"?
Răspuns scurt
Se întâmplă pe toată lumea - poate fi și așa, că este necesar să scrieți codul.
Răspuns lung
Voi începe cu definițiile termenilor de rating și de facturare. pe care o voi folosi. Foarte adesea ele sunt reciproc înlocuiesc reciproc, și un mare dezastru pe acest lucru nu se întâmplă, dar în post de astăzi doar atinge diferențele esențiale și fundamentale între aceste procese, și voi încerca să nu le confunde :)
Deci, evaluarea este procesul de calculare a costului unui eveniment. Suntem de acord că evenimentul - acesta este un act de utilizator de consum uslgu în cel mai larg sens al cuvântului :)
Evaluarea este o facturare strâns legată - procesul de generare a facturilor, a cheltuielilor generale și a altor documente contabile, punerea în aplicare a "închiderii perioadei financiare", notificarea abonaților cu privire la soldul curent și arieratele și alte dansuri similare cu tamburine.
Evaluarea este un proces specific pentru companiile de telecomunicații. Furnizorii de comunicații mobile, furnizori de Internet, operatori de rețele fixe - toate pun într-o oarecare măsură procesul de evaluare.
Cu toate acestea, mă îndepărtez. Să revenim la subiect. Astăzi vom fi mai interesați de evaluare, deoarece am scris deja despre facturare.
Ce este un rating și cum este implementat
Să încercăm să ne găsim în picioare de un arhitect sau de un programator al unui sistem de facturare.
În mod abstract, evaluarea în comunicațiile mobile este o funcție, care, ca argumente, i se atribuie atributele evenimentului și atributele abonaților care au luat parte la acesta.
Cel mai popular set de argumente pentru funcția de rating este: planul tarifar al abonatului A, numărul de abonat B, tipul evenimentului, ora evenimentului, durata (de la A la A) - partea) persoanei care primește apelul.).
Cea mai populară formă a funcției de rating: dependența liniară (a * x + b) a valorii duratei evenimentului, unde coeficientul "a" este luat din planul tarifar, iar "b" este așa-numita "taxă de configurare a apelului".
Dacă suntem de acord că costul depinde întotdeauna liniar de durata, ne va simplifica foarte mult viața atunci când scriem sistemul. Probabil că vom merge cel mai simplu și vom reuși.
Evaluare de tabel (rating de tip tabel)
Inima sistemului nostru va fi un tabel care stochează înregistrările formularului (rating_plan_id, event_type, destination, price_per_unit). Fiecare intrare va descrie cât costă apelul (sau apelul înainte sau 1 sms). În direcția specificată din planul tarifar specificat.
Prin urmare, în tabelul nostru pot fi înregistrări precum "Super-ball", "clopot", "*", 0,01) - în pachetul tarifar "Super-ball" cheamă oriunde - pentru un penny o secundă :)
Cum va funcționa evaluarea noastră? Este foarte simplu. Luăm o înregistrare a evenimentului (înregistrarea detaliilor apelului, CDR). din acesta - numărul abonatului A. îl găsim în baza abonaților. aflați planul său tarifar. Tipul de eveniment este cunoscut de noi, numărul B este de asemenea (toate acestea sunt în CDR). Găsirea în tabelul tarifar a unei intrări cu direcția dorită (pentru aceasta se utilizează căutarea celui mai lung prefix, potrivire regexp, potrivire globală). vom cunoaște prețul pentru o secundă. Îl înmulțim cu durata - și voila, evaluarea se face!
Pentru un astfel de sistem, de regulă, nu împiedică un număr mare de abonați, în același timp, un număr mare de planuri tarifare. Singurul dezavantaj - configurarea GUI unui astfel de sistem, de regulă, reprezintă un primitiv DB Grid, precum și un număr mare de ve schimba planurile lor tarifare se transformă într-o corvoada minte-numbing. Dar sistemul este infernal rapid (TM), care ne va permite o lungă perioadă de timp pentru a uita despre necesitatea de a actualiza serverul de rating :)
Cu toate acestea, merită remarcat faptul că în sălbăticie asemenea sisteme primitive nu sunt aproape niciodată îndeplinite - fie au murit, fie au evoluat.
Evaluarea tabelului, numărul de încercare 2
Rețineți că sistemul bazat pe tabel poate fi extins doar prin abilitatea de a specifica nu numai dependența liniară a valorii în timp. Să modificăm schema din baza noastră de date după cum urmează: tarifele vor fi stocate în înregistrări (rating_plan_id, tip_tip, destinație, funcție_id). unde funcția_id este o indicație a uneia dintre mai multe funcții hardwired în codul sistemului. Un astfel de upgrade ne va permite, de exemplu, să creăm planuri tarifare cu un cost fix al unui apel sau planuri ca "primele cinci secunde sunt libere".
Cu toate acestea, este greu să coase un interval liber în cod în cinci secunde - este urât. Adăugați la câmpurile noastre tabel - (rating_plan_id. Function_id, const_1, const_2, const_3, const_4 .const_9). După aceea vom fi în măsură să scrie să-l ( "Megadrive", "Up", "*", "Fiks_tsena_s_bespl_intervalom", 5, 10, NULL, NULL. NULL). ceea ce înseamnă că în planul tarifar "MegaDrive" toate apelurile costă 10 ruble, indiferent de cost și primele cinci secunde - gratuit.
Munca această evaluare va fi un pic mai lent - pentru fiecare intrare va trebui să nu fie multiplica doar două numere, și sună o anumită funcție. Dar ar fi în continuare infernală rapidă (TM), mai ales în cazul în care funcția va scrie oameni ale căror mâini nu sunt fund rostut. În toate celelalte (comoditate configurație, flexibilitate, etc.), această soluție este identică cu cea anterioară.
În ciuda primitivismului aparent, astfel de sisteme sunt de obicei utilizate pentru evaluarea abonaților prepaid pe platformele IN. Cea mai mare limitare a acestor sisteme este imposibilitatea de a-și crea funcțiile de rating (de obicei producătorul vinde servicii pentru extinderea ratingului pentru bani individuali) și o dată pentru totdeauna un anumit set de parametri pe care prețul poate depinde. Asta ne aduce.
Evaluarea "Componentă"
Facem un pas mai departe pe scara evoluționistă. Fie ca utilizatorul sistemului să poată scrie el însuși funcțiile de rating. Pentru a vă asigura că utilizatorii nu sunt foarte fericiți, puteți face acest proces greoi, lent și greu de slăbit. În cel mai bun caz, utilizatorul va trebui să scrie funcția PL / SQL, în cel mai rău - pentru a le scrie în piața internă limbaj „scripting“, care este masculinizare C, în realitate, uneori este, și compilate într-un DLL și a cauzat kernel-ul de rating care, prin urmare, se va prăbuși cu orice eroare gravă în codul de utilizator.
Ca o opțiune, utilizatorului nu i se poate da posibilitatea de a scrie ceva însuși, dar poate alege dintr-o gamă largă de DLL-uri disponibile (componente), le poate cumpăra de la producătorul cu ridicata sau cu amănuntul și se conectează independent la facturarea. Cum va fi configurat și configurat - nervos este mai bine să nu urmăriți :)
În mod tipic, aceste sisteme au un API bine definit, prin care componentele pot urca în sistem și pot extrage datele necesare de acolo. Pentru a menține o performanță decentă, API oferă accesul la un subset limitat de date de abonat, un plan tarifar și așa mai departe.
Astfel, cea mai importantă limitare a unui astfel de sistem ar fi incapacitatea de a depăși acest API. De exemplu, dacă nu puteți obține data abonatului prin API prin API, nu veți putea efectua facturarea formularului "dacă sunteți cu noi un an - o reducere de 10%, dacă două sunt 20%".
Regula de rating
Variațiile pe aceeași temă vor fi "evaluarea cu posibilitatea de a scrie reguli" (bazată pe reguli). Utilizatorul este dat regulile interne ale descrierii de rating de limba, cu care, de regulă, puteți ajunge la toate datele posibile despre abonat, planul tarifar său, serviciile sale, istoria sa, și așa mai departe.
În mod tipic, astfel de sisteme de rating fac parte din (sau sunt strâns legate de) unele sisteme BSS, iar conceptele utilizate de sistemele BSS pot fi accesate și în timpul evaluării.
De exemplu, puteți utiliza clasament în valoarea ultimului proiect de lege (și să se bazeze pe baza sa de o reducere) sau același număr de plângeri de abonat de manipulare în call center :)
Este clar că un astfel de rating va fi, probabil, cel mai lent dintre toate. Dacă regulile pot fi scrise (pe mâini), atunci configurarea unui astfel de sistem poate fi o afacere ușoară și chiar plăcută. Dar, de regulă, regulile trebuie să fie introduse într-un GUI bastard, ca o diagramă bloc, care pune procesul de configurare pe un singur raft cu setarea unui sistem de masă.
Ce trebuie să faceți dacă sistemul este deja cumpărat și marketingul dorește ciudat?
Dacă marketingul dorește ciudat - ceva care nu este implementat în sistemul de rating existent (și el dorește, de regulă, "pentru ieri"), atunci opțiunile, din păcate, puțin.
- Trimiteți marketing. Am auzit că există astfel de companii în care este posibil, dar, în practică, acest lucru nu îndeplinește nici, și nici măcar nu au văzut oamenii care au lucrat în astfel de companii.
- Comandați o schimbare de sistem de la furnizor. De obicei, aceasta este costisitoare, lungă și înseamnă hemoroizi cu sprijin pentru soluții în viitor.
- Faceți niște cârje. De obicei, aceasta este rapidă, deshidratată și înseamnă hemoroizi cu sprijin pentru soluții în viitor.
Ce fel de caruselă se înțelege? De exemplu, marketingul dorește ca apelul fiecărui al treilea abonat să fie gratuit. „Corectă“ decizie - pentru a comanda la funcționalitatea furnizorului, care permite să se atribuie fiecărui abonat numără evenimente de diferite tipuri și capacitatea de a folosi valorile acestor contoare în clasament. Să presupunem că este nevoie de trei luni, iar funcționalitatea este necesară după 5 zile, pentru că este necesar pentru a obține înainte de cel mai apropiat competitor, care se zvoneste ca ar fi de gând să ofere ceva similar.
Cârjelul universal arată astfel: se scrie un program în care toate CDR-urile cad direct în fața ratingului. Acest program menține și actualizează tabelul (numărul de abonat A, numărul de apeluri). și modifică CDR-urile cu fiecare al treilea apel, astfel încât să puteți "observa" această modificare în sistemul de rating și să apelați tariful zero.
De exemplu, puteți adăuga prefixul "666" la numărul de abonat B în fiecare al treilea apel și configurați sistemul de rating astfel încât toate apelurile către direcția 666 să fie libere. O actualizare mică a bazei de date înainte de facturare nu va permite ca prefixul să intre în imprimate detaliate ale abonaților :)
Sau este posibil să transformați fiecare al treilea apel într-un eveniment de tip nou, iar în rating să plasați toate evenimentele de acest tip la cost zero.
Există o mulțime de opțiuni. Fiecare operator are propriul său "stil" și setul său preferat de cârje, pe care le prețuiește, le prețuiește și crește. Periodic, masa cumulativă de cârje depășește cea critică, iar sistemul de facturare se schimbă într-o altă (sau modernizată într-o nouă versiune), în timpul căreia cârjele sunt îndepărtate și implementate în mod "drept". După aceea, procesul de creare a cârjelor începe din nou - din motive necunoscute, piața are nevoie exact de acele funcții care nu sunt în versiunea curentă a sistemului de facturare folosit :)
Articole similare
Trimiteți-le prietenilor: