Creeaza.com - informatii profesionale despre


Simplitatea lucrurilor complicate - Referate profesionale unice
Acasa » afaceri » economie
SPECIFICATII FUNCTIONALE SISTEM RETAIL

SPECIFICATII FUNCTIONALE SISTEM RETAIL


SPECIFICATII FUNCTIONALE

SISTEM RETAIL

Definitie

Gestiunea proceselor din magazinele Orange

Sistemul Retail va fi folosit in reteaua de magazine proprii ale Orange Romania pentru gestiunea proceselor ce se desfasoara in magazine . Acestea includ efectuarea vanzarilor de produse, intretinerea si monitorizarea stocurilor, gestiunea clientilor si asigurarea suportului in cazul defectarii sau necesitatii schimbarii diverselor produse puse in vanzare in aceste magazine, precum si multe alte procese si activitati .



Sistemul preia date introduse manual de utilizatori sau importate din sisteme externe, gestioneaza procesele din magazin, emite documentele ce le insotesc si pune la dispozitie datele rezultate pentru analize, verificari si pentru export catre alte sisteme .

Feedback al proceselor din magazin

Sistemul Retail se va constitui intr-un instrument de eficientizare a activitatii din magazinele Orange, atat prin usurarea efectuarii actiunilor din magazin (vanzari, schimburi, SAV, etc) cat si prin oferirea unor mecanisme de analiza a informatiilor rezultate de pe urma acestor activitati (informatii ce se vor constitui intr-un feedback pentru a optimiza procesele ce se desfasoara in magazine) .

Situatie existenta

In momentul de fata, pentru gestiunea activitatii magazinelor proprii Orange Romania se foloseste aplicatia eShop, dezvoltata in tehnologia Oracle Developer (versiunea 6i) cu baze de date Oracle (versiuni 8 . 0 . 5, 8i si 9i) .

Cate o baza de date pentru fiecare magazin

Sistemul este conceput cu cate o baza de date pentru fiecare magazin (fiecare baza de date pe serverul propriu) si o baza de date centrala pe care se transfera periodic (in fiecare noapte sau la cerere, printr-un proces numit Sincronizare) datele de pe fiecare baza de magazin .

Procesul de sincronizare

Anumite informatii care sunt comune tuturor magazinelor (de exemplu nomenclatorul de produse, preturi, oferte, etc) se introduc o singura data pe baza de date centrala, dupa care se transfera prin procesul de sincronizare pe toate bazele de date de magazin .

In sens invers (dinspre bazele de magazin catre baza de date centrala) se transfera periodic (automat in fiecare noapte) datele relevante specifice activitatii fiecarui magazin (facturi, clienti, proforme, schimburi de sim, tranzactii, stocuri, etc), care devin apoi disponibile pentru consultare pe baza de date centrala . Din cauza acestei arhitecturi, datele referitoare la vanzarile dintr-o anumita zi de la un anume magazin sunt disponibile pentru raportare si comparatie cu alte magazine abia incepand cu ziua urmatoare .

Sincronizarea stocurilor

Un caz particular al procesului de sincronizare este procesul de aducere periodica a informatiei referitoare la stocuri de pe toate magazinele pe magazinul central . Acest proces se ruleaza automat o data pe ora, in intervalul 7 – 19, in fiecare zi . In acest fel, pe baza de date centrala exista (cu aproximatie de maxim o ora) informatia referitoare la stocurile fiecarui magazin, pentru consultare prin aplicatia Help Line (aplicatie prin care se poate verifica prezenta in stocurile magazinelor a unui anume produs, preturile la care acesta este disponibil spre vanzare in functie de oferta aleasa la vanzare, precum si rezervarile efectuate in magazinele din tara) .

Arhitectura

SHAPE * MERGEFORMAT

In momentul de fata exista 43 de magazine in tara (plus inca 2 Corporate Business Center si un Orange Studio – servicii Internet), fiecare cu propria baza de date . Aceasta structura se va extinde in viitorul apropiat, ajungand sa depaseasca 50 de magazine .

Definitii

Vantive

Software utilizat de Orange Romania pentru administrarea relatiei cu clientii existenti (este sistemul Customer Relationship Management – CRM utilizat de Orange Romania)

ePOS

Electronic Point of Sales . ePOS este o aplicatie care asigura comunicarea in timp real a detaliilor din contractele incheiate de partenerii Orange catre sistemele care asigura serviciile de telecomunicatii, cel de facturare si CRM .

CRM

Customer Relationship Management, este un ansamblu de aplicatii si sisteme care usureaza relatia dintre Serviciul Clienti si client, prin colectarea si gestiunea tuturor informatiilor legate de acesta, automatizarea unor procese de business sau asigurarea accesului direct al clientului la diverse facilitati de tip Customer Service

PREVENTEL

Baza de date comuna intre operatorii de telefonie mobila care contine toti clientii suspendati pe motive de frauda sau neplata .

Serviciu/Produs PrePay

Serviciu/Produs preplatit (fara abonament, fara factura) . Din aceasta categorie fac parte:

pachetele PrePay – contin SIM-uri de voce de tip PrePay cu un credit initial si durata de valabilitate;

cartelele de reincarcare (incarcarea cu un anumit credit a unui cont de tip PrePay si prelungirea duratei de valabilitate);

serviciile de reincarcare electronica (eVoucher si eTopUp) .

eVoucher

Serviciu de reincarcare a unui cont PrePay cu o suma variabila (33 de valori prestabilite) . Reincarcarea contului se face prin apelarea serviciului reincarcare (222) si introducerea unui cod tiparit de bonul emis de sistemul eVoucher .

eTopUp

Serviciu de reincarcare a unui cont PrePay cu o suma variabila (de la 1 la 200€, in trepte de cate un euro) . Reincarcarea se face la emiterea bonului de catre aplicatia eTopUp, fara a mai fi nevoie de introducerea vreunui cod de catre client . Confirmarea operatiunii de reincarcare a creditului se face printr-un SMS trimis de catre sistemul de reincarcare clientului beneficiar al serviciului .

Client

Clientul este entitatea centrala din Sistemul Retail . Acesta este implicat in aproape toate procesele din sistem, este beneficiarul majoritatii operatiunilor realizate prin intermediul Sistemului Retail (vanzare, schimburi, cesiuni, etc) . Clientii pot fi catalogati in functie de interactiune lor cu compania, dupa cum urmeaza:

clienti PrePay – sunt clientii ce achizitioneaza produse si servicii de tip PrePay;

clienti PostPay – sunt clientii ce au incheiat abonamente la Orange Romania;

clienti obisnuiti – clienti ce cumpara diverse produse la liber, fara fi achizitionat vreodata produse PrePay si fara a fi abonati Orange Romania SA .

Factura

O factura reprezinta multimea datelor asociate unui si rezultate dintr-un proces de vanzare in magazin . Facturile reprezinta vanzari nominale - pentru a putea fi emisa o factura fiind necesare datele clientului . In urma procesului de vanzare se tipareste un document de factura propriu-zisa pe care se vor evidentia toate produsele, serviciile, taxele si discounturile operate clientului prin procesul de vanzare si tot pe acest document, daca este cazul este afisata si chitanta in baza careia se face plata .

Proforma

Proformele sunt documente emise in vederea unei plati prin banca, in baza carora se poate finaliza o vanzare . Sunt o imagine a facturii finale, inmanata clientului in avans .

Bon Fiscal

Bonurile fiscale (bonuri de casa) sunt documente justificative de incasare numerar, emise de o casa de marcat, controlata de aplicatie direct sau prin intermediul unui driver . Au un comportament similar unei vanzari cu factura (reprezinta tot o vanzare) dar nu suporta vanzare in regim de oferta, nu permit vanzarea de telefoane, nu permit decat acordarea anumitor discounturi (fie globale, la nivel de bon, fie la nivel de produs pe bon), nu necesita specificarea unui client drept cumparator .

Produs/serviciu

Produsul este obiectul vanzarii si conform politicii Sistemului Retail se afla in centrul acestui proces . Prin produse se inteleg:

Handset-urile;

Accesoriile;

Pachetele PrePay;

Cartelele de reincarcare;

SIM-urile (atat cele PrePay cat si cele PostPay);

Produsele promotionale (tricouri, genti, etc . );

Taxele;

Serviciile de reincarcare (eVouchere);

Serviciile de reincarcare directa (eTopUp);

alte tipuri de produse/servicii .

Pret

Pretul defineste valoarea la vanzare a unui anume produs/serviciu . Preturile sunt mereu asociate unui produs, putem avea un produs cu mai multe preturi dar nu si un pret asociat mai multor produse, si nici sa avem un pret fara un produs asociat .

Discount

Discountul este o reducere ce afecteaza pretul final al unui produs/serviciu/taxa achitat de client .

Plan Tarifar

Planurile tarifare reprezinta tipurile de abonamente oferite de Orange Romania . Fiecare plan tarifar are asociata o lista de optiuni dintre care clientul, in momentul semnarii contractului de abonament, sau ulterior, poate alege variante, in functie de o matrice de compatibilitate intre optiuni .

Oferta

Oferta reprezinta o combinatie produs, pret, discount . Ofertele determina pretul final la care un client poate achizitiona un produs aflat in vanzare in magazinele Orange .

TVA

Taxa pe Valoarea Adaugata . Sistemul Retail trebuie sa permita co-existenta mai multor valori pentru TVA, dintre care unul singur este cel implicit . Un TVA poate fi sau nu valid, dar cel implicit nu poate fi invalid .

Curs valutar

Reprezinta rata de schimb pentru valuta sau valutele in care sunt exprimate preturile din aplicatie .

Stoc

Stocul contine toate produsele ce pot fi achizitionate de clienti (inclusiv unele produse promotionale) si care sunt prezente in gestiunea magazinului .

Tranzactie

Tranzactia reprezinta o inregistrare a detaliilor unui transfer de marfa in una din urmatoarele situatii:

intre gestiunile magazinelor;

in cadrul gestiunii unui magazin;

transferuri catre WAREHOUSE;

receptii de marfa de la WAREHOUSE;

transferuri catre Service;

receptii din Service;

transferuri pe gestiunea clientului (produse in custodia clientului);

receptii din gestiunea clientului;

Utilizator

Utilizatorul reprezinta orice persoana ce interactioneaza cu Sistemul Retail, interactiune care se face intr-o maniera controlata de drepturile de acces . Fiecare utilizator are asociat un nivel de acces la aplicatie . Utilizatorii trebuie sa fie unic identificabili din punct de vedere al interactiunii lor cu Sistemul Retail .

Magazin

Magazinul este un punct de desfacere si prezentare a serviciilor si produselor oferite de Orange Romania .

SR

Sales Representative . Este un vanzator la punct fix de desfacere, apartine unui magazin si activitatea si-o desfasoara numai in incinta acelui magazin .

BSR

Bussiness Sales Representative . Este un vanzator mobil, se ocupa cu clientii corporate si business, si care din punct de vedere organizatoric apartine de un anume magazin .

Comanda electronica

Comanda este un formular in format electronic trimis de catre magazine catre WAREHOUSE prin care se cere alimentarea gestiunii cu produse .

WAREHOUSE

Depozitul Central . Se foloseste si cu sensul de subinventar in Oracle Applications .

Handset

Telefon de pe gestiune, folosit atat pentru vanzare cat si pentru schimburile de defecte, trimiterile in service, SWAP-uri, orice implica manupularea unui telefon prin intermediul sistemului Retail

Serie IMEI

International Mobile station Equipment Identity . Seria unui Handset, ce il identifica unic .

MSISDN

Mobile Station ISDN Number - numarul de telefon al abonatului .

Serviciu

Servicii oferite de companie: servicii de reincarcare pentru pachetele PrePay, servicii de operatii service in afara garantiei .

SAV

Service Apres Vente . Servicii de service in perioada de garantie .

PV

Proces Verbal . Document ce autentifica un acord semnat intre doua parti, in speta intre client si reprezentatul Orange Romania SA . Procese verbale se incheie in Sistemul Retail in cazul:

SAV-urilor – la preluarea si predarea din custodie a unui telefon de SWAP, la predarea telefonului defect in service si la receptia telefonului reparat;

Preluarii si predarii din custodia clientului a unui produs cu contract de comodat;

etc .

AIM

Aviz de insotire a marfii . Document folosit la transferul produselor, de la WAREHOUSE la magazin, intre magazine, catre service, etc .

OA

Oracle Applications .

NIR

Nota Interna de Receptie . Document folosit la receptionarea manuala a unor produse, in cazul in care OA este inaccesibil pentru a se face importul AIM-ului .

SWAP

Telefon de schimb . Este oferit clientilor pe perioada in care telefonul defect este in service .

Entitati

In activitatea desfasurata in magazinele Orange se pot identifica urmatoarele entitati (actiuni, formulare, clienti, produse etc . ) ce interactioneaza pentru a oferi functionalitati specifice sau pentru a descrie concepte compuse . Entitatile pot fi impartite, in functie de orientarea acestora, in doua categorii:

interne

externe .

Entitatile interne sunt cele ce iau nastere in interiorul aplicatiei si abia apoi sunt si materializate pe un suport fizic (formulare, rapoarte, contracte, etc . ) .

Entitatile externe sunt cele ce descriu obiecte din realitate ce sunt introduse in sistem (clienti, produse, magazine, etc . ) .

Lista a entitatilor cu care opereaza Sistemul Retail:

client

factura (vanzare)

proforma;

bon fiscal;

produs;

pret;

discount

oferta

stoc

utilizator

tranzactie

magazin

plan tarifar

TVA

curs valutar

etc

Entitatea Client

Clientul este entitatea centrala din Sistemul Retail . Acesta este implicat in aproape toate procesele din sistem, este beneficiarul majoritatii operatiunilor realizate prin intermediul Sistemului Retail (vanzare, schimburi, cesiuni, etc) . Orice proces de vanzare incepe cu selectia unui client . Aproape orice proces din Sistemul Retail incepe cu selectia clientului (in afara de transferurile de marfa sau bonurile de casa cu plata cash) .

Atribute ale entitatii

Dintre atributele asociate acestei entitati enumeram:

nume;

prenume;

adresa (freetext importat din Vantive, dar cu detalii de tara, judet si oras separate, sau structurat, prin impartire la nivel de strada, numar, bloc, scara, etc . in cazul in care clientul este intretinut intern in Sistemul Retail);

tip client (juridic/fizic);

forma de organizare in cazul persoanelor juridice: PFA, SA, SRL, ONG, etc) (tipul de persoana juridica este intretinut numai intern, nu se poate aduce din Vantive deocamdata);

cod postal (optional);

numar de telefon de contact/numar de fax de contact fix (nu al persoanei de contact);

numar de telefon de contact/numar de fax de contact mobil (nu al persoanei de contact);

adresa mail;

cod fiscal sau CNP;

data nasterii;

banca si contul in cazul in care clientul este o persoana juridica - nu mai sunt obligatorii (dar daca se cunosc, nu strica sa fie completate);

tip act identitate (pentru persoane straine poate fi pasaport );

numarul de contract;

data incheierii contractului pentru fiecare subscriber;

MSISDN (numar de telefon al subscriberului);

numar client (customer number – din Vantive);

lista cu numele si prenumele persoanelor de contact si eventual un numar de telefon fix/mobil al persoanei de contact (poate fi o singura persoana de contact);

un istoric de client (intern – stabilit din log-ruile Sistemului Retail):

o      in ce magazin a facut achizitiile si a incheiat contractele;

o      numarul de schimburi de SIM si datele schimbarilor;

o      numarul de schimburi de defect;

o      numarul de operari in service, de schimburi de SIM (PrePay/PostPay), de schimburi de defect;

o      etc .

un istoric de client (extern – importat din Vantive)

o      perioadele contractuale pentru fiecare contract;

o      perioadele contractuale pentru fiecare prelungire de contract;

o      consumul mediu/maxim, detalii legate de facturile precedente, de convorbiri, atat in retea, cat si in afara ei, etc;

o      ultima factura;

o      etc .

tipul de abonament (planul tarifar);

optiunile si serviciile atasate abonamentului;

etc . (orice alte atribute ce ar putea fi folosite in evolutia viitoare)

Intretinere Clienti

Clientii vor fi inregistrati in Sistemul Retail in urmatoarele moduri:

import din EPOS la cerere (pentru clientii noi, care inca nu sunt inregistrati in CRM) – importul de client noi va fi validat, astfel incat sa nu fie incarcate in Sistemul Retail date eronate;

import din CRM la cerere (in cazul in care un client se importa din Vantive, este adus clientul cu totul, cu informatii despre toti subscriberii sai si este actualizat in Sistemul Retail . Informatiile aflate in Vantive sunt prioritare fata de informatiile aflate in Sistemul Retail . La momentul importarii unui client din Vantive, daca acesta exista deja in Sisteml Retail, informatiile acestuia vor fi suprascrise de cele existente in Vantive);

manual din Sistemul Retail - pentru clientii care nu au abonament Orange, si deci nu figureaza in Vantive sau EPOS (in cazul in care se va introduce pe viitor obligativitatea inregistrarii de informatii in legatura cu utilizatorii PrePay, aceste informatii vor trebui ulterior integrate in Sistem intr-un mod analog informatiilor legate de clienti PostPay);

La importul din Vantive al listei de subscriberi asociati customerului, se vor aduce urmatoarele informatii:

- MSISDN;

- nume utilizator;

- data nasterii;

- agreement date;

- data ultimei fidelizari;

- detalii legate de abonamentul curent, de subscriberi, de change-urile relevante din Vantive din ultima perioada, etc;

La primul import sau prima inserare manuala se va marca la nivel de subscriber data aparitiei in Sistem, pentru a se putea stabili vechimea in sistem .

Forma de organizare a clientului nu poate fi importata din Vantive, ea fiind inclusa in numele clientului . Din ePOS aceasta poate fi importata in mod distinct . La completarea manuala a unui client nou in Sistemul Retail (in cazul in care clientul este un client de servicii PrePay sau este un client ce cumpara accesorii, fara sa fie nici macar un client de servicii PrePay), categoria din care face sa fie completata manual de catre utilizator .

In ePOS exista o lista de astfel de categorisiri (forme de organizare): aceasta fie se poate importa in Sistemul Retail, fie se poate mentine manual de catre un utilizator autorizat .

Forma de organizare a clientului poate indica si cota de TVA care ii va fi asociata in cazul unei facturari (cota TVA asociata la nivelul facturii) .

Din Vantive numele si prenumele se importa pe un singur camp, pe cand din ePOS, sau in cazul in care clientul este introdus manual in Sistemul Retail, poate avea completat numele in mod separat (nume si prenume) .

In cazul in care codul fiscal sau CNP-ul nu au putut fi validate, sa fie emisa o notificare (fie un mesaj, fie un mail, sau ambele) si va exista posibilitatea de a forta introducerea in sistem a unot astfel de coduri (se poate intampla sa fie emise eronat de organele raspunzatoare) . Validarea acestor coduri va fi facuta si in functie de forma de organizare a firmei (in cazul codului fiscal) .

In cazul in care se va introduce pe viitor obligativitatea inregistrarii de informatii in legatura cu utilizatorii PrePay, aceste informatii vor trebui ulterior integrate in Sistem intr-un mod analog informatiilor legate de clienti PostPay .

Sistemul va asocia o lista de persoane de contact pentru fiecare client . Din Vantive poate fi adusa o singura persoana de contact, restul sunt introduse manual in Sistem . Informatiile relevante pentru personanele de contact sunt : numar telefon, cnp/cod fiscal, nume . O persoana de contact ale clientului trebuie asociata fiecarei facturi emise (daca aceasta nu se afla printre persoanele de contact existente, trebuie adaugata)

Se va mentine un istoric la nivel de clienti (un client cu contract reziliat nu dispare din sistem, ci este doar marcat corespunzator) si la nivel de subscriptie (istoric al operatiunilor interne Sistemului si al operatiunilor efectuate in sistemele externe) .

Istoricul operatiunilor efectuate prin Sistemul Retail de clientul respectiv (inclusiv la nivel de subscriber) va contine:

- vanzarile

- schimburile de SIM (PrePay)

- schimburile de defect

- operatiuni SAV

Informatia din isoricul operatiunilor interne Sistemului Retail va fi disponibila in timp real . Informatia din istoric va contine si referinta magazinului la care s-a efectuat operatiunea, pentru a putea oferi o imagine a operatiunilor in cadrul unui anume magazin .

Sistemul va pastra si o lista a schimbarilor efectuate de-a lungul timpului (schimbari ce afecteaza numele, MSISDN-ul, codul fiscal sau CNP-ul, adresa, etc . ), care va fi corelata cu istoricul operatiunilor descris mai sus .

Sistemul va permite cautarea in acest istoric dupa oricare din campurile clientului definite mai sus (MSISDN, nume, CNP, etc) . In acest mod, se va putea efectua, de exemplu, o cautare a tuturor operatiunilor asociate unei anume adrese (chiar daca este vorba despre clienti diferiti) .

Va fi definita o lista de factori de calitate pentru clienti . Lista va fi dinamica, in sensul ca va permite adaugarea unor noi factori de calitate pentru client, impreuna cu definirea detaliilor legate de acestea . Un factor de calitate ar putea fi actualizat odata cu urmatoarele operatiuni: vanzari, vizite, operatiuni SAV, etc . Se vor defini functii pe care utilizatorii le pot alege in calculul factorului de calitate (suma, medie, count, etc . ) . Se va alege o politica de resetare a factorilor de calitate pentru fiecare factor in parte . Un exemplu de factor de calitate al clientului este valoare facturii de serviciii pe ultima luna, sau data ultimei fidelizari (sa fie aceasta data de ex . mai veche de 2 ani de zile . ) .

Clasificare

Clientii inregistrati in Sistemul Retail sunt fie clienti PostPay (cu abonament), fie clienti de PrePay, fie clienti care nu sunt abonati Orange . In cazul clientilor PostPay, se specifica tipul abonamentului (planul tarifar) si optiunile activate ale abonamentului . Fiecare client cu abonament are asociata o lista de subscriberi (numerele pentru care acesta are abonamente) .

Clientii sunt importati din sistemele Vantive sau ePOS (in cazul celor PostPay) sau introdusi manual (in cazul celorlalti clienti sau in cazul in care nu exista acces la sistemele externe) .

Fiecare client va avea asociate informatii legate de abonamentul si de activitatea sa in cadrul contractului cu Orange, iar Sistemul Retail va folosi aceste informatii pentru a face sugestii in legatura cu cea mai avantajoasa oferta de achizitie a unui nou terminal (de exemplu unui client care are mai multe abonamente i se poate sugera folosirea punctelor Thank You corespunzatoare unuia din abonamente sau o oferta de fidelizare disponibila pentru un alt abonament) .

Sistemul Retail va putea permite accesul la discounturi sau oferte in functie de anumite informatii legate de client . Informatiile pot fi de urmatoarele tipuri:

informatii de billing (tipul abonamentului, valoarea convorbirilor, informatii legate de plata facturii, optiunile activate sau dezactivate de-a lungul timpului, etc) – obtinute prin import din Vantive;

operatiunile in service (de cate ori a dus un terminal in service, de cate ori i s-a schimbat terminalul, etc);

de facturare in Sistemul Retail (valoarea achizitiilor, tipul de produs sau terminal achizitionat, periodicitatea, modalitatea de plata, etc);

