Acest cod trebuie sa identifice usor magazinul de colecta, numarul de PV din Sistemul Retail, tipul de PV .

Catre eService se va exporta si informatia legata de Client, din Vantive (MAJOR, STRATEGIC) .

Orange Service Center dispune de o lista de modele de telefoane pe care le repara (la nivel de cod de produs) si la nivel de brand . Aceste lista vor fi periodic importate (zilnic) in Sistemul Retail pentru a asigura o trimitere corecta a telefoanelor in service (repartizarea lor corecta – catre operatorul de service corect) .

Din eService se va importa si o lista de defecte recunoscute de aceasta aplicatie, defecte ce se vor folosi si cand un telefon este trimis catre un operator de service autorizat . Pe langa valorile importate din eService se vor putea adauga si defecte interne, recunoscute poate de operatorii service externi . Insa in cazul in care se face o trimitere de defecte catre Orange Service Centrer, defectul trebuie sa fie ales numai din lista pe care acesta o pune la dispoziite .

Din eService, dandu-se un PV si un magazin, sa se poata obtine starea acestui PV (trebuie in prealabil importate din eService lista de stari) . In cazul in care starea unui PV este una terminala, sa se poata vedea si suma de plata pe care clientul o are de achitat (daca exista) . In acest mod clientul poate fi informat din timp de eventualele cheltuieli pe care trebuie sa le suporte .

Starea unui PV din eService sa fie corelata si cu cea a PV-ului din Sistemul Retail (daca un telefon a plecat catre magazin, dar exista riscul retrimiterii sale in service e bine sa existe o stare de tipul “in lucru” care sa descrie aceasta parte a procesului – abia la receptia in magazin, dar fara retrimitere, sa fie schimbata starea in “telefon reparat”)

Importul de Produse colectabile (produse active) va fi efectual periodic sau la cerere, in momentul in care se efectueaza o receptie de defect . Fiecare produs va veni din eService cu cod, denumire si brand .

Sistemul Retail va avea acces la BlackList-ul din eService, in timp real .

Din eService vor putea fi importate si liste de accesorii colectabile, accesorii ale terminalelor vandute de Orange (aceste accesorii s-au vandut impreuna cu terminalul, la pachet, nu figureaza pe factura) .

Din eService vine si o lista de defecte, prin care se identifica starea unui produs defect colectat .

Sa se poata importa din eService si lista punctelor de colecta (ca sa fie informati clientii in legatura cu cel mai apropiat punct de colecta) .

Sistemul Retail va avea si acces la seriile de swap service . Aceste liste contin seriile inlocuite la service si permit indentificarea unui telefon cu care un client revine in service sau caruia i se face o stornare sau un schimb de defect .

Client management

Clasificare

Clientii retail pot fi de mai multe tipuri, functie de relatia lor cu Orange Romania:

clienti PostPay (existenti in Vantive si ePOS - initial);

clienti PrePay (existenti in Vantive, dar nu cu toate datele completate – unii nu au completat nici macar numele si adresa);

clienti non-Orange (care nu sunt abonati Orange, de regula cumpara accesorii, acesti clienti fiind intretinuti intern in Sistemul Retail);

Clientii PostPay pot fi introdusi numai din sistemul CRM (Vantive) si din sistemul EPOS . Orice modificare asupra lor in aceste doua sisteme trebuie sa fie vizibila, atat automat, la momentul facturarii, cat si la cerere (din Sistemul Retail un client poate vedea care este abonamentul sau curent si care ii sunt optiunile atasate) .

Clientii PrePay sau cei ce non-Orange nu au numar de contract, si sunt identificati numai dupa CNP si tipul de client (persoana fizica sau juridica) sau dupa Codul Fiscal . Acesti clienti nu au informatii de subscriber . Acesti clienti vor fi introdusi doar in Sistemul Retail .

Clientii PostPay sunt identificati de tipul de client si de numarul de contract cu Orange si au o lista de numere de telefon (subscriberii) .

Un client poate avea mai multe numere de telefon, caz in care poarta atasata o lista cu acestea (lista de subscriberi) .

Unicitate client

Unicitatea unui client este asigurata de tipul de client, CNP sau CodFiscal si Codul de contract (un client poate avea mai multe contracte cu Orange si fiecare contract poate avea mai multe numere de telefon - subscriberi) . Este permisa introducere unui client de doua ori cu acelasi CNP in conditiile in care este o data Persoana Fizica si apoi este introdus ca Persoana Fizica Autorizata (situatie intalnita mai ales in cazul cesiunilor) .

Clientii PrePay si cei non-Orange sunt pastrati numai in Sistemul Retail . In cazul in care acestia semneaza si un contract cu Orange, atunci vor fi importati din sistemul CRM-Vantive sau EPOS (cu tot cu numarul de contract) si vor fi diferentiati de ceilalti (PrePay si non-Orange) .

Fiecare client in Sistemul Retail are asociate informatii de abonament, plan tarifar, detalii de consum, pati efectuate, istoric de achizitii, schimburi de SIM, de produse, plangeri depuse, numar de clienti adusi in retea, cesiuni efectuate, servicii activate - toate la nivel de subscriber si altele . . Toate aceste informatii sunt actualizare din sistemul CRM (Vantive) in momentul unei noi achizitii sau la cerere .

Aceste informatii legate de client trebuie sa fie accesibile vanzatorului, intr-o interfata intuitiva si clara, care sa permita identificarea rapida a unor informatii ce ar putea ajuta vanzatorul la efectuarea unor eventuale sugestii de modificari ale abonamentului . In momentul unei vanzari aceste informatii sunt folosite pentru a identifica discounturile acordabile clientului, si vor determina in final pretul cu care produsele de pe factura vor fi vandute clientului .

Vizibilitatea clientilor intre magazine

Sistemul Retail trebuie sa permita vizibilitatea tuturor clientilor din orice magazin indiferent de punctul de vanzare in care acestia au fost creati prima data . Cu toate acestea, odata cu prima introducere a unui client in Sistemul Retail (prin import din sisteme externe sau manual) clientului i se va asocia o informatie legata de magazinul unde a fost creat initial . Aceasta informatie va putea fi folosita ca si criteriu de selectie de catre utilizatori in momentul in care se va face cautarea unui anume client (de exemplu un vanzator trebuie sa poata cauta un client doar printre clientii definiti la acel magazin, sau printre clientii definiti la oricare din magazinele din reteaua Orange) .

Fiecare client va putea fi accesat din orice magazin, dar va avea asociata o informatie de magazin de origine (un client nu va avea cate o instanta de fiecare data cand apare intr-un magazin, ci va fi unul singur in sistem, istoricul sau de Sistem Retail aratand pe unde i s-au efectuat tranzactiile) .

Securitatea

Autentificare si autorizare

Fiecare utilizator este obligat sa se autentifice inainte de a putea folosi Sistemul Retail .

Fiecare utilizator are asociat un nivel de acces la optiunile Sistemului Retail si, daca e cazul o gestiune, pe care numai el sau un utilizator desemnat, cu drepturi superioare poate sa o acceseze .

Autentificare prin amprenta digitala

Sistemul Retail va 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 .

Delegarea

Sistemul Retail va permite unui utilizator sa delege un alt utilizator sa actioneze in numele sau in aplicatie (de exemplu pentru cazurile in care utilizatorul este plecat in concediu) . Delegarea se va face pe o perioada sau pana la momentul cand utilizatorul delegator decide sa intrerupa delegarea . Un utilizator poate delega un grup sau o lista de utilizatori sa actioneze in numele sau .

Drepturile de acces

Un rol = nivel de acces = nivel de autoritate .

Un rol = Σ drepturi de acces (drept de acces la “zone” ale sistemului sau la functionalitati, o zona reprezentand una sau mai multe pagini grupate sub aceasi functionalitate) .

Sistemul Retail trebuie sa permita acordarea drepturilor de acces in functie de tipul operatiunii care se executa:

• vizualizare (acces read-only),
• adaugare,
• modificare,
• stergere,
• vizualizare sau
• orice combinatie dintre optiunile enumerate mai sus .

Drepturile de acces sa poata fi diferentiate si in functie de grupul din care face parte utilizatorul, locatia sa fizica, in cadrul unui departament sau in cadrul unui magazin Orange .

Separare informatii in functie de nivelul de autoritate

Sistemul Retail va trebui sa permita acordarea de drepturi de acces diferentiate fie doar asupra informatiilor proprii (de ex . vanzatorii sa aiba acces doar la facturile emise de ei) fie asupra informatiilor corespunzatoare tutuor utilizatorilor de la diverse niveluri (de exemplu seful de magazin sa aiba acces la toate facturile emise in magazinul sau) sau asupra tuturor utilizatorilor din sistem (de ex . utilizatori autorizati sa vizualizeze toate facturile emise in Sistemul Retail) .

Identificarea unica a documentelor

Orice exemplar de document tiparit ce contine informatii confidentiale din punctul de vedere al clientului va contine si un identificator unic . Aceste identificatoare vor fi generate de Sistemul Retail si vor permite identificarea unica a oricarui exemplar tiparit . Odata generate, aceste identificatoare sunt stocate in baza de date pentru verificari si comparari ulterioare .

Scopul acestui sistem este de a permite identificarea fara echivoc, avand la dispozitie o copie a oricarui document ce contine informatii confidentiale, a utilizatorului care a tiparit documentul respectiv precum si a momentului, locatiei de unde aceasta tiparire s-a facut, precum si a situatiei in care acel document nu este emis de catre Sistemul Retail (daca este un document fals) .

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 .

Logurile Sistemului vor contine informatii despre:

• utilizatorul care executa actiunea
• actiunea propriu zisa
• detalii (parametri, inregistrari modificate, etc)
• momentul actiunii
• masina (statia) de unde s-a facut modificarea
• identificator de sesiune (pentru cazul in care are mai multe sesiuni deschise de pe aceeasi masina)
• alte informatii relevante

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) .

Interactiuni relevante

Sistemul Retail va salva in tabelele de log toate actiunile relevante facute de utilizator printre care :

• vizualizare informatii confidentiale
• transfer intern;
• transfer extern;
• adaugare client
• modificare client;
• facturare;
• vanzare pe baza de bon;
• proforma;
• SAV;
• cesiune;
• retipariri diverese documente;
• modificare nomenclatoare (magazine, magazii, utilizatori);
• modificari preturi/produse/discouturi;
• importuri;
• modificare parola;
• login / logout;
• etc .

Vizualizare log-uri

Sistemul Retail va contine si o interfata de vizualizare si triere a informatiilor din loguri (dupa zi, ora, utilizator, actiune, prioritate, etc . ) .

Accesul la Log-uri il va avea numai un utilizator de nivel superior, acesta putand filtra datele in functie de nivelul sau de acees (de ex . un utilizator de pe canalul Retail nu va vizualiza decat log-urile de pe canalul sau) .

Gestiunea Documentelor

Facturile emise se tiparesc integrat de Sistemul Retail, cu serie unica pentru fiecare factura, tiparita initial in doua exemplare (fiecare cu aceeasi serie), dar putand fi retiparite oricand si in oricate formulare . Facturile trebuie sa respecte o ordine cronologica si trebuie sa asigure consecutivitate la nivel de zi (nu conteaza consecutivitatea la nivel de ora si minut) . Fiecare document fizic folosit in Sistemul Retail trebuie sa fie unic identificat in sistem (la fiecare tiparire i se va aloca o serie unica de identificare a formularului fizic – exista astfel o legatura intre momentul tiparirii si formularul fizic) .

Seriilor le va fi asigurata continuitatea la nivel de canal Retail . Continuitatea seriilor va fi asigurata la nivel de zi doar (pe un magazin seriile nu vor fi consecutive la nivel de zi, dar pe intregul canal Retail da) .

Sistemul Retail va trebui sa gestioneze aceste serii in asa fel incat sa se indeplineasca urmatoarele conditii:

• Factura tiparita are asociate intotdeauna 2 formulare pretiparite (cu 1 serie unica);
• Seriile pe care se tiparesc facturile trebuie sa fie garantat unice (nu poate exista o factura asociata mau multor serii sau o serie asociata mai multor facturi, distincte);
• Orice factura trebuie sa poata fi identificata unic dupa seria ce apare pe exemplarul fizic tiparit .

Documentele cu regim special, ce necesita inseriere, vor fi tratate aparte, in sensul ca vor avea parte de log-uri amanuntite si vor avea serii pastrate stocate in Sistemul Retail .

Documentele cu regim special vor fi tiparite in intregime de Sistemul Retail si unele documente (daca nu chiar toate) vor avea serii asignate de Sistemul Retail .

Documentele cu regim special sunt:

• facturile fiscale
• AIM-urile
• monetarele
• fisele de magazie
• fisele documentelor cu regim special

Aceste Documente vor fi intretinute de un mecanism dedicat, ce va asigna fiecarui document o serie unica de identificare .

Managementul documentelor cu regim special (prin fisa documentelor) poate fi asigurat in intregime de Sistemul Retail . Inclusiv monetarele pot fi generate si intretinute, conform cu legislatia in vigoare .

Toate documentele emise de Sistemul Retail vor salva in baza de date toate datele afisate pe ele la momentul respectiv (inclusiv eventualele date legate de vanzator, chiar si unele detalii ce nu se tiparesc dar care se pot schimba in baza de date), in asa fel incat se se poata reconstitui exact documentul in forma lui initiala .

Suportul pentru inventar

Sistemul Retail trebuie sa ofere suport la realizarea fizica a inventarului in magazine . Acest lucru presupune compararea stocurilor cu o lista a produselor existente fizic in magazin, pe care utilizatorii o completeaza manual la nivel de serie sau doar la nivel cantitativ .

