UNIVERSITATEA DIN CRAIOVA

FACULTATEA DE AUTOMATICĂ, CALCULATOARE ȘI

ELECTRONICĂ

DEPARTAMENTUL DE MECATRONICĂ ȘI ROBOTICĂ

PROIECT DE DIPLOMĂ

Albăstrin Marian Alexandru

COORDONATOR ȘTIINȚIFIC

Profesor doctor inginer Viorel Stoian

Iulie 2016

CRAIOVA
 UNIVERSITATEA DIN CRAIOVA
FACULTATEA DE AUTOMATICĂ, CALCULATOARE ȘI
ELECTRONICĂ

DEPARTAMENTUL DE MECATRONICĂ ȘI ROBOTICĂ

„Studiul sistemelor ERP”

Albăstrin Marian Alexandru

COORDONATOR ȘTIINȚIFIC

Profesor doctor inginer Viorel Stoian

Iulie 2016

CRAIOVA

ii
„Software-ul este întotdeauna important, pentru că internetul conectează lumea din ce în ce mai
mult.”

Bill Gates

iii
 DECLARAȚIE DE ORIGINALITATE

Subsemnatul Albăstrin Marian Alexandru, student la specializarea Robotică din cadrul Facultății de
Automatică, Calculatoare și Electronică a Universității din Craiova, certific prin prezenta că am luat la
cunoştinţă de cele prezentate mai jos şi că îmi asum, în acest context, originalitatea proiectului meu de
licenţă:

 cu titlul „Studiul sistemelor ERP”,

 coordonată de Profesor doctor inginer Viorel Stoian,
 prezentată în sesiunea iulie 2016.

La elaborarea proiectului de licenţă, se consideră plagiat una dintre următoarele acţiuni:

 reproducerea exactă a cuvintelor unui alt autor, dintr-o altă lucrare, în limba română sau prin
traducere dintr-o altă limbă, dacă se omit ghilimele şi referinţa precisă,
 redarea cu alte cuvinte, reformularea prin cuvinte proprii sau rezumarea ideilor din alte
lucrări, dacă nu se indică sursa bibliografică,
 prezentarea unor date experimentale obţinute sau a unor aplicaţii realizate de alţi autori fără
menţionarea corectă a acestor surse,
 însuşirea totală sau parţială a unei lucrări în care regulile de mai sus sunt respectate, dar care
are alt autor.

Pentru evitarea acestor situaţii neplăcute se recomandă:

 plasarea între ghilimele a citatelor directe şi indicarea referinţei într-o listă corespunzătoare la
sfărşitul lucrării,
 indicarea în text a reformulării unei idei, opinii sau teorii şi corespunzător în lista de referinţe
a sursei originale de la care s-a făcut preluarea,
 precizarea sursei de la care s-au preluat date experimentale, descrieri tehnice, figuri, imagini,
statistici, tabele et caetera,
 precizarea referinţelor poate fi omisă dacă se folosesc informaţii sau teorii arhicunoscute, a
căror paternitate este unanim cunoscută și acceptată.

Data, Semnătura candidatului,

iv
 UNIVERSITATEA DIN CRAIOVA Aprobat la data de
Facultatea de Automatică, Calculatoare şi Electronică …………………
Şef de departament,
Departamentul de Mecatronică și Robotică Prof. dr. ing.
Dorian COJOCARU

PROIECTUL DE DIPLOMĂ

Numele și prenumele studentului/-ei: Albăstrin Marian Alexandru

Enunțul temei:
Studiul sistemelor ERP

Datele de pornire: [Descrierea datelor inițiale de la care s-a început activitatea

de cercetare/dezvoltare a tezei]

[Descrierea succintă a conținutului fiecărui capitol al

Conținutul proiectului:
lucrării]

Material grafic obligatoriu:

Consultații: Periodice

Conducătorul științific
Profesor Univ. dr. ing. Viorel Stoian
(titlul, nume și prenume, semnătura):

Data eliberării temei: 10.10.2015

Termenul estimat de predare a

10.07.2016
proiectului:

Data predării proiectului de către

student și semnătura acestuia:

v
 UNIVERSITATEA DIN CRAIOVA
Facultatea de Automatică, Calculatoare şi Electronică

Departamentul de Mecatronică și Robotică

REFERATUL CONDUCĂTORULUI ȘTIINȚIFIC

Numele și prenumele candidatului/-ei: Albăstrin Marian Alexandru

Specializarea: Robotică
Titlul proiectului: Studiul sistemelor ERP
În facultate □
Locația în care s-a realizat practica de
documentare (se bifează una sau mai În producție □
multe din opțiunile din dreapta): În cercetare □
Altă locație: [se detaliază]

În urma analizei lucrării candidatului au fost constatate următoarele:

Insuficient Satisfăcător Bine Foarte bine

Nivelul documentării
□ □ □ □
Cercetare Proiectare Realizare Altul
Tipul proiectului
□ □ practică □ [se detaliază]
Simplu Mediu Complex Absent
Aparatul matematic utilizat
□ □ □ □
Contract de Cercetare Utilare Altul
Utilitate
cercetare □ internă □ □ [se detaliază]
Insuficient Satisfăcător Bine Foarte bine
Redactarea lucrării
□ □ □ □
Insuficientă Satisfăcătoar Bună Foarte bună
Partea grafică, desene
□ e□ □ □
Realizarea Insuficientă Satisfăcătoar Mare Foarte mare
practică Contribuția autorului
□ e □ □ □
Complexitatea Simplă Medie Mare Complexă
temei □ □ □ □
Insuficient Satisfăcător Bine Foarte bine
Analiza cerințelor
□ □ □ □
Arhitectura Simplă Medie Mare Complexă
□ □ □ □

vi
 Întocmirea Insuficientă Satisfăcătoar Bună Foarte bună
specificațiilor
funcționale □ e □ □ □
Insuficientă Satisfăcătoar Bună Foarte bună
Implementarea
□ e □ □ □
Insuficientă Satisfăcătoar Bună Foarte bună
Testarea
□ e □ □ □
Da Parțială Nu
Funcționarea
□ □ □
Experiment propriu Preluare din bibliografie
Rezultate experimentale
□ □
Cărți Reviste Articole Referințe web
Bibliografie

Comentarii
și
observații

În concluzie, se propune:

ADMITEREA PROIECTULUI RESPINGEREA PROIECTULUI

□ □

Data, Semnătura conducătorului științific,

vii
 REZUMATUL PROIECTULUI

Lucrarea este structurată pe 5 capitole, la care se adaugă concluziile și referințele

bibliografice. Scopul acestei lucrări, constă în studierea importanței implementării unui sistem ERP în
cadrul unei companii.

Partea teoretică este prezentată în capitolul 1, aici fiind incluse noţiunile fundamentale despre
sistemele informatice, clasificarea sistemelor, ciclul de viaţă, conceperea şi construirea sistemelor
informatice, principali factori care participă la dezvoltarea unui sistem informatic.Capitolul 2 prezintă
noțiuni generale despre sistemele ERP, definiția acestora, componente, caracteristici, avantajele și
dezavantajele implementării acestora într-o firmă, în timp ce în capitolul 3 sunt prezentate
particularități ale implementării precum și costurile pentru achiziționarea unui sistem ERP.În capitolul
4 este studiat sistemul initOra.ERP.Ultimul capitol este prezentat sistemul initOra.SFA și legătură
dintre acesta și initOra.ERP.

viii
CUPRINSUL

1 INTRODUCERE.................................................................................................................................................1

1.1 DEFINIŢIA SI EVOLUŢIA INTEGRĂRII APLICAŢIILOR INFORMATICE ....................................................................................1

1.2 PROBLEME ALE INTEGRĂRII.................................................................................................................................3
1.3 INFRASTRUCTURA DE INTEGRARE.........................................................................................................................4
1.4 EVOLUŢIA APLICAŢIILOR INTEGRATE DE GESTIUNE A FIRMELOR.....................................................................................7

2 SISTEME DE PLANIFICARE A RESURSELOR ÎNTREPRINDERII DE TIP ERP...................................................9

2.1 SISTEMELE ERP........................................................................................................................................9

2.2 ARHITECTURA UNUI SISTEM ERP..................................................................................................................10
2.3 COMPONENTELE SISTEMULUI INFORMATIC ERP.............................................................................................10
2.4 OBIECTIVELE PUNCTUALE ALE SISTEMELOR INFORMATICE ERP..........................................................................11
2.5 PRINCIPALELE CARACTERISTICI ALE UNEI SOLUŢII ERP.......................................................................................11
2.6 EVOLUŢIA SISTEMELOR DE PLANIFICARE A RESURSELOR ÎNTREPRINDERII ERP........................................................12
2.7 AVANTAJE IMPLEMENTĂRII SISTEMELOR DE PLANIFICARE A RESURSELOR ÎNTREPRINDERII ERP..................................12
2.8 DEZAVANTAJELE IMPLEMENTĂRII SISTEMELOR DE PLANIFICARE A RESURSELOR ÎNTREPRINDERII ERP..........................13
2.9 MANAGEMENTUL PROIECTULUI....................................................................................................................13
2.10 FACTORI IMPORTANŢI PENTRU IMPLEMENTAREA SISTEMELOR DE GESTIUNE ERP...................................................14

3 PARTICULARITĂŢI ALE IMPLEMENTĂRII SISTEMELOR ERP.....................................................................15

3.1 COSTUL UNUI SISTEM ERP..........................................................................................................................15

3.2 MENTENANŢA SISTEMULUI INFORMATIC ERP..................................................................................................16
3.3 IMPLEMENTAREA SISTEMELOR ERP ÎN ÎNTREPRINDERI MICI ŞI MIJLOCII................................................................17
3.4 MOTIVAŢIA IMPLEMENTĂRII.........................................................................................................................22

4 PREZENTAREA SISTEMULUI INITORA.ERP............................................................................................. 23

4.1 DESCRIEREA SISTEMULUI.............................................................................................................................23

4.2 DEOSEBIRI INTRE INITORA.ERP SI ALTE SISTEME ERP......................................................................................23
4.3 STRUCTURA GENERALA A SISTEMULUI INITORA.ERP.........................................................................................27

5 PREZENTAREA SISTEMULUI INITORA.SFA............................................................................................. 34

5.1 DEFINIŢIA UNUI SFA..................................................................................................................................34

5.2 BENEFICIILE UNUI SFA................................................................................................................................35
5.3 ARHITECTURA SOLUȚIEI INITORA.SFA...........................................................................................................36

5.4 AVANTAJELE SISTEMULUI INITORA.SFA..........................................................................................................37

5.5 CARACTERISTICI FUNCȚIONALE.....................................................................................................................37

ix
6 CONCLUZII.......................................................................................................................................... 38

7 BIBLIOGRAFIE..................................................................................................................................... 39

8 REFERINȚE WEB.................................................................................................................................. 40

A. CODUL SURSĂ..................................................................................................................................... 41

B. SITE-UL WEB AL PROIECTULUI............................................................................................................. 53

C. CD / DVD............................................................................................................................................ 54

Index.......................................................................................................................................................................55

x
LISTA FIGURILOR