detaliile de client (locuinta – daca se poate sugera o casierie mai apropiata de casa; tipul de client – fizic sau juridic; informatii PREVENTEL, etc) .

alte informatii

Selectia unui client

Cautarea clientilor se va face in principal dupa:

numar de telefon (MSISDN) – acest client va fi cautat in ePOS (daca e vorba de un subscriber nou sau este la primul abonament) sau in Vantive (daca este un client existent);

numarul de contract EPOS (in cazul in care este un abonament nou, informatiile inca nu exista in Vantive);

CNP/Cod Fiscal sau nume, pentru clientii care nu au abonament Orange si nu pot fi gasiti nici in Vantive nici in EPOS . In acest caz, sistemul trebuie sa permita (in masura in care acest lucru se poate realiza in timp real) afisarea unor liste dinamice, afisand automat pentru selectie clientii care corespund cu primele caractere tastate de utilizator (eventual sa fie un numar minim de caractere completate in campurile de cautare) .

Detalii de interfata cu utilizatorul

Adresa clientului va fi introdusa printr-o macheta separata, ce contine:

- lista de judete;

- lista de orase (populata in functie de judetul selectat - trebuie selectat un judet);

- lista de sectoare (daca e Bucurestiul selectat);

- lista de tipuri de adresa (strada, bulevard, sosea, etc) .

Restul campurilor (strada, numar, etc) vor fi completate in campuri free text (nu vor fi liste de valori) .

Unele detalii de client vor fi stocate dar nu si neaparat vizibile nefiind folositoare la modul direct pentru utilizator, insa vor putea fi folosite ca si parametri interni de catre sistem . Pentru client se vor stoca informatii precum: planul tarifar curent, serviciile si optiunile active .

Informatiile disponibile prin interfata se impart in: Informatii primare (vizibile primele in interfata) si informatii secundare ca importanta (accesibile prin operatiuni suplimentare – click pe un buton de “Details ” de ex . )

Concluzie

Clientii sunt entitati carora li se adreseaza facturarea, sunt beneficiarii produselor, cei ce fac plata catre Orange Romania . Cientii PrePay au asociate detalii mai restranse (au doar o cartela PrePay), cei PostPay au asociate detalii extinse de abonament, un istoric de activitate, aceste date fiind importate din sistemul CRM (Vantive) si sincronizate cu Sistemul Retail fie periodic, fie la cerere (de exemplu in momentul vanzarii – pentru ca Sistemul Retail sa ofere vanzatorului toate detaliile necesare pentru ca sa se efectueze vanzarea) .

Legaturi cu alte entitati

SHAPE * MERGEFORMAT

Factura

Client

nume, adresa, tip,

Proforma

PV SAV

Pret

Discount

Magazin

Abonament

Sistemul va asigura o scalabilitate si flexibilitate in manipularea informatiilor (atributelor) entitatii si va permite operatii de adaugare / modificare / stergere / clasificare / intervale de timp (prin calendare) / valabilitate . Din acest motiv sistemul va asigura un configurator propriu pentru toate categoriile de entitati enumerate .

Entitatea Factura (Vanzare)

O factura reprezinta multimea datelor asociate unui si rezultate dintr-un proces de vanzare in magazin . Facturile reprezinta vanzari nominale - pentru a putea fi emisa o factura fiind necesare datele clientului . In urma procesului de vanzare se tipareste un document de factura propriu-zisa pe care se vor evidentia toate produsele, serviciile, taxele si discounturile operate clientului prin procesul de vanzare .

Atribute ale entitatii

Informatiile cele mai importante ce compun entitatea factura sunt:

produsul:

o      serie;

o      identificator produs;

o      model;

o      brand;

o      tip;

o      valoarea (pretul initial);

o      cantitate (daca nu este produs cu serie);

discountul:

o      valoare;

o      tipul;

legatura (daca exista) intre discount si produs;

seria facturii;

data emiterii (la nivel de secunde);

magazinul emitent;

numarul chitantei - numai daca factura este achitata numerar si nu in baza unui bon de casa;

seria proformei;

identificarea ordinului de plata:

o      seria;

o      data;

o      valoare;

datele de storno:

o      factura initiala stornata;

o      data facturii stornate;

o      suma este restituita clientului: numerar sau prin banca (dispozitie de plata sau ordin de plata);

o      refacturare (dupa caz): daca se refactureaza si factura initiala este platita prin ordin de plata sau carte de credit, atunci se pot folosi aceleasi serii de document (depinde de modul in care se efectueaza stornarea: cash sau prin banca); daca nu se face refacturare si vanzatorul are bani in casa, i se plateste clientului suma trecuta pe dispozitia de plata (in cazul in care se face stornarea in baza unei dispozitii de plata, altfel clientului ii este realimentat contul din banca de unde a efectuat plata initiala – prin OP sau CC);

clientul:

o      client implicat intr-o vanzare de tip PostPay:

cod client;

subscriberul catre care se face vanzarea;

nume client;

adresa client;

cod fiscal sau CNP;

banca si contul bancar (pentru persoane juridice);

numar de telefon de contact;

numarul de contract;

data semnarii contractului;

tipul de prelungire a contractului (daca este cazul: fara prelungire, prelungire pe 12 luni, prelungire pe 24 luni);

o      nu este client implicat intr-o vanzare de tip PostPay:

nume client;

adresa client;

cod fiscal sau CNP;

banca si contul bancar (pentru persoane juridice);

numar de telefon de contact;

vanzatorul care a incheiat factura (identificatorul sau);

valoarea facturii:

o      in valuta fara TVA – nu va fi tiparita pe factura;

o      in valuta TVA – nu va fi tiparita pe factura;

o      in lei fara TVA;

o      in lei TVA;

o      in lei cu TVA (total factura);

valuta in care este exprimat pretul produsului achizitionat;

cursul valutar folosit (valoarea sa si data);

modul de plata (sau tipul de vanzare):

o      numerar;

o      carte de credit;

o      ordin de plata;

o      compensare (nu se raporteaza la nivel de registru de casa) - folosita in relatiile cu partenerii Orange sau subcontractantii;

o      factura in baza unui bon de casa;

o      plata la termen;

tipul de factura:

o      facturare normala;

o      factura storno (totala/partiala);

o      factura pentru bon;

o      factura de corectie;

valoarea TVA-ului folosit in calcule;

daca produsul ce apare in vanzare se tipaseste sau nu pe factura (de ex . SIM-urile nu apar pe factura, dar sunt incluse in procesul de vanzare);

oferta la care s-a facut vanzarea .

identificator unic la nivel de factura si la nivel de exemplar tiparit, care sa permita identificarea momentului si utilizatorului care a facut aceasta tiparire;

elemente de identificare pentru serviciul de reancarcare folosit sau deviz eservice in baza caruia se face facturarea;

etc .

Clasificare

Facturile pot fi de trei tipuri:

normale;

storne;

anulate .

Nota

Anularea unei facturi se poate face doar in aceeasi zi in care a avut loc vanzarea . Stornarea poate sa se lege de orice factura emisa din magazin, indiferent de data emiterii acesteia . Se poate storna orice factura, emisa in orice magazin .

Mod de plata

In functie de modul de plata, facturile pot fi achitate cu: document justificativ de plata cu Carte de Credit, document justificativ de achitare a unui Ordin de Plata, numerar, sau pot fi facturi de compensare (intern, pentru clienti ce emit la randul lor facturi catre Orange Romania) .

Gestiune formulare pretiparite

Factura va fi tiparita in intregime din Sistemul Retail pe o foaie normala A4 . Seria unica pentru fiecare exemplar va fi intern generata de catre Sistemul Retail, dar aceste serii vor corespunde cu o plaja stabilita de Departamentul Contabilitate .

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

  • factura tiparita are asociate intotdeauna 2 formulare (folosind ambele aceleasi serie) – putandu-se insa tipari in oricate exmeplare, dar sa fie mai mult de doua;
  • seria care se tipareste pe facturi trebuie sa fie garantat unica (nu poate exista o serie asociata mai multor facturi – ci doar mai multor exeplare tiparite);
  • orice factura trebuie sa fie unic identificabila dupa seria oricaruia dintre exemplarele tiparite (in plus, fiecare exemplar tiparit va avea un cod unic de identificare) .

Fisa de magazie – formulare pretiparite

Sistemul Retail va permite de asemenea tiparirea unei “fise de magazie” prin care se evidentiaza scopul pentru care a fost folosita fiecare serie (factura care a fost tiparita pe acele exemplare, motivul anularii daca e cazul, etc) . Vezi capitolul Gestiune Documente .

Legaturi cu alte entitati

SHAPE * MERGEFORMAT

Produs

Factura

id, data, client, produse,

Pret

Client

Proforma

Stoc

Tranzactie

Discount

Utilizator

Magazin

Bon fiscal

Sistemul va asigura o scalabilitate si flexibilitate in manupularea informatiilor (atributelor) entitatii si va permite operatii de adaugare / modificare / stergere / clasificare / intervale de timp (prin calendare) / valabilitate . Din acest motiv sistemul va asigura un configurator propriu pentru toate categoriile de entitati enumerate .

Entitatea Proforma

Proformele sunt documente emise in vederea unei plati prin banca, in baza carora se poate finaliza o vanzare . Sunt o imagine a facturii finale, exprimata in valuta,inmanata clientului in avans .

Au un comportament si o functionalitate asemanatoare cu cele ale unei facturi (mai tarziu se poate emite o factura in baza unei proforme), dar nu se opereaza destocarea produselor de pe proforma din gestiune, ci doar se face o rezervare a produselor (daca se doreste) . Proforma este numai o nota de calcul a facturii, pe care se listeaza produsele, preturile lor de pornire si discounturile in baza carora se ajunge la valoarea finala a facturii .

Se poate, la nivel de client, face o verificare a inchiderii cu OP a unei proforme . Daca o proforma a expirat si nu a fost inchisa, se poate verifica daca a fost emisa vreo factura cu OP pe acest client si daca este gasit un astfel de client, utilizatorul de nivel Shop Manager este instiintat ca sa verifice ca nu cumva factura respectiva sa nu fie inchiderea de fapt a proformei pomenite initial .

Se va efectua si o verificare a unui OP pentru un client: daca acest OP pentru clientul cu pricina a mai fost folosit, vanzatorul sa fie atentionat (poate alege sa continue vanzare, in cazul in care cu un OP se fac mai multe achizitii pe mai multe facturi) – aceasta verificare are scopul de a preveni falsul din partea unui client (cu acelasi OP sa faca mai multe achizitii, si suma acestora sa depaseasca suma trecuta pe OP) .

Va exista si conceptul de plata cu OP de plata electronica – pentru cei ce fac plati Web (formatul numarului de ordin de plata difera de cel pentru o plata cu OP direct la banca) .

Atribute ale entitatii

Datele ce definesc proforma sunt asemanatoare celor ale facturii, dar furnizeaza in primul rand informatii asupra sumei de plata, si nu asupra detaliilor de vanzare (oferta, serie, contract, etc):

data printarii;

produsul:

o      daca este facuta rezervare, atunci e trecuta si seria;

o      identificator produs;

o      tipul;

o      cantitatea;

o      valoarea (pretul initial)

discountul (la nivel de produs, ca sa se ajunga la pretul final al produsului sau la nivel de factura);

perioada de valabilitate a proformei;

vanzatorul ce emite proforma;

client:

o      nume;

o      adresa;

o      cod fiscal sau CNP;

o      banca si contul (pentru persoane juridice – nefiind insa obligatorii aceste campuri);

o      numarul de telefon de contact;

valoare:

o      valuta fara TVA;

o      valuta TVA;

o      valuta cu TVA;

valuta in care este exprimat pretul produsului;

TVA-ul folosit la calcul;

starea curenta a proformei:

o      expirata (clientul nu a facut plata in decurs de 5 zile);

o      anulata (clietnul s-a razgandit);

o      achitata si avand drept corespondent o factura si identificatorul acestei facturi;

magazinul emitent;

seria proformei;

bancile si conturile in care se poate face plata;

etc .

Rezervare produse

Prin emiterea unei proforme se face sau nu o rezervare a produsului ales de client, si in decurs de maxim 5 zile (perioada maxima de valabilitate a unei proforme – cu posibilitatea de a fi modificata din aplicatie) este pastrat pe stoc . Rezervarea se face la nivel de serie (pentru telefoane si produsele ce au serie) sau la nivel de tip de produs (de exemplu pentru accesorii) .

La rezervarea realizata in urma efectuarii unei proforme sa se mute produsul intr-o magazie de rezervate . Seriile IMEI vor fi sugerate vanzatorului a fi mutate in magazia de rezervate, dar nu el va realiza rezervarea acestora, ci Stock Keeper-ul . Pentru ca produsele se afla oricum pe stocul vanzatorului, nu exista riscul ca un alt vanzator sa le vanda pana in momentul rezervarii lor de catre Stock Keeper .

Vanzarea catre un client a unui produs deja rezervat, de catre un alt client(in baza unei proforme), nu poate fi efectuata decat de catre acelasi utilizator sau de catre un utilizator de nivel superior celui ce a facut rezervarea .

Legaturi cu alte entitati

SHAPE * MERGEFORMAT

Produs

Proforma

id, data, client, produse,

Pret

Client

Factura

Stoc

Discount

Utilizator

Magazin

Sistemul va asigura o scalabilitate si flexibilitate in manupularea informatiilor (atributelor) entitatii si va permite operatii de adaugare / modificare / stergere / clasificare / intervale de timp (prin calendare) / valabilitate . Din acest motiv sistemul va asigura un configurator propriu pentru toate categoriile de entitati enumerate .

Entitatea Bon fiscal

Bonurile fiscale (bonuri de casa) sunt documente justificative reprezentand o vanzare similara cu facturarea dar care are si semnificatia de incasare numerar, emise de o casa de marcat, controlata de aplicatie direct sau prin intermediul unui driver . Au un comportament similar unei vanzari cu factura (reprezinta tot o vanzare) dar nu suporta vanzare in regim de oferta, nu permit vanzarea de telefoane, nu permit decat acordarea anumitor discounturi (fie globale, la nivel de bon, fie la nivel de produs pe bon), nu necesita specificarea unui client drept cumparator .

Atribute

Detaliile cuprinse pe un bon de casa sunt:

numar bon de casa;

produs:

o      cantitate;

o      denumire;

o      serie (daca e cazul);

o      tip, brand;

discount:

o      valoare;

o      asociere (la nivel de bon sau la nivel de produs);

o      identificator discount;

valoare:

o      pret lei fara TVA;

o      pret lei TVA;

o      pret lei cu TVA;

o      pret in valuta fara TVA;

o      pret in valuta TVA;

o      pret in valuta cu TVA;

valuta in care este exprimat pretul produsului sau al discoutului;

vanzatorul care a facut vanzarea pe baza de bon de casa;

data vanzarii (la nivel de secunda);

magazinul emitent .

tip vanzare (cu Carte de Credit sau Cash);

etc .

Vanzarile prin bon de casa pot fi:

prin carte de credit – pe bon apare numarul chitantei cu care s-a facut plata cu Carte de Credit;

numerar .

Vanzarile pe casa de marcat nu pot fi facute in baza unui Ordin de Plata;

Factura pe baza de bon

Sistemul Retail va permite generarea unei facturi pe baza unui bon de casa emis in prealabil . Inchiderea unui bon prin factura se poate face doar pentru bonurile emise in acceasi zi . Daca in baza unui bon de casa de marcat se emite o factura, pe factura nu se mai afiseaza chitanta, ci numai se tipareste numarul bonului de casa si apoi se ataseaza la factura si bonul de casa drept document justificativ . Pentru o factura in baza unui bon de casa nu se mai pot adauga produse sau discounturi . Pretul de pe bonul de casa emis trebuie sa fie acelasi cu cel de pe factura emisa in baza acelui bon si produsele de pe bon trebuie sa se regasesca pe factura si trebuie sa fie identica factura cu bonul in baza caruia este emisa .

Pentru emiterea unui bon fiscal, Sistemul Retail trebuie sa nu pemita accesul vanzatorului la unele produse (de exemplu telefoane) ce nu se pot vinde decat cu factura . Sistemul trebuie sa permita utilizatorilor autorizati sa specifice, la crearea produsului, daca acesta poate fi sau nu vandut cu bon de casa .

Un bon defineste o vanzare cu ajutorul casei de marcat . Detaliile de client nu sunt completate in cazul unui bon fiscal dar, in cazul in care se emite o factura in baza unui bon, atunci acestea trebuie completate . Pentru orice bon de casa se poate emite o factura, cu conditia ca aceasta sa fie emisa in aceeasi zi .

Legaturi cu alte entitati

SHAPE * MERGEFORMAT

Produs

Bon fiscal

nr, data, produse,

Pret

Stoc

Tranzactie

Discount

Utilizator

Magazin

Factura

Sistemul va asigura o scalabilitate si flexibilitate in manupularea informatiilor (atributelor) entitatii si va permite operatii de adaugare / modificare / stergere / clasificare / intervale de timp (prin calendare) / valabilitate . Din acest motiv sistemul va asigura un configurator propriu pentru toate categoriile de entitati enumerate .

Entitatea Produs

Produsul este obiectul vanzarii si conform politicii Sistemului Retail se afla in centrul acestui proces . Pentru produsul ales in cadrul procesului de vanzare Sistemul Retail va afisa variantele de preturi si discounturi disponibile pentru acesta in functie de seturile de conditii definite pentru preturi si discounturi (vezi capitolul Procese si functionalitati ale Sistemului Retail ->Vanzarea) .

Atribute

Entitate definita prin urmatoarele proprietati:

denumire

denumirea comerciala (fara brand – acesta este stocat separat)

brand-ul telefonului

clasificare:

o      tip:

terminal;

accesoriu;

scratch-card;

pachet PrePay;

SIM;

promo;

taxe;

servicii de reincarcare;

servicii de reincarcare directa;

servicii de operare post-garantie;

etc .

o      subtip: terminal mobil, terminal smartphone, terminal PDA, etc . – aceste categorii vor putea fi create dupa necesitati, ficare subtip apartinand unui tip (si accesoriile pot fi casca bluetooth, incarcator, baterie, handsfree, etc);

cod OA;

Fiecare produs sa aibe codul sau de bare, atasat codului OA care-i corespunde;

daca pretul este sau nu exprimat cu TVA;

seria produsului – poate lipsi in cazul produselor fara serie (poate fi citit sau nu cu cititorul de bare);

serie unica (da/nu)

unitatea de masura folosita (implicit completata cu ‘buc . ’);

cod de bare asociat tipului de produs – poate lipsi daca produsul nu necesita recunoastere a tipului prin acest cod sau daca seria sa este unica;

daca este sau nu un produs valid – produsele ce nu se mai comercializeaza sunt pastrate cu valoare istorica dar nu mai sunt valide;

clasa din care face parte: sa se poata astfel stabili o ierarhie de produse, din punct de vedere business: daca un produs inlocuieste un altul (de exemplu Nokia 1100 inlocuit de Nokia 1101);

in functie de clasa valorica:

o      High end;

o      Middle end;

o      Low end;

“phone features”:

o      MMS;

o      GPRS, clasa GPRS;

o      EDGE

o      camera foto;

o      3G;

o      etc .

clasa de compatibilitate a unui produs (cu accesorii sau cu servicii/optiuni)

linia de produs din care face parte, categorie terminal – in corelatie cu alte terminale

pret de cost;

etc

Produsele de tip Promo, flayere, manuale ( OA expence items) nu se vor gestiona nici cantitativ nici valoric in Sistemul Retail . Aceste produse se gestioneaza in OA, prin descarcarea si trecerea lor pe cheltuieli in momentul livrarii catre Shop .

Nu vor exista in aplicatie produse vandabile cu prκt de vanzare 0 . Ele vor avea pret standard si vor avea asociat un discount 100% si asa vor apare si pe factura .

Produsele nevandabile sunt doar cele PRO si nu apar pe factura ci doar pe un PV .

Aceste produse se gestioneaza in OA, prin descarcarea si trecerea lor pe cheltuieli in momentul livrarii catre Shop .

Produsele sa mai aibe si o eticheta de categorie (ex . PRACTIC, MULTIMEDIA ) . Se va defini un nomenclator de etichete si apoi un utilizator autorizat va crea asocierile intre eticheta si produs

Produsul trebuie sa mai contina si o informatie legata de realimentarea stocului din WAREHOUSE (un indicator al faptului ca din depozit se mai fac comenzi pe acest produs, ca se mai intentioneaza sa se achizitioneze) . Produsele pentru care nu se mai fac comenzi de alimentare in WAREHOUSE trebuie sa fie marcate corespunzator .

O parte a acestor proprietati sunt introduse manual:

- clasificarea

- seria unica

- codul de bare

- unitatea de masura

- clasa de compatibilitate, linia de produs

- etc .

Brand-ul poate lipsi in cazul in care accesoriul este general (ex . huse)

Invalidarea automata a unui produs se va produce intr-unul din cazurile:

la un nr . de zile de la utlima aparitie in stocul oricarui magazin (de la iesirea completa din stocul comercial) - numarul de zile este modificabil prin interfata si poate fi diferit de la un produs la altul, insa are o valoare default aceeasi pentru toate produsele;

la aparitia pe stocul comercial, produsul este reactivat automat (daca era invalid) .

Produsul invalid nu mai este vizibil in interfata in mod uzual – decat daca utilizatorul executa operatiuni suplimentare (de exemplu apasa un buton suplimentar “Arata si produsele invalide”) .

Invalidarea/Validarea manuala a unui produs: la validare manuala sistemul va completa automat “ultima aparitie in stoc” cu data validarii, pentru ca procesul automat sa nu-l invalideze la loc decat la expirarea unei noi perioade de validitate .

Unele produse apartin exclusiv Sistemului Retail, ele nu se regasesc in OA iar altele se regasesc in OA doar ca grup, neavand cod individual (ex . reincarcarile sau unele taxe folosite in Orange Studio) .

Stocul retail afisat in interfata de vizualizare produse va contine stocul local (al magazinului curent) precum si stocul disponibil in WAREHOUSE, alocat canalului retail (stocul WAREHOUSE va fi primul in lista de stocuri retail, inaintea stocurilor din magazine) .

Un telefon poate suferi si uzura, in acest caz el fiind transferat intr-un stoc special, de telefoane uzate (foste telefoane de test, aflate in magazia Touch&Try) .

Sistemul Retail ve permite introducerea unor perioade maxime de timp in care un produs ramane netranzactionat si in cazul depasirii acestei perioade sa fie notificat shop manager-ul . Produse tranzactionate inseamna produse vandute, schimbate, transferate extern . Monitorizarea netranzactionarii se va face la nivel de cod de produs (cantitativ) si nu la nivel de serie IMEI .

Ultimul pret de cost cu care un produs este importat in Sistemul Retail din WAREHOUSE este cel ce va fi folosit pe viitor pe AIM-urile si PV-urile de transfer (catre service, catre alt magazin, catre WAREHOUSE) . La un nou import de marfa aceasta valoare se va schimba .

Clasificare

Produsele pot fi impartite in urmatoarele tipuri:

telefoane (pe brand);

accesorii (pe brand);

SIM-uri (PrePay, PostPay, de schimb PrePay, de schimb PostPay);

cartele de reincarcare (functie de valoare si promotie);

pachete PrePay (pe tip promotie);

servicii de reincarcare (eVouchere si reincarcare directa);