Folosirea cititorului de coduri de bare

Introducerea listei de produse existente fizic in magazin se face de catre utilizatori prin scanarea produselor din stoc cu ajutorul cititorului de coduri de bare .

Comparatie stoc scriptic – stoc fizic

Sistemul Retail va permite compararea listei de produse scanate de catre utilizatorii din magazin (stocul fizic) cu lista produselor aflate in acel moment in stocul corespunzator magazinului respectiv (stocul scriptic) .

Aceasta comparatie se va face la nivel de serie (numar de inventar) pentru produsele care au numar de inventar, sau la nivel cantitativ pentru produsele din stoc care nu au numar de inventar (accesorii, produse promotionale, etc) .

Rapoarte de diferente

La finalizarea procesului de inventar, Sistemul Retail va furniza o serie de rapoarte prin care sa se evidentieze diferentele intre stocul scriptic si cel fizic identificat in urma inventarului . Aceste rapoarte vor identifica produsele gasite ca lipsa (inclusiv la nivel de serie) afisand in acelasi timp valoarea acestora declarata in Warehouse (pentru a oferi o valoare totala lipsa din gestiune), precum si eventuale produse gasite in plus in gestiunea fizica fata de stocul scriptic .

Informatiile rezultate din procesul de inventar trebuie sa fie accesibile utilizatorilor autorizati (manageri, departamentul financiar, etc) .

Rapoarte

Accesul la rapoarte este permis atat Shop Managerilor cat si userilor de nivel superior (acestia au acces deplin la rapoarte) sau userilor de nivel inferior (Stock Keeper sau Vanzator), insa acestia au drepturi de acces restranse, iar unele rapoarte le pot rula numai partial (se afiseaza numai datele ce fac referire la acesti utilizatori) .

Cele mai importante rapoarte sunt:

• cele de vanzari:
• jurnalul de vanzari;
• borderoul de incasari;
• lista de documente emise (seriile folosite);
• produse vandute (grupate pe handseturi, eVouchere, cartele, etc . );
• lista de oferte si discounturi folosite;
• dispozitii de plata;
• ordine de plata emise;
• plati cu carte de credit;
• vanzari fidelizare/ retention/ achizitie/ abonament;
• cele de transfer:
• transferuri in defecte;
• retururi de marfa;
• receptii de marfa;
• stocuri;
• PV-uri de SAV;
• cesiuni;
• raportul de produse destinate vanzarii – este un raport zilnic destinat informarii clientilor asupra preturilor produselor de la vanzare;
• rapoarte de ansamblu (analiza tendinte, evolutii, etc)
• etc .

Rapoarte de analiza informatiilor rezultate din procesele din magazin

Sistemul retail va trebui sa puna la dispozitie o multime de rapoarte ce analizeaza activitatea din magazine sub multiplele ei aspecte .

Aceste rapoarte vor include analiza unor tendinte, evolutii, etc si vor veni in sprijinul utilizatorilor de nivel inalt (manageri) pentru a-i ajuta sa optimizeze fluxurile din magazine si activitatea departamentului in general .

Raportul ca suport pentru feedback

Informatiile furnizate de rapoartele de ansamblu (de analiza a informatiilor) ale Sistemului Retail trebuie sa se constituie intr-un feedback util la reglarea si optimizarea activitatii in magazinele Orange .

Clasificare

Sistemul Retail va pune la dispozitia utilizatorilor autorizati mai multe tipuri de rapoarte printre care :

• rapoarte cantitative
• rapoarte de productivitate

Cateva exemple de rapoarte pe care Sistemul Retail le va pune la dispozitie sunt:

• rapoarte de vanzari
• la nivel de vanzator
• la nivel de magazin
• la nivel de regiune
• la nivel de retea
• la nivel de zi
• la nivel de luna
• la nivel de oferta
• altele
• rapoarte de gestiune
• la nivel de vanzator
• la nivel de magazin
• la nivel de regiune
• la nivel de retea
• la nivel de zi
• la nivel de luna
• la nivel de oferta
• altele
• etc .

Rapoartele ce vor fi disponibile in Sistemul Retail sunt descrise pe larg in Capitolul 9 .

Cautare factura dupa nr . Ordin de Plata / chitanta achitare cu Carte de Credit

Sistemul Retail trebuie sa permita utilizatorilor autorizati rularea unui raport de cautare de vanzari (factura sau bon fiscal) in functie de numarul ordinului de plata sau al chitantei de achitare cu carte de credit .

Utilizatorul va introduce numarul OP-ului respectiv al chitantei pt . achitare cu carte de credit, iar Sistemul Retail va identifica si afisa vanzarea (factura sau eventual bonul de casa, in cazul achitarii cu carte de credit) care a fost achitata cu acel OP sau chitanta carte de credit .

Nomenclatoare

Sistemul Retail va trebui sa permita intretinerea prin interfata a tuturor nomenclatoarelor (listelor dinamice) cu care se opereaza in aplicatie .

Printre nomenclatoarele folosite se includ utilizatorii si drepturile de acces, magazinele, listele de produse, tipurile de produse, magaziile, planurile tarifare, abonamentele, reducerile, motivele de retur, motivele pentru schimbul de SIM sau schimbul de defecte, tipurile de vanzare si asocierile de discounturi (folosite la export – mai multe discounturi sau servicii pot fi exportate sub acelasi nume), TVA, produsele promotionale . Aceste liste sunt intretinute fie prin import din OA, Vantive sau EPOS, fie sunt interne si sunt intretinute manual .

Import informatii din sisteme externe

Din OA sunt importate tipurile de produse, produsele, specificatii de produs (mai exact este vorba de un document in format . xls pe care Logistica poate sa-l puna la dispozitia Sistemului Retail fie incarcandu-l direct, fie in OA si apoi de acolo specificatiile sunt aduse in Sistemul Retail – aceste specificatii au un format de dscriere) si starile unei comenzi . .

Din Vantive sunt importate unele discounturi (cele ce tin de Vantive), planurile tarifare, optiunile .

Din EPOS sunt importate motivele de schimb de SIM .

Din eService se importa lista de defecte constatate, lista de brand-uri preluabile in service si lista de coduri de produs ce pot fi reparate .

Listele de tipuri de vanzari sunt intretinute manual, nu prin import, la fel ca si motivele de retur, magaziile, motivele pentru schimbul de defecte, tipurile de vanzare, asocierile de discounturi, lista de TVA-uri, produsele promotionale, magazinele, utilizatorii, drepturile de acces si altele .

Tiparirea ofertelor zilnice

In fiecare zi, in fiecare magazin se tipareste oferta zilnica – un set de documente destinate clientilor, ce contin o lista de terminale disponibile in magazin spre vanzare si preturilor acestora in diverse oferte (pret informativ, pentru ca se mai pot aplica discounturi suplimentare) – cum ar fi fidelizare, la liber, cu abonament sau grupate dupa tipul ofertei: oferta de abonament clasic, oferta de abonament de date, oferta de abonament 3G, etc . . Documentul tiparit trebuie sa contina in clar si data la care a fost tiparit, cursul de referinta leu-dolar (sau leu - valuta de referinta), si magazinul in care s-a tiparit .

Exista un singur utilizator autorizat care poate sa selecteze ce telefoane nu apar in aceasta lista si care este numarul minim pe stoc in care trebuie sa fie un produs pentru a aparea in lista . Vanzatorii si ceilalti utilizatori de nivel inferior nu pot decat sa vizualizeze si sa tipareasca aceasta oferta . Totusi, utilizatorul de nivel Shop Manager poate sa acorde drept de modificare oferta zilnica si unor vanzatori .

Oferta zilnica este compusa din doua clase de rapoarte: cea de terminale, cu diferentierea de pret, si cea de accesorii, ce contine un singur pret: cel de achizitie la liber (oferta de accesorii poate deci sa nu apara in formatul de date, 3G sau abonament clasic) .

Cautarea seriilor

Trebuie sa existe in Sistemul Retail si un mecanism de cautare al seriilor in :

• vanzari;
• tranzactii (interne sau externe, la alegere);
• SAV-uri;
• stoc;
• etc .

Utilizatorul va alege modul de cautare (unde vrea sa caute seria) si Sistemul va afisa la final un raport cu inregistrarile ce corespund criteriilor de cautare .

In cazul vanzarilor vor fi incluse informatii legate de data, referinta interna, clientul de pe factura, date legate de vanzator si vor fi afisate toate vanzarile in care apare acea serie (fie facturi, fie bonuri de casa) de-a lungul timpului, chiar daca este vorba de o vanzare normala, stornare sau anulare .

In cazul tranzactiilor vor fi afisate: data tranzactiei, magazia de intrare, magazia de iesire (sau destinatarul/expeditorul in cazul unei tranzactii externe) si de asemenea va include si toate tranzactiile efecturate pe aceasta serie, indiferent de data .

In cazul SAV-urilor trebuiesc afisare PV(urile) pe care apare, clientul, data receptiei, starea actuala a PV-ului si vanzatorul care a facut receptia, cel ce a trimis in service si cel ce a facut receptia (daca informatiile sunt disponibile) .

Informatii preturi

Sistemul Retail va avea disponibil si un modul de informare legat de preturile tuturor produselor definite si eventualele discounturi disponibile . Este un modul accesibil tuturor utilizatorilor si face posibile comparatiii intre produse si calcule de puncte ThankYou necesare acoperirii unui produs . Informatiile se refera atat la produse de tip handset cat si la produse PrePay (in module diferite) .

In cazul produselor PrePay se pot alege simultan mai multe linii, pentru comparare, si se pot aplica pretului de pornire discounturi sau puncte ThankYou .

In cazul handset-urilor, in functie de brand, vor fi afisare listele cu produse (putand sa avem pe mai multe linii acelasi brand, pentru o comparatie intre modele ale aceluiasi producator) . In functie de oferta aleasa se pot face calcule legate de preturi (prin aplicarea de puncte ThankYou sau prin aplicarea unor discounturi din lista de discounturi disponibile aplicabile acelui produs – nu sunt afisate cele aplicabile clientilor sau cele aplicabile in functie de factura) .

Sistemul de Rezervare

Sistemul de rezervare va permite blocarea accesului la un anumit produs sau la anumite cantitati dintr-un tip de produs . Este un mecanism ce va fi folosit explicit de catre utilizatorii autorizati sau indirect, prin interfatare cu diferite module ale Sistemului Retail (proforma, HelpLineSystem, transfer inter-magazine, etc) .

Prin urmare, rezervarile pot fi:

• Rezervarile facute de catre InfoShops
• Rezervarile facute de shop manager (locala, in cadrul aceluiasi magazin)
• Rezervari speciale (stoc rezervat unor anumite operatiuni) – locale

Rezervarile facute de InfoShops nu sunt la nivel de serie, ci la nivel cantitativ . In modulul de vizualizare stocuri disponibile in magazinele din tara (InfoShops), utilizatorii pot selecta un numar de telefoane rezervate, impreuna cu detalii de rezervare . Shop Managerul (sau delegatul acestuia) preia comanda si alege de pe stocul magazinului seriile telefoanelor rezervate, serii ce sunt mutate in magazia de rezervari, iar procesul de rezervare initiat de InfoShops este incheiat .

Procesul de rezervare InfoShops :

• Initiere (sunt alese produsele si cantitatile impreuna cu detaliile de rezervare);
• Pending (se asteapta selectarea unei serii din magazinul in care s-a facut rezervarea);
• Approved (in magazin s-a selectat o serie) .

Detaliile de rezervare:

• Motivul rezervarii – va fi disponibila o lista de motive frecvente de rezervare, dar si un motiv de tip “Others”, insotit de un text introdus de utilizator in cazul unei rezervari atipice;
• Data limita a rezervarii;
• Clientul (optional) – daca nu exista in sistem (daca nu e client Orange si nu a mai fost introdus in sistem cu o alta ocazie), se va introduce numele;
• Magazinul in care clientul vine sa-si cumpere telefonul ;
• Proforma in baza careia clientul va efectua plata (daca e cazul) .

La vanzare, penrtu clientul selectat, se vor afisa si eventualele rezervari pe care acesta le-a facut . Seriile rezervate vor fi cele trecute pe factura .

Va exista si un editor de rezervari pentru cazul in care rezervarea se face chiar din magazin . . Prin intermediul acestui mecanism de editare, rezervarile existente vor putea fi vizualizate, modificate sau anulate . Pentru anularea unei rezervari sunt necesare drepturi speciale .

In cazul in care o data limita de rezervare (sau mai multe) a fost atinsa, shop managerul este informat de Sistemul Retail si i se ofera posibilitatea:

• sa mute inapoi in magazia magazinului telefonul (telefoanele) rezervat, sau
• sa pelungeasca rezervarea .

In pagina principala a aplicatiei va aparea o nota informativa referitoare la existenta unor telefoane carora le-a expirat rezervarea . Click pe nota si vor fi afisate detaliile rezervarilor in cauza .

Rezervarea poate fi facuta de InfoShops intr-un magazin pentru un telefon din alt magazin . In acest caz, telefonul rezervat, in starea Approved, este pus pe bursa inter-shop-uri pentru a fi preluat de magazinul destinatar . Telefonul este marcat ca fiind exclusiv destinat magazinului destinatar (indisponibil pentru toate celelalte magazine) .

Info Shop

Modulul acesta este accesibil celor ce lucreaza in departamentul de TeleSales, si permite vizulizarea instantanee a stocului fiecarui magazin, listarea ofertei zilnice din acel magazin, vizualizarea vanzarilot pe ultimele 90 de zile pe acel produs (cantitiativ) si vizualizarea informativa a unui pret final .