FIGURA 1 - EVOLUŢIA APLICAŢIILOR INTEGRATE DE GESTIUNE A FIRMELOR( PRELUCRARE ŞI ADAPTARE DUPĂ [FOHU04]...............10
FIGURA 2 - LANȚUL DE DOCUMENTE CARE APAR INTR-O FIRMA...........................................................................................25
FIGURA 3 – INTEGRAREA CU CASA DE MARCAT.................................................................................................................26
FIGURA 4 - LOGIN INITORA.ERP...................................................................................................................................27
FIGURA 5 - GRUPAREA PROGRAMULUI............................................................................................................................27
FIGURA 6 - STRUCTURA SISTEMULUI INITORA.ERP...........................................................................................................29
FIGURA 7 - FLUX DOCUMENTE......................................................................................................................................30
FIGURA 8 - PRODUCȚIE................................................................................................................................................30
FIGURA 9 - EXEMPLU DOCUMENT..................................................................................................................................31
FIGURA 10 - STRUCTURA FIȘIERULUI COMEZI.ODS.............................................................................................................31
FIGURA 11 - TRANSFORMAREA COMENZILOR ÎN DOCUMENTE.............................................................................................33
FIGURA 12 - EXEMPLU DE DOCUMENT IMPORTANT...........................................................................................................35
Figura 13 - Comunicația aplicației android cu serverul.........................................................................................37

1 INTRODUCERE

1.1 Definiţia si evoluţia integrării aplicaţiilor informatice

xi
 Integrarea aplicaţiilor informatice este o activitate ce reuneşte oameni, echipamente,
programe, dar şi practici manageriale. Integrarea aplicaţiilor este o abordare strategică de a lega mai
multe sisteme informatice, la nivel de informaţii şi servicii, astfel încât sistemele să fie capabile să
facă schimb de informaţii şi să asigure o funcţionare a proceselor în timp real .

Integrarea aplicaţiilor informatice în cadrul unei întreprinderi sau între mai multe întreprinderi
care colaborează este un subiect de mare actualitate. Integrarea aplicaţiilor informatice de
întreprindere permite coordonarea şi sincronizarea mai multor aplicaţii eterogene atât în interiorul
(integrarea aplicaţiilor la nivel de companie), cât si în afara întreprinderilor (integrarea aplicaţiilor
Business-to-Business - B2B).

Denumită în limbajul de specialitate EAI (Enterprise Application Integration), integrarea

aplicaţiilor la nivel de companie reprezintă, de fapt, noul stil de lucru în domeniul software.
Întreprinderile au din ce în ce mai puţini informaticieni care concep şi scriu aplicaţii şi din ce în ce
mai mulţi care integrează aplicaţii. Entitatea ce trebuie integrată nu mai este un obiect sau o
componentă software, ci este o aplicaţie software. Prin EAI, sistemele informatice ale întreprinderilor
se mulează din ce în ce mai bine pe structura procesului de afaceri.

Complexitatea problemelor legate de infrastructura informatică creşte şi mai mult în cazul unei
întreprinderi virtuale, formată din module (secţii, departamente, birouri etc.) cu funcţionalitate extrem
de diversă şi grad de dispersie geografică oricât de mare. Granularitatea modulelor se poate situa pe o
scară foarte cuprinzătoare, depinzând în mare măsură atât de specificul domeniului de activitate, cât şi
de posibilităţile de organizare ale întreprinderii respective.

În contextul actual, în care informaţia este privită ca o resursă strategică a întreprinderii, a

crescut foarte mult importanţa integrării sistemelor informatice care să faciliteze utilizarea în comun a
datelor şi mişcarea lor în cadrul întreprinderii.

La nivelul anului 1999 s-a estimat că peste o treime din bugetul din industria IT a avut ca
destinaţie proiectarea, realizarea şi întreţinerea unor soluţii de integrare a sistemelor informatice. Dar,
cele mai multe dintre aceste soluţii au optat pentru varianta de integrare “punct la punct”, şi s-au
dovedit a fi mari consumatoare de resurse.

Dezvoltarea unei strategii eficiente de integrare a sistemelor informatice la nivelul

întreprinderii este una dintre cele mai complexe probleme întâmpinate de managerii IT. Complexitatea
acestei probleme rezultă în principal din faptul că cele mai multe dintre aplicaţii au fost dezvoltate
fără a se avea în vedere o anumită arhitectură a sistemelor informatice sau o strategie de dezvoltare a
acestora.

xii
 Anul 1959 poate fi considerat începutul integrării în domeniul IT, an în care a apărut
circuitului integrat şi care a reunit şi alte descoperiri cum ar fi: tranzistorii, rezistenţele şi capacitorii
pe un singur chip de silicon. În 1965 Gordon Moore, unul din fondatorii Intel prezicea că numărul de
tranzistori pe un microchip se va dubla la fiecare 18 luni. În mod surprinzător, această lege este încă
adevărată şi acum, la peste 40 de ani de la formularea ei. Acesta poate fi considerat unul din motivele
pentru care avem nevoie de integrare: pentru a ne descurca în condiţiile unei complexităţi crescute. În
acest context, merită reamintite principiile de bază ale managementului complexităţii: descompunea
în părţi mai mici şi mai uşor de manipulat, construirea unei interfeţe standard pentru ca aceste părţi să
comunice şi apoi dezvoltarea unei structuri ierarhice unde informaţia este din ce în ce mai
abstractizată odată ce urcăm în ierarhie.

Informatizarea, dezvoltarea economică globală, specifice începutului de secol XXI au

accentuat tendinţa de organizare a sistemelor informaţionale în modele din ce în ce mai complexe.
Prin integrare creşte, dupa cum s-a vazut, complexitatea, dar şi calitatea, pentru că reuniunea
sistemelor presupune adăugarea de componente evolutive şi emergente.

Dacă organizarea duce la integrare şi integrarea duce la complexitate, aceasta din urmă
determină la rândul ei diversificarea. Din punct de vedere al diversităţii, integrarea este efectul
evoluţiei ciclice şi progresive a unui mix de tehnologii şi este sprijinită de performanţele şi de
expertiza profesioniştilor.

Integrarea aplicaţiilor poate lua mai multe forme, incluzând integrarea internă a aplicaţiilor:
integrarea aplicaţiilor la nivel de companie sau integrarea externă a aplicaţiilor: integrarea
aplicaţiilor Business-to-Business. Cele două tipuri de integrări au multe elemente comune. De
exemplu, întotdeauna vor exista:

 transformare de tehnologie care va face diferenţa între semantica aplicaţiilor;

 tehnologia de router prin care se va asigura că informaţia ajunge la destinaţia corectă;
 reguli de procesare pentru a defini comportamentul de integrare.
Strategia IT trebuie să ţină seama de toţi factorii care influenţează deciziile de integrare a
proceselor economice, ca de exemplu configurarea proceselor economice, frontierele acestora şi
locul în care schimbarea este cel mai probabil a se produce. Înţelegerea scopurilor economice, cum
ar fi strategiile de fuzionare şi de achiziţie sau cost şi creşterea eficienţei, apare ca o cheie
fundamentală. Trebuie stabilită o perspectivă internă şi externă comună a nucleului economic, de
informaţie şi de procese, pentru a înţelege relaţiile şi interfeţele între unităţile economice, sau între
partenerii comerciali.

Trebuie stabilite problemele proprietăţii pentru aplicaţii, componente, infrastructura

integratoare, interfeţele externe etc. Şi aceasta poate fi una dintre cele mai dificile sarcini şi poate
traversa frontiere organizaţionale şi responsabilităţile actuale. Secvenţierea activităţilor trebuie
xiii
să identifice serviciile care trebuie realizate primele, care dintre servicii (nu neapărat aceleaşi)
trebuie utilizate consistent cu restul organizaţiei şi când anume.

O tendinţă în evoluţia integrării sistemelor este trecerea de la integrarea bazată pe informaţii

la integrarea bazată pe servicii. Integrarea bazată pe informaţii oferă un mecanism ieftin de a integra
aplicaţii deoarece, în cele mai multe cazuri, nu este nevoie ca aplicaţia să fie modificată. Cu toate că
acest tip de integrare oferă o soluţie funcţională pentru multe domenii ale problematicii de integrare a
aplicaţiilor, integrarea bazată pe servicii oferă mai multă valoare pe termen lung.

1.2 Probleme ale integrării

Problema integrării sistemelor informatice existente în cadrul unei întreprinderi este greu de
formalizat deoarece pleacă de la situaţii foarte diferite. În principal, integrarea sistemelor informatice
conduce la apariţia a două mari tipuri de probleme:

.a Probleme tehnice
Problemele tehnice sunt datorate eterogenităţii soluţiilor hardware şi software şi diversităţii
tehnologiilor utilizate de diversele sisteme informatice din cadrul întreprinderii. Problemele tehnice
generează o discontinuitate de comunicaţie între sistemele informatice.

Pentru rezolvarea acestei probleme, companiile furnizoare de soluţii hardware şi software au

un aport important, acestea fiind direct interesate de succesul integrării propriilor produse cu
produsele altor companii.

.b Probleme informationale
Problemele informaţionale sunt datorate inconsistenţei datelor şi duc la apariţia unei
discontinuităţi semantice şi structurale între sistemele informaţionale.

Inconsistenţa datelor este rezultatul modului în care au fost dezvoltate aplicaţiile informatice.
La realizarea acestor aplicaţii s-a ignorat că ar putea exista alte aplicaţii care să necesite acces la
datele create sau întreţinute de aplicaţia respectivă. Alte cauze ale inconsistenţei datelor sunt lipsa unei
terminologii standard de definire a conceptelor şi proceselor de afaceri la nivelul întreprinderii şi
faptul că sistemele care utilizează tehnologii învechite (sistemele moştenite) nu au implementate
mecanisme riguroase pentru declararea şi constrângerea respectării regulilor de afaceri. Soluţionarea
inconsistenţei datelor presupune:

.i Identificarea discrepanţelor şi conflictelor posibile

Discrepanţele din date apar datorită reprezentării în mod diferit a unor date similare în
sisteme diferite, lucru care poate conduce la conflicte. Diferenţele pot fi:

xiv
  Diferenţe de nume;
 Diferenţe de natură şi dimensiune;
 Diferenţe de domeniu;
 Diferenţe structurale.
.ii Politici de soluţionare a inconsistenţelor
 Utilizarea uneia din valorile inconsistente fără avertizarea utilizatorului;
 Prezentarea tuturor valorilor inconsistente utilizatorului, indicând sursa informaţiilor
şi lăsând la latitudinea utilizatorului soluţionarea problemei;
 Utilizarea celei mai recente valori, pe baza unei mărci de timp care indică momentul
actualizării informaţiei;
 Utilizarea informaţiei din sistemul cel mai de încredere, pe baza evaluării gradului de
încredere al datelor din diferite aplicaţii;
 Utilizarea unei mărimi agregate pe baza valorilor inconsistente (medie aritmetică,
minim, maxim etc).
O alternativă ar fi includerea în logica de acces la datele unei aplicaţii din alte aplicaţii,
respectiv în logica de migrare a datelor dintr-o aplicaţie în alta, a mecanismelor de tratare a
conflictelor. De exemplu, pot fi utilizate tabele de corespondenţă sau formule de conversie, precum şi
mecanisme de implementare a politicilor de soluţionare a inconsistenţei datelor .

1.3 Infrastructura de integrare

Modelul conceptual al unei organizaţii cuprinde:

 arhitectura sistemului de afaceri (operaţional şi strategic),

 arhitectura sistemului informaţional şi
 arhitectura sistemului informatic.

Lipsa unei arhitecturi de integrare a sistemelor informatice a făcut ca adesea cerinţele de

integrare să fie rezolvate prin stabilirea unor interfeţe individuale între două sisteme (integrare “punct
la punct”). Cum numărul de aplicaţii care trebuie integrate creşte în permanenţă, se ajunge inevitabil
la o reţea de perechi de conexiuni, foarte dificil de întreţinut şi dezvoltat.

Această soluţie este uşor de implementat, deoarece necesită o abstractizare redusă a datelor şi
proceselor. Dar, pe termen lung, integrarea “punct la punct” nu asigură flexibilitatea necesară adaptării
la cerinţe noi care pot să apară. Soluţiile izolate şi punctuale, rezolvă o situaţie de moment, chiar
printr-o tehnologie inovatoare, dar pe termen lung conduc la rigiditatea întreprinderii datorită
complexităţii soluţiei care devine dificil de implementat şi gestionat.

Pentru ca comunicarea şi colaborarea între aplicaţii să se poată dezvolta eficient este necesară
dezvoltarea unei infrastructuri de integrare a sistemelor la nivelul întreprinderii. Această infrastructură
trebuie să promoveze metode care să permită sistemelor partajarea de informaţii fară să mai fie nevoie
ca fiecare sistem să fie conectat cu toate celelalte.

xv
 Alegerea unei soluţii care evită utilizarea integrării “punct la punct” şi asigură un
management centralizat al integrării va conduce la reducerea efortului de realizare şi întreţinerii a
infrastructurii de integrare a sistemelor informatice.

Aşadar, infrastructura de integrare a aplicaţiilor asigură un cadru centralizat, scalabil,

gestionabil pentru integrarea tuturor sistemelor din cadrul întreprinderii, independent de
caracteristicile tehnologice ale aplicaţiilor, bazelor de date sau sistemelor de operare. Infrastructura
de integrare va permite întreprinderii să gestioneze sisteme informatice complexe, să adapteze sau să
îmbunatăţească într-un timp scurt aplicaţiile şi să reducă costurile de întreţinere a infrastructurii
tehnice la nivel de întreprindere [MATT99][DONN 99] .

Eficienţa soluţiei de integrare este furnizată de scalabilitatea sa şi de uşurinţa de gestionare în

cazul adăugării/modificării sau eliminării de sisteme în cadrul acestei infrastructuri .

Pentru a evita apariţia unor situaţii neprevăzute şi asumarea unor riscuri importante, se
recomandă o abordare incrementală în implementarea şi testarea infrastructurii de integrare la nivelul
întreprinderii.

În lipsa unei metodologii de elaborare a infrastructurii de integrare se va impune ca cerinţă

minimă respectarea următoarelor etape:

a. Definirea scopului integrarii

Identificarea acestui scop presupune definirea problemei de afaceri care trebuie rezolvată.
Scopul integrării sistemelor informatice trebuie să fie definit la nivelul întreprinderii, nu al sistemelor
individuale. La realizarea planului de integrare trebuie să ţinem seama în primul rând de obiectivele
de afaceri şi prioritatea acestora. Planurile de integrare trebuie să ţină cont de probleme pe termen
lung, cum ar fi implicaţiile modificării sistemelor existente asupra soluţiei de integrare.

b. Definirea strategiei de integrare

Definirea strategiei de integrare a sistemelor informatice la nivelul întreprinderii trebuie să

ţină cont de nevoia de flexibilitate în momentul adăugării/modificării/eliminării uneia dintre
aplicaţiile integrate. De asemenea, aplicaţiile existente trebuie să fie cât mai puţin afectate de procesul
integrării, mai ales dacă este vorba despre sisteme operaţionale cu cerinţe speciale de performanţe şi
siguranţă.

O soluţie completă de integrare a sistemelor informatice la nivelul întreprinderii trebuie să

includă tehnologii atât pentru integrare la nivelul datelor, cât şi la nivelul proceselor de afaceri.
Despre diferitele tipuri de integrare şi tehnologii utilizate pentru realizarea acestora se va vorbi în
capitolul 2.
xvi
 Datorită utilizării unei infrastructuri strategice de integrare a sistemelor informatice,
întreprinderea poate beneficia de o viziune completă asupra datelor operaţionale sau suport de decizie
din toate bazele de date, aplicaţiile şi sistemele, de la cele “moştenite” până la platformele de
integrare. O arhitectură de integrare oferă puterea de transformare, controlul interfeţelor şi
scalabilitatea necesară pentru a elimina haosul din reţeaua de interfeţe şi a oferi o flexibilitate reală în
implementarea proceselor de afaceri.

c. Definirea soluţiilor de integrare a sistemelor moştenite

Integrarea sistemelor moştenite, care utilizează o tehnologie învechită trebuie tratată distinct,
prin interfeţe formate din componente configurabile, capabile să asigure metodele pentru acces la
tranzacţiile şi datele de pe mainframe-uri. De obicei, mijloacele necesare pentru aceste interfeţe sunt
oferite de producătorii de soluţii de integrare. Există trei tipuri de interfeţe:

 Interfaţă obiect, numită “wrapping”, pentru tranzacţiile şi datele de pe mainframe. Se

recomandă pentru integrarea aplicaţiilor operaţionale cu aplicaţii Web.
 Maparea metodelor de acces specifice mainframe-lui la o interfaţă externă cu ajutorul
metadatelor. Un exemplu îl constituie interfeţele care folosesc tehnologia XML.
 Interfeţe standard de acces la baze de date, de exemplu SQL sau ODBC. Se recomandă
pentru conectarea aplicaţiilor mainframe cu aplicaţiile client-server pe două niveluri.

Pentru o întreprindere de mari dimensiuni, se recomandă o strategie care să combine toate cele trei
abordări.

Problema centrală în cazul sistemelor moştenite provine din faptul că acestea au fost
proiectate pentru a procesa cereri în mod secvenţial sau la cerere. Ele nu au fost construite pentru un
mediu eterogen de execuţie distribuită. Ca urmare, va fi necesară găsirea unui mod de simulare a
notificării evenimentelor specifice sistemelor bazate pe schimburi de mesaje.

1.4 Evoluţia aplicaţiilor integrate de gestiune a firmelor

Schimbările tot mai rapide din mediul de afaceri şi creşterea în complexitate a activităţilor din
cadrul unei companii necesită o adaptare permanentă, într-un ritm alert, care, adeseori, pune la
încercare capacităţile de efort şi analiză ale factorului uman. Sistemele ERP (Enterprise Resource
Planning) au fost create ca soluţie la aceste provocări, fiind capabile să proceseze un volum foarte
mare de date şi informaţii agregate în scopul optimizării şi eficientizării proceselor. Ideea centrală în
evoluţia sistemelor de aplicaţii pentru întreprindere este caracterul evolutiv. Punctul de plecare în

xvii
evoluţia actualelor aplicaţii pentru întreprindere ăl constituie anii ’60 şi apoi, pe parcursul a patru
decenii, urmând îndeaproape dezvoltările din domeniul sistemelor hardware şi software, a continuat
evoluţia până la sistemele ERP.

Anii ’60 se caracterizează prin faptul că majoritatea întreprinderilor realizau aplicaţii

centralizate, prin forţe proprii, ceea ce presupune că proiectarea, dezvoltarea şi implementarea lor era
făcută in–house. Cele mai multe aplicaţii se axau pe controlul stocurilor şi automatizarea gestiunii, dar
se încerca şi crearea aplicaţiilor pentru calculul automat al salariilor şi pentru contabilitate generală.
Ca şi limbaje de programare folosite în acea perioadă menţionăm COBOL, ALGOL şi FORTRAN.

În anii ’70, urmează conturarea sistemelor Material Requirements Planning (MRP). În

literatura de specialitate [FOHU04], aceste aplicaţii sunt considerate ca un set de tehnici care
utilizează inventarul, datele despre stocuri şi programul de producţie pentru calculul necesarului de
materiale, lansarea aprovizionării şi asigurarea acesteia pe parcursul procesului de fabricaţie. Văzute
prin prisma trecerii timpului şi a evoluţiei de la aplicaţiile simple de control al stocurilor, aplicaţiile
MRP au reprezentat metamorfoza sistemului de control al stocurilor sub influenţa calculatorului şi a
aplicaţiilor acestuia.

Odată cu maturizarea sistemelor MRP-uri, anii ’80 au marcat evoluţia spre MRP II sau
Manufacturing Resource Planning care este conceput în jurul ideii de optimizare a proceselor de
fabricaţie prin sincronizarea necesarului de materiale cu cerinţele producţiei. Zonele de aplicaţie a
acestor sisteme s-au extins mult peste departamentul producţiei şi au ajuns să aibă aplicabilitate şi
departamentele: financiar, resurse umane, distribuţie, vânzare, gestiunea proiectelor.

La acel moment, MRP II era soluţia pentru planificarea eficientă a tuturor resurselor
întreprinderii şi asigura planificarea operaţională a necesarului care susţine procesele de producţie,
planificarea financiară şi elaborarea de scenarii de tipul “ce ar fi dacă?”. Funcţiunile integrate ale
acestor sisteme vizau: planificarea producţiei, planul de vânzări, programarea producţiei, planificarea
necesarului de materiale, planificarea capacităţilor de producţie, ca şi urmărirea execuţiei –
aprovizionare, fabricaţie, vânzare. Deosebit de importante sunt ieşirile oferite de aceste sisteme:
rapoarte financiare, plan de vânzări, plan de aprovizionare, proiecţii de stocuri, buget de expediţie şi
transport.

Pe baza acestor câtorva caracteristici prezentate, putem afirma faptul că MRP II nu este doar
un instrument de planificare şi urmărire a producţiei, el fiind un sistem mult mai complex care a
evoluat către ceva şi mai cuprinzător şi anume, Enterprise Resource Planning. În [FOHU04] se
arată că la acel moment s-a propus un alt nume, care a funcţionat pentru un timp: BRP (Business
Resource Planning), denumire care subliniază faptul că este mai mult decât un sistem care se
adresează exclusiv producţiei. Potrivit resurselor de pe internet, şi anume site-ului
xviii
www.technologyevaluation.com , cei care au introdus conceptul de ERP sunt cei de la Gartner
Group.

Deci, sfârşitul anilor ’80 şi anii ’90 au fost marcaţi de apariţia sistemelor ERP, ele fiind
rezultatul extinderii funcţionalităţii suitelor MRPII. Având ca şi punct de plecare, fundaţia tehnologică
a MRP II, sistemele ERP integreaza toate procesele economice: producţie, distribuţie, contabilitate,
financiar, personal, stocuri, service şi întreţinere, logistică şi gestiune proiecte, asigurând consistenţa
informaţională, accesul şi vizibilitatea în întreaga organizaţie.

Menţinând caracterul evolutiv, producătorii de soluţii ERP, au adăugat suitelor lor, noi module
şi funcţionalităţi, şi s-a produs astfel trecerea la o nouă etapă în evoluţia sistemelor ERP şi anume
“ERP extins”. Anii 2000 sunt caracterizaţi prin aplicaţii precum APS (Advanced Planning and
Scheduling), soluţii e-business pe zona relaţiilor cu clienţii – CRM (Customer Relationship
Management) sau pe furnizori-aprovizionare – SCM (Supply Chain Management). Tot în acestă
perioadă au apărut şi concepte noi, cum sunt BPI (Business Process Integration), EAI (Enterprise
Application Integration), ENS (Enterprise Nervous System).

Pentru a ilustra grafic evoluţia sistemelor ERP de-a lungul celor 4 decenii, prezentăm, în
continuare, următoarea figură:

Figura 1 - Evoluţia aplicaţiilor integrate de gestiune a firmelor( prelucrare şi adaptare după [FOHU04]

xix
2 SISTEME DE PLANIFICARE A
RESURSELOR ÎNTREPRINDERII DE TIP ERP

2.1 Sistemele ERP

Planificarea resurselor întreprinderii (Enterprise Resource Planning - ERP) reprezintă „un

cadru pentru organizarea, definirea, şi standardizarea proceselor de afaceri necesare pentru
planificarea şi controlul eficient al organizaţiei, astfel încât organizaţia să poată utiliza cunoştinţele
sale interne în vederea obţinerii unor avantaje externe.” (definiţie conform dicţionarului APICS).
Sistemele ERP sunt „sisteme software pentru managementul afacerii, care încorporează
module ce sprijină ariile funcţionale ale afacerii, precum planificarea, producţia, vânzări, marketing,
distribuţie, contabilitate, financiar, managementul resurselor umane, managementul proiectului,
managementul inventarului, service şi mentenanţă, transport şi afaceri electronice (e
-business)”[Rashid ş.a., 2002].
Sistemele de planificare a resurselor întreprinderii integrează toate activităţile întreprinderii
într-o manieră transparentă şi disponibilă utilizatorului final al sistemului.
În figura 1 este prezentat schema unui sistem ERP.

2.2 Arhitectura unui sistem ERP

Sistemul aplicaţiilor de planificare a resurselor întreprinderii se implementează pe o
arhitectură de tip client-server care creează premisele unui mediu de prelucrare descentralizat.

Caracterizarea funcţiunilor celor trei niveluri ale arhitecturii:

 Nivelul prezentare – constă în interfaţa grafică utilizator sau programul de navigare (browser)
pentru accesarea funcţiilor sistemului;
 Nivelul aplicaţie – cuprinde regulile afacerii, logica şi funcţiunile sistemului, programele care
asigură transferul datelor la serverele de baze de date;

xx
 Nivelul bazei de date – asigură gestiunea datelor organizaţiei, inclusiv a metadatelor. Această
structurare logică permite ca interfaţa sistemului ERP să ruleze pe calculatorul utilizatorului,
prelucrarea să se realizeze pe nivelul de mijloc al serverelor de aplicaţii, iar sistemele de baze de
date să funcţioneze pe al treilea strat, al serverelor specializate.

2.3 Componentele sistemului informatic ERP

Componentele sistemului informatic ERP sunt:

 Nomenclatoare cunoscute sub denumirea de fişiere de bază de clienţi, furnizori, personal.
 Contabilitate generală şi financiar contabilă care asigură conducerea evidenţei contabile şi
gestiunea financiară;
 Încasări – plăţi, această componentă este formată din două module, debitori şi creditori, care
gestionează şi înregistrează creanţele şi datoriile întreprinderii;
 Salarizare, această componentă este legată de cea de resurse umane, care are ca obiectiv
calcularea şi evidenţa salariilor. Se calculează automat taxele, contribuţiile la bugetul statului şi al
asigurărilor sociale;
 Resurse umane, este componenta care sprijină crearea unei politici de personal, ajutând la
activitatea de recrutare şi selecţie a personalului;
 Imobilizări - această componentă gestionează mijloacele fixe, si obiectivele de inventar sau
activele necorporale. Oferă multiple posibilităţi de calcul, înregistrare a amortizării;
 Planificare şi producţie - planifică termenele de producţie, articole de realizat, costuri producţie şi
detalii tehnice;
 Urmărire producţie - înregistrează preluarea notelor de predare şi a rapoartelor de lucru,
analizează şi compară comenzile lansate, oferă rapoarte cumulate şi detaliate ale producţiei pe
faze, produse, şi rapoarte de costuri;
 Gestiune date tehnice – stochează definiţiile şi caracteristicile tehnice ale produselor şi
tehnologiilor de fabricaţie;
 Planificarea necesarului de materiale - această componentă determină automat cantităţile
necesare, pe baza datelor despre procesul de fabricaţie şi a planului de producţie aprobat;
 Planificarea şi urmărirea consumurilor şi costurilor - întocmeşte bonurile de consum şi prelucreză
datele despre consumuri de la magazii, centralizează datele pentru calculul costurilor, generează
rapoarte detaliate sau centralizate cu privire la cosumurile planificate şi realizate;
 Managementul proiectelor - această componentă are ca obiect proiectele de investiţii, activităţile
interne sau lucrările efectuate de terţi.
 Stocuri - gestionează cantitativ şi calitativ stocurile şi generează automat documentele contabile;
 Gestiunea depozitelor - defineşte unităţile de stocare, tipurile de inventar şi subinventar, depozite,
magazii, locaţii, modul de localizare al stocurilor;
 Aprovizionare - componenta depăşeşte atribuţiile unei aplicaţii de gestiune, este un instrument de
optimizare al aprovizionării, care determină realizarea eficientă a aprovizionării pentru a face
economii. Modulul aprovizionare este în strânsă legătură cu componenta stocuri;
 Vânzări - gestionează activităţile specifice procesului de vânzare;
 Întreţinerea echipamentelor - gestionează modul de utilizare a echipamentelor, permite
planificarea resurselor şi costurile lucrărilor care trebuie efectuate pentru mentenanţă. Este foarte
importantă pentru istoricul activităţilor de întreţinere şi reparaţie;
 Transport - permite planificarea şi gestionarea activităţilor logistice din procesele de vânzare şi
distribuţie;

xxi
 Service – urmăreşte activităţile de garanţie şi serviciile de postvânzare.
 Analiză – modulul preia datele din baza de date şi realizează diferite rapoarte, analize şi
furnizează informaţiile în forma dorită de utilizator.
 Generator de rapoarte – utilizatorii obţin rapoarte din cadrul fiecărui modul funcţional folosind
datele din baza de date a sistemului ERP.

2.4 Obiectivele punctuale ale sistemelor informatice ERP

Având în vedere că sistemul informatic de planificare a resurselor întreprinderii este subordonat

procesului decizional, al cărui rol este de a asigura funcţionarea normală şi optimă a întregii activităţi
şi de a reduce la minimum pierderile în caz de funcţionare anormală, rezultă că obiectivul oricărui
sistem informatic trebuie să fie subordonat obiectivului propriu-zis al unităţii economice.
Obiectivul principal urmărit prin introducerea unui sistem informatic, îl constituie asigurarea,
în timp util, a tuturor informaţiilor necesare în procesul conducerii, în scopul fundamentării şi
elaborării deciziilor cu privire la desfăşurarea cât mai eficientă a întregii activităţi din unitatea
economică.

2.5 Principalele caracteristici ale unei soluţii ERP

Principalele caracteristici ale unei soluţii ERP sunt [Rashid ş.a., 2002]:
 Design structurat şi modular, care încorporează module pentru diferite funcţiuni ale afacerii;
 Utilizarea unei baze de date centrale;
 Complexitate ridicată;
 Costuri ridicate;
 Flexibilitate;
 Încorporarea celor mai bune practici de afaceri;
 Integrarea modulelor componente într-o manieră care asigură fluxul informaţiilor între toate
modulele aplicaţiei, cu grad ridicat de transparenţă;
 Consumul de timp, necesar pentru configurarea şi adaptarea soluţiei la nevoile organizaţiei;

2.6 Evoluţia sistemelor de planificare a resurselor întreprinderii ERP

Evoluţia sistemelor ERP s-a desfăşurat în paralel cu dezvoltările uluitoare din domeniul programelor
software şi a componentelor hardware, trecând prin câteva etape semnificative [Rashid ş.a.,2002].
Începând cu anii 1960, a început proiectarea şi implementarea sistemelor centralizate de
calculatoare, destinate în primul rând pentru automatizarea sistemelor de control.
Prin anii 1970, încep să apară primele sisteme de planificare a necesarului de materiale, pentru
a veni în ajutorul întreprinderilor pentru a-şi planifica necesarul de materie primă, în funcţie de
producţia planificată.
În anii 1980, au apărut sistemele de planificare a resurselor de producţie, a cărui scop era
optimizarea proceselor de producţie, aceste sisteme aveau incorporate şi resursele umane, distribuţia
produselor, fiind destinate marilor corporaţii.
Sistemele de planificare a resurselor întreprinderii, au apărut la începutul anilor 1990, ele fiind
prezente în marile companii şi multinaţionale. Începând cu anul 1995, a început implementarea
sistemelor de tip ERP, şi în întreprinderi mici şi mijlocii din România.

xxii
2.7 Avantaje implementării sistemelor de planificare a resurselor
întreprinderii ERP

Principalele avantaje ale implementării unui sistem ERP în organizaţie sunt [Rashid ş.a.,
2002]:
 Acces la informaţii sigure - soluţia ERP stochează toate informaţiile privind activităţile
întreprinderii într-o bază de date comună, oferind informaţii precise şi sigure şi rapoarte
îmbunătăţite;
 Evitarea redundanţei datelor şi operaţiilor - se elimină necesitatea introducerilor multiple de date,
întrucât toate modulele sistemului ERP accesează informaţiile din baza de date centrală; de
exemplu, odată ce o tranzacţie de vânzare este înregistrată în aplicaţie, aceasta devine accesibilă
tuturor modulelor sistemului;
 Reducerea timpilor de livrare - se minimizează întârzierile raportărilor;
 Reducerea costurilor - „Timpul înseamnă bani”, iar soluţia ERP permite economisirea resurselor
de timp prin oferirea unui control mai bun asupra tuturor deciziilor organizaţionale;
 Grad ridicat de adaptabilitate - soluţia ERP poate fi restructurată şi adaptată cu uşurinţă dacă
întreprinderea aduce modificări proceselor sale de afaceri;
 Scalabilitate îmbunătăţită - sistemele ERP sunt proiectate într-o manieră structurată şi modulară,
conţinând module de bază ale aplicaţiei şi o serie de module suplimentare (de tip „add-on”), care
pot fi adăugate în funcţie de necesităţile organizaţiei;
 Mentenanţă îmbunătăţită - relaţia dintre furnizorul sistemului ERP şi întreprinderea care adoptă
soluţia nu se încheie odată cu achiziţia şi implementarea sistemului în organizaţie; furnizorul
soluţiei ERP va asigura întreprinderii asistenţă pe termen lung;
 Extindere - soluţiile ERP pot fi integrate cu alte aplicaţii importante, cum sunt Managementul
relaţiei cu clienţii (CRM) sau Managementul lanţului de distribuţie (SCM );
 Comerţ electronic şi afaceri electronice – soluţiile ERP pot oferi opţiuni pentru comerţul pe
internet.

2.8 Dezavantajele implementării sistemelor de planificare a resurselor

întreprinderii ERP

Sistemele ERP prezintă şi dezavantaje, iar unele dintre avantajele prezentate anterior pot
deveni dezavantaje [Rashid ş.a., 2002]:

 Costuri extrem de ridicate. Cheltuielile pe care le implică adoptarea unei soluţii ERP în
organizaţie variază de la mii la milioane de Euro, fapt ce le transformă într-o investiţie riscantă. În
plus, cel mai adesea funcţionalităţile unui sistem ERP nu se mulează perfect pe nevoile specifice
ale întreprinderii, şi drept urmare organizaţia va trebui să reproiecteze unele dintre procesele sale
de afaceri, ceea ce atrage după sine alte cheltuieli semnificative;

 Consumatoare de timp. Adoptarea unei soluţii ERP aduce modificări majore într-o organizaţie,
fiind un proces extrem de complex şi care poate conduce chiar la nevoia firmei de a-şi modifica
cultura organizaţională;

 Conformitatea modulelor. În alegerea unei soluţii ERP, organizaţiile trebuie să ţină cont de
obiectivele lor strategice şi de propriile procese de afaceri.
xxiii
 Complexitate. Un sistem ERP încorporează foarte multe module. Se pare că sunt puţine la număr
companiile care exploatează toate funcţiunile soluţiei ERP adoptate; mai degrabă, principiul 80/20
se aplică şi în domeniul sistemelor ERP, adică 80% dintre organizaţiile care adoptă o soluţie ERP
folosesc doar 20% dintre funcţiunile acesteia, şi numai 20% dintre firmele care adoptă aceeaşi
soluţie exploatează 80% dintre funcţiuni. Pentru a reduce acest dezavantaj, se recomandă
organizaţiei să implementeze doar acele module ale soluţiei ERP care îi sunt cu adevărat necesare;

 Dependenţa de furnizorul soluţiei. Relaţia dintre furnizor şi clientul care adoptă soluţia trebuie să
rămână extrem de strânsă şi după finalizarea implementării, datorită serviciilor de mentenanţă,
asistenţă tehnică, upgrade la versiuni mai noi, etc.

2.9 Managementul proiectului

Implementarea unei soluţii ERP într-o organizaţie necesită resurse consistente: oameni, bani,
timp. Dată fiind complexitatea pe care o prezintă implementarea unei astfel de soluţii, managementul
proiectului îi este necesar organizaţiei pentru planificarea, coordonarea şi monitorizarea diferitelor
activităţi desfăşurate pe parcursul tuturor etapelor de implementare [Ngai ş.a., 2008].
Diferenţele culturale reprezintă un alt factor critic de succes pentru implementarea unei soluţii
ERP, întrucât numeroase studii au arătat că unele soluţii ERP dezvoltate de furnizori occidentali şi
bazate pe modele foarte bune de afaceri, nu au putut fi implementate cu succes în organizaţii asiatice,
din cauză că nu satisfăceau cerinţele organizaţiilor respective. Dincolo de diferenţele culturale
evidente (de exemplu, afacerile din China au nevoie de o soluţie ERP care se ofere interfaţă pentru
utilizatori în limba chineză), alţi autori [Ngai ş.a., 2008] propun extinderea factorului critic de succes
„diferenţe culturale” în „cerinţe funcţionale specifice ţării”, întrucât companiile din diferite ţări au
necesităţi diferite, în funcţie de practicile de afaceri şi cerinţele guvernamentale sau legale din ţările
respective.
Selectarea sistemului ERP este de importanţă vitală pentru o implementare de succes, dar nu
este deloc facilă, întrucât compania care doreşte să adopte soluţia ERP trebuie să ia în considerare o
serie de variabile extrem de importante: caracteristicile sistemului, durata sa de implementare, preţul,
asistenţa tehnică oferită de furnizorul sistemului pe durata implementării şi post - implementare,
corelaţia dintre nevoile organizaţionale şi funcţionalităţile sistemului. În ceea ce priveşte ultima
variabilă menţionată, adică „potrivirea” dintre soluţia ERP şi specificul afacerii, autorii [Ngai ş.a.,
2008] recomandă alegerea soluţiei ERP care prezintă „cel mai ridicat grad de potrivire” cu necesităţile
companiei; în acest sens, este necesar ca anterior achiziţiei unei soluţii ERP, organizaţia să efectueze o
analiză a discrepanţelor dintre caracteristicile şi modulele sistemului şi nevoile organizaţionale, prin
implicarea în această analiză a specialiştilor tehnici şi a angajaţilor care vor deveni utilizatori ai
sistemului [Ngai ş.a., 2008].
Implementarea unui sistem ERP implică adesea costuri uriaşe pentru organizaţia care decide
să-l achiziţioneze. Probabil companiile care nu deţin suficiente informaţii despre domeniul soluţiilor
ERP ar putea crede că simpla achiziţionare şi implementare a unui sistem ERP este suficientă pentru
ca ulterior totul „să meargă ca pe roate”. În realitate, cel mai adesea nu soluţia ERP va fi modificată
pentru a fi adaptată la nevoile specifice ale organizaţiei, ci firma trebuie să-şi reproiecteze procesele
de afaceri pentru a exploata cu succes toate funcţiunile oferite de soluţia ERP.

2.10 Factori importanţi pentru implementarea sistemelor de gestiune ERP

xxiv
 Companiile care doresc să achiziţioneze şi să implementeze un sistem informatic de tip ERP,
trebuie să ia neapărat în calcul şi faptul că nu întotdeauna implementarea unui sistem de gestiune
garantează si succesul firmei.
Pe baza analizei literaturii de specialitate, unii autori [Basoglu ş.a, 2007] consideră că
principalii factori de succes pentru sistemele ERP sunt:
1) Sprijinul acordat de managementul de vârf al organizaţiei este considerat unul dintre cei mai
importanţi factori de succes pentru implementarea oricărui sistem informatic sau tehnologic,
iar soluţiile ERP pentru afaceri nu fac excepţie de la această realitate. Implementarea oricărei
soluţii ERP trebuie să beneficieze de aprobarea managementului de vârf al companiei, iar apoi
să aibă parte de suportul acestuia pe toată durata proiectului. Top managementul organizaţiei
trebuie să gestioneze cu atenţie şi aspectele psihologice sau comportamentale pe care le
implică implementarea soluţiei, mai ales dacă procesul de implementare este întâmpinat cu
rezistenţă la schimbare de către angajaţi;
2). Instruirea utilizatorilor sistemului este esenţială pentru implementarea cu succes a soluţiei
ERP;
3). Utilizatorii sistemului trebuie educaţi pentru a înţelege conceptele soluţiei ERP adoptate,
pentru a se familiariza cu procesele şi practicile de afaceri încorporate în soluţie, astfel încât la finalul
implementării ei să accepte în totalitate soluţia şi să fie apţi să o folosească cu succes.

