Proiectarea Unui Sistem Informatic Pentru Evidenta Importurilor Si Exporturilor la Sc
CUPRINS
INTRODUCERE …………………………………………….p2
CAPITOLUL I – STUDIUL ȘI ANALIZA SISTEMULUI INFORMATIC EXISTENT…………………………………………………………………………………p3
Prezentarea succintă a unității economico – sociale…………….p3
Activitățile desfășurate în unitatea economică……………….…..p4
1.3 Studiul sistemului de conducere ……………..…………………. .p17
1.4 Studiul sistemului condus ………………………………………….p20
1.5 Studiul sistemului informațional ……………………….…………..p20
CAPITOLUL II – PROIECTAREA DE ANSAMBLU A SISTEMULUI INFORMATIC ………………………………………………………………p26
CAPITOLUL III – PROIECTAREA DE DETALIU A NOULUI SISTEM INFORMATIC ………………………………………………………………p32
3.1 Definirea sistemului informatic ……………………….………….. p32
3.2. Principalele modalități de apelare ……………………………….. p37
3.3 Explorarea aplicației ………………………………………….…… p39
3.4 Proiectarea sistemului ………………………….………………… p39
CAPITOLUL IV – PREZENTAREA MEDIULUI DE GESTIUNE A DATELOR MICROSOFT ACCESS SQL …………………………………p48
CAPITOLUL V – GESTIUNEA BAZEI DE DATE A SISTEMULUI INFORMATIONAL PROPUS………………………………………………p40
5.1 Studiu de caz ……………………………………………..………..…..p49
Bibliografie ……………………………………………………….……p63
ANEXE ………………………………………………………………………p64
+ aplicatia
=== ProiectFinal ===
CUPRINS
INTRODUCERE …………………………………………….p2
CAPITOLUL I – STUDIUL ȘI ANALIZA SISTEMULUI INFORMATIC EXISTENT…………………………………………………………………………………p3
Prezentarea succintă a unității economico – sociale…………….p3
Activitățile desfășurate în unitatea economică……………….…..p4
1.3 Studiul sistemului de conducere ……………..…………………. .p17
1.4 Studiul sistemului condus ………………………………………….p20
1.5 Studiul sistemului informațional ……………………….…………..p20
CAPITOLUL II – PROIECTAREA DE ANSAMBLU A SISTEMULUI INFORMATIC ………………………………………………………………p26
CAPITOLUL III – PROIECTAREA DE DETALIU A NOULUI SISTEM INFORMATIC ………………………………………………………………p32
3.1 Definirea sistemului informatic ……………………….………….. p32
3.2. Principalele modalități de apelare ……………………………….. p37
3.3 Explorarea aplicației ………………………………………….…… p39
3.4 Proiectarea sistemului ………………………….………………… p39
CAPITOLUL IV – PREZENTAREA MEDIULUI DE GESTIUNE A DATELOR MICROSOFT ACCESS SQL …………………………………p48
CAPITOLUL V – GESTIUNEA BAZEI DE DATE A SISTEMULUI INFORMATIONAL PROPUS………………………………………………p40
5.1 Studiu de caz ……………………………………………..………..…..p49
Bibliografie ……………………………………………………….……p63
ANEXE ………………………………………………………………………p64
INTRODUCERE
Prezenta lucrare de licență a fost creată în anul 2009 si se referă la “Proiectarea unui sistem informatic pentru evidența importurilor – exporturilor într-o firma de comerț exterior”. Am ales această temă în urma efectuării stagiului de practică la firma S.C. ISA S.R.L., firmă care se ocupă cu importul – exportul mărfurilor.
Firma ISA dispune de un soft pentru evidențierea salariilor neavând un soft dedicat activității desfășurate și în urma observării si discuției cu persoanele angajate în cadrul acestei firme și în principal cu persoanele din conducere am hotărât că dezvoltarea unei aplicații ar fi foarte utile. În primul rând, oportunitatea sistemului informatic, este aceea de reducere a timpului de lucruș facturarea si evidențierea facturilor primite urmând a se face cu noul sistem informatic. În cadrul acestei firme facturarea este un punct foarte sensibil, firma rulând in jur de 200 de facturi pe zi si informatizarea facturarii va reduce timpul de facturare cu cel puțin 80 %. Evidențierea depozitului de marfă se va face tot cu ajutorul noului sistem informatic. Gestiunea depozitului firmei este un punct foarte important in cadrul oricărei firme deoarece comenzile care se fac trebuiesc calculate foarte atent. În momentul de față, firma întâmpină greutăți foarte mari atunci când vine vorba de lansarea unei comenzi; gestionarul fiind nevoit sa numere produsele pe care dorește sa le comande.
Informatizarea gestiunii va permite regăsirea produselor într– un timp foarte scurt; inventarierea se va face foarte ușor prin imprimarea balantei materialelor și verificarea acestora in depozit.
Sistemul informatic este oportun și din punct de vedere al spațiului, într– ucât multele stive de dosare vor fi inlocuite cu DVD– uri si regăsirea datelor dintr– o anumita perioada va fi foarte ușor regăsită cu ajutorul filtrelor de regăsire rapidă oferite de noul sistem informatic.
Sistemul informatic este foarte util si pentru managementul firmei intr– ucât controlarea facturilor emise si primite pot fi foarte ușor vizualizate. La un moment dat, managementul firmei va dori sa reducă cheltuielile și vor trebui sa verifice marfa din depozit și angajații care se ocupă cu achiziția. Dacă aceștia constituie stocuri mult prea mari în comparație cu necesitatea firmei, conducerea poate interveni și rezolva această problemă. Cu noul sistem informatic, managementul firmei va ști in orice moment ce facturi s– au emis, dacă acestea sunt încasate; vor putea regăsi și hotarî ce facturi vor fi plătite, crearea unui top al furnizorilor și al clienților, fidelizarea anumitor clienți.
Cu ajutorul aplicației conducerea firmei poate verifica și calitățile personalul propriu, prin verificarea operațiunilor făcute de aceștia în cadrul sistemului informatic.
CAPITOLUL I – STUDIUL ȘI ANALIZA SISTEMULUI INFORMATIC EXISTENT
Prezentarea succintă a unității economico – sociale.
Date de identificare a firmei
Denumirea firmei: S.C ISA S.R.L.
Sediul firmei: Str. Gheorghe Manea nr. 15, Sector 3 Bucuresti
Numarul si data de inregistrare in Registrul Comertului: J40/13000/1994
Cod Fiscal: RO5969420
Forma juridica de constituire: Societate cu raspundere limitata
Tipul activitatii: Import – Export echipamente periferice it si consumabile pt. Imprimante,faxuri.
– Comercializare echipamente periferice: imprimante, copiatoare, fax-uri, multifunctionale, scannere, etc
– Comercializare consumabile pentru imprimante, copiatoare, fax-uri, multifunctionale, etc
– Comercializare kit-uri de mentenanta pentru imprimante, copiatoare, fax-uri, multifunctionale, etc
– Comercializare medii de stocare standard si profesionale
– Comercializare accesorii & materiale intretinere
– Servicii de mentenanta si depanare copiatoare, imprimante, multifunctionale, faxuri, PC-uri, monitoare, ups
– Servicii de editare cataloage multimedia, carti de vizita multimedia
– Editarea de cursuri multimedia
Natura capitalului social: Privat
ISA este o companie cu capital privat, integral românesc, al cărei principal obiect de activitate constă în importul – exportul echipamente periferice it si consumabile pt. Imprimante,faxuri.
Inființată în 1994, compania ISA dispune de o echipa de 50 specialiști cu o foarte bună pregatire, cu cunoștințe solide de marketing și management. Cifra de afaceri a firmei este 587.303.600 lei.
Indicatori firma:
Fondul de rulment (FR);
Necesarul de fond de rulment(NFR);
Trezoreria neta(TN).
FR = 488.147.600 lei
NFR= 202.259.700 lei
TN = 285.887.900 lei
sau TN = FR – NFR = 488.147.600 – 202.259.700 = 285.887.900 lei
Produsele furnizate de noi se pliază atât pe necesitățile și cerințele companiilor de mari dimensiuni cât și pe ale celor de dimensiuni mai reduse.
Pentru a ne menține produsele la un standard cât mai ridicat a fost necesară elaborarea unor obiective bine definite, precum:
»Utilizarea de personal calificat corespunzător
» Identificarea necesităților explicite si implicite ale utilizatorilor
» Identificarea timpurie a eventualelor probleme, remedierea acestora in cel mai scurt timp. Principiile ce fundamentează scopurile ISA se refera la:
» Orientarea spre client
» Oferirea permanenta de noi facilități și servicii
Considerăm că într-un mediu de piată concurențial, aflat într-o continuă transformare, rapiditatea luării deciziilor joacă un rol hotărâtor pentru succesul oricărei afaceri. ISA creează mediul decizional eficient!
Activitățile desfășurate în unitatea economică.
Sistemul informațional contabil din România
Cadrul legislativ
Nevoia de armonizare, convergență și uniformitate în contabilitate impune normalizarea sa. Pe această cale se formalizează și materializează obiectivele, conceptele, metodele, regulile și procedurile privind producția și utilizarea informației contabile.
Acceptarea normelor de către părțile afectate poate fi forțată sau voluntară, sau ambele în același timp. În mod corespunzător se disting două forme ale normalizării: normalizarea legală sau reglementată, se impune tuturor în virtutea textelor legale (legi) și textelor reglementate (ordonanțe, hotarâri de guvern, ordine ministeriale și intraministeriale) și normalizarea profesională care se impune decât profesiunilor corespunzătoare, iar prin profesiune în producția de informații contabile și validarea socială a acestora.
În România, dispozitivul de normalizare a contabilității agenților economici se compune din:
Legea contabilității 82/1991 cu modificările aduse de OG 70/2004 și Legea 420/2004, aplicabile de la data de 01.01.2005 – publicată în M.O. nr. 993 din 28.10.2004;
Reglementări contabile pentru agenții economici și instituțiile publice;
Norme metodologice și precizări contabile cu statut de reglementări;
Instrumentări metodologice cu statut de ghiduri profesionale;
Cadrul general pentru întocmirea și prezentarea situațiilor financiare elaborate de Comitetul pentru Standarde de Contabilitate Internaționale (IASB);
Rețeaua de standarde sau norme contabile definită de:
Standardele Internaționale de Raportare Financiară (IFRS), denumite până în anul 2003, Standardele Internaționale de Contabilitate (IAS);
Directivele contabile europene;
Standardele Naționale de Contabilitate ca dezvoltări efectuate în conformitate cu Directivele contabile ale C.E.E. Cadrul general IASB și în convergență cu IFRS-urile;
Standarde Naționale de Contabilitate suplimentare pentru ariile ce nu sunt acoperite de IFRS/IAS-uri.
Planul de conturi general;
Recomandări și ghiduri practice;
Legea auditului financiar;
O.M.F.P. nr. 94/2001 pentru aprobarea Reglementărilor contabile armonizate cu Directiva a IV-a a Comunității Economice Europene și cu Standardele de Contabilitate Internaționale. Monitorul Oficial nr. 85 / 20.02.2001;
O.M.F.P. nr. 306 / 2002 privind reglementările contabile simplificate, armonizate cu Directivele C.E.E. și I.A.S.
Legea nr. 571/2003 privind Codul fiscal, publicată în MO nr. 927/2003;
OG nr. 83/2004 pentru modificarea și completarea Legii nr. 571/2003 privind Codul fiscal, publicată în MO nr. 793/2004;
HG nr. 44/2004 privind Normele metodologice de aplicare a Codului Fiscal, publicate în MO nr. 112/2004;
Ordinul ministrului Finanțelor Publice nr. 1845/2003 privind norme de aplicare a unor prevederi din Titlul VI, Taxa pe valoarea adăugată din Codul fiscal;
Normalizare și politici contabile
Definirea normalizării în contabilitate
Nevoia de armonizare și uniformitate în contabilitate impune normalizarea sa. Pe această cale se formalizează și materializează obiectivele, conceptele, metodele, regulile și procedurile privind producția și utilizarea informației contabile.
Efortul de normalizare dar și produsul acesteia se concretizează în:
a) definirea de concepte, principii și norme contabile bazate pe o terminologie precisă și identică pentru toți producătorii și utilizatorii de informații contabile;
b) aplicarea lor practică în vederea asigurării comparabilității în timp și spațiu, relevanței și credibilității a informațiilor contabile.
Așa cum se degajă de mai sus nucleul normalizării îl reprezintă elaborarea de norme contabile. Norma contabilă reprezintă o regulă sau mai multe reguli constituite ca sistem de referință pentru producția de informații contabile și validarea socială a situațiilor financiare.
Obiectivul situațiilor financiare
Obiectivul situațiilor financiare este de a furniza informația despre poziția financiară a întreprinderii, rezultatele și modificările poziției financiare ale întreprinderii. Toate aceste informații satisfac necesitățile comune ale majorității utilizatorilor, ele lasă în afară o serie de necesități informaționale nefinanciare și predictive.
Informațiile privind poziția financiară sunt oferite, în primul rând, de bilanț, cele privind rezultatul, prin contul de profit și pierdere, iar informațiile privind modificările poziției financiare prin intermediul unor situații distincte.
Poziția financiară a întreprinderii este definită de resursele economice pe care le controlează, de structura financiară a activelor, datoriilor și capitalului propriu, de lichiditatea și solvabilitatea valorilor
economice și de capacitatea sa de a se adapta la schimbările mediului în care își desfășoară activitatea.
Ecuația fundamentală a poziției financiare este de forma:
CAPITAL PROPRIU (ACTIV NET) = ACTIV – DATORII (PASIV)
O întreprindere are o poziție financiară pozitivă în cazul în care capitalul propriu este mai mare sau cel puțin egal cu datoriile cu valoare economică. Această condiție indică faptul că întreprinderea, ca subiect de drept, are posibilitatea să plătească obligațiile față de terți, atât pe parcursul desfășurării activității sale cât și la lichidarea sa.
Performanța sau rezultatul este definit prin prisma profitabilității întreprinderii. Ecuația folosită în acest sens este de forma:
REZULTATUL = VENITURILE – CHELTUIELILE
EXERCITIULUI EXERCITIULUI EXERCITIULUI
Având în vedere că rezultatul se delimitează ca o diferență dintre venituri și cheltuieli, ultimele două componente pot fi definite ca structuri ale capitalurilor proprii, rezultatul poate fi definit și prin prisma variației capitalurilor proprii.
De asemenea, în aceeași contabilitate, în loc de sintagma modificările poziției financiare este folosită cea de situație financiară. Modificările poziției financiare pot fi definite în diverse moduri cum sunt: fondul de rulment și fluxurile de fonduri, trezoreria netă și fluxurile nete de trezorerie.
Astfel, într-o viziune statică, modificările poziției financiare definite prin fondul de rulment și trezoreria netă, sunt formalizate pe baza bilanțului astfel:
Unde:
Fondul de rulment = Capital permanent – Activul imobilizat
Necesarul de fond = Stocuri și creanțe – Datorii din exploatare
de rulment din exploatare si și din afara exploatării
din afara exploatarii
Trezoreria netă = Fondul de rulment – Necesarul de fond de rulment
Caracteristicile calitative ale situațiilor financiare
Analiza caracteristicilor calitative ale informațiilor contabile se face în jurul a patru axe: inteligibilitatea, relevanța, fiabilitatea și comparabilitatea. Aceste caracteristici considerate a fi principale sunt susținute de o serie de calități anexe . Totodată, cadrul analizează restricțiile care trebuie respectate pentru ca informațiile financiare să răspundă la cele două calități fundamentale: relevanța și fiabilitatea.
INTELIGIBILITATEA vizează ușoara înțelegere a informațiilor de către utilizatori. În acest scop trebuie asigurat un echilibru între cunoștințele de contabilitate, care să fie suficiente, ale utilizatorilor privind afacerile și activitățile economice, pe de o parte, și dorința acelorași de a studia informațiile depunând eforturi rezonabile, pe de altă parte. Așa cum se desprinde din Cadru, informațiile despre probleme complexe care ar trebui incluse în situațiile financiare, datorită importanței lor în luarea deciziilor economice ale utilizatorilor, nu trebuie excluse doar pe motivul că ar putea fi prea dificil de înțeles pentru anumiți utilizatori.
RELEVANȚA. Informațiile au calitatea de relevanță dacă vehiculează cunoștințele necesare luării deciziilor economice de către utilizatori, adică îi ajută pe aceștia să evalueze evenimentele trecute, prezente sau viitoare, confirmând sau corectând evaluările lor trecute.
Relevanța informației este influențată de natura și materialitatea sa. În cele mai multe cazuri, natura este ea însăși suficientă pentru a determina relevanța sa. Dar nu puține sunt cazurile când natura trebuie asociată cu materialitatea sa.
FIABILITATEA. O informație este fiabilă atunci când nu conține erori sau elemente care să conducă la interpretări eronate; astfel, utilizatorii pot avea încredere in ea, în vederea reprezentării fidele a tranzacțiilor sau altor evenimente. Calitățile anexe legate de imaginea fidelă , de primordialitatea conținutului economic asupra naturii juridice, de prudență, de neutralitate și de exhaustivitate reprezintă ingredientele unei reprezentări fiabile.
COMPARABILITATEA. Informațiile prezentate în situațiile financiare trebuie să fie comparabile în timp și spațiu. Pentru a da curs acestei cerințe este necesară permanența metodelor contabile de evaluare, clasificare și prezentare a elementelor descrise în situațiile financiare. Dacă acestea s-au schimbat, utilizatorii trebuie să aibă posibilitatea de a identifica diferențele dintre metodele contabile utilizate.
Prin raportare la IAS 1 "Prezentarea situațiilor financiare" prezentarea fidelă și în conformitate cu Standardele Internaționale de Contabilitate impune:
(a) situațiile financiare trebuie să fie în conformitate cu prevederile contabile semnificative ale Standardelor Internaționale de Contabilitate;
(b) prezentarea fidelă nu exclude posibilitatea abaterilor de la o cerință specifică din Standardele Internaționale de Contabilitate;
(c) pentru a asigura o imagine fidelă și completă privind poziția financiară, performanța financiară și fluxurile de numerar ale unei întreprinderi, aplicarea corespunzătoare a IAS – urilor nu exclude prezența informațiilor suplimentare;
(d) tratamentele contabile neadecvate nu pot fi corectate, nici prin evidențierea politicilor contabile utilizate, nici prin note și material explicativ;
(e) trebuie evidențiate situațiile în care dispozițiile specifice dintr-un anumit standard sunt aplicate înainte de data intrării în vigoare a IAS-ului.
Principiile contabile
Principiile contabile sunt reguli care ajută producătorii de informații contabile la măsurarea, clasificarea și prezentarea situațiilor financiare. Totodată, ele constituie reguli foarte generale care pot fi puse în aplicare în mai multe moduri ce dau naștere mai multor norme contabile.
Pornind de la diversitatea de principii și reguli, se va adopta schema grupării acestora în: principiile înregistrării și ținerii contabilității, principiile partidei duble; principiile cuantificării; principiile observării și principiile responsabilității. Totodată, în Programul de dezvoltare a contabilității din România, în cadrul reglementărilor contabile au fost formulate și adoptate următoarele principii: principiul continuității activității; principiul prudenței; principiul permanenței metodelor; principiul independenței exercițiului; principiul evaluării separate a elementelor de activ și de pasiv; principiul intangibilității; principiul necompensării; principiul prevalenței economicului asupra juridicului; principiul pragului de semnificație.
Principiile înregistrării și ținerii contabilității
La principiile și regulile fundamentale care vizează fondul “producției” de informații și validarea lor socială contabilitatea trebuie să satisfacă un set de reguli de formă în măsură să-i confere calitatea probatorie, adică mijloc de probă în raporturile economico-juridice, cu deosebire în fiscalitate.
Forța probatoare a contabilității în raporturile juridice se înfăptuiește prin respectarea următoarelor reguli: înregistrarea completă și continuă; uniformitatea înregistrării contabile; fundamentarea documentară a înregistrării contabile și ținerea contabilității.
Înregistrarea completă și continuă.
Constă în reprezentarea în scris a tuturor operațiilor economice și financiare care modifică masa patrimoniului întreprinderii. Pentru a se realiza înregistrarea completă și continuă, întreprinderea este obligată să conducă următoarele registre: registrul-jurnal; registrul-inventar și cartea mare. Primele două au regim de înregistrare la administrația fiscală. Prin înregistrare ele pot fi admise ca probă în cadrul litigiilor, în caz de faliment, precum și în orice situații.
Din cadrul registrelor de contabilitate, enumerate mai sus, registrul-jurnal este documentul oficial care atestă înregistrarea tuturor operațiilor economice, financiare și juridice pe care le efectuează o întreprindere.
Principiile partidei duble
Definesc modul de sesizare și de reprezentare a informației contabile. Aceste principii sunt: dubla înregistrare; dublul calcul al rezultatului contabil; înregistrarea cronologică și sistematică; înregistrarea analitică și sintetică.
Principiul dublei reprezentări este fundamental pentru metoda contabilității. Potrivit dublei reprezentări, relațiile dintre structurile patrimoniale (stocurile de active și pasive) la un moment dat, precum și mișcările de valori economice sunt analizate și evidențiate ca un raport de echivalență (raport de schimb) între doi termeni: destinația /alocarea /utilizarea valorilor, pe de o parte, proveniența /finanțarea /reproducția valorilor, pe de altă parte.
Semnificația termenilor ecuației se diferențiază în raport cu obiectul dublei reprezentări. Astfel, în cazul în care acest obiect îl constituie situația financiară a patrimoniului luat în totalitatea sa, termenii ecuației sunt cei de activ și pasiv. Pentru activitățile consumatoare de resurse și producătoare de rezultate, ecuația se formalizează prin termenii de cheltuieli și venituri. În sfârșit, dacă obiectul reprezentării îl constituie elementele componente ale patrimoniului și operațiile care modifică aceste elemente, ecuația este de forma <<debit = credit>>.
Principiul dublului calcul al rezultatului contabil. Rezultatul contabil se calculează prin două relații, prima bazată pe capitalul propriu iar cea de a doua pe activitatea desfășurată.
Principiile de observare
Definesc câmpul și perioada de observare a evaluării și înregistrării contabile. Acestea sunt: entitatea contabilă, continuitatea activității și independența exercițiilor.
Principiul entității contabile definește perimetrul de observare și înregistrare al contabilității. Acesta se identifică cu un patrimoniu, și folosirea sintagmei de entitate patrimonială. Resursele economice și tranzacțiile privind mișcarea acestora sunt atribuite unei entități numai în măsura în care acestea își exercită dreptul de proprietate, de posesie și de folosință.
Definirea patrimonială a entității contabile exclude luarea în calculul economic contabil a acelor resurse economice care nu generează în plan juridic raporturi de proprietate în cadrul cărora se aproprie și gestionează bunuri.
Ipoteza separării patrimoniilor întreprinderii și proprietarilor nu concordă cu realitatea juridică decât dacă întreprinderea este sub formă de societate comercială de capital sau de persoane. În acest caz, bunurile economice aduse de participanți devin proprietatea societății, constituind un patrimoniu social propriu independent de acela al asociaților. Asociații nu mai au un drept real asupra patrimoniului, ci eventual un drept de creanță rezultat din calitatea lor de asociați. De asemenea, căpătând personalitate juridică , societatea nu mai acționează prin asociații săi, ci prin reprezentanți legali, denumiți întreprinzători sau administratori. Aceștia îndeplinesc în nume propriu toate actele juridice de conducere, administrare și gestionare.
La întreprinderile individuale cu proprietate personală rămâne la nivel de ipoteză separarea în plan juridic a celor două patrimonii: patrimoniul afacerii și patrimoniul personal al proprietarului. Totuși, chiar dacă separarea celor două patrimonii este fictivă din punct de vedere juridic, în plan contabil se impune individualizarea lor pentru a calcula situația financiară, performanța și fiscalitatea.
Principiul continuității activității presupune că întreprinderea iși continuă în mod normal activitatea într-un viitor previzibil, fără a intra în starea de lichidare sau de reducere sensibilă a activității sale. În cazul în care este vorba de necontinuitate, conturile sunt prezentate pe baza unei evaluări în valori lichidative, nu se mai amortizează activele, nu se mai permanentizează metodele de evaluare și calcul economic, etc.
Principiul independenței exercițiului efectele tranzacțiilor și alte evenimente sun luate în calcul din momentul când acestea s-au produs și nu atunci când intervine plata sau încasarea de lichidități sau a echivalentului de lichidități.
În reglementările contabile din România, acest principiu este definit prin prisma delimitării în timp a veniturilor și cheltuielilor corespunzătoare exercițiului financiar pentru care se face raportarea, fără a se ține seama de data încasării sumelor sau a efectuării plăților. Un asemenea demers conduce la considerarea fiecărui exercițiu ca un tot independent separat de exercițiile anterioare sau cele viitoare, evidențiind toate cheltuielile și veniturile și atribuind doar acele cheltuieli și venituri care îi sunt proprii.
Principiile responsabilității
Vizează permanența sau consecvența metodelor, intangibilitatea bilanțului de deschidere, necompensarea și importanța relativă.
Principiul permanenței metodelor contabile constă în asigurarea continuității de la un exercițiu la altul, a aplicării metodelor contabilizării și a evaluării adoptate în contabilitate privind măsurarea și analiza activelor, datoriilor și rezultatelor. Pe această cale se asigură integritatea situației patrimoniului și comparabilitatea în timp a informațiilor. Metode și evaluări diferite conduc la rezultate diferite.
Așa cum se arată în Standardul de Contabilitate Internațional nr. 8 modificarea metodei de contabilitate are loc atunci când noua metodă este impusă de lege sau de o autoritate cu atribuții de normalizare a contabilității, precum și în cazul în care se consideră că această schimbare va oferi o prezentare mai adecvată a bilanțului contabil.
Principiul intangibilității bilanțului de deschidere impune ca la deschiderea exercițiului să fie preluate informațiile privind patrimoniul și rezultatele de închidere a exercițiului precedent. Orice eventuale modificări trebuie divulgate potrivit regulilor privind schimbarea metodelor contabile și de evaluare.
Principiul necompensării. Este interzis a se efectua compensarea între posturile de activ și cele de pasiv, între creanțe și datorii, între posturile de cheltuieli și venituri. În felul acesta se asigură transparența informației, implicit evaluarea și înregistrarea separată în contabilitate a elementelor patrimoniale de activ și pasiv, cheltuieli și venituri.
Principiul necompensării nu trebuie absolutizat, el este opozabil numai în cazul în care activele și pasivele, datoriile și creanțele, cheltuielile și veniturile constituie structuri separate și în virtutea cerințelor pragului de semnificație trebuie prezentate separat în situațiile financiare . Activele și datoriile nu trebuie compensate decât cu excepția cazurilor în care substituirea este cerută sau permisă de un standard de contabilitate. De asemenea, elementele de venituri și cheltuieli pot fi compensate decât în baza unor prevederi speciale din standardele de contabilitate sau dacă câștigurile, pierderile și cheltuielile provenite din aceeași tranzacție / eveniment ori din tranzacții / evenimente similare nu sunt semnificative.
Principiul importanței relative sau pragului de semnificație impune ca situațiile financiare să evidențieze toate operațiile economice și financiare, precum și informațiile a căror importanță poate afecta evaluările și deciziile. De exemplu, trecerea în bilanț la o valoare fixă a acelor elemente reduse ca valoare care sunt în permanență reînnoite, iar valoarea lor nu variază semnificativ de la un exercițiu la altul. Așa cum se afirmă în contabilitatea anglo – saxonă, un eveniment este considerat important când poate influența decizia celor care folosesc situațiile financiare, iar valoarea informației depășește sensibil costul prelucrării și transmiterii acesteia. De asemenea, potrivit principiului pragului de semnificație, orice element care are o valoare semnificativă trebuie prezentat separat în cadrul situațiilor financiare.
Elementele cu valori nesemnificative care au aceeași natură sau funcții similare vor fi însumate nefiind necesară prezentarea lor separată.
Principiile măsurării și evaluării
Problemele de valoare și implicit de evaluare în contabilitate nu pot fi discutate decât în relație cu principiile contabile fundamentale. În acest sens, patru principii pot fi reținute: costul istoric, stabilitatea unității monetare, prudența și continuitatea exploatării.
Principiul costului istoric impune înregistrarea în contabilitate a activelor și pasivelor la costul de origine consemnat în documentele justificative. Cu acest cost figurează în contabilitate de la intrare și până la ieșire, el putând fi substituit prin alte prețuri sau modificat numai prin reevaluare.
Costul istoric reflectă valoarea reală a elementelor patrimoniale la data intrării lor în întreprindere. Dar, ulterior, orice schimbare semnificativă tinde să facă costul istoric înșelător în scopul luării deciziei și asigurării capacității de finanțare sau a puterii de cumpărare a capitalului propriu.
Un principiu care corijează parțial limitele costului istoric este cel al prudenței. Acesta constă în aprecierea cu precauție sau rezonabil a activelor și pasivelor, cheltuielilor și veniturilor pentru a evita supraevaluarea rezultatului. Potrivit principiului prudenței nu este admisă supraevaluarea elementelor de pasiv și a veniturilor, respectiv subevaluarea elementelor de activ și a cheltuielilor, ținând cont de deprecierile, riscurile și pierderile posibile generate de desfășurarea activității exercițiului curent sau anterior.
Principiul evaluării separate a activelor și datoriilor. În vederea stabilirii valorii totale corespunzătoare a fiecărei poziții din bilanț se determină separat valoarea aferentă fiecărui element individual de activ sau de datorii.
Principiul prevalenței economicului asupra juridicului acest principiu este specific sistemelor contabile anglosaxone, el fiind acceptat în mod limitat în țările în care informația contabilă este puternic influențată de aspectele juridice.
Standardul IAS 1 menționează în legătură cu acest principiu, că “operațiile si alte evenimente ale vieții întreprinderii trebuie să fie înregistrate și prezentate conform naturii lor și realității financiare, fără să se țină cont, în mod unic, de aparența lor juridică”.
Principalele operațiuni de import-export:
Stocarea si pregatirea marfurilor pentru livrarea la export
In funcție de locul pe care-l ocupă in sistemul pieței produselor, unitățile economice actioneaza cu sau fara eficienta, in calitate de consumatori sau producatori-furnizori. Pentru rezolvarea unei asemenea cerinte, unitatea economica consumatoare poate alege, cea mai eficienta forma de aprovizionare. La alegerea formei de aprovizionare se va avea in vedere ca optiunea sa asigure:
acces usor la servire;
satisfacerea prompta, in conditii economice avantajoase, a intregii structuri de produse necesare si la momentele dorite;
cumpararea si aducerea resurselor materiale la destinatie la preturi
de aprovizionare cat mai mici;
prevenirea suprastocarii, a formarii de stocuri cu miscare lenta sau fara miscare, ca si a lipsei de stoc;
evitarea stocarii de resurse materiale pe perioade prea lungi de timp, prin inlesnirea asigurarii la intervale mici si accelerarea vitezei de rotatie a fondurilor de care dispune sau/si asigura intreprinderea consumatoare;
afectarea unor spatii de depozitare mai reduse pentru stocarea resurselor aprovizionate in cantitati mai mici si la intervale mai scurte de timp.
Costul stocarii poate fi rezultatul unui raport de proportionalitate fata de pretul de achizitie sau de aprovizionare sau calculat ca efect al imobilizarilor resurselor in stoc.
Tehnici de masurare a costurilor la stocuri:
IAS 2 referitor la „Contabilitatea stocurilor” recomanda folosirea a doua metode pentru masurarea valorii stocurilor, si anume: metoda costurilor standard si metoda pretului cu amanuntul.
Trebuie mentionat ca in contabilitatea din Romania se mai practica si o a treia metoda, acea a costurilor efective; aceasta mai este cunoscuta si ca metoda costurilor standard sau metoda costurilor prestabilite.
In cele ce urmeaza se vor face succinte prezentari ale diferitelor tehnici de masurare a costului stocurilor.
a) Metoda costurilor efective. Costul stocurilor se stabileste pe baza datelor consemnate in documentele justificative. Tehnica de masurare este cea a insumarii elementelor constitutive ale costului stocului.
b) Metoda costurilor standard sau prestabilite. Costul stocurilor este o cheltuiala estimata in functie de materialele si consumabilele aferente, sapreciate ca fiind normale, de manopera – prestabilita in conditii normale privind eficienta si folosire a capacitatii de productie. Altfel spus, costurile standard sunt costuri antecalculate, in raport de datele relativ constatate referitoare la perioade precedente.
Metode si uzante de asigurare a calitatii marfurilor
la nivelul intreprinderii importatoare
In activitatea de comert exterior un rol deosebit revine procedurilor de asigurare a calitatii marfurilor, ce fac obiectul operatiunilor de export/import. Aceasta presupune o serie de activitati si operatii intreprinse de catre partenerii implicati in tranzactii ce au ca scop final delurarea in conditii optime a contractului.
Referitor la calitatea marfurilor reglementarile comunitare prevad coexistenta dintre regimurile nationale cu marcile comunitare si astfel, prin tranzactiile care se efectueaza, agentii economici pot opta intre marcile nationale si cele comunitare.
Metode si uzante de asigurare a calitatii marfurilor
la nivelul intreprinderii exportatoare
O intreprindere exportatoare trebuie sa mentina permanent nivelul calitativ stabilit pentru produsele contractate. « Calitatea » trebuie sa reprezinte scopul urmarit in cadrul tuturor activitatilor desfasurate, de la receptia materiilor prime si pana la livrarea produselor finite, la toate nivelurile ierarhice si pentru toti cei care participa la productie sau comercializare.
Inainte de lansarea unui proiect de productie ce urmeaza a fi destinata exportului, conducerea intreprinderii va trebui sa-si asigure echipamentele de lucru necesare pentru a raspunde cu succes exigentelor proceselor de fabricatie.
Exportatorul – trebuie sa stie care sunt caracteristicile care il vor determina pe consumator sa accepte sau sa refuze tipul respectiv de produs, cum se situeaza produsul pe piata externa in raport cu produsele similare ale firmelor concurente, care sunt elementele care ii pot conferi superioritate fata de articolele deja comercializate pe piata importatoare, astfel incat produsele acesteia destinate exportului sa se situeze la niveluri
calitativ ridicate, sa satisfaca gustul consumatorilor externi si sa se realizeze pe pietele externe in cauza.
Conditionarea si ambalarea neconforma cu specificatiile contractuale sau, in lipsa acestora, cu procedurile obisnuite in bransa respectiva fac obiectul refuzului marfurilor de catre cumparator, avarierii sau alterarii in timpul transportului si depozitarii sau reducerii timpului de comercializare.
Firmele exportatoare trebuie sa previna aparitia defectelor pentru produsele lor prin definirea unor standarde de firma proprii si prin dotarea cu sisteme de control al calitatii eficiente.
Exporturile in sectorul alimentar catre Uniunea Europeana sunt supuse Reglementarii C.E.E. nr.339/1993 a Consiliului Europei privind efectuarea controalelor de conformitate a produselor importate din tari terte cu reglementari care se aplica in domeniul securitatii produselor.
Conform acestui document, daca autoritatile vamale constata :
prezenta unui produs (lot de produse) care prezinta indoieli la securitatea alimentara ;
absenta unui document sau a unui marcaj care trebuie sa insoteasca produsul, acestea sunt indreptatite sa opreasca comercializarea produsului respectiv si sa informeze autoritatile nationale cu competente in sfera supravegherii pietei de desfacere.
Vamuirea marfurilor
Romania, ca membra a Organizatiei Mondiale a Comertului (OMC), are o politica comerciala compatibila cu cerinbtele acesteia. Ca membra a OMC, Romania a negociat plafoane pentru taxele vamale – taxele vamale consolidate. In Runda Uruguay taxele vamale consolidate negociate de Romania au fost foarte diricate, insa taxele vamale efectiv aplicate au fost mai mici si ulterior s-a decis reducerea acestora la un nivel cat mai apropiat de nivelurile reale/practicate. De asemenea, Romania aplica regimul vamal al clauzei natiunii celei mai favorizate (CNF) tarilor membre ale OMC, si acorda unor parteneri comerciali taxe vamale preferentiale in cadrul acordurilor de comert.Introducerea sau scoaterea din tara a marfurilor, a mijloacelor de transport si a oricaror altor bunuri si servicii este permisa numai prin punctele de control de trecere a frontierei de stat in conformitate cu prevederile Codul Vamal al României .
Codul vamal se aplica in mod uniform si nediscriminatoriu pe intreg teritoriul tarii. Prevederile cuprinse in Codul Vamal al României se aplica tuturor bunurilor introduse sau scoase din tara de catre persoane fizice sau persoane juridice. In Anexele 5.1. – 5.6. sunt sintetizate principalele prevederi ale Legii nr.141/1997 privind Codul Vamal al României.
Marfurile supuse operatiunii de vamuire in cadrul birourilor vamale
raman sub supravegherea acestora pana la acordarea liberului de vama,care presupune indeplinerea urmatoarelor operatii:
bunurile care ies din tara se inscriu, in ordinea sosirii la frontiera, in registrul de evidenta pe baza documentelor de transport si a celor comerciale ; în lipsa documentelor de insotire, inscrierea marfurilor se face pe baza constatarilor autoritatii vamale sau a altor documente prezentate de catre operatorul economic organelor vamale ; din aceste documente trebuie sa rezulte tipul si caracteristicile marfurilor ce urmeaza sa fie supuse vamuirii ;
regimul de export consta in scoaterea definitiva a marfurilor romanesti de pe teritoriul tarii;
conform prevederilor legale sunt admise la export marfurile produse in tara, precum si cele importate anterior, cu exceptia marfurilor care sunt supuse unor masuri prohibitive sau de restrictie ce sunt formulate prin politica economica de comert exterior adoptata de executiv la un moment dat ; in general, regulile de clasificare tarifara prevazute la exportul de marfuri se aplica si la import;
exportatorul care scoate marfuri din tara, definitiv sau temporar, este obligat sa depuna o declaratie vamala de export la biroul vamal in raza caruia se afla sediul exportatorului sau la locul/adresa la care marfurile sunt ambalate ori incarcate pentru a fi exportate ; legea prevede ca in cazuri temeinic justificate declaratia vamala sa poata fi depusa si la un birou vamal de frontiera ;
la exportul de marfuri nu se incaseaza taxe vamale si TVA; la importul de marfuri se incaseaza taxe vamale si TVA;
liberul de vama la export se acorda cu conditia ca marfurile in cauza sa paraseasca teritoriul Romaniei in aceiasi stare in care acestea se aflau in momentul inregistrarii vamale la export .
Principalelor documente nonfinanciar-contabile obligatorii
ce insotesc marfurile in tranzactiile internationale
Documente necesare la import
Factura comerciala externa – de la exportator; factura de transport (daca acesta este platit separat) – de la exportator; document de transport si asigurare marfa; actele firmei exportatoare – de la exportator; actele firmei importatoare; licenta de import, daca este cazul – de la Ministerul de Externe; certificat de origine a marfii – de la biroul vamal sau camerele de comert ale tarii exportatoare; certificat de conformitate, de calitate – de la producator; certificat de garantie – de la producator; contract extern;
packing list – de la exportator; alte avize, daca este cazul (certificate fitosanitare,
certificate sanitar-veterinare, certificate de abilitate etc.); declaratia vamala de import.
Documente necesare la export
Factura comerciala externa (se completeaza in cel putin 3 exemplare in original – nu se calculeaza TVA la export); factura de transport si asigurare marfa; document de transport si asigurare marfa; actele firmei exportatoare; licenta, daca este cazul; certificat de origine a marfii; certificate de conformitate, de calitate; certificat de garantie; contract extern; declaratie de incasare in valuta; packing list; alte avize, daca este cazul (certificat fito-sanitar, certificat sanitar-veterinar, certificate de abilitate etc.); declaratie vamala de export.
Contabilitatea operatiunilor de import/export
Importul si exportul de marfuri au diferite forme de realizare. Din acest
punct de vedere cele doua activitati comerciale se caracterizeaza dupa26:
modalitatile de realizare a importului de marfuri se efectueaza pe cont propriu si in comision;
termenul de decontare a marfurilor importate se face cu plata la vedere si cu plata la termen (pe credit comercial);
principalele instrumente de decontare cu furnizorii externi: acreditivul documentar; incasso-documentar precum si pe baza de efecte de comert;
marfurile importate generale si marfuri complexe;
destinatia marfurilor importate: pentru consumul intern si pentru reexport.
Recunoasterea marfurilor sosite din import se face pe baza facturii comerciale externe27. In factura comerciala externa sunt inscrise pretul extern al marfurilor din partea exportatorului extern, cantitatea precum si valoarea totala. Derularea contractului la importul de marfuri se face la preturi FOB (free-of-board) portul strain de incarcare, in conditiile CIF (cost-insurance and freight) portul romanesc de descarcare. De asemenea in factura externa se prevad, in principal, conditiile de livrare, si modalitatea de plata.
Pretul initial (Pi) al intreprinderii de comert exterior care importa marfuri este compus din urmatoarele:
pretul extern (Pex) in valuta ce este convertit la cursul zilei (Pexcsz) mentionam ca pretul extern al marfii este fara TVA din tara de origine;
costul transportului la extern (Ctex);
cheltuieli vamale: comision vamal (Cv) + taxa vamala (Tv) + taxe de magazinaj in vama (Tmv); in prezent (i) comisionul vamal se aplica in cota de 0,5% la pretul extern in valuta si convertit in lei, (ii) taxa vamala este diferentiata pe grupe de marfuri de catre Directia Generala a Vamilor, iar (iii) taxa de magazinaj depinde de numarul de zile de stationare a marfii importate in vama.
Pi = Pexcsz + Ctex + (Cv + Tv + Tmv)
La pretul initial al intreprinderii de comert exterior ce importa marfuri se adauga urmatoarele componente28:
accize (Acc) – se aplica conform reglementarilor MFP numai la anumite categorii de marfuri;
taxa pe valoarea adaugata (TVA) – aferenta marfurilor importate stabilita conform legislatiei din tara importatorului (in Romania in prezent cota de TVA este 19% si se aplica la urmatoarele: pretul extern al importatorului (Pex) + cheltuieli vamale (Chv + Tv + Tmv) + accize (Acc);
cheltuieli de transport la intern (Chti);
cheltuieli de manipulare a marfii (Chmm);
cheltuieli de depozitare (Chd).
Rezulta costul total al achizitionarii marfurilor importate (CTAimp):
CTAimp = Pi + Acc + TVA + Chti + Chmm + Chd)
Pretul de vanzare al marfurilor importate (Pmimp) este format din:
– costul total al achizitionarii marfurilor importate (CTAimp);
– marja comerciala a importatorului (Mcimp).
Pmimp = CTAimp + Mcimp
Marja comerciala a importatorului este cota care se aplica de catre acesta la costul total al achizitionarii marfurilor importate (CTAimp). In cele ce urmeaza se prezunta tratamentele contabile aferente importului de marfuri realizat in cadrul unei firme de comert exterior importatoare, care este beneficiar direct29, cu plata la vedere.
Recunoasterea, evaluarea si tratamentele contabile la exportul de marfuri
Exportul de bunuri si servicii este privit de pe pozitia firmei romanesti care livreaza bunuri, presteaza lucrari si executa servicii in alte tari. Recunoasterea marfurilor pentru export se face pe baza facturii fiscale interne transpusa in factura externa30. In factura externa sunt inscrise in principal conform contractului convenit intre parti pretul pentru export si cantitatea.
Principalele aspecte privind raportarea financiara a exporturilor in economiile in tranzitie
Una din caracteristicile economiilor in tranzitie o reprezinta manifestarea unor fenomene hiperinflationiste. Aceasta se caracterizeaza prin:
preturile nationale sunt raportate la o valuta stabila (de obicei Euro sau USD);
tranzactiile pe credit au loc la „preturi” mari, dobanzile aplicate urmarind pierderi estimate a puterii de cumparare;
preturile isi pierd puterea de cumparare;
cantitatea de marfuri achizitionate de pe piata interna este mai mica etc.
Conform IAS 29 intr-o economie hiperinflationista rezultatele financiar-contabile trebuie ajustate; pentru ajustare se foloseste indicele preturilor calculat de institutele de statistica sau exprimarea printr-o valuta relativ mai stabila. Cand inceteaza hiperinflatia inceteaza si ajustarea financiar-contabila.
In cazul activitatilor de import/export intr-o moneda liber convertibila, ajustarile de curs valutar executate in diferite momente ale derularii activitatilor respective pot fi asimilate ajustarilor recomandate de IAS 29.
Studiul sistemului de conducere
Societatea "ISA" are ca reprezentant un asociat unic care exercită drepturile și obligațiile ce revin potrivit legii române.
Asociatul unic este persoana fizica/juridică străină sau romana,care in România are următoarele atribuții:
aprobă structura organizatorică a societății și numărul de posturi
decide majorarea sau reducerea capitalului social
decide asupra modificării obiectului de activitate al societății
decide schimbarea sediului social al societății
decide fuziunea cu alta societate
decide dizolvarea anticipată a societății
decide orice modificare a statutului sau în orice altă problemă privind societatea, aflată în competența sa, potrivit legii sau prezentului statut
decide asupra transferului părților sociale
aprobă politica generală a societății
numește și revocă administratorul societății
discută, aprobă, modifică raportul anual prezentat de administrator și determină dividendele
trasează sarcinile, răspunderea și nivelul de salarizare al administratorului
descarcă administratorul de răspunderea sa referitoare la administrarea societății în cursul anului financiar deja încheiat
aprobă bilanțul și contul de profit și pierderi
aprobă bugetul pentru anul următor
numește lichidatorii
decide gajarea, închirierea, concesionarea sau dizolvarea uneia sau mai multor unități ale societății
Hotărârile asociatului unic adoptate în scopul îndeplinirii atribuțiilor prevăzute sunt luate de către Consiliul de Administrare al societății "ISA" .
Administratorul are următoarele atribuții:
definește și decide politica de credite a societății împreună cu asociatul unic;
supraveghează întocmirea bilanțului și a contului de profit și pierderi în conformitate cu prevederile legale în vigoare
pregătește raportul anual
angajează și concediază personalul societății, îi definește drepturile și obligațiile precum și nivelul de salarizare
aprobă toate tranzacțiile financiare și comerciale pe care le consideră ca depășesc nivelul de competență al angajaților
ORGANIGRAMA societații comerciale ISA S.R.L.
Studiul sistemului condus
Studiul sistemului informațional
Pentru proiectarea sistemelor informatice exista mai multe metode de proiectare, metode perfecționate în decursul timpului. Pentru sistemul informatic de contabilitate pe care l-am dezvoltat eu am ales metoda de proiectare orientată obiect deoarece în cadrul acestei metode eu am găsit toate instrumentele necesare proiectului ce urma sa îl construiesc.
Caracteristici ale proiectării sistemului informatic financiar-contabil:
Definirea obiectivelor
Obiectivele sistemului informatic reprezintă scopuri imediate și de perspectivă ale perfecționării activității economice și de conducere, în vederea ridicării nivelului de informare operativă și previzională a structurilor organizatorice, a perfecționării metodelor și proceselor tehnico-informaționale și de conducere pentru asigurarea maximalizării eficienței economice și a rentabilității unității beneficiare.
Obiectivele sistemului informatic presupun abordarea și rezolvarea informatică a unor probleme cu caracter sintetic și analitic, într-o manieră sistemică, pentru asigurarea scopurilor propuse. Aceste obiective sunt diferențiate în funcție de nivelele micro, mezo și macroeconomice având caracteristici generale și specifice, subordonate cadrului legislativ-normativ, dotării cu tehnică de calcul și cerințelor dezvoltării economice, imediate și de perspectivă, a unității beneficiare.
Obiectivele sistemului informatic pot fi:
generale ;
specifice.
Obiectivele generale ale unui sistem informatic vizează probleme cu caracter global ale conducerii unității comerciale și structurale specifice compartimentelor funcționale, în scopul realizării atributelor conducerii și ale funcțiilor unităților economice.
Obiectivele specifice ale unui sistem informatic urmăresc rezolvarea unor probleme dependente strict de activitatea de bază (producție, comerț, servicii, etc.) și de cea auxiliară, în raport de funcțiile de cercetare și producție. Acestea au un caracter propriu și dependent de rolul unității economice în mecanismul economiei de piață.
Metode de proiectare a sistemelor informatice
Metode de proiectare a sistemelor informatice
Evoluție structurabilă în trei generații de metode, determinată de:
creșterea ariei de utilizare a sistemului informatic;
creșterea gradului de complexitate a aplicațiilor și a cerințelor de integrare;
evoluția structurii și tipologiei aplicațiilor de gestiune : SIG, SIAD, SE, SIE, birotică, multimedia;
Metode ierarhice
prima generație, anii ’70;
sistemul informațional/informatic este structurat pe baza funcțiilor sale;
centrate pe analiza funcțională : fiecare funcție identificată se subdivide ierarhic în subfuncții, continuând în această manieră până se ajunge la componente suficient de mici astfel încât acestea sa poata fi programate cu usurință;
Avantaje: simplitate, bună adaptare la definirea cerințelor utilizatorului.
Dezavantaje : concentrează efortul de analiză asupra fucțiilor neglijând coerența datelor; volatilitatea cerințelor utilizatorilor face ca aplicațiile sa fie într-o aproape continuă reconsiderare.
Metode sistemice :
generația a doua, anii ’80;
se bazează pe aplicarea teoriei sistemelor în analiza întreprinderii;
sistemul informațional/informatic este abordat sub doua aspecte complementare: datele și prelucrările, care sunt studiate și modelate independent și reunite cât mai târziu cu putință;
acordă prioritate datelor față de prelucrări;
respectă cele trei nivele de concepție : extern, conceptual, intern;
exemple: MERISE, AXIAL, Information Engineering.
Avantaje : sistemele se axează pe conceptul de bază de date, care oferă mai multă coerență, stabilitate si elimină redondanțele.
Dezavantaje : deficiențe în modelarea prelucrărilor, posibilitatea apariției de discordanțe între modelele datelor și ale prelucrărilor.
Metode orientate obiect (obiectuale)
Metodele de "Analiză și proiectare orientate obiect" au apărut după anul 1990 preluând cele mai bune idei ale programării structurate și le-a combinat cu concepte noi încurajând programatorii să privească activitatea de programare într-o nouă optică.
Un consorțiu american (Object Management Group-OMG) format din peste 800 de companii ce produc și distribuie aplicații la a căror realizare s-a utilizat tehnologia orientată obiect și care stimulează și supraveghează adoptarea unor standarde industriale în domeniu a hotărât să studieze posibilitățile de convergență din domeniul metodelor de analiză și proiectare orientate obiect.
La 17 noiembrie 1997 OMG a hotărât unificarea celor mai utilizate și mai apreciate metode de analiză și proiectare prin realizarea unui standard în domeniul construirii sistemelor software, într-un LIMBAJ DE MODELARE UNIFICAT (UML-Unified Modeling Language).
Limbajul de modelare unificat (UML) utilizează simbolistici grafice în simbioză cu adnotările textuale care conduc la:
o înțelegere mult mai rapidă și completă a domeniului problemei;
schimbarea instantanee a nivelului de abstractizare a prezentării cu ajutorul instrumentelor;
automatizarea tuturor activităților care se pretează la acest gen de abordare.
Analiza și proiectarea orientată obiect privește sistemul informatic ca o structură de obiecte autonome ce se organizează și cooperează între ele. Fiecare obiect poate interveni în mai multe feluri sau scenarii funcționale diferite și poate participa la conceperea altor obiecte mai complexe.
Regruparea proprietăților și metodelor într-o singură entitate (încapsularea) este un concept fundamental de modelare a datelor la fel ca instanțierea și abstractizarea sau generalizarea.
Analiza și proiectarea orientată obiect utilizează limbaje de programare orientate obiect care au cinci elemente comune:
obiecte și clase de obiecte;
abstractizare;
încapsulare;
moștenire;
polimorfism.
Un obiect încapsulează caracteristici structurale și comportamentale. La modul general, un obiect este caracterizat prin trei elemente: stare, comportament și identitate.
Starea este formată din setul de valori corespunzătoare atributelor obiectului.
La un moment dat un obiect are o singură stare, dar această stare se poate modifica în timp ca urmare a execuției operațiilor.
Mai multe obiecte care posedă aceleași caracteristici formează o clasă de obiecte.
Abstractizarea implică reflectarea caracteristicilor comune și relevante ale unui set de elemente și eliminarea caracteristicilor irelevante. O definiție elocventă este dată de Jim Rumbaugh care consideră: “abstractizarea este examinarea selectivă a anumitor aspecte ale unei probleme.Scopul abstractizării este izolarea acestor aspecte care sunt importante și eliminarea acelor aspecte care nu prezintă importanță. ”
Prin încapsulare se ințelege reunirea datelor (atributelor) și operațiilor (metodelor) aferente acestora într-o clasă de obiecte. Legat de conceptul de încapsulare este conceptul de ascundere a informației. Booch a dat conceptului de ascundere a informației definiția cea mai clară: “procesul de ascundere a detaliilor unui obiect care nu constituie caracteristicile esențiale; în mod curent structura unui obiect este ascunsă, ca și implementarea metodelor sale ”. Astfel o clasă de obiecte va fi formată din membri vizibili și membrii privați.
Moștenirea definește o relație între clase prin care o clasă, numită superclasă partajează structura și comportamentul comun a uneia sau mai multor clase numite subclase. Astfel atributele și metodele superclasei sunt moștenite de subclasele sale.Spre exemplu o superclasă ContBancar poate avea subclasele : ContBancarPersoanăFizică și ContBancarSocietate Comercială.
Polimorfismul într-o traducere desemnează capacitatea de a avea mai multe forme. În abordarea obiectuală acest concept reflectă faptul că trimiterea unui mesaj poate avea drept rezultat comportamente diferite.
Caracteristici ale limbajului UML (Unified Modeling Language):
UML cuprinde un set de nouă diagrame care pot fi utilizate pentru vizualizarea, specificarea, descrierea și documentarea sistemelor:
diagrama cazurilor de utilizare;
diagrama claselor;
diagrama obiectelor;
diagrama de activități;
diagrama de secvențe;
diagrama de colaborări;
diagrama de stări-tranziții;
diagrama componentelor;
diagrama de amplasare.
Aceste diagrame pot fi utilizate pentru realizarea de modele care să descrie sistemul informatic, un model reflectând un anumit aspect al sistemului.
Diagrama cazurilor de utilizare: Un caz de utilizare corespunde unui serviciu furnizat de către o anumită entitate unuia sau mai multor utilizatori. Entitatea implicată poate fi sistemul sau o anumită componentă a acestuia, cum ar fi un subsistem sau o clasă. Utilizatorii sunt întotdeauna exterioru entutății avute în vedere și sunt reprezentați drept actori ai cazului de utilizare.
Reprezentarea structurii se face prin Diagrama claselor și Diagrama obiectelor: Aceste două diagrame concentrează o parte însemnată a rezultatelor eforturilor de analiză și de proiectare.
O clasă de obiecte corespunde semantic unui concept din sistemul real ce urmează a fi modelat. Reprezentarea unei clase trebuie să indice ansamblul de atribute ce formează structura sa, operațiile ce-I definesc comportamentul și relațiile cu alte elemente ale modelului.
Diagrama de activitate: diagramele de activitate servesc pentru descrierea dinamicii sistemului, în situațiile în care stările observate sunt reprezentate de acțiuni sau subactivități, iar evenimentele care declanșează tranzția de la o stare la alta, în totalitate sau în cea mai mare parte, constituite de încheierea acestor activități sau subactivități.
Acest tip de diagramă foloseste următoarele elemente: acțiuni, tranziții, puncte de decizie și bare de sincronizare.
Diagrama de secvențe: – diagrama de secvențe este utilă în special pentru definirea specificațiilor de funcționare în timp real și pentru scenariile de funcționare complexe, deci pentru cazuri în care dimensiunea temporală este importantă sau vitală.
Diagrama de secvențe se dezvoltă într-un plan al cărui dimensiune verticală reprezintă timpul iar cea orizontală participanții.
Diagrama de colaborări: – diagrama de colaborări are forma unui graf ale cărui noduri reprezintă, în funcție de nivelul pe care se dezvoltă – specificare sau instanțiere – roluri de clasificatori sau obiecte și ale cărui arce indică asocieri sau legături între obiecte. În această structură, diagrama prezintă participanții și relațiile dintre aceștia, necesari realizării interacțiunilor și poate fi folosită pentru a defini contextul aferent unei operații sau ansamblului operațiilor unei clase sau grup de clase.
Diagrama de stări: Diagrama de stări servește pentru a reprezenta suita de stări prin care poate trece un element de modelare – fie acesta obiect sau interacțiune – în cursul existenței sale, ca reacție la evenimentele survenite în exteriorul său.
Diagrama componentelor: – diagrama componentelor reflectă structurarea programelor prin care se implementează pachetele din planul arhitectural logic și legăturile necesare între acestea.
Diagrama de amplasare: diagramele de amplasare prezintă modul de distribuire fizică al tuturor echipamentelor utilizate în cadrul sistemului și repartizarea componentelor de program executabil pe acestea.
Reprezentarea are forma unui graf ale cărui noduri corespund resurselor de prelucrare a datelor implicate. În general, se consideră ca o asemenea resursă posedă cel puțin memorie și un procesor.
Avantaje : permite reutilizarea componentelor de program, favorizează modelarea și utilizarea de obiecte complexe.
Dezavantaje: percepția și reprezentarea monolitică de tipul“totul este obiect” nu corespunde întotdeauna realității reprezentate.
Soluții de realizare a sistemului informatic
Pentru realizarea sistemul informatic existau mai multe limbaje de programare în care putea fi construit sistemul.
Dintre acestea, cele mai cunoscute sunt:
Limbajul Visual Basic;
Limbajul Visual C++;
Limbajul C – Sharp;
Oracle;
Fox Pro;
Microsoft Access.
Din multitudinea de soluții, eu am ales dezvoltarea sistemului informatic în limbajul Microsoft Access, realizarea diagramelor orientate obiect, documentarea foarte atentă a aplicației și testarea pe mai multe computere, de către mai multe persoane cu părerile tuturor și erorile pe care le depistau la începutul aplicației, erori care au fost rezolvate.
Limbajul Visual Basic, este un limbaj foarte puternic, dar persistența trebuie asigurată cu exteriorul aplicației, într-ucât acest limbaj nu are propriile tabele.
Limbajele Visual C++ și Visual C# (C-Sharp) sunt dintre cele mai puternice limbaje existente, fac parte din limbajele lansate de microsoft, cea mai importantă firmă de pe planetă, dar sunt la începutul lucrului cu aceste limbaje și în cadrul facultății nu s-a studiat așa ceva (doar la facultatea Cibernetică).
CAPITOLUL II – PROIECTAREA DE ANSAMBLU A SISTEMULUI INFORMATIC
Soluții de modele
Analiza și proiectarea orientată obiect folosește trei modele diferite pentru descrierea unui sistem informatic:
1. Modelul obiect: descrie obiectele și relațiile lor în sistem;
2. Modelul dinamic: descrie interacțiunile între obiecte în cadrul sistemului;
3. Modelul funcțional: descrie transformarea valorii datelor în sistem.
1. Modelul obiect – Concepte de bază:
Obiecte :
Orice lucru din lumea înconjuratoare poate fi considerat un obiect (ex.: o persoană, un formular de cerere, un ordin de plată, etc.), iar prin analogie în analiza și proiectarea orientată pe obiect, un câmp dintr-o bază de date (ex. cod produs), un formular de bilanț etc., sunt considerate obiecte.
Un obiect se caracterizează prin:
Proprietăți – care redau atributele fizice ale unui obiect.
Ex. pentru obiectul Factură ca proprietăți pot fi:
număr factură;
data factură;
cod fiscal, etc.;
sau pentru un text sau control dintr-o fereastră ecran se definesc următoarele proprietăți sau atribute:
poziția pe ecran;
lățimea;
înălțimea;
culoarea;
variabila care îl însoțește;
tipul fontului;
vizibilitatea, etc.;
Metode care reprezinta actiunile ce pot fi efectuate de un obiect.
Exemple:
afișarea pe ecran a unei anexe din formularul de bilanț;
calcularea stocului curent de materiale;
suma drepturilor cuvenite salariaților;
totalul valorii mărfurilor vândute;sau pentru o fereastră ecran ca metode ar putea fi:
open;
close etc.
Metoda redă ceea ce poate face un obiect, iar manipularea obiectelor prin program se realizează prin mesaje. Ex. o metoda a obiectului factura este listarea iar mesajul care i se poate transmite prin program la acționarea butonuli Print este listarea.
Clase și subclase de obiecte:
În varianta proiectării orientate obiect (POO) obiectele sunt grupate în clase și subclase de obiecte.
-Clasa de obiecte:
este formată din totalitatea proprietăților și metodelor ce caracterizează o anumită categorie de obiect;
între clase pot exista asemănări datorită unor proprietăți și metode comune;
între clase pot exista deosebiri;
o particularitate a claselor de obiecte o constituie conceptul de moștenire. În momentul creării unui obiect este necesar să se precizeze clasa din care face parte obiectul respectiv pentru ca acesta să poată moșteni:
proprietatile;
metodele, etc.
procesul creării unui obiect este numit instanțiere.
instanțierea este procesul prin care orice obiect creat este o instanță a clasei părinte.
operația de instanțiere este necesară pentru a putea realiza procesul de moștenire a proprietăților, metodelor și valorilor aferente proprietăților.
-Subclasele de obiecte
Sunt definite drept clase derivate dintr-o clasa parinte, care iau nastere dintr-un grup de clase.
Legaturi intre clasele de obiecte:
Legaturile exprimă o relație între două sau mai multe obiecte: asocieri și agregări.
Asocierea:
– se realizează între două sau mai multe obiecte care sunt în mod normal independente, dar adesea pot fi legate între ele;
– poate fi între două sau mai multe obiecte: fără atribute și cu atribute.
Exemplu fără atribute:
– Asociere binară
Exemplu cu atribute:
Agregarea:
Agregarea exprimă legăturile care apar în cazul în care un obiect este compus din alte obiecte. Obiectele componente pot să aibă o existența independentă sau pot exista numai în cadrul agregării. De asemenea, aceleași componente pot apare în mai multe agregări diferite. Agregarea este tranzitivă: un obiect este compus din alte obiecte care, la rândul lor, pot fi compuse.
Exemplu: O factură este compusă din produse facturate și cheltuieli de transport-aprovizionare facturate. Fiecare produs facturat se referă la un produs anumit și precizează cantitatea facturată și prețul de facturare.
Agregare
Asociere
Atribute ale asocierii
Mostenirea, poate fi :
– Moștenire simplă și multiplă
Moștenirea multiplă permite unei clase să aibă mai multe superclase directe și să mosteneasca proprietățile tuturor.
Mostenire multiplă
Clase abstracte :
O clasă abstractă este o clasă care nu are instanțieri directe dar ale căror clase descendente au instanțieri. O clasă concretă(adică instanțiabilă) poate avea subclase abstracte, cu condiția ca acestea să aibă subclase concrete.
Clasele abstracte servesc pentru:
– încapsularea claselor care participă la aceleași asocieri sau agregări;
– definirea metodelor care urmează a fi moștenite de subclase; este posibil să se definească numai semnătura metodei urmând ca implementarea concretă să se facă la nivelul fiecărei subclase.
– Extensie si restricție în moștenire
Extensie: adăugarea într-o subclasa de noi proprietăți, alături de cele moștenite.
Restricție: limitarea valorii pe care obiectele le pot lua pentru atributele moștenite.
Restricții de integritate
Tipologia restricțiilor de integritate din cadrul metodelor sistemice ramâne valabilă și aici.
Metodele orientate obiect introduc anumite notații particulare pentru unele restricții de integritate (RI).
Cardinalitațile: exprimă, în mod implicit, restricții de integritate referitoare la participarea obiectelor la asocieri sau agregări.
2. Modelul dinamic
Modelul dinamic prezintă modificările suportate de obiecte și corelațiile temporale dintre acestea.
Conceptele de bază:
– evenimente
– stări.
• Eveniment:
– un fapt intervenit într-un anumit moment;
– conceptual, un eveniment nu are durată.
Ordine de apariție a evenimentelor poate fi dirijată de legături de cauzalitate. Spre exemplu, plata unei facturi se face numai după recepția mărfurilor facturate.
Două evenimente care nu au nici o influență unul asupra altuia sunt numite concurente, ordinea lor putând fi oarecare.
Starea:
– o abstractizare a valorilor atributelor și a legăturilor unui obiect;
– mulțimile de valori sunt grupate în stări în funcție de proprietățile
care afectează comportamentul ansamblului obiectului;
– reprezintă răspunsul obiectului la evenimentele de intrare.
O stare corespunde intervalului de timp dintre două evenimentente survenite pentru același obiect. O stare are deci o durată. Evenimentele și stările sunt duale: o stare separă două evenimente și un eveniment separă doua stări.
O stare regrupează toate combinațiile de valori ale atributelor și legăturilor care conduc la același răspuns față de un anumit tip de eveniment.
Evenimentele și stările depind de nivelul de abstractizare utilizat.
Legăturile dintre stări și evenimente sunt reprezentate prin diagrame de stare. La apariția unui eveniment starea următoare depinde de starea curentă a obiectului și de evenimentul survenit: schimbarea declanșată este numită tranziție.
Diagrama de stare indică comportamentul unei clase de obiecte. Dar, tot așa cum fiecare obiect are valori proprii ale atributelor, are și stări proprii și deci funcționează independent de celelalte, urmând însa aceeași schemă.
3. Modelul funcțional
Modelul funcțional tratează o altă fațetă a prelucrărilor și anume cea referitoare la modul în care are loc transformarea datelor, în marea majoritate a cazurilor, prin calcule.
Modelul funcțional oferă o imagine a funcționării sistemului compusă din seturi de date care traversează o suită de prelucrări în cursul cărora suferă transformări.
Fiecare suită de asemenea transformări este reprezentată într-o diagramă de flux.
O diagramă de flux se compune din:
prelucrări;
fluxuri de date;
obiecte actor;
obiecte rezervor.
Transformările ce figurează într-o diagramă sunt jalonate de obiecte actor, care marchează proveniența și destinația datelor delimitând astfel punctele de intrare și de ieșire din diagramă. Aceasta face să mai fie denumite și "borne" ale diagramei. Obiectele actor sunt obiecte active, în sensul că dirijează suita de transformări prin producerea sau consumarea de date. Acțiunea lor este exterioară diagramei de flux dar trebuie să figureze în mod normal în modelul dinamic.
Exemplu de diagramă de flux :
GENERARE BALANȚĂ CONTABILĂ
CAPITOLUL III – PROIECTAREA DE DETALIU A NOULUI SISTEM INFORMATIC
3.1 DEFINIREA SISTEMULUI INFORMATIC
Aplicația a fost dezvoltată în limbajul Microsoft Access, care este un limbaj de programare relațional bazat pe baze de date.
Realizarea interactiunii utilizatorilor cu bazele de date din sistemele informatice necesita folosirea unui limbaj (mediu) prietenos ,avand o sintaxa simpla ,denumit limbaj de interogare(QL) .Un astfel de limbaj de interogare include posibilitati pentru consultarea (interogarea) si actualizarea (inserarea ,stergerea si modificarea) datelor din bazele de date. Pentru modelul de date relational ,abordarea folosita consta in incorporarea tuturor acestor posibilitati de exploatare cerute intr-o sintaxa uniforma,in cadrul unui singur limbaj. Standardul cel mai cunoscut al unui astfel de limbaj este SQL .
SQL (Structured Query Language) este folosit frecvent pentru gestiunea bazelor de date organizate structural conform modelului de date relational. Unul dintre motivele popularitatii acestui limbaj consta in faptul ca a fost standardizat de American Standards Institute(ANSI) in anul 1986.La acest motiv se mai poate adauga si faptul ca SQLa fost dezvoltat si comercializat de firma IBM prin anii”70 , ceea ce a i-a asigurat o mare raspandire in gestiunea bazelor de date relatoinale.Principala aplicatie a limbajului SQL efectuata de utilizatori ,consta, dupa cum rezulta din denumirea limbajului ,in interogarea bazelor de date.
Asfel,printr-o singura instructiune SQLse poate construi o interigare care implica o secventa de operatii SELECT, PROJECT si JOIN nefiind necesara o anumita ordine a acestora.Desi forma sintactica de exprimare a unei insructiuni SQL pare a fi imperativa, de fapt instuctiunea este de tip declarativ .Ca urmare, limbajul SQL il scuteste pe un utilizator de necesitatea dezvoltarii unei proceduri (secvente de operatii) de efectuat pentru obtinerea rezultatelor asteptate –tot ceea ce are de realizat utilizatorul este sa specifice informatia de care are nevoie .In consecinta, majoritatea instructiunilor limbajului SQL sunt executabile ,putand fi interpretate si executate imediat in mod interactiv sau putand fi incluse in diferite aplicatii elaborate in diverse limbaje de programare cum sunt limbajele :APL,BASIC,C,COBOL,FORTRAN,PL\I,ASSEMBLER ETC.
Fiind cel mai raspandit sistem de gestiune a bazelor de date relationale, limbajul SQL se poate folosi, indiferent ca utilizatorii sumt creatori de aplicatii , administratorii de baze de date,proiectantii de aplicatii Web sau Microsoft Office,astfel incat cunostiintele dobandite de lucru cu SQL reprezinta o componenta importanta a interactiunii utilizatorilor cu bazele de date relationale si implicit cu SGBD-urile aferente.De asemenea cunoasterea bazelor de date reprezinta o parte importanta a stapanirii limbajului SQL,deoarece exista frecvent confuzii intre termenul de baze de date si programele de baze de date folosite,care,de fapt,se numesc sisteme de gestiune a bazelor de date (SGBD)
Spre deosebire de alte limbaje de programare, SQL este un limbaj alcatuit dintr-un numar foarte redus de cuvinte. Acest numar nu este intamplator, deoarece SQL este proiectat pentru a furniza o modalitate simpla si eficienta de a citi si a scrie baze de date de tip relational .De asemenea,SQL nu este un limbaj “de firma” folositi de anumiti producatori de programe de baze de date.Totusi, se poate afirma ca aproape toate sistemele importante de gestiune a bazelor de date recunosc instructiunile limbajului SQL.In SQL toate instructiunile sunt alcatuite din cuvinte descriptive,reduse ca numar,astfel ca limbajul SQL este usor de invatat.Cu toata aparenta simplitate ,SQL este de fapt un limbaj de programare foarte puternic ,care se poate folosi pentru efectuarea de aplicatii compexe si sofisticate de gestiune a bazelor de date relationale ,prin implicarea eficienta a constructiilor sintactice si semantice ale limbajului.
SQL constituie un standard numai in forma teoretica ,descrisa cu multi ani in urma.Odata cu avansul tehnologic setul de facilitati oferite de SQL a devenit rapid insuficient .Foarte multi producatori de sisteme de gestiune a bazelor de date relatoinale si-au dezvoltat suportul pentru limbajul SQL ,prin adaugarea de de noi extensii ,cu scopul de a furniza functionalitati suplimentare si modalitati simplificate de a efectua anumite operatii. Astfel de extensii sunt specifice unui anumit SGBD si ca urmare ,sunt rareori acceptate de alti producatori de SGBD.
Exista limbajul SQL standard controlat de comisia de standardizare ANSI denumit ANSI SQL .Astfel ,toate sistemele reprezentative de gestiune a bazelor da date relationale, chiar si cele care folosesc extensii proprii ,accepta limbajul standard ANSI SQL ,insa implementarea acestor extensii au nume proprii.Functiile si extensiile SQL nu mai sunt standardizate .Astfel,componenta SQL denumita Limbaj de Definire a Datelor (DDL) a ramas aproape neschimbata ,insa Limbajul de Manipulare a Datelor a suferit modificari substantiale.Metodele cu care datele pot fi prelucrate sunt de o varietate deosebita si nu au putut fi grupate intr-un set de functii comune,fiecare aplicatie avand cerinte specifice .Insa ,SQL reprezenta singura metoda de interogare a bazelor de date ,asfel incat a fost obligatorie implementare mai multor functii si extensii.
Aceste noi functii introduse pentru a satisface cele mai variate cerinte de la simple conversii intre tipuri de date pana la diverse operatii complexe (medii geometrice,logaritmi etc)nu au mai reprezentat un standard.Au inceput prin a fi extensii menite sa completeze limbajul de baza si sa usureze munca utilizatorului ,dar au devenit indispensabile si au fost implemenate de toate sistemele.
Aplicatiile de baze de date sunt mult mai compexe decat alte categorii de aplicatii,deoarece trebuie sa realizeze ,pe de o parte,interfata cu sistemele de gestiune a bazelor de date ,pentru introducerea si extragerea datelor ,iar pe de alta parte interfata cu utilizatorii astfel incat acestia sa poata efectua diverse operatii .
Interfetele cu utilizatorii sunt interfete de tip grafic ,cunoscute sub numele de formulare .Folosind controalele (ferestre cu diferite functionalitati) din formulare ,utilizatorii sunt ghidati sa introduca numai datele necesare ,asfel incat sa se limiteze posibilitatea introducerii unor date eronate.
Rezultatele operatiilor cerute de utilizatori sunt afisate in formulare si pot fi tiparite la dorinta ,sub forma de rapoarte .De exemplu ,o aplicatie de gestiune a stocurilor ofera o interfata grafica utilizatorilor ,prin intermediul careia acestia pot sa introduca in baza de date diferite informatii ;programul calculeaza diferiti indicatori de gestiune (nivelul stocurilor ,dinamica stocurilor etc)si afiseaza sau tipareste rezultatele.
Interfetele grafice cu utilizatorii se pot realiza prin tehnologii software de uz general ,dar multe sisteme de dezvoltare a bazelor de date ofera suport pentru dezvoltarea lor .
SGBD-urile relationale prelucreaza instructiuni SQL ,asfel ca limbajul SQL in standardul definit pana in prezent este un limbaj neprocedural ,care permite definirea datelor si efectuarea de operatii de de gestiune a lor,dar nu are insructiuni de control al ordinii de executie a operatiilor.Deci ,pentru realizarea aplicatiilor de gestiune a bazelor de date au fost dezvoltate diverse limbaje si biblioteci de programe :limbaje procedurale de extensie SQL,limbajul SQL integrat ,biblioteci de functii sau clase pentru comunicarea cu bazele de date.
Un limbaj procedural este o extensie a limbajului SQL si permite combinarea instructiunilor SQL cu instructiuni de control al ordinii de dexecutie.Asfel de limbaje sunt folosite in principal in sistemele de gestiune a datelor pentru stocarea unor proceduri de calcul ,insa exista si posibilitatea ca programele de aplicatii sa transmita sistemului SGBD secvente de instructiuni intr-un limbaj procedural.Transmiterea unei astfel de secvente de instructiuni in locul transmiterii individuale a fiecarei instructiuni SQL ,asigura perfomante de executie a aplicatiilor mai ridicate ,datorita reducerii traficului in retea.
Majoritatea sistemelor de gestiune a datelor relationale sunt prevazute cu cel putin un limbaj procedural,cele mai cunoscute fiind;PL\SQLpentru sistemele de gestiune Oracle ,Transact-SQLpentru sistemele de gestiune Microsoft SQL Server,PL\PGSQL si PL\Pearl pentru sistemul de gestiune PostgreSQL,ETC.
Pentru dezvoltarea programelor de aplicatii cu baze de date se pot aborda doua tehnologii diferite.
Limbajul SQL integrat intr-un limbaj de nivel inalt;
Interfete de programare a aplicatiilor.
In limbajul SQL integrat (Embeded SQL),instrictiunile SQL sunt incluse direct in
codul programului sursa scris intr-un limbaj gazda de nivel inalt .Controlul fluxului de operatii este realizat prin instructiunile limbajului gazda si operatiile cu baza de date prin instructiuni SQL.
Interfetele de programe a aplicatiilor (API-Application Programming Interface) sunt dezvoltate ca biblioteci de functii sau de clase ,iar programele de aplicatie folosesc apelul functiilor din interfata respectiva pentru a comunica cu server-ul bazei de date.Interfetele de programare a aplicatiilor permit dezvoltarea aplicatiilor cu baze de date prin apeluri de functii (call –level interface –CLI)intr-un mod flexibil ,usor de dezvoltat si de intretinut .Interfetele separa programul de aplicatie de biblioteca de acces la baza de date .iar aceasta separare ofera modularitate si independenta mai ridicata a aplicatiilor.
Limbaje procedurale de extensie a limbajului SQL
Un limbaj procedural combina instructiuni ale limbajului SQL cu instructiuni pentru controlul ordinii de executie ,asigurand extinderea posibilitatilor sistemelor de gestiune a bazelor de date.
Limbajele procedurale permit definirea unor variabilelocale, instructiuni de control al ordinii de executie (bucle while ,instructiuni conditionale if ,etc)precum si suport de creare a cursoarelor,a procedurilor stocate, a functiilor definite de utilizator si a declansatorilor(triggere).
Un cursor este o structura care permite memorarea a unei multimi de linii returnate ca rezultat de catre o instructiune de interogare.
Programele de aplicatii nu pot prelucra deodata toate liniile rezultatului si folosesc cursoare pentru extragerea individuala a unei linii din multimea de linii rezultat.In fiecare moment ,intr-un cursor exista o pozitie curenta in multimea de linii rezultat.La fiecare operatie de extragere ,se citesc una sau mai multa linii relativ la pozitia curenta a cursorului ,iar aceasta pozitie se actualizeaza conform modului de parcurgere .Cursoarele permit salvarea,folosirea repetata sau derularea de mai multe ori a liniilor pe care le contin.De asemenea ,cursoarele ofera mai multe posibilitati de control al accesului concurent al mai multor utilizatori la inregistrarile de date din tabelele unei baze de date .
Cursoarele create printr-un limbaj de extensie SQL sunt cursoare la server si pot fi definite in functiile si procedurile stocate din server. In interfetele de programare se pot defini atat cursoare la server cat si cursoare la client. Aceste aspecte pot fi detaliate pentru fiecare limbaj sau interfata in parte. Se considera ca este mai avantajos sa fie folosite cursoare la server decat cursoare la client, deoarece memorarea la client necesita ca intreaga multime de tupluri sa fie transferata dintr-o data de la server la client, chiar daca ulterior, clientul nu va folosi decat o parte din aceasta multime de tupluri pe care le-a primit prin retea si le-a memorat.
A fost preferat limbajul Microsoft access în locul celorlalte limbaje de programare, într-ucât acesta este un limbaj complet, care are în componența sa elemente de persistență (tabele), elemente de exploatare (rapoarte și formulare), posibilitatea scrierii de cod avansat VBA, relaționarea tabelelor, precum și normalizarea acestora, restricționarea utilizatorului în introducerea de date eronate, o interfață cu utilizatorul foarte prietenoasă și usor de dedus.
Pentru construirea aplicației au fost construite tabele care asigură persistența datelor și păstrarea acestora în condiții de siguranță. Prin aceste tabele se salvează automat facturile emise și primite de către societate, firmele partenere, toate operațiunile de casă și de bancă, toți angajații introduși, cursurile valutare, planul de conturi, notele contabile introduse și generate automat de aplicație, toate valutele introduse, județele, orașele, țările.
În cadrul aplicației au fost construite foarte multe interogări pentru obținerea anumitor situații contabile în funcție de perioada aleasă, interogări care afișează cursul valutar dintr-o dată dorită sau toate cursurile existente, interogări pe baza cărora este construită balanța de verificare, precum și jurnalele de vânzări și de cumpărări.
Pentru introducerea datelor au fost construite formulare de introducere, precum și formulare de vizualizare a datelor și de selectare a unei perioade pentru a deschide un raport în funcție de anumite dorințe.
Pentru listarea diferitelor situații, precum și a registrului de casă și al celui de bancă, a balanței de verificare, au fost construite rapoarte.
Limbajul de programare Microsoft Access este un limbaj complex care permite scrierea de cod VBA, cod foarte util pentru realizarea unei aplicații complexe și complete. În cadrul aplicației a fost folosit scris cod VBA pentru validarea și împiedicarea utilizatorului să introducă date eronate, pentru încarcarea tabelelor cu date, pentru construirea balanței de verificare, pentru generarea automată a jurnalelor de cumpărări și de vânzări, pentru închiderea conturilor de venituri și cheltuieli, pentru regularizarea TVA-ului, pentru generarea automată a Registrului Jurnal sintetic și analitic, pentru generare Carte Mare analitică și sintetică, pentru construirea fișei partenerului.
Elemente de originalitate: spre deosebire de celelalte aplicații care există în comerț, eu am construit un modul nou, modul care permite lucrul cu acest program de contabilitate atât a celor care cunosc contabilitate cât și celor care nu cunosc această disciplină. În cadrul panoului de contabilitate am dezvoltat o schemă de contare care se completează de către contabilul șef al unității sau de către o persoană care cunoaște disciplina de contabilitate și operațiile contabile existente în unitatea respectivăș această schemă de contare se completează la începutul lucrului cu această aplicație. O dată dezvoltată această schemă, utilizatorul aplicației nu trebuie să își introducă nota contabilă aferentă unei operațiuni, ci pur și simplu iși alege numele operațiunii și programul va genera automat contarea aferentă acelei tranzacții (Spre exemplu utilizatorul alege operatia contabilă Încasare client, în acest caz programul va genera nota contabilă 5121 = 4111).
Un alt element de originalitate este acela al analiticelor. In cadrul acestei aplicații, utilizatorul nu trebuie să iși definească, spre exemplu pentru conturile de furnizori și clienți analitice (401.1, 401.2), pentru că această aplicație își face singură analiticele , luând contul 401 și denumire firmei respective. În planul de conturi va exista doar contul 401 și analiticele și le face programul singur în funcție de denumire firmei respective.
Un al treilea element de originalitate foarte util utilizatorilor este următorul: în cadrul modulului de casă sau de bancă, dacă utilizatorul lucrează în banca în Euro, spre exemplu, atunci când va alege o categorie de operațiune, aplicația îi va selecta automat contul de euro, nefiind nevoie sa definească în schema de contare două operațiuni cu două conturi de bancă (casă) diferite. Spre exemplu, în schema de contare s-a definit “Incasare client 5121 = 4111”; cand se va alege din casă sau din bancă încasare client și utilizatorul lucrează în banca de euro, aplicația va face automat contarea 5124 (5314)=4111, chiar dacă în schema de contare nu există această operațiune.
Restricții ale aplicației:
La introducerea unei facturi, utilizatorul nu este lăsat să părăsească factura până nu introduce toate elementele obligatorii (Furnizorul, Clientul, Nr. facturii, Data facturii, Cota TVA, Valuta facturii, Persoana care a introdus factura, Detaliile facturii).
Utilizatorului nu îi este permisă introducerea de două ori a aceluiași număr de factură.
Nu se poate părăsi și salva factura dacă nu se introduce cursul valutar aferent zilei din data facturii, în cazul în care factura este într-o alta valută decât cea românească.
Când se introduce o firmă parteneră, utilizatorul este obligat să introducă și codul fiscal al firmei respective, altfel acea firmă se va sterge.
Nu este permis introducerea a două firme cu același nume.
Este obligatoriu ca utilizatorul săa aleagă o categorie de operațiune pentru ca aplicația să genereze automat contarea aferentă acelei operațiuni.
Dacă se introduce ca operațiune încasare client sau plată furnizor, utilizatorul este obligat să își aleagă din listă denumirea acestuia.
Nu este permisă introducerea cursului valutar de două ori în aceeași dată la aceeași monedă (valută).
De asemenea, fișa partenerului se poate consulta și lista doar după introducerea lunii și anului.
În meniul Nomenclator, utilizatorul nu poate introduce de două ori același cont bancar, aceeași bancă, aceeași funcție, același oraș, același județ, aceeași țară, aceeași valută, același tip de document, aceeași cotă TVA, aceeași modalitate de încasare plăți.
Principalele modalități de apelare
Datele firmei vor fi introduse de către programator, din motive de siguranță programatorul introduce Denumirea firmei și codul fiscal, utilizatorul introducând celelalte date în legătură cu firma (adresă, județ, țară, localitate, angajați).
Pentru începerea lucrului cu această aplicație utilizatorul trebuie să introducă nomenclatorul aplicației, necesar pentru preluarea automată de catre aplicație a acestor date din tabelele corespunzătoare, nomenclator care include următoarele elemente:
Introducera planului de conturi.
Adăugarea denumirii și adresa băncilor cu care lucrează societatea.
Introducerea tuturor funcțiilor de încadrare existente în cadrul entității.
Intoducerea țărilor.
Introducerea județelor.
Introducerea orașelor.
Introducerea valutelor cu care lucrează entitatea (obligatoriu de introdus valuta românească).
Introducerea tipurilor de documente utilizate la operațiile prin casă.
Introducerea tipurilor de documente utilizate la operațiile prin bancă.
Introducerea principalelor cote de TVA utilizate de către societate și de către partenerii acesteia.
Introducerea modalităților de încasare/plată.
Principalele functionalitați ale aplicației sunt:
Generarea balanței de materiale
Generarea NIR-ului.
Introducerea datelor
Aplicația dezvoltată este o bază de date și cu ajutorul acestei aplicații utilizatorul poate efectua următoarele operațiuni:
Emiterea facturilor personalizate către clientii săi, aplicația având și posibilitatea poziționării facturilor în pagină in funcție de tipul imprimantei folosite, și al formatului facturilor (A4 sau A5) folosite de către societate;
Înregistrarea facturilor primite de către societate de la furnizorii acesteia;
Introducerea si evidențierea partenerilor de afaceri ai firmei, aplicația oferind posibilitatea de a se introduce toate datele necesare pentru cunoașterea acelei firme; date cum ar fi:
Denumire;
Oraș;
Țară;
Județ;
Cod fiscal;
Numarul de înregistrare in Registrul Comerțului;
Banca;
Contul bancar;
Adresa;
Numerele de telefon;
Faxul;
Adresa WEB;
Persoanele de contact și funcțiile deținute de acestea in cadrul firmei respective;
Diverse observații ;
Introducerea datelor referitoare la firma proprie, date cum ar fi:
Denumire;
Capitalul social al societății;
Oraș;
Țară;
Județ;
Cod fiscal;
Numarul de înregistrare in Registrul Comerțului;
Banca;
Contul bancar;
Adresa;
Numerele de telefon;
Faxul;
Adresa WEB;
Introducerea propriilor angajați și a funcțiilor de încadrare ale acestora;
Introducerea zilnică a cursului valutar, aplicația facând conversia în lei a operațiunilor efectuate în valută si diferențele de curs aferente acestor tranțacții.
Elemente de subincludere: – sunt elementele introduse la inceputul lucrului cu aplicația, elemente introduse în nomenclatorul aplicației.
Principalul element de subincludere, specific contabilității este Schema de contare. Utilizatoru își va defini propria schemă de contare referitoare la tipurile de servicii existente în cadrul facturilor emise, facturilor primite, categoriile de intrare și de ieșire utilizate pentru evidențierea operațiunilor prin casă și prin bancă.
După definirea schemei de contare, la alegerea tipului de servicii aferent modulului în care se lucrează la un moment dat (facturare, casă, bancă), aplicația va face automat contarea acelor servicii.
Explorarea aplicației
Regasirea de informații:
Aplicația dezvoltată este o bază de date, motiv pentru care toate informațiile introduse au fost salvate automat de aplicație și se gasesc sub forma diverselor note contabile generate, note introduse, precum si rapoarte diversificate.
Informațiile referitoare la facturare sunt regăsite atât în modulul de facturare, utilizatorul având posibilitatea să vadă toate facturile emise/primite , utilizatorul are posibilitatea să facă filtre diversificate și utile pentru vizualizarea doar a anumitor facturi, emise într-o perioadă dată, având o anumită valoare, emise către un anumit client sau primite de la un anumit furnizor, precum și multe alte filtre. De asemenea, legat de partea de facturare, utilizatorul poate vedea o fișă a partenerului în funcție de perioada selectată. Facturile emise, precum și cele primite apar și în balanța de verificare, în echivalent lei.
Informațiile din aceste facturi se mai regăsesc și în jurnalul de vânzări facturile emise, precum și în jurnalul de cumpărări facturile primite.
Infomațiile referitoare la firmele partenerilor de afaceri ai întreprinderii sunt regăsite foarte usor, aplicația având un motor de cautare în funcție de denumirea firmei.
Informațiile referitoare la proprii angajați sunt regăsite foarte repede în funcție de numele și funcție deținută.
Informațiile referitoare la cursurile valutare sunt regăsite foarte ușor, aplicația oferă posibilitatea vizualizării cursului valutar dintr-o zi a tuturor valutelor introduse în ziua respectivă, precum și vizualizarea tuturor cursurilor valutare.
Principalele rapoarte specifice oferite de aplicație sunt:
Balanța de materiale.
Nota de recepție și constatare de diferențe.
Facturi emise.
DVI.
3.4. Proiectarea sistemului
Etape ale proiectarii sistemului
Modelarea sistemului se realizeaza in functie de utilizatorii implicati si de aspectele ce urmeaza a fi modelate. Pentru aceasta sunt utilizate vederile UML (View). Acestea surprind aspecte particulare ale sistemului de modelat. Un view este o abstractizare a sistemului, iar pentru construirea lui se folosesc anumite diagrame.
Un sistem poate fi descris luând în considerare diferite aspecte:
Funcțional: este descrisă structura statică și comportamentul dinamic al sistemului;
Non-funcțional: necesarul de timp pentru dezvoltarea sistemului
Din punct de vedere organizatoric: organizarea lucrului, maparea modulelor de cod;
Așadar pentru descrierea unui sistem sunt necesare un număr de view-uri, fiecare reprezentând o proiecție a descrierii intregului sistem și care reflectă un anumuit aspect al sau. Fiecare view este descris folosind un număr de diagrame care conțin informații relative la un anumit aspect particular al sistemului. Aceste view-uri se completeaza, deci este posibil ca o anumită diagramă să facă parte din mai multe view-uri.
View-ul cazurilor de utilizare (Use-case View) – Acest view surprinde funcționalitatea sistemului, așa cum este ea percepută de actorii externi care interacționează cu sistemul, de exemplu utilizatorii acestuia sau alte sisteme. În componența lui intră diagrame ale cazurilor de utilizare și ocazional, diagrame de activitate.
Cei interesați de acest view sunt deopotrivă clienții, designerii, dezvoltatorii dar și cei care vor realiza testarea și validarea sistemului.
View-ul logic (Logic View) – Spre deosebire de view-ul cazurilor de utilizare, un view logic “privește” înăuntrul sistemului și descrie atât structura internă a acestuia (clase, obiecte și relații) cât și colaborările care apar când obiectele trimit unul altuia mesaje pentru a realiza funcționalitatea dorită.
Structura statică este descrisă în diagrame de clasă, în timp ce pentru modelarea dinamicii sistemului se vor folosi diagramele de stare, de secventă, de colaborare sau de activitate. Prin urmare, cei care sunt interesați de acest tip de vizualizare a sistemului sunt designerii și dezvoltatorii.
View-ul componentelor (Component View) – Componentele sunt module de cod de diferite tipuri. În funcție de conținutul lor acestea pot fi: componente care conțin cod sursă, componente binare sau excutabile.
View-ul componentelor are rolul de a descrie componentele implementate de sistem și dependențele ce există între ele, precum și resursele alocate acestora și eventual alte informații administrative, cum ar fi de exemplu un desfașurător al muncii de dezvoltare. Este folosit în special de dezvoltatorii sistemului, iar în componența sa intră diagrame ale componentelor.
View-ul de concurență (Concurent View) – Sistemul poate fi construit astfel încât să ruleze pe mai multe procesoare. Acest aspect, care este unul nonfuncțional, este util pentru o gestionare eficientă a resurselor, execuții paralele și tratări asincrone ale unor evenimente din sistem, precum și pentru rezolvarea unor probleme legate de comunicarea și sincronizarea theadu-urilor.
Cei care sunt interesați de o astfel de vizualizare a sistemului sunt dezvoltatorii și integratorii de sistem, iar pentru construirea lui se folosesc diagrame dinamice (stare, secventă, colaborare și activitate) și diagrame de implementare (ale componentelor sau de desfășurare).
View-ul de desfăsurare (Deployment View) – Desfășurarea fizică a sistemului, ce calculatoare și ce device-uri (numite și noduri) vor fi folosite pentru realizarea efectivă a implementării, cum sunt acestea conectate, precum și ce componente se vor executa pe fiecare nod (de exemplu ce program sau obiect este executat pe fiecare calculator), toate sunt surprinse în view-ul de desfășurare.
Aceast tip de vizualizare a sistemului prezintă interes sunt dezvoltatori, integratorii de sistem și cei care realizează testarea sistemului, iar pentru construirea view-ului este folosită diagrama de desfășurare.
Modelarea se realizează ținând cont de componenetle sistemului modelat. Astfel sunt identificate trei pachete principale de componete:
Business Services – modelează soluția sistemului, clasele de bază și interacțiunea dintre acestea.
User Services – modelează componenetele legate de interfața sistemului cu utilizatorul, dar și elementele de interfața dintre anumite subsisteme.
Data Services – modelează serviciile legate de accesul la bazele de date: atât cele multidimensionale cât și cele relaționale.
Etape urmărite în modelarea sistemului sunt aceleași cu etapele modelării sistemelor tranzacționale:
Specificarea cerintelor – descrierea cerintelor functionale si nefunctionale
Analiza
Modelarea cazurilor de utilizare – se realizeaza diagrama Use Case generala si descrierea cazurilor de utilizare
Analiza domeniului claselor
Static:
– diagrama claselor: sunt schitate clasele din domeniul Business (al aplicatiei) fara atribute si operatii
– pentru clasele care au un comportament dinamic se realizeaza diagrama de stare
Dinamic- se realizeaza (optional) pentru domeniul Business (al aplicatiei):
– Diagrama de activitati
– Diagrama de colaborare
– Diagrama de secventa
Proiectarea
Construierea solutiei – Use Case detaliate
Proiectarea arhitecturala – se identifica principalele pachete ale aplicatiei, se grupeaza clasele in pachete si se realizeaza diagrama de pachete
Proiectarea detaliata
Static:
– diagrama claselor: clasele din domeniul Business (al aplicatiei) cu specificarea atributelor si operatiilor
– optional: diagrama claselor din domeniile User (interfata) si Data (accesul la BD)
– pentru clasele care au un comportament dinamic se realizeaza diagrama de stare
Dinamic – se realizeaza integrand elementele din Business (aplicatie), User (interfata) si Data (accesul la BD):
– Diagrama de colaborare
– Diagrama de secventa
Proiectarea interfetei cu utilizatorul – se detaliaza diagrama claselor din User Services (interfata).
Implementarea – diagrama componentelor
Desfasurarea – diagrama de desfasurare
Principiul de lucru: împărțirea sistemului în subsisteme pe baza funcțiilor sistemului (abordarea funcțională) sau în funcție de date (abordarea bazată pe date).
Punctul de plecare: programarea structurată
Analiza și proiectarea structurată sunt realizate pornind de la:
– o abordare funcțională (pornind de la prelucrările pe care le suferă datele)
– o abordare bazată pe date (de la structura datelor utilizate în sistem și de la relațiile care există între acestea)
metodologiile propun modelarea datelor separat de modelarea procedurilor (funcțiile sunt active).
Sistemul nu este izolat, reacționează la evenimentele transmise din mediu printr-un răspuns, dar nu controlează mediul.
Punctul de plecare în analiză: stabilirea graniței între sistem și mediu și modul de interacțiune între ele=> MODELUL MEDIULUI.
Sistemul = colecție de procese (transformări) care acceptă date din afara sistemului (evenimente) și le transformă în date interne pe care le stochează sau le transformă mai departe în date de ieșire (răspunsuri).
Sistemul este structurat după diverse criterii în subsisteme până la nivel elementar, punându-se în evidență relațiile dintre ele
Abordarea acestor subsisteme se face din punct de vedere: static, funcțional și dinamic.
În final rezultă, atât pentru sistemul existent, cât și pentru sistemul proiectat:
Modelul fizic – reflectă structura tehnică și operațională a sistemului. Descrie CUM funcționează sistemul într-o anumită implementare.
Modelul logic – arată CE face sistemul, fiind mai stabil în timp și independent de implementare.
Avantajele proiectarii:
– utilizarea reprezentării grafice, la îndemâna atât a analiștilor, cât și a beneficiarilor;
– planificarea eficace a proiectului prin divizarea în subsisteme => un mediul bine structurat, flexibil din punct de vedere al comportamentului, are obiective clare, o arie de cuprindere cunoscută;
– posibilitatea reducerii timpului și a costului de dezvoltare a sistemului prin luarea în considerare de la început a detaliilor, prin interacțiunea continuă cu beneficiarul;
modificarea unei anumite activități a sistemului nu conduce la reluarea integrală a studiului.
Exemple de metodologii structurate
Structured Analysis and Design Information Systems (STRADIS) [1979]
Yourdon Systems Method (YSM) [1993]
Information Engineering (IE) [1989]
Structured System Analysis and Design Methodology (SSADM) [ 1982]
MERISE – elaborată de Institutul de Cercetări în Informatică
Jackson System Development (JSD) [1988]
Information System Work and Analysis of Changes (ISAC) [1982]
Effective Techical and Human Implementation of Computer-based Systems (ETHICS) [1995]
Soft System Methodology (SSM) [1990]
Multiview [1990]
Process Innovation [1993]
Rapid Application Development (RAD) [1991]
AXIAL – elaborată de firma IBM, Franța
SSADM (Structured System Analysis and Design Methodology)
realizată la cererea Guvernului Marii Britanii, în 1982, cu scopul dezvoltării sistemelor informaționale de către departamentele guvernamentale.
cea mai larg folosită metodologie în Marea Britanie, precum și în alte țări. Metodologia e evoluat în timp prin modificarea tehnicilor utilizate.
SSADM include un set de tehnici, instrumente și formulare standard pentru descrierea sistemului existent sau a sistemului proiectat (noul sistem).
Pentru prezentarea sistemului se utilizează o documentație complexă.
Caracteristici generale:
metodologie orientată pe structura datelor
două tipuri de modele: modelul logic și modelul fizic al sistemului, deci separă întru-totul proiectarea logică de proiectarea fizică
se bazează pe specificarea clară a cerințelor și a unor reguli detaliate pentru construirea (proiectarea) celor două modele
reprezentarea fluxurilor de date și prelucrărilor cu ajutorul diagramelor
Module-etape-pasi
Modulul 0: Studiul de fezabilitate
Determină posibilitatea realizării proiectului cu determinarea încadrării în timp și buget, a gradului de acceptare de către organizație.
Opțional, de multe ori înlocuit cu un studiu de planificare a realizării sistemului informațional.
Pentru planificare SSADM folosește tehnicile:
definirea cerințelor,
diagramele de flux a datelor,
structura logică a datelor.
Rezultatul etapei: documentul Studiu de fezabilitate.
Modulul 1 Analiza cerințelor
se identifică ce face și ce ar trebui să facă sistemul.
analiza sistemului existent cu determinarea direcțiilor de perfecționare.
beneficiarii sunt parte activă în această fază
sistemul existent este investigat doar pentru a facilita realizarea noului sistem
Etapa 1. Investigarea
Analistul să înțeleagă modul de funcționare a sistemului, cu identificarea exactă a granițelor sistemului
Punct de plecare: vechiul sistem, in implementarea curenta
Studiu complex privind:
activitățile și fluxurile informaționale existente,
volumul informațiilor prelucrate și
aria de cuprindere a sistemului informațional.
Analiza sistemul existent
Investigarea sistemului existent
Construirea modelului fizic al sistemului existent
Construirea modelului fizic al prelucrărilor
Construirea modelului fizic al datelor
Construirea modelului logic al sistemului existent
Construirea modelului logic al prelucrărilor
Documentație întocmita:
Prezentarea unității (Profilul unității);
Cadru organizatoric;
Activitatea de desfacere;
Conducerea activității de desfacere;
Modelul fizic al sistemului existent;
Modelul logic al sistemului existent;
Diagramele de flux de date
Modelul proceselor, o reprezentare grafică a transformării datelor de intrare în date de iesire
TOP-DOWN
identifica toate funcțiunile existente ale sistemului
nivelul 0 îl constituie DIAGRAMA CONTEXTUALĂ, care definește granițele între sistemul analizat și mediu
Elaborarea diagramelor de flux a datelor pentru sistemul existent.
Se întocmește o listă a documentelor fizice implicate.
Se trasează o diagramă a fluxurilor de documente, cu verificarea completitudinii.
Se elaboreaza primul nivel a DFD prin enumerand procesele pentru fiecare document
Următoarele niveluri ale DFD se realizează prin detalierea proceselor.
Intocmirea modelului datelor pentru sistemul existent, modelul entitate-asociere (identifica entitatile si relatiile dintre ele, indepndent de procese)
Modelul logic
pune clar in evidenta CE? face sistemul eliminand detaliile care arata CUM? functioneaza sistemul in implementarea actuala.
pune in evidenta functiunile de baza ale sistemului si permite identificarea problemelor legate de redundanta datelor si duplicarea proceselor de prelucrare.
scoaterea in afara granitelor a proceselor manuale care nu pot fi automatizate, inlaturarea referintelor fizice si temporare, identificarea stocurilor, proceselor si fluxurilor logice,
Procesul de derivare a DFD logice incepe de la ultimul nivel de descompunere si continua la niv. superior
direcții de perfecționare și modernizare ale sistemului curent
Rezultatul etapei : reprezentarea fizica si logică a sistemului existent, cu identificarea funcțiilor ce vor fi preluate în noul sistem.
Etapa 2. Opțiunile sistemului economic
se identifică opțiunile (variantele) de organizare a noului sistem, pentru ca acesta să îndeplinească toate cerințele beneficiarului.
selectia din punct de vedere al mai multor criterii timp,
resurse materiale,
resurse umane și
resurse financiare
Rezultatul etapei: opțiunea sistemului cea mai avantajoasă economic
Modulul2. Specificarea cerințelor
Etapa 3. Definirea cerințelor
detalierea cerințelor deja formulate pentru opțiunea aleasă în cadrul etapei anterioare.
asigură tranziția între etapa de analiză și cea de proiectare.
etapa începe cu identificarea variantelor de realizare
Fiecare varianta intocmita va contine:
Descrierea sistemului (cerinte functionale, nefunctionale)
Analiza cost-beneficiu (durata-max 5 ani, cost, beneficiu)
Analiza impactului introducerii SI (struct. organiz, instruire)
Pași
se înlătură deficiențele din organizarea sistemului existent,
se construiește un model al sistemului prin modificarea DFD logice și a structurii logice a datelor.
se construiește un catalog al funcțiunilor și o descriere a entităților.
Rezultat:
catalogul cerințelor și
noul model al sistemului: DFD modificate și evoluția în timp a entităților identificate în sistem (modelul dinamic).
Noul sistem poate fi o îmbunătățire a sistemului existent, dar poate fi și o abordare nouă.
Modulul 3. Specificarea sistemului logic
Etapa 4.Opțiunile tehnice ale sistemului
Având toate datele necesare, furnizate de etapele anterioare, se pot identifica și detalia opțiunile tehnice de realizare a sistemului informatic.
Se vor identifica detaliile tehnice, precum și modul de funcționare a sistemului în cazul alegerii fiecăreia dintre opțiuni.
Se realizează o analiză cost beneficiu care duce la alegerea uneia dintre opțiuni.
Rezultatul etapei: opțiunea tehnică selectată, detaliată.
detalii tehnice referitoare la hardware și software,
modul de lucru al sistemului,
costurile implicate,
trăsăturile semnificative ale etapei de proiectare.
informații privind posibilitatea de perfecționare, întreținere și dezvoltare a sistemului.
Etapa 5. Proiectarea logică
Specificațiile au fost detaliate în etapa 3.
Dupa aprobare, se va realiza o proiectare logică de detaliu a noului sistem, pentru a se evidenția funcționarea acestuia => model logic detaliat:
proiectarea datelor, utilizând tehnica normalizării entităților bazei informaționale (modelul entit-asoc pt noul sistem si descrierea detaliata a entitatilor)
proiectarea procedurilor, elaborând mai multe schițe detaliate ale proceselor (DFD logic pt noul sistem)
Proiectarea datelor și a procedurilor se realizează în paralel și interacționează permanent.
Rezultatul etapei: proiectarea logică de detaliu a noului sistem.
Modulul 4. Proiectarea fizică
Proiectarea logică de detaliu este convertită într-un proiect tehnic, pentru a realiza compatibilizarea cu echipamentele și software-ul selectat.
Specificatiile de programare trebuie sa contina:
logica aplicatiei (schema de apel a modulelor aplicatiei);
modul de organizare a datelor utilizate de aplicatie (sistem de fisier / BD);
pentru fiecare procedura / functie trebuie specificate : datele de intrare, datele de iesire, algoritul de transformare a datelor de I/ in date de /E.
Activitatile pe care le vom parcurge in aceasta etapa sunt:
Proiectarea iesirilor sistemului
Proiectarea sistemului de codificare a datelor
Proiectarea intrarilor sistemului
Proiectarea BD (conceptuala, logica, fizica)
Proiectarea interfetei cu utilizatorul (meniuri si/sau forme)
Proiectarea functiilor (pseudocod sau diagrame Jackson)
presupune realizarea modelului fizic al datelor și al proceselor, precum și elaborarea programelor.
La sfârșitul etapei
se redactează programul de dezvoltare și planurile de testare,
se specifică instrucțiunile de operare, procedurile manuale
se realizează specificațiile detaliate ale produsului program.
Avantaje SSADM
Prezintă o abordare simplă a problemelor prin viziunea utilizatorului;
Oferă flexibilitate mare în analiză și proiectare;
Permite implementarea ușoară a sistemului;
Documentația de sistem este extrem de sugestivă, completă și este aproape în întregime redată sub formă grafică.
CAPITOLUL IV – PREZENTAREA MEDIULUI DE GESTIUNE A DATELOR MICROSOFT ACCESS SQL
Mediul Access SQL diferă, in unele aspecte, de standardul ANSI SQL in sensul ca, pe de o parte, contine instructiuni legate de securitate si acces concurent (COMMIT, GRANT, LOCK) sau instructiuni DDL (Data Definition Language) pentru definirea datelor si, pe de alta parte, include instrucțiunea TRANSFORM si declarația PARAMETERS. Incepând cu versiunea 2000, mediul Micrososft Access accepta folosirea limbajului de interogare SQL.
Caracteristici definitorii și posibilități de exploatare ale mediului Access SQL
Mediul Access SQL oferă utilizatorilor posibilitatea de a folosi instrucțiuni în diferite situații, ca de exempluȘ
Înlocuirea unor interogări ale bazei de date Access cu instrucțiunea SELECT, simplificând gestiunea bazei de date, în sensul că va conține mai puține obiecte, însă micșorând viteza de regăsire a datelorș
Crearea unor tipuri de interogare a bazei de date Access, prin folosirea numai a instrucțiunilor SQL (interogări de tip UNION).
Pentru editarea corectă a instrucțiunilor Access SQL incepând cu versiunea Access 2000 este necesar sa se respecte strict unele reguli de sintaxă:
fiecare instrucțiune trebuie sa se termine cu caracterul punct si virgulă (;);
la crearea unei interogări, în care se folosesc câmpuri de date din mai multe tabele ale bazei de date, pentru a separa numele tabelului de numele câmpului de date este necesar să se folosească caracterul punct (.);
pentru a delimita parametrii trebuie folosită virgula (,)ș
pentru a marca datele de tip caracter trebuie incadrate între doua caractere apostrof (‘) sa ghilimele (“);
pentru specificarea inegalitatilor din cadrul clauzelor trebuie folosite doua paranteze ascutite (<>).
Pentru a pune in evidenta sirurile de tip data calendaristica si de timp se foloseste caracterul “#”;
Pentru a incadra numele de campuri de date, atunci cand contin spatii sau simboluri neacceptate de SQL, trebuie folosite parantezele drepte ([]).
In literatura de specialitate se cunosc se cunosc trei metode de baza referitoare la implementarea limbajului SQL:
prin apelare directa (Direct Invocation), care consta in introducerea instructiunilor in prezenta promter-ului sistem;
de tip modular (Module Language), metoda care foloseste anumite proceduri apelate de programele aplicatiilor;
de tip incapsulat (Embeded SQL), metoda care foloseste numai instructiuni incapsulate in codul de program, fiind de tip static si dinamic.
CAPITOLUL V – GESTIUNEA BAZEI DE DATE A SISTEMULUI INFORMATIONAL PROPUS MICROSOFT ACCESS SQL
5.1 Studiu de caz:
Se considera o aplicatie Microsoft ACCESS SQL pentru evidenta importurilor / exporturilor intr-o firma de comert exterior:
Descrierea continutului si destinatia tabelelor
Tabelul Firme contine clientii carora li se emit facturi. In tabel fiecare client are o inregistrare, iar campul de date care contine toti identificatorii unici (Firma_ID) este folosit pentru stabilirea relatiilor dintre clienti si produse.
Tabelul FacturiPrimite contine facturile primite de la furnizori. In tabel fiecare factura are o inregistrare, iar campul de date care contine toate facturile unice (FacturaPrimita_ID) este folosit pentru stabilirea relatiilor cu detaliile facturii, produsele primite de la furnizori.
Tabelul FacturiPrimiteDetalii contine detaliile facturilor primite de la furnizori. In tabel fiecare detaliu de factura are o inregistrare, iar campul de date care contine toate facturile unice (FacturaPrimitaDetalii_ID) este folosit pentru stabilirea relatiilor cu factura.
Tabelul Cursul_Valutar contine istoricul cursurilor valutare avand un identificator unic (CursValutar_ID).
Tabelul Firme_Persoane_Contact contine informatiile referitoare la toate persoanele de contact ale firmelor avand un identificator unic (PersoaneContact_ID).
Tabelul Lista_Banci contine informatiile referitoare la bancile firmei proprii cu identificatorul unic (Banca_ID).
Proiectarea structurii tabelelor din baza de date
Crearea tabelelor prezentate mai sus s-au creat astfel:
Creare tabela Firme
CREATE TABLE Firme
(
Firma_ID NOT NULL Primary KEY,
FirmaTara_ID Number NOT NULL,
FirmaOras_ID Number NOT NULL,
FirmaJudet_ID Number NOT NULL,
FirmaNume CHAR(20) NOT NULL,
FirmaProprie YES/NO NULL,
FirmaImportanta YES/NO NULL,
FirmaFormaJuridica CHAR(5) NULL,
FirmaCodFiscal CHAR(20) NULL,
FirmaRegistruComert CHAR(20) NULL,
FirmaAdresaStrada CHAR(40) NULL,
FirmaAdresaNumar CHAR(5) NULL,
FirmaAdresaDetalii CHAR(200) NULL,
FirmaTelefon1 CHAR(20) NULL,
FirmaTelefon2 CHAR(20) NULL,
FirmaFax CHAR(20) NULL,
FirmaCodPostal CHAR(20) NULL,
FirmaEmail CHAR(20) NULL,
FirmaWeb CHAR(20) NULL,
FirmaCont CHAR(20) NULL,
FirmaBanca CHAR(20) NULL,
FirmaObservatii CHAR(200) NULL,
FirmaAnulare YES/NO NULL,
CapitalSocialFirma NUMBER NULL,
DataIntroduceriiFirma Date/Time NOT NULL,
PersoanaIntroducereFirma_ID Number NOT NULL
);
Creare tabela FacturiPrimite
CREATE TABLE FacturiPrimite
(
FacturaPrimita_ID NOT NULL Primary KEY,
CumparatorFCaraus_ID Number NOT NULL,
FurnizorFCaraus_ID Number NOT NULL,
ValutaFCaraus_ID Number NOT NULL,
NumarFCaraus Number NOT NULL,
DataFCaraus Date/Time NOT NULL,
TVAFCaraus Number NOT NULL,
TotalValFCaraus Number NOT NULL,
TotalValTVAFCaraus Number NOT NULL,
TotalFCaraus Number NOT NULL,
DataIntrareFCaraus Date/Time NOT NULL,
DataIntrareCMR_Aviz Date/Time NOT NULL,
TermenDePlataFCaraus Number NOT NULL,
PlatitaFact Yes/No NULL,
ObservatiiFCaraus CHAR(100) NULL,
RestPlataFCaraus Number NULL,
PersoanaIntocmireFCaraus CHAR(20) NULL,
DataPlatiiIntegraleFCaraus Date/Time NULL,
TotalTVALeiFCaraus Number NOT NULL,
TotalFactLeiFCaraus Number NOT NULL,
DataIntroduceriiFCaraus Date/Time NOT NULL,
OraIntroduceriiFCaraus Date/Time NOT NULL
CursValFCaraus Number NOT NULL
);
Creare tabela FacturiPrimiteDetalii
CREATE TABLE FacturiPrimiteDetalii
(
FacturaPrimitaDetalii_ID NOT NULL Primary KEY,
FacturaServFCDetalii_ID Number NOT NULL,
ServiciuFCDetalii CHAR(200) NULL,
CantitateServFCDetalii Number NOT NULL,
PretServFCDetalii Number NOT NULL,
ValoareaServFCDetalii Number NOT NULL,
ValoareaTVAServFCDetalii
TVAFCarausLinie_ID Number NOT NULL
);
Creare tabela CursValutar
CREATE TABLE CursValutar
(
CursValutar_ID NOT NULL Primary KEY,
ValutaCurs_ID Number NOT NULL,
DataCursValutar Date/Time NOT NULL,
CursValutar Number NOT NULL
);
Creare tabela PersoaneContact
CREATE TABLE PersoaneContact
(
PersoaneContact_ID NOT NULL Primary KEY,
FirmaPC_ID ID Number NOT NULL,
FunctiePC_ID ID Number NOT NULL,
NumePC CHAR (20) NOT NULL,
SexPC CHAR (1) NOT NULL,
TelefonPC CHAR (20) NULL
);
Creare tabela Banci
CREATE TABLE Banci
(
Banca_ID NOT NULL Primary KEY,
Banca CHAR (20) NOT NULL,
AdresaBanca CHAR (120) NOT NULL,
);
Dupa executarea instructiunii CREATE TABLE, pentru fiecare din cele sase tabele, structura creata se poate vizualiza selectand in fereastra Database grupul de obiecte Tables, apoi pe rand numele fiecarui tabel. Structura tabelului selectat se poate vizualiza prin actionarea butonuluiDesign.
Tabela Firme
Tabela FacturiPrimite
Tabele Facturi primite detalii
Tabela Cursul Valutar
Tabela Persoane de contact
Tabela Banci
Stabilirea relatiilor dintre tabelele bazei de date
Selectarea unor inregistrari din tabelele bazei de date, folosind instructiunea SELECT cu diverse clauze (FROM, WHERE, etc.):
Regasirea si afisarea tuturor inregistrarilor din tabela Firme
SELECT
Firme.Firma_ID, Firme.FirmaTara_ID, Firme.FirmaOras_ID, Firme.FirmaJudet_ID, Firme.FirmaNume, Firme.FirmaProprie, Firme.FirmaImportanta, Firme.FirmaFormaJuridica, Firme.FirmaCodFiscal, Firme.FirmaRegistruComert, Firme.FirmaAdresaStrada, Firme.FirmaAdresaNumar, Firme.FirmaAdresaDetalii, Firme.FirmaTelefon1, Firme.FirmaTelefon2, Firme.FirmaFax, Firme.FirmaCodPostal, Firme.FirmaEmail, Firme.FirmaWeb, Firme.FirmaCont, Firme.FirmaBanca, Firme.FirmaDestinatii, Firme.FirmaObservatii, Firme.FirmaAnulare, Firme.CapitalSocialFirma, Firme.DataIntroduceriiFirma, Firme.PersoanaIntroducereFirma_ID
FROM
Firme;
Regasirea si afisarea tuturor Facturilor si detaliile acestora
SELECT
Facturi_Carausi.FacturaCaraus_ID, Facturi_Carausi.CumparatorFCaraus_ID, Facturi_Carausi.FurnizorFCaraus_ID, Facturi_Carausi.ValutaFCaraus_ID, Facturi_Carausi.NumarFCaraus, Facturi_Carausi.DataFCaraus, Facturi_Carausi.TVAFCaraus, Facturi_Carausi.TotalValFCaraus, Facturi_Carausi.TotalValTVAFCaraus, Facturi_Carausi.TotalFCaraus, Facturi_Carausi_Detalii.ServiciuFCDetalii_ID, Facturi_Carausi_Detalii.FacturaServFCDetalii_ID, Facturi_Carausi_Detalii.FacturaServPartidaFCDetali_ID, Facturi_Carausi_Detalii.ServiciuFCDetalii, Facturi_Carausi_Detalii.CantitateServFCDetalii, Facturi_Carausi_Detalii.PretServFCDetalii, Facturi_Carausi_Detalii.ValoareaServFCDetalii, Facturi_Carausi_Detalii.ValoareaTVAServFCDetalii, Facturi_Carausi_Detalii.ContDebitFCDetalii_ID, Facturi_Carausi_Detalii.ContCreditFCDetalii_ID, Facturi_Carausi_Detalii.ValoareServEUR, Facturi_Carausi_Detalii.ValoareTVAServEUR, Facturi_Carausi_Detalii.IncadrareServ_ID, Facturi_Carausi_Detalii.TVAFCarausLinie_ID, Facturi_Carausi.DataIntrareFCaraus, Facturi_Carausi.DataIntrareCMR_Aviz, Facturi_Carausi.TermenDePlataFCaraus, Facturi_Carausi.PlatitaFact, Facturi_Carausi.ObservatiiFCaraus, Facturi_Carausi.FacturaDeLaCaraus, Facturi_Carausi.RestPlataFCaraus, Facturi_Carausi.PersoanaIntocmireFCaraus, Facturi_Carausi.RestTrPlataFCaraus, Facturi_Carausi.DataPlatiiIntegraleFCaraus, Facturi_Carausi.BazaDeImpozitareLeiFCaraus, Facturi_Carausi.TotalTVALeiFCaraus, Facturi_Carausi.TotalFactLeiFCaraus, Facturi_Carausi.RestEur, Facturi_Carausi.ScadentaFact, Facturi_Carausi.NuCashFlowFC, Facturi_Carausi.DataIntroduceriiFCaraus, Facturi_Carausi.OraIntroduceriiFCaraus, Facturi_Carausi.NuInJurnalFCaraus, Facturi_Carausi.CursValFCaraus, Facturi_Carausi.BlocareFCaraus, Facturi_Carausi.SumaAchitataFCaraus, Facturi_Carausi.CompensareFCaraus, Facturi_Carausi.NuInManagementFCaraus, Facturi_Carausi.SoldInitialFCaraus, Facturi_Carausi.BalantaEmisaFCaraus, Facturi_Carausi.RulajAnteriorFCaraus, Facturi_Carausi.SumaDorita, Facturi_Carausi.ValutaDorita, Facturi_Carausi.CursulDorit, Facturi_Carausi.DiferentaDeCurs
FROM
Facturi_Carausi INNER JOIN Facturi_Carausi_Detalii ON Facturi_Carausi.FacturaCaraus_ID = Facturi_Carausi_Detalii.FacturaServFCDetalii_ID;
Selectarea cursului valutar dintr-o anumita data
SELECT
Cursul_Valutar.DataCursValutar, Cursul_Valutar.CursValutar, Cursul_Valutar.ValutaCurs_ID
FROM
Cursul_Valutar
WHERE
(((Cursul_Valutar.DataCursValutar)=[Forms]![Curs_Valutar_Data]![Data]));
Afisarea cursului valutar pe valute si pe date
TRANSFORM
Max(Cursul_Valutar.CursValutar) AS MaxOfCursValutar
SELECT
Cursul_Valutar.DataCursValutar
FROM
Lista_Valute INNER JOIN Cursul_Valutar ON Lista_Valute.Valuta_ID = Cursul_Valutar.ValutaCurs_ID
GROUP BY
Cursul_Valutar.DataCursValutar
ORDER BY
Cursul_Valutar.DataCursValutar DESC
PIVOT
Lista_Valute.Valuta;
Afisarea produselor achizitionate grupate pe furnizori
TRANSFORM Sum(Facturi_Carausi.TotalFCaraus) AS SumOfTotalFCaraus
SELECT Firme.FirmaNume
FROM Firme INNER JOIN ((Facturi_Carausi INNER JOIN Facturi_Carausi_Detalii ON Facturi_Carausi.FacturaCaraus_ID = Facturi_Carausi_Detalii.FacturaServFCDetalii_ID) INNER JOIN Lista_Servicii_Facturi ON Facturi_Carausi_Detalii.ServiciuFCDetalii_ID = Lista_Servicii_Facturi.Articol_ID) ON Firme.Firma_ID = Facturi_Carausi.FurnizorFCaraus_ID
GROUP BY Firme.FirmaNume
PIVOT Lista_Servicii_Facturi.DenumireArticol;
Afisarea produselor vandute grupate pe clienti
TRANSFORM Sum(Facturi_Emise_Detalii.ValoareaServ) AS SumOfValoareaServ
SELECT Firme.FirmaNume
FROM ((Firme INNER JOIN Facturi_Emise ON Firme.Firma_ID = Facturi_Emise.CumparatorFact_ID) INNER JOIN Facturi_Emise_Detalii ON Facturi_Emise.Factura_ID = Facturi_Emise_Detalii.FacturaServ_ID) INNER JOIN Lista_Servicii_Facturi ON Facturi_Emise_Detalii.Serviciu_ID = Lista_Servicii_Facturi.Articol_ID
GROUP BY Firme.FirmaNume
PIVOT Lista_Servicii_Facturi.DenumireArticol;
Indicatorii eficientei
Vanzari
SELECT Firme.FirmaNume, Sum(Facturi_Emise_Detalii.ValoareaServ) AS SumOfValoareaServ
FROM (Firme INNER JOIN Facturi_Emise ON Firme.Firma_ID = Facturi_Emise.CumparatorFact_ID) INNER JOIN Facturi_Emise_Detalii ON Facturi_Emise.Factura_ID = Facturi_Emise_Detalii.FacturaServ_ID
GROUP BY Firme.FirmaNume;
Cumparari
SELECT Firme.FirmaNume, Sum(Facturi_Carausi_Detalii.ValoareaServFCDetalii) AS Valoare
FROM (Firme INNER JOIN Facturi_Carausi ON Firme.Firma_ID = Facturi_Carausi.FurnizorFCaraus_ID) INNER JOIN Facturi_Carausi_Detalii ON Facturi_Carausi.FacturaCaraus_ID = Facturi_Carausi_Detalii.FacturaServFCDetalii_ID
GROUP BY Firme.FirmaNume;
Furnizori – Produse
SELECT Firme.FirmaNume, Facturi_Carausi_Detalii.ServiciuFCDetalii, Facturi_Carausi_Detalii.CantitateServFCDetalii, Facturi_Carausi_Detalii.ValoareaServFCDetalii
FROM (Firme INNER JOIN Facturi_Carausi ON Firme.Firma_ID = Facturi_Carausi.FurnizorFCaraus_ID) INNER JOIN Facturi_Carausi_Detalii ON Facturi_Carausi.FacturaCaraus_ID = Facturi_Carausi_Detalii.FacturaServFCDetalii_ID
GROUP BY Firme.FirmaNume, Facturi_Carausi_Detalii.ServiciuFCDetalii, Facturi_Carausi_Detalii.CantitateServFCDetalii, Facturi_Carausi_Detalii.ValoareaServFCDetalii;
Distributie
SELECT Firme.FirmaNume, Facturi_Emise_Detalii.Serviciu, Facturi_Emise_Detalii.CantitateServ, Facturi_Emise_Detalii.ValoareaServ
FROM Firme INNER JOIN (Facturi_Emise INNER JOIN Facturi_Emise_Detalii ON Facturi_Emise.Factura_ID = Facturi_Emise_Detalii.FacturaServ_ID) ON Firme.Firma_ID = Facturi_Emise.CumparatorFact_ID
GROUP BY Firme.FirmaNume, Facturi_Emise_Detalii.Serviciu, Facturi_Emise_Detalii.CantitateServ, Facturi_Emise_Detalii.ValoareaServ;
Produs grupat pe clienti
TRANSFORM Sum(Facturi_Emise_Detalii.ValoareaServ) AS SumOfValoareaServ
SELECT Facturi_Emise_Detalii.Serviciu
FROM Firme INNER JOIN (Facturi_Emise INNER JOIN Facturi_Emise_Detalii ON Facturi_Emise.Factura_ID = Facturi_Emise_Detalii.FacturaServ_ID) ON Firme.Firma_ID = Facturi_Emise.CumparatorFact_ID
GROUP BY Facturi_Emise_Detalii.Serviciu
PIVOT Firme.FirmaNume;
Grupare pe furnizori
TRANSFORM Sum(Facturi_Carausi_Detalii.ValoareaServFCDetalii) AS SumOfValoareaServFCDetalii
SELECT Facturi_Carausi_Detalii.ServiciuFCDetalii
FROM (Firme INNER JOIN Facturi_Carausi ON Firme.Firma_ID = Facturi_Carausi.FurnizorFCaraus_ID) INNER JOIN Facturi_Carausi_Detalii ON Facturi_Carausi.FacturaCaraus_ID = Facturi_Carausi_Detalii.FacturaServFCDetalii_ID
GROUP BY Facturi_Carausi_Detalii.ServiciuFCDetalii
PIVOT Firme.FirmaNume;
CAPITOLUL VI – CONCLUZII
Lucrarea de față, redactată în vederea încheierii studiilor la Facultatea de Contabilitate și Informatică de Gestiune din cadrul Academiei de Studii Economice București are drept subiect atât partea de contabilitate cât și partea de informatică studiate în 3 ani de studii, iar ca obiective de viitor sunt cuprinse foarte multe elemente de analiză economico-financiare.
Am ales acest subiect pentru a suprinde esențialul și materiile de bază ale profilului facultății și în primul rând pentru că materiile mele preferate sunt contabilitatea și informatica și cu ajutorul acestui proiect sper să fi reușit să scot în evidență o parte din multitudinea de avantaje pe care le avem la îndemână combinând aceste materii.
Din lucrarea supusă atenției Comisiei de examen de diplomă, se pot extrage unele concluzii cu privire la sistemul contabil din România conform Directivei economice Europene, conform Standardelor Internaționale de Contabilitate, precum și cu privire la sistemele informatice din domeniul financiar – contabil.
Concluzii cu privire la contabilitatea din România:
Convergența sistemelor de guvernanță europene și internaționale presupune existența unui model superior celorlalte, cu alte cuvinte mai eficient, din punct de vedere politic, economic și social. Eventualitatea unui atare fenomen ne conduce la ideea alinierii ansamblului țărilor Uniunii Europene, la exemplul anglo-american.
Pentru a conduce o contabilitate benefică și utilă trebuie, în primul rând, să înțelegem foarte bine acest domeniu și să ne perfecționăm continuu pentru o evoluție ascendentă pentru că, la fel ca orice meserie, dacă nu te adaptezi la nou te degradezi profesional și rezultatele sperate nu vor mai fi atinse niciodată.
Sistemul contabil devine din ce în ce mai reductor, o dată cu dezvoltarea capitalului intelectual (capitalul uman, capitalul relațional, capitalul organizaționa). Cum să se măsoare competența salariaților, elementul Know-how al unei organizații? Din acest punct de vedere, situațiile financiare prezintă un conținut informativ slab.
Concluzii cu privire la sistemele informatice din domeniul financiar – contabil:
– în România există foarte multe sisteme informatice dezvoltate pe acest domeniu, dar cum nici un sistem informatic nu este perfect, aceste sisteme se dezvoltă în continuare și încearcă să se formeze un standard. Fiecare firmă are metoda sa de evidențiere, fiecare manager dorește să vadă situațiile financiare și performanțele evidențiate într-un mod propriu și de aceea aceste sisteme sunt într-un număr atât de mare pe piața românească.
În țara noastră, evidențierea cu ajutorul informaticii, este relativ recentă, dar se dezvoltă foarte rapid și concurența este cea care dictează prețul și perefecționarea continuă a programelor existente precum și dezvoltarea altora noi.
Sistemul informatic pe care l-am dezoltat, a fost conform dorințelor și nevoilor firmei Wind Soft, acest sistem fiind unul personalizat pentru această firmă, dar ținând cont de legislația în vigoare, de posibilitățile oferite de limbajul în care a fost dezvoltat și nu în ultimul rând de cunoștințele mele din domeniul contabilității și al informaticii.
Obiective propuse pentru îmbunătățirea sistemului informatic dezvoltat:
Preluarea automată a cursului valutar de pe internet de pe pagina Băncii Nationale a României;
Generarea automată a decontului de T.V.A.;
Generarea automată a bilanțului contabil și a contului de profit și pierdere;
Generarea automată a unei balanțe de verificare pentru diferite valute pe care le va alege utilizatorul.
Dezvoltarea unui modul complet de gestiune (NIR-uri, Bonuri de consum, Fișe de magazie).
Dezvoltarea unui modul de verificări și analize ale performanței întreprinderii, analiză asupra riscurilor la care este supusă societatea la un moment dat . Printre indicatorii propuși pentru determinare sunt:
Indicatori privind analiza performanțelor întreprinderii:
Analiza cifrei de afaceri;
Tabloul soldurilor intermediare de gestiune;
Analiza ratelor de rentabilitate;
Analiza pragului de rentabilitate;
Analiza poziției financiare a întreprinderii:
Ratele de structura ale activului și ale pasivului;
Analiza patrimoniului net și a surselor reale de finanțare;
Analiza echilibrului financiar;
Ratele de solvabilitate și lichiditate;
Analiza vitezei de rotație;
Dezvoltarea unui modul nou privind consultarea și analiza de către conducerea societății, acest modul cuprinzând informații cum ar fi:
Disponibil de lichidități și echivalente de lichidități la o dată solicitată.
Tabelul fluxurilor de trezorerie, pe fiecare flux (exploatare, finanțare și investiții), precum și pe total, utilizând pentru obținera fluxului de trezorerie din activitatea de exploatare fie metoda directă fie metoda indirectă, utilizatorul având posibilitatea să aleagă una dintre aceste metode.
Sold general rentabilitate firma.
Evidență facturare.
Centralizări venituri și cheltuieli pe diferite categorii.
Pondere clienti in total venituri.
Pondere furnizori în total cheltuieli.
Bibliografie
1. Constantin Baron Sisteme informatice
Niculae Feleagă, Contabilitate Financiară
Liliana Feleagă(Malciu) o abordare europeană și internațională
Volumul I, Editura Infomega 2005;
Niculae Feleagă, Contabilitate Financiară
Liliana Feleagă(Malciu) o abordare europeană și internațională
Volumul II, Editura Infomega 2005;
Ana Morariu, Gabriel Radu Contabilitate și Fiscalitate,
Mirela Păunescu Ex Ponto 2005;
Chirața Caraiani, Contabilitate și control de gestiune,
Mihaela Dumitrana Editura InfoMega, București 2004;
Mihai Ristea, Contabilitate aprofundată,
Corina Graziella Dumitru Editura Universitară, 2005;
Mihai Ristea (coordonator) Contabilitatea Financiară a întreprinderii,
Colectivul de autori Editura Universitară, 2005;
Prof. dr. Victoria Stanciu Proiectarea sistemelor informatice,
Alexandru Gavrilă, Dragoș Editura Dual Tech, 2002
Mangiuc, Bogdan Gheorghe
Sahlean
Prof.dr. Roșca I. Ioan, Proiectarea sistemelor informatice de
Prof.dr. Zaharie Dorin gestiune (Note de Curs)
Editura ASE, București 2001;
Dorin Zaharie, Ioan Roșca Proiectarea obiectuală a sistemelor
Informatice, Editura Dual Tech, 2003
10. Roșca Ioan, Mangiuc Proiectarea obiectuală a sistemelor,
Dragoș, Boldeanu Dana Editura InfoMega, 2004
Maria, Secătureanu Ofelia,
Țarțavulea Cristina Venera,
Băbeanu Delia
11. Grupul BDASEIG Baze de Date, Fundamente teoretice
și practice, Editura Infomega, 2002;
12. Site – ul www.mfinante.ro.
Anexe:
DESCHIDERE APLICAȚIE
VIZUALIZARE FACTURI EMISE
INTRODUCERE FACTURI EMISE
VIZUALIZARE FACTURI PRIMITE
INTRODUCERE FACTURI PRIMITE
VIZUALIZARE CURSURI VALUTARE
INTRODUCERE CURS VALUTAR
CAUTARE CURS VALUTAR
ADAUGARE COTA TVA
ADAUGARE ORASE
ADAUGARE TARI
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Proiectarea Unui Sistem Informatic Pentru Evidenta Importurilor Si Exporturilor la Sc (ID: 149341)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.