InfoShop va avea acces la o interfata de vizualizare stocuri si rezervare produse, similara cu cea existenta in prezent (gen Help Line) .

Cautarea se face la nivel de produs, fie prin introducerea denumirii, fie a codului OA de produs si Sistemul Retail va afisa apoi stocurile pentru acel produs la toate magazinele .

Se pot rula si rapoarte de produse disponibile pe stoc, cu limita minima introdusa la rularea raportului, fie pe toate magazinele, fie pe unul singur .

Permite vizualizarea preturilor de baza ale produselor si discounturile aplicabile (nu si cele ce tin cont de client, sau cele ce tin de factura), si aplicarea unor puncte ThankYou la aceste preturi sau calculul de puncte ThankYou necesare achizitionarii produsului numai cu puncte .

Queue Management

Sistemul Retail va trebui sa contina functionalitati specifice de Queue Management .

Tinand cont de fluxul mare de clienti in magazine, este necesara implementarea unui sistem de monitorizare a clientilor si a servirii acestora .

Receptia preia clienti, adaugand intr-o lista operatiunile pe care acestia doresc sa le efectueze (se va prelua de la client numele si eventual numarul de telefon) . Apoi aceeasi lista este folosita in cazul in care un client ajunge la o masa (la un vanzator) pentru a fi marcat ca preluat, si tot in aceasta lista este marcata incheierea cu succes sau nu a operatiunilor dorite de client . La finalul zilei clientii adaugati in lista si neactualizati (au plecat inainte de a fi abordati de un vanzator sau s-a uitat marcarea lor) sunt marcati sa nerezolvati si nu mai pot fi accesati din lista .

Urmarirea clientilor de la intrarea in magazin pana la printarea facturii

Sistemul Retail va trebui sa inregistreze si sa analizeze informatii referitoare la prezenta clientilor in magazin, separarea acestora in functie de scopul vizitei in magazin, urmarirea rezolvarii cererii acestora de la intrarea in magazin si pana la finalizarea operatiunii pentru care acestia au venit . Se va urmari si o prioritizare a proceselor Business ce au loc in magazine .

Analiza informatiilor rezultate si statistici

Pe baza informatiilor zilnice se vor alcatui predictii si statistici referitoare la timpul mediu de asteptare pentru rezolvarea diferitelor probleme, cat timp sta un client la masa, numarul de clienti ce sosesc pentru rezolvarea diverselor probleme, etc . In functie de aceste statistici activitatea din magazin va putea fi optimizata pentru asigurarea unui flux imbunatatit . Datele comparative vor tine cont de anumite constante stabilite de aplicatie, referitoare la timpul de servire si de asteptare pentru diferite doleante ale clientilor .

Operare in sistem de pe PDA

Sistemul Retail va permite accesarea unora dintre functiile acestuia de pe device-uri mobile de gen PDA .

Scop

Scopul principal al accesului de pe PDA la unele din functionalitatile Sistemului Retail este de a elimina limitarea volumului de clienti ce pot fi serviti simultan de numarul de statii disponibile in magazin (posturi fixe), limitare care exista in prezent in toate magazinele Orange . Un alt avantaj al acestei facilitati este ca permite o apropiere mai mare intre client si vanzator, o flexibilitate mai mare legata de modul in care se desfasoara relatia vanzator-client .

Cu ajutorul acestui sistem, un vanzator va putea insoti clientul la vitrina cu produse, va putea sa demonstreze acestuia diversele optiuni si facilitati ale produsului, si in acelasi timp in sa completeze factura pentru acesta, astfel eficientizand procesul de vanzare si eliminand necesitatea repetarii alegerilor facute de catre client la momentul completarii facturii .

Operare direct de pe PDA

Sistemul Retail va permite efectuarea de catre vanzatori a urmatoarelor operatiuni direct de pe PDA:

• selectie client
• afisare informatii client
• vizualizare stocuri
• afisare informatii produse
• selectie produse
• compunere factura
• alte operatii

Tiparirea de documente

Dupa completarea facturii direct pe PDA, pentru procesul de tiparire al facturii pe formularele pretiparite cu serii, utilizatorul se va putea conecta la o statie de lucru fixa pentru a-si transfera informatiile generate anterior pe PDA . Aceasta solutie se va adopta in cazul in care procesul de tiparire nu va putea fi comandat direct de pe device-ul mobil .

Continuarea procesului la statia de lucru fixa

In cazul in care procesul de vanzare presupune totusi finalizarea acestuia de pe o statie fixa (de exemplu in cazul in care vanzatorul ar trebui sa acceseze si alte aplicatii pentru a incheia procesul de vanzare), Sistemul Retail va permite accesarea datelor introduse pe PDA de pe statia de lucru pentru a putea continua procesul de acolo . Cu alte cuvinte, vanzatorul ar putea realiza o parte din procesul de vanzare de pe PDA, pentru ca apoi, doar pentru faza finala sa se aseze la statia de lucru si sa finalizeze vanzarea .

Uniformitatea datelor in Sistemul Retail

Toate datele introduse de pe PDA vor trebui sa se regaseasca in Sistemul Retail, intr-un format identic cu datele introduse de la o statie de lucru fixa, prin intermediul interfetei standard a sistemului, pentru a fi accesibile in rapoarte, analize, etc .

Inregistrarea platilor

Sistemul Retail va trebui sa permita inregistrarea platilor pentru facturile achitate cu Ordin de Plata sau Carte de Credit .

Inregistrarea platilor se face in functie de numarul Ordinului de Plata sau al chitantei de achitare cu Carte de Credit . Dat fiind acest numar, Sistemul Retail trebuie sa fie capabil de a identifica rapid vanzarea pentru care se va inregistra plata .

Va exista si un raport special , de prezentare a facturilor achitate cu OP sau CC .

Inchiderea unei facturi

O factura se va considera deschisa pana in momentul in care suma achitata va fi egala cu suma totala datorata pe factura .

Facturile achitate cu cash se presupun achitate (inchise), si vor apare in aceasta stare in rapoartele referitoare la plati (daca utilizatorul alege includerea acestora in rapoarte) .

La inchiderea unei zile (operatiune indeplinita de orice vanzator, numita “Inchidere de Zi”) facturile neinchise ii sunt aduse in prim-plan si nu i se permite sa-si emita borderoul pana ce nu se inchid respectivele facturi sau sunt anulate . O factura neinchisa nu poate ramane mai mult de o zi in aceasta stare .

Export informatii de plata in Oracle Applications

Informatiile legate de plata facturilor trebuie exportata in Oracle Applications (numai platile cash) .

Operatiuni

Accesarea Sistemului Retail

Accesul la Sistemul Retail este permis numai utilizatorilor inregistrati, autentificati in baza unei amprente digitale (vezi cap . Securitate – Autentificare si Autorizare) .

Utilizatorului ii sunt asociate in urma autentificarii o regiune, un magazin si o magazie (magazia numai daca este cazul, mai ales pentru utiliztatorii pe nivel de vanzator) . Orice vanzare va face sau orice operatie pe stoc va trebui sa implice si aceasta magazie .

In cazul in care un utilizator a delegat un inlocuitor, la autentificarea acestuia i se va cere sa specifice identitatea sub care doreste sa opereze .

Exista useri care pot accesa mai multe magazine simultan, caz in care acestora trebuie sa li se permita sa acceseze individual un anume magazin (sa li se afiseze o lista de magazine de unde sa selecteze magzinul pe care vor sa-l acceseze), sau multimea de magazine ce compun reteaua Orange Romania SA .

Fiecare autentificare (reusita sau nu) si fiecare de-conectare va fi pastrata in log-uri .

Tranzactii

Operarea tranzactiilor este permisa numai unei clase de utilizatori ce se ocupa cu transferurile intre gestiuni (StockKeeper de ex . ) . Tranzactiile pot fi interne (intre gestiunile interne magazinului) sau externe (cu alte magazine, cu WAREHOUSE-ul, cu un operator service, etc) .

In urma fiecarei tranzactii se va tipari un document care sa demonstreze efectuarea acesteia . In acest sens trebuie sa existe si posibilitatea vizualizarii tranzactiilor si retiparirea documentelor atestatoare (Note de Retur, Avize de Insotire Marfa, Fise de Transfer intre Gestiuni, etc . ) .

Va exista si un utilizator autorizat care sa poata anula tranzactii, in cazul in care sunt introduse gresit in sistem, sau sa le poata modifica (cazul in care este introdusa gresit seria unui AIM, in cazul in care pe AIM s-au trecut prea multe produse si nu mai pot fi tiparite pe un singur AIM, in cazul in care telefoanele defecte au fost trimise la un alt service, etc . ) .

Sistemul Retail va exporta catre OA tranzactiile ce afecteaza gestiunea totala a unui magazin, precum si cele ce presupun schimbarea seriilor IMEI (schimburi si corectii de serii) . Acest export se va efectua la nivel de tranzactie individuala (fiecare vanzare de pe un magazin va genera un export catre OA, nu va mai exista un export de tranzactii la nivel de zi) .

Un transfer intre doua magazine va produce efecte in mod automat in gestiunea OA (prin intermediul unui export ‘live’, asemanator celui de tranzactii de vanzare) .

Va exista si posibilitatea operarii unei tranzactii de corectie la nivel de serie IMEI, ramanand de stabilit daca va fi si exportata catre sistemul OA (in aceasi situatie se afla si schimbul de defect – se va exporta sau nu?) sau doar va genera un raport de schimburi de IMEI care va fi trimis catre departamentul Logistica .

Exportul de SAV-SWAP se va face la nivel de serie IMEI .

Va exista o verificare automata de serii IMEI si cantitati intre OA si Sistemul Retail, rulata periodic (ex . : la inceput la cate o saptamana) . Rezultatul acestei verificari este trimis pe mail persoanelor interesate si este accesibil si din Sistemul Retail , sub forma unui raport, accesibil anumitor utilizatori de nivel superior .

Inainte de lansarea exportului operatiunilor catre OA si a verificarilor de stoc Sistem Retail – OA trebuie ca stocurile celor doua sisteme sa concorde, pana la nivel de serie IMEI .

Transferul de produse intre magazine va fi operat in doua tranzactii:

• trimitere din magazin
• receptie in magazinul destinatie

Aceasta tranzactie pe stoc se va efectua prin intermediul unei magazii de tranzit (avand un corespondent in OA – un subinventar de transfer) .

In cazul in care transferul intre magazine este exportat in doua tranzactii, va exista si o magazie de rezervari speciale, pentru acest tip de transferuri, in care produsele sunt postate pana in momentul in care se va face receptia in magazinul destinatie .

In Sistemul Retail va exista si un raport care permite, la nivel de AIM, sa se verifice folosirea stocului asociat acestuia (care AIM a fost folosit in intregime si pe care au mai ramas produse netranzactionate) .

Tranzactiile de retur de marfa pot fi:

• pentru telefoane defecte
• in urma unui transfer direct in defecte (DOA)
• in urma unui schimb de defect (Damaged)
• in urma unei stornari (Damaged)
• pentru telefoane Obsoletes (nu se mai comercializeaza, retrase de la vanzare)
• pentru telefoane uzate (de ex . cele din magazia Touch&Try)

Aceste tranzactii de retur nu pot fi importate in OA fara aprobare, prin urmare, un mail este generat catre persoanele apte sa ia aceasta decizie, si, daca acestea au acces in Sistemul Retail, pot sa aprobe transferurile . Un transfer aprobat poate fi apoi exporat catre OA . Altfel, in OA, returile se vor opera manual .

Atasata oricarui retur de produse, va exista si o “fisa de constatare” in care sa fie completate:

• motivul returului
• defectul constatat (daca exista)
• factura de achizitie (daca exista)
• data facturarii (daca exista)
• orice alte campuri necesare

Fisa de constatare este completata in momentul in care un produs intra in magazia de defecte (inclusiv la un schimb de defect) . Fisa de constatare va avea campuri bine definite, pentru a asigura o metoda unitara de completare, la momentul introducerii in magazia de defecte .

Tranzactii interne

Tranzactiile interne sunt la nivel de magazin, si prin urmare pot afecta numai gestiunea unui anume magazin (ales de utilizator in prealabil sau dedus din tipul utilizatorului pentru acei utilizatori care nu au acces la mai multe magazine) . Interfata trebuie sa permita alegerea unui produs (eventual si a unei cantitati – pentru produsele fara serie), si a partilor implicate in transfer: magazia sursa si magazia destinatie .

Pentru alegerea unui produs se va folosi fie o listare a tuturor produselor dintr-o magazie, fie posibilitatea cautarii unui produs dupa cod OA, dupa denumire, dupa tip sau dupa serie . Seria este citita cu un cititor de coduri de bare .

Tranzactiile pot fi

• manuale - cele introduse de un utilizator autorizat (de exemplu transferul dintr-o magazie in alta), sau
• automate -generate de Sistemul Retail (de exemplu transferul automat al unui telefon de SWAP din magazie de SAV – Stoc de schimb in magazia SAV - Imprumutate) .

Fiecare tranzactie interna finalizata este salvata, impreuna cu un log al actiunii . Fiecarei tranzactii interne manuale finalizate i se va tipari un formular de transfer intre gestiuni (Fisa de transfer intre gestiuni) .

Orice tranzactie este efectuata e un utilizator cu rol de Stock Keeper .

In cazul in care un al doilea utilizator doreste sa se autentifice drept Stock Keeper, sa i se refuze conectarea pe motiv de sesiune deja deschisa .

Prin tranzactii interne nu pot fi accesate manual magaziile de SAV (SAV defecte, SAV service, SAV reparate, SAV – telefoane de schimb sau SAV – telefoane imprumutate) .

Tranzactii externe

Retururi de marfa