xxv
3 PARTICULARITĂŢI ALE IMPLEMENTĂRII
SISTEMELOR ERP

3.1 Costul unui sistem ERP

Adoptarea unui sistem ERP implică cheltuieli uriaşe pentru organizaţii, indiferent de dimensiunea
acestora: de la zeci de mii de Euro (în cazul întreprinderilor mijlocii), până la milioane de Euro, în
situaţia marilor companii. Situaţia devine cu atât mai dificilă dacă sunteţi antreprenor şi cel mai
probabil, nu dispuneţi de un buget generos pe care să îl alocaţi pentru adoptarea soluţiei ERP. Atunci
când o organizaţie este interesată de adoptarea unei soluţii ERP şi începe să compare ofertele mai
multor furnizori, nu trebuie scăpat din vedere un aspect extrem de important, compania nu va trebui să
plătească doar costul de achiziţie al sistemului şi licenţele de utilizare, pe parcursul implementării
proiectului vor apărea numeroase cheltuieli în plus, ceea ce poate conduce la nevoia de a dubla sau
chiar tripla bugetul alocat de organizaţie pentru adoptarea soluţiei respective.
De exemplu, furnizorul de soluţii pentru afaceri SAP vine în sprijinul procesului decizional al
potenţialilor săi clienţi, punând la dispoziţia acestora un configurator online care permite estimarea
costurilor de achiziţie şi implementare a unei configuraţii SAP Business All-in -One, în funcţie de
cerinţele clientului, acest configurator este disponibil la adresa
http://www.sap.com/roman ia/solutions/configurator.
O firmă care este interesată de achiziţia unui pachet SAP Business All-in-One va accesa
configuratorul la adresa menţionată, apoi va selecta industria în care activează (opţiuni disponibile –
Comerţ / Producţie / Servicii Tehnice), va introduce numărul de angajaţi ai întreprinderii, respectiv
numărul de angajaţi care vor deveni utilizatori ai sistemului, şi va selecta modulele de care are nevoie
în cadrul soluţiei ERP. Pe baza acestor informaţii, completate de informaţii de identificare, firma va
cunoaşte costurile pe care le implică achiziţionarea soluţiei configurate.
Platforma hardware susţine soluţia ERP şi reprezintă punctul de start în diferenţierea costurilor
diferitelor sisteme ERP. Costurile sunt variabile, dar trebuie luate în calcul, întrucât există produse
care pot rula o bună perioadă de timp (de ordinul anilor) pe aceeaşi platformă şi sisteme ERP care
solicită upgradarea platformei hardware la apariţia oricărei noi versiuni a sistemului.
Costul de suport reprezintă costul pentru suportul sistemului pe durata unui an şi în general,
echivalează cu 20-25% din costul iniţial de achiziţie.
Costul de implementare a soluţiei diferă între furnizorii de soluţii ERP şi include cheltuielile
cu instalarea produsului, cu preluarea datelor din vechiul sistem al organizaţiei, cu trainingul
angajaţilor care vor utiliza aplicaţia, cu managementul proiectului etc.
Costurile de personalizare apar atunci când organizaţia are nevoie de customizarea soluţiei
ERP la nevoile sale specifice. Aceste costuri pot fi uriaşe. Din fericire, organizaţiile pot elimina sau
minimiza aceste costuri, fie se va alege de la bun început o soluţie ERP care se mulează cel mai bine
pe nevoile firmei, fie întreprinderea va reproiecta unele dintre procesele sale de afaceri pentru a se
adapta soluţiei ERP, ceea ce implică cheltuieli mai reduse decât particularizarea produsului la
organizaţie.