taxe (de verificare, de despagubire, de schimb, etc . ) .

altele

Produsele pot fi catalogate si dupa codul de bare:

  • Produse cu serii de inventar (codul de bare e seria produsului);
  • Produse fara serie de inventar dar cu cod de bare la nivel de model .

Codul de bare identifica un produs (ca model) dar exista cazuri in care unul, doua sau mai multe produse au acelasi cod de bare (de ex . in cazul in care o parte a stocului pe un produs e alocat ca fiind cadou – PACHET PREPAY 01 – CADOU si PACHET PREPAY 01 sunt in fond acelasi produs dar disponibil in doua variante de destocare – la vanzare sau cadou) . La produsele fara serie de inventar li se vor introduce codul de bare de pe produs la aparitia sa in Sistemul Retail (la importul din OA sau la introducerea manuala) .

Produsele se supun unui sistem de clasificare flexibil:

  • arborescent, pe N niveluri
  • grupat in categorii
  • suma de calitati sau proprietati

Grupuri de categorii: produsele isi definesc fiecare o categorie din care fac parte si apoi acestei categorii i se adauga proprietati (categoria telefon cu proprietatile generatie, tip display, culoare, etc . ) .

Clasificare arborescenta: orice produs se poate incadra intr-o categorie in mod unic, categoriile nu depind de produs .

Calsificare insumata: se definesc calitati dinamic si se asociaza produselor .

Sursa informatiilor

Produsele sunt importate din sisteme externe (Oracle Applications) sau introduse manual, dar trebuie pastrata in permanenta o corespondenta stricta intre produsele introduse in Sistemul Retail si sistemele cu care acesta se interfateaza .

Produsele vor fi identificate prin seria IMEI (cazul telefoanelor), prin seria de produs (cazul cartelelor de reincarcare) sau prin codul de bare al produsului (in acest mod, fiecare produs poate fi identificat de cititorul de bare si Sistemul Retail il va selecta automat, fara sa mai fie necesara cautarea sa de catre vanzator in lista de produse – totusi aceasta optiune va ramane valabila, pentru cazurile in care vanzatorul va dori sa caute manual produsul) .

Sistemul Retail trebuie sa permita definirea unui set de reguli dupa care produsele sunt tiparite sau nu pe factura (vezi capitolul Raportare) .

Din OA produsul este importat cu detalii precum:

denumire OA

cod OA

pret de cost

alte proprietati

Importul din OA se declanseaza manual de catre utilizator, specificandu-se codul OA de produs care se doreste a fi importat, sau este rulat automat (vezi capitolul de interfatare cu OA) .

Din OA nu sunt obligatoriu importate toate produsele . Vor exista reguli de import (de ex . produsele de tip promo, sau flyerele, manualele, etc . nu se vor importa) . Importul din OA nu este facut automat, va exista un utilizator care valideaza produsele ce vor fi importate in Sistemul Retail .

Compatibilitate intre produse/servicii

Sistemul Retail sa pemita impartirea produselor in clase de compatibilitate, in functie de model si de fabricant (de exemplu sa se evite situatia in care clientul cumpara din greseala un terminal Nokia cu un handsfree bluetooth Sagem si acestea sa nu fie compatibile) sau de functionalitatile oferite de terminal (cu/fara MMS, cu/fara GPRS, cu/fara 3G, etc), caz in care este vorba despre o compatibilitate intre produs si serviciul oferit .

Produsele pot avea asociate si preturi si discounturi, in urma aplicarii carora se ajunge la un pret final .

Sistemul Retail va permite si definirea unor proprietati asociate produselor, a unor descrieri (de exemplu functii telefon, capacitate baterie, rezolutie camera, etc) care sa poata fi accesate de orice utilizator, dar intretinute de catre un utilizator de nivel superior cu atributii speciale in acest sens . Aceste proprietati si descrieri vor fi folosite in procesul de vanzare pentru a usura munca vanzatorului, prezentand clientului toate detaliile produsului pe care doreste sa-l achizitioneze .

Fiecare produs va apartine unei categorii clare, si va avea asociate compatibilitati cu alte clase de produse, cu alte produse (individual), o linie de produse (ex . linia SonyEricsson W, sau Blackberry), etc .

Produsele pot fi vandute la liber (cu pretul implicit), la abonament (cu pretul corespunzator abonamentului) sau la loializare (fie fidelizare – oferta publica, fie retention – oferta ascunsa, pentru ca se aplica doar clientilor ce doresc rezilierea);

Produsele pot fi subventionate, caz in care pretul lor la liber nu mai este la fel cu pretul de abonament sau de fidelizare, sau nesubventionate – caz in care pretul la liber este la fel cu cel de abonament sau de fidelizare .

La definirea unui produs, sistemul va permite definirea unei liste de produse compatibile cu produsul curent (pot fi accesorii pentru un telefon, sau telefoane pentru un accesoriu) .

In fereastra de vizualizare a detaliilor de produs (vezi fig1), sistemul va permite, prin apasarea unui buton suplimentar, vizualizarea listei de produse compatibile cu produsul selectat (fig . 4) . In aceasta fereastra, se vor afisa urmatoarele informatii:

  • denumire produs
  • daca este produs Orange (definit in Sistem) sau daca este un produs introdus ca text liber
  • stocul pentru acel produs in magazinul curent (daca e produs Orange)
  • stocul global, la nivelul intregului canal Retail pentru produsul respectiv (daca e produs Orange)

Lista de compatibilitati va include doua tipuri de informatii:

  • produse existente (deja definite in Sistem), care vor fi alese dintr-o lista;
  • text liber, pentru situatiile in care produsul respectiv nu se gaseste in Sistem (de exemplu carduri de memorie, care nu exista ca si produs in magazinele Orange)

Lista de compatibilitati va include doua tipuri de informatii:

  • produse existente (deja definite in Sistem), care vor fi alese dintr-o lista;
  • text liber, pentru situatiile in care produsul respectiv nu se gaseste in Sistem (de exemplu carduri de memorie, care nu exista ca si produs in magazinele Orange) .

Detalii de Interfata

In interfata aplicatiei, in cazul in care sistemul gaseste mai multe tipuri de produse cu acelasi cod de bare (de exemplu Pachet PrePay si Pachet PrePay Cadou), sa se afiseze o fereastra care sa permita utilizatorului selectarea tipului de produs curent . De asemenea, fereastra va permite introducerea unei cantitati asociate produsului respectiv .

La click pe cifra reprezentand stocul din magazin sau stocul pe canalul retail, se vor afisa cate o fereastra detaliind informatiile de stoc la nivel de magazie pentru stocul intern (vezi fig . 2) si respectiv la nivel de magazin pentru stocul retail (vezi fig . 3) .

In fereasra de vizualizare a detaliilor de produs, se vor afisa urmatoarele informatii (vezi figura 1):

  • denumirea comerciala;
  • cod Oracle Applications;
  • tip produs (un sir compus prin concatenarea categoriilor in care a fost incadrat produsul);
  • marca ;
  • status (valid/invalid);
  • stocul la nivel de magazin;
  • stocul la nivel de canal retail .

In fereastra de vizualizare a detaliilor de produs (vezi fig1), sistemul va permite, prin apasarea unui buton suplimentar, vizualizarea listei de preturi pentru produsul curent (in ce oferte este implicat, ce preturi ii sunt disponibile, etc) .

SHAPE * MERGEFORMAT

Figura SEQ Figura * ARABIC - Produse - Fereastra de detalii

 

Denumire comerciala

SPV

Cod OA

Tip produs

Telefon > PDA > 2G

Marca

Orange

Status

Valid

Stoc magazin:

Stoc retail:

Compatibilitati

Preturi

Inchide

Handsfree

Incarcator

Continut

Pachet

Produs

SPV

Cod OA

Inchide

Magazie

Cantitate

Magazia Vanzator 1

6

Magazia Vanzator 8

4

Magazia Magazinului

2

Figura SEQ Figura * ARABIC - Produse - Detalii stoc magazin

 

Produs

SPV

Cod OA

Inchide

Shop

Bucati disponibile

Shop Arad

12

Shop Sibiu

46

Shop EH

18

Figura SEQ Figura * ARABIC - Produse - Detalii stoc retail

 

Produs

SPV

Cod OA

Inchide

Denumire

Produs

Orange

Stoc magazin

Stoc

retail

Incarcator masina

Da

12

55

Card memorie 1GB

Nu

-

-

Handsfree

Da

18

47

Produse compatibile:

Figura SEQ Figura * ARABIC - Produse - Lista compatibilitati

 


Legaturi cu alte entitati

SHAPE * MERGEFORMAT

Pret

Produs

denumire, tip, serie, etc

Bon fiscal

Factura

Discount

Proforma

Stoc

PV SAV

Comanda

Sistemul va asigura o scalabilitate si flexibilitate in manupularea informatiilor (atributelor) entitatii si va permite operatii de adaugare / modificare / stergere / clasificare / intervale de timp (prin calendare) / valabilitate . Din acest motiv sistemul va asigura un configurator propriu pentru toate categoriile de entitati enumerate .

Entitatea Pret

Entitatea Pret defineste valoarea la vanzare a unui anume produs . Preturile sunt mereu asociate unui produs, putem avea un produs cu mai multe preturi dar nu si un pret asociat mai multor produse, si nici sa avem un pret fara un produs asociat .

Atribute

Pretul este identificat de urmatoarele atribute:

denumire;

valoare;

tip pret: lei sau valuta (si identificarea valutei de referinta);

daca este exprimat cu sau fara TVA;

daca este pretul implicit al unui produs – identifica pretul la liber al unui produs;

carui produs ii este asociat (un pret nu poate fi asociat decat unui singur produs);

valid sau nu (daca o promotie nu mai este valabila, si preturile produselor din aceasta promotie sunt invalidate);

perioada de valabilitate a pretului (data finala lasata necompletata inseamna ca pretul este valabil pe o perioada nedefinita);

data ultimei modificari;

istoric de modificari;

istoric de valabilitate pe perioade de timp;

canal de vanzari (poate fi pret corporate sau retail);

etc .

Perioada de valabilitate

Preturile pot avea perioade de valabilitate, si un istoric in care sunt pastrate valorile de-a lungul timpului . Este permisa reactivarea unui pret mai vechi in conditiile in care nu genereaza conflict de activare in istoric .

Set de conditii pentru aplicare pret

Pentru fiecare pret al unui produs se va asocia un set de conditii care trebuie satisfacute pentru ca acel pret sa fie disponibil in cadrul procesului de vanzare (concept descris mai pe larg in capitolul Vanzare) .

Preturile pot fi cu sau fara TVA, pot fi exprimate in lei sau valuta, caz in care se va specifica si valuta folosita . Preturile pot fi importate din sisteme externe (Vantive) sau introduse manual (vezi si capitolul Interfatare Sistem Retail – sisteme existente) .

Pretul este entitatea ce permite vanzarea unui produs, oferindu-i o valoare de start, de la care pornind, prin aplicarea unor eventuale discounturi, se poate ajunge la valoarea de oferta .

Legaturi cu alte entitati

SHAPE * MERGEFORMAT

Produs

Pret

denumire, produs, val .

Bon fiscal

Discount

Factura

Proforma

Oferta

Sistemul va asigura o scalabilitate si flexibilitate in manupularea informatiilor (atributelor) entitatii si va permite operatii de adaugare / modificare / stergere / clasificare / intervale de timp (prin calendare) / valabilitate . Din acest motiv sistemul va asigura un configurator propriu pentru toate categoriile de entitati enumerate .

Entitatea Discount

Discountul este o reducere ce afecteaza pretul final al unui produs/serviciu/taxa achitat de client .

Discounturile vor avea un proprietar (vor exista discounturi accesibile oricarui utilizator de nivel vanzator si discounturi accesibile la vanzare numai unui nivel superior – de exemplu, unui utilizator de nivel Shop Manager) .

Existenta unui set clar de discounturi ce se pot acorda pe o oferta .

Va exista un set clar de reguli de acordare a discounturilor .

Va exista un set de asocieri bazate pe incompatibilitati intre discounturi (nu se va putea acorda un discount daca in procesul de vanzare mai este implicat un discount cu care acesta nu este compatibil) . Toate aceste asocieri vor avea o descriere . Utilizatorul este notificat in cazul in care o astfel de restrictie de asociere intre discounturi este incalcata .

Sistemul Retail va asigura un sistem de regului de acordare a discounturilor de genul:

  • daca sunt scazute SIM-uri (sau SIM-uri de un anumit tip)
  • daca utilizatorul este de tip BSR
  • clientul e mai vechi de x ani
  • clientul face parte dintr-o anume categorie comerciala (Gold, Platinum, etc) sau o anumita proprietate a sa permite acordarea discountului (are mai multe de x subscriberi, are ultima factura de peste x RON, nascut in anul xxxx, are sau nu un anumit serviciu activat sau o lista de servicii)
  • pe factura mai este scazut un anumit produs, un anumit numar de produse sau un anumit set de produse
  • pe facturile anterioare s-au cumparat anumite produse (ca numar sau cantitate)
  • magazinul in care se face vanzarea .

Discounturile vor avea o plaja de valori (un discount fix va avea aceleasi valori la maximul si minimul plajei) si pot fi valorice sau procentuale . Plaja de valori a unui discount ce poate fi acordat poate varia, in functie de nivelul de acces al utilizatorului .

Discounturile pot fi asociate unui nivel de acces la aplicatie (vezi utilizarea ofertelor) sau accesibile tuturor celor implicati in procesul de vanzare .

Vor exista discounturi optionale si unele dintre acestea se vor acorda, de exemplu, in functie de unele proprietati ale clientului . Unele discounturi insa vor fi cu acordare obligatorie (de ex . un discount de 5€ asociat unei fidelizari poate sa fie obligatoriu aplicat pentru unele produse) .

Discounturile trebuie sa aiba un identificator suplimentar la nivel de asociere care sa arate daca este obligatorie aplicarea sa . (de ex . un discount de 5€ asociat unei fidelizari sa fie obligatoriu sa fie aplicat pentru unele produse)

Pe o factura pot apare oricate discounturi, cu conditia ca acestea, insumate, sa nu depaseasca pretul produsului .

Atribute

Proprietatile unui discount includ:

numele discountului;

codul OA (la fel ca la produse: compus din doua segmente: COD1-COD2, COD1 este codul de producator iar COD2 este codul de produs);

valoarea discountului;

tip de valoare – procentuala sau valorica;

tip valoric – lei sau valuta (daca este vorba de un discount in valuta, );

valoare TVA aplicat valorii (identificatorul TVA-ului) – poate lipsi;

serie de identificare a tipului de discount– aplicabila celor ce pot fi scanate cu cititorul de bare de pe o lista si apoi aplicate;

unitatea de masura (lei puncte, etc . );

daca este sau nu discount global (cel global se aplica la nivelul facturii, conditionat sau nu de anumite entitati, pe cand discounturile obisnuite se aplica la nivel de produs);

daca este valid sau nu (un discount ce nu se mai acorda nu mai este valid);

daca este sau nu un discount flexibil – valoarea sa poate fi stabilita de catre vanzator;

identificator de sursa: arata de unde a venit acest discount – importat din sistemul CRM (Vantive), introdus manual, etc .

istoric de valabilitate discount (perioadele trecute de valabilitate si perioada curenta de valabilitate);

matrice de compatibilitate cu celelalte discounturi (arata daca un discount poate fi acordat impreuna cu un alt discount sau nu);

perioada de valabilitate;

etc;

Seturi de conditii asociere discount

Discounturile pot fi sau nu disponibile la o operatiune de vanzare in functie de o multime de conditii legate de:

tipul produsului – de ex . pot fi discounturi disponibile doar pe anumite tipuri de produse;

produsul;

clientul – de ex . discounturi disponibile in functie de diferite proprietati ale clientului;

magazinul;

optiuni;

plan tarifar;

pretul initial al produsului;

oferta;

orice combinatie intre cele de mai sus .

Aceste conditii fac ca unele discounturi sa fie legate de un produs, pe cand altele sunt acordate la nivel de produs, dar fara sa depinda de acesta (de ex . un discount generic de 10$ acordat unui client de tip Top Spender, aplicabil la nivel de produs, dar fara sa fie constrans de un anumit produs) . Contrangerile pot fi definite in sensul permiterii acordarii lor, dar si in sesnul inhibarii asocierii lor unor entitati ce definesc vanzarea (se definesc atat conditii de includere cat si conditii de excludere) . Aplicarea unui discount nu trebuie sa aduca valoarea facturii sub 0 .

Istoric al discounturilor

Sistemul Retail trebuie sa permita definirea discounturilor cu o perioada de valabilitate si trebuie sa tina un istoric al discounturilor .

Sistemul Retail trebuie sa faciliteze definirea de discounturi acordate unor produse numai pentru situatia in care sunt achizitionate in “pachete” (adica clientul poate beneficia de anumite discounturi doar daca cumpara un set de produse) .

Clasificari

Discounturile pot fi:

in lei sau valuta;

procentuale sau valorice;

fixe sau flexibile;

globale sau specifice (cele globale se aplica intregii vanzari, cele specifice unui produs);

acordabile numai de o anumita clasa de vanzatori (de ex . vanzatorii BSR pot acorda un discount variabil functie de numarul de SIM-uri de pe factura – in acest caz o constrangere suplimentara legata de numarul de SIM-uri de pe factura trebuie introdusa);

dependente de o anumita clasa de produse, de un interval valoric in care se incadreaza produsul sau de cantitatea de produse vandute cu care acest discount se inmulteste;

exprimate in preturi cu sau fara TVA (asta nu inseamna ca nu se mai percepe TVA pentru ele, ci pretul este exprimat intr-o anume forma . ) .

Punctele ThankYou

Un tip special de discount il reprezinta punctele ThankYou: acest tip de discount poate fi acordat oricarui client Orange Romania , poate fi asociat oricarui produs si are pretul fix, in euro cu TVA: 10 punte TY = 1 EUR cu TVA .

Legaturi cu alte entitati

SHAPE * MERGEFORMAT

Produs

Discount

nume, cod, valoare, tip,

Bon fiscal

Pret

Factura

Proforma

Client

Plan tarifar

Oferta

Sistemul va asigura o scalabilitate si flexibilitate in manupularea informatiilor (atributelor) entitatii si va permite operatii de adaugare / modificare / stergere / clasificare / intervale de timp (prin calendare) / valabilitate . Din acest motiv sistemul va asigura un configurator propriu pentru toate categoriile de entitati enumerate .

Entitatea Oferta

“Oferta” reprezinta o parte a procesului de vanzare, un set de reguli de aplicare, cu conditii atasate . Regulile stabilesc preturile de pornire ale produselor si conditiile de calificare a clientului iar conditiile influenteaza procesul de vanzare (prin acordarea de discounturi suplimentare) .

Ofertele sunt suportul vanzarii de telefoane si accesorii . Vanzarile de accesorii, de pachete PrePay, de cartele sau servicii de raincarcare se pot face si fara a fi nevoie de prezenta unei oferte (doar in baza pretului implicit al produsului) .

Vanzatorul nu trebuie sa aiba o prea mare libertate in stabilirea unui pret final in cadrul unei operatiuni de vanzare: vor exista un set de reguli de acordare a discounturilor si de selectie a preturilor . In cazul in care un vanzator este nevoit sa aplice discounturi ce nu-i sunt accesibile sau premise (situatii exceptionale), el va putea sa-si asume rolul unui utilizator de drepturi superioare (folosind o parola speciala – situatie discutata mai jos) .

Relatia dintre Sistemul Retail si Vantive:

  • Sistemul Retail poate exporta tranzactiile de vanzare in care vor fi detaliate produsul, pretul cu care a fost achizitionat de catre client impreuna cu o descriere din care sa se inteleaga modul in care s-a ajuns la acel pret final .
  • tranzactiile relevante pentru interactiunea cu Vantive (de exemplu fidelizari) vor fi validate de catre Vantive inainte de a fi finalizate in Sistemul Retail (cu alte cuvinte inainte de a se finaliza o tranzactie de fidelizare, aceasta va fi mai intai validata de catre Vantive pentru a se asigura ca indeplineste toate conditiile impuse de acesta) . Daca o tranzactie de loializare nu este validata de Vantive, un utilizator de nivel superior va avea totusi posibilitatea de a forta aceasta tranzactie ca sa fie salvata in Sistemul Retail (va ramane insa ca nevalidata de Vantive, dar abia acum se va exporta in OA) .

Discount-urile vor fi definite ca avand doua limite intre care vor putea fi acordate (o valoare minima si una maxima) . In cazul unor discounturi fixe, aceste limite vor fi egale . In functie de utilizatorul autentificat, aceste limite ale discounturilor vor putea fi diferite, la fel si preturile disponibile (cu alte cuvinte, acelasi discount ar putea avea limite diferite in functie de nivelul de acces) .

Va exista o lista de preturi si discounturi accesibile oricarui utilizator implicat in procesul de vanzare si o lista de preturi si discounturi accesibile numai utilizatorilor de nivel superior, acordabile in conditii speciale .

Fiecare produs poate avea mai multe preturi, in funcite un set de reguli stabilite in prealabil . Conditiile pot fi la nivel de:

  • Client (dictate de MKT sau stabilite intern – acestea permit inceperea procesului de vanzare)
  • Produs (acestea se aplica in timpul procesului de vanzare)
  • Factura (conditie finala – nu se poate finaliza vanzarea daca anumite conditii nu sunt respectate)

Vanzarea printr-o oferta se va supune unor reguli stricte de acordare de discounturi, astfel incat vanzatorului sa nu-i fie permisa o flexibilitate indiferent cat de mare (vor fi discounturi ce ve vor aplica in mod obligatoriu, discounturi cu valoare variabila si seturi de discounturi optionale, dar fiecare va prezenta o dependenta stricta de tipul de vanzare – fidelizare, abonament, la liber, cu/fara prelungire contractuala, etc) .

SHAPE * MERGEFORMAT

Oferta

nume, cod, descriere, tip,

Produs

Pret

Discount

In sistemul actual, ofertele au asociate planuri tarifare, depind de acestea si de optiuni; pot fi definite oferte ce sunt valabile numai pentru unii clienti sau numai pentru o categorie de clienti . In Sistemul Retail se doreste o flexibilitate mai mare, in sensul definirii seturilor de conditii de alocare discount sau asociere pret, despre care s-a vorbit anterior .

Ofertele (si implicit discounturile si preturile) au o perioada de valabilitate si prezinta un istoric al declararii lor si al perioadelor in care au fost active .

Clasificare

Ofertele pot fi de tip:

  • abonament (la 12 sau 24 de luni – implicit sunt definite pe 12 luni);
  • prepay sau la liber (terminal cu pachet PrePay);
  • fidelizare (cu prelungirea contractului pe 12 sau 24 de luni – implicit pe 12 luni); fidelizarile pot fi de tip retention (pentru retinerea clientilor in retea) sau de tip normal (dupa 11 sau 23 de luni clientul are dreptul la unele preturi preferentiale la unele terminale);
  • de date, 3G, speciale (promotii);
  • retail sau corporate (ofertele au un domeniu de aplicabilitate, pot fi aplicabile unor magazine, individual, sau unui grup de magazine);
  • altele

Ofertele pot mentine asocieri intre:

  • produsul;
  • pretul produsului;
  • discountul asociat;
  • magazinul in care este folosita;
  • planul tarifar al clientului;
  • optiunile clientului;
  • contractul clientului;
  • tipul clientului;
  • clientul individual;
  • etc