Retururile de marfa sunt transferuri din gestiunea proprie magazinului (dar nu de pe gestiunile vanzatorilor, vitrina sau magaziile de SAV) catre WAREHOUSE (din magazia magazinului, din magazia de accesorii, sau din magazia de defecte), catre un operator de service (din magazia de defecte), catre un alt magazin (din magazia de defecte sau de accesorii) .

In urma unui retur de marfa, produsul dispare din gestiunea magazinului sursa, chiar daca tranzactia este cu un operator service (nu este cazul operatiilor SAV) .

Returul de marfa este insotit de Fisa de retur de marfa si de Avizul de insotire a marfii .

Retururi de marfa sunt:

• Retururi de defecte;
• Retururi cerute de WAREHOUSE;
• Retururi de produse Obsolete .

Orice retur catre WAREHOUSE se face in urma aprobarii din partea departamentului Logistica si in urma receptiei unei dispozitii de retur .

In momentul returului de marfa SIstemul Retail va tipari un AIM de retur de marfa . Pe acest AIM vor figura si datele transportatorului (compania de curierat – inclusiv curieratul intern, camp obligatoriu, si optional datele curierului ca persoana fizica), precum si informatiile legate de valoarea de asigurare .

Transferul cu/din gestiunea clientului

Acest tip de transfer afecteaza gestiunea magazinului (atat magazia magazinului cat si magaziile vanzatorilor) si reprezinta mutarea produsului selectat pe/de pe gestiunea clientului .

Utilizatorul trebuie sa aleaga clientul din/catre gestiunea caruia se face transferul, motivul pentru care se opereaza aceasta tranzactie si numarul AIM-ului corespunzator (in cazul unui transfer in gestiunea clientului, la retur se tipareste doar PV-ul de retur din gestiune) .

In urma acestui transfer se tipareste un Proces Verbal de Transfer in/din custodie, eventual un AIM (numai pentru transfer in custodia clientului) si eventual un contract de comodat (in cazul unor produse precum modemurile Navini) .

Receptia de marfa

Reprezinta introducerea pe stoc a produselor primite de la diverse magazine sau de la WAREHOUSE, in baza unui AIM . Utilizatorul autorizat cauta in sistem numarul avizului corespunzator, dupa care se introduc in mod automat pe stoc produsele (in magazia magazinului) .

La fiecare import de marfa din WAREHOUSE, produsele au un pret de cost asociat . Valoarea pretului de cost este la nivel de produs, si nu la nivel de serie IMEI .

Facandu-se o medie ponderata in functie de cantitatea dintr-un anumit produs receptionata si valorile preturilor de cost asociate acestui produs, se poate stabili o valoare de asigurare . Valoarea de asigurare poate fi si ultima valoare (de pe cel mai recent AIM) . Aceste doua metode de calcul sunt la alegere .

Valoarea de asigurare va fi tiparita in clar pe:

• avizele de retur
• avizele de trimitere in service
• avizele de transfer intre magazine

Receptia manuala

Daca sunt probleme la citirea acestui AIM sau din alte cauze nu se poate face importul automat (de exemplu lipsa unei conexiuni la sistemul sursa), utilizatorul autorizat poate face o receptie de marfa in baza unei Note Interne de Receptie (receptie manuala) .

In cazul unei receptii manuale, trebuie specificate:

• codul produsului sau denumirea;
• seria (daca este cazul);
• cantitatea (este 1 implicit in cazul produselor cu serie);
• sursa transferului (WAREHOUSE sau magazin);
• numarul AIM-ului (marfa trebuie sa fie insotita de un Aviz, fie manual fie generat automat de sistem);
• data AIM-ului;
• etc .

Tranzactii cu operatorul service

Sunt operate automat de sistem in urma operatiei de trimitere a defectelor SAV in service sau in urma receptiei din service a telefoanelor reparate .

Trimiterea telefoanelor in service se face prin selectarea telefoanele de pe PV-urile care se doresc sa fie atribuite unui operator service (selectat la randul sau de utilizator) . Fiecare tranzactie service va referentia un singur operator service . Dupa ce utilizatorul a selectat telefoanele defecte, mai trebuie completate datele de transfer (detaliile de AIM – numar, data, expeditorul, reprezentantul firmei de curierat, etc . ) .

In urma tranzactiei cu operatorul service telefoanele nu sunt destocate ci sunt mutate in magazia de SAV service .

Receptia telefoanelor din service se face individual, schimbandu-se starea PV-ului din ‘service’ in ‘reparat’ . Transferul de gestiune, din SAV service in SAV reparate se face automat, la fel si inregistrarea transferului . Utilizatorul doar face marcarea telefoanelor intoarse din service .

Vanzare

Incasare

Incasarea insumeaza pasii necesari emiterii unei facturi sau bon de casa . In urma unei incasari apar inregistrari in borderoul de incasari sau in jurnalul de vanzari (depinde de tip: cash sau prin banca) .

O factura poate fi achitata prin:

- carte de credit

- OP

- cash

- etc .

Se va prevedea posibilitatea ca o factura sa fie achitata prin toate aceste metode, dar si prin mai multe de acelasi tip (de exemplu sa fie achitata o factura prin 3 ordine de plata)

Factura

Pentru emiterea unei facturi este necesara autentificarea unui vanzator . Acest vanzator trebuie sa aiba pe gestiunea sa toate produsele pe care doreste sa le vanda (cu alte cuvinte, inainte de a vinde un produs acesta trebuie mai intai transferat in gestiunea vanzatorului) .

Primul pas este selectia clientului, adaugarea sa manuala in baza de date (daca nu exista in nici un sistem) sau importul sau din sistemele externe (EPOS, CRM-Vantive) .

Selectia clientului se face:

• din Vantive (pentru un contract vechi, dupa MSISDN)
• din ePOS (pentru un contract nou, dupa numarul de contract al subscriberului)
• manual (daca e un client PrePay – si necesita detalii introduse de mana,- chair daca e importat din Vantive –l sau daca e client ce achizitioneaza doar accesorii)

Sunt selectate apoi produsele, permitandu-se cautarea dupa serie (daca este cazul) cu cititorul de coduri de bare si cantitatile (in cazul in care produsul este fara serie) . Pentru fiecare produs, in functie de clientul ales, sistemul pune la dispozitia vanzatorul o lista cu preturi sau selecteaza implicit pretul in cazul in care exista numai unul . Apoi utilizatorul este interogat in legatura cu discounturile pe care doreste sa le aplice produsului, discounturi acordate in functie de clientul ales, de produs si de pretul de baza al acestuia . Implicit sunt acordate toate discounturile disponibile, utilizatorul putand sa mai elimine din acestea, sau sa opteze intre discounturi, in cazul in care unele dicounturi fac parte din categorii disjuncte . Selectia discounturilor disponibile este facuta automat de catre sistem, interventia vanzatorului aparand numai pentru a mai elimina din discounturi sau pentru a selecta unul din discounturile discjuncte (daca este cazul) .

Pe un produs pot fi acordate mai multe discounturi, cu conditia ca acestea, insumate, sa nu depaseasca pretul produsului

Pe o factura pot fi acordate mai multe discounturi globale, cu conditia ca acestea, insumate, sa nu depaseasca valoarea produselor de pe factura (cu tot cu discounturile acordate acestora)

In cazul vanzarii cu fidelizare pentru un client care are mai multi subscriberi, la adaugarea unei noi linii de fidelizare, se va selecta implicit numarul de telefon ales la selectia clientului . Daca pe acest numar de telefon nu se mai poate efectua nicio fidelizare (fie deja in vanzarea curenta s-a mai efectuat o fidelizare pe acest numar, fie pe acest numar nu se mai pot efectua noi fidelizari), se poate alege un alt numar de telefon din lista de subscriberi ai clientului .

Sistemul va afisa o lista de subscriberi, in grupuri de cate X . Pentru fiecare subscriber din cei X afisati, aplicatia va atentiona vanzatorul printr-un semn grafic daca si cand subscriber-ul respectiv poate fi fidelizat . Astfel daca data la care subscriberul poate face o noua fidelizare este:

• Mai mica decat data curenta si se poate face fidelizarea, aplicatia va marca acest lucru in lista subscriptia ( ex . Customerul va fi marcat cu verde)
• Mai mare decat data curenta, dar la un interval de timp mai mic de o valoare prestabilita atunci se afiseaza data urmatoarei fidelizari posibile si se avertizeaza ca este posibila o fortare a fidelizarii (marcat de ex . cu galben)
• Mai mare decat data curenta, dar la un interval de timp mai mare decat o valoare prestabilita atunci se afiseaza data urmatoarei fidelizari si se avertizeaza ca nu se poate efectua nici o fidelizare

Nota: Se poate schimbat subscriberul pe care se efectueaza fidelizarea, in cazul fiecarei linii de vanzare in cazul in care clientul se razgandeste si vrea sa faca fidelizarea pe alt subscriber .

Tot in cadrul procesului de facturare, vanzatorul este informat de situatia curenta a clientului, dandu-i posibilitatea de a face sugestii referitoare la cele mai bune achizitii pe care le poate face clientul sau modificarea optiunilor sau abonamentului ca sa corespunda mai bine necesitatilor sale sau produselor cumparate (de exemplu, daca nu are optiunea GPRS activata, dar cumpara un telefon cu GPRS, sa-i poata activa clientului aceasta optiune sau sa-l informeze despre modalitatile de activare a acestei optiuni) .

La fiecare noua linie de vanzare se va alege operatiunea cu care se doreste sa se finalizeze vanzarea . Se va retine ultima folosire a operatiunii si la fiecare adaugare de linie se pot folosi detaliile liniei precedente

Dupa ce au fost selectate toate produsele de pe factura, pot fi aplicate si discounturile globale (cate un tip de discount globa per factura) . Discounturile fixe sunt selectabile dintr-o lista iar reducerea ThankYou putand fi importata din Vantive sau introdusa manual .

Factura va putea sa fie listata pe mai multe pagini, fiecare avand aceeasi serie, dar peginile fiind numerotate, marcandu-se clar pagina curenta si numarul total de pagini . In acest caz chitanta si totalul va fi afisat pe ultima pagina .

Sistemul Retail va prevede si un sistem de acordare de drepturi pentru ca un utilizator dintr-un magazin sa se poata conecta ca utilizator al altui magazin si sa poata emite facturi in acest mod (pentru situatia de urgenta in care intr-un magazin nu se poate factura si este necesara o facturare) . Un utilizator de nivel superior va putea acorda astfel de drepturi . Utilizatorul ce se conecteaza astfel la alt magazin emite factura si apoi aceasta trebuie trimisa pe fax sau curier la magazinul in care a efectuat vanzarea (aceasta solutie este creata strict pentru cazurile in care un magazin nu poate factura – de ex . din cauza unei pene de curent) . Acest utilizator se conecteaza ca si cum s-ar afla in magazinul in care exista problema de conectica (va avea acces la stoc, serii facturi, etc – e ca si cum ar fi fizic prezent in celalalt magazin) .

Va exista si posibilitatea de a retipari factura salvata si de a vizualiza toate vanzarile functie de anumite criterii (data, perioada, client . , vanzator, serie factura, etc . ) .

Se vor salva si informatiile legate de vanzare, in log-uri, inclusiv informatiile legate de exemplarul de factura tiparit (fiecare exemplar de factura tiparit trebuie sa fie unic identificabil) .

Pot fi emise si facturi in baza unui bon de casa, dar numai cu conditia ca bonul sa fie emis in aceeasi zi ca si factura . Datele de vanzare de pe bon nu mai pot fi modificate, nu se permit nici adaugari, nici stergeri, nici modificari ale vanzarii pe baza de bon . Singurul lucrul cerut de sistem va fi numele clientului care va aparea pe factura si seriile facturii . In borderoul de vanzari incasarea aceasta va aparea la facturi si nu la bonuri si trebuie evidentiata (la sfarsit de zi, bonul Z – sau stergerea zilnica - a casei de marcat va include si acest bon in baza caruia s-a facut factura) . Va exista si un raport care sa cuprinda aceste facturi emise

Un sistem de Generare Template-uri va asigura posibilitatea schitarii facturilor uzuale . Aceste schite de facturi vor cuprinde:

• tipul de vanzare (abonament, fidelizare, etc);
• subtipul (12/24 luni);
• tipul de plan tarifar (Date, Voce, etc);
• produsul (produsele);
• alte informatii generale .

Template-urile micsoreaza timpul de realizare a unei vanzari uzuale (de . ex o vanzare a unui produs la o oferta speciala – un accesoriu ce se vinde cu discount impreuna cu un anumit produs) nefiind necesara decat selectia clientului, a seriilor produselor (daca este cazul) – selectie intr-o fereastra separata, si eventual a altor detalii legate numai de pretul final al produsului vandut sau de factura(se mai alege un discount suplimentar, un discount global, se mai adauga un produs la factura, etc) .

Un Template va verifica si faptul ca elementele sale sunt valabile pentru clientul curent (verificare la crearea unei facturi in baza unui Template, dupa alegerea clientului) .

Un Draft se realizeaza printr-o vanzare ramasa neinchisa (nu s-a tiparit inca factura, nu are inca serii asociate) .

Draft-urile ramase neinchise la momentul in care se face “Inchiderea de Zi” sunt afisate utilizatorului . Daca utilizatorul vrea, poate sa nu termine “Inchiderea de Zi” si sa inchida Draft-urile dorite si apoi la “Inchiderea de ZI” definitiva, daca nu se razgandeste din nou, Draft-urile sale vor fi anulate (si produsele repuse pe stoc) .

Sistemul Retail va implementa si un sistem de definire a unor “pachete” – produse grupate, care numai impreuna se vand in conditii avantajoase clientului .

