SPECIFICATII FUNCTIONALE
SISTEM RETAIL
Gestiunea proceselor
din magazinele
Sistemul Retail va fi folosit in reteaua de magazine proprii
ale Orange
Sistemul preia date introduse manual de utilizatori sau importate din sisteme externe, gestioneaza procesele din magazin, emite documentele ce le insotesc si pune la dispozitie datele rezultate pentru analize, verificari si pentru export catre alte sisteme .
Feedback al proceselor din magazin
Sistemul Retail se va constitui intr-un instrument de eficientizare a activitatii din magazinele Orange, atat prin usurarea efectuarii actiunilor din magazin (vanzari, schimburi, SAV, etc) cat si prin oferirea unor mecanisme de analiza a informatiilor rezultate de pe urma acestor activitati (informatii ce se vor constitui intr-un feedback pentru a optimiza procesele ce se desfasoara in magazine) .
In momentul de fata, pentru gestiunea activitatii
magazinelor proprii Orange
Cate o baza de date pentru fiecare magazin
Sistemul este conceput cu cate o baza de date pentru fiecare magazin (fiecare baza de date pe serverul propriu) si o baza de date centrala pe care se transfera periodic (in fiecare noapte sau la cerere, printr-un proces numit Sincronizare) datele de pe fiecare baza de magazin .
Procesul de sincronizare
Anumite informatii care sunt comune tuturor magazinelor (de exemplu nomenclatorul de produse, preturi, oferte, etc) se introduc o singura data pe baza de date centrala, dupa care se transfera prin procesul de sincronizare pe toate bazele de date de magazin .
In sens invers (dinspre bazele de magazin catre baza de date centrala) se transfera periodic (automat in fiecare noapte) datele relevante specifice activitatii fiecarui magazin (facturi, clienti, proforme, schimburi de sim, tranzactii, stocuri, etc), care devin apoi disponibile pentru consultare pe baza de date centrala . Din cauza acestei arhitecturi, datele referitoare la vanzarile dintr-o anumita zi de la un anume magazin sunt disponibile pentru raportare si comparatie cu alte magazine abia incepand cu ziua urmatoare .
Sincronizarea stocurilor
Un caz particular al procesului de sincronizare este procesul de aducere periodica a informatiei referitoare la stocuri de pe toate magazinele pe magazinul central . Acest proces se ruleaza automat o data pe ora, in intervalul 7 – 19, in fiecare zi . In acest fel, pe baza de date centrala exista (cu aproximatie de maxim o ora) informatia referitoare la stocurile fiecarui magazin, pentru consultare prin aplicatia Help Line (aplicatie prin care se poate verifica prezenta in stocurile magazinelor a unui anume produs, preturile la care acesta este disponibil spre vanzare in functie de oferta aleasa la vanzare, precum si rezervarile efectuate in magazinele din tara) .
Arhitectura
SHAPE * MERGEFORMAT
In momentul de fata exista 43 de magazine in tara (plus inca
2
Vantive
Software utilizat de Orange
ePOS
Electronic Point of Sales . ePOS este o aplicatie care asigura comunicarea in timp real a detaliilor din contractele incheiate de partenerii Orange catre sistemele care asigura serviciile de telecomunicatii, cel de facturare si CRM .
CRM
Customer Relationship Management, este un ansamblu de aplicatii si sisteme care usureaza relatia dintre Serviciul Clienti si client, prin colectarea si gestiunea tuturor informatiilor legate de acesta, automatizarea unor procese de business sau asigurarea accesului direct al clientului la diverse facilitati de tip Customer Service
PREVENTEL
Baza de date comuna intre operatorii de telefonie mobila care contine toti clientii suspendati pe motive de frauda sau neplata .
Serviciu/Produs PrePay
Serviciu/Produs preplatit (fara abonament, fara factura) . Din aceasta categorie fac parte:
pachetele PrePay – contin SIM-uri de voce de tip PrePay cu un credit initial si durata de valabilitate;
cartelele de reincarcare (incarcarea cu un anumit credit a unui cont de tip PrePay si prelungirea duratei de valabilitate);
serviciile de reincarcare electronica (eVoucher si eTopUp) .
eVoucher
Serviciu de reincarcare a unui cont PrePay cu o suma variabila (33 de valori prestabilite) . Reincarcarea contului se face prin apelarea serviciului reincarcare (222) si introducerea unui cod tiparit de bonul emis de sistemul eVoucher .
eTopUp
Serviciu de reincarcare a unui cont PrePay cu o suma variabila (de la 1 la 200€, in trepte de cate un euro) . Reincarcarea se face la emiterea bonului de catre aplicatia eTopUp, fara a mai fi nevoie de introducerea vreunui cod de catre client . Confirmarea operatiunii de reincarcare a creditului se face printr-un SMS trimis de catre sistemul de reincarcare clientului beneficiar al serviciului .
Client
Clientul este entitatea centrala din Sistemul Retail . Acesta este implicat in aproape toate procesele din sistem, este beneficiarul majoritatii operatiunilor realizate prin intermediul Sistemului Retail (vanzare, schimburi, cesiuni, etc) . Clientii pot fi catalogati in functie de interactiune lor cu compania, dupa cum urmeaza:
clienti PrePay – sunt clientii ce achizitioneaza produse si servicii de tip PrePay;
clienti PostPay – sunt clientii ce au incheiat abonamente
la Orange
clienti obisnuiti – clienti ce cumpara diverse produse la liber, fara fi achizitionat vreodata produse PrePay si fara a fi abonati Orange Romania SA .
Factura
O factura reprezinta multimea datelor asociate unui si rezultate dintr-un proces de vanzare in magazin . Facturile reprezinta vanzari nominale - pentru a putea fi emisa o factura fiind necesare datele clientului . In urma procesului de vanzare se tipareste un document de factura propriu-zisa pe care se vor evidentia toate produsele, serviciile, taxele si discounturile operate clientului prin procesul de vanzare si tot pe acest document, daca este cazul este afisata si chitanta in baza careia se face plata .
Proforma
Proformele sunt documente emise in vederea unei plati prin banca, in baza carora se poate finaliza o vanzare . Sunt o imagine a facturii finale, inmanata clientului in avans .
Bon Fiscal
Bonurile fiscale (bonuri de casa) sunt documente justificative de incasare numerar, emise de o casa de marcat, controlata de aplicatie direct sau prin intermediul unui driver . Au un comportament similar unei vanzari cu factura (reprezinta tot o vanzare) dar nu suporta vanzare in regim de oferta, nu permit vanzarea de telefoane, nu permit decat acordarea anumitor discounturi (fie globale, la nivel de bon, fie la nivel de produs pe bon), nu necesita specificarea unui client drept cumparator .
Produs/serviciu
Produsul este obiectul vanzarii si conform politicii Sistemului Retail se afla in centrul acestui proces . Prin produse se inteleg:
Handset-urile;
Accesoriile;
Pachetele PrePay;
Cartelele de reincarcare;
SIM-urile (atat cele PrePay cat si cele PostPay);
Produsele promotionale (tricouri, genti, etc . );
Taxele;
Serviciile de reincarcare (eVouchere);
Serviciile de reincarcare directa (eTopUp);
alte tipuri de produse/servicii .
Pret
Pretul defineste valoarea la vanzare a unui anume produs/serviciu . Preturile sunt mereu asociate unui produs, putem avea un produs cu mai multe preturi dar nu si un pret asociat mai multor produse, si nici sa avem un pret fara un produs asociat .
Discount
Discountul este o reducere ce afecteaza pretul final al unui produs/serviciu/taxa achitat de client .
Plan Tarifar
Planurile tarifare reprezinta tipurile de abonamente oferite
de Orange
Oferta
Oferta reprezinta o combinatie produs, pret, discount . Ofertele
determina pretul final la care un client poate achizitiona un produs aflat in
vanzare in magazinele
TVA
Taxa pe Valoarea Adaugata . Sistemul Retail trebuie sa permita co-existenta mai multor valori pentru TVA, dintre care unul singur este cel implicit . Un TVA poate fi sau nu valid, dar cel implicit nu poate fi invalid .
Curs valutar
Reprezinta rata de schimb pentru valuta sau valutele in care sunt exprimate preturile din aplicatie .
Stoc
Stocul contine toate produsele ce pot fi achizitionate de clienti (inclusiv unele produse promotionale) si care sunt prezente in gestiunea magazinului .
Tranzactie
Tranzactia reprezinta o inregistrare a detaliilor unui transfer de marfa in una din urmatoarele situatii:
intre gestiunile magazinelor;
in cadrul gestiunii unui magazin;
transferuri catre WAREHOUSE;
receptii de marfa de la WAREHOUSE;
transferuri catre Service;
receptii din Service;
transferuri pe gestiunea clientului (produse in custodia clientului);
receptii din gestiunea clientului;
Utilizator
Utilizatorul reprezinta orice persoana ce interactioneaza cu Sistemul Retail, interactiune care se face intr-o maniera controlata de drepturile de acces . Fiecare utilizator are asociat un nivel de acces la aplicatie . Utilizatorii trebuie sa fie unic identificabili din punct de vedere al interactiunii lor cu Sistemul Retail .
Magazin
Magazinul este un punct de desfacere si prezentare a
serviciilor si produselor oferite de Orange
SR
Sales Representative . Este un vanzator la punct fix de desfacere, apartine unui magazin si activitatea si-o desfasoara numai in incinta acelui magazin .
BSR
Bussiness Sales Representative . Este un vanzator mobil, se ocupa cu clientii corporate si business, si care din punct de vedere organizatoric apartine de un anume magazin .
Comanda electronica
Comanda este un formular in format electronic trimis de catre magazine catre WAREHOUSE prin care se cere alimentarea gestiunii cu produse .
WAREHOUSE
Depozitul Central . Se foloseste si cu sensul de subinventar in Oracle Applications .
Handset
Telefon de pe gestiune, folosit atat pentru vanzare cat si pentru schimburile de defecte, trimiterile in service, SWAP-uri, orice implica manupularea unui telefon prin intermediul sistemului Retail
Serie IMEI
International Mobile station Equipment Identity . Seria unui Handset, ce il identifica unic .
MSISDN
Mobile Station ISDN Number - numarul de telefon al abonatului .
Serviciu
Servicii oferite de companie: servicii de reincarcare pentru pachetele PrePay, servicii de operatii service in afara garantiei .
SAV
Service Apres Vente . Servicii de service in perioada de garantie .
PV
Proces Verbal . Document ce autentifica un acord semnat intre doua parti, in speta intre client si reprezentatul Orange Romania SA . Procese verbale se incheie in Sistemul Retail in cazul:
SAV-urilor – la preluarea si predarea din custodie a unui telefon de SWAP, la predarea telefonului defect in service si la receptia telefonului reparat;
Preluarii si predarii din custodia clientului a unui produs cu contract de comodat;
etc .
AIM
Aviz de insotire a marfii . Document folosit la transferul produselor, de la WAREHOUSE la magazin, intre magazine, catre service, etc .
OA
Oracle Applications .
NIR
Nota Interna de Receptie . Document folosit la receptionarea manuala a unor produse, in cazul in care OA este inaccesibil pentru a se face importul AIM-ului .
SWAP
Telefon de schimb . Este oferit clientilor pe perioada in care telefonul defect este in service .
In activitatea desfasurata in magazinele
interne
externe .
Entitatile interne sunt cele ce iau nastere in interiorul aplicatiei si abia apoi sunt si materializate pe un suport fizic (formulare, rapoarte, contracte, etc . ) .
Entitatile externe sunt cele ce descriu obiecte din realitate ce sunt introduse in sistem (clienti, produse, magazine, etc . ) .
Lista a entitatilor cu care opereaza Sistemul Retail:
client
factura (vanzare)
proforma;
bon fiscal;
produs;
pret;
discount
oferta
stoc
utilizator
tranzactie
magazin
plan tarifar
TVA
curs valutar
etc
Clientul este entitatea centrala din Sistemul Retail . Acesta este implicat in aproape toate procesele din sistem, este beneficiarul majoritatii operatiunilor realizate prin intermediul Sistemului Retail (vanzare, schimburi, cesiuni, etc) . Orice proces de vanzare incepe cu selectia unui client . Aproape orice proces din Sistemul Retail incepe cu selectia clientului (in afara de transferurile de marfa sau bonurile de casa cu plata cash) .
Atribute ale entitatii
Dintre atributele asociate acestei entitati enumeram:
nume;
prenume;
adresa (freetext importat din Vantive, dar cu detalii de tara, judet si oras separate, sau structurat, prin impartire la nivel de strada, numar, bloc, scara, etc . in cazul in care clientul este intretinut intern in Sistemul Retail);
tip client (juridic/fizic);
forma de organizare in cazul persoanelor juridice: PFA, SA, SRL, ONG, etc) (tipul de persoana juridica este intretinut numai intern, nu se poate aduce din Vantive deocamdata);
cod postal (optional);
numar de telefon de contact/numar de fax de contact fix (nu al persoanei de contact);
numar de telefon de contact/numar de fax de contact mobil (nu al persoanei de contact);
adresa mail;
cod fiscal sau CNP;
data nasterii;
banca si contul in cazul in care clientul este o persoana juridica - nu mai sunt obligatorii (dar daca se cunosc, nu strica sa fie completate);
tip act identitate (pentru persoane straine poate fi pasaport );
numarul de contract;
data incheierii contractului pentru fiecare subscriber;
MSISDN (numar de telefon al subscriberului);
numar client (customer number – din Vantive);
lista cu numele si prenumele persoanelor de contact si eventual un numar de telefon fix/mobil al persoanei de contact (poate fi o singura persoana de contact);
un istoric de client (intern – stabilit din log-ruile Sistemului Retail):
o in ce magazin a facut achizitiile si a incheiat contractele;
o numarul de schimburi de SIM si datele schimbarilor;
o numarul de schimburi de defect;
o numarul de operari in service, de schimburi de SIM (PrePay/PostPay), de schimburi de defect;
o etc .
un istoric de client (extern – importat din Vantive)
o perioadele contractuale pentru fiecare contract;
o perioadele contractuale pentru fiecare prelungire de contract;
o consumul mediu/maxim, detalii legate de facturile precedente, de convorbiri, atat in retea, cat si in afara ei, etc;
o ultima factura;
o etc .
tipul de abonament (planul tarifar);
optiunile si serviciile atasate abonamentului;
etc . (orice alte atribute ce ar putea fi folosite in evolutia viitoare)
Intretinere Clienti
Clientii vor fi inregistrati in Sistemul Retail in urmatoarele moduri:
import din EPOS la cerere (pentru clientii noi, care inca nu sunt inregistrati in CRM) – importul de client noi va fi validat, astfel incat sa nu fie incarcate in Sistemul Retail date eronate;
import din CRM la cerere (in cazul in care un client se importa din Vantive, este adus clientul cu totul, cu informatii despre toti subscriberii sai si este actualizat in Sistemul Retail . Informatiile aflate in Vantive sunt prioritare fata de informatiile aflate in Sistemul Retail . La momentul importarii unui client din Vantive, daca acesta exista deja in Sisteml Retail, informatiile acestuia vor fi suprascrise de cele existente in Vantive);
manual din Sistemul Retail - pentru clientii care nu au abonament Orange, si deci nu figureaza in Vantive sau EPOS (in cazul in care se va introduce pe viitor obligativitatea inregistrarii de informatii in legatura cu utilizatorii PrePay, aceste informatii vor trebui ulterior integrate in Sistem intr-un mod analog informatiilor legate de clienti PostPay);
La importul din Vantive al listei de subscriberi asociati customerului, se vor aduce urmatoarele informatii:
- MSISDN;
- nume utilizator;
- data nasterii;
- agreement date;
- data ultimei fidelizari;
- detalii legate de abonamentul curent, de subscriberi, de change-urile relevante din Vantive din ultima perioada, etc;
La primul import sau prima inserare manuala se va marca la nivel de subscriber data aparitiei in Sistem, pentru a se putea stabili vechimea in sistem .
Forma de organizare a clientului nu poate fi importata din Vantive, ea fiind inclusa in numele clientului . Din ePOS aceasta poate fi importata in mod distinct . La completarea manuala a unui client nou in Sistemul Retail (in cazul in care clientul este un client de servicii PrePay sau este un client ce cumpara accesorii, fara sa fie nici macar un client de servicii PrePay), categoria din care face sa fie completata manual de catre utilizator .
In ePOS exista o lista de astfel de categorisiri (forme de organizare): aceasta fie se poate importa in Sistemul Retail, fie se poate mentine manual de catre un utilizator autorizat .
Forma de organizare a clientului poate indica si cota de TVA care ii va fi asociata in cazul unei facturari (cota TVA asociata la nivelul facturii) .
Din Vantive numele si prenumele se importa pe un singur camp, pe cand din ePOS, sau in cazul in care clientul este introdus manual in Sistemul Retail, poate avea completat numele in mod separat (nume si prenume) .
In cazul in care codul fiscal sau CNP-ul nu au putut fi validate, sa fie emisa o notificare (fie un mesaj, fie un mail, sau ambele) si va exista posibilitatea de a forta introducerea in sistem a unot astfel de coduri (se poate intampla sa fie emise eronat de organele raspunzatoare) . Validarea acestor coduri va fi facuta si in functie de forma de organizare a firmei (in cazul codului fiscal) .
In cazul in care se va introduce pe viitor obligativitatea inregistrarii de informatii in legatura cu utilizatorii PrePay, aceste informatii vor trebui ulterior integrate in Sistem intr-un mod analog informatiilor legate de clienti PostPay .
Sistemul va asocia o lista de persoane de contact pentru fiecare client . Din Vantive poate fi adusa o singura persoana de contact, restul sunt introduse manual in Sistem . Informatiile relevante pentru personanele de contact sunt : numar telefon, cnp/cod fiscal, nume . O persoana de contact ale clientului trebuie asociata fiecarei facturi emise (daca aceasta nu se afla printre persoanele de contact existente, trebuie adaugata)
Se va mentine un istoric la nivel de clienti (un client cu contract reziliat nu dispare din sistem, ci este doar marcat corespunzator) si la nivel de subscriptie (istoric al operatiunilor interne Sistemului si al operatiunilor efectuate in sistemele externe) .
Istoricul operatiunilor efectuate prin Sistemul Retail de clientul respectiv (inclusiv la nivel de subscriber) va contine:
- vanzarile
- schimburile de SIM (PrePay)
- schimburile de defect
- operatiuni SAV
Informatia din isoricul operatiunilor interne Sistemului Retail va fi disponibila in timp real . Informatia din istoric va contine si referinta magazinului la care s-a efectuat operatiunea, pentru a putea oferi o imagine a operatiunilor in cadrul unui anume magazin .
Sistemul va pastra si o lista a schimbarilor efectuate de-a lungul timpului (schimbari ce afecteaza numele, MSISDN-ul, codul fiscal sau CNP-ul, adresa, etc . ), care va fi corelata cu istoricul operatiunilor descris mai sus .
Sistemul va permite cautarea in acest istoric dupa oricare din campurile clientului definite mai sus (MSISDN, nume, CNP, etc) . In acest mod, se va putea efectua, de exemplu, o cautare a tuturor operatiunilor asociate unei anume adrese (chiar daca este vorba despre clienti diferiti) .
Va fi definita o lista de factori de calitate pentru clienti . Lista va fi dinamica, in sensul ca va permite adaugarea unor noi factori de calitate pentru client, impreuna cu definirea detaliilor legate de acestea . Un factor de calitate ar putea fi actualizat odata cu urmatoarele operatiuni: vanzari, vizite, operatiuni SAV, etc . Se vor defini functii pe care utilizatorii le pot alege in calculul factorului de calitate (suma, medie, count, etc . ) . Se va alege o politica de resetare a factorilor de calitate pentru fiecare factor in parte . Un exemplu de factor de calitate al clientului este valoare facturii de serviciii pe ultima luna, sau data ultimei fidelizari (sa fie aceasta data de ex . mai veche de 2 ani de zile . ) .
Clasificare
Clientii inregistrati in Sistemul Retail sunt fie clienti PostPay
(cu abonament), fie clienti de PrePay, fie clienti care nu sunt abonati
Clientii sunt importati din sistemele Vantive sau ePOS (in cazul celor PostPay) sau introdusi manual (in cazul celorlalti clienti sau in cazul in care nu exista acces la sistemele externe) .
Fiecare client va avea asociate informatii legate de abonamentul si de activitatea sa in cadrul contractului cu Orange, iar Sistemul Retail va folosi aceste informatii pentru a face sugestii in legatura cu cea mai avantajoasa oferta de achizitie a unui nou terminal (de exemplu unui client care are mai multe abonamente i se poate sugera folosirea punctelor Thank You corespunzatoare unuia din abonamente sau o oferta de fidelizare disponibila pentru un alt abonament) .
Sistemul Retail va putea permite accesul la discounturi sau oferte in functie de anumite informatii legate de client . Informatiile pot fi de urmatoarele tipuri:
informatii de billing (tipul abonamentului, valoarea convorbirilor, informatii legate de plata facturii, optiunile activate sau dezactivate de-a lungul timpului, etc) – obtinute prin import din Vantive;
operatiunile in service (de cate ori a dus un terminal in service, de cate ori i s-a schimbat terminalul, etc);
de facturare in Sistemul Retail (valoarea achizitiilor, tipul de produs sau terminal achizitionat, periodicitatea, modalitatea de plata, etc);
detaliile de client (locuinta – daca se poate sugera o casierie mai apropiata de casa; tipul de client – fizic sau juridic; informatii PREVENTEL, etc) .
alte informatii
Selectia unui client
Cautarea clientilor se va face in principal dupa:
numar de telefon (MSISDN) – acest client va fi cautat in ePOS (daca e vorba de un subscriber nou sau este la primul abonament) sau in Vantive (daca este un client existent);
numarul de contract EPOS (in cazul in care este un abonament nou, informatiile inca nu exista in Vantive);
CNP/Cod Fiscal sau nume, pentru clientii care nu au
abonament
Detalii de interfata cu utilizatorul
Adresa clientului va fi introdusa printr-o macheta separata, ce contine:
- lista de judete;
- lista de orase (populata in functie de judetul selectat - trebuie selectat un judet);
- lista de sectoare (daca e Bucurestiul selectat);
- lista de tipuri de adresa (strada, bulevard, sosea, etc) .
Restul campurilor (strada, numar, etc) vor fi completate in campuri free text (nu vor fi liste de valori) .
Unele detalii de client vor fi stocate dar nu si neaparat vizibile nefiind folositoare la modul direct pentru utilizator, insa vor putea fi folosite ca si parametri interni de catre sistem . Pentru client se vor stoca informatii precum: planul tarifar curent, serviciile si optiunile active .
Informatiile disponibile prin interfata se impart in: Informatii primare (vizibile primele in interfata) si informatii secundare ca importanta (accesibile prin operatiuni suplimentare – click pe un buton de “Details ” de ex . )
Concluzie
Clientii sunt entitati carora li se adreseaza facturarea,
sunt beneficiarii produselor, cei ce fac plata catre Orange
Legaturi cu alte entitati
SHAPE * MERGEFORMAT
Factura |
Client nume, adresa, tip, |
Proforma |
PV SAV |
Pret |
Discount |
Magazin |
Abonament |
Sistemul va asigura o scalabilitate si flexibilitate in manipularea informatiilor (atributelor) entitatii si va permite operatii de adaugare / modificare / stergere / clasificare / intervale de timp (prin calendare) / valabilitate . Din acest motiv sistemul va asigura un configurator propriu pentru toate categoriile de entitati enumerate .
O factura reprezinta multimea datelor asociate unui si rezultate dintr-un proces de vanzare in magazin . Facturile reprezinta vanzari nominale - pentru a putea fi emisa o factura fiind necesare datele clientului . In urma procesului de vanzare se tipareste un document de factura propriu-zisa pe care se vor evidentia toate produsele, serviciile, taxele si discounturile operate clientului prin procesul de vanzare .
Atribute ale entitatii
Informatiile cele mai importante ce compun entitatea factura sunt:
produsul:
o serie;
o identificator produs;
o model;
o brand;
o tip;
o valoarea (pretul initial);
o cantitate (daca nu este produs cu serie);
discountul:
o valoare;
o tipul;
legatura (daca exista) intre discount si produs;
seria facturii;
data emiterii (la nivel de secunde);
magazinul emitent;
numarul chitantei - numai daca factura este achitata numerar si nu in baza unui bon de casa;
seria proformei;
identificarea ordinului de plata:
o seria;
o data;
o valoare;
datele de storno:
o factura initiala stornata;
o data facturii stornate;
o suma este restituita clientului: numerar sau prin banca (dispozitie de plata sau ordin de plata);
o refacturare (dupa caz): daca se refactureaza si factura initiala este platita prin ordin de plata sau carte de credit, atunci se pot folosi aceleasi serii de document (depinde de modul in care se efectueaza stornarea: cash sau prin banca); daca nu se face refacturare si vanzatorul are bani in casa, i se plateste clientului suma trecuta pe dispozitia de plata (in cazul in care se face stornarea in baza unei dispozitii de plata, altfel clientului ii este realimentat contul din banca de unde a efectuat plata initiala – prin OP sau CC);
clientul:
o client implicat intr-o vanzare de tip PostPay:
cod client;
subscriberul catre care se face vanzarea;
nume client;
adresa client;
cod fiscal sau CNP;
banca si contul bancar (pentru persoane juridice);
numar de telefon de contact;
numarul de contract;
data semnarii contractului;
tipul de prelungire a contractului (daca este cazul: fara prelungire, prelungire pe 12 luni, prelungire pe 24 luni);
o nu este client implicat intr-o vanzare de tip PostPay:
nume client;
adresa client;
cod fiscal sau CNP;
banca si contul bancar (pentru persoane juridice);
numar de telefon de contact;
vanzatorul care a incheiat factura (identificatorul sau);
valoarea facturii:
o in valuta fara TVA – nu va fi tiparita pe factura;
o in valuta TVA – nu va fi tiparita pe factura;
o in lei fara TVA;
o in lei TVA;
o in lei cu TVA (total factura);
valuta in care este exprimat pretul produsului achizitionat;
cursul valutar folosit (valoarea sa si data);
modul de plata (sau tipul de vanzare):
o numerar;
o carte de credit;
o ordin de plata;
o compensare
(nu se raporteaza la nivel de registru de casa) - folosita in relatiile cu partenerii
o factura in baza unui bon de casa;
o plata la termen;
tipul de factura:
o facturare normala;
o factura storno (totala/partiala);
o factura pentru bon;
o factura de corectie;
valoarea TVA-ului folosit in calcule;
daca produsul ce apare in vanzare se tipaseste sau nu pe factura (de ex . SIM-urile nu apar pe factura, dar sunt incluse in procesul de vanzare);
oferta la care s-a facut vanzarea .
identificator unic la nivel de factura si la nivel de exemplar tiparit, care sa permita identificarea momentului si utilizatorului care a facut aceasta tiparire;
elemente de identificare pentru serviciul de reancarcare folosit sau deviz eservice in baza caruia se face facturarea;
etc .
Clasificare
Facturile pot fi de trei tipuri:
normale;
storne;
anulate .
Nota
Anularea unei facturi se poate face doar in aceeasi zi in care a avut loc vanzarea . Stornarea poate sa se lege de orice factura emisa din magazin, indiferent de data emiterii acesteia . Se poate storna orice factura, emisa in orice magazin .
Mod de plata
In functie de modul de plata, facturile pot fi achitate cu: document justificativ de plata cu Carte de Credit, document justificativ de achitare a unui Ordin de Plata, numerar, sau pot fi facturi de compensare (intern, pentru clienti ce emit la randul lor facturi catre Orange Romania) .
Gestiune formulare pretiparite
Factura va fi tiparita in intregime din Sistemul Retail pe o foaie normala A4 . Seria unica pentru fiecare exemplar va fi intern generata de catre Sistemul Retail, dar aceste serii vor corespunde cu o plaja stabilita de Departamentul Contabilitate .
Sistemul Retail va trebui sa gestioneze aceste serii in asa fel incat sa se indeplineasca urmatoarele conditii:
Fisa de magazie – formulare pretiparite
Sistemul Retail va permite de asemenea tiparirea unei “fise de magazie” prin care se evidentiaza scopul pentru care a fost folosita fiecare serie (factura care a fost tiparita pe acele exemplare, motivul anularii daca e cazul, etc) . Vezi capitolul Gestiune Documente .
Legaturi cu alte entitati
SHAPE * MERGEFORMAT
Produs |
Factura id, data, client, produse, |
Pret |
Client |
Proforma |
Stoc |
Tranzactie |
Discount |
Utilizator |
Magazin |
Bon fiscal |
Sistemul va asigura o scalabilitate si flexibilitate in manupularea informatiilor (atributelor) entitatii si va permite operatii de adaugare / modificare / stergere / clasificare / intervale de timp (prin calendare) / valabilitate . Din acest motiv sistemul va asigura un configurator propriu pentru toate categoriile de entitati enumerate .
Proformele sunt documente emise in vederea unei plati prin banca, in baza carora se poate finaliza o vanzare . Sunt o imagine a facturii finale, exprimata in valuta,inmanata clientului in avans .
Au un comportament si o functionalitate asemanatoare cu cele ale unei facturi (mai tarziu se poate emite o factura in baza unei proforme), dar nu se opereaza destocarea produselor de pe proforma din gestiune, ci doar se face o rezervare a produselor (daca se doreste) . Proforma este numai o nota de calcul a facturii, pe care se listeaza produsele, preturile lor de pornire si discounturile in baza carora se ajunge la valoarea finala a facturii .
Se poate, la nivel de client, face o verificare a inchiderii cu OP a unei proforme . Daca o proforma a expirat si nu a fost inchisa, se poate verifica daca a fost emisa vreo factura cu OP pe acest client si daca este gasit un astfel de client, utilizatorul de nivel Shop Manager este instiintat ca sa verifice ca nu cumva factura respectiva sa nu fie inchiderea de fapt a proformei pomenite initial .
Se va efectua si o verificare a unui OP pentru un client: daca acest OP pentru clientul cu pricina a mai fost folosit, vanzatorul sa fie atentionat (poate alege sa continue vanzare, in cazul in care cu un OP se fac mai multe achizitii pe mai multe facturi) – aceasta verificare are scopul de a preveni falsul din partea unui client (cu acelasi OP sa faca mai multe achizitii, si suma acestora sa depaseasca suma trecuta pe OP) .
Va exista si conceptul de plata cu OP de plata electronica – pentru cei ce fac plati Web (formatul numarului de ordin de plata difera de cel pentru o plata cu OP direct la banca) .
Atribute ale entitatii
Datele ce definesc proforma sunt asemanatoare celor ale facturii, dar furnizeaza in primul rand informatii asupra sumei de plata, si nu asupra detaliilor de vanzare (oferta, serie, contract, etc):
data printarii;
produsul:
o daca este facuta rezervare, atunci e trecuta si seria;
o identificator produs;
o tipul;
o cantitatea;
o valoarea (pretul initial)
discountul (la nivel de produs, ca sa se ajunga la pretul final al produsului sau la nivel de factura);
perioada de valabilitate a proformei;
vanzatorul ce emite proforma;
client:
o nume;
o adresa;
o cod fiscal sau CNP;
o banca si contul (pentru persoane juridice – nefiind insa obligatorii aceste campuri);
o numarul de telefon de contact;
valoare:
o valuta fara TVA;
o valuta TVA;
o valuta cu TVA;
valuta in care este exprimat pretul produsului;
TVA-ul folosit la calcul;
starea curenta a proformei:
o expirata (clientul nu a facut plata in decurs de 5 zile);
o anulata (clietnul s-a razgandit);
o achitata si avand drept corespondent o factura si identificatorul acestei facturi;
magazinul emitent;
seria proformei;
bancile si conturile in care se poate face plata;
etc .
Rezervare produse
Prin emiterea unei proforme se face sau nu o rezervare a produsului ales de client, si in decurs de maxim 5 zile (perioada maxima de valabilitate a unei proforme – cu posibilitatea de a fi modificata din aplicatie) este pastrat pe stoc . Rezervarea se face la nivel de serie (pentru telefoane si produsele ce au serie) sau la nivel de tip de produs (de exemplu pentru accesorii) .
La rezervarea realizata in urma efectuarii unei proforme sa se mute produsul intr-o magazie de rezervate . Seriile IMEI vor fi sugerate vanzatorului a fi mutate in magazia de rezervate, dar nu el va realiza rezervarea acestora, ci Stock Keeper-ul . Pentru ca produsele se afla oricum pe stocul vanzatorului, nu exista riscul ca un alt vanzator sa le vanda pana in momentul rezervarii lor de catre Stock Keeper .
Vanzarea catre un client a unui produs deja rezervat, de catre un alt client(in baza unei proforme), nu poate fi efectuata decat de catre acelasi utilizator sau de catre un utilizator de nivel superior celui ce a facut rezervarea .
Legaturi cu alte entitati
SHAPE * MERGEFORMAT
Produs |
Proforma id, data, client, produse, |
Pret |
Client |
Factura |
Stoc |
Discount |
Utilizator |
Magazin |
Sistemul va asigura o scalabilitate si flexibilitate in manupularea informatiilor (atributelor) entitatii si va permite operatii de adaugare / modificare / stergere / clasificare / intervale de timp (prin calendare) / valabilitate . Din acest motiv sistemul va asigura un configurator propriu pentru toate categoriile de entitati enumerate .
Bonurile fiscale (bonuri de casa) sunt documente justificative reprezentand o vanzare similara cu facturarea dar care are si semnificatia de incasare numerar, emise de o casa de marcat, controlata de aplicatie direct sau prin intermediul unui driver . Au un comportament similar unei vanzari cu factura (reprezinta tot o vanzare) dar nu suporta vanzare in regim de oferta, nu permit vanzarea de telefoane, nu permit decat acordarea anumitor discounturi (fie globale, la nivel de bon, fie la nivel de produs pe bon), nu necesita specificarea unui client drept cumparator .
Atribute
Detaliile cuprinse pe un bon de casa sunt:
numar bon de casa;
produs:
o cantitate;
o denumire;
o serie (daca e cazul);
o tip, brand;
discount:
o valoare;
o asociere (la nivel de bon sau la nivel de produs);
o identificator discount;
valoare:
o pret lei fara TVA;
o pret lei TVA;
o pret lei cu TVA;
o pret in valuta fara TVA;
o pret in valuta TVA;
o pret in valuta cu TVA;
valuta in care este exprimat pretul produsului sau al discoutului;
vanzatorul care a facut vanzarea pe baza de bon de casa;
data vanzarii (la nivel de secunda);
magazinul emitent .
tip vanzare (cu Carte de Credit sau Cash);
etc .
Vanzarile prin bon de casa pot fi:
prin carte de credit – pe bon apare numarul chitantei cu care s-a facut plata cu Carte de Credit;
numerar .
Vanzarile pe casa de marcat nu pot fi facute in baza unui Ordin de Plata;
Factura pe baza de bon
Sistemul Retail va permite generarea unei facturi pe baza unui bon de casa emis in prealabil . Inchiderea unui bon prin factura se poate face doar pentru bonurile emise in acceasi zi . Daca in baza unui bon de casa de marcat se emite o factura, pe factura nu se mai afiseaza chitanta, ci numai se tipareste numarul bonului de casa si apoi se ataseaza la factura si bonul de casa drept document justificativ . Pentru o factura in baza unui bon de casa nu se mai pot adauga produse sau discounturi . Pretul de pe bonul de casa emis trebuie sa fie acelasi cu cel de pe factura emisa in baza acelui bon si produsele de pe bon trebuie sa se regasesca pe factura si trebuie sa fie identica factura cu bonul in baza caruia este emisa .
Pentru emiterea unui bon fiscal, Sistemul Retail trebuie sa nu pemita accesul vanzatorului la unele produse (de exemplu telefoane) ce nu se pot vinde decat cu factura . Sistemul trebuie sa permita utilizatorilor autorizati sa specifice, la crearea produsului, daca acesta poate fi sau nu vandut cu bon de casa .
Un bon defineste o vanzare cu ajutorul casei de marcat . Detaliile de client nu sunt completate in cazul unui bon fiscal dar, in cazul in care se emite o factura in baza unui bon, atunci acestea trebuie completate . Pentru orice bon de casa se poate emite o factura, cu conditia ca aceasta sa fie emisa in aceeasi zi .
Legaturi cu alte entitati
SHAPE * MERGEFORMAT
Produs |
Bon fiscal nr, data, produse, |
Pret |
Stoc |
Tranzactie |
Discount |
Utilizator |
Magazin |
Factura |
Sistemul va asigura o scalabilitate si flexibilitate in manupularea informatiilor (atributelor) entitatii si va permite operatii de adaugare / modificare / stergere / clasificare / intervale de timp (prin calendare) / valabilitate . Din acest motiv sistemul va asigura un configurator propriu pentru toate categoriile de entitati enumerate .
Produsul este obiectul vanzarii si conform politicii Sistemului Retail se afla in centrul acestui proces . Pentru produsul ales in cadrul procesului de vanzare Sistemul Retail va afisa variantele de preturi si discounturi disponibile pentru acesta in functie de seturile de conditii definite pentru preturi si discounturi (vezi capitolul Procese si functionalitati ale Sistemului Retail ->Vanzarea) .
Atribute
Entitate definita prin urmatoarele proprietati:
denumire
denumirea comerciala (fara brand – acesta este stocat separat)
brand-ul telefonului
clasificare:
o tip:
terminal;
accesoriu;
scratch-card;
pachet PrePay;
SIM;
promo;
taxe;
servicii de reincarcare;
servicii de reincarcare directa;
servicii de operare post-garantie;
etc .
o subtip: terminal mobil, terminal smartphone, terminal PDA, etc . – aceste categorii vor putea fi create dupa necesitati, ficare subtip apartinand unui tip (si accesoriile pot fi casca bluetooth, incarcator, baterie, handsfree, etc);
cod OA;
Fiecare produs sa aibe codul sau de bare, atasat codului OA care-i corespunde;
daca pretul este sau nu exprimat cu TVA;
seria produsului – poate lipsi in cazul produselor fara serie (poate fi citit sau nu cu cititorul de bare);
serie unica (da/nu)
unitatea de masura folosita (implicit completata cu ‘buc . ’);
cod de bare asociat tipului de produs – poate lipsi daca produsul nu necesita recunoastere a tipului prin acest cod sau daca seria sa este unica;
daca este sau nu un produs valid – produsele ce nu se mai comercializeaza sunt pastrate cu valoare istorica dar nu mai sunt valide;
clasa din care face parte: sa se poata astfel stabili o ierarhie de produse, din punct de vedere business: daca un produs inlocuieste un altul (de exemplu Nokia 1100 inlocuit de Nokia 1101);
in functie de clasa valorica:
o High end;
o Middle end;
o Low end;
“phone features”:
o MMS;
o GPRS, clasa GPRS;
o EDGE
o camera foto;
o 3G;
o etc .
clasa de compatibilitate a unui produs (cu accesorii sau cu servicii/optiuni)
linia de produs din care face parte, categorie terminal – in corelatie cu alte terminale
pret de cost;
etc
Produsele de tip Promo, flayere, manuale ( OA expence items) nu se vor gestiona nici cantitativ nici valoric in Sistemul Retail . Aceste produse se gestioneaza in OA, prin descarcarea si trecerea lor pe cheltuieli in momentul livrarii catre Shop .
Nu vor exista in aplicatie produse vandabile cu prêt de vanzare 0 . Ele vor avea pret standard si vor avea asociat un discount 100% si asa vor apare si pe factura .
Produsele nevandabile sunt doar cele PRO si nu apar pe factura ci doar pe un PV .
Aceste produse se gestioneaza in OA, prin descarcarea si trecerea lor pe cheltuieli in momentul livrarii catre Shop .
Produsele sa mai aibe si o eticheta de categorie (ex . PRACTIC, MULTIMEDIA ) . Se va defini un nomenclator de etichete si apoi un utilizator autorizat va crea asocierile intre eticheta si produs
Produsul trebuie sa mai contina si o informatie legata de realimentarea stocului din WAREHOUSE (un indicator al faptului ca din depozit se mai fac comenzi pe acest produs, ca se mai intentioneaza sa se achizitioneze) . Produsele pentru care nu se mai fac comenzi de alimentare in WAREHOUSE trebuie sa fie marcate corespunzator .
O parte a acestor proprietati sunt introduse manual:
- clasificarea
- seria unica
- codul de bare
- unitatea de masura
- clasa de compatibilitate, linia de produs
- etc .
Brand-ul poate lipsi in cazul in care accesoriul este general (ex . huse)
Invalidarea automata a unui produs se va produce intr-unul din cazurile:
la un nr . de zile de la utlima aparitie in stocul oricarui magazin (de la iesirea completa din stocul comercial) - numarul de zile este modificabil prin interfata si poate fi diferit de la un produs la altul, insa are o valoare default aceeasi pentru toate produsele;
la aparitia pe stocul comercial, produsul este reactivat automat (daca era invalid) .
Produsul invalid nu mai este vizibil in interfata in mod uzual – decat daca utilizatorul executa operatiuni suplimentare (de exemplu apasa un buton suplimentar “Arata si produsele invalide”) .
Invalidarea/Validarea manuala a unui produs: la validare manuala sistemul va completa automat “ultima aparitie in stoc” cu data validarii, pentru ca procesul automat sa nu-l invalideze la loc decat la expirarea unei noi perioade de validitate .
Unele produse apartin exclusiv Sistemului Retail, ele nu se regasesc in OA iar altele se regasesc in OA doar ca grup, neavand cod individual (ex . reincarcarile sau unele taxe folosite in Orange Studio) .
Stocul retail afisat in interfata de vizualizare produse va contine stocul local (al magazinului curent) precum si stocul disponibil in WAREHOUSE, alocat canalului retail (stocul WAREHOUSE va fi primul in lista de stocuri retail, inaintea stocurilor din magazine) .
Un telefon poate suferi si uzura, in acest caz el fiind transferat intr-un stoc special, de telefoane uzate (foste telefoane de test, aflate in magazia Touch&Try) .
Sistemul Retail ve permite introducerea unor perioade maxime de timp in care un produs ramane netranzactionat si in cazul depasirii acestei perioade sa fie notificat shop manager-ul . Produse tranzactionate inseamna produse vandute, schimbate, transferate extern . Monitorizarea netranzactionarii se va face la nivel de cod de produs (cantitativ) si nu la nivel de serie IMEI .
Ultimul pret de cost cu care un produs este importat in Sistemul Retail din WAREHOUSE este cel ce va fi folosit pe viitor pe AIM-urile si PV-urile de transfer (catre service, catre alt magazin, catre WAREHOUSE) . La un nou import de marfa aceasta valoare se va schimba .
Clasificare
Produsele pot fi impartite in urmatoarele tipuri:
telefoane (pe brand);
accesorii (pe brand);
SIM-uri (PrePay, PostPay, de schimb PrePay, de schimb PostPay);
cartele de reincarcare (functie de valoare si promotie);
pachete PrePay (pe tip promotie);
servicii de reincarcare (eVouchere si reincarcare directa);
taxe (de verificare, de despagubire, de schimb, etc . ) .
altele
Produsele pot fi catalogate si dupa codul de bare:
Codul de bare identifica un produs (ca model) dar exista cazuri in care unul, doua sau mai multe produse au acelasi cod de bare (de ex . in cazul in care o parte a stocului pe un produs e alocat ca fiind cadou – PACHET PREPAY 01 – CADOU si PACHET PREPAY 01 sunt in fond acelasi produs dar disponibil in doua variante de destocare – la vanzare sau cadou) . La produsele fara serie de inventar li se vor introduce codul de bare de pe produs la aparitia sa in Sistemul Retail (la importul din OA sau la introducerea manuala) .
Produsele se supun unui sistem de clasificare flexibil:
Grupuri de categorii: produsele isi definesc fiecare o categorie din care fac parte si apoi acestei categorii i se adauga proprietati (categoria telefon cu proprietatile generatie, tip display, culoare, etc . ) .
Clasificare arborescenta: orice produs se poate incadra intr-o categorie in mod unic, categoriile nu depind de produs .
Calsificare insumata: se definesc calitati dinamic si se asociaza produselor .
Sursa informatiilor
Produsele sunt importate din sisteme externe (Oracle Applications) sau introduse manual, dar trebuie pastrata in permanenta o corespondenta stricta intre produsele introduse in Sistemul Retail si sistemele cu care acesta se interfateaza .
Produsele vor fi identificate prin seria IMEI (cazul telefoanelor), prin seria de produs (cazul cartelelor de reincarcare) sau prin codul de bare al produsului (in acest mod, fiecare produs poate fi identificat de cititorul de bare si Sistemul Retail il va selecta automat, fara sa mai fie necesara cautarea sa de catre vanzator in lista de produse – totusi aceasta optiune va ramane valabila, pentru cazurile in care vanzatorul va dori sa caute manual produsul) .
Sistemul Retail trebuie sa permita definirea unui set de reguli dupa care produsele sunt tiparite sau nu pe factura (vezi capitolul Raportare) .
Din OA produsul este importat cu detalii precum:
denumire OA
cod OA
pret de cost
alte proprietati
Importul din OA se declanseaza manual de catre utilizator, specificandu-se codul OA de produs care se doreste a fi importat, sau este rulat automat (vezi capitolul de interfatare cu OA) .
Din OA nu sunt obligatoriu importate toate produsele . Vor exista reguli de import (de ex . produsele de tip promo, sau flyerele, manualele, etc . nu se vor importa) . Importul din OA nu este facut automat, va exista un utilizator care valideaza produsele ce vor fi importate in Sistemul Retail .
Compatibilitate intre produse/servicii
Sistemul Retail sa pemita impartirea produselor in clase de compatibilitate, in functie de model si de fabricant (de exemplu sa se evite situatia in care clientul cumpara din greseala un terminal Nokia cu un handsfree bluetooth Sagem si acestea sa nu fie compatibile) sau de functionalitatile oferite de terminal (cu/fara MMS, cu/fara GPRS, cu/fara 3G, etc), caz in care este vorba despre o compatibilitate intre produs si serviciul oferit .
Produsele pot avea asociate si preturi si discounturi, in urma aplicarii carora se ajunge la un pret final .
Sistemul Retail va permite si definirea unor proprietati asociate produselor, a unor descrieri (de exemplu functii telefon, capacitate baterie, rezolutie camera, etc) care sa poata fi accesate de orice utilizator, dar intretinute de catre un utilizator de nivel superior cu atributii speciale in acest sens . Aceste proprietati si descrieri vor fi folosite in procesul de vanzare pentru a usura munca vanzatorului, prezentand clientului toate detaliile produsului pe care doreste sa-l achizitioneze .
Fiecare produs va apartine unei categorii clare, si va avea asociate compatibilitati cu alte clase de produse, cu alte produse (individual), o linie de produse (ex . linia SonyEricsson W, sau Blackberry), etc .
Produsele pot fi vandute la liber (cu pretul implicit), la abonament (cu pretul corespunzator abonamentului) sau la loializare (fie fidelizare – oferta publica, fie retention – oferta ascunsa, pentru ca se aplica doar clientilor ce doresc rezilierea);
Produsele pot fi subventionate, caz in care pretul lor la liber nu mai este la fel cu pretul de abonament sau de fidelizare, sau nesubventionate – caz in care pretul la liber este la fel cu cel de abonament sau de fidelizare .
La definirea unui produs, sistemul va permite definirea unei liste de produse compatibile cu produsul curent (pot fi accesorii pentru un telefon, sau telefoane pentru un accesoriu) .
In fereastra de vizualizare a detaliilor de produs (vezi fig1), sistemul va permite, prin apasarea unui buton suplimentar, vizualizarea listei de produse compatibile cu produsul selectat (fig . 4) . In aceasta fereastra, se vor afisa urmatoarele informatii:
Lista de compatibilitati va include doua tipuri de informatii:
Lista de compatibilitati va include doua tipuri de informatii:
Detalii de Interfata
In interfata aplicatiei, in cazul in care sistemul gaseste mai multe tipuri de produse cu acelasi cod de bare (de exemplu Pachet PrePay si Pachet PrePay Cadou), sa se afiseze o fereastra care sa permita utilizatorului selectarea tipului de produs curent . De asemenea, fereastra va permite introducerea unei cantitati asociate produsului respectiv .
La click pe cifra reprezentand stocul din magazin sau stocul pe canalul retail, se vor afisa cate o fereastra detaliind informatiile de stoc la nivel de magazie pentru stocul intern (vezi fig . 2) si respectiv la nivel de magazin pentru stocul retail (vezi fig . 3) .
In fereasra de vizualizare a detaliilor de produs, se vor afisa urmatoarele informatii (vezi figura 1):
In fereastra de vizualizare a detaliilor de produs (vezi fig1), sistemul va permite, prin apasarea unui buton suplimentar, vizualizarea listei de preturi pentru produsul curent (in ce oferte este implicat, ce preturi ii sunt disponibile, etc) .
SHAPE * MERGEFORMAT
|
Denumire comerciala |
SPV |
Cod OA |
Tip produs |
Telefon > PDA > 2G |
Marca |
|
Status |
Valid |
Stoc magazin: |
|
Stoc retail: |
|
Compatibilitati |
Preturi |
Inchide |
Handsfree Incarcator |
Continut Pachet |
Produs |
SPV |
Cod OA |
Inchide |
|
|
Produs |
SPV |
Cod OA |
Inchide |
|
|
Produs |
SPV |
Cod OA |
Inchide |
|
Produse compatibile: |
|
Legaturi cu alte entitati
SHAPE * MERGEFORMAT
Pret |
Produs denumire, tip, serie, etc |
Bon fiscal |
Factura |
Discount |
Proforma |
Stoc |
PV SAV |
Comanda |
Sistemul va asigura o scalabilitate si flexibilitate in manupularea informatiilor (atributelor) entitatii si va permite operatii de adaugare / modificare / stergere / clasificare / intervale de timp (prin calendare) / valabilitate . Din acest motiv sistemul va asigura un configurator propriu pentru toate categoriile de entitati enumerate .
Entitatea Pret defineste valoarea la vanzare a unui anume produs . Preturile sunt mereu asociate unui produs, putem avea un produs cu mai multe preturi dar nu si un pret asociat mai multor produse, si nici sa avem un pret fara un produs asociat .
Atribute
Pretul este identificat de urmatoarele atribute:
denumire;
valoare;
tip pret: lei sau valuta (si identificarea valutei de referinta);
daca este exprimat cu sau fara TVA;
daca este pretul implicit al unui produs – identifica pretul la liber al unui produs;
carui produs ii este asociat (un pret nu poate fi asociat decat unui singur produs);
valid sau nu (daca o promotie nu mai este valabila, si preturile produselor din aceasta promotie sunt invalidate);
perioada de valabilitate a pretului (data finala lasata necompletata inseamna ca pretul este valabil pe o perioada nedefinita);
data ultimei modificari;
istoric de modificari;
istoric de valabilitate pe perioade de timp;
canal de vanzari (poate fi pret corporate sau retail);
etc .
Perioada de valabilitate
Preturile pot avea perioade de valabilitate, si un istoric in care sunt pastrate valorile de-a lungul timpului . Este permisa reactivarea unui pret mai vechi in conditiile in care nu genereaza conflict de activare in istoric .
Set de conditii pentru aplicare pret
Pentru fiecare pret al unui produs se va asocia un set de conditii care trebuie satisfacute pentru ca acel pret sa fie disponibil in cadrul procesului de vanzare (concept descris mai pe larg in capitolul Vanzare) .
Preturile pot fi cu sau fara TVA, pot fi exprimate in lei sau valuta, caz in care se va specifica si valuta folosita . Preturile pot fi importate din sisteme externe (Vantive) sau introduse manual (vezi si capitolul Interfatare Sistem Retail – sisteme existente) .
Pretul este entitatea ce permite vanzarea unui produs, oferindu-i o valoare de start, de la care pornind, prin aplicarea unor eventuale discounturi, se poate ajunge la valoarea de oferta .
Legaturi cu alte entitati
SHAPE * MERGEFORMAT
Produs |
Pret denumire, produs, val . |
Bon fiscal |
Discount |
Factura |
Proforma |
Oferta |
Sistemul va asigura o scalabilitate si flexibilitate in manupularea informatiilor (atributelor) entitatii si va permite operatii de adaugare / modificare / stergere / clasificare / intervale de timp (prin calendare) / valabilitate . Din acest motiv sistemul va asigura un configurator propriu pentru toate categoriile de entitati enumerate .
Discountul este o reducere ce afecteaza pretul final al unui produs/serviciu/taxa achitat de client .
Discounturile vor avea un proprietar (vor exista discounturi accesibile oricarui utilizator de nivel vanzator si discounturi accesibile la vanzare numai unui nivel superior – de exemplu, unui utilizator de nivel Shop Manager) .
Existenta unui set clar de discounturi ce se pot acorda pe o oferta .
Va exista un set clar de reguli de acordare a discounturilor .
Va exista un set de asocieri bazate pe incompatibilitati intre discounturi (nu se va putea acorda un discount daca in procesul de vanzare mai este implicat un discount cu care acesta nu este compatibil) . Toate aceste asocieri vor avea o descriere . Utilizatorul este notificat in cazul in care o astfel de restrictie de asociere intre discounturi este incalcata .
Sistemul Retail va asigura un sistem de regului de acordare a discounturilor de genul:
Discounturile vor avea o plaja de valori (un discount fix va avea aceleasi valori la maximul si minimul plajei) si pot fi valorice sau procentuale . Plaja de valori a unui discount ce poate fi acordat poate varia, in functie de nivelul de acces al utilizatorului .
Discounturile pot fi asociate unui nivel de acces la aplicatie (vezi utilizarea ofertelor) sau accesibile tuturor celor implicati in procesul de vanzare .
Vor exista discounturi optionale si unele dintre acestea se vor acorda, de exemplu, in functie de unele proprietati ale clientului . Unele discounturi insa vor fi cu acordare obligatorie (de ex . un discount de 5€ asociat unei fidelizari poate sa fie obligatoriu aplicat pentru unele produse) .
Discounturile trebuie sa aiba un identificator suplimentar la nivel de asociere care sa arate daca este obligatorie aplicarea sa . (de ex . un discount de 5€ asociat unei fidelizari sa fie obligatoriu sa fie aplicat pentru unele produse)
Pe o factura pot apare oricate discounturi, cu conditia ca acestea, insumate, sa nu depaseasca pretul produsului .
Atribute
Proprietatile unui discount includ:
numele discountului;
codul OA (la fel ca la produse: compus din doua segmente: COD1-COD2, COD1 este codul de producator iar COD2 este codul de produs);
valoarea discountului;
tip de valoare – procentuala sau valorica;
tip valoric – lei sau valuta (daca este vorba de un discount in valuta, );
valoare TVA aplicat valorii (identificatorul TVA-ului) – poate lipsi;
serie de identificare a tipului de discount– aplicabila celor ce pot fi scanate cu cititorul de bare de pe o lista si apoi aplicate;
unitatea de masura (lei puncte, etc . );
daca este sau nu discount global (cel global se aplica la nivelul facturii, conditionat sau nu de anumite entitati, pe cand discounturile obisnuite se aplica la nivel de produs);
daca este valid sau nu (un discount ce nu se mai acorda nu mai este valid);
daca este sau nu un discount flexibil – valoarea sa poate fi stabilita de catre vanzator;
identificator de sursa: arata de unde a venit acest discount – importat din sistemul CRM (Vantive), introdus manual, etc .
istoric de valabilitate discount (perioadele trecute de valabilitate si perioada curenta de valabilitate);
matrice de compatibilitate cu celelalte discounturi (arata daca un discount poate fi acordat impreuna cu un alt discount sau nu);
perioada de valabilitate;
etc;
Seturi de conditii asociere discount
Discounturile pot fi sau nu disponibile la o operatiune de vanzare in functie de o multime de conditii legate de:
tipul produsului – de ex . pot fi discounturi disponibile doar pe anumite tipuri de produse;
produsul;
clientul – de ex . discounturi disponibile in functie de diferite proprietati ale clientului;
magazinul;
optiuni;
plan tarifar;
pretul initial al produsului;
oferta;
orice combinatie intre cele de mai sus .
Aceste conditii fac ca unele discounturi sa fie legate de un produs, pe cand altele sunt acordate la nivel de produs, dar fara sa depinda de acesta (de ex . un discount generic de 10$ acordat unui client de tip Top Spender, aplicabil la nivel de produs, dar fara sa fie constrans de un anumit produs) . Contrangerile pot fi definite in sensul permiterii acordarii lor, dar si in sesnul inhibarii asocierii lor unor entitati ce definesc vanzarea (se definesc atat conditii de includere cat si conditii de excludere) . Aplicarea unui discount nu trebuie sa aduca valoarea facturii sub 0 .
Istoric al discounturilor
Sistemul Retail trebuie sa permita definirea discounturilor cu o perioada de valabilitate si trebuie sa tina un istoric al discounturilor .
Sistemul Retail trebuie sa faciliteze definirea de discounturi acordate unor produse numai pentru situatia in care sunt achizitionate in “pachete” (adica clientul poate beneficia de anumite discounturi doar daca cumpara un set de produse) .
Clasificari
Discounturile pot fi:
in lei sau valuta;
procentuale sau valorice;
fixe sau flexibile;
globale sau specifice (cele globale se aplica intregii vanzari, cele specifice unui produs);
acordabile numai de o anumita clasa de vanzatori (de ex . vanzatorii BSR pot acorda un discount variabil functie de numarul de SIM-uri de pe factura – in acest caz o constrangere suplimentara legata de numarul de SIM-uri de pe factura trebuie introdusa);
dependente de o anumita clasa de produse, de un interval valoric in care se incadreaza produsul sau de cantitatea de produse vandute cu care acest discount se inmulteste;
exprimate in preturi cu sau fara TVA (asta nu inseamna ca nu se mai percepe TVA pentru ele, ci pretul este exprimat intr-o anume forma . ) .
Punctele ThankYou
Un tip special de discount il reprezinta punctele ThankYou:
acest tip de discount poate fi acordat oricarui client Orange
Legaturi cu alte entitati
SHAPE * MERGEFORMAT
Produs |
Discount nume, cod, valoare, tip, |
Bon fiscal |
Pret |
Factura |
Proforma |
Client |
Plan tarifar |
Oferta |
Sistemul va asigura o scalabilitate si flexibilitate in manupularea informatiilor (atributelor) entitatii si va permite operatii de adaugare / modificare / stergere / clasificare / intervale de timp (prin calendare) / valabilitate . Din acest motiv sistemul va asigura un configurator propriu pentru toate categoriile de entitati enumerate .
“Oferta” reprezinta o parte a procesului de vanzare, un set de reguli de aplicare, cu conditii atasate . Regulile stabilesc preturile de pornire ale produselor si conditiile de calificare a clientului iar conditiile influenteaza procesul de vanzare (prin acordarea de discounturi suplimentare) .
Ofertele sunt suportul vanzarii de telefoane si accesorii . Vanzarile de accesorii, de pachete PrePay, de cartele sau servicii de raincarcare se pot face si fara a fi nevoie de prezenta unei oferte (doar in baza pretului implicit al produsului) .
Vanzatorul nu trebuie sa aiba o prea mare libertate in stabilirea unui pret final in cadrul unei operatiuni de vanzare: vor exista un set de reguli de acordare a discounturilor si de selectie a preturilor . In cazul in care un vanzator este nevoit sa aplice discounturi ce nu-i sunt accesibile sau premise (situatii exceptionale), el va putea sa-si asume rolul unui utilizator de drepturi superioare (folosind o parola speciala – situatie discutata mai jos) .
Relatia dintre Sistemul Retail si Vantive:
Discount-urile vor fi definite ca avand doua limite intre care vor putea fi acordate (o valoare minima si una maxima) . In cazul unor discounturi fixe, aceste limite vor fi egale . In functie de utilizatorul autentificat, aceste limite ale discounturilor vor putea fi diferite, la fel si preturile disponibile (cu alte cuvinte, acelasi discount ar putea avea limite diferite in functie de nivelul de acces) .
Va exista o lista de preturi si discounturi accesibile oricarui utilizator implicat in procesul de vanzare si o lista de preturi si discounturi accesibile numai utilizatorilor de nivel superior, acordabile in conditii speciale .
Fiecare produs poate avea mai multe preturi, in funcite un set de reguli stabilite in prealabil . Conditiile pot fi la nivel de:
Vanzarea printr-o oferta se va supune unor reguli stricte de acordare de discounturi, astfel incat vanzatorului sa nu-i fie permisa o flexibilitate indiferent cat de mare (vor fi discounturi ce ve vor aplica in mod obligatoriu, discounturi cu valoare variabila si seturi de discounturi optionale, dar fiecare va prezenta o dependenta stricta de tipul de vanzare – fidelizare, abonament, la liber, cu/fara prelungire contractuala, etc) .
SHAPE * MERGEFORMAT
Oferta nume, cod, descriere, tip, |
Produs |
Pret |
Discount |
In sistemul actual, ofertele au asociate planuri tarifare, depind de acestea si de optiuni; pot fi definite oferte ce sunt valabile numai pentru unii clienti sau numai pentru o categorie de clienti . In Sistemul Retail se doreste o flexibilitate mai mare, in sensul definirii seturilor de conditii de alocare discount sau asociere pret, despre care s-a vorbit anterior .
Ofertele (si implicit discounturile si preturile) au o perioada de valabilitate si prezinta un istoric al declararii lor si al perioadelor in care au fost active .
Clasificare
Ofertele pot fi de tip:
Ofertele pot mentine asocieri intre:
Ofertele vor fi descompuse in categorii de operatiuni frecvente:
Lista de categorii nu este fixa, ea putandu-se modifica cu timpul .
Fiecare categorie de operatiuni contine la randul ei procese de vanzare frecvente, operatiuni precum Fidelizare la 12 luni, Fidelizare la 24 luni, etc . Intrucat toate procesele de vanzare presupun vanzari cu anumite discounturi, prin extensie, si categoriile de operatiuni vor avea la randul lor asociate discounturi (de exemplu, nu se va putea asocia un discount de tip punct OrangeThankYou unei operatiuni de vanzare prin abonament) .
Pe factura tiparita de Sistemul Retail pot fi prezente mai multe categorii de operatiuni si chiar mai multe operatiuni din aceeasi categorie, insa nu se poate ca o linie a facturii sa aiba asociata mai mult de o operatiune .
Clientul ales determina tipul contractului, planul tarifar folosit in vanzare, optiunile ce determina oferta si discounturile ce i se pot acorda . .
Stabileste o legatura intre pret si produs: in cadrul unei oferte exista o asociere unica intre produs si pret . O oferta poate sa contina mai multe discounturi si mai multe conditii de acordare .
Atributele entitatii
Printre proprietatile ofertei se numara:
Finalizarea unei oferte cu drepturi extinse
Sistemul Retail va implementa un sistem de asumare temporara a unui rol de nivel superior, care sa permita o mai mare flexibilitate in vanzare .
Sistemul Retail va implementa si un sistem de definire a accesului unui utilizator de nivel inferior autentificat cu drepturi de pe un nivel superior
Pentru ca cele doua sisteme de asumare de drepturi si
accesare cu drepturi de nivel superior a aplicatiei sa fie implementate de
In cazul in care un utilizator de nivel inferior are nevoie pe timp limitat de drepturi extinse (de exemplu in cazul in care unui anumit client are nevoie sa-i acorde un discount special), acesta poate consulta o lista de utilizatori de nivel superior si sa initieze un proces de asumare temporara a unui rol de nivel superior (initiaza o cerere de acces extins) .
Dupa ce utilizatorul de nivel superior a fost ales, acestuia
i se adreseaza o notificare prin SMS cu cererea utilizatorului de nivel
inferior si cu o scurta descriere a motivului . Aceasta notificare contine si o
parola unica pe care initiatorul cererii o poate folosi (trebuie ca
utilizatorul destinatar al cererii sa i-o comunice) . Motivul este completat de
catre utilizatorul de nivel inferior (un
Aceasta parola unica poate fi generata de sistem sau poate fi intretinuta de utilizatorul de nivel superior (lista de parole) . Parolele pot fi introduse manual de catre utilizatori, sau generate automat de sistem .
Parola generata de sistem este unica, este valabila numai intr-un anumit interval (de ordinul orelor sau minutelor) si poate fi folosita numai de catre utilizatorul intiator o singura data .
Odata ce parola a fost generata de sistem, este monitorizata activitatea utilizatorului initiator si la finalul vanzarii, utilizatorul destinatar (de nivel superior) este notificat (pentru raportare) . La autentificarea in aplicatie, utilizatorul de nivel superior este notificat de toate accesele de pe nivelurile de acces inferioare la discounturile nivelului sau .
Orice utilizator de nivel superior poate sa delege drepturi de acces utilizatorilor de pe nivelurile inferioare si poate sa opteze pentru folosirea sau nu a sistemului de acordare dinamica de parole . Orice utilizator de nivel superior poate delega drepturi de acces la parti din zonele aplicatiei la care are acces, sau poate acorda si drepturi asupra unor obiecte (discounturi sau preturi) ce ii apartin exclusiv .
Legaturi cu alte entitati
SHAPE * MERGEFORMAT
Produs |
Oferta denumire, cod, tip, |
Pret |
Discount |
Alte entitati |
Client |
Plan tarifar |
Sistemul va asigura o scalabilitate si flexibilitate in manupularea informatiilor (atributelor) entitatii si va permite operatii de adaugare / modificare / stergere / clasificare / intervale de timp (prin calendare) / valabilitate . Din acest motiv sistemul va asigura un configurator propriu pentru toate categoriile de entitati enumerate .
Stocul contine toate produsele disponibile din punct de vedere comercial (inclusiv unele produse promotionale), prezente in gestiunea magazinului .
Atribute
Stocul contine toate produsele inventariate in magazine (produsele pentru vanzare, produsele promotionale, produsele cadou, defectele, etc . ) . Este o entitate identificata de urmatoarele proprietati:
magazin;
magazia;
produsul;
seria;
cantitatea (daca nu are serie);
etc .
Clasificare
Stocul poate fi impartit in:
stoc vanzator (magazie individuala);
stoc magazin (magazia magazinului de pe care se fac apoi transferurile pe stocurile individuale);
stoc defecte (telefoanele din magazin defecte);
stocurile de SAV service:
o magazie de produse defecte preluate de la client;
o magazia de produse defecte trimise in service;
o magazia de produse defecte reparate si returnate de la service,
o magazia de telefoane de SWAP din magazin;
o magazia de telefoane de SWAP imprumutate clientilor;
o magazia de telefoane de SWAP defecte din magazin;
stocul de accesorii;
stocul de produse din vitrina .
Fiecare stoc individual are asociat un vanzator si o lista de utilizatori cu drepturi mai largi ce pot accesa acest stoc pentru vizualizare sau pentru modificare .
Stocurile sunt afectate de vanzari, transferuri, operatiuni SAV, retururi, receptii, schimburi, etc .
Legat de stocuri, vor exista si unele alarme de sistem (pop-up de avertizare):
Stocul este asociat unei magazii . Nu vor exista produse (fizice) care sa nu aiba asociata o magazie (taxele, serviciile, discounturile nu apartin vreunei magazii) .
Magaziile pot fi:
Magaziile vizibile includ:
Proprietatea de vizibil(disponibil)/invizibil(indisponibil vanzarii) va fi un atribut la nivel de magazie/tip de magazie si va putea fi stabilit de catre utilizator .
InfoShops poate vizualiza stocul din Magaziile vizibile, putand lansa pentru produsele din aceste magazii comenzi de rezervare . Vizibilitatea din punctul de vedere InfoShops nu este la nivel de magazie, ci la nivel general (stoc total in magaziile vizibile) .
Magazia de produse rezervate este o magazie speciala, nu e vizibila de catre InfoShops si contine si informatii suplimentare de rezervare (vezi Subiectul ‘Sistemul de rezervare’) .
Magaziile ascunse contin produse indisponibile:
Magazia Touch&Try de telefoane uzate cuprinde telefoane din magazia Touch&Try, si care acum sunt uzate . Acestea pot fi vandute la un pret special (cu discount) . Se va putea calcula perioada dintre mutarea pe stocul de Touch&Try si mutarea pe stocul de Uzate, si in functie de aceasta perioada din stocul de uzate pot fi vandute telefoane la un pret variabil .
Nu se permit operari simultane asupra stocului la nivel de cod de produs si magazie . Utilizatorul este notificat de cazul in care transferul este operat partial, din motiv de blocare acces la stoc (in cazul unei tranzactii de transfer, o parte din produse nu pot fi transferate din motivul enuntat mai sus, restul produselor vor putea fi transferate) .
Daca un utilizator opereaza pe stocul unui produs dintr-o magazie si un alt utilizator opereaza pe stocul aceluias produs, dar din alta magazie, sistemul permite realizarea simultana a ambelor operatiuni (cu conditia ca nici magaziile destinatare sa nu fie aceleasi) .
Daca doi utilizatori simultan doresc sa opereze asupra a doua produse distincte, sistemul va permite aceasta, indiferent de magazia pe care se opereaza sau de magazia destinatie .
Daca doi utilizatori incearca sa opereze asupra aceluiasi produs (produs cu sau fara serie), aflat in aceeasi magazie (sau cu aceeasi magazie destinatie), sistemul nu va permite celui de-al doilea utilizator sa opereze acel produs (doar il va vedea; la initierea operarii ii va aparea un mesaj “Asupra produsului [] din magazia [] se desfasoara o tranzactie initiata de []”)
Vizualizarea stocurilor se va face la nivel de produs si cantitate . Daca se doreste selectarea unei anumire serii, prin click pe linia cu produsul dorit se ajunge la lista de serii de pe stoc ale acestui produs (daca este un produs fara serie, nu se intampla nimic la click pe produs) . Daca se doreste selectarea unei serii a unui produs de pe stoc prin cititorul de coduri de bare, va exista si o zona de cautare dupa serie . Scaderea seriei este vizibila numai in detaliile tranzactiei, pe stocul vizibil se va observa numai diminuarea cantitatii de pe stoc .
Fiecare utilizator va avea acces la stocul istoric de final de zi, dar numai pentru gestiunea sa .
Un utilizator autentificat sub nivel de Shop Manager poate vizualiza stocurile istorice ale oricarui alt utilizator, precum si tranzactiile acestuia (operarile pe stoc) .
Un utilizator ce mai are inca produse in magazia intermediara, nu poate face “Inchiderea de Zi” pana ce nu face receptia acestor produse, sau pana ce nu refuza acest transfer .
Transferurile intre gestiuni pote fi efectuate doar de catre utilizatori sub rolul de Stock Keeper, rol pe care si-l pot asuma utilizatorii autorizati (inclusiv vanzatorii) .
Tranferurile pot fi operate chiar daca utilizatorul a carui gestiune este afectata nu a facut “Inchiderea de Zi” .
In momentul in care un transfer este operat, utilizatorul care il efectueaza este responsabil pentru produsul transferat in gestiunea destinatie (pana in momentul in care acest produs ajunge fizic in gestiunea destinatie) .
Operarile scriptice pe gestiune trebuie sa corespunda
operarii fizice pe gestiune si trebuie sa respecte procedura interna
Un utilizator in a carui magazie se efectueaza un transfer, este anuntat de aplicatie si i se cere sa confirme receptia tutror produselor implicate in acest transfer (vezi Transfer cu magazia intermediara) .
Utilizatorul de pe nivel Sef de Magazin se considera ca are acces la stocul unui vanzator, dupa ce acesta si-a facut “Inchiderea de ZI” si inainte de orice alta noua autentificare in Sistem a sa .
La efectuarea unei inchideri de zi, urmatoarele rapoarte zilnice sunt obligatorii:
Utilizatorii de nivel vanzator, operand sub rolul de Stock Keeper, pot transfera in oricare magazie (inclusiv in propria magazie) din oricare alta magazie si din oricare magazie (inclusiv din propria magazie) in oricare alta magazie .
Un utilizator de nivel superior (de ex . Retail Area Manager, Shop Manager sau Retail Controller) sa poata opera corectii de marfa pe o gestiune:
Vizibilitatea stocului din sisteme externe – OA
Toate operatiunile asupra stocului, care sunt relevante din punct de vedere al stocului la nivel de magazin, se vor sincroniza cu OA, prin intermediul tranzactiilor operate asupra sa .
Stocul din Sistemul Retail va fi vizibil in OA, in timp real . Se va face si o detaliere pe magazii (la cerere, din Sistemul Retail se va putea vizualiza chiar si numai un subinventar al unui magazin – de ex . stocul de defecte) . Unele magazii sunt indiponibile OA:
Va exista si o magazie speciala de transfer intre magazine (in cadrul celor de rezervari) vizibila in OA .
Stocul din OA poate fi vizibil in Sistemul Retail, dar acesta este neconcludent, din cauza fluxului mare de comenzi (un stoc AVAILABLE la un moment dat este posibil sa aibe in asteptare mai multe rezervari – inca neoperate - sau sa urmeze sa fie alimentat in curand, asa ca valoarea sa curenta nu reflecta realitatea) .
La nivel de serie IMEI sa se poata lansa periodic (initial cu o frecventa de o data pe saptamana) o verificare stocul din OA si cel din Sistemul Retaiil . Rezultatele acestei verificari vor fi trimise prin eMail persoanelor interesate, si vor putea fi si accesate din Sistemul Retail de catre utilizatori autorizati .
Transferul cu magazia intermediara
Orice transfer efectuat catre o gestiune a unui utilizator de nivel Vanzator, gestiune diferita de cea a utilizatorului care efectueaza transferul, va trece printr-o magazie intermediara .
Un astfel de transfer presupune doua faze:
Utilizatorului destinatar i se afiseaza apoi un mesaj pop-up cu informatia ca sunt in asteptare pentru transfer un numar de produse . Click pe popup si in fereastra ce se va afisa apoi se bifeaza fiecare produs receptionat si la apasarea butonului de OK se finalizeaza transferul si se afiseaza nota de transfer .
Aceasta magazie intermediara nu este implicata in transferurile cu magazia magazinului, magazia de defecte, de rezervari, etc .
Vanzatorului implicat intr-un asemenea transfer, pecum cel descris mai sus, i se afiseaza un popup din aplicatie in care este anuntat ca tocmai i-au fost transferate pe stoc si i se cere sa bifeze (in scop de verificare) produsele pe care le receptioneaza (va exista si un buton de “Selecteaza toate produsele”) .
Consultare stoc
Sistemul Retail trebuie sa ofere posibilitatea fiecarui vanzator de a-si vizualiza stocul propriu la orice moment si, in functie de drepturi, de cautare a unor produse in stocurile apartinand altor entitati (alti vanzatori, magazinul din care face pare, alte magazine, etc . ) .
Istoric stoc
Sistemul Retail va pastra un istoric al stocurilor . Istoricul de stocuri contine data salvarii si apoi datele de stoc (vezi mai sus) . Istoricul de stoc poate fi salvat la nivel de zi sau la nivel de luna sau ambele (pentru o consultare mai usoara si comparatie cu sistemul OA) .
Legaturi cu alte entitati
SHAPE * MERGEFORMAT
Produs |
Stoc magazin, magazie, produs, serie, etc |
Proforma |
Bon fiscal |
Factura |
Tranzactie |
Utilizator |
Sistemul va asigura o scalabilitate si flexibilitate in manupularea informatiilor (atributelor) entitatii si va permite operatii de adaugare / modificare / stergere / clasificare / intervale de timp (prin calendare) / valabilitate . Din acest motiv sistemul va asigura un configurator propriu pentru toate categoriile de entitati enumerate .
Entitatea utilizator reprezinta orice persoana ce interactioneaza cu Sistemul Retail, interactiune care se face intr-o maniera controlata de drepturile de acces . Fiecare utilizator are asociat un nivel de acces la aplicatie . Utilizatorii trebuie sa fie unic identificabili din punct de vedere al interactiunii lor cu Sistemul Retail .
Fiecare utilizator apartine unui nivel de autoritate, sau mai multora . In cazul din urma, la autentificarea in aplicatie, este fortat sa-si aleaga un nivel de autoritate sub care doreste sa opereze in Sistemul Retail .
Dintre toate nivelurile de autoritate pe care le poseda, un utilizator apartine “nativ” unui singur nivel, acesta fiind cel implicit de activitate . (de ex . un utilizator poate fi si Vanzator si Stock Keeper)
Utilizatorii vor fi grupati pe niveluri de acces si roluri
La fiecare nivel de acces vor exista atasate drepturi de acces suplimentare (de ex . , pentru utilizatori BSR, drept de accces la un anumit discount sau la anumite plaje pentru un anume discount) – in cadrul nivelurilor de autoritate definite mai sus .
Sistemul Retail va permite declararea unei liste de functionalitati primare asupra carora se pot introduce restrictii de acces (de ex . vanzare PrePay, vanzare cu CC , Transfer extern marfa sau vanzare prin bon de casa) .
Aceste functionalitati primare pot fi combinate in grupuri functionale, pentru a fi mai usor manipulate de catre administratorul aplicatiei la acordarea de drepturi .
Grupurile functionale pot fi la randul organizate in roluri, fiecare rol putand avea unul sau mai multe grupuri functionale atasate .
Un utilizator ce are asociat un anume rol dobandeste accesul la functionalitatile primare ce sunt continute in grupurile functionale ale rolului .
La definirea unui utilizator se aleg dintr-o lista rolurile pe care acest utilizator le va avea .
Perspectivele de vizualizare dicteaza felul in care un utilizator are acces la functionalitatile oferite de rolul sau (ordinea meniurilor, gruparea functiilor cele mai folosite, etc . )
Exemple de roluri definibile:
Fiecare nivel de autoritate va avea asociata o “perspectiva” asupra operatiunilor pe care are dreptul sa le execute (fiecare nivel de autoritate este o suma de drepturi) .
“Perspectiva” nivelului de autoritate presupune chiar si un layout al paginii si al meniurilor disponibile .
Un utilizator poate avea acces la mai multe “perspective”, fie in functie de nivelul de autoritate sub care doreste sa opereze in sistem, fie sa aibe posibilitatea de a-si creea propria sa perspectiva .
Operatiunile cele mai frecvente vor fi amplasate la indemana . In ecranul imediat urmator autentificarii in Sistemul Retail va exista o zona in care vor aparea aceste operatiuni sub forma de link-uri catre paginile de inceput ale operatiunilor dorite . Chiar si in cazul in care un utilizator se autentifica pentru prima data in Sistem, el va avea aceasta lista de operatiuni frecvente, pentru ca operatiunile frecvente vor fi asociate fiecarui nivel de autoritate, sau fiecarui tip de utilizator . In cazul unui utilizator constant al aplicatiei, operatiunile frecvente sunt calculate din analiza activitatii sale (in baza log-urilor de activitate) .
Nivelul de autoritate permite si acccesul la unele functii specifice (de ex . discounturile definite pentru un anumit nivel de autoritate, transferuri externe, etc . ) .
Atribute
Utilizatorii sunt definiti de urmatoarele atribute:
nume;
cod;
parola;
locatia scriptica in care isi desfasoara activitatea (un casier poate activa in cadrul unui magazin, dar sa fie gestionat la nivelul unei entitati speciale ce contine utilizatori din mai multe magazine)
magazinul in cadrul caruia isi desfasoara activitatea;
magazia asociata;
nivelul de acces;
identificator de casa de marcat (de obicei la fel ca si codul);
date buletin:
o CNP;
o serie;
o numar;
o sectia de politie eliberatoare;
o etc .
daca este sau nu un vanzator BSR (Bussiness Sales Representative);
utilizatorul sau utilizatorii delegati sa actioneze in numele sau;
etc .
Clasificare
Rolurile (sau nivelurile de acces) sunt:
vanzator;
stock keeper;
sef de magazin;
retail area manager;
retail channel manager;
commercial;
etc .
Categoriile in schimb impart utilizatorii pe departamente (se considera ca o delegare inter-departamentala nu este permisa):
Rolurile sunt axate pe functionalitati
Grupurile sunt axate pe drepturi de acces la unele obiecte apartinand diverselor functionalitati (de ex . rol de vanzator => acces la vanzare; apartine grupului de retail => poate acorda anumite discounturi, daca ar fi fist BSR, ar fi accesat mai multe discounturi)
Acordarea de drepturi se va face si pe perioade nedefinite (de ex . pentru unii vanzatori cu experienta, shop managerul poate alege delegarea de drepturi depline pe perioada nedefinita)
Ex . de ierarhie:
ORO
OROSH
AR
GL
EH
OROSOHO&SME
RAMAR
RAMOR
RAMPL
OROCORP
CBC-EH
CBC-BV
OROSHCAS
CASEH
CASPL
CASCR
Drepturile de acces
Drepturile de acces permit numai vizualizare, numai
adaugare, vizualizarea si modificarea sau toate cele enumerate . Drepturile de
acces sa poata fi create si in functie de grupul din care face parte
utilizatorul, locatia sa fizica, in cadrul unui departament sau in cadrul unui
magazin
Utilizatorii pot fi asociati unui anume magazin, sau pot fi utilizatori generici, ce se pot conecta oriunde, dar in functie de drepturile pe care le au pot accesa o parte sau toate functionalitatile Sistemului Retail . Trebuie, de asemenea, sa fie definite functionalitatile Sistemului Retail carora se doreste sa le fie asociate drepturi de acces . Se va construi in acest sens o matrice de drepturi ce va dicta ce utilizator ce functionalitati acceseaza .
In cazul in care un utilizator de nivel inferior are nevoie pe timp limitat de drepturi extinse (de exemplu in cazul in care unui anumit client are nevoie sa-i acorde un discount special), acesta poate consulta o lista de utilizatori de nivel superior si sa initieze un proces de asumare temporara a unui rol de nivel superior (initiaza o cerere de acces extins) .
Dupa ce utilizatorul de nivel superior a fost ales, acestuia
i se adreseaza o notificare prin SMS cu cererea utilizatorului de nivel
inferior si cu o scurta descriere a motivului . Aceasta notificare contine si o
parola unica pe care initiatorul cererii o poate folosi (trebuie ca
utilizatorul destinatar al cererii sa i-o comunice) . Motivul este completat de
catre utilizatorul de nivel inferior (un
Aceasta parola unica poate fi generata de sistem sau poate fi intretinuta de utilizatorul de nivel superior (lista de parole) . Parolele pot fi introduse manual de catre utilizatori, sau generate automat de sistem .
Parola generata de sistem este unica, este valabila numai intr-un anumit interval (de ordinul orelor sau minutelor) si poate fi folosita numai de catre utilizatorul intiator o singura data .
Odata ce parola a fost generata de sistem, este monitorizata activitatea utilizatorului initiator si la finalul vanzarii, utilizatorul destinatar (de nivel superior) este notificat (pentru raportare) . La autentificarea in aplicatie, utilizatorul de nivel superior este notificat de toate accesele de pe nivelurile de acces inferioare la discounturile nivelului sau .
Modalitatea de delegare de drepturi este definita la nivel de rol, dar fiecare utilizator de nivel superior poate sa aleaga metoda (metodele) prin care se face delegarea de drepturi .
Rezumand: delegarea de drepturi poate sa fie facuta:
Fiecare utilizator de nivel superior va putea defini o lista de utilizatori (de nivel inferior, evident) care vor putea obtine temporar drepturi de nivel superior . In dreptul fiecarui utilizator de nivel inferior (beneficiarul drepturilor), utilizatorul de nivel superior (furnizorul drepturilor) va putea specifica daca este necesara autentificare prin cod transmis prin SMS sau, in cazul in care este vorba despre o persoana in care acesta are deplina incredere, aceasta delegare temporara se va putea face fara confirmare din partea furnizorului dreptului (vezi delegarea) .
In ambele cazuri (cu autentificare prin cod trimis prin SMS sau fara autentificare speciala) actiunile utilizatorului care a primit in mod exceptional drepturi de nivel superior vor fi salvate in loguri, iar aceste informatii vor fi afisate furnizorului acestor drepturi exceptionale in fereastra principala a aplicatiei, cu ocazia urmatoarei logari .
In acest fel, furnizorul drepturilor va putea inspecta imediat toate actiunile facute de utilizatori in perioada in care au primit acele drepturi exceptionale .
Delegarea
Fiecare utilizator poate delega un alt utilizator sa actioneze in numele sau in aplicatie . Delegarea se va face pe o perioada, de catre utilizatorul delegator . Un utilizator poate delega un grup sau o lista de utilizatori sa actioneze in numele sau .
Un utilizator de nivel superior poate delega un alt utilizator drepturile sale de acces, pe o perioada limitata .
Delegarea nivelului de autoritate se poate face in mod explicit:
La alegerea perioadelor de delegare se vor introduce si datele si orele intre care se face delegarea; se va adauga si un scurt comentariu descriptiv relativ la motivul delegarii . Delegarea poate fi facuta numai de utilizatorul de nivel superior, adica acest proces de delegare poate fi initiat numai de catre utilizatorul ce doreste sa-si delege drepturile .
Delegarea se poate face catre un utilizator sau catre o lista de utilzatori . Pentru fiecare din acesti utilizatori se poate defini si dreptul ca acestia, la randul lor, sa poata delega aceste drepturi mostenite altor utilizatori de pe acelasi nivel ierarhic sau de pe un nivel ierarhic inferior .
Poate sa existe si un sistem de “delegare exceptionala”: numai un utilizator de nivel superior poate sa delege drepturi exceptionale unui utilizator de nivel inferior . Initierea unei delegari execeptionale se face pentru cate o singura operatiune(are legatura cu parola de acces trimisa prin SMS – vezi mai sus) .
Autentificare prin amprenta digitala
Sistemul Retail va putea fi extins pentru a permite interfatarea cu un device de autentificare prin amprenta digitala, identificandu-se astfel fara echivoc persoana care inceraca sa se autentifice in aplicatie .
In cazul in care aceasta persoana are asociata mai multi utilizatori (prin indeplinirea mai multor functii, or prin delegarea primita din partea altor utilizatori) sistemul va afisa o lista de conturi sub care utilizatorul se poate conecta . Acest lucru nu este necesar in cazul in care exista un singur cont asociat, caz in care logarea se va face automat .
Sistemul de “Inchidere Zi”
Utilizatorii care au magazii asociate sunt singurii care pot face transferuri de iesire de pe gestiunea proprie . Pentru ca si Stock Keeper-ul sa aibe acest drept, utilizatorul trebuie sa poata face o “inchidere de zi”, sa marcheze in acest fel incheierea oricaror operatii si sa permita accesul la gestiunea sa .
Pe parcursul zilei, un utilizator de nvel inferior, cu gestiune proprie, poate sa se autentifice si sa faca “LogOff” de mai multe ori, dar abia la sfarsitul programului face “Inchiderea de Zi” . Prima autentificare in aplicatie dupa ce o “Inchidere de Zi” este facuta, declanseaza automat un “Inceput de Zi” si gestiunea utilizatorului respectiv este blocata numai accesului sau .
“Inchiderea de Zi” poate fi facuta:
In functie de starea in care se afla gesiunea unui utilizator, se definesc 2 stari posibile:
Numai in perioada “Out of Office” Stock Keeperul va avea dreptul sa opereze transferuri in gestiunea vanzatorului .
Daca un vanzator inca nu a facut “Inchiderea de Zi”, iar cu gestiunea sa se opereaza transferuri, sa fie atentionat printr-un pop-up de genul: “Atentie! Tocmai ti-au fost transferate din/spre stoc, urmatoarele produse: Esti de acord sa le receptionezi/Esti de acord sa-ti fie destocate?”
Daca vanzatorul a facut deja “Inchiderea de Zi”, nu i se mai cere permisiunea, dar este totusi instiintat de transferul ce tocmai a fost operat .
Un utilizator de nivel superior poate alege si fortarea unui transfer pe/de pe stoc in cazul in care un vanzator inca nu a facut “Inchiderea de Zi”, dar nu este inca disponibil pentru a-si da acordul (de ex . e in pauza de masa) . Si in acest caz vanzatorul este atentionat de efectuarea transferului .
De asemenea, vanzatorul catre care se opereaza un astfel de transfer nu-si poate efectua “Inchiderea de Zi” pana ce nu rezolva toate transferurile ce ii asteapta acordul .
In cazul in care o “Inchidere de Zi” este efectuata automat de Sistemul Retail . superiorul ierarhic al vanzatorului trebuie sa fie instiintat de acest lucru .
Mecanismul ce sta in spatele “Inchiderii de Zi” va putea sa fie modificat de utilizatori autorizati (perioada de inactivitate dupa care se efectueaza o “Inchidere de Zi”, activarea/dezactivarea “Inchiderii de Zi” automata, etc . )
Pentru a se incuraja folosirea functiei de “Inchidere Zi”, numai dupa folosirea acestei functii vor aparea rapoartele de sfarsit de zi, rapoarte ce nu sunt disponibile decat intr-o forma partiala (cu un marcaj clar pe raport) daca nu este operata “Inchidere Zi” . Rapoartele in forma completa – ce poate fi predata de exemplu la casieri – sunt accesibile numai unui utilizator de nivel superior . Va exista, deci, un borderou partial si unul final . Borderoul partial va fi folosit pentru plati partiale la casierie in cursul unei zile si va fi marcat corespunzator (de ex . “Exemplar borderou partial”) . Borderoul final marcheaza finalul unei zile de activitate a unui vanzator . In cazul in care acesta mai trebuie sa mai efectueze o vanzare i se va permite sa mai emita un borderou final (pentru aceasta utilizatorul va face o “Inchidere de zi”, o autentificare in aplicatie – operatie ce redeschide ziua de lucru –, o vanzare si apoi iar o “Inchidere de Zi”, in urma careia va putea tipari noul borderou final de incasari) .
Borderoul final nu se poate emite decat daca se face “Inchiderea de Zi” .
Borderoul va afisa valoarea incasarilor cash pe facturi, incasarile pe bonuri de casa precum si totalul incasarilor cash .
Aplicatia nu va permite unui vanzator rularea vreunei noi operatiuni pana ce nu se inchide ziua precedenta, operatiune ce declanseaza emiterea borderoului final pe ziua anterioara .
Audit trail
Sistemul Retail va gestiona un sistem de loguri care vor stoca informatii despre interactiunile utilizatorilor cu Sistemul . Aceste loguri vor fi accesibile pentru consultare utilizatorilor autorizati si nu vor putea fi modificate sau sterse de catre nici un utilizator .
Orice modificare facuta prin aplicatie de catre un utilizator trebuie sa permita identificarea acestuia in mod unic .
Toate actiunile efectuate de catre utilizatorii delegati sa actioneze in numele unui user delegator trebuie sa introduca in log informatii referitoare atat la utilizatorul care face actiunea (utilizatorul delegat) cat si la cel in numele caruia o face (utilizatorul delegator) .
Legaturi cu alte entitati
SHAPE * MERGEFORMAT
Factura |
Utilizator nume, cod, parola, magazin |
Stoc |
Proforma |
Bon fiscal |
Magazin |
Sistemul va asigura o scalabilitate si flexibilitate in manupularea informatiilor (atributelor) entitatii si va permite operatii de adaugare / modificare / stergere / clasificare / intervale de timp (prin calendare) / valabilitate . Din acest motiv sistemul va asigura un configurator propriu pentru toate categoriile de entitati enumerate .
O magazie reprezinta o gestiune, un recipient pentru marfa fizica aflata la un magazin sau in gestiunea Orange SA . Fiecare magazie este in mod unic asociata unui magazin, iar fiecare magazin are in mod unic asociat un cod alfanumeric (Codul Jupiter) .
Magaziile pot fi:
Magaziile pot avea un proprietar (un responsabil asupra stocului aflat in aceste magazii) si sunt asociate in mod unic unui magazin si unei regiuni .
In toate magaziile informatiile depre produse sunt stocate la nivel de serie IMEI, exceptie facand magazia de Rezervari Generale, o magazie in care se rezerva un anumit produs, dar fara sa fie o anumita serie rezervata (de ex . pentru cazurile in care un client face o rezervare prin TeleSales) . Rezervarea se face la nivel de serie in cazul unei proforme, sau in cazul unui transfer intre magazine, de exemplu .
Magaziile vor fi organizate in ierarhii, depinzand de regiune,
magazin, tip magazie, etc . Printre atributele importante ale unei magazii se
numara si locatorul . Aceasta proprietate identifica sursa marfii disponibila la
vanzare si modul in care ea va fi gestionata in OA . Fiecare magazie poate avea
locatorul sau: de ex, cel de magazin
Exemplu de ierarhie:
Locator
Regiune (
Magazin (Europe House,
Tip Magazie (vizibila, ascunsa, etc)
Subtip Magazie (magazie vanzator, magazie rezervari, T&T, etc)
FineGrained Subtype (T&T uzate, T&T expuse, Rezervari InfoShops, Rezervari transfer, Rezervari vanzare - locala)
Magazia (Magazie V1AR, Magazie T&T uzate
O magazie poate fi validata sau invalidata, poate fi mutata de la un utilizator la altul, dar numai in cadrul aceluias magazin .
O tranzactie reprezinta o inregistrare a detaliilor unui transfer de marfa in una din urmatoarele situatii:
intre gestiunile magazinelor;
in cadrul gestiunii unui magazin;
transferuri catre WAREHOUSE;
receptii de marfa de la WAREHOUSE;
transferuri catre Service;
receptii din Service;
transferuri pe gestiunea clientului (produse in custodia clientului);
receptii din gestiunea clientului;
Atribute
Printre proprietatile tranzactiilor se numara:
data;
tipul de transfer:
o intern, intre magaziile magazinului;
o extern, intre magazine (prin intermediul unei magazii intermediare);
o receptii de marfa (de la Depozitul Central, sau de la un alt magazin);
o notele de retur (catre Depozitul Central sau catre un alt magazin);
o trimiteri in Service;
o receptii in Service
numarul AIM-ului cu care s-a facut receptia sau returul de marfa (inclusiv catre Service);
magazia de intrare (daca e retur de marfa va lipsi);
magazia de iesire (daca e receptie de marfa va lipsi);
furnizorul sau destinatarul marfii trimise;
numarul comenzii (daca este o receptie de la Depozitul Central in baza unei Comenzi);
motivul transferului (completat dupa caz);
produsele implicate in tranzactie (tip, model, producator, etc . );
seriile produselor;
cantitatea (daca nu au serie, sau este serie de tip de produs);
valoarea asigurata a produsului;
daca este o tranzactie in magazia de defecte (nu cea de SAV Defecte), descrierea defectului reclamat;
detalii legate de expeditor (reprezentatntul firmei de curierat) – in cazul in care este vorba de o tranzactie externa:
o seria buletinului si numarul buletinului si alte detalii legate de actul de identitate;
o mijlocul de transport (tip, numar inmatriculare, etc . );
o numele expeditorului;
numele firmei de curierat – in cazul in care este vorba de o tranzactie externa;
etc .
Transferurile catre WAREHOUSE se fac numai cu acordul Logisticii . Pot contine atat telefoane obisnuite (pe gestiunea de marfa pentru vanzare) , cat si telefoane defecte (DOA – dead on arrival) sau telefoane de SWAP retrase spre casare .
Atat transferurile catre Service cat si receptiile din service se fac numai in baza unui PV de trimitere in Service si un AIM (aviz de insotire a marfii) .
Transferurile pe/din gestiunea clientului se fac in baza unui contract de comodat (de ex . un modem Navini este inchiriat clientilor care incheie si un contract de date, sau un modem Navini poate fi in gestiunea unui client pentru teste, se testeaza posibilitatea interconectarii in retea) .
Fiecare utilizator poate sa-si vizualizeze doar tranzactiile proprii, care se compun pentru a ilustra dinamica propriei sale gestiuni .
Intr-un astfel de acces la tranzactii vor fi afisate date care sa raspunda la intrebarile cine?, ce?, de unde? si unde? – anume utilizatorul care transfera, gestiunea sursa, gestiunea destinatie, cantitatea, produsele .
Legaturi cu alte entitati
SHAPE * MERGEFORMAT
Stoc |
Tranzactie data, tip transfer, aim |
Utilizator |
Produs |
Magazin |
Operatori de service
In cazul transferurilor cu Service-ul, trebuie sa fie mentinuta si o lista de Operatori de Service, care sa contina printre altele:
numele Operatorului de Service;
adresa;
CUI (Cod Unic de Inregistrare la Registrul Comertului);
contul bancar si banca Operatorului;
etc .
Sistemul va asigura o scalabilitate si flexibilitate in manupularea informatiilor (atributelor) entitatii si va permite operatii de adaugare / modificare / stergere / clasificare / intervale de timp (prin calendare) / valabilitate . Din acest motiv sistemul va asigura un configurator propriu pentru toate categoriile de entitati enumerate .
Magazinul este un punct de desfacere si prezentare a serviciilor si produselor oferite de companie .
Atribute
Magazinele pot fi mai multe in acelasi oras sau mai multe in aceeasi regiune fiind definite de:
denumire;
adresa;
numar de fax (trecut pe proforme);
cod Jupiter si OA;
regiunea sau un alt identificator de locatie;
orasul;
locatorul corespunzator Jupiter;
banca si contul in care se fac platile (apare pe proforma, pe langa bancile si conturile companiei);
turneul de aprovizionare de care apartine (turneul de aprovizionare reprezinta regiunea pentru care si data la care se face aprovizinarea cu marfa – de ex . pentru Bucuresti exista dublu turneu: se aprovizioneaza de doua ori pe saptamana si aceasta aprovizionare se face numai pentru Bucuresti);
curierul cu care se receptioneaza marfa de la WAREHOUSE;
informatii legate de aprovizionare (vezi mai jos);
etc .
Magazinele pot fi impartite pe zone geografice, pot fi corelate cu o localitate si un turneu, pot fi Corporate sau Retail . Pot avea asociate oferte si discounturi .
Magazinul, la definire, va contine si informatii legate de aprovizionare . Fiecare magazin va avea o zi din saptamana asociata, reprezentand ziua cea mai tarzie in care trebuie incheiata o comanda si trimisa Logisticii . De asemenea, magazinul va avea asociata si o perioada de alimentare (intervalul existent intre 2 comenzi succesive) .
Magazinele definite in sistem vor avea asociata si o valoare procentuala pana in care pot depasi valoare de stoc a tranzactiilor efectuate de la ultima comanda . Va exista un procentaj implicit de depasire a comenzii, modificabil pentru fiecare magazin .
Magazinele au asociate sub-inventare (o lista de magazii) pe care utilizatorii autorizati le alimenteaza cu produse din stocul magazinului .
Legaturi cu alte entitati
SHAPE * MERGEFORMAT
Stoc |
Magazin denumire, adresa, |
Utilizator |
Factura |
Client |
Tranzactie |
Sistemul va asigura o scalabilitate si flexibilitate in manupularea informatiilor (atributelor) entitatii si va permite operatii de adaugare / modificare / stergere / clasificare / intervale de timp (prin calendare) / valabilitate . Din acest motiv sistemul va asigura un configurator propriu pentru toate categoriile de entitati enumerate .
Planurile tarifare reprezinta tipurile de abonamente oferite
de Orange
Planurile tarifare pot influenta si preturile finale sub care un client poate face achizitii din magazine .
Planurile tarifare depind si de tipul clientului – exista planuri tarifare dedicate anumitor tipuri de clienti, aplicatia trebuie sa nu permita “accesul” unui client la planuri tarifare ce nu ii pot fi asociate .
Planurile tarifare sunt introduse in sistem fie printr-o procedura de import din sisteme externe (sistemul CRM), fie manual de catre un user ce are dreptul la aceasta operatiune .
Sistemul va asigura o scalabilitate si flexibilitate in manupularea informatiilor (atributelor) entitatii si va permite operatii de adaugare / modificare / stergere / clasificare / intervale de timp (prin calendare) / valabilitate . Din acest motiv sistemul va asigura un configurator propriu pentru toate categoriile de entitati enumerate .
La importul unui plan tarifar din Vantive, i se va atasa si o informatie de tip . Aceasta va fi intretinuta o lista de tip-uri de planuri tarifare, si fiecarui nou plan tarifar i se va asocia o singura valoare din aceasta lista . Pentru tipuri compuse (de ex . Voce + Date) se vor genera noi tipuri de planuri tarifare .
Sistemul Retail trebuie sa permita co-existenta mai multor valori pentru TVA, dintre care unul singur este cel implicit . Un TVA poate fi sau nu valid, dar cel implicit nu poate fi invalid .
Este taxa ce afecteaza toate vanzarile, toate preturile din aplicatie, in afara de pretul punctelor TY, care sunt calculate cu TVA .
Atribute
Definit de:
descriere taxa;
valoare TVA;
indentificator de TVA “default” – daca este sau nu un TVA default;
cod TVA (pot avea de exemplu TVA_DEBT si TVA_0, ambele codificari pentru un TVA cu valoare 0) – acest cod se importa din sistemele externe catre care ajung vanzarile si reprezinta cota TVA ce o plateste un client (este preluata din OA – de ex . TVA 19% si Scutit DED);
valid/invalid .
Cotele de TVA vor avea asociate coduri speciale, folosite in exportul catre OA . In functie de categoria clientului, o cota de TVA va fi aleasa implicit pe factura (existand si posibilitatea schimbarii ei manuale) .
Cotele de TVA folosite vor fi corespunzator marcate pe factura tiparita (la nivel de linie de factura sau la nivel de factura) .
Sistemul va asigura o scalabilitate si flexibilitate in manupularea informatiilor (atributelor) entitatii si va permite operatii de adaugare / modificare / stergere / clasificare / intervale de timp (prin calendare) / valabilitate . Din acest motiv sistemul va asigura un configurator propriu pentru toate categoriile de entitati enumerate .
Reprezinta rata de schimb pentru valuta sau valutele in care sunt introduse preturile din aplicatie . Zilnic, aceasta rata de schimb este actualizata pentru a corespunde cursului dictat de Banca Nationala a Romaniei . Trebuie sa existe si o lista de valute, dintre care una sa fie cea implicita, adica valuta curenta .
Atribute
Definit de:
valuta la care se raporteaza leul;
rata de schimb (o unitate monetara a valutei = cati lei);
data ratei de schimb;
etc .
Actualizarea cursului
Actualizarea cursului trebuie sa se faca fie automat, fie manual (dar numai de catre un utilizator de nivel superior ierarhic peste tot canalul Retail si /sau Corporate), ca solutie de rezerva in cazul in care nu este accesibila nici o metoda automata de actualizare . Accesul la aceasta optiune va fi drastic restrictionat .
Cursul trebuie sa pastreze si un istoric de evolutie de-a lungul timpului, se vor face doar adaugari .
Tipuri de curs valutar
Sistemul Retail va permite sa se poata introduce pe perioade de valabilitate diferite tipuri de curs:
La orice moment dat trebuie sa existe un singur tip de curs activ in Sistem .
Sistemul va asigura o scalabilitate si flexibilitate in manupularea informatiilor (atributelor) entitatii si va permite operatii de adaugare / modificare / stergere / clasificare / intervale de timp (prin calendare) / valabilitate . Din acest motiv sistemul va asigura un configurator propriu pentru toate categoriile de entitati enumerate .
SHAPE * MERGEFORMAT
Produs |
Discount |
Pret |