Ofertele vor fi descompuse in categorii de operatiuni frecvente:

    • fidelizare;
    • achizitie;
    • retention;
    • la liber;
    • altele .

Lista de categorii nu este fixa, ea putandu-se modifica cu timpul .

Fiecare categorie de operatiuni contine la randul ei procese de vanzare frecvente, operatiuni precum Fidelizare la 12 luni, Fidelizare la 24 luni, etc . Intrucat toate procesele de vanzare presupun vanzari cu anumite discounturi, prin extensie, si categoriile de operatiuni vor avea la randul lor asociate discounturi (de exemplu, nu se va putea asocia un discount de tip punct OrangeThankYou unei operatiuni de vanzare prin abonament) .

Pe factura tiparita de Sistemul Retail pot fi prezente mai multe categorii de operatiuni si chiar mai multe operatiuni din aceeasi categorie, insa nu se poate ca o linie a facturii sa aiba asociata mai mult de o operatiune .

Clientul ales determina tipul contractului, planul tarifar folosit in vanzare, optiunile ce determina oferta si discounturile ce i se pot acorda . .

Stabileste o legatura intre pret si produs: in cadrul unei oferte exista o asociere unica intre produs si pret . O oferta poate sa contina mai multe discounturi si mai multe conditii de acordare .

Atributele entitatii

Printre proprietatile ofertei se numara:

  • tipul de client caruia i se adreseaza sau clientului caruia i se adreseaza (daca e cazul);
  • conditiile de acordare legate de client (vechime, clienti adusi in retea, consum, etc . )
  • tipul de plan tarifar pe care poate fi acordata, optiunea sau optiunile ce o determina;
  • magazinul in care este aplicabila;
  • prelungirea contractuala:
    • 12 luni;
    • 24 luni;
    • 28 luni;
    • etc;
  • tipul ofertei:
    • liber:
      • PrePay;
      • accesoriu;
      • etc .
    • abonament:
    • loializare:
      • fidelizare:
      • retention:
      • etc .
  • daca include un SIM sau nu (pentru oferta de abonament) – indica faptul ca trebuie scazut sau nu si un SIM impreuna cu produsul, sau cate SIM-uri se scad per abonament incheiat;
  • vechimea minima (pentru loializari) – indica numarul minim de luni la care un client are dreptul sa faca o loializare;
  • cantitatea minima si maxima pentru care se poate folosi oferta;
  • produsul;
  • pretul;
  • discountul sau discounturile;
  • validitatea ofertei (daca este valida sau nu);
  • perioada de valabilitate a ofertei;
  • istoricul de valabilitate al ofertei;
  • etc .

Finalizarea unei oferte cu drepturi extinse

Sistemul Retail va implementa un sistem de asumare temporara a unui rol de nivel superior, care sa permita o mai mare flexibilitate in vanzare .

Sistemul Retail va implementa si un sistem de definire a accesului unui utilizator de nivel inferior autentificat cu drepturi de pe un nivel superior

Pentru ca cele doua sisteme de asumare de drepturi si accesare cu drepturi de nivel superior a aplicatiei sa fie implementate de Sistemul Retail, va exista un sistem de acordare parole one-shot (manual si automat), parole apartinand utilizatorului de nivel superior si disponibile unui utilizator de nivel inferior ierarhic, la cerere .

In cazul in care un utilizator de nivel inferior are nevoie pe timp limitat de drepturi extinse (de exemplu in cazul in care unui anumit client are nevoie sa-i acorde un discount special), acesta poate consulta o lista de utilizatori de nivel superior si sa initieze un proces de asumare temporara a unui rol de nivel superior (initiaza o cerere de acces extins) .

Dupa ce utilizatorul de nivel superior a fost ales, acestuia i se adreseaza o notificare prin SMS cu cererea utilizatorului de nivel inferior si cu o scurta descriere a motivului . Aceasta notificare contine si o parola unica pe care initiatorul cererii o poate folosi (trebuie ca utilizatorul destinatar al cererii sa i-o comunice) . Motivul este completat de catre utilizatorul de nivel inferior (un camp scurt) .

Aceasta parola unica poate fi generata de sistem sau poate fi intretinuta de utilizatorul de nivel superior (lista de parole) . Parolele pot fi introduse manual de catre utilizatori, sau generate automat de sistem .

Parola generata de sistem este unica, este valabila numai intr-un anumit interval (de ordinul orelor sau minutelor) si poate fi folosita numai de catre utilizatorul intiator o singura data .

Odata ce parola a fost generata de sistem, este monitorizata activitatea utilizatorului initiator si la finalul vanzarii, utilizatorul destinatar (de nivel superior) este notificat (pentru raportare) . La autentificarea in aplicatie, utilizatorul de nivel superior este notificat de toate accesele de pe nivelurile de acces inferioare la discounturile nivelului sau .

Orice utilizator de nivel superior poate sa delege drepturi de acces utilizatorilor de pe nivelurile inferioare si poate sa opteze pentru folosirea sau nu a sistemului de acordare dinamica de parole . Orice utilizator de nivel superior poate delega drepturi de acces la parti din zonele aplicatiei la care are acces, sau poate acorda si drepturi asupra unor obiecte (discounturi sau preturi) ce ii apartin exclusiv .

Legaturi cu alte entitati

SHAPE * MERGEFORMAT

Produs

Oferta

denumire, cod, tip,

Pret

Discount

Alte entitati

Client

Plan tarifar

Sistemul va asigura o scalabilitate si flexibilitate in manupularea informatiilor (atributelor) entitatii si va permite operatii de adaugare / modificare / stergere / clasificare / intervale de timp (prin calendare) / valabilitate . Din acest motiv sistemul va asigura un configurator propriu pentru toate categoriile de entitati enumerate .

Entitatea Stoc

Stocul contine toate produsele disponibile din punct de vedere comercial (inclusiv unele produse promotionale), prezente in gestiunea magazinului .

Atribute

Stocul contine toate produsele inventariate in magazine (produsele pentru vanzare, produsele promotionale, produsele cadou, defectele, etc . ) . Este o entitate identificata de urmatoarele proprietati:

magazin;

magazia;

produsul;

seria;

cantitatea (daca nu are serie);

etc .

Clasificare

Stocul poate fi impartit in:

stoc vanzator (magazie individuala);

stoc magazin (magazia magazinului de pe care se fac apoi transferurile pe stocurile individuale);

stoc defecte (telefoanele din magazin defecte);

stocurile de SAV service:

o      magazie de produse defecte preluate de la client;

o      magazia de produse defecte trimise in service;

o      magazia de produse defecte reparate si returnate de la service,

o      magazia de telefoane de SWAP din magazin;

o      magazia de telefoane de SWAP imprumutate clientilor;

o      magazia de telefoane de SWAP defecte din magazin;

stocul de accesorii;

stocul de produse din vitrina .

Fiecare stoc individual are asociat un vanzator si o lista de utilizatori cu drepturi mai largi ce pot accesa acest stoc pentru vizualizare sau pentru modificare .

Stocurile sunt afectate de vanzari, transferuri, operatiuni SAV, retururi, receptii, schimburi, etc .

Legat de stocuri, vor exista si unele alarme de sistem (pop-up de avertizare):

  • Alarma pentru o rotatie de stoc mica
  • Alarma pentru valoare de stoc mare (pret de cost insumat mare)
  • Alarma pentru depasiri SAV Periodic se vor analiza anumiti parametrii ce vanzare (perioada modificabila) si utilizatorii responsabili vor fi instiintati de existenta unei probleme in urma acestei analize

Stocul este asociat unei magazii . Nu vor exista produse (fizice) care sa nu aiba asociata o magazie (taxele, serviciile, discounturile nu apartin vreunei magazii) .

Magaziile pot fi:

  • vizibile (contin produsele disponibile);
  • ascunse (defecte, SAV, vitrina, Touch&Try, etc);
  • speciale (rezervari);
  • intermediare (contin produsele care sunt in tranzit intre gestiunea unui magazin si gestiunea unui alt magazin) .

Magaziile vizibile includ:

  • Magazia magazinului si
  • Magaziile vanzatorilor

Proprietatea de vizibil(disponibil)/invizibil(indisponibil vanzarii) va fi un atribut la nivel de magazie/tip de magazie si va putea fi stabilit de catre utilizator .

InfoShops poate vizualiza stocul din Magaziile vizibile, putand lansa pentru produsele din aceste magazii comenzi de rezervare . Vizibilitatea din punctul de vedere InfoShops nu este la nivel de magazie, ci la nivel general (stoc total in magaziile vizibile) .

Magazia de produse rezervate este o magazie speciala, nu e vizibila de catre InfoShops si contine si informatii suplimentare de rezervare (vezi Subiectul ‘Sistemul de rezervare’) .

Magaziile ascunse contin produse indisponibile:

  • Magaziile de SWAP (SWAP disponibile si SWAP la client)
  • Magazia de defecte
  • Magazia de defecte SAV (SAV defecte receptionate, SAV defecte trimise in service, SAV defecte intoarse din service)
  • Magazia Touch&Try
  • Magazia Touch&Try de telefoane uzate

Magazia Touch&Try de telefoane uzate cuprinde telefoane din magazia Touch&Try, si care acum sunt uzate . Acestea pot fi vandute la un pret special (cu discount) . Se va putea calcula perioada dintre mutarea pe stocul de Touch&Try si mutarea pe stocul de Uzate, si in functie de aceasta perioada din stocul de uzate pot fi vandute telefoane la un pret variabil .

Nu se permit operari simultane asupra stocului la nivel de cod de produs si magazie . Utilizatorul este notificat de cazul in care transferul este operat partial, din motiv de blocare acces la stoc (in cazul unei tranzactii de transfer, o parte din produse nu pot fi transferate din motivul enuntat mai sus, restul produselor vor putea fi transferate) .

Daca un utilizator opereaza pe stocul unui produs dintr-o magazie si un alt utilizator opereaza pe stocul aceluias produs, dar din alta magazie, sistemul permite realizarea simultana a ambelor operatiuni (cu conditia ca nici magaziile destinatare sa nu fie aceleasi) .

Daca doi utilizatori simultan doresc sa opereze asupra a doua produse distincte, sistemul va permite aceasta, indiferent de magazia pe care se opereaza sau de magazia destinatie .

Daca doi utilizatori incearca sa opereze asupra aceluiasi produs (produs cu sau fara serie), aflat in aceeasi magazie (sau cu aceeasi magazie destinatie), sistemul nu va permite celui de-al doilea utilizator sa opereze acel produs (doar il va vedea; la initierea operarii ii va aparea un mesaj “Asupra produsului [] din magazia [] se desfasoara o tranzactie initiata de []”)

Vizualizarea stocurilor se va face la nivel de produs si cantitate . Daca se doreste selectarea unei anumire serii, prin click pe linia cu produsul dorit se ajunge la lista de serii de pe stoc ale acestui produs (daca este un produs fara serie, nu se intampla nimic la click pe produs) . Daca se doreste selectarea unei serii a unui produs de pe stoc prin cititorul de coduri de bare, va exista si o zona de cautare dupa serie . Scaderea seriei este vizibila numai in detaliile tranzactiei, pe stocul vizibil se va observa numai diminuarea cantitatii de pe stoc .

Fiecare utilizator va avea acces la stocul istoric de final de zi, dar numai pentru gestiunea sa .

Un utilizator autentificat sub nivel de Shop Manager poate vizualiza stocurile istorice ale oricarui alt utilizator, precum si tranzactiile acestuia (operarile pe stoc) .

Un utilizator ce mai are inca produse in magazia intermediara, nu poate face “Inchiderea de Zi” pana ce nu face receptia acestor produse, sau pana ce nu refuza acest transfer .

Transferurile intre gestiuni pote fi efectuate doar de catre utilizatori sub rolul de Stock Keeper, rol pe care si-l pot asuma utilizatorii autorizati (inclusiv vanzatorii) .

Tranferurile pot fi operate chiar daca utilizatorul a carui gestiune este afectata nu a facut “Inchiderea de Zi” .

In momentul in care un transfer este operat, utilizatorul care il efectueaza este responsabil pentru produsul transferat in gestiunea destinatie (pana in momentul in care acest produs ajunge fizic in gestiunea destinatie) .

Operarile scriptice pe gestiune trebuie sa corespunda operarii fizice pe gestiune si trebuie sa respecte procedura interna Orange .

Un utilizator in a carui magazie se efectueaza un transfer, este anuntat de aplicatie si i se cere sa confirme receptia tutror produselor implicate in acest transfer (vezi Transfer cu magazia intermediara) .

Utilizatorul de pe nivel Sef de Magazin se considera ca are acces la stocul unui vanzator, dupa ce acesta si-a facut “Inchiderea de ZI” si inainte de orice alta noua autentificare in Sistem a sa .

La efectuarea unei inchideri de zi, urmatoarele rapoarte zilnice sunt obligatorii:

  • Borderoul de Vanzari
  • Dispozitiile de Plata
  • Monetarul

Utilizatorii de nivel vanzator, operand sub rolul de Stock Keeper, pot transfera in oricare magazie (inclusiv in propria magazie) din oricare alta magazie si din oricare magazie (inclusiv din propria magazie) in oricare alta magazie .

Un utilizator de nivel superior (de ex . Retail Area Manager, Shop Manager sau Retail Controller) sa poata opera corectii de marfa pe o gestiune:

  • corectii de inventar (acestea se vor opera doar la nivel de magazin si se vor exporta catre OA – se presupune ca intre Sistemul Retail si OA nu vor fi diferente de stoc) .
  • corectii in urma unor note interne sau cu aprobarea Logisticii (de ex . pentru telefoane furate sau pentru serii sosite incorect din WAREHOUSE)

Vizibilitatea stocului din sisteme externe – OA

Toate operatiunile asupra stocului, care sunt relevante din punct de vedere al stocului la nivel de magazin, se vor sincroniza cu OA, prin intermediul tranzactiilor operate asupra sa .

Stocul din Sistemul Retail va fi vizibil in OA, in timp real . Se va face si o detaliere pe magazii (la cerere, din Sistemul Retail se va putea vizualiza chiar si numai un subinventar al unui magazin – de ex . stocul de defecte) . Unele magazii sunt indiponibile OA:

  • Magazia de SAV imprumutate;
  • Magazia de SAV schimb;
  • Magazia de Rezervari;
  • s . a .

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

Stocul din OA poate fi vizibil in Sistemul Retail, dar acesta este neconcludent, din cauza fluxului mare de comenzi (un stoc AVAILABLE la un moment dat este posibil sa aibe in asteptare mai multe rezervari – inca neoperate - sau sa urmeze sa fie alimentat in curand, asa ca valoarea sa curenta nu reflecta realitatea) .

La nivel de serie IMEI sa se poata lansa periodic (initial cu o frecventa de o data pe saptamana) o verificare stocul din OA si cel din Sistemul Retaiil . Rezultatele acestei verificari vor fi trimise prin eMail persoanelor interesate, si vor putea fi si accesate din Sistemul Retail de catre utilizatori autorizati .

Transferul cu magazia intermediara

Orice transfer efectuat catre o gestiune a unui utilizator de nivel Vanzator, gestiune diferita de cea a utilizatorului care efectueaza transferul, va trece printr-o magazie intermediara .

Un astfel de transfer presupune doua faze:

  • transferul se face printr-o magazie intermediara, in care se duc produsele in prima faza a transferului (cu destinatia precisa specificata)
  • acceptul utilizatorului cu rol de vanzator, destinatar – se bifeaza fiecare produs primit (la nivel de serie, daca produsele au serie, altfel, la nivel de cantitate)

Utilizatorului destinatar i se afiseaza apoi un mesaj pop-up cu informatia ca sunt in asteptare pentru transfer un numar de produse . Click pe popup si in fereastra ce se va afisa apoi se bifeaza fiecare produs receptionat si la apasarea butonului de OK se finalizeaza transferul si se afiseaza nota de transfer .

Aceasta magazie intermediara nu este implicata in transferurile cu magazia magazinului, magazia de defecte, de rezervari, etc .

Vanzatorului implicat intr-un asemenea transfer, pecum cel descris mai sus, i se afiseaza un popup din aplicatie in care este anuntat ca tocmai i-au fost transferate pe stoc si i se cere sa bifeze (in scop de verificare) produsele pe care le receptioneaza (va exista si un buton de “Selecteaza toate produsele”) .

Consultare stoc

Sistemul Retail trebuie sa ofere posibilitatea fiecarui vanzator de a-si vizualiza stocul propriu la orice moment si, in functie de drepturi, de cautare a unor produse in stocurile apartinand altor entitati (alti vanzatori, magazinul din care face pare, alte magazine, etc . ) .

Istoric stoc

Sistemul Retail va pastra un istoric al stocurilor . Istoricul de stocuri contine data salvarii si apoi datele de stoc (vezi mai sus) . Istoricul de stoc poate fi salvat la nivel de zi sau la nivel de luna sau ambele (pentru o consultare mai usoara si comparatie cu sistemul OA) .

Legaturi cu alte entitati

SHAPE * MERGEFORMAT

Produs

Stoc

magazin, magazie, produs, serie, etc

Proforma

Bon fiscal

Factura

Tranzactie

Utilizator

Sistemul va asigura o scalabilitate si flexibilitate in manupularea informatiilor (atributelor) entitatii si va permite operatii de adaugare / modificare / stergere / clasificare / intervale de timp (prin calendare) / valabilitate . Din acest motiv sistemul va asigura un configurator propriu pentru toate categoriile de entitati enumerate .

Entitatea Utilizator

Entitatea utilizator reprezinta orice persoana ce interactioneaza cu Sistemul Retail, interactiune care se face intr-o maniera controlata de drepturile de acces . Fiecare utilizator are asociat un nivel de acces la aplicatie . Utilizatorii trebuie sa fie unic identificabili din punct de vedere al interactiunii lor cu Sistemul Retail .

Fiecare utilizator apartine unui nivel de autoritate, sau mai multora . In cazul din urma, la autentificarea in aplicatie, este fortat sa-si aleaga un nivel de autoritate sub care doreste sa opereze in Sistemul Retail .

Dintre toate nivelurile de autoritate pe care le poseda, un utilizator apartine “nativ” unui singur nivel, acesta fiind cel implicit de activitate . (de ex . un utilizator poate fi si Vanzator si Stock Keeper)

Utilizatorii vor fi grupati pe niveluri de acces si roluri

La fiecare nivel de acces vor exista atasate drepturi de acces suplimentare (de ex . , pentru utilizatori BSR, drept de accces la un anumit discount sau la anumite plaje pentru un anume discount) – in cadrul nivelurilor de autoritate definite mai sus .

Sistemul Retail va permite declararea unei liste de functionalitati primare asupra carora se pot introduce restrictii de acces (de ex . vanzare PrePay, vanzare cu CC , Transfer extern marfa sau vanzare prin bon de casa) .

Aceste functionalitati primare pot fi combinate in grupuri functionale, pentru a fi mai usor manipulate de catre administratorul aplicatiei la acordarea de drepturi .

Grupurile functionale pot fi la randul organizate in roluri, fiecare rol putand avea unul sau mai multe grupuri functionale atasate .

Un utilizator ce are asociat un anume rol dobandeste accesul la functionalitatile primare ce sunt continute in grupurile functionale ale rolului .

La definirea unui utilizator se aleg dintr-o lista rolurile pe care acest utilizator le va avea .

Perspectivele de vizualizare dicteaza felul in care un utilizator are acces la functionalitatile oferite de rolul sau (ordinea meniurilor, gruparea functiilor cele mai folosite, etc . )

Exemple de roluri definibile:

  • Vanzator Junior pe Casa de Marcat
  • Vanzator Junior
  • Vanzator
  • Vanzator BSR
  • BSR Manager
  • SOHO&SME Manager
  • Retail Channel Manager
  • Retail Area Manager
  • etc .

Fiecare nivel de autoritate va avea asociata o “perspectiva” asupra operatiunilor pe care are dreptul sa le execute (fiecare nivel de autoritate este o suma de drepturi) .

“Perspectiva” nivelului de autoritate presupune chiar si un layout al paginii si al meniurilor disponibile .

Un utilizator poate avea acces la mai multe “perspective”, fie in functie de nivelul de autoritate sub care doreste sa opereze in sistem, fie sa aibe posibilitatea de a-si creea propria sa perspectiva .

Operatiunile cele mai frecvente vor fi amplasate la indemana . In ecranul imediat urmator autentificarii in Sistemul Retail va exista o zona in care vor aparea aceste operatiuni sub forma de link-uri catre paginile de inceput ale operatiunilor dorite . Chiar si in cazul in care un utilizator se autentifica pentru prima data in Sistem, el va avea aceasta lista de operatiuni frecvente, pentru ca operatiunile frecvente vor fi asociate fiecarui nivel de autoritate, sau fiecarui tip de utilizator . In cazul unui utilizator constant al aplicatiei, operatiunile frecvente sunt calculate din analiza activitatii sale (in baza log-urilor de activitate) .

Nivelul de autoritate permite si acccesul la unele functii specifice (de ex . discounturile definite pentru un anumit nivel de autoritate, transferuri externe, etc . ) .

Atribute

Utilizatorii sunt definiti de urmatoarele atribute:

nume;

cod;

parola;

locatia scriptica in care isi desfasoara activitatea (un casier poate activa in cadrul unui magazin, dar sa fie gestionat la nivelul unei entitati speciale ce contine utilizatori din mai multe magazine)

magazinul in cadrul caruia isi desfasoara activitatea;

magazia asociata;

nivelul de acces;

identificator de casa de marcat (de obicei la fel ca si codul);

date buletin:

o      CNP;

o      serie;

o      numar;

o      sectia de politie eliberatoare;

o      etc .

daca este sau nu un vanzator BSR (Bussiness Sales Representative);

utilizatorul sau utilizatorii delegati sa actioneze in numele sau;

etc .

Clasificare

Rolurile (sau nivelurile de acces) sunt:

vanzator;

stock keeper;

sef de magazin;

retail area manager;

retail channel manager;

commercial;

etc .

Categoriile in schimb impart utilizatorii pe departamente (se considera ca o delegare inter-departamentala nu este permisa):

  • Departament Logistica;
  • Departamentul Retail;
  • Departamentul Contabilitate;
  • etc .

Rolurile sunt axate pe functionalitati

Grupurile sunt axate pe drepturi de acces la unele obiecte apartinand diverselor functionalitati (de ex . rol de vanzator => acces la vanzare; apartine grupului de retail => poate acorda anumite discounturi, daca ar fi fist BSR, ar fi accesat mai multe discounturi)

Acordarea de drepturi se va face si pe perioade nedefinite (de ex . pentru unii vanzatori cu experienta, shop managerul poate alege delegarea de drepturi depline pe perioada nedefinita)

Ex . de ierarhie:

ORO

OROSH

AR

GL

EH

OROSOHO&SME

RAMAR

RAMOR

RAMPL

OROCORP

CBC-EH

CBC-BV

OROSHCAS

CASEH

CASPL

CASCR

Drepturile de acces

Drepturile de acces permit numai vizualizare, numai adaugare, vizualizarea si modificarea sau toate cele enumerate . Drepturile de acces sa poata fi create si in functie de grupul din care face parte utilizatorul, locatia sa fizica, in cadrul unui departament sau in cadrul unui magazin Orange .