In cazul in care sistemul ePOS este inaccesibil (sau exista alte dificultati in incheierea unui abonament in ePOS) nu se vor poata salva abonamentele fara import (modul manual de creare a unui abonament nu este permis) .

Generarea unei facturi se face dintr-o pagina asemanatoare cu cea descrisa in Figura 1 - Facturarea . La apasarea pe butonul Add se deschide fereastra de adaugare tranzactie noua (ce prezinta in mod secvential compunerea unei noi tranzactii prin definirea tipului de vanzare, a planului tarifar si a prelungiri contractuale – ultimele doua nefiind folosite in cazul unei vanzari standard) . La apasara pe butonul Edit se deschide o fereastra de vizualizare a tranzactiei selectate din lista, cu posibilitatea de a o modifica (adaugare/stergere/modificare discount, produs, pret) si cu posibilitatea de a schimba modul de facturare (in acest caz discounturile ce nu mai sunt valabile in noul mod de facturare dispar, si utilizatorul este nevoit sa aleaga un nou pret si un nou discount din lista de optiuni disponibile) . La apasarea butonului de stergere se va elimina intreaga tranzactie de vanzare prezenta in factura .

Bonul de casa

Un bon de casa de marcat poate fi:

• Document de incasare si
• Document de vanzare (daca se emite numai bonul, fara factura) .

Un bon de casa de marcat poate fi un

• Document de incasare (daca se emite factura pentru acest bon) .

Un bon de casa nu are trecut numele clientului ci numai produsele cumparate si valoarea totala a acestora daca este achitat cash . Daca achitarea se face cu CC, atunci pe bonul de casa apare si numele clientului si numarul chitantei de POS . Bonul de casa este emis de casa de marcat, un device extern cu care Sistemul Retail se interfateaza .

Bonurile fiscale sunt evidentiate in jurnalul de vanzari zilnic . In cazul in care achitarea lor se face in numerar ele sunt evidentiate in borderoul de incasari zilnic ca documente ce atesta incasarea .

Pe un bon de casa se pot face vanzari in baza unei chitante de plata cu carte de credit, in acest caz trebuind sa apara pe bonul de casa numarul chitantei si sa fie clar identificata aceasta incasare .

Se pot acorda si reduceri, insa numai cele globale, si care nu depind de un client .

Un bon de casa poata fi transformat intr-o factura dar numai daca bonul de casa este din aceeasi zi ca si factura ce se va emite .

Pe un bon de casa de marcat va fi specificat si numarul de telefon pe care s-a efectuat reancarcarea directa .

Va exista si posibilitatea ca din aplicatia de incarcari directe sa fie generat automat un bon de casa, fara sa mai fie nevoie de interventia vanzatorului in cadrul modulului de emitere de bonuri de casa . Pentru eVouchere sa se poata alege daca se emite direct bonul de casa sau doar este pregatiri eVoucherul pentru a fi transformat in bon de casa din modulul de emitere de bonuri de casa de marcat .

La tiparirea unui bon de casa de o valoare mai mare ca n RON (dar inainte de salvarea sa definitiva) sa fie atentionat vanzatorul ca in cazul in care clientul este o persoana juridica acest bon nu va putea fi folosit in decontare . Aceasta valoare a bonului va putea fi schimbata dinamic din aplicatie . Daca vanzatorul alege sa-i fie facuta factura clientului, bonul nu se mai salveaza si i se deschide automat fereastra de facturare cu produsele de pe bon deja completate, trebuind doar ales clientul .

Un bon de casa poate fi anulat doar inainte de inchidere (daca insa emiterea sa se face dintr-o singura operatiune, nu se mai poate anula) . Stornarea unui bon de casa se poate face numai in conditii exceptionale, sub indrumarea departamentului contabil .

Stornare / anulare

Orice factura emisa poate fi stornata/anulata . Anularea are loc in aceeasi zi in care a fost emisa factura iar stornarea se incheie fie in aceeasi zi, fie la cel putin o zi distanta de facturarea initiala . In cazul unei stornari va fi emisa o noua factura, dar va fi pe suma negativa, astfel incat cele doua facturi (initiala si stornarea) sa aiba impreuna valoare nula .

Stornarea poate fi incheiata si partial: o parte din produse sunt returnate de client si ii este returnata suma corespunzatoare acestora . In cazul in care pe factura exista si discounturi globale fixe (adica nu puncte ThanlYou) nu se poate face stornare partiala . In cazul in care pe factura initiala sunt trecute Puncte ThankYou, atunci punctele se vor distribui pe produsele de pe factura si o parte din ele vor fi incluse in factura storno emisa . Fiecare produs stornat de pe factura initiala va fi trecut in factura storno cu tot cu pretul sau de baza si discounturile asociate . Produsele stornate din factura iniatiala vor fi marcate ca atare, pentru ca pe factura respectiva sa mai poata fi aplicate

stornari partiale .

Stornarile pot fi impartite in functie de tipul de plata catre client:

• Stornare cash: in acest caz se emite o dispozitie de plata si se returneaza clientului bani din casa;
• Stornare prin OP: banii trebuie sa intre in contul clientului . In acest caz, clientul trebuie sa declare atat contul cat si banca DIN care a facut plata initiala . In urma unei astfel de stornari se va emite si o informare (pe mail de exemplu) catre persoanele interesate din departamentul Contabilitate;
• Stornare cu OP pentru refacturare: in acest caz OP-ul original este refolosit la noua factura si nu mai este cazul ca respectivul client sa declare contul si banca in care sa-i fie virati banii . Pentru ca tot in baza aceluiasi OP i se va emite si noua factura, aceasta va contine o referinta la factura de stornare prin OP si nicio informare nu se va emite catre utilizatori interesati din cadrul departamentului de Contabilitate (dar se vor putea analiza intr-un raport aceste situatii) . Se vor putea storna poentru refacturare mai multe facturi si apoi pe noua factura sa fie folosite toate OP-urile de pe aceste facturi (insumate) pentru a genera o noua factura (cel mai probabil pe o suma mai mare), sau chiar sa fie adaugate OP-uri noi sau metode noi de plata pentru a acoperi costul facturii . (de ex . doua facturi achitate prin OP sunt stornate si se emite o noua factura care este achitata prin cele doua OP-uri originale, plus o diferenta achitata prin Carte de Credit) .

Stornarea va contine in clar, pe exemplarul tiparit si referinta la factura originala (numarul ei, suma, OP-ul de pe aceasta, etc . ) .

Exemplarul tiparit de factura storno trebuie si acesta sa fie unic identificabil, salvandu-se in baza de date un identificator de exemplar tiparit, pe care aplicatia il va tipari pe acesta, astfel incat sa existe mereu o asociere intre fiecare exemplar tiparit di inregistrarea din baza de date .

In cazul in care o factura este finalizata intr-un magazin si este apoi stornata in alt magazin, suma de pe dispozitia de plata va apare pe borderoul vanzatorului din magazinul in care se face stornarea si produsul returnat de client va ajunge in stocul corespunzator vanzatorului din magazinul in care se face stornarea (cu tot cu serie IMEI) .

In cazul unei stornari va exista o lista de motive de stornare, cu elemente fixe, dar si posibilitatea de a completa manual un motiv inedit (catalogat ca ‘Other reasons’) .

Tot in cazul unei stornari, mai ales in cazul in care facturarea-stornarea are loc in magazine diferite, va exista posibilitatea ca unii utilizatori (sau anumite persoane, definite prin adresele lor de mail) sa primeasca o notificare referitoare la stornarea ce tocmai s-a incheiat (de ex . departamentul Contabilitate sa fie informat), cu conditia ca acea stornare sa nu se transforme intr-o refacturare . Departamentul Contabilitate trebuie sa primeasca o notificare doar in cazul in care stornarea implica un retur de bani prin banca . Daca se face refacturare nu este nevoie de informare, sau daca banii sunt returnati in numerar ,, . tranzactia se va exporta in oa . In cazul unui retur prin banca, vanzatorul va trebui sa completeze in aplicatie datele platitorului din OP initial respectiv numele, banca, contul, suma de returnat, data platii initiale – date care trebuie mentionate in notificare . .

In cazul in care clientul doreste o refacturare, sa existe posbilitatea de a efectua o stornare cu refacturare (fie refacturare pana la nivel de produs, fie pana la nivel de client) . Daca plata initiala a fost efectuata cu carte de credit sau cu Ordin de Plata (adica plata prin servicii bancare), stornarea si refacturarea ar trebui ca suma platita prin banca sa se reflecte atat in stornare cat si in refacturare (eventualele diferente de refacturare sa fie vizibile in dispozitii de plata sau in chitante de plata cash suplimentara) – daca clientul vrea ca noua facturare sa se opereze printr-o tranzactie noua, refacturarea nu va fi legata de stornare, dar stornarea va fi operata tot prin banca (poate fi operata si cash, depinde de dorinta clientului) .

La o stonare cu refacturare va fi stocata si referinta initiala a facturii ce este stornata .

Factura pe baza de bon fiscal

Facturile pe baza de bon fiscal nu pot fi anulate in sens conventional . Anularea unei facturi emisa pe baza de bon trebuie sa presupuna revenirea acesteia la starea de bon fiscal fara factura asociata, insa informatia legata de vanzarea initiala (cea inchisa cu bonul fiscal) nu trebuie sa se piarda .

Din aceste motive, o anulare a unei facturi pe baza de bon fiscal nu va produce reintroducerea in stoc a produselor aflate pe bon .

Proforme

Proformele, fiind facturi emise in avans unui client, nu trebuie sa produca si descarcari din gestiune . Ca si in cazul unei facturi, trebuie selectat clientul, produsul (produsele), pretul de baza si discounturile aplicabile . La fel ca si in cazul unei facturi, vanzatorului ii sunt puse la dispozitie toate discounturile acordabile, din care se vor selecta numai cele ce nu vor aparea pe proforma . Nu se selecteaza seriile produselor in cadrul unei profome, decat in cazul in care se doreste sa se faca o rezervare pentru acel produs .

Rezervarea este accesibila numai vanzatorului care a eliberat proforma si poate fi anulata numai de un utilizator de rang superior . In cazul in care se face o rezervare, produsul nu va fi destocat ci numai marcat ca fiind rezervat .

In momentul in care un utilizator creaza o proforma (adica la salvarea sa), produsele de pe aceasta sunt salvate intr-o lista speciala de rezervari .

Rezervarea este facuta din magazia magazinului (nu este nevoie sa-si mai transfere telefonul pe stocul sau) si este facuta la nivel de produs, fara a mai fi necesara alegerea unei serii IMEI de telefon, pentru vanzare .

O rezervare valabila pentru o proforma este vizibila numai 5 zile (sau o perioada, definibila la nivel de Sistem Retail) . Dupa aceasta perioada, proforma si rezervarea sa se anuleaza (se pastreaza insa aceste date intr-un istoric) .

Sistemul Retail va prevede si posibilitatea de a schimba parioada de valabilitate a unei proforme, ca proprietate generala de Sistem (va exista o interfata utilizator de stabilire a tuturor parametrilor generali ai Sistemului Retail) .

SHAPE * MERGEFORMAT

Denumire  Cod Bucati pe stoc

Cauta dupa IMEI:

dublu click sau Enter

Lista IMEI pentru: [ nume produs ]

IMEI pe stoc Vnz .

Discounturi Disponibile pentru aplicare:

Denumire Tip Valoare

Sunt afisate numai discounturile aplicabile la nivel de produs (si care sunt valabile pentru vanzarea curenta)

Daca se citeste cu un pistol de citit coduri de bare, atunci se trece direct la pasul alegerii disc .

Figura 2 - Selectia Produselor la Vanzare

SHAPE * MERGEFORMAT

Client:

Nume:

Prenume:

Nr . tel . :

Detalii

ADD

EDIT

DELETE

NOKIA CLASSIC JEWELRY COLLECTION CP Discount 20 EUR SIM CARD PLUG-IN F01, G10

SONY ERICSSON K610i red Discount 10 EUR SIM CARD PLUG-IN F01, G10

Reducere puncte Thank You

TOTAL: 430 . 5 RON TOTAL: 230 . 5 RON TOTAL: 95 . 1 RON

TOTAL: 756 . 1 RON

ADD

EDIT

DELETE

Detalii Tranzactie de vanzare:

NOKIA CLASSIC JEWELRY CO 450 . 5 RON Discount 20 EUR  -20 . 0 RON SIM CARD PLUG-IN F01, G10  0 . 0 RON

Denumire  Pret

Fid .

Ab .

Figura 3 – Facturarea - Mecanismul de vizualizare vanzare in curs

Schimburi

Inlcuirile de produse se fac numai in cazul defectarii (orice produs din magazin, supus vanzarii si caruia i se acorda o garantie), al pierderii (SIM-uri) sau al deteriorarii acestora (SIM-uri) .

Schimb de defect

Schimbul de defect va putea fi operat de orice vanzator cu rol de Stock Keeper si va rezulta intr-un transfer automat a produsului in magazia de defecte (o introducere pe stoc de fapt) .

Afecteaza numai telefoanele si necesita cunoasterea clientului, a facturii de achizitionare si a datei de cumparare a produsului (sunt introduse manual, dar sistemul verifica corectitudinea completarii datelor) . In cazul in care clientul a cumparat produsul pe alte canale si acesta este brandat Orange (seria este recunoscuta ca fiind achizitionata la origine de Orange), se va permite introducerea manuala a seriei facturii si a datei de cumparare . Dintre produsele de pe factura (produse inlocuibile) se selecteaza cel ce se doreste sa fie schimbat si apoi si produsul corespunzator de pe gestiune ce urmeaza a-i fi dat la schimb clientului .