xxvi
 Costurile de mentenanţă sunt o componentă esenţială în procesul de determinare a cheltuielilor
pe care le implică pe termen lung soluţia ERP adoptată.
Costul de integrare este dat de necesitatea de integrare a soluţiei ERP proaspăt adoptate cu
toate celelalte sisteme şi aplicaţii existente în organizaţie şi variază în funcţie de specificul de
activitate al organizaţiei şi de dimensiunea sa.
Costul cu aplicaţii terţe reprezintă costurile aplicaţiilor conexe soluţiei de ERP, cum sunt
diferitele aplicaţii de comunicare sau bazele de date.
Prin reunirea acestor componente de preţ, se determină costul total al soluţiei ERP.

3.2 Mentenanţa sistemului informatic ERP

Mentenanţa sistemului informatic de planificare a resurselor întreprinderii ERP reprezintă

totalitatea acţiunilor efectuate pentru menţinerea stării de funcţionare.
Mentenanţa poate fi caracterizată prin următoarele activităţi:
 Mentenanţă neplanificată adică diagnosticarea şi corectarea erorilor;
 Mentenanţă adaptivă: activitate care modifică software-ul pentru a interacţiona corect cu un
mediu în schimbare (hardware sau software);
 Mentenaţă perfectivă: activităţi pentru adăugarea de noi capabilităţi, modificarea funcţionalităţii