Utilizatorii pot fi asociati unui anume magazin, sau pot fi utilizatori generici, ce se pot conecta oriunde, dar in functie de drepturile pe care le au pot accesa o parte sau toate functionalitatile Sistemului Retail . Trebuie, de asemenea, sa fie definite functionalitatile Sistemului Retail carora se doreste sa le fie asociate drepturi de acces . Se va construi in acest sens o matrice de drepturi ce va dicta ce utilizator ce functionalitati acceseaza .

In cazul in care un utilizator de nivel inferior are nevoie pe timp limitat de drepturi extinse (de exemplu in cazul in care unui anumit client are nevoie sa-i acorde un discount special), acesta poate consulta o lista de utilizatori de nivel superior si sa initieze un proces de asumare temporara a unui rol de nivel superior (initiaza o cerere de acces extins) .

Dupa ce utilizatorul de nivel superior a fost ales, acestuia i se adreseaza o notificare prin SMS cu cererea utilizatorului de nivel inferior si cu o scurta descriere a motivului . Aceasta notificare contine si o parola unica pe care initiatorul cererii o poate folosi (trebuie ca utilizatorul destinatar al cererii sa i-o comunice) . Motivul este completat de catre utilizatorul de nivel inferior (un camp scurt) .

Aceasta parola unica poate fi generata de sistem sau poate fi intretinuta de utilizatorul de nivel superior (lista de parole) . Parolele pot fi introduse manual de catre utilizatori, sau generate automat de sistem .

Parola generata de sistem este unica, este valabila numai intr-un anumit interval (de ordinul orelor sau minutelor) si poate fi folosita numai de catre utilizatorul intiator o singura data .

Odata ce parola a fost generata de sistem, este monitorizata activitatea utilizatorului initiator si la finalul vanzarii, utilizatorul destinatar (de nivel superior) este notificat (pentru raportare) . La autentificarea in aplicatie, utilizatorul de nivel superior este notificat de toate accesele de pe nivelurile de acces inferioare la discounturile nivelului sau .

Modalitatea de delegare de drepturi este definita la nivel de rol, dar fiecare utilizator de nivel superior poate sa aleaga metoda (metodele) prin care se face delegarea de drepturi .

Rezumand: delegarea de drepturi poate sa fie facuta:

  • explicit (la cererea utilizatorului de nivel superior, ale carui drepturi sunt puse la dispozitia altor utilizatori – sau altui utilizator)
  • implicit (cand un utilizator de nivel inferior cere drepturi, se trimite un SMS cu o parola de confirmare utilizatorului de nivel superior si acesta poate alege daca sa acorde sau nu drepturi aplicantului – transmitandu-i parola one-shot de acces) .

Fiecare utilizator de nivel superior va putea defini o lista de utilizatori (de nivel inferior, evident) care vor putea obtine temporar drepturi de nivel superior . In dreptul fiecarui utilizator de nivel inferior (beneficiarul drepturilor), utilizatorul de nivel superior (furnizorul drepturilor) va putea specifica daca este necesara autentificare prin cod transmis prin SMS sau, in cazul in care este vorba despre o persoana in care acesta are deplina incredere, aceasta delegare temporara se va putea face fara confirmare din partea furnizorului dreptului (vezi delegarea) .

In ambele cazuri (cu autentificare prin cod trimis prin SMS sau fara autentificare speciala) actiunile utilizatorului care a primit in mod exceptional drepturi de nivel superior vor fi salvate in loguri, iar aceste informatii vor fi afisate furnizorului acestor drepturi exceptionale in fereastra principala a aplicatiei, cu ocazia urmatoarei logari .

In acest fel, furnizorul drepturilor va putea inspecta imediat toate actiunile facute de utilizatori in perioada in care au primit acele drepturi exceptionale .

Delegarea

Fiecare utilizator poate delega un alt utilizator sa actioneze in numele sau in aplicatie . Delegarea se va face pe o perioada, de catre utilizatorul delegator . Un utilizator poate delega un grup sau o lista de utilizatori sa actioneze in numele sau .

Un utilizator de nivel superior poate delega un alt utilizator drepturile sale de acces, pe o perioada limitata .

Delegarea nivelului de autoritate se poate face in mod explicit:

  • pe o perioada fixa (incepand cu un moment anume din viitor sau din momentul inceperii procesului de delegare - instant) .
  • pe o perioada nedefinita (incepand cu un anume moment din viitor sau din momentul inceperii procesului de delegare - instant)

La alegerea perioadelor de delegare se vor introduce si datele si orele intre care se face delegarea; se va adauga si un scurt comentariu descriptiv relativ la motivul delegarii . Delegarea poate fi facuta numai de utilizatorul de nivel superior, adica acest proces de delegare poate fi initiat numai de catre utilizatorul ce doreste sa-si delege drepturile .

Delegarea se poate face catre un utilizator sau catre o lista de utilzatori . Pentru fiecare din acesti utilizatori se poate defini si dreptul ca acestia, la randul lor, sa poata delega aceste drepturi mostenite altor utilizatori de pe acelasi nivel ierarhic sau de pe un nivel ierarhic inferior .

Poate sa existe si un sistem de “delegare exceptionala”: numai un utilizator de nivel superior poate sa delege drepturi exceptionale unui utilizator de nivel inferior . Initierea unei delegari execeptionale se face pentru cate o singura operatiune(are legatura cu parola de acces trimisa prin SMS – vezi mai sus) .

Autentificare prin amprenta digitala

Sistemul Retail va putea fi extins pentru a permite interfatarea cu un device de autentificare prin amprenta digitala, identificandu-se astfel fara echivoc persoana care inceraca sa se autentifice in aplicatie .

In cazul in care aceasta persoana are asociata mai multi utilizatori (prin indeplinirea mai multor functii, or prin delegarea primita din partea altor utilizatori) sistemul va afisa o lista de conturi sub care utilizatorul se poate conecta . Acest lucru nu este necesar in cazul in care exista un singur cont asociat, caz in care logarea se va face automat .

Sistemul de “Inchidere Zi”

Utilizatorii care au magazii asociate sunt singurii care pot face transferuri de iesire de pe gestiunea proprie . Pentru ca si Stock Keeper-ul sa aibe acest drept, utilizatorul trebuie sa poata face o “inchidere de zi”, sa marcheze in acest fel incheierea oricaror operatii si sa permita accesul la gestiunea sa .

Pe parcursul zilei, un utilizator de nvel inferior, cu gestiune proprie, poate sa se autentifice si sa faca “LogOff” de mai multe ori, dar abia la sfarsitul programului face “Inchiderea de Zi” . Prima autentificare in aplicatie dupa ce o “Inchidere de Zi” este facuta, declanseaza automat un “Inceput de Zi” si gestiunea utilizatorului respectiv este blocata numai accesului sau .

“Inchiderea de Zi” poate fi facuta:

  • manual, de catre utilizatorul cu gestiune proprie
  • manual, de catre un utilizator de nivel superior (de ex . de catre Seful de Magazin)
  • automat, de catre sistem, la expirarea unei “perioade de gratie”, predefinita

In functie de starea in care se afla gesiunea unui utilizator, se definesc 2 stari posibile:

  • in office – de la prima autentificare pana la “Inchidere Zi”
  • out of office – dupa operarea manuala sau automata “Inchidere Zi” pana la prima autentificare

Numai in perioada “Out of Office” Stock Keeperul va avea dreptul sa opereze transferuri in gestiunea vanzatorului .

Daca un vanzator inca nu a facut “Inchiderea de Zi”, iar cu gestiunea sa se opereaza transferuri, sa fie atentionat printr-un pop-up de genul: “Atentie! Tocmai ti-au fost transferate din/spre stoc, urmatoarele produse: Esti de acord sa le receptionezi/Esti de acord sa-ti fie destocate?”

Daca vanzatorul a facut deja “Inchiderea de Zi”, nu i se mai cere permisiunea, dar este totusi instiintat de transferul ce tocmai a fost operat .

Un utilizator de nivel superior poate alege si fortarea unui transfer pe/de pe stoc in cazul in care un vanzator inca nu a facut “Inchiderea de Zi”, dar nu este inca disponibil pentru a-si da acordul (de ex . e in pauza de masa) . Si in acest caz vanzatorul este atentionat de efectuarea transferului .

De asemenea, vanzatorul catre care se opereaza un astfel de transfer nu-si poate efectua “Inchiderea de Zi” pana ce nu rezolva toate transferurile ce ii asteapta acordul .

In cazul in care o “Inchidere de Zi” este efectuata automat de Sistemul Retail . superiorul ierarhic al vanzatorului trebuie sa fie instiintat de acest lucru .

Mecanismul ce sta in spatele “Inchiderii de Zi” va putea sa fie modificat de utilizatori autorizati (perioada de inactivitate dupa care se efectueaza o “Inchidere de Zi”, activarea/dezactivarea “Inchiderii de Zi” automata, etc . )

Pentru a se incuraja folosirea functiei de “Inchidere Zi”, numai dupa folosirea acestei functii vor aparea rapoartele de sfarsit de zi, rapoarte ce nu sunt disponibile decat intr-o forma partiala (cu un marcaj clar pe raport) daca nu este operata “Inchidere Zi” . Rapoartele in forma completa – ce poate fi predata de exemplu la casieri – sunt accesibile numai unui utilizator de nivel superior . Va exista, deci, un borderou partial si unul final . Borderoul partial va fi folosit pentru plati partiale la casierie in cursul unei zile si va fi marcat corespunzator (de ex . “Exemplar borderou partial”) . Borderoul final marcheaza finalul unei zile de activitate a unui vanzator . In cazul in care acesta mai trebuie sa mai efectueze o vanzare i se va permite sa mai emita un borderou final (pentru aceasta utilizatorul va face o “Inchidere de zi”, o autentificare in aplicatie – operatie ce redeschide ziua de lucru –, o vanzare si apoi iar o “Inchidere de Zi”, in urma careia va putea tipari noul borderou final de incasari) .

Borderoul final nu se poate emite decat daca se face “Inchiderea de Zi” .

Borderoul va afisa valoarea incasarilor cash pe facturi, incasarile pe bonuri de casa precum si totalul incasarilor cash .

Aplicatia nu va permite unui vanzator rularea vreunei noi operatiuni pana ce nu se inchide ziua precedenta, operatiune ce declanseaza emiterea borderoului final pe ziua anterioara .

Audit trail

Sistemul Retail va gestiona un sistem de loguri care vor stoca informatii despre interactiunile utilizatorilor cu Sistemul . Aceste loguri vor fi accesibile pentru consultare utilizatorilor autorizati si nu vor putea fi modificate sau sterse de catre nici un utilizator .

Orice modificare facuta prin aplicatie de catre un utilizator trebuie sa permita identificarea acestuia in mod unic .

Toate actiunile efectuate de catre utilizatorii delegati sa actioneze in numele unui user delegator trebuie sa introduca in log informatii referitoare atat la utilizatorul care face actiunea (utilizatorul delegat) cat si la cel in numele caruia o face (utilizatorul delegator) .

Legaturi cu alte entitati

SHAPE * MERGEFORMAT

Factura

Utilizator

nume, cod, parola, magazin

Stoc

Proforma

Bon fiscal

Magazin

Sistemul va asigura o scalabilitate si flexibilitate in manupularea informatiilor (atributelor) entitatii si va permite operatii de adaugare / modificare / stergere / clasificare / intervale de timp (prin calendare) / valabilitate . Din acest motiv sistemul va asigura un configurator propriu pentru toate categoriile de entitati enumerate .

Entitatea Magazie

O magazie reprezinta o gestiune, un recipient pentru marfa fizica aflata la un magazin sau in gestiunea Orange SA . Fiecare magazie este in mod unic asociata unui magazin, iar fiecare magazin are in mod unic asociat un cod alfanumeric (Codul Jupiter) .

Magaziile pot fi:

  • vizibile (stocul asociat acestor magazii este vizibil din sisteme externe – de exemplu OA – sau din module si mecanisme interne ale Sistemului Retail, de exemplu modulul InfoShops)
  • ascunse – cum ar fi magaziile de tranzit, magazia de SWAP client, sau cele de SAV: stocul asociat acestor magazii nu este vizibil din unele module si mecanisme interne ale Sistemului Retail – cum ar fi modulul InfoShops;
  • speciale – cum ar fi magaziile de rezervari, magazia de SWAP magazin, magaziile de T&T, magazia de Defecte, accesibile din unele sisteme externe – cum ar fi OA – dar inaccesibile din unele module ale Sistemului Retail sau din cadrul unor operatii .

Magaziile pot avea un proprietar (un responsabil asupra stocului aflat in aceste magazii) si sunt asociate in mod unic unui magazin si unei regiuni .

In toate magaziile informatiile depre produse sunt stocate la nivel de serie IMEI, exceptie facand magazia de Rezervari Generale, o magazie in care se rezerva un anumit produs, dar fara sa fie o anumita serie rezervata (de ex . pentru cazurile in care un client face o rezervare prin TeleSales) . Rezervarea se face la nivel de serie in cazul unei proforme, sau in cazul unui transfer intre magazine, de exemplu .

Magaziile vor fi organizate in ierarhii, depinzand de regiune, magazin, tip magazie, etc . Printre atributele importante ale unei magazii se numara si locatorul . Aceasta proprietate identifica sursa marfii disponibila la vanzare si modul in care ea va fi gestionata in OA . Fiecare magazie poate avea locatorul sau: de ex, cel de magazin Orange si cel de consignment (pentru vanzarea in regim de consignatie) . Locatorul va fi parintele ierarhiei de magazii .

Exemplu de ierarhie:

Locator

Regiune (Banat, Ardeal, etc)

Magazin (Europe House, Iasi, Constanta, Arad, etc)

Tip Magazie (vizibila, ascunsa, etc)

Subtip Magazie (magazie vanzator, magazie rezervari, T&T, etc)

FineGrained Subtype (T&T uzate, T&T expuse, Rezervari InfoShops, Rezervari transfer, Rezervari vanzare - locala)

Magazia (Magazie V1AR, Magazie T&T uzate ARAD, etc . )

O magazie poate fi validata sau invalidata, poate fi mutata de la un utilizator la altul, dar numai in cadrul aceluias magazin .

Entitatea Tranzactie

O tranzactie reprezinta o inregistrare a detaliilor unui transfer de marfa in una din urmatoarele situatii:

intre gestiunile magazinelor;

in cadrul gestiunii unui magazin;

transferuri catre WAREHOUSE;

receptii de marfa de la WAREHOUSE;

transferuri catre Service;

receptii din Service;

transferuri pe gestiunea clientului (produse in custodia clientului);

receptii din gestiunea clientului;

Atribute

Printre proprietatile tranzactiilor se numara:

data;

tipul de transfer:

o      intern, intre magaziile magazinului;

o      extern, intre magazine (prin intermediul unei magazii intermediare);

o      receptii de marfa (de la Depozitul Central, sau de la un alt magazin);

o      notele de retur (catre Depozitul Central sau catre un alt magazin);

o      trimiteri in Service;

o      receptii in Service

numarul AIM-ului cu care s-a facut receptia sau returul de marfa (inclusiv catre Service);

magazia de intrare (daca e retur de marfa va lipsi);

magazia de iesire (daca e receptie de marfa va lipsi);

furnizorul sau destinatarul marfii trimise;

numarul comenzii (daca este o receptie de la Depozitul Central in baza unei Comenzi);

motivul transferului (completat dupa caz);

produsele implicate in tranzactie (tip, model, producator, etc . );

seriile produselor;

cantitatea (daca nu au serie, sau este serie de tip de produs);

valoarea asigurata a produsului;

daca este o tranzactie in magazia de defecte (nu cea de SAV Defecte), descrierea defectului reclamat;

detalii legate de expeditor (reprezentatntul firmei de curierat) – in cazul in care este vorba de o tranzactie externa:

o      seria buletinului si numarul buletinului si alte detalii legate de actul de identitate;

o      mijlocul de transport (tip, numar inmatriculare, etc . );

o      numele expeditorului;

numele firmei de curierat – in cazul in care este vorba de o tranzactie externa;

etc .

Transferurile catre WAREHOUSE se fac numai cu acordul Logisticii . Pot contine atat telefoane obisnuite (pe gestiunea de marfa pentru vanzare) , cat si telefoane defecte (DOA – dead on arrival) sau telefoane de SWAP retrase spre casare .

Atat transferurile catre Service cat si receptiile din service se fac numai in baza unui PV de trimitere in Service si un AIM (aviz de insotire a marfii) .

Transferurile pe/din gestiunea clientului se fac in baza unui contract de comodat (de ex . un modem Navini este inchiriat clientilor care incheie si un contract de date, sau un modem Navini poate fi in gestiunea unui client pentru teste, se testeaza posibilitatea interconectarii in retea) .

Fiecare utilizator poate sa-si vizualizeze doar tranzactiile proprii, care se compun pentru a ilustra dinamica propriei sale gestiuni .

Intr-un astfel de acces la tranzactii vor fi afisate date care sa raspunda la intrebarile cine?, ce?, de unde? si unde? – anume utilizatorul care transfera, gestiunea sursa, gestiunea destinatie, cantitatea, produsele .

Legaturi cu alte entitati

SHAPE * MERGEFORMAT

Stoc

Tranzactie

data, tip transfer, aim

Utilizator

Produs

Magazin

Operatori de service

In cazul transferurilor cu Service-ul, trebuie sa fie mentinuta si o lista de Operatori de Service, care sa contina printre altele:

numele Operatorului de Service;

adresa;

CUI (Cod Unic de Inregistrare la Registrul Comertului);

contul bancar si banca Operatorului;

etc .

Sistemul va asigura o scalabilitate si flexibilitate in manupularea informatiilor (atributelor) entitatii si va permite operatii de adaugare / modificare / stergere / clasificare / intervale de timp (prin calendare) / valabilitate . Din acest motiv sistemul va asigura un configurator propriu pentru toate categoriile de entitati enumerate .

Entitatea Magazin

Magazinul este un punct de desfacere si prezentare a serviciilor si produselor oferite de companie .

Atribute

Magazinele pot fi mai multe in acelasi oras sau mai multe in aceeasi regiune fiind definite de:

denumire;

adresa;

numar de fax (trecut pe proforme);

cod Jupiter si OA;

regiunea sau un alt identificator de locatie;

orasul;

locatorul corespunzator Jupiter;

banca si contul in care se fac platile (apare pe proforma, pe langa bancile si conturile companiei);

turneul de aprovizionare de care apartine (turneul de aprovizionare reprezinta regiunea pentru care si data la care se face aprovizinarea cu marfa – de ex . pentru Bucuresti exista dublu turneu: se aprovizioneaza de doua ori pe saptamana si aceasta aprovizionare se face numai pentru Bucuresti);

curierul cu care se receptioneaza marfa de la WAREHOUSE;

informatii legate de aprovizionare (vezi mai jos);

etc .

Magazinele pot fi impartite pe zone geografice, pot fi corelate cu o localitate si un turneu, pot fi Corporate sau Retail . Pot avea asociate oferte si discounturi .

Magazinul, la definire, va contine si informatii legate de aprovizionare . Fiecare magazin va avea o zi din saptamana asociata, reprezentand ziua cea mai tarzie in care trebuie incheiata o comanda si trimisa Logisticii . De asemenea, magazinul va avea asociata si o perioada de alimentare (intervalul existent intre 2 comenzi succesive) .

Magazinele definite in sistem vor avea asociata si o valoare procentuala pana in care pot depasi valoare de stoc a tranzactiilor efectuate de la ultima comanda . Va exista un procentaj implicit de depasire a comenzii, modificabil pentru fiecare magazin .

Magazinele au asociate sub-inventare (o lista de magazii) pe care utilizatorii autorizati le alimenteaza cu produse din stocul magazinului .

Legaturi cu alte entitati

SHAPE * MERGEFORMAT

Stoc

Magazin

denumire, adresa,

Utilizator

Factura

Client

Tranzactie

Sistemul va asigura o scalabilitate si flexibilitate in manupularea informatiilor (atributelor) entitatii si va permite operatii de adaugare / modificare / stergere / clasificare / intervale de timp (prin calendare) / valabilitate . Din acest motiv sistemul va asigura un configurator propriu pentru toate categoriile de entitati enumerate .

Entitatea Plan tarifar

Planurile tarifare reprezinta tipurile de abonamente oferite de Orange Romania . Fiecare plan tarifar are asociata o lista de optiuni dintre care clientul, in momentul semnarii contractului de abonament, sau ulterior, poate alege variante, in functie de o matrice de compatibilitate intre optiuni .

Planurile tarifare pot influenta si preturile finale sub care un client poate face achizitii din magazine .

Planurile tarifare depind si de tipul clientului – exista planuri tarifare dedicate anumitor tipuri de clienti, aplicatia trebuie sa nu permita “accesul” unui client la planuri tarifare ce nu ii pot fi asociate .

Planurile tarifare sunt introduse in sistem fie printr-o procedura de import din sisteme externe (sistemul CRM), fie manual de catre un user ce are dreptul la aceasta operatiune .

Sistemul va asigura o scalabilitate si flexibilitate in manupularea informatiilor (atributelor) entitatii si va permite operatii de adaugare / modificare / stergere / clasificare / intervale de timp (prin calendare) / valabilitate . Din acest motiv sistemul va asigura un configurator propriu pentru toate categoriile de entitati enumerate .

La importul unui plan tarifar din Vantive, i se va atasa si o informatie de tip . Aceasta va fi intretinuta o lista de tip-uri de planuri tarifare, si fiecarui nou plan tarifar i se va asocia o singura valoare din aceasta lista . Pentru tipuri compuse (de ex . Voce + Date) se vor genera noi tipuri de planuri tarifare .

Entitatea TVA

Sistemul Retail trebuie sa permita co-existenta mai multor valori pentru TVA, dintre care unul singur este cel implicit . Un TVA poate fi sau nu valid, dar cel implicit nu poate fi invalid .

Este taxa ce afecteaza toate vanzarile, toate preturile din aplicatie, in afara de pretul punctelor TY, care sunt calculate cu TVA .

Atribute

Definit de:

descriere taxa;

valoare TVA;

indentificator de TVA “default” – daca este sau nu un TVA default;

cod TVA (pot avea de exemplu TVA_DEBT si TVA_0, ambele codificari pentru un TVA cu valoare 0) – acest cod se importa din sistemele externe catre care ajung vanzarile si reprezinta cota TVA ce o plateste un client (este preluata din OA – de ex . TVA 19% si Scutit DED);

valid/invalid .

Cotele de TVA vor avea asociate coduri speciale, folosite in exportul catre OA . In functie de categoria clientului, o cota de TVA va fi aleasa implicit pe factura (existand si posibilitatea schimbarii ei manuale) .

Cotele de TVA folosite vor fi corespunzator marcate pe factura tiparita (la nivel de linie de factura sau la nivel de factura) .

Sistemul va asigura o scalabilitate si flexibilitate in manupularea informatiilor (atributelor) entitatii si va permite operatii de adaugare / modificare / stergere / clasificare / intervale de timp (prin calendare) / valabilitate . Din acest motiv sistemul va asigura un configurator propriu pentru toate categoriile de entitati enumerate .

Entitatea Curs valutar

Reprezinta rata de schimb pentru valuta sau valutele in care sunt introduse preturile din aplicatie . Zilnic, aceasta rata de schimb este actualizata pentru a corespunde cursului dictat de Banca Nationala a Romaniei . Trebuie sa existe si o lista de valute, dintre care una sa fie cea implicita, adica valuta curenta .