Responsabilitatea pentru transferul cu magazia de defecte va fi a utilizatorului care face schimbul .

Telefonul dat la schimb clientului trebuie in prealabil sa fie transferat pe stocul asociat utilizatorului care face schimbul de defect .

Produsul defect va fi transferat automat in magazia de defecte in urma schimbului .

Se va pastra un istoric al schimburilor pentru ca in cazul unei stornari sau la un nou schimb de produs sa nu se schimbe tot prima serie (seria cea mai recenta aflata la client este cea pe care se vor opera noile schimbari sau stornari) .

In cazul unei stornari in care este implicat un telefon schimbat, pe factura storno va aparea seria initiala, dar pe stoc va fi pus telefonul cu serie schimbata (adica cel cu seria cea mai recenta) . In acest sens se va pastra o asociere cu factura de achizitie, astfel ca la o eventuala stornare va fi repus pe stocul utilizatorului ce face stornarea produsul cu seria schimbata si nu cel originar .

Va exista posibilitatea de a efectua un schimb de defect pentru produse achizitionate in oricare alt magazin, iar istoricul se va actualiza corespunzator . Daca un client cumpara dintr-un magazin si schimba produsul in altul, factura sa initiala va avea atasata seria noua, chiar daca va fi schimbata in alt magazin .

Va exista si posibilitatea de a retipari schimburile de defecte si de a le vizualiza .

Va exista posibilitatea de a efectua un schimb de produs defect si pentru cazurile in care un produs este in service mai mult de 36 de zile (o lista de motive de schimb va permite selectii diferite, unele conditionate – de ex . in cazul schimbului pentru un telefon tinut mai mult de 36 de zile in service se va consulta istoricul de SAV al respectivei serii) .

Schimbul de defect se face doar pe acelasi cod de produs (insa va trebui verificat cu departamentul de contabilitate daca se poate face o exceptie in cazul in care difera “culoarea”) .

Daca un schimb de defect nu se poate face, se va opera o stornare in sistem .

In cazul unor erori de import, sa se poata modifica informatiile de import din ePOS .

Se va face numai pe magazia magazinului, defectul va fi transferat automat in magazia de defecte .

Schimb de SIM PrePay

Permite schimbul de SIM-uri PrePay . Pentru aceasta operatiune se vor completa:

• datele identificare client (pentru selectarea sa din lista de clienti) – sa existe si posibilitatea de a importa clientul din sistemul Vantive sau EPOS in cazul in care acesta inca nu este introdus in Sistemul Retail;
• motivul inlocuirii cartelei:
• Cartela defecta;
• Cartela stricata din vina clientului;
• Cartela furata sau pierduta;
• La cerere;
• etc .
• numarul de inventar al SIM-ului vechi;
• numarul de inventar al SIM-ului nou (identifica si produsul ce trebuie destocat);
• in cazul in care este stricata sau defecta, trebuie sa se introduca si o descriere a defectiunii;
• daca este pierduta sau furata, se poate introduce si seria trecuta pe pachetul ce cotinea SIM-ul;
• consumul mediu anual (preluat automat din CRM-Vantive);
• data activarii PrePay-ului (preluat automat din CRM-Vantive);
• taxarea inlocuirii:
• gratuita;
• taxata cash/carte credit;
• taxata cu diminuarea creditului (eventual aceasta optiune poate fi inhibata din motiv de imposibilitate de inregistrare contabila);
• tipul de taxa de inlocuire platita de client (pot exista mai multe taxe, in functie de credit, de vechime, de numarul de inlocuiri efectuate de-a lungul timpului sau de numarul de schimburi intr-o anumita perioada) .

Datele pot fi completate manual sau automat, prin import din EPOS .

In urma unui schimb de SIM PrePay se va tipari un “Formular de inlocuire produse ale serviciului preplatit” .

Daca schimbul de SIM PrePay presupune si plata unei sume (suma va fi o taxa fixa, dar cazurile in care aceasta suma trebuie platita vor fi stabilite de Sistem, in baza unor conditii), atunci sa fie usurat accesul la facturare . Se vor completa automat toate datele de facturare (clientul si produsul) vanzatorul trebuind doar sa aleaga modul de plata si eventual sa aibe posibilitatea de a schimba persoana pe care se intocmeste factura . In cazul in care persoana pe care se intocmeste factura difera de titular, schimbul de SIM apare in istoricul acesteia .

Daca din ePOS nu este importat si clientul (ca detalii de nume, adresa, etc) acestea sa poata fi introduse din Sistemul Retail la momentul importului .

Conditie ca schimbul de PrePay sa se incheie cu succes: un MSISDN corespunde in mod unic la un moment dat unui singur client din Sistemul Retail .

Schimb de SIM PostPay

Accesibil numai Shop Managerilor .

Functional, importul din ePOS presupune doar preluarea informatiilor din ePOS (inclusiv cele legate de client) – este automatizat, pentru import fiind necesara apasarea unui buton de “Import Schimb SIM PostPay din ePOS” .

Permite un schimb de SIM PostPay pentru clientii abonati Orange .

In cazul in care nu este operata in ePOS schimbarea de SIM, importul in Sistemul Retail nu se poate efectua . In acest caz exista si posibilitatea de a efectua manual schimbarea de SIM . In acest caz, se vor completa:

• datele de identificare client (fie client existent in Sistemul Retail fie un client existent in sistemele Vantive si EPOS);
• numarul de inventar al SIM-ului vechi;
• numarul de inventar al SIM-ului nou;
• motivul pentru care se face schimbul:
• SIM furat/pierdut;
• SIM blocat;
• SIM defect;
• SIM stricat de client;
• etc .
• selectarea taxei de inlocuire .
• etc .

Schimbarea manuala de SIM PostPay este accesibila numai unui utilizator de nivel superior .

In urma efectuarii unui schimb de SIM PostPay se va tipari un “Formular pentru inlocuirea cartelei SIM”

Daca vanzatorul este gresit completat, sa se poata forta importul din ePOS pe codul corect de vanzator (in acest caz utilizatorul este rugat sa completeze codul corect – daca il are la dispozitie) . In cazul in care codul corect de vanzator nu poate fi stabilit, importul pe acest SIM nu se va finaliza, si va fi necesara interventia externa .

Interfatare Sistem Retail – sisteme existente

lista vanzatori, info magazin

loializari, multiple info . cllienti

Oracle Applications

comenzi, stocuri, vanzari, retur, etc

Sistem Retail

procese verbale SAV

info . loializari schimb sim PrePay

eService

Intrari

Iesiri

EPOS

marfa, stocuri, produse, etc

clienti, schimburi sim, scaderi sim

CRM (Vantive)

servicii PrePay

eVouchers

eTopUp

servicii reincarcare directa

eService

devize, status

URS

Oracle Applications

Registrul de Casa

lista vanzatori, vanzari zilnice

Casa de marcat

bonuri de casa

eVouchers

Sistemul Retail se interfateaza cu urmatoarele sisteme externe :

• Intrari:
• Oracle Applications
• EPOS
• CRM
• eVouchers
• eTopUp
• eService
• Iesiri:
• Oracle Applications
• eService
• Registrul de casa
• URS
• Casa electronica de marcat
• eVouchers

Intrari in Sistemul Retail

Intrari din Oracle Applications

Import Marfa:

Sistemul Retail va importa marfa din Oracle Applications sub forma unor inregistrari continand informatii despre:

• produs,
• serie produs,
• cantitate,
• pret lista,
• data comenzii din OA,
• etc

Importul de marfa din OA poate fi legat de o comanda initiata de Sistemul Retail (importul inchide o comanda emisa din Sistemul Retail) sau poate fi independenta de comenzile emise din Sistemul Retail (o comanda din OA care nu a fost initiata din Sistemul Retail) .

Import produse

Produsele din Sistemul Retail vor trebui create mai intai in OA si importate apoi in sistem . Sistemul Retail va trebui sa pastreze o identificare unica a produsului din OA (codul OA al produsului) pentru referinte ulterioare intre cele doua sisteme .

Indentificarea produselor fara replenishment in WAREHOUSE nu este disponibila (nu pot fi identificate produsele pentru care nu se mai fac achizitii – in WAREHOUSE)

Unele produse apartin exclusiv Sistemului Retail (este vorba de taxe sau de servicii de reincarcare, tinute in Sistemul Retail tot ca produse), 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) .

Produsele sunt importate din 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 .

Din OA produsul este importat cu urmatoarele detalii:

denumire OA

cod OA

pret de cost

data primei intrari in stoc

alte proprietati

Importul din OA se declanseaza manual de catre utilizator, specificandu-se codul OA de produs care se doreste a fi importat, sau prin import automat, dar decis de utilizatorul autorizat sa efectueze intretinerea produselor in Sistemul Retail . Acest utilizator este informat periodic de noile produse aparute in OA si decide daca trebuie sa fie importate in Sistemul Retail .

In conditiile in care in OA nu apar mai mult de 3-4 produse pe zi, se poate face, la un interval regulat, un import de produse noi din OA (un produs este introdus in OA cu mult inainte ca el sa apara in WAREHOUSE) . O lista de produse noi disponibile este generata de Sistemul Retail si este afisata intr-un pop-up, la prima autentificare in sistem, utilizatorilor responsabili de intretinerea produselor in Sistem . Este posibil ca la aparitie unor produse noi sa se trimita si o notificare prin eMail catre persoanele interesate .

In OA exista si o data de creare a produsului, prin urmare poate fi implementat in Sistemul Retail si un raport de produse noi pentru o anumita perioada – accesibil numai unor utilizatori autorizati . Raportul va permite filtrarea produselor noi din OA dupa:

• data crearii (sau perioada crearii);
• denumire;
• cod .

Produsele ce sunt considerate demne de import in Sistemul Retail sunt apoi bifate dintre rezultatele filtrului si sunt apoi importate in Sistemul Retail .

Utilizatorii responsabili de intretinerea produselor in Sistemul Retail decid care produse trebuiesc introduse in Sistem, din lista de produse noi disponibile .

Importul produselor din OA se face la nivel de cod OA . Fiecare produs importat va avea atasate si informatii legate de caracteristici (ramane sa se decida asupra tiputilor de caracteristici care vor fi importate in Sistemul Retail) . Caracteristicile de baza ale produselor vor fi introduse de un utilizator autorizat (din partea departamentului Logistica), sub forma unor fisiere excel, al caror continut va popula apoi detaliile de produs din Sistemul Retail . Fisierele folosite la importul in Sistemul Retail vor avea o structura predefinita (campuri prestabilite) .

Produsele din OA importate in Sistemul Retail pot sa aiba si informatii legate de linia de produs (compatibilitati intre produse) . Aceste informatii vor fi intretinute (daca e cazul) tot de un utilizator autorizat, din partea departamentului Logistica, impreuna cu datele legate de caracteristicile terminalelor .

In cazul in care un produs nou din OA nu are inca aceste detalii discutate mai sus, completate, utilizatorul autorizat cu introducerea produselor in Sistemul Retail este informat asupra lipsei acestora . Poate fi generat si un email catre persoanele responsabile cu introducerea caracteristicilor de produs .

Intrari din EPOS

Sistemul EPOS contine abonati Orange Romania S . A . , permite incheierea de noi contracte, schimburi de SIM, efectuarea de cesiuni, etc .

Import clienti

Clientii introdusi in sistemul EPOS sunt noi abonati . Importul de clienti din EPOS se face pentru a incheia o vanzare la oferta de abonament in Sistemul Retail sau pentru a actualiza lista de clienti .

Informatiile aduse din EPOS legate de client sunt cele de definire a entitatii client (vezi cap . Entitati – Entitatea Client), insa fara informatiile legate de istoric (fiind client nou, nu are istoric de abonament in CRM), cele legate de magazin si de vanzatorul care a facut abonamentul (exista o asociere intre utilizatorii EPOS si cei din Sistemul Retail) .

In cazul in care se face importul in vederea unei vanzari, trebuie ca impreuna cu clientul sa se aduca si informatiile referitoare la cartela SIM inmanata clientului (tipul si clasa SIM-ului, seria sa, etc . ), iar Sistemul Retail va face automat destocarea cartelei SIM si va facilita si destocarea sa din gestiunea OA .

Import schimburi de sim

Schimburile de SIM se opereaza in EPOS, iar acesta le propaga in CRM si Sistemul Retail . Datele puse la dispozitie de EPOS sunt cele legate de clientul caruia i se face schimbul (vezi cap Entitati -Entitate Client), si cele legate de SIM-uri:

• seria SIM-ului inlocuit;
• seria SIM-ului nou;
• motivul inlocuirii;
• taxarea inlocuirii (daca e cazul) – taxare ce se materializeaza mai tarziu intr-o factura, deci trebuie pastrata si o asociere intre facturi si schimburile de SIM cu taxare;
• data inlocuirii;
• vanzatorul care face schimbul de SIM;
• magazinul in care se face schimbul de SIM;
• etc .

Import scaderi de sim

Scaderile de SIM sunt abonamente noi, incheiate cu clienti care nu vor si sa cumpere terminale ale companiei . Sistemul EPOS pune la dispozitie o lista de clienti (definiti conform proprietatilor entitatii client – cap . Entitati) si SIM-urile scazute . Clientul trebuie sa aiba definit si subscriberul in cazul in care este o scadere de SIM PostPay . Orice SIM are fizic o serie, care se preia prin import din EPOS pentru a fi salvata in tranzactia generata si a fi folosita pentru eventuale rapoarte . Asocierea intre produsele de tip SIM din gestiunea interna a Sistemului Retail si SIM-urile din EPOS se face dupa tip si clasa de SIM (ex . in EPOS avem SIM J3 G4 iar in Sistemul Retail acestuia trebuie sa-i fie asociat codul OA si sa fie destocat din gestiune) . Cu alte cuvinte, destocarea SIM-urilor din Sistemul Retail se face cantitativ pe tipul de SIM importat .