existente şi aducerea de îmbunătăţiri generale;
 Mentenanţă preventivă (planificată): activităţi care pregătesc produsul software pentru o mai bună
mentenabilitate sau fiabilitate în viitor, sau pentru a pune baza unor viitoare îmbunătăţiri.
Pe parcursul ciclului de viaţa a unui proiect, după fazele de analiză de proiect şi dezvoltare,
întreţinerea sistemului are un rol foarte important. Pe măsură ce un proiect devine tot mai mare şi mai
complex, creşte cantitatea datelor gestionate şi infrastructura, necesitând un suport tehnic elaborat
pentru a ţine în funcţiune şi a întreţine componentele software şi hardware ale acestui sistem. În
majoritatea cazurilor un sistem informatic dezvoltat la cerere poate fi întreţinut doar de compania care
l-a proiectat şi dezvoltat, deci este foarte important să ofere aceste servicii compania care dezvoltă un
produs informatic. Astfel, în cursul exploatării curente, apar momente care solicită intervenţii de
menţinere în funcţiune a sistemului.
Există o mulţime variată de motive pentru care apar defecte în dezvoltarea produselor
software:
 Lipsa comunicării sau comunicare slabă în cadrul proiectului;
 Constrângeri de timp şi de buget, care duc la presiune şi la apariţia erorilor;
 Cerinţe care nu au fost specificate suficient de clar;
 Modificări în cerinţe si o slabă documentare a lor;
 Presupuneri;
 Pregătire insuficientă;
 Erori de programare.
Rezolvarea acestora implică intervenţii ce pot include una sau mai multe dintre activităţile
derulate pentru creare: definire de cerinţe, analiză, proiectare, construcţie, testare, introducere în
exploatare.
Pentru că schimbările sunt inevitabile, trebuie dezvoltate mecanisme pentru a identifica,
evalua, controla, efectua şi raporta modificările necesare. Aceste activităţi încep odată cu proiectul şi
se încheie doar când produsul este retras din funcţiune.

xxvii
3.3 Implementarea sistemelor ERP în întreprinderi mici şi mijlocii

Pe măsură ce majoritatea companiilor mari au implementat sisteme de planificare a resurselor,

numeroşi furnizori de soluţii ERP au început să-şi îndrepte atenţia şi asupra afacerilor mici şi mijlocii,
venindu-le în întâmpinare cu sisteme adaptate pentru nevoile lor specifice. Noua orientare a
furnizorilor ERP către IMM -uri se datorează următoarelor aspecte [Morabito ş.a., 2005]:

 Saturaţia pieţei reprezentate de companiile mari şi multinaţionale;

 Integrarea lanţului de distribuţie între afacerile mici şi marile companii;

 Numărul mult mai redus de companii mari, comparativ cu numărul de IMM -uri existente (de
exemplu, în UWniunea Europeană peste 97% dintre întreprinderile existente sunt reprezentate de
afacerile mici şi mijlocii);

 Dezvoltările tehnologice.

Din punctul de vedere al aceloraşi autori [Morabito ş.a., 2005], există două diferenţe majore
între sistemele ERP pentru marile companii şi soluţiile ERP destinate IMM -urilor:

Soluţiile ERP pentru afacerile mici şi mijlocii se caracterizează printr-o implementare

simplificată, ceea ce presupune reducerea cheltuielilor; astfel, implementarea unei soluţii ERP într-o
companie mare poate dura şi 9 luni, în timp ce durata de implementare a soluţiei într-un IMM este de
2-3 luni.

Spre deosebire de sistemele ERP pentru companii mari, soluţiile destinate IMM-urilor sunt
comercializate, implementate şi asistate post-implementare de către revânzători cu valoare adăugată,
care beneficiază de acces la codul aplicaţiei şi o pot modifica ei înşişi. Cu toate acestea, un studiu
realizat pentru Comisia Europeană în 2006 , arăta că dintre firmele care utilizează calculatoare, în
funcţie de dimensiunea afacerii, gradul de adoptare a soluţiilor ERP în IMM –uri este destul de redus:
7% în microîntreprinderi, 16% în întreprinderile mici şi 25% în întreprinderile mijlocii, spre deosebire
de 45% în cazul companiilor cu peste 250 angajaţi.

Aberdeen Group, o companie renumită de cercetare în domeniul sistemelor IT pentru afaceri, a

desfăşurat o cercetare pe 454 IMM-uri, privind diferite aspecte ale adoptării soluţiilor ERP în afacerile
mici şi mijlocii. Principalele arii de interes ale cercetării şi rezultatele obţinute sunt redate succinct în
continuare.

Principali factori care influenţează strategia de implementare ERP:

 Standardizarea şi automatizarea proceselor de producţie (66% dintre firmele respondente);

 Presiunea de reducere a cheltuielilor operaţionale (53%);

 Necesitatea de îmbunătăţire a serviciilor pentru clienţi (43%);

 Conexiunea cu operaţiuni globale (26%);

 Creşterea veniturilor (12%);

 Facilitarea conexiunilor cu partenerii externi ai afacerii (13%).

xxviii
 Prinicipalele provocări cu care se confruntă IMM-urile în ceea ce priveşte implementarea şi
mentenanţa unei soluţii ERP:

 Particularizarea soluţiei ERP la nevoile specifice ale afacerii (40%);

 Reproiectarea proceselor de afaceri (39%);

 Trainingul utilizatorilor (39%);

 Cheltuielile cu upgrade (33%);

 Flexibilitatea redusă a soluţiei ERP de adaptare la procesele de afaceri (28%);

 Costuri ridicate de mentenanţă a sistemului ERP (28%);

 Costuri ridicate cu integrarea sistemului ERP (23%);

 Durata prea lungă de implementare (18%).

Modalităţi prin care IMM-urile fac faţă provocărilor legate de adoptarea soluţiilor ERP:

 Alinierea proceselor de afaceri la funcţiunile sistemului ERP (60%);

 Alinierea funcţiunilor sistemului ERP la procesele de afaceri (49%);

 Eliminarea activităţilor de particularizare a soluţiei ERP (39%);

 Utilizarea consultanţilor externi (35%);

 Dezvoltarea unor aplicaţii informatice mai moderne (33%).

Indicatori de performanţă ai soluţiei ERP adoptate (cum măsoară IMM-urile beneficiile pe

care le generează sistemul ERP implementat):

 Fluidizarea proceselor de afaceri (53%);

 Automatizarea proceselor manuale (47%);

 Vizibilitatea pe care sistemul ERP o conferă asupra întregii afaceri (39%);

 Cheltuielile cu componenta software şi serviciile ataşate (29%);

 Rentabilitatea investiţiei în sistemul ERP (26%);

 Reducerea cheltuielilor (26%);

 Durata de implementare integrală a soluţiei ERP (22%);

Criteriile de selecţie a unei soluţii ERP:

 Funcţionalităţile soluţiei (64%);

 Costul total de proprietate al soluţiei ERP (48%);

 Uşurinţa în utilizare a sistemului (46%).

xxix
 Decizii critice privind adoptarea soluţiilor ERP în IMM-uri. Pe baza analizei literaturii de
specialitate, dar şi a implicării directe în procesele de implementare a sistemelor ERP în IMM-uri,
Malhotra&Temponi (2010) argumentează că există şase decizii critice pe care o afacere mică sau
mijlocie trebuie să le ia în ceea ce priveşte adoptarea unei soluţii ERP.

1. Structura echipei de proiect

Deşi există mai multe modalităţi de formare a echipei de proiect care se va ocupa de adoptarea
soluţiei ERP în organizaţie, se pare că modalitatea cea mai eficientă pentru IMM -uri este cea “cu
greutate” (în engl. heavyweight). Sructura unei echipe de acest tip nu necesită ca membrii proiectului
să se dedice în exclusivitate unor sarcini bine delimitate din cadrul proiectului, ci responsabilităţile
fiecăruia dintre membrii pot varia în funcţie de cerinţele specifice fiecărei etape de implementare.
Echipa de proiect va fi condusă de un manager care va dispune de control şi autoritate direct asupra
echipei. Principalele avantaje ale unei echipe de proiect ERP de tip “heavyweight” constă în: creşterea
şanselor de aliniere a implementării soluţiei ERP cu strategia de afaceri, rezolvarea rapidă a
potenţialelor conflicte, o comunicare eficientă privind toate aspectele proiectului de implementare.
Formarea echipei de proiect ERP de acest tip este ideală pentru afacerile mici, dar devine mai dificil
de utilizat pe măsură ce creşte complexitatea implementării soluţiei.

2. Implementarea strategiei

În alegerea strategiei de implementare a soluţiei ERP, IMM-urile sunt condiţionate de resursele

umane şi tehnice disponibile, pe care cu certitudine nu le pot aloca în regim exclusiv pentru a
implementa aplicaţia ERP. De asemenea, limitările financiare joacă un rol esenţial în alegerea
strategiei de implementare. Ţinând cont de aceste restricţii cu care se confruntă afacerile mici şi
mijlocii, strategia parteneriatului pare a fi cea mai bună soluţie pentru implementarea unei soluţii ERP.
Această strategie presupune utilizarea resurselor interne şi externe, şi împărţirea responsabilităţilor
proiectului ERP între membrii interni ai organizaţiei şi partenerii externi. Principalul avantaj al
strategiei de tip parteneriat constă în expertiza şi resursele cu care contribuie partenerii organizaţiei.
Desigur, este posibil să apară conflicte între partenerii de proiect, fapt ce poate prelungi durata de
implementare a soluţiei ERP, dar dacă echipa de proiect are o structură tip “heavy weight”, managerul
proiectului poate interveni prompt pentru a rezolva conflictele.