Atribute

Definit de:

valuta la care se raporteaza leul;

rata de schimb (o unitate monetara a valutei = cati lei);

data ratei de schimb;

etc .

Actualizarea cursului

Actualizarea cursului trebuie sa se faca fie automat, fie manual (dar numai de catre un utilizator de nivel superior ierarhic peste tot canalul Retail si /sau Corporate), ca solutie de rezerva in cazul in care nu este accesibila nici o metoda automata de actualizare . Accesul la aceasta optiune va fi drastic restrictionat .

Cursul trebuie sa pastreze si un istoric de evolutie de-a lungul timpului, se vor face doar adaugari .

Tipuri de curs valutar

Sistemul Retail va permite sa se poata introduce pe perioade de valabilitate diferite tipuri de curs:

  • curs fix la nivel de zi,
  • curs mediu pe o perioada de timp,
  • curs calculat conform unei formule pe perioada de timp pe care aceasta este definita, formula ce va fi stabilita in momentul in care cursul nu se va mai tine zilnic ci mediu, pe o perioada . ;
  • alte tipuri

La orice moment dat trebuie sa existe un singur tip de curs activ in Sistem .

Sistemul va asigura o scalabilitate si flexibilitate in manupularea informatiilor (atributelor) entitatii si va permite operatii de adaugare / modificare / stergere / clasificare / intervale de timp (prin calendare) / valabilitate . Din acest motiv sistemul va asigura un configurator propriu pentru toate categoriile de entitati enumerate .

Procese si functionalitati ale noului Sistem Retail

Vanzarea

SHAPE * MERGEFORMAT

Produs

Discount

Pret

Lista conditii

aplicare discount

Lista conditii aplicare pret

Factura

Produs

Discount

Pret

Produsul in centrul vanzarii

In centrul activitatii de vanzare se afla produsul . Pretul cu care este vandut un produs poate fi compus dintr-un pret de baza si un set de discounturi ce se acorda in functie de indeplinirea unui set de conditii asociat fiecarui pret si fiecarui discount . Un discount poate fi constrans de:

produs;

pachet;

client;

locatie (magazin, regiune, canal: Retail/Corporate);

factura;

perioada (zi, ora, luna);

etc .

La momentul efectuarii vanzarii, in functie de o multime de parametri ce intra in compunerea setului de conditii pentru fiecare pret respectiv discount care poate fi asociat cu produsul selectat, vanzatorului i se va prezenta o lista de preturi si discounturi permise iar dintre acestea, vanzatorul implicat in procesul de vanzare poate alege sa acorde sau nu anumite discounturi .

Pretul final este obtinut din pretul initial la care se pot adauga o multime de discounturi .

Seturi de conditii pentru discount si pret

In setul de conditii asociat unui discount sau unui pret, se includ:

zona geografica si/sau orasul din care face parte magazinul;

intervalul de timp in care este cumparat produsul(ora, zi, luna, an);

magazinul in care are loc vanzarea;

client:

o      abonament si plan tarifar;

o      optiuni ale abonamentului;

o      vechimea abonamentului;

o      perioada contractuala;

o      numarul de subscriberi;

o      tipul clientului (private, bussiness);

o      istoricul sau (cesiuni incheiate, trimiteri in service, schimburi de SIM sau de terminal, etc . );

o      detalii client (nume, varsta, domiciliul, etc . );

o      migrarea clientului de la operatorii concurenti (Vodafone, Zapp, etc . );

o      numar de noi subscriberi adusi in retea de catre client;

produs

o      tipul produsului;

o      valoarea produsului;

o      numarul produselor;

o      dicount pe un pachet de produse si/sau servicii

factura:

o      valoarea facturilor anterioare la produse si/sau servicii;

o      plata la timp a facturior anteriore;

o      valoarea facturii curente (ex . discount pentru achizitii de peste 200€);

o      modul de plata(credit card, cach, etc . );

discounturile anterioare de care a beneficiat clientul;

altele

Nota:

Intre conditiile asociate unui pret, trebuie neaparat sa se specifice un produs caruia ii este asociat acel pret . Acest lucru nu este neaparat necesar in cazul unui discount (cu alte cuvinte, se pot defini discount-uri care nu sunt asociate unui produs anume, insa preturile trebuie neaparat legate de un anume produs) .

Vanzatorul va fi avertizat in cazul in care clientul face o achizitie incompatibila cu produsele/serviciile achizitionate anterior (ex . : a cumparat un terminal fara GPRS si are activat serviciul) si ii sunt sugerate solutii de produse/servicii alternative:

un terminal mai performant, care sa profite de optiunile activate ale abonamentului;

un alt accesoriu, in functie de modelul de terminal ales;

un serviciu de reincarcare de valoare mai mare, in cazul in care se observa ca acest client are consum mare;

noi optiuni la abonamentul sau existent;

In functie de conditiile enumerate mai sus se pot acorda o serie de discounturi iar vanzatorul are libertatea de a alege dintre acestea pe care sa le acorde sau daca sa le acorde pe toate cele disponibile . Din lista de discounturi ce pot fi acordate, vanzatorul trebuie sa deselecteze doar acele discounturi pe care nu vrea sa le acorde (nu e obilgat sa le acorde pe toate) .

Fiecare proces de vanzare are atasat o serie de factura sau un bon de casa de marcat . Sistemul Retail va permite ca seriile de facturi sa fie generate automat in functie de magazinul in care se genereaza vanzarea (in cazul in care din punct de vedere contabil acest lucru este permis), altfel vanzatorul este cel ce introduce in sistem seriile facturilor, conform cu pretiparitele .

In cazul in care sistemul Vantive este inaccesibil, vanzarea prin fidelizare poate fi finalizata in regim de operare manuala – Sistemul Retail va implementa si un sistem de validare a operarilor manuale cu Vantive-ul, pentru ca tranzactiile din cele doua sisteme sa fie consistente . In cazul in care o tranzactie manuala de fidelizare nu este acceptata de Vantive, un utilizator de nivel corespunzator este anuntat (fie pe e-mail, fie la autentificarea in sistem) de aparitia acestei situatii si i se ofera posibilitatea de a storna factura emisa in aceste conditii sau de a forta factura in Sistemul Retail – in acest caz factura ramane marcata ca invalidata de Vantive, dar fortata in Sistemul Retail . In cazul in care o fidelizare manuala esuata in Vantive este stornata, storna nu se mai exporta catre Vantive .

Procesul de vanzare poate importa si devize de plata din eService, caz in care se va importa o singura linie de detaliu ce va contine suma totala a devizului emis din eService . Conditiile de acordare a vreunui discount suplimentar pot fi stabilite prin asocierile produse – discounturi (taxa de service este si ea un tip de produs) . Impreuna cu formularul de factura, se va tipari si un formular de deviz de reparatii si costuri, conform cu datele importate din eService .

Pe o factura pot apare oricate discounturi, cu conditia ca acestea, insumate, sa nu depaseasca pretul produsului

Fidelizarea

Fidelizarea (programul Orange Thank You) este un proces de loializare dedicat in exclusivitate abonatilor Orange activi in retea prin care acestia pot sa beneficieze de preturi speciale la achizitionarea unui telefon . Cu aceasta ocazie clientul isi exprima in mod expres acordul de a continua relatia contractuala cu Orange Romania S . A . pe o perioada de cel putin 12 luni .

O fidelizare nu poate fi facuta decat daca clientul are minim 12 luni de la activare si daca are mai mult de 12 luni de la ultima fidelizare (informatii ce se vor importa din Vantive) . Aceste reguli pot fi fortate de un utilizator de nivel superior (un shop manager), dar numai in Vantive (posibil inca ca si din Sistemul Retail sa se poata forta o astfel de operare, dar numai de catre un utilizator de nivel superior) . Dupa ce o astfel de fortare a fost efectuata se poate revalida tranzactia in Sistemul Retail . Aceasta fortare modifica detaliile unui client in Vantive pentru a i se putea efectua o noua loializare . Fortarea returneaza succes sau esec, in caz de esec fiind necesara operarea manuala in Vantive a operatiunii de fortare .

Exista cazuri in care o loializare nu poate fi operata in Vantive si totusi ea sa poata fi operata in Sistemul Retail .

Va trebui deci sa existe si un mecanism de loializare manuala fortata in Sistemul Retail, aceesibil numai utilizatorilor de nivel superior, dar acest mecanism va duce si la instiintarea utilizatorilor de niveluri superioare . O astfel de tranzactie asteapta inca o aprobare inainte sa fie considerata incheiata .

Vor fi afisate toate numerele pe care un client poate sa faca o fidelizare (grupate cate x – pentru a nu incarca interfata cu prea multe detalii) . Va fi afisata data la care a facut ultima fidelizare pentru numerele pe care nu mai poate sa faca fidelizare

Un utilizator de nivel superior, (de ex . Shop Managerul) daca are posibilitatea de a forta in Vantive o tranzactie de fidelizare, va avea o interfata prin care sa poata realiza acest lucru . Odata ce fortarea a fost acceptata de Vantive (daca va fi posibil sa se implementeze aceasta fortare) orice utilizator de nivel Vanzator poate sa efectueze in conditii normale fidelizarea dorita . O astfel de fortare poate fi realizata numai de catre un utilizator de nivel Shop Manager sau de catre un utilizator ce-si asuma (daca are dreptul) rolul de Shop Manager . Acest utillizator este complet raspunzator de tranzactia fortata in Vantive .

Daca Sistemul Vantive este inaccesibil si se opereaza o vanzare fidelizare/retention in mod manual, cu prima ocazie in care Vantive-ul este disponibil se verifica tranzactia operata in mod manual . Daca aceasta a esuat, utilizatorul de nivel Shop Manager este anuntat printr-un pop-up – in acest caz el poate decide sa forteze tranzactia in Vantive (daca e cazul, daca se poate) sau sa storneze factura .

Punctele OTY vor fi acordate la nivel de factura dar vor fi asociate numai tranzactiei de fidelizare din care provin (daca pe aceeasi factura avem o fidelizare si o achizitie, punctele TY trebuie sa acopere numai valoarea corespunzatoare fidelizarii) .

Vanzarea la Abonament

Vanzarea la abonament este procesul prin care un nou client Orange este introdus in Sistem, sau un client existent isi extinde flota (isi mai adauga un numar de telefon, un subscriber) . Pretul asociat unei vanzari la abonament poate fi unul subventionat de Orange, prilej cu care clientul poate sa achizitioneze un produs la un pret redus . Un produs nesubventionat este un produs de nu beneficiaza de nicio reducere, indiferent de tipul de vanzare

In urma unui nou abonament de obicei se ofera clientului si un SIM . Scaderea din gestiune a unui SIM se poate face manual sau prin import din ePOS . Scaderea manuala este mereu verificata sa fie corespunzatoare cu importul din ePOS (daca in momentul in care s-a incercat scaderea manuala nu era accesibil ePOS-ul) .

Vanzari tip Retention

Sunt vanzari de tip loializare in scopul de a determina clientul sa-si mai prelungeasca contractul cu Orange Romania SA . Aceste vanzari pot fi importate din Vantive, la fel ca o fidelizare normala .

Vanzarea la liber

Vanzarea Standard presupune ca orice telefon poate fi vandut la pretul sau standard, cu sau fara un pachet PrePay .

In categoria vanzare la liber intra si vanzarile efectuate de pe casa de marcat .

Vanzarea de pe casa de marcat se poate efectua fie din magazia de accesorii, fie din magazia proprie a vanzatorului

Vanzarea cu credit bancar

Vanzarea cu credit bancar se aplica numai anumitor tipuri de vanzari (de ex . vanzarilor de telefoane impreuna cu un pachet PrePay) si presupune achitarea din partea clientului numai a unui procentaj din suma totala de plata, restul fiind platit la banca .

Factura fiscala se va emite pe intreaga suma, adica facturarea se va face pe intreaga suma, dar chitanta de incasare se va efectua numai pe suma corespunzatoare procentajului din valoarea totala .

Va exista un formular special pentru aceste facturi, formular ce va contine si detalii suplimentare legate de creditul bancar contractat .

Vanzarea cu credit bancar presupune numai incasari cash sau prin carte de credit (nu si prin Ordine de Plata) .

Vanzarea la termen

Facturarea la termen presupune emiterea unei facturi din Sistemul Retail fara destocarea produselor, si care este considerata inchisa in momentul in care clientul aduce dovada platii (sau face achitarea produselor) – aceasta forma de facturare este disponibila numai clientilor bugetari .

La salvarea unei astfel de facturi, catre OA se genereaza o tranzactie speciala (marcata in mod special ca vanzare la termen) care nu produce destocare ci numai incasare . In Registrul de Casa se va inregistra o incasare numai daca aceasta factura este achitata cash si numai la inchiderea ei . Tipul acesta de factura va fi marcat si in clar, pe exemplarul tiparit .

La inchiderea unei astfel de facturi catre OA se mai emite o tranzactie, care de data asta va produce o destocare (dar nu si un income) .

La stornarea unei astfel de facturi catre OA trebuie emisa o tranzactie speciala, de anulare a sumei trecute pe factura, tranzactie care, din nou, nu va produce repuneri pe stoc .

La expirarea termenului in care clientul trebuie sa achite suma (termen modificabil din Sistemul Retail de un utilizator de nivel superior) Sistemul Retail avertizeaza utilizatorul de nivel Shop Manager si acesta pooate decide sa storneze aceasta factura .

In raportul de Facturi Emise (vizibil contabilitatii) acest tip de factura va fi marcat in mod vizibil .

Optional, la emiterea unei astfel de facturi, se pot trimite e-mail-uri persoanelor interesate .

SHAPE * MERGEFORMAT

1 . Selectie CLIENT

2 . Tip Oferta:

- Achizitie

- Fidelizare

- Retention

2 . Oferta Standard

3 . Selectie Plan Tarifar

4 . Selectie Prelungire Contractuala 12/24

5 . Selectie Produs

sau

Selectie Discount

Import din ePOS

Import din Vantive

Introducere manuala

3 . Selectie Produs

Figura SEQ Figura * ARABIC - Vanzarea - Desfasurarea unui proces de Vanzare

Gestiunea stocurilor

Una din functiile de baza ale Sistemului Retail este gestiunea stocurilor . Prin aceasta functie sistemul va realiza urmatoarele :

va permite transferuri intre gestiuni interne (in cadrul aceluias magazin) si externe (la nivel inter-magazine si WAREHOUSE);

va permite realizarea de comenzi catre WAREHOUSE si alte magazine;

va intretine stocul in urma unor vanzari, schimburi de produse;

va mentine lista de produse defecte din magazin;

va mentine lista de terminale si accesorii defecte din magazin (fiecare produs primit defect de la client spre a fi trimis in service) .

Sistemul Retail va permite definirea unei limite minime in stoc la nivel de produs si magazin . In momentul scaderii stocului sub aceasta limita Sistemul Retail va include in comanda generata automat si produsele ce respecta aceasta conditie .

Sistemul va prezenta utilizatorului numarul mediu de produse vandute la nivelul intregului magazin in intervalul de timp dintre doua comenzi, sau intr-un interval de timp prestabilit, la alegere .

Stoc minim

Definirea pentru fiecare produs de pe stoc a unui stoc minim, considerat stoc de avarie . Acest stoc minim este luat in considerare de mecanismul de generare Comanda Electronica si modulul HelpLine (daca un magazin are un produs pe stoc de avarie, nu se vor mai face comenzi InfoShops pe acest produs la magazinul respectiv) .

Interfata de stoc minim contine o lista cu toate produsele de pe stoc, cu un stoc minim asociat . O bifa va fi prezenta pentru cazurile in care stocul minim nu conteaza (temporar este invalidat stocul de avarie, de exemplu) .

Produsele ce nu se mai afla pe stoc sunt eliminate din lista de stoc minim dupa o anumita perioada, modificabila (o perioada egala cu 0 inseamna ca produsul este eliminat din lista de produse pe stoc minim imediat de dispare de pe stoc) . Stocul minim tine cont numai de produsele de pe stocul disponibil (magaziile vizibile) .

Sistemul de Rezervari

Rezervarea presupune:

  • blocarea unei cantitati
  • transferul unor serii (egale ca numar cu cantitatea rezervata)
  • se poate materializa rezervarea intr-o tranzactie sau aceasta se poate anula .

Initierea unei rezervari presupune numai selectarea unei cantitati de produse – la final se trece rezervarea in status “Pending” . Rezervarea in status “Pending” are un deadline pana la care trebuie sa fie aprobata . Inainte de validarea acesteia trebuie selectate si seriile produselor rezervate (daca e cazul, daca produsul este cu serie) . La validare, o rezervare se trece in status “Reserved” .

Rezervarea se face la nivelul unei magazii (chiar si cea cantitativa – fiecare utilizator are asociata o magazie sau poate sa aleaga dintr-o lista o anumita magazie) . In cazul unei rezervari facute de InfoShop se foloseste magazia magazinului . Daca rezervarea se face intern, trebuie sa se aleaga si magazia din care se rezerva, sau magaziile din care se rezerva produsul (cu cantitatile corespunzatoare) .

Daca s-a atins deadline-ul (nu s-a modificat statusul in “Reserved”) sa fie “notificat intr-un mod violent” utilizatorul de expirarea deadline-ului rezervarii . Utilizatorul poate apoi sa opteze pentru prelungirea deadline-ului sau pentru anularea rezervarii .

Comanda electronica

Comanda este generata automat de catre aplicatie si va fi manipulata (adaugare, modificare sau stergere produse si cantitati), validata si trimisa la departamentul Logistica de catre persoana imputernicita cu aceste drepturi (shop manager) . Sistemul Retail doar face o sugestie, shop managerul este cel ce aproba si timite comanda . Daca este vorba de o comanda adresata altui magazin, atunci comanda trebuie sa fie validata si de shop-managerul acestuia (sau o parte din ea sa fie validata) .

Exista o legatura intre Logistica (in speta OA) si aplicatie: comanda este trimisa direct catre sistemul de gestiune din OA si apoi, la primirea marfii, se face si importul in aplicatie, conform cu AIM-ul trimis de sistemul de gestiune din OA catre aplicatie . Acest import se face de catre shop-manager in momentul in care in magazin ajunge si marfa trimisa prin transportator .

Mecanismul din spatele Comenzii Electronice trebuie sa faca sugestii in mod automat, sugestii modificabile de catre un utilizator autorizat (adaugare, stergere, modificare)

  • Sugestiile se pot referi la produsele de pe stocul curent;
  • Sugestiile se pot referi la produsele noi (aparute de curand pe stocul WAREHOUSE retail channel, dar produse ce sunt introduse in Sistemul Retail - produsele de pe stocul WAREHOUSE Retail Channel neintroduse in Sistemul Retail nu sunt vizibile mecanismului de intretinere Comenzi Electronice . ) .

Sugestiile de Comanda Electronica vor contine produse si cantitati asociate, pe care utilizatorul le va bifa daca sunt corecte din punctul sau de vedere (sugestiile ne-bifate nu vor face parte din noua comanda) .

Orice comanda sugerata de Sistemul Retail va permite modificari din partea shop managerului .

Printre sugestiile Comenzii Electronice sa se afle si produse ce inca nu au aparut pe stocul vreunui magazin (introduse in Sistemul Retail mai recent de ultima comanda) . Aceste produse vor aparea in sugestia de comanda cu stoc 0 .

Shop managerul sa fie notificat de validare/invalidarea comenzii de catre Logistica . In cazul in care o comanda aprobata si creata de Logistica difera de cea initiata in Sistemul Retail, shop managerul sa fie notificat .

Sugestiile de Comanda Electronica vor tine cont de un set de reguli precum:

  • stoc minim
  • miscarea pe stoc (dinamica stocului) – vanzari raportate la cantitatea existenta pe stoc – dinamica este individuala, orice produs are propria dinamica .
  • perioada de calcul a dinamicii stocului
  • perioada de alimentare a stocului (pentru unele magazine perioada este mai scurta)

Cand se face analiza dinamicii stocului, produsele rezervate vor fi considerate deja ca fiind tranzactionate .

Un flux aproximativ al comenzi electronice este:

  • propunere Sistem Retail;
  • validare Shop Manager;
  • push Logistica (comanda este aprobata de Logistica si urmeza doar sa fie importata in OA);
  • import Comanda in OA;
  • analiza diferente;
  • (vezi figura 8 pentru detalii)

Utilizatori ai departamentului Logistica vor putea sa vizualizeze comenzile din Sistemul Retail, nou create si validate de Shop Manager, si vor putea sa le ajusteze . Ajustarea poate presupune:

  • modificare cantitate linie comanda
  • inlocuire produs
  • adaugare produs nou
  • stergere produs

O comanda nu poate fi ajustata de Logistica atat timp cat nu este inca validata de un utilizator cu rol de Shop Manager .

Utilizatorii Sistemului Retail, responsabili cu crearea comenzilor (nivelurile Stock Keeper si Shop Manager) va fi asistati in acest proces de informatii suplimentare disponibile printr-un modul ‘Helper’ (accesibil in cadrul Sistemului Retail) . Acest modul presupune afisarea diverselor informatii legate de produsul dorit (depinde de caracteristicile de produs introduse – inclusiv informatiile de linie de produs, daca sunt disponibile) .

Utilizatori autorizati, din partea departamentului Logistica, pot crea o comanda noua, fara sa mai necesite acordul explicit al Shop Managerului . Acest tip de comanda va putea fi generata de la zero de catre utilizator, sau poate fi intocmita in baza sugestiei Sistemului Retail .

Fiecare linie de comanda poate avea si comentarii asociate: comentarii din partea Shop Managerului sau comentarii din partea utilizatorului din departamentul Logistica .

Starea unei comenzi importate in OA poate fi vizualizata din Sistemul Retail:

  • comanda validata
  • comanda trimisa
  • comanda respinsa
  • comanda modificata
  • etc .

Sugestia Sistemului va fi insotita si de un motiv pentru care acest produs a fost ales sa faca parte din noua comanda (va exista o lista fixa de motive invocate de Sistem) .

Se va calcula si o valoare estimativa a comenzii (in baza valorii de inventar – accesibila din OA) si se va compara cu volumul tranzactiilor (cantitatile inmultite cu valorile de inventar salvate in sistem la momentul importului de marfa din OA) . In calculul estimativ, volumul tranzactiilor este cel general, nu se tine cont de tranzactiile efectuate pe produsele din comanda . Volumul tranzactiilor se calculeaza pe intervalul dintre doua comenzi .

Valoarea estimativa a comenzii insumeaza valorile de inventar ale produselor ce se vor comanda .

In cazul in care valoarea comandata depaseste valoarea tranzactionata cu un procentaj mai mare decat cel stabilit in sistem, va trebui completat un motiv de depasire a valorii comenzii (motivul va fi atasat la nivel de comanda) . Declararea unui procentaj cu care valoarea comenzii are voie sa depaseasca valoare tranzactionata in magazin . Procentajul este specific fiecarui magazin . Procentajul de depasire este modificabil pentru fiecare magazin de catre un utilizator autorizat .

Pentru un model de interfata vezi Figura 6 si Figura 7 .

SHAPE * MERGEFORMAT

Produs

Cantitate

Val . Stoc

Val . Vanzari

TOTAL:

215

18,500

15,300

Add

Delete

Edit

25

1,253