Intrari din CRM (Vantive)

Import loializari

Sunt preluate informatii legate de:

• client (conform proprietatilor entitatii client – cap . Entitati, vezi si Specificatiile Tehnice de interfatare cu Vantive-ul);
• subscriberii clientului (numerele de telefon ce-i apartin);
• numarul de puncte ThankYou disponibile clientului;

Import Pachete

Sunt preluate din Vantive pachetele pentu abonamentele incheiate de client (sau pentru pachetul PrePay achizitionat), catalogate dupa tip: voce, date, 3G, etc .

Import Optiuni

Sunt preluate din Vantive optiunile definite si atasabile unui abonament . Acestea vor cuprinde denumirea comerciala si codul Vantive . Intern Sistemului Retail li se vor putea atasa si descrieri suplimentare (pentru o mai clara identificare) .

Consultare/import informatii client

Sistemul Retail va trebui sa se interfateze cu Vantive pentru a obtine diverse informatii despre clientul subiect al operatiunii . Aceste informatii pot include, dar nu se limiteaza la:

• consum
• valoare medie/ultima factura
• nr . contracte
• vechimea in retea
• servicii la care este abonat
• istorie credit
• etc

Aceste informatii trebuie sa fie disponibile on-line (in timp real) pentru a putea fi folosite la o eventuala personalizare a avantajelor oferite fiecarui client in parte in momentul in care acesta doreste sa efectueze o operatiune in Sistemul Retail .

Intrari din eVouchers

Import informatii servicii PrePay (eVouchere)

Sistemul Retail va trebui sa importe informatiile legate de serviciile de reincarcare PrePay generate de sistemul eVouchers .

Intre informatiile generate de sistemul eVouchers si care trebuie importate in Sistemul Retail sunt:

• identificator order
• data order
• vanzator care a generat eVoucher-ul
• destinatie eVoucher (bon/factura),
• produs (eVoucher) generat
• pret
• cantitate
• etc

Modificare destinatie eVoucher importat

Sistemul Retail trebuie sa permita utilizatorilor autorizati modificarea unui import de servicii PrePay, in cazul in care s-a ales gresit destinatia unui eVoucher (de ex . sa nu fie disponibil pentru vanzare pe bon de casa ci sa fie disponibil unei vanzari pe baza unei facturi) .

Includere pe factura / bon de casa

Dupa import, informatiile generate de sistemul eVouchers vor trebui sa poata fi incluse pe o factura (creata de catre utilizatorul care a generat eVoucher-ul) sau pe un bon de casa de marcat .

Rapoarte de verificare

Sistemul Retail trebuie sa puna la dispozitia utilizatorilor autorizati rapoarte de verificare a vanzarilor de eVouchere, cu comparatie intre numarului de eVouchere generate si numarul de eVouchere incluse pe factura sau bon de casa, precum si o comparatie intre eVocuherele emise din sistemul eVoucher si ceea ce a fost importat in Sistemul Retail .

Alert-uri eVouchere nefacturate

De asemenea, Sistemul Retail ar trebui sa genereze alert-uri automate in cazul in care vanzatorul are eVouchere generate dar pentru care n-a tiparit factura sau bon de casa . Un model asemanator de alert-uri ar trebui sa se genereze pentru Shop Manager in cazul in care exista vanzatori cu eVouchere netiparite mai vechi de o zi .

Intrari din eTopUp

Import informatii Servicii Reincarcare Directa

Sistemul Retail va importa informatii legate de serviciile de reincarcare directa generate de sistemul eTopUp .

Informatiile generate de sistemul eTopUp sunt asemanatoare cu cele generate de sistemul eVouchers (punctul Intrari din eVouchers) .

Includere pe factura / bon de casa

Dupa import, informatiile generate de sistemul eTopUp vor trebui sa poata fi incluse pe o factura (creata de catre utilizatorul care a generat cererea de reincarcare directa) sau pe un bon de casa de marcat .

Rapoarte de verificare

Sistemul Retail trebuie sa puna la dispozitia utilizatorilor autorizati rapoarte de verificare a vanzarilor de servicii de reincarcare directa, cu comparatie intre numarului de eVouchere generate si numarul de eVouchere incluse pe factura sau bon de casa .

Alert-uri servicii nefacturate

De asemenea, Sistemul Retail ar trebui sa genereze alert-uri automate in cazul in care vanzatorul are eVouchere generate dar pentru care n-a tiparit factura sau bon de casa . Un model asemanator de alert-uri ar trebui sa se genereze pentru Shop Manager in cazul in care exista vanzatori cu eVouchere netiparite mai vechi de o zi .

Intrari din eService

Import devize si status terminal

Sistemul Retail va trebui sa importe informatii generate de aplicatia eService . Aceste informatii includ:

• devizele generate de aplicatia eService pentru activitatea de service post garantie pentru terminalele achizitionate prin shop-urile Orange – accesibile imediat ce starea unui PV este intr-un stadiu terminal (de ex . in starea de ‘Trimis inapoi catre punctul de colecta’);
• statusul telefoanelor in service (din eService, dandu-se un PV si un magazin, sa se poata obtine starea acestui PV - trebuie in prealabil importate din eService lista de stari; in cazul in care starea unui PV este una terminala, sa se poata vedea si suma de plata pe care clientul o are de achitat, daca exista - in acest mod clientul poate fi informat din timp de eventualele cheltuieli pe care trebuie sa le suporte) . Tot in cadrul unei receptii din Orange Service Center, sa se importe si eventualele modificari aduse terminalului (serie noua baterie, serie noua IMEI, etc . ) .

Aceste informatii trebuie sa fie disponibile on-line in Sistemul Retail, pentru a fi utilizate la inchiderea unui Proces Verbal de SAV sau la cerere de catre vanzator (verificarea statusului terminalului in service) .

Orange Service Center dispune de o lista de modele de telefoane pe care le repara (la nivel de cod de produs) si la nivel de brand . Aceste lista vor fi periodic importate (zilnic) in Sistemul Retail pentru a asigura o trimitere corecta a telefoanelor in service (repartizarea lor corecta – catre operatorul de service corect) .

Din eService se va importa si o lista de defecte recunoscute de aceasta aplicatie, defecte ce se vor folosi si cand un telefon este trimis catre operatorul propriu de service .

Devizul inclus pe factura

Informatiile derivate din devizul generat de aplicatia eService vor trebui incluse automat pe o anexa la factura ce se va emite clientului care a adus terminalul defect la shop . In factura va figura numai valoarea totala a devizului, adica se va face o facturare a unui serviciu de post-garantie .

Iesiri din Sistemul Retail

Iesiri catre Oracle Applications

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 .

• vanzarea
• stornarea
• schimbul de SIM (PrePay, PostPay)
• schimbul de defect
• corectia de serii
• tranzactia de SAV – SWAP
• transferurile intre magazine
• retururile de marfa
• receptiile de marfa in magazin
• transferul intre gestiunile aceluiasi magazin
• incasarile cash (chitante)
• retururile de numerar (DP)

Vanzarile efecuate in Sistemul Retail vor fi exportate catre OA printr-o impartire a acestora in :

• Facturare
• Destocare
• Incasare

Facturarea va exporta in OA sumele facturate si produsele .

Destocarea va exporta in OA informatiile pana la nivel de serie pentru destocarea din subinventarele OA .

Incasarea va exporta cash-ul catre OA .

In cazul unei facturi la termen, se va genera o facturare si abia la inchiderea vanzarii in Sistemul Retail cu un OP se va genera si o destocare . La stornarea unei astfel de vanzari (pentru ca nu s-a achitat in termen de n zile prin OP) se va genera o facturare inversa (valoric) .

Exportul catre OA (de tranzactii de transfer si de corectii, de vanzari, etc) se va face prin intermediul unui “buffer” – de unde OA, la intervale regulate, va prelua datele disponibile .

La exportul de marfa catre OA sa fie exportat si numele clientului . In plus, exportul catre OA se va face la nivel de tranzactie individuala din Sistemul Retail . Fiecare vanzare efectuata unui client va fi exportata in OA ca o tranzactie independenta, dar va fi legata la tranzactia din Sistemul Retail

Export comenzi de marfa

Sistemul Retail va trebui sa poata exporta comenzi de marfa catre sistemul Oracle Applications . Comanda va fi generata in interiorul Sistemului Retail si va trebui exportata catre Oracle Applications .

O comanda generata catre sistemul OA va trebui sa contina informatiile

• La nivel de header:
• locatie (customer catre care se emite comanda)
• data comenzii
• metoda de livrare (curier, rapid curier, turneu, etc) . Prin intermediul acestei informatii Shop Managerul va putea transmite informatii legate de urgenta comenzii .
• etc
• La nivel de detalii:
• produs
• cantitate
• etc

Inainte de a se emite o comanda catre OA, Sistemul Retail trebuie sa-i permita Shop Managerului sa verifice stocurile din OA pentru a se asigura ca produsele pe care acesta intentioneaza sa le includa pe comanda exista in cantitate suficienta pe stocul Available din OA .

Inregistrare automata a comenzii in OA

Comanda emisa de Sistemul de Retail va trebui sa fie inregistrata automat in Oracle Applications in modulul Order Management in starea “Entered” .

Dupa emiterea comenzii catre OA, Sistemul Retail va trebui sa interpreteze un raspuns din partea OA in urmatoarele situatii:

• Eroare – Sistemul Retail va trebui sa trateze situatia in care comanda nu s-a putut introduce in OA, si sa afiseze detalii in legatura cu motivul pentru care nu s-a putut face introducerea comenzii . In aceasta situatie Order-ul din Sistemul Retail va trebui trecut intr-o stare “eroare OA” .
• Succes – in cazul in care comanda a fost introdusa cu succes in OA, Sistemul Retail va prelua de la OA numarul de order, pe care il va salva impreuna cu comanda pentru referinte ulterioare (la receptia comenzii dupa validarea in OA) . Comanda va fi trecuta in Sistemul Retail in starea “Introdusa in OA” .

Export comenzi de retur marfa

Sistemul Retail va trebui sa permita exportul automat al unor comenzi de retur de marfa catre Oracle Applications . Aceste comenzi de retur vor avea urmatoarele caracteristici de baza :

• locatie (magazinul care face retur-ul de marfa, identificat ca si customer in OA)
• produs de returnat
• cantitate

Inregistrare automata a returului in OA

Operatiunea de retur emisa de Sistemul de Retail va trebui sa fie inregistrata automat in Oracle Applications in modulul Order Management in starea “Entered” .

Dupa emiterea returului catre OA, Sistemul Retail va trebui sa interpreteze un raspuns din partea OA in urmatoarele situatii:

• Eroare – Sistemul Retail va trebui sa trateze situatia in care returul nu s-a putut introduce in OA, si sa afiseze detalii in legatura cu motivul pentru care nu s-a putut face transferul . In aceasta situatie retur-ul din Sistemul Retail va trebui trecut intr-o stare “eroare OA” .
• Succes – in cazul in care returul a fost introdus cu succes in OA, Sistemul Retail va prelua de la OA numarul de order, pe care il va salva pentru referinte ulterioare (rapoarte de verificare, cross checking, etc) . Returul va fi trecut in Sistemul Retail in starea “Transferat in OA” .

Tranzactiile de retur nu pot fi importate in OA fara aprobare, prin urmare, un mail este generat catre persoanele apte sa ia aceasta decizie, si, daca acestea au acces in Sistemul Retail, pot sa aprobe transferurile . Un transfer aprobat poate fi apoi exporat catre OA . Altfel, in OA, returile se vor opera manual, in baza unor documente trimise de fiecare magazin in parte .

Atasata oricarui retur de produse, va exista si o “fisa de constatare” in care sa fie completate:

• motivul returului
• defectul constatat (daca exista)
• factura de achizitie (daca exista)
• data facturarii (daca exista)
• orice alte campuri necesare

Ordine de transfer

Operatiunile de transfer de marfa intre magazine vor trebui insotite in Sistemul de Retail de un ordin de transfer in OA .

Aceasta operatiune are ca scop pastrarea unor evidente corecte in inventarul OA din punctul de vedere al locatiei la care le gasesc produsele .

Ordinul de transfer trebuie sa se inregistreze automat in Oracle Applications in asa fel incat produsele sa se transfere automat dintr-un subinventar OA in altul in cazul unei operatiuni de transfer intern intre magazine .

Ordinul de transfer trebuie sa contina informatii la nivel de serie .

Transferul intre 2 locatii (magazine sau la/de la depozit) trebuie facut prin emiterea unui AIM (pe care se mentioneaza ca Nu urmeaza factura) astfel :

Loc 1 – loc de plecare a bunurilor

Loc 2 – subinventar de tranzit

Loc 3 – loc de sosire a bunurilor

Operatiunea 1 : Loc 1 -> Loc 2 se genereaza AIM din sistem (cu numerotare unica la fel ca la factura) la data plecarii fizice a bunurilor

Operatiunea 2 : Loc 2 ->Loc 3 la receptia bunurilor in locatia de sosire pe baza AIM – se completeaza seria si nr AIM in sistem pt identificare la data sosirii bunurilor

Fiecare operatiune se exporta catre OA in momentul in care a fost efectuata .

Export tranzactii diverse

Vanzari

Sistemul Retail va trebui sa permita exportul in OA al vanzarilor efectuate si inregistrarea acestora automata in OA .

Facturile / Bonurile Fiscale se vor exporta catre OA in scopul preluarii distributiei contabile, in scopul completarii Jurnalelor de Vanzare, ca referinta pentru platile din sistem .