3. Selectarea tehnicii de tranziţie

În momentul adoptării unei soluţii ERP, în organizaţie există deja anumite sisteme, care pot
varia de la sisteme de tip manual (tipărite pe hârtie) la o soluţie ERP eşuată sau la o versiunea mai
veche a soluţiei ERP a cărei implementare se doreşte în prezent. Adoptarea noii soluţii va duce la
înlocuirea sistemului existent în organizaţie, iar compania trebuie să decidă asupra unei tehnici de
tranziţie de la vechiul sistem la noua soluţie. Pentru IMM-uri se recomandă alegerea unei tranziţii
etapizate, ceea ce presupune tranziţia, în ordine secvenţială, a câte unui modul. Alegerea acestui tip de
tranziţie permite firmei reducerea resurselor care trebuie alocate, întrucât în fiecare etapă sunt
necesare resurse pentru tranziţia unui singur modul. Pe de altă parte, trecerea integrală la noul sistem
ERP va dura mai mult timp şi vor fi necesare resurse tehnice suplimentare pentru a dezvolta interfeţe
de program care să asigure funcţionarea în paralel a vechiului sistem şi a noii soluţii ERP, până la
tranziţia cu succes a tuturor modulelor.

4. Strategia de conversie a bazei de date pentru sistemul ERP

xxx
 Odată cu tranziţia la noul sistem ERP, informaţiile conţinute în vechiul sistem trebuie
transferate în noua soluţie; în acest scop, IMM-urile pot apela la două metode de conversie a bazei de
date: electronică şi manuală. Conversia electronică a bazei de date este rapidă şi se face automat de
către softuri specializate.

Pe de altă parte, conversia manuală presupune introducerea datelor în noul sistem de către
utilizatori.

Desigur, conversia manuală a datelor necesită o perioadă mult mai îndelungată de timp decât
cea electronică, dar facilitează verificarea integrităţii informaţiilor care trebuie transferate în noul
sistem. Pentru majoritatea afacerilor mici şi mijlocii, metoda de conversie recomandată este cea
manuală, mai mult, este indicat ca introducerea manuală a informaţiilor în noul sistem să fie realizată
chiar de către viitori utilizatori direcţi ai aplicaţiei, care pot astfel să se familiarizeze mai uşor cu noul
mediu de lucru.

5. Strategia de managementul riscului în implementarea ERP

Implementarea unei soluţii ERP este extrem de complexă, poate generea beneficii deosebite
pentru afacere, dar comportă şi riscuri majore. Riscurile asociate cu implementarea soluţiei ERP într-
un IMM pot deriva din următorii factori:

Locaţia IMM-ului: angajaţii afacerilor mici sau mijlocii care activează în localităţi de
dimensiuni reduse vor manifesta rezistenţă mai înaltă la adoptarea soluţiilor ERP, întrucât, dată fiind
dimensiunea redusă a localităţii, nu au şansa de a intra în contact cu alţi utilizatori ai sistemelor ERP,
care le-ar putea împărtăşi din propria experinţă de utilizatori.

Realităţile IMM-urilor: afacerile mici şi mijlocii sunt adesea supuse presiunilor

financiare imediate, de accea un IMM va fi mai tentat să aleagă o soluţie ERP ce presupune
costuri mai reduse, în defavoarea uneia care i-ar putea aduce beneficii strategice.

Nişa firmei: adesea IMM-urile acţionează pe o piaţă de nişă, cu un produs specific, iar această
piaţă poate să nu prezinte suficient interes pentru furnizorii de soluţii ERP, astfel încât aceştia nu vor
elabora soluţii ERP care să se potrivească specificului de activitate al IMM -ului în cauză.

6. Strategia de managementul schimbării

Angajaţii unei organizaţii manifestă adesea un anumit grad de rezistenţă la schimbare atunci
când vine vorba de implementarea unui proiect nou, sistemele ERP nu fac excepţie în acest sens. Deşi
rezistenţa la schimbare nu poate fi complet eliminată, o strategie de comunicare eficientă poate
minimiza impactul negativ al implementării soluţiei ERP. În acelaşi scop de minimizare a rezistenţei
la schimbare pot acţiona şi câteva dintre deciziile critice prezentate mai sus: selectarea unei echipe de
proiect tip “heavyweight”, care permite soluţionarea rapidă a conflictelor; încheierea parteneriatelor
cu organizaţii externe va permite angajaţilor firmei să-şi concentereze eforturile pe activităţile
strategice; utilizatorii vor accepta mai uşor noul sistem dacă ei vor realiza conversia manuală a bazei
de date. Utilizatorii vor accepta fără rezerve noua soluţie în momentul în care sistemul ERP va ajuta
organizaţia să-şi îndeplinească obiectivele.

Concluzionând, o afacere mică sau mijlocie poate creşte şansele de adoptare cu succes a unui
sistem ERP dacă [Malhotra şi Temponi, 2010]:

xxxi
 Alege pentru echipa de proiect o structură de tip „heavyweight”;

 Încheie parteneriate cu organizaţii externe, care dispun de competenţele necesare

pentru implementarea soluţiei;

 Optează pentru implementarea aplicaţiei ERP într-un mod etapizat;

 Alege strategia de conversie manuală a bazelor de date;

 Aplică un management proactiv al schimbărilor interne şi al riscului de proiect.

3.4 Motivaţia implementării

Principalele motive pentru care companiile trebuie să instaleze si să implementeze un sistem ERP
sunt enumerate mai jos:

 Integrarea informaţiilor financiare. Atunci când managerul unei companii încearcă să

descopere performanţa de ansamblu a întregii sale companii, el poate găsi mai multe versiuni
ale stării adevărate a firmei.
 Integrarea informaţiilor despre comenzile de la clienţi. Sistemul ERP este locul unde sunt
procesate comenzile de la clienţi din momentul în care acestea sunt primite de către serviciul
de relaţii cu clientii până în momentul în care produsele sunt livrate şi este emisă factura
pentru comanda respectivă. Păstrând aceste informaţii într-un singur sistem, poate fi mai uşor
de urmărit traseul unei comenzi, stadiul în care ea se află în orice moment, şi de asemenea,
pot fi coordonate mai uşor toate departamentele firmei, indiferent de locaţia unde se află.
 Standardizarea şi creşterea vitezei de producţie. Sistemele ERP oferă premizele pentru a
standardiza diferitele etape ale procesului de producţie, standardizare ce reduce costurile,
măreşte viteza şi productivitatea sectorului respectiv.
 Reduce timpul pierdut prin inventariere. Cunoscându-se în orice moment situaţia
stocurilor, pot fi făcute planuri mult mai precise de livrare a produselor la clienţi şi
coordonarea mult mai bună a distribuţiei acestora.
 Standardizează informaţiile pentru resursele umane. Un sistem ERP aduce beneficii
suplimentare deoarece introduce un sistem unificat de urmărire a activităţii angajaţilor şi de
comunicare între aceştia.

4 PREZENTAREA SISTEMULUI INITORA.ERP

4.1 Descrierea Sistemului

xxxii
 Initora.ERP a fost dezvoltat la cererea de gestiune en-gros și en-detail. Generic spus, acest produs
va da posibilitatea de a integra software întreagă organizare internă a firmei, ținând cont de
necesitățile particulare ale fiecărui client.

Sistemul de gestiune economică și management este destinat în special firmelor care în activitatea
lor trebuie să urmărească foarte exact fluxul mărfurilor, fimelor de distribuție, firmelor cu activitate de
comerț en-gros și en-detail. Produsul initOra.ERP oferă posibilitatea de a integra software întreaga
organizare internă a firmei, ținând cont de necesitățile particulare ale fiecărui client.

4.2 Deosebiri intre InitOra.ERP si alte sisteme ERP

 Formele de control ale documentelor reprezintă nucleul produsului software. Cu parametri
diferiți la definirea tipurilor de documente este posibilă ilustrarea fluxului de date non-
standard, la cererea particulară a clientului. Deci, orice document poate fi creat și configurat
de către client, dacă este necesar, de exemplu facturi de vânzare/cumpărare, avize de
expediție, facturi de corecție, note de intrare și recepție, note de transfer, procese verbale,
chitanțe fiscale etc. Prin legarea între ele a acestor tipuri de documente configurate de client,
este posibil să se definească fluxul de date al programului initOra.ERP conform necesităților
afacerii clientului.

Mai jos avem un exemplu de lanț de documente ce ar putea apărea într-o firmă și interacțiunile
dintre acestea.

xxxiii
 Figura 2 - Lanțul de documente care apar intr-o firma

 Integrarea sistemului cu casa de marcat

Figura 3 – Integrarea cu casa de marcat

 Baza de date Oracle®. Volumul mare de date pe care le poate stoca sistemul nu influențează
viteza, Oracle fiind liderul mondial in sisteme de baze de date.

 Sistemul permite o urmarire in timp real a activității companiei in regim multi-user (acces pe
baza de parole și pe mai multe nivele) și multi-valută (EUR, RON)

xxxiv
 Figura 4 - Login initOra.ERP

 Grupările și clasificările programului permit o organizare structurată specifică fiecarei

firme din care se extrag statistici, simplificând astfel administrarea sistemului

Figura 5 - Gruparea programului

 Sistemul poate administra mai multe gestiuni

 Modulul de raportare, utilizatorul având posibilitatea definirii și integrării în aplicație de

rapoarte noi precum si de a modifica rapoartele existente

xxxv
4.3 Structura generala a sistemului Initora.ERP
Aplicația are o parte de administrare a datelor sistem necesare, o parte de obiecte, o parte de
vânzare, o parte de cumpărare, o parte de stocuri, o parte de contabilitate, o parte de rapoarte, o parte
de procese și o parte de interogări. Funcționalitatea este descrisă mai jos:

xxxvi
Figura 6 - Structura sistemului initOra.ERP

xxxvii
Figura 7 - Flux documente

Figura 8 - Producție

xxxviii
 Figura 9 - Exemplu document

Figura 10 - Structura fișierului comezi.ods

DOCUMENT – reprezintă tipul de document care se va genera(Acesta poate fi FCT.1, FCT+CHIT,

AvDetail).

CLIENT,ADRESĂ – este codul de client din program. Dacă se adaugă un client în acest fișier acesta
trebuie neapărat să facă parte din clienții definiți în program.

xxxix
ZONA – reprezintă agentul pe care se va face factura/avizul. Este de fapt o zonă logică. De exemplu
pentru suplimentări se folosește o altă zonă.

COD PRODUS – reprezintă codul produsului din program. Dacă se adaugă un produs nou în acest
fișier acesta trebuie neapărat să facă parte din produsele definite în program.

CANTITATE – se completează de operator cu cantitatea comandată

CHEIE CANTITATE - reprezintă suma tuturor cantităților completată. Este de fapt o cheie de
verificare pentru operator. Când se începe o serie de comenzi acest număr trebuie să fie 0. Dacă e
diferit de 0 înseamnă că există deja comenzi în fișier.

CHEIE IMPORT – este o cheie de verificare a importului. Este de formatul AAAALLZZ.v Exp.
20140425.2 – se folosește pentru ziua 18.07.2016. Trebuie să fie completat de operator la începerea
seriilor de comenzi. Această cheie va fi importata în același timp cu documentele CHEIE IMPORT
ZONĂ DOCUMENT CLIENT, ADRESĂ COD PRODUS CHEIE CANTITATE CANTITATE
CHEIE IMPORT ZONĂ DOCUMENT CLIENT, ADRESĂ COD PRODUS CHEIE CANTITATE
CANTITATE oraecon S.R.L. business software solutions și va identifică seria de documente
importate. Se pot importa mai multe serii de comenzi în aceeași zi cu condiția să aibă această cheie
diferită. Dacă importăm o serie de comenzi cu cheia 20160718.1 o altă serie de comenzi se pot
importa cu cheia 20160718.2 .. 20160718.3 …

xl
 Figura 11 - Transformarea comenzilor în documente

Acest va importa fisierul și va genera documente (Facturi, Facturi + Chitante, Avize)

Pentru executia lui: se apasa tasta F3, se introduce data documentelor (trebuie să corespunda cu data

din cheia de import), F7, CTRL+P

După execuție se vor afișa pe ecran 3 rapoarte:

– unul cu jurnalul de documente generate ( la sfârșitul lui va afișa numărul total de

documente)

– unul cu toate documentele de tip factura (FCT.1 si FCT+CHIT)

– unul cu toate documentele de tip aviz (AvDetail)

ATENȚIE: Trebuie verificat că numărul de pagini din cele două rapoarte să fie egal cu numărul total

de documente. Este posibil să fie mai mare în caz că o factură nu încape cu ambele copii pe aceeași

pagină.
xli
 Este posibil ca la import să apară unele erori:

– NU EXISTĂ PRODUSUL (sau e blocat) : 7014 – produsul cu codul 7014 nu există definit în

program (Obiecte → Produse)

– fișierul are cheia 20160718 și e executat cu altă data – se verifică cheia introdusă e formatul

yyyymmdd.x sau e diferită de data importului.

– col14 client sau adresă incorect: ALNIS COM 0-înseamnă că nu există clientul definit în