1,500

Figura SEQ Figura * ARABIC - Comanda Electronica - Detalii de interfata

SHAPE * MERGEFORMAT

Confirmare depasire

Motiv:

Text:

OK

Cancel

Figura SEQ Figura * ARABIC - Comanda Electronica - Confirmarea de depasire cota valorica

Raport comparatie comanda emisa / livrata

Sistemul Retail va genera si un raport in cazul in care comanda emisa initial nu se regaseste integral in marfa primita . Raportul va evidentia diferentele intre comanda emisa si cea livrata in urmatoarele aspecte:

  • linii noi (produse care nu au fost comandate dar au fost primite pe comanda)
  • linii lipsa (produse care nu au fost trimise de loc)
  • linii modificate (in care cantitatile nu sunt aceleasi)

In functie de produs sau de tipul acestua, Sistemul Retail va permite si introducerea unor perioade maxime de timp in care un produs e acceptabil sa ramana netranzationat (nevandut, ne-transferat extern) . In cazul depasirii acestei perioade, shop-managerul (sau un utilizator autorizat) va fi avertizat de depasirea acestei perioade . Monitorizarea dinamicii de stoc se va face la nivel de produs, nu si la nivel de serie .

SHAPE * MERGEFORMAT

Sugestie

Sistem Retail

Modificare Comanda

Import

marfa din OA

modificare cantitate

stergere produse

adaugare produse

modificare produse

validare comanda

Push Logistica

OA

Procesare

comanda in OA

Import automat in OA

Analiza diferente

intre comanda initiala si importul din OA

Sistem Retail

OA

Sistem Retail

Set Reguli

Verificare

Status Comanda

(inclusiv detaliile comenzii)

Cote Fixe

Sugestie

Sistem Retail

Validare

Shop Manager

Figura SEQ Figura * ARABIC - Comanda Electronica - Principiul de functionare

In momentul in care modifica comanda, Shop Managerul trebuie sa poata vizualiza in dreptul fiecarei linii de pe comanda daca exista sau nu in stocul Oracle Applications (fara a se specifica insa cantitatea existenta in OA, pentru a nu influenta decizia Shop Managerului in legatura cu cantitatea comandata) .

Mecanismul de generare comenzi va genera automat sugestii de comanda catre WAREHOUSE in conditiile de mai jos:

  • calculand dupa anumite formule prestabilite sau definite de utilizator evolutia viitoare a stocului, functie de vanzarile anterioare, de transferurile efectuate, de schimburile din magazin, de proformele emise sau de produsele blocate pe stoc (rezervate); .

Mecanismul din spatele gestiunii stocurilor trebuie sa avertizeze shop-managerul in cazul in care volumul unor stocuri atinge cote critic de joase, si sa poata modifica aceste valori sau sa elimine aceasta optiune de avertizare .

Cote fixe (impartire stocuri la nivel de magazin)

Din interiorul Sistemului Retail, marfa disponibila in OA, in cazul in care nu este suficienta pentru a satisface necesitatile magazinelor va putea fi impartita in cote la nivel de magazin (si fiecare magazin va primi un procent din cantitatea totala) . Aceste cote vor fi stabilite pentru fiecare transa in care marfa intra in stocul OA . Cu alte cuvinte, pentru o anume transa intrata in stocurile OA un anume magazin ar putea primi o cota fixa (numita si split), stabilita de utilizatorul specializat in aceasta operatiune . Pot exista insa si transe de intrare marfa in stocuri OA care nu sunt supuse unor asemenea cote, caz in care nu se aplica restrictiile impuse prin sistemul de cote fixe (marfa este suficienta si nu se justifica o impartire “rationalizata”) .

Fiecare magazin, pentru fiecare produs, va avea limita sa de comanda din WAREHOUSE .

Sistemul Retail va trebui sa tina cont de cotele definite in asa fel incat sa nu permita comandarea din transa din care se importa marfa a unei cantitati mai mari decat cea stabilita prin cota .

Cotele for fi intretinute de catre un utilizator autorizat al Sistemului Retail, pe baza informatiilor importate din Oracle Applications (informatii legate de stocurile disponibile) . Cotele se vor stabili la nivel de produs si transa .

Pentru fiecare produs (linie) de pe comanda, valoarea dorita se va salva in sistem, independent de valoarea permisa (care ar putea fi mai mica din cauza cotelor stabilite pentru acel produs) . Diferenta (daca exista) se va constitui ca si sugestie pentru urmatoarea comanda .

Ciclul de viata al comenzii

Ciclul de viata al unei comenzi este urmatorul:

SHAPE * MERGEFORMAT

1 . Sugestie sistem

2 . Modificare

3 . Validare

4 . Import automat in OA

5 . Procesare in OA

6 . Validare in OA

7 . Import in Sistem Retail

8 . Raport Diferente

Etapele unei comenzi

O comanda trece prin urmatoarele etape:

1 . Sugestie sistem – sistemul analizeaza o serie de reguli dupa care face o sugestie de produse si cantitati de comandat din depozit

2 . Modificare – Shop Managerul are dreptul sa modifice sugestia facuta de catre sistem, adaugand linii, stergand/adaugand linii de pe comanda sau modificand cantitatile propuse de catre sistem

3 . Validare – Shop Manager-ul valideaza comanda in Sistemul Retail

4 . Import automat in OA – Sistemul Retail va exporta automat comanda in Oracle Applications, unde va fi introdusa in starea “Entered”

5 . Procesare in OA – comanda este procesata in Oracle Applications de catre Logistica

6 . Validare in OA – comanda este validata in Oracle Applications si este gata pentru import in Sistem Retail

7 . Import in Sistem Retail – la momentul cand marfa apare la magazin, comanda este importata in Sistemul Retail .

8 . Raport diferente – dupa importul comenzii in Sistemul Retail, se va genera un raport cu neconcordantele intre comanda emisa si cea livrata . Diferentele aparute vor putea constitui input (ca si sugestie) pentru urmatoarea comanda .

Bursa inter-magazine

In cadrul mecanismului de gestiune a stocurilor sa existe si o “bursa” a stocurilor: magazinele care au un suprastoc sa poata declara unele produse ca fiind disponibile pentru a fi preluate de alte magazine care au un stoc insuficient . Bursa inter-magazine este accesibila tuturor magazinelor si permite transferuri de marfa intre acestea

Utilizatorii responsabili cu stocul (sau dintr-o anume categorie) vor primi o notificare in cazul in care apar produse noi pe bursa sau in cazul in care oferta pe care au publicat-o pe bursa a fost acceptata de un magazin . In momentul in care o oferta sau o cerere noua apare in sistem, magazinele sa fie informate printr-o notificare (vizibila utilizatorilor responsabili cu stocul) . Informarea este adresata unui singur magazin in cazul in care acesta este specificat ca destinatar, altfel notificarea ajunge la toate magazinele .

Cererile si ofertele de pe bursa pot fi:

  • private (se adreseaza unui anume magazin)
  • publice (toate magazinele pot vizualiza postarea)

Pe bursa pot fi postate cereri si oferte de produse . Proprietatile unei cereri/oferte:

  • produsul
  • cantitatea
  • magazinul adresat (optional – pentru cazul in care este adresat un magazin anume)
  • intervalul de valabilitatea a cererii/ofertei

Valabilitatea unei cereri sau oferte va putea fi prelungita (sau restransa), sau poate fi retrasa cu totul de pe bursa . O oferta poate fi de asemenea prelungita pe termen nelimitat (adica pana la epuizarea stocului pus la dispozitie pe bursa) .

Cererea/oferta este modificata in functie de gradul in care este satisfacuta: cantittatea ceruta este diminuata pe masura ce sunt receptionate produse (sau cererea dispare cu totul daca este facut un transfer pe toata suma) si cantitatea ofertata este diminuata pe masura ce sunt trimise produse (sau dispare cu totul daca un magazin cere tot stocul de produse publicate pe bursa) .

Cererea si Oferta poate fi considerata satisfacuta si daca inca nu s-au epuizat cantitatile publicate pe bursa, la cererea utilizatorului, altfel aceasta va ramane marcata ca nesatisfacuta . De asemeni, o cerere poate fi satisfacuta si de o cantitate ce o depaseste este insa necesar acordul din partea magazinului ce receptioneaza .

Sistemul Retail trebuie sa puna la dispozitie Shop Managerilor posibilitatea de a alege sa-si puna sau nu la dispozitia celorlalte magazine unele produse care sunt in suprastoc, si sa existe un sistem automat de sugerare a numarului de teminale pe care sa le marcheze disponibile pentru “bursa” .

Transferul produselor dintr-un magazin in altul trebuie sa se inregistreze automat in Oracle Applications pentru ca acestea sa fie transferate in subinventarul corect printr-un subinventar de transfer (sau de tranzit) .

Cesiunea

Operatia de cesionare consta din punct de vedere functional in inchiderea contractului Cedentului si deschiderea unui contract nou (pentru Cesionar) . Cesiunea este un proces de transfer al unui contract de la un client Orange Romania (Cedent) la un client nou sau existent (Cesionar) .

Pentru a se incheia o cesiune trebuie cunoscute:

planul tarifar(planurile tarifare) al cedentului si optiunile asociate;

planul tarifar(planurile tarifare) si optiunile dorite de catre cesionar;

compatibilitatile dintre planurile tarifare acceptate de catre cesionar si noile optiuni dorite de catre acesta .

compatibilitatile dintre optiunile existente si cele suplimentare dorite de catre cesionar;

detalii privind particularitatile planurilor tarifare alese de catre cesionar (ex . : numere favorite);

serviciile suplimentare ce doresc a fi activate (roaming, acces GPRS, etc . )

existenta unor facturi neplatite de catre cedent;

existenta unui sold negativ al cedentului;

etc .

Cesiunile pot fi importate dintr-un sistem extern (Vantive in speta) . Singura dificultate implicata de Vantive este ca nu exista nicio modalitate explicita de a lega cesionarul de cedent, din cauza lipsei unei clauze de tip “previous customer” . Aceasta modificare se poate implementa insa in sistemul Vantive si datele se vor putea prelua corect (dar numai pentru cesiunile noi) . O alta metoda de vizualizare a cesiunilor din Vantive ar fi analizarea directa a procesarii acestora si in baza change-urilor sa se identifice, de catre Sistemul Retail, a cesionarului si a cedentului . Vizualizarea cesiunilor permite o mai buna analiza a evolutiei unui contract, a schimbarior survenite la migrarea si in functie de acestea existand posibilitatea de a se crea oferte noi .

Cesiunea transfera un abonament de la un client existent la unul nou sau un alt client existent . Abonamentul poate fi schimbat in acest proces, sau poate fi modificat din punct de vedere al planului tarifar sau al optiunilor .

Procesul de Cesiune este caracterizat de:

data incheierii;

cedentul:

o      nume;

o      prenume;

o      adresa;

o      buletin (serie si numar, sectia de politie eliberatoare, CNP);

o      numar de telefon;

o      numar de telefon de contact;

o      persoana de contact alternativa;

o      reprezentant imputernicit (daca este cazul);

o      data nasterii;

o      cetatenia;

o      domeniul de activitate (daca este persoana juridica);

o      ocupatia socio-profesionala (daca este persoana fizica);

o      banca si contul bancar (daca este persoana juridica);

o      CUI in Registrul Comertului (daca este persoana juridica);

cesionarul (aceleasi date ca la cedent);

adresa de facturare a cesionarului;

daca cesionarul este client nou sau nu (daca nu este client nou, atunci trebueisc specificate si cate numere are deja);

seria SIM-ului asociat abonamentului;

descrierea abonamentului:

o      planul tarifar asociat (cel vechi si cel nou);

o      optiunile transferate noului client (precum si optiunile asociate initial abonamentului);

o      descrierea serviciilor suplimentare (roaming, acces GPRS, etc . )

modalitatea de plata in caz de datorie;

numarul de puncte ThankYou cedate;

numar PREVENTEL;

numar de fax mobil;

numar personalizat;

numar de aur;

etc .

Cesiunea poate fi si multipla, caz in care se vor trece aceleasi date ca la client, dar cu detalii de abonament modificate .

Tranzactia SAV

Clientii pot preda la magazine produsele defecte aflate inca in perioada de garantie, produse comercializate de Orange sau de dealerii sai sau produse ce au serii Orange (vezi mai jos detaliile de receptie defect) . In service se pot receptiona si telefoane ce vor beneficia de servicii de service post-garantie (cu conditia ca aceste telefoane sa fie cu serie Orange) . Fiecare operatiune de acest gen (numita generic SAV – Service Apres-Vente) este reprezentata fizic de un proces-verbal intocmit cu clientul si semnat de acesta .

SAV-urile trec prin urmatoarele etape:

receptia terminalului defect;

trimiterea terminalului in service;

receptia terminalului din service;

returnarea terminalului reparat clientului sau daca reparatia nu a putut fi efectuata, atunci clientului sa-i fie schimbat terminalul, sau indrumat catre punctul de vanzare in cazul in care vanzatorul este un partener .

La receptie, sau dupa acest punct, dar inainte ca terminalul defect sa se intoarca din service, clientului poate sa-i fie dat la schimb un terminal de SWAP pe care sa-l foloseasca pe perioada in care terminalul sau este in service . Clientul il poata inapoia inaintea sau in momentul in care isi primeste produsul reparat inapoi .

Orice tranzactie de tip SAV este identificata de:

data receptiei in magazin a terminalului defect;

clientul, cu tot cu datele de identificare (adresa, nume, prenume, CNP/cod fiscal, banca si cont daca e cazul, tipul de client, etc . );

numar de telefon de contact;

persoana de contact daca clientul nu este disponibil;

vanzatorul care a facut receptia defectului;

produsul defect:

o      tip;

o      serie;

o      model;

o      producator;

o      accesorii;

o      baterie;

o      incarcator;

o      daca este in garantie sau nu;

o      descrierea defectului;

o      etc .

terminalul de SWAP dat la schimb (daca i-a fost inmanat):

o      tip;

o      serie;

o      model;

o      producator;

o      accesorii;

o      baterie;

o      incarcator;

o      observatii legate de terminalul de SWAP;

numar proces verbal;

vanzatorul care a facut receptia terminalului de SWAP;

vanzatorul care a facut predarea terminalului reparat clientului (poate diferi de vanzatorul care face receptia terminalului de SWAP in cazul in care clientul inapoiaza terminalul de SWAP inainte de a i se returna terminalul din Service);

in ce stare a fost returnat terminalul de SWAP:

o      defect;

o      nu a fost predat (pierdut/furat);

o      in stare perfecta;

o      eventuale observatii legate de receptia terminalului de SWAP;

ce reparatii au fost efectuate asupra terminalului (descrierea lor);

daca reparatiile au fost efectuate in garantie sau nu;

numar fisa de laborator;

statusul curent al PV-ului (receptionat, in service, reparat, inchis);

daca terminalul a suferit modificarea seriei sau inlocuirea totala:

o      seria noua;

o      tip, model, producator;

o      serie baterie, accesorii, incarcator;

daca terminalul de SWAP este pierdut sau defect la predare, sa fie furnizata si descrierea taxei de despagubire si valoare acesteia (platita de client), precum si numarul facturii pe care a fost trecuta aceasta taxa;

numarul AIM-ului cu care s-a facut trimiterea in service;

numarul AIM-ului de pe care s-a facut receptia din service;

daca seria terminalului preluat apartine Orange Romania sau daca provine de la dealeri;

factura de achizitie (chiar daca este un terminal de la un dealer) – eventual aceasta factura poate fi retiparita din Sistemul Retail, daca nu e vorba de o factura de la un dealer sau emisa din alt sistem;

data facturii de achizitie;

tranzactiile de transfer cu service-ul (trimiterile de defecte si receptiile de telefoane reparate) sa fie reprezentate de data la care se face transferul si referinta la tranzactia de transfer (data trimiterii, tranzactia de trimitere, data receptiei si tranzactia de receptie);

magazinul in care s-a facut colectarea defectului;

magazinul in care s-a facut predarea defectului;

certificat de garantie (nu e obligatoriu pentru unele produse – mai trebuie detaliat acest aspect);

etc .

Impreuna cu situatia PV-urilor Sistemul Retail va include si un istoric al telefoanelor de SWAP:

pe ce PV a figurat terminalul de SWAP;

data la care a fost inmanat clientului;

data la care a fost returnat de client;

seria produsului si descrierea sa;

starea in care a fost returnat si daca nu a mai fost returnat, sau a fost returnat defect (din vina clientului), sa fie specificata si taxa de despagubire si factura pe care s-a facut incasarea taxei;

referinta la tranzactia de destocare a terminalului de SWAP si la tranzactia de reintegrare pe stoc in urma receptiei;

etc .

In orice moment, de la predarea telefonului defect si pana in momentul intoarcerii acestuia din service, clientul are dreptul de a solicita un telefon de SWAP .

Alegerea telefonului de SWAP sa se faca automat de catre aplicatie, dupa ce utilizatorul a completat un camp destinat seriei telefonului de SWAP acordat clientului (introdus manual sau citit cu cititorul de coduri de bare)

In cazul in care un vanzator opereaza gresit o tranzactie SAV, Sistemul Retail trebuie sa permita ca acesta sa o modifice, daca inca nu a fost trimis telefonul defect la service si sa o poata si anula, in cazul in care clientul se razgandeste inainte sa defectul sa fie trimis in service .

La receptia unui telefon defect, primul lucru care se verifica este telefonul receptionat . Daca acesta se regaseste in Sistemul Retail (pe vreo tranzactie), se cauta referinta facturii da vanzare . Odata gasita factura, se poate selecta automat si clientul si se trece la completarea celorlalte detalii legate de defect .

Facturile emise in orice magazin vor fi vizibile in procesurl de receptie SAV .

Pe parcusul procesului descis mai sus pot aparea urmatoarele probleme:

  • seria IMEI a telefonului a fost vanduta de un dealer – in acest caz clientul e obligat sa se prezinte cu factura de achizitie asupra sa si se va completa in sistem referinta acesteia, data emiterii si detalii de emitere (ce dealer, prin WebShop?, etc . );
  • daca telefonul este achizitionat de la un dealer, are o serie Orange si clientul nu este introdus in sistem, el poate fi importat din sistemele externe sau poate fi introdus manual in Sistemul Retail (daca este un client PrePay el nu este introdus in niciun sistem extern);
  • daca seria IMEI nu este recunoscuta ca fiind serie Orange si marca telefonului nu este nici ea colectabila in niciun service partener Orange, importul in Sistemul Retail pentru acest produs nu este permis (acest comportament poate fi supus unor modificari ulterioare);

Daca clientul ce preda defectul este diferit de cel ce l-a achizitionat, atunci clientul ce preda telefonul defect trebuie sa semneze pe PV-ul de predare-primire telefon defect (datele sale vor fi tiparite pe PV) . In acest caz, clientul ce preda defectul poate fi in lista de persoane de contact si prin urmare se afiseaza lista de persoane de contact a clientului de pe factura, cu posibilitatea de a adauga o persoana noua de contact . Aceste informatii vor fi afisate intr-o fereastra separata ce va afisa mai intai persoanele de contact definite pentru acest client, putandu-se selecta una dintre acestea, sau se va introduce o noua persoana de contact, persoana ce va trebui sa semneze pe PV-ul intocmit (in aceasta lista se va afla si clientul propriu-zis – este cel selectat implicit) . La adaugara unei noi persoane de contact va apare o fereastra pop-up in care se vor cere detaliile clientului ce efectueaza predarea (nume, prenume, numar de telefon, adresa , CNP si alte detalii considerate a fi necesare) .

Trebuie considerata numai cea mai recenta vanzare pe care apare seria IMEI pe care clientul o aduce ca defecta (sa nu fie intercalata si vreo stornare) .

Un telefon defect poate fi receptionat chiar daca a fost vandut in alt magazin (accesul la factura de achizitie nu depinde de magazinul in care se afla clientul) .

Receptia de defecte trebuie sa gestioneze trei tipuri de defecte:

  • telefon defect (cu IMEI Orange – facturat din Sistemul Retail sau nu);
  • accesoriu defect (cumparat de clientul ce-l reclama prin Sistemul Retail – clientul este obligat sa prezinte fie factura, fie bonul de casa prin care a achizitionat produsul, precum si certificatul de garantie);
  • accesoriu defect dar facand parte din pachetul telefonului cumparat (in acest caz e necesara factura de achizitie a terminalului pentru a se verifica continutul pachetului cumparat) .

Telefonul a carui serie nu se regaseste in OA nu se repara in conditii de garantie la service-urile autorizate Orange, ci in conditii de reparatii post-garantie (contra cost) .

Telefonul neregasit in lista de brand-uri sau de coduri de produse ce pot fi colectate pentru service, nu se poate trimite in niciun service .

Orice operator de service autorizat de Orange trebuie sa fie regasit in Sistemul Retail . Fiecare operator de service are asociata o lista de Brand-uri pe care acesta le repara . In cazul in care este vorba de Orange Service Center, acesta mai are si o lista de terminale pe care le poate repara si numai aceste terminale se pot trimite spre reparare .

Exista cazuri in care un service poate repara si telefoane ce nu se afla in nomenclatorul de produse OA, dar produse pentru care Orange poate face colecta (prin contract de service) . In acest caz, este permisa receptia . In cazul Orange Service Center, daca un telefon nu se afla in lista sa de telefoane colectabile, acesta nu se poate trimite in service (pentru un service partener vezi mai jos) .

Daca o serie de defect nu este o serie Orange, se alege brand-ul si denumirea din Sistemul Retail . Acestea sunt cuprinse intr-o lista din eService, importata in mod regulat sau la cerere (in cazul in care un telefon este adaugat in lista de telefoane colectabile inaintea actualizarii automate a listei) . Daca brand-ul sau numele telefonului nu este prezent nici in nomenclatorul importat din eService, acesta poate fi trimis catre un alt service autorizat (cu conditia ca brand-ul sa fie printre cele receptioabile de acest operator service) . Daca telefonul clientului nu este nici macar in lista de brand-uri asociate unui operator de service, colecta ii este refuzata . In acest caz clientul este indrumat sa se adreseze unui alt centru de colectare (dar nu unul al Orange Romania SA) .

Daca produsul defect al clientului se afla in lista de brand-uri reparate de un service partener (altul decat Orange Service Center) si seria sa nu este o serie Orange (dar este achizitionat de la un dealer Orange), utilizatorul va completa manual campul de denumire produs (brandul este ales din lista de brand-uri reparate de service-uri) .

Asocierea intre brand-uri si operatorii service este intretinuta intern in Sistemul Retail de un utilizator autorizat .

Principial, se face colecta pentru orice produs pentru care exista contract de service (inclusiv pentru service-urile partenere) .

In functie de importanta clientului (MAJOR, STRATEGIC) – informatie importata din Vantive - se va alege modul in care clientul va primi din service telefonul (direct prin posta sau prin ridicare de la punctul de colecta) . Daca acesta alege sa-i fie trimis prin posta, atunci din Sistemul Retail nu i se mai poate acorda si un terminal de SWAP .