Facturile/Bonurile fiscale se emit (tiparesc) in Sistemul Retail . In OA nu vor avea serie/numar unic din plajele alocate OA si nu se vor putea emite/tipari/retipari

Toate valorile (valoare fara TVA, valoare TVA, valoare cu TVA) asociate liniilor de produse din entitatilor Factura, Proforma, Bon Fiscal care se exporta in OA Receivables au un numar de 2 zecimale - numarul de zecimale al monedei functionale (RON) . Toate calculele de totaluri se fac cu 2 zecimale .

Calcului TVA se face pe linie / articol . Valorile totale se obtin prin insumarea liniilor

Se vor aplica urmatoarele rotunjiri :

Valoare fara TVA = ROUND( pret * cantitate, 2 zecimale)

TVA = ROUND(Valoare fara TVA * %TVA, 2 zecimale)

Valoare cu TVA = Valoare fara TVA + TVA

Total Valoare fara TVA = suma Valoare fara TVA de pe linii

Total Valoare TVA = suma Valoare TVA pe linii

Total Valoare cu TVA = suma Valoare cu TVA pe linii

Aceasta problema provine din faptul ca programul de import OA lucreaza cu entitatule cantitate, pret net, pret de lista si discount . Valorile nu sunt sume importate ci sunt sume calculate de procesul concurent care creaza facturile .

In cazul punctelor de discount Thank you punctul de plecare in rotunjiri va fi valoarea fara TVA . Sse vor aplica rotunjirile astfel :

1 punct = -0 . 10 Euro

Cursul la care se face calculul 1 Euro = 3 . 3421

1 punct cu TVA = -0 . 33421 RON

1 punct fara TVA = -0 . 33421 / 1 . 19 = -0 . 280848739495798

Numar de puncte = 100

Valoare fara TVA = round( nr pucte * valoare punct fara TVA, 2)=

Round(100*-0 . 280848739495798,2)=round(-28 . 0848739495798,2)=-28 . 08

TVA= round(Valoare fara TVA * 0 . 19,2)=round(-28 . 08*0 . 19,2) = -5 . 34

Valoare cu TVA = -28 . 08 – 5 . 34=-33 . 42

Destocare automata din OA

Sistemul Retail va trebui sa permita exportul automat al destocarilor catre sistemul OA, prin intermediul unei interfete, populate in timp real, odata cu operatiunea de vanzare din Sistemul Retail, protejata in interiorul aceleiasi tranzactii . Cu alte cuvinte, o operatiune de vanzare din Sistemul Retail trebuie sa provoace o destocare din OA .

Stocuri sincronizate Sistem Retail – OA (IC)

Stocurile din Sistemul Retail si cele din Oracle Applications – IC trebuie sa fie in permanenta sincronizate la nivel de cantitate per articol (nu este posibil la nivel de serie din cauza destocarii FIFO in IC) .

Transfer informatii vanzari in OA (GL)

Toate informatiile relevante referitoare la vanzarile din Sistemul Retail trebuie sa fie transferate in Oracle Applications, modulul GL (General Ledger) automat sau la cerere .

Tranzactii de operare pe stoc

Un transfer intre doua magazine va produce efecte in mod automat in gestiunea OA (prin intermediul unui export ‘live’, asemanator celui de tranzactii de vanzare) . Orice transfer intre doua magazine va presupune in Sistemul Retail si folosirea unei magazii speciale de tranzit, magazie in care se afla produsele trimise de la un magazin si care inca nu au ajuns la destinatie .

Sistemul Retail va putea genera si o tranzactie de corectie la nivel de serie IMEI, ramanand la latitudinea departamentului Logistica sa stabileasca daca va fi si exportata catre sistemul OA sau doar va fi raportata printr-un mail adresat persoanei responsabile de Sistemul Retail din cadrul departamentului Logistica .

Transferul de produse intre magazine poate fi operat in doua tranzactii:

• trimitere din magazin
• receptie in magazinul destinatie

Ramane la latitudinea Logisticii daca acest tip de transfer va fi operat in doua etape sau numai una singura .

Exportul de tranzactii SAV-SWAP

Exportul de SAV-SWAP se va face la nivel de serie IMEI, deci la nivel de tranzactie SAV-SWAP .

Vizibilitatea stocului SR din OA

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:

• Magazia de SAV imprumutate;
• Magazia de SAV schimb;
• Magazia de Rezervari;
• etc .

Va exista si o magazie speciala de transfer intre magazine (in cadrul celor de rezervari) vizibila in OA .

Iesiri catre Sistemul Vantive

Toate verificarile legate de corectitudinea tranzactiei de loializare se vor efectua in Sistemul Retail, in Vantive doar se vor exporta tranzactiile finalizate (de fidelizare/retention) .

Exportul catre Vantive presupune transferul tranzactiilor de fidelizare din Sistemul Retail . Orice tranzactie de fidelizare se efectueaza numai dupa ce in prealabil a fost verificata posibilitataea efectuarii sale (printr-o procedura interna Sistemului Retail) . Daca sistemul Vantive nu este disponibil, acestre tranzactii de fidelizare se acumuleaza intr-un buffer de unde sunt pe rand exportate catre Vantive . Din Sistemul Retail sa vor putea si forta unele tranzactii de loializare (de ex . pt . o loializare inainte de termen) . Fortarea va putea fi efectuata numai de un utilizator cu drepturi speciale . Aceste tranzactii fortate vor fi marcate corespunzator astfel incat sa poata fi raportate oricand .

In urma unui export catre Vantive, se va obtine un ID de tranzactie din Vantive, ID care identifica succesul inserarii tranzactiei in Vantive (acest ID poate fi folosit apoi la stornari si la referentierea tranzactiei din Vantive) .

Exportul de fidelizari presupune transmiterea datelor:

customer number;

subscriber MSISDN;

tip fidelizare;

prelungire contractuala;

puncte OTY acordate;

produs;

cantitate (in general este 1 pentru telefoane si n pentru alte produse);

pret final (pret net, exprimat un EURO, fara TVA – va include si discountul de la nivel de produs, nu si pe cel de puncte TY)

In cazul in care se exporta un produs ce nu exista in OA, acesta trebuie sa aibe din Sisteml Retail un cod asemanator celui OA, “fake”, cu care sa se exporte (de ex . in cazul eVoucherelor, al taxelor, etc . ) .

Exportul catre Vantive va cuprinde si anularile si stornarile de facturi din Sistemul Retail, facturi ce contineau tranzactii de loializare si puncte OTY (va exista un mecanism similar celui de la facturare: folosind ID-ul de tranzactie din Vantive, se va genera o tranzactie marcata drept “Cancelled”) .

Exportul catre Vantive va cuprinde si stornarile partiale . Exportul unei stornari partiale, din punctul de vedere al Sistemului Retail, se poate face prin doua metode:

- se exporta catre Vantive o tranzactie “Cancelled” intr-un format special: va contine si informatiile despre produsele, preturile si punctele OTY stornate – aceasta tranzactie nu trebuie sa modifice data ultimei loializari din Vantive;

- se genereaza o tranzactie “Cancelled”, folosind ID-ul de tranzactie din Vantive, iar apoi se genereaza o noua fidelizare, continand numai produsele care nu au fost stornate (de pe factura initiala) . In acest caz insa, se modifica data ultimei loializari din Vantive, fiind pusa chiar data stornarii partiale ca fiind data ultimei loializari . Aceasta informatie ar putea fi actualizata apoi de catre Sistemul Retail printr-un nou export, care de data asta nu modifica decat data ultimei loializari, pentru un subscriber specificat in tranzactie .

Catre Vantive mai sunt generate in mod automat din Sistemul Retail si jurnale, in cadrul procesului de SAV:

Jurnal de receptie telefon defect preluat de la client;

Jurnal de retur telefon reparat la client;

Jurnal de trimitere in service;

Jurnal de retrimitere in service;

Jurnal de receptie din service;

Jurnal de notificare client sa vina sa-si ridice telefonul reparat (si sa predea eventual si telefonul de SWAP) .

In cazul in care un proces de SAV este anulat in Sistemul Retail, in Vantive se genereaza doar un jurnal de retur telefon la client, specificandu-se netrimiterea acestuia in service .

Iesiri catre eService

Catre aplicatia eService sunt transmise informatiile legate de procesele verbale incheiate in Sistemul Retail:

• clientul;
• produsul (tip, serie, baterie, incarcator, etc . );
• defectul reclamat de client;
• defectul constatat de vanzator;
• data receptiei;
• numarul procesului verbal emis din Sistemul Retail;
• numarul facturii de achizitie a terminalului (se accepta si facturi de la dealeri);
• data facturii de achizitie;
• vanzatorul care a facut preluarea terminalului defect;
• magazinul de la care s-a facut colectarea defectului;
• etc .

Exportul din Sistemul Retail va aduce in aplicatia eService PV-urile trimise catre Orange Service Center (la fel ca in sistemul actual descris mai sus) .

Iesiri catre Registrul de Casa

Lista vanzatori si plati zilnice

Sistemul Retail va pune la dispozitia sistemului Registrul de Casa Orange urmatoarele informatii:

• lista vanzatorilor organizati pe magazine
• id unic utilizator
• cod utilizator
• nume utilizator
• magazin (cod jupiter magazin)
• lista platilor zilnice cu numerar la nivel de vanzator
• magazin
• ziua
• id unic utilizator
• valoare

Iesiri catre URS (Unified Report System)

Loializari si schimburi de sim

Sistemul Retail va trebui sa ofere pentru sistemul de raportare (URS) informatii referitoare la:

• loializari inregistrate prin Sistemul Retail
• data facturii de loializare
• cod produs
• denumire produs
• serie produs
• subscriber loializat
• dealer
• etc
• schimburi de sim inregistrate in Sistemul Retail
• data schimbului de sim
• magazinul
• nr . de telefon pentru care s-a facut schimbul de sim
• seria simului vechi (defect)
• seria simului nou
• modalitatea de plata
• motivul schimbarii simului

Iesiri catre Casa electronica de marcat

Bonuri fiscale

Sistemul Retail va trebui sa comunice cu Casa Electronica de Marcat in vederea emiterii de bonuri fiscale .

Procesul de emitere de bonuri fiscale trebuie sa fie la finalul unei operatiuni de vanzare de produse/servicii, vanzare care trebuie sa poata fi facuta cat mai rapid, fara inregistrarea neaparata a datelor clientului (pe bonul fiscal nu apar datele clientului) .

Cu bon fiscal trebuie sa se poata vinde urmatoarele tipuri de produse:

• pachete PrePay

• scratch-uri
• accesorii
• eVouchere
• eTopUp
• servicii
• taxe
• produse promotionale
• etc

Pe bonul fiscal trebuie sa se poata tipari urmatoarele informatii:

• vanzator
• magazin
• produs – denumire
• reduceri comerciale
• cantitate
• valoare
• serie produs
• mod plata (carte credit/numerar)
• nr . chitanta (in cazul platii cu carte de credit)
• TVA si cota TVA
• etc

Iesiri catre sistemul eVouchers

Lista vanzatori si info magazine

Sistemul Retail trebuie sa puna la dispozitia sistemului eVouchers urmatoarele informatii:

• lista vanzatorilor din fiecare magazin (cod, nume, etc)
• informatii legate de magazin (adresa – pentru tiparire pe eVoucher, cod jupiter, etc)

Detalii de interfata

Interfata Sistemului Retail va fi asemanatoare cu alte aplicatii folosite in Retail (Vantive, ePOS, etc . )

Va exista o zona de “Favorites” accesibila facil in care utilizatorul sa stocheze cele mai folosite operatiuni ale sale .

Anumite operatiuni (specificate ulterior) vor suporta optiunea de “Undo”, dar numai inainte de finalizare . Sistemul de Undo va fi organizat in pasi, depinzand de locul in care se face undo si de operatiune .

Vanzatorul trebuie sa aiba acces usor la toate operatiunile pe care clientul doreste sa le efectueze in magazin (vezi si anexele cu sugestiile de interfata - schite) .

Facturile vor avea si un sistem de drafting: o vanzare poate sa nu fie finalizata (de ex . clientul isi da seama ca a uitat acasa o parte din bani), in acest caz salvandu-se o vanzare partiala . Aceasta vanzare partiala (un draft al unei vanzari) este salvat si este accesibil vanzatorului din ecranul principal, pentru a fi inchis (transformat intr-o factura tiparita) . Draft-urile sunt anulate la sfarsitul unei zile, iar produsele repuse pe stoc . Vanzatorul sau un utilizator de nivel superior are dreptul de a anula un astfel de draft . Produsele ce apartin unui Draft sunt “rezervate” si mutate intr-o magazie speciala, de produse asociate unui Draft .

Prin crearea unui Draft se poate face o impartire a procesului de vanzare in facturare si incasare, iar factura ca exemplar fizic va aparea numai la finalizara vanzarii (la inchiderea unui Draft) .

SHAPE * MERGEFORMAT

Client:

Nume:

Prenume:

Nr . tel . :

Detalii

ADD

EDIT

DELETE

Detalii de implementare - Figura SEQ Figura * ARABIC - Interfata de Facturare

SHAPE * MERGEFORMAT

Are Nr . Orange: Nu are Nr . Orange: CNP Nume

(MSISDN)

Cauta!

Rezultate:

Clienti:

Nume Nr .

Detalii Client:

CNP:

Nume:

Adresa:

Selecteaza

Inchide

Info . Generale

Istoric Client

Istoric Abonament

Istoric Vizite

Istoric

Istoric retail Data Operatiunea Valoare

Detalii de implementare - Figura SEQ Figura * ARABIC - Selectia unui client