sistem, trebuie mai întâi definit în sistem. Atenție să nu conțină mai multe spații libere. Se

verifică fișierul pe coloană 14 (Obiecte → Firme)

– col78 ZONĂ INCORECTĂ – zonă nu este definită în sistem (Obiecte → Agenți)

– col78 DOCUMENT INCORECT – tipul de document nu este definit în sistem (Configurări de

bază → Tipuri de Obiecte → Tipuri de documente)

– Importul a mai fost executat – de la ultimul import executat nu s-a mai apăsat TRIMITE

COMENZI.

– Fișierul cu cheia 20140425.2 a mai fost importat – fișierul cu cheia respectivă a mai fost

încărcat în sistem

După corectarea erorilor se reiau pașii:-salvare fișier, trimitere comenzi, import facturi și listarea

acestora.

xlii
 Figura 12 - Exemplu de document important

În fișierul comenzi.ods avem: DOCUMENT: FCT+CHIT, CLIENT,ADRESĂ: FLOREA I#0

(prima

adresă de la clientul FLOREA I), ZONĂ: Z01, cheie import: 20140529.1, data 29.05.2014 este data

introdusă la procesul de import și validată prin cheie.

Celelate câmpuri sunt generate de sistem:

-seria și numărul facturii: F 334275 – se definesc în (Sistem ->Tipuri de obiecte → Tipuri

documente), pentru fiecare document în parte. Tot acolo se definește și seria de chitanțe.Ultimele 3
câmpuri din dreaptă conțin: Chitanță – număr generat de sistem pe aceleași reguli cu

numărul de factură, Cheie import – apare numai la importul de documente, ID Procesare – cod unic

generat de import – identifică o serie de comenzi. Dacă se dorește ștergerea unei serii de documente

importate acest număr e folosit de procesul “Sterge facturi procesate”.

5 PREZENTAREA SISTEMULUI INITORA.SFA

5.1 Definiţia unui SFA

xliii
 Abrevierea SFA provine de la Sales Force Automation și este o aplicație software, integrată în
cadrul unui sistem de tip ERP, care are rolul de a aduce eficientă în cadrul activităților de vânzări, deci
de a automatiza întreg procesul de vânzări în special în cadrul companiilor de distribuție. O asemenea
aplicație este un instrument puternic utilizat de echipele de vânzări: agenți de teren, reprezentanți
zonali și mercantizori.

Primele soluții SFA utilizau dispozitive mobile cunoscute că și PDA-uri, însă soluțiile SFÂ
moderne se instalează pe smartphone-uri și sunt compatibile cu platformele mobile Android sau IOS.
Prin intermediul lor se preiau și sunt urmărite comenzi până la livrarea lor, dar există și funcționalități
legate de încasarea comenzilor, facturare, șolduri și stocuri. Datele se întroduc ușor în interfață de
mobil, însă marea majoritate a operațiilor pe care agenții de vânzări le fac cu o aplicație SFÂ este
aceea de a regăsi informații legate de clienți, mărfuri, șolduri etc-preluate din sistemul ERP al
companiei. Un SFÂ elimină lipsă accesului la informații și problemele de cash-flow care ar putea să
apăra datorită facturării întârziate a produselor livrate.

5.2 Beneficiile unui SFA

 Centralizarea informațiilor privind stocurile, clienții, produsele și prețurile și accesul la ele.

 Preluarea comenzilor de la clienți în timp real și regăsirea lor automată în sistemul ERP al
companiei. Dacă anterior utilizării unui SFA, fiecare agent avea metodele proprii de a-și notă
datele despre clienți, produsele comandate și alte informații legate de promoții, un SFA oferă
o formă unitară de preluare a comenzilor, bazată pe informații certe din sistemul ERP. Un
agent de vânzări regăsește în sistem date despre clienți, șoldul și produsele comandate
anterior. În funcție de ele, agentul poate să anticipeze cerințele clientului. De asemenea, el
cunoaște stocul din fiecare produs comandat și poate face rezervări de stoc în momentul în
care lansează o comandă în numele clientului. Pentru produsele care nu au stoc, se pot
prezența alternative.

 Reducerea timpului de vizită petrecut la client prin simplul fapt că inițializarea unei comenzi
noi aduce un set de date predefinite pentru clientul respectiv, iar regăsirea prețurilor
negociate, a cantităților sau a produselor se face printr-un click. Completarea pas cu pas a
comenzii este echivalentă cu preluarea și regăsirea ei automată în sistem în același timp. Nu
este nevoie de operare suplimentară.

 Reducerea timpului de vizită petrecut la client prin simplul fapt că inițializarea unei comenzi
noi aduce un set de date predefinite pentru clientul respectiv, iar regăsirea prețurilor
negociate, a cantităților sau a produselor se face printr-un click. Completarea pas cu pas a

xliv
 comenzii este echivalentă cu preluarea și regăsirea ei automată în sistem în același timp. Nu
este nevoie de operare suplimentară.

 Creșterea gradului de încasare prin posibilitatea de emitere la față locului a bonului sau a
facturii și a documentelor de încasare.

 Optimizarea stocurilor pe baza istoricului comenzilor.

 Controlul activității agenților de vânzări și menținerea motivației prin implementarea unui

sistem transparent de bonusuri.

 Creșterea notorietății firmei prin onorarea comenzilor în parametrii stabiliți cu clientul.

5.3 Arhitectura soluției initOra.SFA

Soluția Sales Force Automation (automatizarea forței de vânzare) initOra.SFA este o
implementare a unei soluții de automatizare a forței de vânzare, rulând pe sistemul de operare pentru
dispozitive mobile Android, optimizată pentru sincronizarea cu sistemul de gestiune economică și
management initOra.ERP.

 Dispozitiv mobil care rulează pe sistemul de operare ANDROID cu aplicația initOra.SFA

 Interfețele de sincronizare a datelor

 Serverul sistemului de gestiune initOra.ERP

Figura 13 - Comunicația aplicației android cu serverul

5.4 Avantajele sistemului initOra.SFA

xlv
  Posibilitatea de a culege date la punctul de activitate al clientului

 Monitorizarea continuă a agenților de vânzări, rutele folosite, timpul petrecut la clienți, timpul
consumat pe drum

 Oferă agentului o imagine exactă asupra stocului de marfă, soldurilor la clienți, facturile din
care este compus un sold, componența facturilor anterioare

 Reducerea timpului de culegere și prelucrare a comenzilor

 Permite agentului întocmirea zilnică de rapoarte de activitate

 Posibilitatea de a acorda discounturi procentuale și valorice pe poziții comenzii și pe întreaga

comandă

 Informații despre transport și termene de plată

 Gruparea clienților, a produselor

 Stabilirea pentru un produs pana la 3 tipuri de prețuri în funcție de tipul clientului

 Posibilitate de a crea propriile formulare de culegere a datelor despre client sau despre
concurență

5.5 Caracteristici funcționale

 CLIENȚI-informații despre clienți (adresă, tip, sold total, sold pe agent, facturi restanțe)

 COMENZI-introducere comenzi : client, data, produse, cantități, disounturi, informații

transport

 STATISTICI-valoare comenzi pe zi, total volum comandat, total greutate comandată

 RAPORTĂRI – liste clienți/produse/prețuri/baxare etc.

6 CONCLUZII

Sistemele de planificare a resurselor întreprinderii de tip ERP sunt o industrie care până în acest
moment a aratat numai aspecte de viitor, iar acest lucru nu pare să se oprească aici. O companie nu
trebuie să se îngrijoreze referitor la outsourcing sau avansul tehnologic deoarece, în oricare din aceste

xlvi
cazuri un sistem ERP poate fi uşor adaptat şi implementat numai în acele activităţi ale firmei unde
este nevoie de el.

Fără îndoială că acesta este un proces complex şi implementarea unui ERP cere multă
meticulozitate, grijă şi profesionalism, însă odată implementat, sistemul ERP poate fi folosit pe toată
durata de viaţă a companiei, cu eventuale îmbunătăţiri generate de progresul tehnologic al sistemelor
ERP.

În concluzie, un sistem ERP integrează într-o singură bază de date informaţiile şi modul de lucru
specific tuturor departamentelor şi funcţiilor dintr-o companie, asigurând astfel un mediu de lucru
propice pentru atingerea obiectivelor strategice.

xlvii
7 BIBLIOGRAFIE

1. Morariu N., Proiectarea sistemelor informatice. Suceava, 2005;

2. Cozgarea G., Zaharie D., Utilizarea proiectării orientate obiect în informatica de
gestiune, A.S.E. 2004;
3. Chindea M. E , Proiectarea sistemelor informatice economice. Bucureşti, 1999;
4. Oprea D., Analiza şi proiectarea sistemelor informaţionale economice, Ed. Polirom,
Iaşi,1999;
5. Stanciu V., Proiectarea sistemelor informatice de gestiune, Ed. Cison, Bucureşti
2000;
6. Zaharie D., Rosca I., Proiectarea obiectuală a sistemelor informatice, Ed. Dual
Tech,Bucuresti, 2002;
7. Rashid, M.A., Hossain, L., Patrick, J.D. [2002], The evolution of ERP systems: A
historical perspective, Idea Group Publishing;
8. Lungu I., Sabau Gh., Proiectarea sistemelor informatice economice. Bucuresti, 2000;
9. Sabău Gh., ş.a., Sisteme informatice. Analiză, proiectare şi implementare. Ed.
Economica, Bucuresti, 2003;
10. Ion Gh. Rosca, Bogdan Ghilic-Micu, Marian Stoica - "Informatica. Societatea
Informationala –E-Serviciile ",Editura Economica 2006;
11. Vasilescu P., Dunca V. – Proiectarea sistemelor informatice, Ed. Tehnică, Bucureşti,
1979;
12. Oz, E. [2009], Management Information Systems, Ediţia a 6-a, Thomson Course
Technology, SUA;
13. Morabito, V., Pace, S., Previtali, P. [2005], ERP Marketing and Italian SMEs,
European Management Journal, 23 (5), pp. 590-598;
14. Balan D., Balan G. – Sistemul informaţional în gestionarea întreprinderilor, Ed.
Junimea, Iaşi, 1998;
15. Basoglu, N., Daim, T., Kerimoglu, O. [2007], Organizational adoption of enterprise
resource planning systems: A conceptual framework , Journal of High Technology
Management Research, 18, pp. 73-97;
16. Malhotra, R., Temponi, C. [2010], Critical decisions for ERP integration: Small
business issues, International Journal of Information Management, 30, pp. 28 -37;
17. Amza C.P. , Proiectarea sistemelor informatice financiar-bancare si de gestiune.
Editura Cartea Studentească. Bucureşti. 2008;
18. Ngai, E.W.T., Law, C.C.H., Wat, F.K.T. [2008], Examining the critical success factors
in the adoption of enterprise resource planning, Computers in Industry, pp. 548-564;

xlviii
8 CODUL SURSĂ

Codul sursa al Log in-ului:

package ro.oraecon.initorasfa;

import android.os.Bundle;
import android.app.Activity;
import android.app.AlertDialog;
import android.util.Log;
import android.view.Menu;
import android.widget.Button;
import android.widget.EditText;
import android.widget.Toast;
import android.view.View;
import android.widget.ListView;
import java.lang.Object;

import android.content.DialogInterface;
import android.content.Intent;
import android.database.Cursor;
import android.database.sqlite.SQLiteException;
import android.net.Uri;
import android.view.View.OnClickListener;
import android.content.Intent;

public class initOraSFA extends Activity {

Button m_button_login;
Button m_button_cancel;
OraSqlLiteClass oraDB = new OraSqlLiteClass(this);
EditText m_edit_user=null;
EditText m_edit_password=null;
int CheckPassword()
{
String m_user="",m_password="";
try
{
// Log.d("test"," cast user");
m_edit_user = (EditText) findViewById(R.id.EDIT_USER_LOGIN);
//Log.d("test"," cast pass");
m_edit_password = (EditText) findViewById(R.id.EDIT_PASSWORD_LOGIN);
m_user= m_edit_user.getText().toString();
m_password=m_edit_password.getText().toString();
m_user=m_user.toUpperCase();
}
catch (Exception e)
{
Toast.makeText(this, e.toString(), Toast.LENGTH_SHORT).show();
}
String sql=null;
//load settiong if no use is defined
sql = "select count(user_id) AS C from users";
xlix
 String a_count=null;
try
{
Cursor c11 = oraDB.rawQuery(sql);
if (c11 != null )
{
int c=0;
if (c11.moveToFirst())
{
do {
a_count= c11.getString(c11.getColumnIndex("C"));
}while (c11.moveToNext());
}
}
}
catch(SQLiteException e)
{
Log.d("test", "error on count users");
a_count="0";
}
if (Integer.valueOf(a_count)==0)
{
oraDB.loadData();
}

sql=null;
sql= "select user_id,password from users where upper(user_id) = '"+m_user+"'"+"and
password = '"+m_password+"'";
int find = -1;
Cursor c1 = oraDB.rawQuery(sql);
if (c1 != null )
{
int c=0;
if (c1.moveToFirst())
{
do {
find=1;
String a =
c1.getString(c1.getColumnIndex("USER_ID"));
String b =
c1.getString(c1.getColumnIndex("PASSWORD"));
//Toast.makeText(this, "CUST_SEARCH "+a ,
Toast.LENGTH_SHORT).show();
c=c+1;
}while (c1.moveToNext());
}
}

/* if (find <=0)
{
Log.d("test",sql);

}
else
l
*/ {
Intent intent = new Intent(this,initOraFormChose.class);
startActivity(intent);
}
return find;
}