In momentul in care se opereaza o receptie de telefoane din service o interfata va usura procesul de modificare a starii PV-ului de SAV: fiecare telefon intors din service poate fi scanat cu un cititor de coduri de bare sau importat din eService in baza PV-ului sau iar apoi se opereaza receptia sa din service in mod automat . Se considera, in aceasta operatiune, numai PV-urile de SAV in starea de trimis in service . In cazul in care seria nu este gasita pe niciun PV de SAV apare o fereastra suplimentara in care se alege PV-ul corespunzator . In acest ultim caz se considera ca seria returnata din service o inlocuieste pe cea trimisa in service . Se va genera si o inregistrare de inlocuire serie IMEI in service . Daca aceasta serie inlocuitoare nu este o serie Orange se genereaza o avertizare . Seria schimbata trebuie sa fie si in legatura cu factura de achizitie pe seria initiala, pentru ca la o eventuala stornare sa nu se repuna pe stoc seria initiala ci seria schimbata .

Un PV de SAV nu se va putea inchide pana ce clientul nu va achita nota de plata corespunzatoare devizului din eService (daca acesta exista) – din procesul de inchidere PV se poate automat genera factura corespunzatoare devizului .

In procesul de SAV se va introduce o noua stare: anuntare client, iar in exportul catre eService se vor include si urmatoarele date:

  • data anuntarii clientului
  • data predarii telefonului la client

Un PV de SAV nu mai poate fi modifcat (la nivelul detaliilor de preluare: nume client, serie IMEI, etc) dupa ce a fost preluat de la client . Se poate opera numai o rectificare de stare (aducerea pana intr-o stare anterioara) .

Pe un PV de trimitere in service (sau pe AIM-ul ce contine produsele expediate in service) se va tipari si valoarea asigurata a produselor .

La momentul receptiei telefonului de la client se va alege si operatorul de service catre care se va trimite . In momentul in care se efectueaza si trimiterea in service, se completeaza in Sistemul Retail numai detaliile de curierat si se modifica starea PV-ului de SAV .

La trecerea a 72 sau 36 de zile de la trimiterea in service sa apara o avertizare .

Daca clientul in decurs de 30 sau 120 de zile nu a venit sa-si ridice telefonul va aparea o avertizare si utilizatoruluii se va oferi si posibilitatea de a-i factura taxa de despagubire pentru telefonul de SWAP (daca e cazul – nu e obligatoriu sa-i fie taxat din Sistemul Retail, poate sa-i fie taxat si pe factura de servicii) . In cazul in care Clientul nu se mai prezinta la magazin, utilizatorul cu rol de shop manager trebuie sa anunte ca facturarea sa se faca din sistemul de billing (pe factura de servicii) .

Daca la inchiderea unui PV se constata ca acesta mai are atasat si un PV de SWAP, mai intai trebuie inchis acesta si abia apoi se poate inchide si PV-ul de SAV .

In cazul in care un telefon intors din service tot nu este reparat, acestuia trebuie sa i se inchida PV-ul de SAV si sa i se deschida unul nou, cu tot cu trimitere in service . Redeschiderea de PV (dar cu alt numar de PV) si inchiderea celui vechi se face in mod automat si clientul nu mai este obligat sa semneze niciun act de luare la cunostina . PV-urile de acest tip se pot inlantui, in cazul unor retrimiteri repetate la service . Va exista si posibilitatea ca la retrimitere sa fie ales alt operator de service . Sistemul Retail va pastra acest istoric al re-trimiterilor in service .

La inchiderea unui PV de SAV se va verifica suplimentar si existenta unui eventual deviz in eService, conform caruia clientul trebuie sa mai achite o taxa de reparatie (pentru telefoane scoase din garantie sau trimise la service in afara perioadei de garantie) . Daca clientul mai are de platit acest deviz, PV-ul sau de SAV nu-i este inchis pana ce clientul nu achita suma restanta .

La schimbarea starii unui PV de SAV (inclusiv la receptia defectului), se vor genera in Vantive Jurnale de activitate 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) .

Service-ul PostGarantie este asigurat numai produselor comercializate de Orange .

Service PostGarantie este asigurat numai de catre Orange Service Center .

Fiecare serie receptionata va fi contra-verificata cu un BlackList din eService . O serie regasita in BlackList va putea fi receptionata numai pe PostGarantie (BlackList-ul contine seriile IMEI scoase din garantie) . In acest caz clientul este atentionat ca produsul sau nu va putea fi colectat decat contra cost .

Strunctura unui proces verbal se modifica dupa cum urmeaza:

  • persoana fizica achizitioneaza prodsuul defect si este adus la punctul de colecta de catre o alta persioana: in acest caz pe PV apare numai persoana care aduce defectul (ea trebuie sa exista drept client in Sistemul Retail – prin import sau introducere manuala) . In cazul unei facturi de despagubure pentru pierdere sau deteriorare SWAP, acest client este cel ce achita despagubirea, nu clientul ce face achizitia .
  • persoana juridica ahizitioneaza produsul dar la punctul de colecta acesta este adus de catre o persoana fizica: pe PV va apare persoana juridica, dar la persoana ce preda defectul va fi trecula persoana fizica ce-l preda . Facturarea de despagubire in acest caz se va face pe persoana juridica ce l-a achizitionat .

Pe PV-ul emis de Sistemul Retail sa apara in clar “Garantie/PostGarantie conform documentelor” .

La preluarea unui defect se va alege din lista de defecte unul sau mai multe . Pentru toate defectele selectate, se va adauga si un camp obligatoriu de comentarii (Starea Optica Constatata) .

Daca o factura de achizitie nu se regaseste in Sistemul Retail (pentru ca facturarea a fost facuta la un dealer) atunci sa se poata completa manual campul de data factura si referinta factura (campuri obligatorii) .

In cazul in care un accesoriu este adus defect de un client (accesoriu ce a fost achizitionat separat), acesta trebuie sa prezinte si factura de achizitie (trebuie sa ateste cumpararea de la unul din magazinele Orange) . Daca accesoriul a fost achizitionat de la un dealer, el nu poate fi preluat in service . Daca accesoriul se va trimite catre Orange Service Center, el va trebui sa fie in lista de produse recunoscute de eService . In caz ca acest accesoriu nu se afla in lista de produse, fie se asteapta pana ce este introdus in eService si apoi se reface aceasta lista de produse colectabile (prin import din eService) si se trimite catre Orange Service Center, fie este redirectionat clientul catre un alt operator service .

In cazul in care accesoriul defect adus de client este achizitionat “la pachet”, impreuna cu un telefon, clientul trebuie sa aduca si telefonul pentru ca IMEI-ul acestuia sa fie verificat in sistem (telefonul nu se va prelua, ci numai accesoriul; telefonul este folosit numai pentru validarea pachetului) .

In cazul in care e necesar ca produsul sa fie retrimis in service trebuie sa existe posibilitatea de a inchide un PV fara tiparire de documente de predare defect reparat, si deschidere PV fara tiparire de documente pentru receptie defect . Jurnalele de Vantive nu vor fi introduse in sistem pentru inchidere si deschidere PV, nici de instiintare client .

Va exista si optiunea de retiparire factura pentru produsele achizitionate de la unul din magazinele Orange .

Daca seria unui telefon este schimbata in service, aceasta serie se regaseste de acum in alta lista => la verificarea seriei IMEI pentru un telefon cu serie schimbata si care iar ajunge la punctul de colecta se va verifica atat lista de serii Orange comercializate cat si lista de serii Orange de schimb pentru service (in aceasta ordine) .

Exportul din Sistemul Retail va aduce in aplicatia eService PV-urile trimise catre Orange Service Center (la fel ca in sistemul actual – header + detalii)

Tranzactiile SAV (trimiterile in service) se vor exporta catre eService intr-un format asemanator celui actual . Se va adauga si o coloana de ID unic de PV sub forma:

SHAPE * MERGEFORMAT

SH nn nnnn nnnnnnn

Cod intern  Magazin Numar PV

Tip PV n = 1 caracter

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

Produse pe stoc

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

SHAPE * MERGEFORMAT

Facturi

Drafts

Emise

Anulate

Stornari

Schimburi de SIM

PrePay

PostPay

SAV

Efectuate

Anulate

Admin

Schimba Parola

Optiuni

Vizualizare Operatiuni

New

New

New

New

Filtru Data

. .

20

30

60

120

< Ante . Urm . >

In functie de selectia din meniul din partea stanga

Numarul de rezultate afisate intr-o pagina

Lansarea unei noi operatiuni

In functie de operatiunea selectata pentru vizualizare, capul de tabel si titlul se schimba

Detalii de implementare - Figura SEQ Figura * ARABIC - Model Interfata de Vizualizari

Raportare

Raportele vor reprezenta o colectie organizata de date si activitati efectuate in noua aplicatia Retail de catre reprezentantii de vanzari din Shopuri precum si de catre shop manageri . Aceste informatii vor fi organizate intr-un format compact, usor accesibil, structurat astfel incat sa se mapeze pe cerintele de business .

Fiecare raport poate fi rulat numai pentru un magazin, poate fi rulat pentru un canal (Retail/Corporate), pe o regiune sau poate fi rulat pentru toate magazinele Orange .

Pentru o usoara raportare magazinele Orange vor fi grupate si pe regiuni geografice care vor fi stabilite la implementarea aplicatiei .

Accesul la rapoarte va fi restrictionat in functie de nivelul de acces al fiecarui utilizator in parte

Rapoartele vor fi impartite in 4 mari categorii:

  • Rapoarte de vanzari
  • Rapoarte de gestiune
  • Rapoarte de analiza
  • Rapoarte diverse

Unele rapoarte uzuale vor fi grupata intr-o coada de executie, care sa permita generarea acestora printr-un singur click . De ex . :

Fisa Stoc Total

Borderou

Jurnal de Vanzari

Lista Documente Emise

sau :

Raport Evaluare SR

Raport Sinteza

Rapoarte de vanzari

In categoria rapoarte de vanzari sunt incluse:

  • Borderoul de incasari;
  • Lista de facturi emise - lista de documente emise in care se regasesc informatiile referitoare la modalitatea de plata;
  • Jurnalul de Vanzari (rulabil la nivel de magazin individual, la nivel de regiune sau la nivel de canal, pe o perioada stabilita la rulare);
  • Raport facturi neinchise;
  • Raport incasari cu OP si CC;
  • Lista de dispozitii de plata;
  • Export date pentru organele de control fiscal;
  • Vanzari cu discounturi;
  • Vanzari produse;
  • Raport pe Categorii Vanzare;
  • Raport vanzari GFK;
  • Rapoarte PP;
  • Rapoarte Centralizate;
  • Raport monetar – incasari;
  • Raport de stoc istoric (la o anumita data, la final de zi);
  • Raport de facturi incasate cu bon fiscal .

Borderoul de incasari si Lista de facturi emise sunt rapoarte ce trebuie tiparite in fiecare zi . Jurnalul de Vanzari nu este obligatoriu sa fie tiparit in magazin si este un document contabil .

Borderoul de incasari poate fi rulat de fiecare utilizator cu rol de  vanzator si poate vedea in acest caz doar incasarile sale; in acelasi  timp poate fi rulat de catre un utilizator de nivel shop manager (sau un utilizator ce-si asuma rolul de shop manager) pentru a vedea incasarile pe tot magazinul, impartite pe fiecare vanzator in parte . Raportul va afisa subtotaluri pentru incasari prin bon de casa si prin facturi fiscale si apoi va si totaliza incasarile (Bonuri de casa + Cash facturi fiscale)

Lista de facturi emise - poate fi tiparita de utilizatorii de nivel vanzator, si in acest caz afiseaza numai facturarile acestora (inclusiv bonurile de casa) sau poate fi rulat de un utilizator de nivel superior, si in acest caz afiseaza facturarile la nivel de magazin (inclusiv incasarile prin bonuri de casa) . In cazul in care pentru un bon de casa este facuta o factura, bonul de casa nu va mai apare la sectiunea de bonuri de casa, ci in cea de facturi fiscale, dar va fi marcat ca factura in baza unui bon de casa

Raportul Lista de dispozitii de plata se poate rula pe o perioada care poate fi selectata de utilizator .

Raportul Vanzari cu discount insumeaza toate vanzarile ce folosesc discounturi . In acest raport vor aparea si produsele vandute fara discount, dar vor fi afisate la finalul raportului ( va fi o bifa care prin selectare va afisa si produsele vandute fara discount) . Raportul se va putea rula pe o anumita perioada- selectata de utilizator, grupand rezultatele la nivel de zi . Raportul va fi impartit pe categorii de vanzari (Fidelizare, Abonament, etc . ) .

Raportul poate fi rulat si fara a si afisata informatia de Vanzator sau cea de Client pentru cazurile in care se doreste o raportare generica . De poate fi rulat si fara a si afisata si ziua, in cazul in care se doreste insumarea totala pe perioada aleasa .

Raportul va putea fi rulat si la nivel de regiune . Campul de regiune poate lipsi cand raportul e rulat pentru un magazin sau pentru toate magazinele .

Raportul acesta va fi disponibil in mai multe formate .

Un prim format va fi:

  • Ziua
  • Regiunea
  • Magazinul
  • Vanzatorul
  • Clientul
  • Produsul (cu cod si nume)
  • Discountul folosit (ca nume)
  • Valoarea discountului (ca procent si ca valoare fixa)
  • Numarul de discounturi de acel tip aplicate
  • Valoarea totala aplicata (insumata)

Raportul mai poate fi prezent si in urmatorul format:

  • Ziua
  • Magazin
  • Produs (nume si cod)
  • Cantitate (insumata)
  • Discount (nume)
  • Valoare unitara discount (procent sau valoare fixa discount)
  • Reducere totala (discounturi insumate)

Raportul de vanzari produse va avea urmatorul format:

  • Ziua
  • Regiunea
  • Magazinul
  • Vanzatorul
  • Produsul (cu cod si nume)
  • Cantitate (insumata)
  • Categoria de vanzare (operatiunea folosita)

Exportul de date pentru organele de control fiscal va cuprinde un raport intr-un format Excel prestabilit, care sa cuprinda informatiile legate de seriile si numerele (referintele interne) generate de Sistemul Retail . Exportul poate fi rulat pe o perioada specicificata de timp .

Raportul pe Categorii Vanzare va permite analiza pe o perioada a vanzarilor . Parametrii de rulare:

  • perioada
  • regiunea/magazinul (magazinele)
  • vanzatorul
  • tipul de vanzare
  • prelungirea contractuala
  • tipul planului tarifar
  • produsul (cod + nume)
  • tipul de client (Buss/Priv)

Raportul va putea fi rulat in mai multe variante .

  • Zi nespecificata / Ziua / Ziua si ora operatiunii
  • Regiunea – poate lipse
  • Magazinul – poate lipsi
  • Vanzatorul – poate lipsi
  • Tipul de Vanzare
  • Prelungirea contractuala
  • Tipul planului tarifar
  • Produsul (cod + nume)
  • Tipul de Client (Buss/Priv) – poate lipsi
  • bucati

Raportul poate fi rulat penrtu toate regiunile (nu mai sunt afisate informatii despre regiuni si magazine), pentru o regiune (fara afisarea magazinelor sau cu afisarea magazinelor) sau penrtu o lista de magazine (cu specificarea si a regiunii de care apartin) .

Raportul poate fi rulat pentru orice vanzator (cu marcarea sau nu in raport a vanzatorilor ce opereaza tranzactia), pentru orice Client (cu marcarea tipului de client sau nu) .

Interfata grafica a acestui raport e prezentata in figura 1 .

Raport de vanzari GFK – ramane ca in forma actuala din eShop

Raportul PrePay e prezent in doua formate:

  • Raport PrePay pachete
  • Raport PrePay Reincarcari

Ambele rapoarte PrePay au ca parametrii de rulare:

  • Tip Pachet (pot fi alese toate);
  • Produs (pot fi alese toate de un tip, un produs sau mai multe, toate produsele);
  • Perioada (camp obligatoriu);
  • Tip Vanzare – poate lipsi;
  • Tip Plan Tarifar – poate lipsi;
  • Tip Client - poate lipsi;
  • Regiunea – poate lipsi;
  • Magazinul – toate dintr-o regiune, unul sau mai multe, toate;
  • Vanzatorul – poate lipsi;

Raportul de PrePay pachete va returna:

  • Tip Pachet;
  • Produs (nume + cod);
  • Ziua (din perioada);
  • Tip Vanzare
  • Tip Plan Tarifar
  • Tip Client
  • Regiunea
  • Magazinul
  • Vanzatorul
  • Numarul de bucati vandute

Raportul de PrePay reincarcari va returna:

  • Tip Raincarcare;
  • Produs (nume + cod);
  • Ziua (din perioada);
  • Tip Vanzare
  • Tip Plan Tarifar
  • Tip Client
  • Regiunea
  • Magazinul
  • Vanzatorul
  • Numarul de bucati
  • Valoarea in € unitara
  • Valoare in € insumata
  • Valoarea in RON insumata

Raport monetar incasari (pentru ca monetarul va fi intretinut de Sistemul Retail) .

Alte rapoarte ce raman neschimbate fata de implementarea lor actuala (din eShop):

  • Corespondenta ref . interna – serii
  • Raport vanzari procentuale
  • Raport proforme emise
  • Raport vanzari cu CC
  • Raport vanzari cu OP
  • Raport Crosschecking Reincarcari
  • Raport de sinteza
  • Raport evaluare SR
  • Analiza vanzari:
    • Terminale
    • SAV
    • Schimbare de SIM PrePay si PostPay
    • Accesorii
    • Reincarcari si PPY
  • Produse vandute:
    • Fara numere de inventar
    • Cu numere de inventar
    • Total Vanzari
    • Vanzari SR si BSR

Rapoarte de gestiune

Rapoartele de gestiune raman in principiu neschimbate fata de implementarea lor din eShop . Acestea sunt:

  • Schimb de SIM PrePay/PostPay
  • Fisa de magazie
  • Raport de Promo
  • Export transferuri in defecte (in formatul agreat de Logistica)
  • Raport tranzactii pentru o serie IMEI
  • Raport folosire AIM-uri (ce produse sunt pe un AIM si care dintre ele au fost folosite pana in prezent in vreo tranzactie ce afecteaza stocul)
  • Raport export istoric
  • Fisa de stoc:
    • Cu numere de inventar
    • Fara numere de inventar
    • Stoc Total
    • Stoc total pe magazii
    • Telefoane ordonate pentru vitrina
    • Lista produse inventariere
    • Stoc ultima luna
    • Stoc zilnic
  • Rapoarte SAV in diverse formate

Rapoarte de analiza

Rapoartele Centralizate permit analiza generala a evolutiei stocurilor . Aceste rapoarte cuprind:

  • Raport de Stocuri;
  • Raport de SAV;
  • Raport de SWAP istoric;
  • Raport de SWAP cu rotatie stoc;
  • Raport de rotatie STOC (nu si SWAP-uri);
  • Raport de transferuri intre magazine;
  • Raportul de STOCURI va furniza informatii despre stocul cantitativ al unui magazin la un moment dat (snapshot):
  • Tip Magazie – selectabila
  • Regiune
  • Magazin
  • Produs (cod + nume)
  • bucati
  • pretul de cost (cel total)

Se va putea lista si preturile de cost asocaite unui produs, sub forma unui alt raport .

Raportul de rotatie de stoc va contine timpul intre o receptie si o iesire de pe stoc (la nivel de magazin) . Rotatia de stoc nu va curpinde si produsele implicate in tranzactii de SAV . Produsele tranzactionate prin magazia de Touch & Try vor fi prelucrate separat (va exista o bifa care va permite rularea raportului numai la nivel T&T sau la nivel general, dar fara T&T) .

Raportul va cuprinde:

  • Ziua la care se doreste rularea raportului (daca lipseste, raportul se refera la rotatia de stoc all-time)
  • Produsul
  • Magazinul
  • Regiunea
  • Numar de zile maxim pe stoc
  • Numar de zile minim pe stoc
  • Numar de zile mediu pe stoc

Momentul rularii

Tranzactie

luata in

consideratie

Tranzactie

ignorata

Tranzactie

returnata

Legenda:

Raportul ia in considerare si produsele valide inaintea zilei fata de care acesta ruleaza precum si produsele care in ziua aleasa nu se gasesc pe stoc dar sunt valide in ziua aleasa pentru rulare si au fost tranzactionate inainte .

Raportul de SAV va permite analiza timpului petrecut in diferite stari de un telefon de SAV . El va cuprinde:

  • Ziua de referinta (PV-urile ce au ziua de referinta intre Data Start si Data Stop);
  • Regiunea;
  • Magazinul;
  • Tip Client;
  • IMEI (raportul poate sau nu sa tina cont de IMEI – va exista o bifa printre parametrii de rulare);
  • Produsul (Cod + Nume);
  • Zile PV deschis;
  • Zile PV in service;
  • Zile PV deschis si netrimis in service;
  • Zile PV reparat – pana cand a venit sa-l ridice clientul, din momentul in care a fost reparat;
  • Data Start PV
  • Data Stop PV
  • Data Trimiterii in Service
  • Data receptiei din Service

Raportul de SWAP rotatie stoc va permite analiza timpului in care un telefon de SWAP este in custodia clientului, sau este nefolosit de niciun client .

Raportul de SWAP rotatie stoc va cuprinde:

  • Produs;
  • IMEI SWAP (poate lipsi din raport daca se doreste – ales printr-o bifa in pagina de parametrii raport);
  • Ragiunea;
  • Magazin;
  • de cate ori a fost atasat unui SWAP;
  • Perioada Maxima/Minima in custodia unui client;
  • Perioada Maxima/Minima in magazia de SWAP a magazinului ;
  • Ziua de referinta (daca lipseste se transforma intr-un raport ALL-TIME, fara coloana de zi de referinta);

Raportul de SWAP istoric cuprinde la nivel de produs si IMEI telefon SWAP, istoricul sau:

  • Produs
  • Serie IMEI (poate lipsi)
  • Regiunea
  • Magazinul
  • Data operatiunii
  • Tipul Operatiune (predare/primire custodie)
  • Perioada de rulare (poate lipsi)
  • Raportul de transfer intre magazine cuprinde:
  • Produs
  • Regiunea de la (poate lipsi)
  • Magazinul de la (poate lipsi)
  • Regiunea la (poate lipsi)
  • Magazinul la (poate lipsi)
  • bucati
  • pret de cost asociat transferului
  • Data trimiterii
  • Data receptiei
  • Perioada (obligatoriu aleasa la inceputul rularii raportului)

Rapoarte Diverse

Raportul audit intern este un raport de activitate al utilizatorilor de niveluri inferioare . Contine campurile:

  • Regiune
  • Magazin
  • Utilizator
  • Nivel de autoritate
  • Perioada
  • durata unei sesiuni (min/max)
  • ora login
  • ora logout
  • ora ultimei operatii (ora ultimei facturi, ultimului raport, ultimului SAV, ultimului transfer, etc)

SHAPE * MERGEFORMAT

OK

Fidelizare

Abonament

12 luni

12 luni

24 luni

8 luni

20 luni

36 luni

Voce

Date

Voce

3G

Date

3G

Date + Voce

Client:

Business

Private

(alti parametrii)

Perioada: --

Figura SEQ Figura * ARABIC - Alegerea unui tip de vanzare

Technical Constraints

In cazul unor erori de retea (de conectare, etc) va fi necesara existenta unor solutii alternative de conectare la baza de date .

Asigurarea unui sistem de buffering pentru situatiile de intrerupere temporara a activitatilor in magazin





Politica de confidentialitate


creeaza logo.com Copyright © 2024 - Toate drepturile rezervate.
Toate documentele au caracter informativ cu scop educational.