@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_apps_login);
this.setTitle("Login");
addListenerOnButtonLogin();
addListenerOnButtonCancel();
}
@Override
public void onBackPressed() {
AlertDialog.Builder builder = new AlertDialog.Builder(this);
builder.setMessage("Inchideti Aplicatia ?")
.setCancelable(true)
.setPositiveButton("Yes", new DialogInterface.OnClickListener() {
public void onClick(DialogInterface dialog, int id) {
oraDB.Close();
finish();
}
})
.setNegativeButton("No", new DialogInterface.OnClickListener() {
public void onClick(DialogInterface dialog, int id) {
// some code if you want
return ;
}
});
AlertDialog alert = builder.create();
alert.show();
return;
}

public void addListenerOnButtonLogin() {

m_button_login = (Button) findViewById(R.id.BUTTON_OK);

m_button_login.setOnClickListener(new View.OnClickListener() {
public void onClick(View arg0)
{
if (CheckPassword() ==1)
{
Toast.makeText(initOraSFA.this,
"user login succes!", Toast.LENGTH_SHORT).show();
//Intent intent = new Intent(this,initOraFormChose.class);
//Intent intent = new Intent(this, OraCustomerSearch.class);
//Intent intent = new Intent(this, OraGridview.class);
// Toast.makeText(this, "new activity" , Toast.LENGTH_SHORT).show();
// startActivity(intent);
}
else
li
 {
Toast.makeText(initOraSFA.this,
"utilizator/parola inexistente", Toast.LENGTH_SHORT).show();
}
}

});

public void addListenerOnButtonCancel() {

m_button_cancel = (Button) findViewById(R.id.BUTTON_CANCEL);
m_button_cancel.setOnClickListener
(
new View.OnClickListener()
{
public void onClick(View arg0)
{
oraDB.Close();
initOraSFA.this.finish();
}

}
);

}
Codul sursa al setarilor:
package ro.oraecon.initorasfa;

import android.os.Bundle;
import android.widget.RadioButton;
import android.app.Activity;
import android.app.TabActivity;
import android.util.Log;
import android.view.Menu;
import android.view.MenuItem;
import android.widget.AdapterView;
import android.widget.Button;
import android.widget.EditText;
import android.widget.SimpleCursorAdapter;
import android.widget.TabHost;
import android.widget.TextView;
import android.widget.Toast;
import android.view.View;
import android.widget.ListView;

import java.lang.Object;

import android.content.Intent;
import android.database.Cursor;
import android.database.sqlite.SQLiteException;
import android.graphics.Color;
lii
import android.view.View.OnClickListener;

import java.util.ArrayList;

import android.app.AlertDialog.Builder;
import android.app.AlertDialog;
import android.app.Dialog;
import android.content.DialogInterface;
import android.content.res.Configuration;

import ro.oraecon.initorasfa.OraSqlLiteClass;
import ro.oraecon.initorasfa.R;

import android.widget.*;
//import org.apache.commons.net.ftp.FTPClient;

public class initOraParameters extends Activity {

int statusMode=0;
OraSqlLiteClass oraDB = new OraSqlLiteClass(this);
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.initora_settings);
this.setTitle("Parametrii Comunicatie");
fillForm();
SetEnabled(false);
// addListenerOnButtonnSaveParameters();

}
@Override
public boolean onCreateOptionsMenu(Menu menu) {
getMenuInflater().inflate(R.menu.order_menu, menu);
return true;
}
@Override
public boolean onPrepareOptionsMenu (Menu menu) {

switch (statusMode){
case 0: case 3: //SELECT
menu.getItem(0).setEnabled(false);
menu.getItem(1).setEnabled(true);
menu.getItem(2).setEnabled(false);
menu.getItem(3).setEnabled(false);
menu.getItem(4).setEnabled(false);
menu.getItem(5).setEnabled(false);
break;
case 1: case 2: //INSERT,update
menu.getItem(0).setEnabled(false);
menu.getItem(1).setEnabled(false);
menu.getItem(2).setEnabled(true);
liii
 menu.getItem(3).setEnabled(false);
menu.getItem(4).setEnabled(false);
menu.getItem(5).setEnabled(false);
break;
}

return true;
}
@Override
public void onConfigurationChanged(Configuration newConfig) {
super.onConfigurationChanged(newConfig);
setContentView(R.layout.initora_settings);
boolean currMode=false;
SetEnabled(currMode);

}
@Override
public boolean onOptionsItemSelected(MenuItem item) {
switch (item.getItemId()){
case R.id.MENU_ORD_NEW:

break;

case R.id.MENU_ORD_SAVE:
SaveHeader();
SetEnabled(false);
break;
case R.id.MENU_ORD_SEARCH:

break;
case R.id.MENU_ORD_UPDATE:
statusMode=2;
SetEnabled(true);
break;
case R.id.MENU_ORD_DELETE:

break;
case R.id.MENU_ORD_SEND:

break;
}
super.invalidateOptionsMenu() ;
return true;
}
public void addListenerOnButtonnSaveParameters(){

Button m_button_new_order = (Button)

findViewById(R.id.SETTINGS_BUTTON_SAVE);
m_button_new_order.setOnClickListener(new View.OnClickListener() {
boolean currMode=false;
public void onClick(View arg0)
{
SaveHeader();
SetEnabled(currMode);
liv
 Toast.makeText(getBaseContext(),
"Comanda a fost salvata",
Toast.LENGTH_SHORT).show();
}

});

public void SaveHeader()

{
EditText m_edit_server1 = (EditText)
findViewById(R.id.SETTINGS_EDIT_SERVER1);
EditText m_edit_server2 = (EditText)
findViewById(R.id.SETTINGS_EDIT_SERVER2);
EditText m_edit_user = (EditText) findViewById(R.id.SETTINGS_EDIT_USER);
EditText m_edit_password = (EditText)
findViewById(R.id.SETTINGS_EDIT_PASSWORD);
EditText m_edit_download_path = (EditText)
findViewById(R.id.SETTINGS_EDIT_DOWNLOAD_DIR);
EditText m_edit_upload_path = (EditText)
findViewById(R.id.SETTINGS_EDIT_UPLOAD_DIR);
EditText m_edit_pocket_id = (EditText)
findViewById(R.id.SETTINGS_EDIT_POCKET_ID);
EditText m_edit_reports_url = (EditText)
findViewById(R.id.SETTINGS_EDIT_REPORTS_URL);
RadioButton radioDistrib = (RadioButton) findViewById(R.id.radioDistrib);
RadioButton radioRest = (RadioButton) findViewById(R.id.radioRest);
String server1 = (String)m_edit_server1.getText().toString();
String server2 = (String)m_edit_server2.getText().toString();
String user = (String)m_edit_user.getText().toString();
String password = (String)m_edit_password.getText().toString();
String download_path = (String)m_edit_download_path.getText().toString();
String upload_path = (String)m_edit_upload_path.getText().toString();
String pocket_id = (String)m_edit_pocket_id.getText().toString();
String reports_url = (String)m_edit_reports_url.getText().toString();
String i_type=null ;
if (radioDistrib.isChecked()){
i_type ="DISTRIB";

}
else if (radioRest.isChecked()){
i_type ="REST";

String sqlOrd="";
try {

sqlOrd = "update PARAMETRI"

+ " SET SERVER1 = " +"'"+server1.toString()+"'"
+ ", SERVER2 = " +"'"+server2.toString()+"'"
+ ", USER = " +"'"+user.toString()+"'"
+ ", PASSWORD = " +"'"+password.toString()+"'"
lv
 + ", REMOTE_PATH_DOWNLOAD = " +"'"+download_path.toString()
+"'"
+ ", REMOTE_PATH_UPLOAD = " +"'"+upload_path.toString()+"'"
+ ", POCKET_ID = " +"'"+pocket_id.toString()+"'"
+ ", REPORTS_URL = " +"'"+reports_url.toString()+"'"
+ ", INTERFACE = " +"'"+i_type.toString()+"'"
;
sqlOrd = sqlOrd.replace("''", "NULL");
oraDB.execSQL(sqlOrd);
//oraDB.CommitTrans();

}
catch(SQLiteException e)
{
Toast.makeText(getBaseContext(),
"eroare la modificare parametrii " +e.toString(),
Toast.LENGTH_SHORT).show();
Log.d("test",sqlOrd);
}
finally
{
//oraDB.Rollback();
}
}
public void fillForm()
{

//Toast.makeText(getBaseContext(),
// "load Parameters data ", Toast.LENGTH_SHORT).show();
EditText m_edit_server1 = (EditText)
findViewById(R.id.SETTINGS_EDIT_SERVER1);
EditText m_edit_server2 = (EditText)
findViewById(R.id.SETTINGS_EDIT_SERVER2);
EditText m_edit_user = (EditText) findViewById(R.id.SETTINGS_EDIT_USER);
EditText m_edit_password = (EditText)
findViewById(R.id.SETTINGS_EDIT_PASSWORD);
EditText m_edit_download_path = (EditText)
findViewById(R.id.SETTINGS_EDIT_DOWNLOAD_DIR);
EditText m_edit_upload_path = (EditText)
findViewById(R.id.SETTINGS_EDIT_UPLOAD_DIR);
EditText m_edit_pocket_id = (EditText)
findViewById(R.id.SETTINGS_EDIT_POCKET_ID);
EditText m_edit_reports_url = (EditText)
findViewById(R.id.SETTINGS_EDIT_REPORTS_URL);
RadioButton radioDistrib = (RadioButton) findViewById(R.id.radioDistrib);
RadioButton radioRest = (RadioButton) findViewById(R.id.radioRest);
// check if order is allready inserted
String sql = "SELECT
SERVER1,SERVER2,USER,PASSWORD,REMOTE_PATH_DOWNLOAD,REMOTE_PATH_UPL
OAD,POCKET_ID,REPORTS_URL,INTERFACE from PARAMETRI";
int rows=0;
try {
Cursor c11 = oraDB.rawQuery(sql);
lvi
 if (c11 != null )
{
if (c11.moveToFirst())
{
do {
rows++;
String a =
c11.getString(c11.getColumnIndex("SERVER1"));
m_edit_server1.setText(a);
a=
c11.getString(c11.getColumnIndex("SERVER2"));
m_edit_server2.setText(a);
a=
c11.getString(c11.getColumnIndex("USER"));
m_edit_user.setText(a);
a=
c11.getString(c11.getColumnIndex("PASSWORD"));
m_edit_password.setText(a);
a=
c11.getString(c11.getColumnIndex("REMOTE_PATH_UPLOAD"));
m_edit_upload_path.setText(a);
a=
c11.getString(c11.getColumnIndex("REMOTE_PATH_DOWNLOAD"));
m_edit_download_path.setText(a);
a=
c11.getString(c11.getColumnIndex("POCKET_ID"));
m_edit_pocket_id.setText(a);
a=
c11.getString(c11.getColumnIndex("REPORTS_URL"));
m_edit_reports_url.setText(a);
a=
c11.getString(c11.getColumnIndex("INTERFACE"));

if (a.equalsIgnoreCase("DISTRIB")){
radioDistrib.setChecked(true);
}
else if (a.equalsIgnoreCase("REST")){

radioRest.setChecked(true);

}while (c11.moveToNext());
}
c11.close();
}
}
catch(SQLiteException e)
{
rows=0;
}
lvii
 }
public void SetEnabled(boolean mode)
{
EditText m_form;
m_form =(EditText)findViewById(R.id.SETTINGS_EDIT_SERVER1);
m_form.setEnabled(mode);
m_form =(EditText)findViewById(R.id.SETTINGS_EDIT_SERVER2);
m_form.setEnabled(mode);
m_form =(EditText)findViewById(R.id.SETTINGS_EDIT_USER);
m_form.setEnabled(mode);
m_form
=(EditText)findViewById(R.id.SETTINGS_EDIT_PASSWORD);m_form.setEnabled(mode);
m_form =(EditText)findViewById(R.id.SETTINGS_EDIT_DOWNLOAD_DIR);
m_form.setEnabled(mode);
m_form =(EditText)findViewById(R.id.SETTINGS_EDIT_UPLOAD_DIR);
m_form.setEnabled(mode);
m_form =(EditText)findViewById(R.id.SETTINGS_EDIT_POCKET_ID);
m_form.setEnabled(mode);
m_form =(EditText)findViewById(R.id.SETTINGS_EDIT_REPORTS_URL);
m_form.setEnabled(mode);
Button m_button_new_order
=(Button)findViewById(R.id.SETTINGS_BUTTON_SAVE);
m_button_new_order.setEnabled(mode);
RadioButton radioDistrib =
(RadioButton)findViewById(R.id.radioDistrib);radioDistrib.setEnabled(mode);
RadioButton radioRest =
(RadioButton)findViewById(R.id.radioRest);radioRest.setEnabled(mode);

// boolean statusMode=mode;
}

B. CD / DVD

lviii
lix