Program Incasare Facturare Abonati Persoane Fizice

I. Motivația alegerii temei

Având în vedere și, luând în considerare, prețurile ridicate pentru anumite programe care țin de modul de facturare a anumitor servicii către populație și diverși agenți economici și, nu în ultimul rând de imposibilitatea societăților comerciale de a le achiziționa, s-a născut necesitatea implementării unor soft-uri strict legate de caracteristicile activității de prestări servicii a societății respective.

Ca urmare a „descentralizării” activității de salubrizare de la nivelul consiliilor locale, din anul 1999, firmele specializate in prestarea de servicii de salubrizare către populație și vechile întreprinderi de stat s-au confruntat cu situații noi. Una, deosebit de stringentă ținea de facturarea serviciului efectuat.

În consecință, s-a încercat identificarea diferitelor metode de urmărire și facturare. Una din metode, efectua verificarea și facturarea serviciilor pe fișe și apoi în registre.

Înființarea numeroaselor firme cu capital majoritar privat, desființarea asociațiilor de locatari și proprietari, precum și necesitatea facturării serviciului de salubrizare pentru fiecare apartament proprietate personală după desprinderea de la principalele servicii – gaz, apa-canal, etc. (începând din 2003), sistemul de urmărire a facturărilor și încasărilor s-a dovedit extrem de greoi. Numărul mare de personal implicat în acest proces, precum și a timpului alocat găsirii și facturării abonatului, legate direct de neplăcerile cauzate de timpul mare pe care abonatul îl petrecea la casieria unității prestatoare, au fost suficiente motive pentru a căuta și implementa un program pe calculator care să facă acest lucru.

Necesitatea existenței acestui program este clară pentru personalul implicat în activitatea directă de facturare a serviciilor de salubrizare.

Programul conceput, dezvoltat si implementat este un soft dedicat societăților mici si mijlocii, care nu au in bugetul alocat investițiilor IT prea mari investiții. El se pretează mai ales, datorită numărului mic de resurse alocate, putând funcționa și pe un calculator de o generație mult mai veche, chiar un Pentium I sau II.

Luând în calcul personalizările programului strict pe firme care prestează servicii de salubrizare, există avantajul eficientizării continue a lui. Programul, în sine, funcționează la una din firmele de profil din județul Maramureș. Față de versiunea inițială a suferit modificări importante legate strict noi prevederi fiscale și legi ale contabilității; deci, programul este încă deschis oricăror sugestii.

Deoarece, bazele acestui program au plecat de premise de ordin strict practic, și pentru că, în practică, rulează de ceva vreme, cu atât mai mult, cu cât el este perfecționat la orice modificare legislativă care trebuie aplicată, am considerat că este utilă alegerea lui ca temă a proiectului de diplomă.

II. Informatizarea programului

Apariția calculatorului electronic a reprezentat pentru întreaga lume un salt imens in dezvoltarea societarii civile. Posibilitățile deschise de calculatorul electronic păreau nelimitate, la fel și domeniile de utilizare a acestuia.

Dezvoltarea, cel puțin în primii ani, nu a fost atât de spectaculoasă pe cât se așteptau mulți. Au existat o serie de probleme care nu puteau fi neglijate: în primul rând dimensiunile unui calculator. Să nu uitam faptul că, primul calculator electronic, era de fapt, o clădire plină cu circuite, iar programarea însemna de fapt, mutarea unor întrerupătoare din poziția „deschis” pe cea  „închis”. De asemenea, rezultatul pe care aceste calculatoare le ofereau operatorului era atât de simplă ca formă, încât cereau un grad foarte mare de cunoștințe tehnice, pentru a fi în stare a le descifra.

Dezvoltarea electronică și apariția tranzistorilor a însemnat un pas deosebit de important în dezvoltarea tehnicii de calcul. În primul rând, dimensiunile calculatorului au scăzut considerabil ; cu toate acestea, în acele momente, un calculator însemna totuși, o încăpere plină cu „dulapuri” de circuite. Programarea se făcea cu ajutorul cartelelor perforate, iar mai târziu cu ajutorul benzii perforate, ceea ce înseamnă din nou, o mulțime de lucru pentru respectivul programator.

Apariția cipurilor de siliciu pe care sunt  „îngrămădite”  milioane de tranzistori a însemnat în primul rând, o mișcare deosebit de importantă a spațiului pe care îl ocupa un calculator. Ajungem astfel, în perioada „modernă” a calculatorului marcată în special, de apariția PC-ului (personal computer). Din acest moment, calculatorul nu mai este un  „monstru” electronic care ocupă o mulțime de spațiu; calculatorul se transformă în instrumentul principal de lucru pentru milioane de oameni, ocupând doar un mic spațiu pe un birou. Calculatorul devine „user-friendly”  – adică nu mai trebuie să faci ani de facultate, plus specializare, pentru a fi în stare să folosești un calculator. În ziua de azi, copii învață de mici să utilizeze calculatoarele, iar modul în care acestea sunt concepute azi încurajează

autodidacții. Foarte mulți învață singuri sa opereze un calculator, doar din interacțiunea zilnică cu acesta.

Cea mai importantă perioadă pentru dezvoltarea calculatoarelor este cea la care am fost cu toții martori: ultimii 15 ani au însemnat o creștere a puterii de calcul de aproximativ 300 de ori, ultimii 5 ani în special, când s-a manifestat aproape o dublare anuală a puterii de procesare a calculatoarelor.

Al doilea obstacol care a trebuit trecut a fost bariera prețului. La început, calculatoarele erau extrem de scumpe; trebuie să ne gândim la faptul că principalii cumpărători erau reprezentanți de stat. Adică guvernul unei țări hotăra dacă va fi cumpărat sau nu un calculator. Primele calculatoare astfel cumpărate au fost folosite în S.U.A. și Marea Britanie în timpul alegerilor și în cazul unor plebiciste.

Dezvoltarea tehnică rapidă, miniaturizarea componentelor electronice și producția de masă a acestora au însemnat tot atâția factori de scădere a prețului calculatoarelor. Deja se ajunge la momentul în care își permit și marile companii sau universități să achiziționeze calculatoare.

Lovitura decisivă dată prețului calculatoarelor a fost în momentul în care a apărut pe piața P.C. (Personal Computer). Lansat de I.B.M., calculatorul personal și-a început drumul spre cucerirea lumii. Deja suntem în momentul în care un calculator putea ajunge la utilizatorul obișnuit, nu numai la un grup de angajați a unei anumite instituții sau firme.

Apariția acestuia a însemnat o scădere dramatică a prețului, pentru că acesta era produs în cantități mari, deci prețul putea fi redus. În ceea ce privește prețul actual al calculatoarelor trebuie să constatăm că nu prea s-a modificat de la apariția primului P.C. dacă luăm în calcul un sistem de ultimă generație care ajunge aproximativ până la 1200 $.

Un alt atribut deosebit al calculatorului electronic, poate la fel de important ca și puterea de calcul o reprezintă posibilitatea de stocare a unor cantități imense de informație. Astfel, s-a ajuns de la metri cubi de cartele perforate și kilometri de bandă perforată, la benzi și discuri magnetice, hard-diskuri, compact discuri, DVD-uri. Cantitatea de material care poate fi azi stocată pe un calculator obișnuit (fără dotări speciale) dacă ar fi transferată pe hârtie ar ocupa un spațiu deosebit de mare. Pentru a sublinia mai bine această posibilitate de stocare și management a informației trebuie doar să facem o mică comparație mentală între a căuta trei rânduri de text între mii de dosare și a apăsa trei taste pentru a obține același rezultat într-un timp incomparabil mai mic.

Posibilitățile oferite de calculator au început să fie explorate chiar de la început, odată cu apariția acestuia. Cele mai multe progrese realizate de om în ultimii ani, mai mult decât sigur – nu ar fi fost posibile fără ajutorul calculatorului. Începând de la „marii utilizatori”, state, ministere, departamente de stat, continuând cu cei mijlocii, instituții, societăți comerciale, și terminând cu utilizatorul obișnuit, toți și-au dat seama de utilitatea practică a calculatorului. Puține sunt domeniile în care nu se folosește azi calculatorul, și vor rămâne probabil și mai puține.

Informatizarea a pătruns, cum era de așteptat și în cadrul firmelor mici datorită avantajelor oferite de utilizarea P.C.-ului , a vitezei de procesare, a posibilităților de stocare, și în special, eficienței muncii.

Deci, calculatoarele personale au apărut din necesitatea stocării și prelucrării cât mai rapide a informațiilor. La început, sistemele memorau o cantitate mică de informație, dar pe măsură ce tehnica a evoluat, ele au devenit din ce în ce mai performante, acesta însemnând o creștere a capacității de memorare și o mai mare viteză de prelucrare a datelor.

Separarea hard-ului (partea electronică a calculatorului) de soft (partea logică, alcătuită din programele după care funcționează calculatorul) a apărut odată cu conceptul de microprogramare, odată cu apariția microprocesorului, și s-a accentuat tot mai mult pe măsura dezvoltării sistemelor de calcul. Aceste două mari componente ale unui sistem electronic de calcul au evoluat în paralel, între ele existând o strânsă interdependență.

S-au dezvoltat astfel două domenii de cercetare în știința informaticii: cel referitor la hard-ul sistemului de calcul, în strânsă corelare cu cercetarea în domeniul fizicii, electronicii, și cel referitor la soft, având legătură cu dezvoltarea matematicii și a logicii.

Odată cu primele calculatoare electronice accesibile societăților comerciale au apărut și programe de introducere si procesare a datelor, în primul rând pentru evidențe si urmărire exactă facturării, a restanțelor și restanțierilor, cât și îmbunătățirea activității. Pentru aceasta,

s-au constituit departamente speciale în cadrul firmelor, care au ca scop principal realizarea acestor deziderate. În acest scop se caută personal specializat, spații necesare unei astfel de activități, elaborarea de programe, și nu în ultimul rând introducerea datelor și întreținerea efectivă a acestuia.

Datorită diversității mari a domeniilor în care un calculator este utilizat, au apărut și, totodată, mărit diversitatea problemelor cu care se confruntă zilnic un „realizator” de program (aparținând bineînțeles laturii soft a calculatorului). Nu există un singur program care să rezolve orice problemă. În schimb, s-au conceput mai multe programe, oarecum general

valabile pentru o anumită gamă de probleme. În funcție de problematica pe care o are de rezolvat, utilizatorul unui calculator alege programul care se potrivește cel mai bine în realizarea scopului propus.

S-a ajuns astfel, în zilele noastre, la o specializare foarte accentuată a sistemelor informatice, orientată spre rezolvarea diverselor tipuri de probleme.

O clasificare a problematicii rezolvate cu ajutorul calculatorului, ținând cont de volumul datelor și al prelucrării implicate în rezolvare ar putea fi:

probleme care implică prelucrări puține asupra unui volum de date;

probleme a căror rezolvare presupune un volum mediu de prelucrări asupra unui volum mediu de date;

probleme în rezolvarea cărora intră un volum mic de date asupra lor efetuându-se un volum mare de prelucrări.

Sistemele de Gestiune a Bazelor de Date – SGBD (prescurtare care este întâlnită foarte des în literatura de specialitate) reprezintă sisteme informatice (soft) specializate în stocarea și prelucrarea unui volum mare de date, în rezolvarea problemelor de primul tip, din clasificarea anterioară. Termenul de „bază de date” se va referii la datele de prelucrat, la modul de organizare a acestora pe suportul fizic de memorat, iar termenul de „gestiune” se va referi la acțiunea de memorare și prelucrare a acestor date.

Un SGBD trebuie să asigure următoarele funcțiuni elementare, referitoare la bazele de date:

definirea bazei de date;

introducerea datelor (adăugarea de noi date în baza de date);

modificarea unor date ea referii la datele de prelucrat, la modul de organizare a acestora pe suportul fizic de memorat, iar termenul de „gestiune” se va referi la acțiunea de memorare și prelucrare a acestor date.

Un SGBD trebuie să asigure următoarele funcțiuni elementare, referitoare la bazele de date:

definirea bazei de date;

introducerea datelor (adăugarea de noi date în baza de date);

modificarea unor date existente în baza de date;

ștergerea unor date;

interogarea bazei de date, adică extragerea informațiilor stocate în acesta;

generare de rapoarte;

modalități noi de interogare a bazei de date (de exemplu un limbaj SQL).

Istoria SGBD-urilor începe odată cu apariția primelor suporturi de memorie pe care informația era memorată secvențial, aceasta dând și caracterul secvențial al accesului de date în cadrul acestor sisteme.

Această etapă de dezvoltare este caracterizată de asemenea de o identitate perfectă între structura logică și cea fizică a informației din baza de date, aceasta, ducând la o manipulare greoaie a datelor din bazele de date.

Apariția sistemelor electronice de memorare, a discului magnetic în special, a dus la o nouă etapă în dezvoltarea SGBD-urilor, caracterizată prin:

separarea nivelului logic de cel fizic, realizându-se astfel o independența logică a datelor;

alături de accesul secvențial apariția accesului direct, acesta având ca efect imediat o creștere spectaculoasă a timpului de acces la date;

SGBD-urile sunt prevăzute acum cu primele utilitare încorporate cum ar fi generatoarele de rapoarte și generatoarele de tabele;

tot acum apar și primele tehnici de selectare, grupare și prelucrare a informațiilor.

Apariția și răspândirea rețelelor de calculatoarea dus la dezvoltarea într-o nouă direcție a SGBD-urilor, acestea căpătând caracter de multiutilizator.

De asemenea, au apărut bazele de date distribuite, care reprezintă baze de date logic integrate, dar fizic distribuite pa mai multe sisteme de calcul. Utilizatorul unei asemenea baze de date o vede ca pe o baza de date compactă, cu toate că în realitate ea este împărțită în mai multe părți pe mai multe calculatoare diferite, evident legate între ele la nivel fizic.

La nivel statistic această organizare a dus la o creștere substanțială a vitezei de acces la o baza de date într-o rețea de calculatoare eliminându-se pe cât posibil transferul de date între calculatoare.

Îmbunătățirile aduse SGBD-urilor se referă la organizarea bazelor de date modelul relațional al acestora și la metodele de interogare a bazelor de date SQL(Structured Query Language).

Ca direcții de dezvoltare a SGBD-urilor, în parte din ele existând deja la nivelul limbajelor vizual se prevăd:

programarea pe obiecte în cadrul SGBD-urilor;

baze de obiecte, în sensul că datele stocate în acestea vor fi imagini, sunete, și diverse alte obiecte complexe, cuprinse în conceptul de multimedia;

interfețe cât mai prietenoase, grafice, orientate pe obiecte.

SGBD – Evoluția sistemelor de gestiune a bazelor de date

Istoria SGBD cuprinde trei generații:

– modele ierarhice și rețea;

– modele relaționale;

– sisteme avansate: SGBD orientate obiect, SGBD deductive, SGBD distribuite.

Pentru modele ierarhice și rețea, datele sunt reprezentate la nivel de articol prin legături ierarhice (arbore) sau de tip graf. Slaba independență fizică a datelor complică administrarea și manipularea acestora. Limbajul de manipulare a datelor impune programatorului să specifice drumurile de acces la date.

Modelul ierarhic este modelul cel mai natural, iar rezultatul studiului după modelul ierarhic îl reprezintă structurile:

– liniare

– arborescente

Nodurile reprezintă entități, iar arcele reprezintă asocieri între entități. Într-o structură ierarhică ramificată, entității aflate la un nivel ierarhic superior (părinte) îi corespund mai multe entități aflate la un nivel ierarhic inferior (copil), dar fiecare entitate aflată la un nivel ierarhic inferior corespunde unei singure entități aflată la un nivel ierarhic superior.

Modelul rețea este un model performant, dar complicat. O bază de date de tip rețea reprezintă o colecție de noduri și legături ce permite realizarea următoarelor tipuri de structuri:

– liniare

– ierarhice

– rețea

Legăturile dintre entități trebuie stabilite luând în calcul toate interogările posibile și acțiunile viitoare probabile.

Modelul relațional tratează entitățile ca niște relații. Piața actuală de baze de date este acoperită în majoritate de sisteme relaționale. Acestea, ca și modelele de prima generație, au fost concepute pentru aplicații clasice: contabilitate, gestiunea stocurilor etc.

Bazele de date relaționale sunt caracterizate de:

structuri de date simple, intuitive;

inexistența pointer-ilor vizibili pentru utilizatori;

constrângeri de integritate;

mulțime de operatori aplicați relațiilor care permit efectuarea operațiilor asupra datelor.

Bazele de date relaționale oferă avantaje precum:

independența completă în descrierea logică a datelor (în termen de relații) și în descrierea fizică a datelor (în termen de fișiere);

un ansamblu integrat de utilitare bazat pe un limbaj de generația a 4-a, și anume generatoare de meniuri, generatoare de aplicații, generatoare de forme, generatoare de etichete etc.;

existența unor limbaje speciale de definire și manipulare a datelor.

Dintre sistemele de gestiune relaționale reprezentative, amintim: DB2, SQL/DS, INGRES, SABRINA, ORACLE, INFORMIX, UNIFY, TS, RAPPORT.

Bazele de date relaționale nu folosesc însă obiecte complexe și dinamice, nu realizează gestiunea datelor distribuite și nici gestiunea cunoștințelor. O altă generație de SGBD ce cuprinde sistemele avansate încearcă să depășească aceste limite ale sistemului relațional.

a) Gestiunea obiectelor complexe (baze de date orientate obiect)

Suportul obiectelor complexe și dinamice și manipularea lor este dificilă pentru sistemele relaționale, deoarece tipul datelor este limitat la câteva domenii alfanumerice, iar structura datelor este simplă. Sistemele relaționale nu modelează obiecte complexe ca grafuri, liste etc.

Un obiect complex poate să fie descompus în relații, deși apar dificultăți la descompunerea și la refacerea lui prin compunere (join). De asemenea, limbajele modelului relațional permit manipularea cu dificultate a obiectelor complexe.

O aplicație are un aspect static (reprezentat prin date) și un aspect dinamic (reprezentat prin tratamentul acestor date). Obiectele manipulate de sistemele relaționale sunt, în general, statice, iar comportamentul lor (dinamica lor) este dat separat prin programele aplicație. Un sistem relațional nu suportă obiecte dinamice care încorporează atât partea de date (informații) efective, cât și o parte relativă la tratamentul lor.

În programarea orientată pe obiect, efortul constă în definirea obiectelor. Obiectele de același tip formează o clasă care este generalizarea noțiunii de tip de date definit de utilizator. Clasa include, pe lângă date, și metodele de acces. Datele sunt vizibile doar metodelor asociate clasei respective. Acesta este așa-numitul principiu al încapsulării datelor. Prin funcții numite constructori și destructori, programatorul deține controlul asupra operațiilor necesare la crearea, respectiv dispariția unui anumit obiect. Un alt concept fundamental este cel al derivării, adică putem defini o clasă care să “moștenească” proprietățile (care constau din date și funcții) uneia sau mai multor clase “părinte”.

Îmbinarea tehnicii limbajelor orientate obiect cu a bazelor de date a permis realizarea bazelor de date orientate obiect. Aceste baze permit organizarea coerentă a obiectelor partajate între utilizatori concurenți.

Sistemele de gestiune orientate obiect prezintă următoarele avantaje:

realizează o modelare superioară;

furnizează posibilități superioare de deducție (ierarhie de clase, moștenire);

permit luarea în considerare a aspectelor dinamice și integrarea descrierii structurale și comportamentale;

îmbunătățesc interfața cu utilizatorul.

b) Gestiunea cunoștințelor (baze de date deductive)

O relație este o colecție de tupluri ce reprezintă fapte. Cunoștințele sunt aserțiuni generale și abstracte asupra faptelor. De exemplu, “Costică este medic” este un fapt, iar “Toți medicii sunt bogați” este o cunoștință. Cunoștințele permit să raționezi, ceea ce permite deducerea de noi fapte, plecând de la fapte cunoscute (“Costică este bogat”) și obținerea de răspunsuri inteligente (putem răspunde la întrebarea “Cine sunt bogați?” prin forma “Toți medicii”).

Un SGBD relațional suportă o formă limitată de cunoștințe, și anume constrângerile de integritate, restul cunoștințelor trebuie integrate în programele aplicație. Aceasta generează probleme, fie că trebuie codificate cunoștințele în programe, fie că apare imposibilitatea de a partaja cunoștințe între utilizatori. Totul se complică dacă există un volum mare de fapte.

Bazele de date deductive, utilizând programarea logică, gestionează cunoștințe relativ la baze de date care, în general, sunt relaționale. Bazele de date deductive permit deducerea de noi informații, plecând de la informațiile stocate în bază.

Un SGBD deductiv posedă:

Un limbaj de definire a datelor, care permite definirea structurii predicatelor sub formă de relații și constrângeri de integritate asociate.

Un limbaj de manipulare a datelor, care permite efectuarea reactualizărilor asupra datelor și formularea unor cereri.

Un limbaj de reguli de deducție, care permite ca, plecând cu predicatele definite anterior, să se specifice cum pot fi construite predicate derivate necesare filtrărilor cerute de utilizator. Un exemplu de limbaj de reguli care permite specificarea relațiilor deduse cu ajutorul clauzelor HORN fără simboluri tip funcție este limbajul DATALOG.

c) Gestiunea datelor distribuite (baze de date distribuite)

Un sistem distribuit este un ansamblu de mașini interconectate printr-o rețea de comunicație și utilizate într-un scop global. Administrarea și manipularea datelor distribuite, situate pe diferite calculatoare și exploatate de sisteme eterogene este obiectivul fundamental al bazelor de date distribuite.

Baza de date distribuită este un sistem de baze de date logic integrat, dar fizic dispersat pe mai multe echipamente de calcul interconectate.

Proprietățile bazei de date distribuite (BDD):

– respectă definiția și toate caracteristicile bazei de date;

– din unghiul de vedere al mulțimii user-ilor, o singură bază de date:

o singură schemă conceptuală; userii interacționează cu ea în aceeași manieră în care o făceau cu o bază de date centralizată;

– este fragmentată, iar fragmentele obținute sunt plasate în mijlocul realității imediate și-n mijlocul user-ilor fracțiunilor respective;

– permite accesul la locații diferite.

Baza de date distribuită (BDD) este o reuniune a bazelor de date locate (BDL), acestea rezultând prin fragmentarea uni tabel unitar.

Sunt utilizate trei modalități de fragmentare:

– împărțirea mulțimii de tabele în submulțimi de tabele;

– fragmentarea orizontală a tabelelor; fragmentele rezultate au aceeași structură cu tabelul original;

– fragmentarea verticală a tabelelor.

Replicarea datelor reprezintă operația de realizare de copii multiple ale unor tabele sau fragmente de tabele care sunt actualizate după două metode:

– actualizarea simultană a BDD este o operație consistentă, dar încarcă rețeaua pe care se lucrează;

– actualizarea întârziată a BDD; asupra copiei principale se efectuează toate operațiile de actualizare, celelalte copii sunt aduse la zi atunci când rețeaua este mai puțin solicitată (noaptea, weekend). Este proprie aplicațiilor pentru care inconsistența de o zi sau o săptămână nu contează.

Modalități de construire a BDD

1. Construirea de la zero – se urmează procedura de creare a bazei de date, care cuprinde:

studiul realității;

modelul logic al datelor;

modelul fizic; la modelul fizic al datelor se mai adaugă două operații:

1) fragmentarea datelor (apropierea de realitatea reflectată și de userii lor);

2)replicarea datelor (se decide dacă se va lucra cu date replicate: ce fragmente vor fi în copie multiplă; care va fi tipul de actualizare (simultan/întârziat); dacă este actualizare întârziată, se va decide care este copia principală și când se actualizează copiile secundare.

2. Integrarea de baze de date și fișiere existente într-o bază de date distribuită – se pune problema eterogenității bazelor de date existente pe calculatoare diferite (gestiunea bazelor de date existente se face cu SGBDD diferite; sau modelele ce stau la baza BDD de tipuri diferite (ierarhice, rețea, fișiere), sau BDD conține structuri care pot fi considerate fragmente ale unei tabele globale, dar cu structuri diferite.

Sistemul de BDD, ca și sistemul de baze de date SBDD, este alcătuit din 4 elemente: date, hardware, software și useri.

Datele sunt aceleași cu cazul în care aceste date ar fi numerotate pe același calculator, cu deosebirea că sunt memorate în locuri diferite.

Hard este mai complexă decât în cazul unui singur calculator, intervin modemurile și liniile de comunicații.

Soft – în locul SGBD, apare SGBDD, iar userii sunt aceiași ca în cazul bazei de date centralizate (finali, informaticieni, administratorul).

Structurarea datelor:

– în cazul unei baze de date locale, structura este următoarea:

Structura externă reprezintă viziunea user-ilor asupra datelor din baza de date.

Schema conceptuală reprezintă viziunea mulțimii tuturor user-ilor din baza de date (viziunea întreprinderii asupra datelor sale operaționale).

Schema internă reprezintă structura de memorare și strategia de acces la date.

Acest tip de structurare permite independența datelor.

Cazul BDD

SEG = viziunea user/grup useri asupra datelor din BDD

SCG = este SG a BDD văzută ca o singură bază de date (formal nu diferă de SC a

unei BD).

SIG = conține informații privind fragmentarea, replicarea și localizarea datelor

distribuite.

Această structurare asigură independența aplicațiilor față de fragmentare, replicare și localizare.

SGBDD – Arhitectura unui SGBDD

Schemă

Interfața utilizator – idem baze de date centralizare, diferă – o cerere a unui user de la acest nivel se adresează nu unei baze locale, ci mai multora. Cererea user este preluată de modulul de evaluare, care analizează cererea respectivă în raport cu dicționarul BD, se stabilesc nodurile care vor participa la rezolvarea cererii respective. Cererea respectivă poate fi descompusă în subcereri (X).

Modulul de recompunere – urmare unei cereri distribuite, sosesc la acest modul mai multe răspunsuri locale. Rolul său este să compună din răspunsurile locale răspunsul global.

Mecanismul de control al concurenței – concurență, blocare, impas

Replicarea

Blocarea – rezolvarea impasului – în cazul BDD se rezolvă mult mai greu, deoarece blocările pot apărea în rețea și rezolvarea impasului este dificilă. Alt g. implementați de SGBDD sunt cel puțin cu un grad mai mare decât cei la SGBD.

Un sistem paralel este un sistem conceput pentru a exploata capacitățile unui calculator multiprocesor. Implementarea unui SGBD ca un sistem paralel permite exploatarea paralelismului inerent care există în bazele de date.

Modelul relațional a rămas instrumentul prin care se realizează prelucrarea datelor distribuite, deoarece:

Bazele relaționale oferă flexibilitate de descompunere în vederea distribuirii. Tabelele se pot descompune orizontal, vertical și se pot regrupa.

Operatorii relaționali pot fi folosiți pentru combinații dinamice ale informațiilor descentralizate.

Limbajele sistemelor relaționale sunt concise și asigură o economie considerabilă a transmiterii datelor. Ele fac posibil, pentru un nod oarecare al rețelei, să analizeze intenția unei tranzacții, să o descompună rapid în componente ce pot fi realizate local și componente ce pot fi transportate altor noduri.

Soluția pentru a descentraliza prelucrarea datelor, în scopul evitării saturării memoriei și a procesoarelor calculatorului central, a fost apariția calculatoarelor baze de date și a mașinilor baze de date. Descentralizarea presupune transferarea unei părți din funcțiile unui SGBD către un calculator periferic (calculator backend), adică deplasarea algoritmilor de căutare și a celor de actualizare a datelor mai aproape de memoria secundară. Acest calculator periferic permite utilizarea optimă a resurselor și realizarea paralelismului în tratarea cererilor de informații. Calculatorul periferic poate fi un calculator clasic, dar cu un software specific de SGBD (calculator bază de date) sau poate fi o mașină cu hardware specializat în gestiunea bazelor de date (mașină bază de date).

Mașinile baze de date sunt înzestrate cu arhitecturi paralele special adaptate pentru gestionarea unui volum mare de date. Tratarea paralelă a cererilor permite reducerea timpului total de execuție a acestora. O execuție în paralel solicită fie descompunerea unui program în module care pot fi executate în paralel (descompunere funcțională), fie descompunerea datelor în subgrupe, astfel încât toate procesoarele să execute același lucru, dar pe date diferite.

Sistemul FoxPro este un sistem de gestiune a bazelor de date relațional, dezvoltat de firma FoxSoftware. Față de concurenții săi la acest nivel, dBase și Paradox, este cu mult peste aceștia ca și performanțe, în special, din punct de vedere a vitezei: în anumite cazuri FoxPro fiind de 100 de ori mai rapid. Obținerea acestei viteze se datorează tehnologiei folosită pentru optimizarea interogării bazelor de date – tehnologia Rushmore. Metodele de indexare s-au diversificat, programul având acum la dispoziție trei tipuri de indexuri: simplu, compus și compact. În mediul FoxPro sunt încorporate o serie de utilitare, foarte folositoare utilizatorilor cum ar fi Filer – pentru gestionarea fișierelor pe disc, Ascii Chart – o tabela cu coduri Ascii, etc.

Toate aceste caracteristici și multe altele fac din SGBD, încă, un puternic instrument software, la îndemâna tuturor utilizatorilor care lucrează sau care intenționează să lucreze în domeniul bazelor de date.

III. Descrierea programului

(- abonați -)

III. 1. Scopul programului

Programul de față se adresează în special firmelor mici, care au ca și activitate principală, servicii de salubrizare către persoane fizice, fiind structurat în așa fel încât să răspundă unora din cerințele existente la acest nivel. Rolul acestuia este de a oferi o alternativă modernă la nivelul efectuării de facturi, urmărire și încasare a acestora.

Principalele operațiuni pe care programul le suportă sunt cele de evidență a abonaților cărora li se prestează acest serviciu, modificările care survin de-a lungul timpului, facturarea periodica a acestora, precum și modul de încasare a facturilor emise.

Un astfel de program este necesar din perspectiva manipulării facile a informației în toate etapele, de la introducerea informației până la exploatarea ei efectivă. Pe același schelet se poate face o evidența si facturare și a societăților comerciale sau a asociațiilor de locatari care au contracte de prestări servicii in domeniul salubrității. Abordarea ar fi oarecum diferențiată deoarece exista la nivel legislativ, diferențe legate de modul de facturare a persoanelor fizice față de agenții economici, un exemplu elocvent ar fi faptul că până în anul 2000 la persoanele fizice nu se percepea TVA. Cunoașterea informației legate de punctul de lucru, care la unele firme pot să fie unul sau mai multe, diferă față de abonații care în cazul de față este evidențiat ca si o entitate unică, adică poți avea mai multe locuințe dar facturile se vor face câte una pentru fiecare în parte, pe când la societățile comerciale acest lucru nu are o importanță prea mare în acest sens se face o factură unică. În plus urmărirea se face lunar, la fiecare încheiere de lună se face obligatoriu inițializarea lunii următoare, în acest sens există posibilitatea salvării lunii anterioare programul nefuncționând aferent lunii următoare, deoarece se folosesc fișiere .dbf care au denumirea anului si lunii de lucru, acest aspect va fi evidențiat în capitolele următoare. Acest mod de abordare pare greoi la început dar pentru siguranța datelor e binevenit luând în calcul obligativitatea salvării lunii anterioare.

Programul ca atare rulează cu succes la una din firmele de profil, suferind modificări față de varianta inițiala ceea ce este normal la un soft în utilizare, probabil următoarea modificare , care ar fi majoră, ar fi transpunerea la nivel visual în acest sens folosindu-se unul din limbajele existente pe piață

III. 2. Structura bazei de date proiectare după modelul relațional

Majoritatea bazelor de date sunt baze de date relaționale; de aceea, vom descrie succint etapele proiectării acestora. Proiectarea bazelor de date presupune fixarea structurii bazei de date și a metodelor de prelucrare a datelor. Dacă, în mod obișnuit, baza de date își schimbă frecvent conținutul, structura ei rămâne nemodificată pe lungi perioade de timp.

Prin proiectare se determină un model semantic, care să reflecte cât mai fidel lumea reală, construit astfel:

– Se identifică o mulțime de concepte semantice (entități, tipuri de entități, proprietăți ale entităților, identificatorii entităților, relații între entități) ce dau informații despre lumea reală.

– Se asociază obiecte simbolice formale, prin care sunt reprezentate conceptele semantice.

– Se definește o mulțime de operatori formali ce pot să transforme obiectele formale.

Etapele construirii unei baze de date sunt următoarele:

– Studiul de fezabilitate, ce constă în cercetarea sistemelor existente, evaluarea costurilor pe diversele alternative.

– Cercetarea sistemului existent (tipuri de date, dimensiuni etc.).

– Analiza sistemului prin determinarea cauzelor diferitelor evenimente și a adoptării metodelor și a alternativelor posibile.

– Proiectarea sistemului prin determinarea celui mai bun model de reprezentare și prelucrare a datelor, de asigurare a securității și integrității.

– Dezvoltarea sistemului prin stabilirea detaliilor asociate datelor prevăzute a fi luate în considerare, a relațiilor dintre ele și a modului de reprezentare fizică.

– Implementarea sistemului prin proiectarea, scrierea și testarea programelor, antrenarea utilizatorilor, alcătuirea documentației, crearea și încărcarea fișierelor.

– Revizuire și întreținere prin probe de lucru ale noului sistem, efectuarea unor eventuale modificări, adăugarea de noi componente și urmărirea procesului de prelucrare a datelor.

Proiectarea urmărește obținerea de baze de date care să întrunească următoarele calități: corectitudine, consistență, distribuire, flexibilitate.

Criteriile de clasificare pentru determinarea modelului logic de date optim corespunzător unei baze de date sunt:

– Validare structurală – reflectarea consistentă a modului de utilizare a informațiilor în lumea reală;

– Simplitate – ușurința înțelegerii structurilor chiar de către utilizatori fără o pregătire specială;

– Neredundanță – eliminarea, pe cât posibil, a reprezentării de mai multe ori a aceleiași informații sau a informațiilor ce se pot deduce logic din altele;

– Distribuire – un model general aplicabil mai multor domenii, fără caracteristici specifice unor aplicații sau tehnologii particulare;

– Extensibilitate – posibilitatea de a dezvolta noi componente cu efecte minime asupra bazei de date existente;

– Integritate – consistența în modul de utilizare și întreținere a valorilor din informații.

Bazele de date au fost realizate cu ajutorul limbajului de programare FoxPro 26 din meniul de baza, și se găsesc în directorul în care este instalat programul de preferat c :\abonați. Avem nevoie de opt baze de date necesare pentru stocarea informațiilor, cărora s-au dat denumiri facile ușor de reținut legate de modul lor de folosire de către program, și de trei fișiere auxiliare, care sunt : vmem.mem, vm0506.mem, ferestre.win unde sunt depozitate variabilele de memorie si cele legate de ‘ferestrele’ utilizate in program.

Prima bază de date respectiv ab0506.dbf unde 0506 reprezintă anul și luna de lucru iar ‘ab’ este strâns legat de faptul că se lucrează cu abonați, persoane fizice,

Descrierea câmpurilor

acod – reprezintă un cod unic de recunoaștere a fiecărui abonat, de preferință este chiar numărul de contract alocat abonatului;

ascod – reprezintă codul alocat străzii la care locuiește persoana fizică;

atipscod – reprezintă o codificare internă pentru diferite prețuri existente la ora respectivă în firmă;

nrf, nrf1 – sunt numerele alocate numărului de factură și numărului de chitanța aferent fiecărui abonat;

anume, astr, anr, apart – numele persoanei, strada, numărul și apartamentul la care locuiește;

afelsal – indice pentru felul serviciului de salubrizare efectuat;

anrvechi – numărul de persoane înainte de ultima modificare, practica ne indică utilitatea utilizării unui astfel de informații;

anrpers – numărul efectiv de persoane care se facturează;

asalmc, asalmcv, asalmcn – reprezintă cantitățile facturate în funcție de cerințele utilizatorului;

afelfact – mod de facturare, L lunar, B o factura pe doua luni, T trimestrial,

difer, diftva – reprezintă posibilitatea existenței unor plăți în avans;

refuz, leisalv, leisaln, leiconv, leiconn – sunt valorile efective in lei a serviciului efectuat;

indtva – indice care reprezintă dacă se facturează cu TVA sau nu;

per – perioada facturată;

sector – indice pentru codificarea persoanei care se ocupă de urmărirea, persoanei pe durata desfășurării activității;

nrpub, datapub – numărul de pubele, și de când le deține în folosință;

contrapa, datacontr – date referitoare la contract;

datamod, cantitate, achitat – reprezintă date legate de modificările ulterioare care se vor efectua asupra abonatului respectiv.

Cea de a doua, uc0506.dbf ‘uc’ vine de la urmărire chitanțe urmat de anul și luna de lucru.

Descrierea câmpurilor

acod – reprezintă un cod unic de recunoaștere a fiecărui abonat, de preferință este chiar numărul de contract alocat abonatului;

ascod – reprezintă codul alocat străzii la care locuiește persoana fizică;

nrf – este numărul alocat unei facturi aferent fiecărui abonat;

datae – data emiterii facturii;

leisal, leicon, leidif, leitva, leitot – sunt valorile efective in lei a serviciului efectuat;

felf – indice aferent unei facturi, factura normala FN sau una speciala SP;

datai – data la care se va face încasarea;

leisali, leiconi, leidifi, leitvai, leitoti – sunt valorile efective in lei a serviciului efectuat, și încasat;

nrchit – notație care este necesară în momentul decontării încasărilor;

sector – indice pentru codificarea persoanei care se ocupă de urmărirea;

inc – indice aferent modului de încasare IC, PC, IO, PO, RC. RP, IB, PB (vor fi explicate în modul de utilizare a programului);

mod – indice care este necesar în momentul inițializării lunii următoare;

nrprovchit – indice de verificare;

dataprov – data când s-a eliberat chitanța provizorie;

nrf1 – câmp care ne indica numărul chitanței aferenta unei facturi.

Următoarea este speciale.dbf în care sunt înscrise toate facturile care se realizează intr-o lună, necesară în special pentru rapoartele către compartimentul contabilitate, marketing, etc.

Descrierea câmpurilor

snrf – este numărul alocat unei facturi aferent fiecărui abonat;

sdata – data emiterii facturii;

scoda – reprezintă codul alocat persoanei fizice;

sscoda – reprezintă codul alocat străzii la care locuiește persoana fizică,

stipf, stextf, ssum, spreț, scod, sca, sca, sva, stva, stot – sunt valorile efective in lei a serviciului efectuat și ce reprezintă acesta, în special aferent facturilor speciale.

După aceasta urmează specif.dbf. Este o bază de date săracă în câmpuri, având un singur câmp numit specif – în care sunt depozitate informații strict legate de modul de lucru cu facturile speciale, dar nu trebuie să-i neglijăm importanța, având posibilitatea să emitem și facturi strict personalizate pe anumite servicii care nu se fac lunar, ci ocazional, cum ar fi închirierea de pubele pe o perioadă determinată, transporturi suplimentare de reziduuri menajere, facturi aferente pe o perioadă determinată, mai mare decât cea normală, adică șase luni, un an, sau orice altă posibilitate.

Urmează un număr de patru baze de date asoc.dbf, temp.dbf, uf.dbf, urmchit.dbf care au o structura identica cu cele amintite mai sus, primele două fiind asemănătoare cu ab0506.dbf, iar ultimele două cu uc.0506.dbf Scopul lor fiind acela de a facilita obținerea de

date din bazele de date inițiale optimizate după un anumit criteriu pentru facilitarea în afișare a unor rapoarte ulterioare.

Relațiile dintre bazele de date este ușor de identificat după cum se vede și din structura lor, adică, prin câmpurile ascod și acod care sunt unice și bine determinate. Unui singur număr de înregistrare din baza de date ab0506.dbf îi poate corespunde una s-au mai multe înregistrări din celelalte două baze respectiv uc0506.dbf și speciale.dbf.

III. 3. Modul de programare – Realizarea aplicațiilor

O aplicație este un sistem de programe proiectat pentru a efectua un ansamblu determinat de operații asupra bazelor de date. Ea se compune din:

– programele propriu-zise (program principal, coordonator, programe pentru meniuri, ecrane, interogări, indexări, actualizări, rapoarte);

– bazele de date.

Executarea aplicației se realizează la două nivele:

Interpretativ – când un program numit “interpreter” ia fiecare enunț al aplicației, îl traduce în cod intern și face analiza erorilor, îl execută, apoi trece la următorul enunț.

Compilativ – când întreaga aplicație este tradusă de programul compilator într-un cod intermediar, memorat pe disc, numit cod obiect, care este supus unei prelucrări suplimentare de către editorul de legături pentru a obține forma finală, executabilă a aplicației. Execuția se face sub controlul sistemului de operare.

Realizarea unei baze de date presupune:

analiza sistemului pentru care se construiește baza de date;

proiectarea structurii bazei;

încărcarea datelor în baza de date;

exploatarea și întreținerea bazei de date.

Realizarea efectivă a unei aplicații presupune:

stabilirea temei;

analiza temei;

proiectarea aplicației;

codificarea aplicației;

testarea modulelor;

implementarea aplicației;

întreținerea aplicației.

Stabilirea temei

Tema este stabilită de beneficiarul aplicației, în raport de activitățile ce urmează a fi modelate.

Analiza temei

Analiza presupune identificarea tipurilor de informații, a legăturilor dintre ele, a operațiilor necesare pentru gestionarea lor.

Rezultatul analizei se presupune:

descrierea datelor de intrare;

descrierea datelor păstrate în baza de date;

lista prelucrărilor efectuate asupra datelor;

descrierea informațiilor din rapoarte.

Proiectarea aplicației

În această etapă, se realizează proiectarea structurii datelor și a structurii programelor. Proiectarea structurii programelor presupune detalierea modulelor necesare realizării aplicației: module pentru crearea fișierelor, pentru introducerea datelor, pentru prelucrarea și extragerea rezultatelor, pentru tratarea erorilor etc. Aceste module sunt controlate și coordonate de programul principal, care are următoarea structură:

program principal

declarare tablouri globale

inițializare variabile globale

salvare stare mediu inițializări generale

SET PROCEDURE TO subprograme_comune

deschide fișiere comune

sfârșit = false

Execută DO WHILE .NOT. sfârșit inițializare dialog

un bloc CLEAR SCREEN

de comenzi afișează mesaje de dialog

în cadrul preia opțiunile utilizatorului

unei bucle DO CASE Execută între 10 CASE și

condiționată CASE activitate 1 ENDCASE; blocurile de

de o expresie DO modul 1 comenzi în ordine, dacă

logică. CASE activitate 2 expresia logică asociată

DO modul 2 este adevărată.

…

OTHER WISE

SAY “opțiune invalidă”

ENDCASE

ENDDO

închide fișierele comune

reface mediul

CLEAR SCREEN acțiuni de încheiere

RETURN

Codificarea aplicației

Dacă la c) nivelul de detaliere este de tip pseudocod, în această etapă se scrie aplicația într-un limbaj specializat, cu respectarea regulilor impuse de acesta.

Testarea modulelor

În această etapă se verifică modulele, se detectează și corectează eventualele erori, se face analiza cazurilor extreme, se proiectează testele.

Implementarea aplicației

Se construiește forma finală a aplicației prin integrarea treptată a modulelor funcționale testate.

Întreținerea aplicației

Se înlătură erorile semnalate de utilizator în perioada de garanție, se modernizează aplicația și se actualizează.

Utilizatorii unei baze de date

Uitlizatorii unei baze de date pot fi:

Utilizatori nespecialiști (conversaționali) care au la dispoziție o formă de comunicare cu baza de date apropiată de vorbirea curentă;

Utilizatori specialiști care cunosc structura bazei de date;

Administratorul bazei de date este un utilizator special, care definește obiectivele exploatării bazei, împarte drepturile de acces ale utilizatorilor, elaborează concepția de proiecție a bazei de date, răspunde de toate activitățile și operațiile referitoare la baza de date, ajută la definirea cerințelor utilizatorilor etc.

Limbaje pentru baze de date

În cadrul SGBD, funcțiile de declarare și de manipulare a datelor sunt realizate cu ajutorul unor limbaje diferite.

Limbaje pentru definirea datelor (LDD)

Funcțiile LDD sunt:

realizează definirea entităților și a atributelor acestora prin nume, formă de memorare, lungime;

precizează relațiile dintre date și strategiile de acces la ele;

stabilește criterii diferențiate de confidențialitate;

definește criterii de validare automată a datelor utilizate.

Limbaje pentru manipularea datelor (LMD)

Operațiile pe baze de date solicită un limbaj specializat, în care comenzile se exprimă prin fraze ce descriu acțiuni asupra bazei.

O comandă are următoarea structură:

operația, care poate fi calcul aritmetic sau logic, editare, extragere, deschidere-închidere, manipulare (introducere, adăugare, ștergere etc.);

criterii de selecție (for, while, where etc.);

mod de acces (secvențial, indexat etc.);

formă de editare.

Limbaje pentru controlul datelor (LCD)

Controlul unei baze de date presupune:

asigurarea confidențialității și integrității datelor;

salvarea informației în cazul unor defecțiuni;

obținerea unor performanțe;

rezolvarea unor probleme de concurență.

Limbaje universale

Un limbaj universal se utilizează rar pentru gestionarea unei baze de date.

Interfața dintre utilizator și SGBD se realizează în două moduri:

Cu ajutorul unui mecanism de apel inserat în programul aplicație. Acest mecanism poate fi un CALL sau un alt cuvânt cheie. Un SGBD care permite acest tip de mecanism se numește SGBD cu limbaj gazdă;

Cu ajutorul unor comenzi speciale, utilizate independent. În acest caz, SGBD se numește autonom. Există, totuși, o interfață specială, care este capabilă să interpreteze comenzile limbajului de cereri.

Pentru realizarea programului s-a folosit limbajul FoxPro 26. Pare un limbaj mai greoi, și ușor depășit dacă stăm și analizăm implementarea in mediu vizual care are avantajele lui, dar, să nu uitam începuturile și faptul că aplicația nu necesită resurse majore ale sistemului de calcul. Nu s-a folosit nici măcar generatorul de rapoarte și ecrane totul fiind lucrat la nivel ‘hard’. Meniul principal a fost realizat, pentru a facilita rularea programului, navigarea în cadrul aplicației se poate face simplu și cu ajutorul mouse-lui sau folosind tasta TAB pentru navigarea in meniu.

Pentru reușita acestui program ne-am folosit foarte mult de funcția Help existentă în limbajul de programare FoxPro, prin apelarea tastei F1. Iată o mică parte din comenzile folosite:

În programul s-au utilizat comenzile @ … SAY, @ … GET și READ:

Comanda afișează expresia dorită la locația specificată de rând și coloană. Dacă SET DEVICE este setată TO SCREEN, expresia apare pe ecran; dacă SET DEVICE este setată TO PRINTER, expresia apare la imprimantă;

Clauzele PICTURE și FUNCTION sunt utilizate sunt utilizate pentru controlul modului de afișare / imprimare a expresiei <exp>. Codurile FUNCTION pot fi incluse în clauza PICTURE caz în care codul va începe cu simbolul @.

Clauza SIZE permite controlarea lungimii și a lățimii regiunii de afișare sau imprimare

Clauzele COLOR SCHEME și COLOR permit specificarea culorilor dorite la afișare.

Comenzile @ … SAY și @ … GET se pot combina într-o singură comandă.

Comanda creează o regiune de editare (introducere de la tastatură) a valorii:

unei variabile de memorie,

unui element de masiv,

unui câmp al tabelei (dbf) active.

La crearea unei regiuni de editare se pot include clauzele FUNCTION, PICTURE sau ambele deodată, pentru a crea o mască de editare.

Clauzele PICTURE și FUNCTION sunt utilizate sunt utilizate pentru controlul modului de editare a variabilei <var>|<câmp>. Codurile FUNCTION pot fi incluse în clauza PICTURE caz în care codul va începe cu simbolul @.

Dacă pentru regiunea de editare se specifică o variabilă care nu există, ea se creează și inițializează automat (nu și pentru masive !) prin includerea clauzei DEFAULT. Clauza DEFAULT este ignorată dacă variabila există deja sau s-a specificat <câmp>.

Clauza DISABLE previne accesul la regiunea de editare. Accesul se permite prin comanda cu specificarea @ … GET … ENABLE

Expresia caracter a clauzei MESSAGE este afișată când regiunea de editare este selectată. Mesajul este centrat pe ultima linie a ecranului, anulând orice expresie SET MESSAGE.

Clauza WINDOW se include dacă se dorește editarea într-o fereastră definită de utilizator.

Dacă este inclusă clauza OPEN fereastra de editare a unui câmp MEMO este automat deschisă atunci când se întâlnește comenzile READ sau READ CYCLE.

Clauza RANGE precizează valorile acceptabile pentru date de tip caracter, numeric sau dată calendaristică.

Clauza VALID permite validarea introducerii atunci când se părăsește regiunea de editare. Regiunea de editare se părăsește acționând Enter, săgeată dreapta, Tab , completarea lungimii maxime a zonei de editare sau Esc.

Clauza ERROR permite specificarea unui mesaj de eroare afișat atunci când clauza VALID returnează valoarea false (introducerea nu este validată).

Clauza WHEN permite sau împiedică accesul la regiunea de editare în funcție de valoarea de adevăr a expresiei logice <expL2>

Clauza COLOR SCHEME|COLOR permit setarea culorii regiunii de editare.

READ – [CYCLE] [ACTIVATE<expL1>] [DEACTIVATE<expL2>] [MODAL] [WITH<lista_tiltluri_ferestre>] [SHOW<expL3>] [VALID<expL4>|<expN1>] [WHEN<expL5>] [OBJECT<expN2>] [TIMEOUT<expN3>] [SAVE] [NOMOUSE] [LOCK|NOLOCK] [COLOR<culoare> | COLORSCHEME <expN4>]

Comanda activează obiectele create cu @…GET și @… EDIT.

Clauza CYCLE determină ca la acțiunile de părăsire a câmpului de editare (Enter, săgeată dreapta, Tab , completarea lungimii maxime a zonei de editare) cursorul să rămână în continuare în zona de editare, oferind posibilitatea reeditării (corectării) datelor. Dacă sunt definite prin @… GET mai multe câmpuri de editare, deplasarea de la un câmp la altul se realizează prin acționarea Tab, Shift-Tab săgeată direcțională sus sau jos. În acest caz părăsire zonei de editare se realizează prin acționarea:

tastei Esc (dacă nu este inhibată prin SET ESCAPE OFF) ,

combinației <Ctrl-W>,

utilizarea clauzelor CLEAR READ sau TIMEOUT,

activarea elementelor pentru controlul ieșirii din READ.

Clauza MODAL împiedică activarea ferestrelor de editare, cu excepția ferestrelor implicate în READ.

Clauza WITH limitează accesul la doar la ferestrele incluse în <lista_tiltluri_ferestre>.

Clauza VALID este evaluată când se încearcă ieșirea din READ-ul curent sau când comanda READ este întâlnită fără o comandă @…GET anterioară.

Clauza WHEN determină execuția comenzii READ în funcție de valoarea de adevăr a <expL5>

Clauza OBJECT determină obiectul (cu numărul <expN2>) care va fi selectat inițial. Obiectele primesc numărul de ordine în funcție de ordinea creării lor.

Clauza TIMEOUT determină cât timp comanda READ așteaptă introducerea datelor în zona de editare creată cu @ … GET. <expN3> indică numărul de secunde de așteptare.

Clauza SAVE determină salvarea definițiilor obiectelor.

Clauza NOMOUSE împiedică selectarea obiectelor cu mouse-ul .

Clauza LOCK|NOLOCK specifică dacă o înregistrare este sau nu protejată la scriere în timpul executării comenzii READ. Se utilizează pentru lucrul în rețea unde mai mulți utilizatori pot accesa simultan aceeași înregistrare a unei baze de date.

Clauza COLOR SCHEME|COLOR permit setarea culorii regiunii de editare @…GET curente.

DEFINE WINDOW – <nume_fereastră1> FROM <r1, c1> TO <r2,c2> [IN[WINDOW] <nume_fereastră2>|IN SCREEN] [FOOTER <expC1>] [TITLE <expC2>] [DOUBLE | PANEL | NONE | SYSTEM | <caracter ASCII>] [CLOSE | NOCLOSE] [FLOAT | NOFLOAT] [GROW|NOGROW] [MINIMIZE] [SHADOW] [ZOOM | NOZOOM] [FILL <expC3>] [COLOR<culoare> | COLORSCHEME<expN4>]

Comanda definește o fereastră astfel:

<r1,c1>, <r2,c2> definesc colțul stânga sus și dreapta jos a zonei de definire a ferestrei (rând, coloană);

marginea ferestrei poate fi dublă (DOUBLE), poate lipsi (NONE) etc.

Clauza IN WINDOW|IN SCREEN plasează fereastra într-o fereastră specificată sau pe ecranul FoxPro;

Clauza FOOTER permite aplicarea textului <expC1> în partea de jos a ferestrei;

Clauza TITLE permite aplicarea textului <expC1> în partea de sus a ferestrei;

Clauza CLOSE|NOCLOSE permite / inhibă închiderea ferestrei;

Clauza FLOAT|NOFLOAT permite / inhibă mutarea ferestrei;

Clauza GROW|NOGROW permite / inhibă redimensionarea ferestrei;

Clauza FILL permite umplerea fundalului ferestrei cu caracterul <expC3>

ACTIVATE WINDOW – [<nume_fereastră1>[,<nume_fereastră2>]]

ACTIVATE WINDOW ALL – [IN[WINDOW] <nume_fereastră3> |SCREEN] [BOTTOM | TOP | SAME] [NOSHOW]

Comenzile afișează și activează o fereastră definită în prealabil cu DEFINE WINDOW.

Clauzele BOTTOM|TOP|SAME permit specificarea poziției de afișare a ferestrei (în fața tuturor ferestrelor / în fața tuturor ferestrelor / fără efect). O fereastră apare în față implicit atunci când este selectată și devine activă.

RELEASE -WINDOW [<listă_ferestre>

Comanda șterge din memorie ferestrele specificate în listă_ferestre

DO CASE – CASE <expL1><instrucțiuni1>[CASE <expL2><instrucțiuni2>]…

[OTHERWISE] <instrucțiuniN> ENDCASE

Instrucțiunea selectează și execută grupul de instrucțiuni care corespund condiției expL cu valoare “true” (adevărată). Dacă o expL este găsită adevărată instrucțiunile corespunzătoare celorlalte expL și OTHERWISE sunt ignorate după se trece la execuția instrucțiunii care urmează teoretic după ENDCASE.. Dacă nici o expL nu este adevărată se vor executa instrucțiunile corespunzătoare OTHERWISE (altfel); în acest caz dacă nici OTHERWISE nu este prezentă se trece direct la execuția instrucțiunii care urmează teoretic după ENDCASE.

FUNCTION<nume>Identifică (descrie) o funcție definită de utilizator sub numele <nume>. Funcția se poate apela prin specificarea numelui ei urmată de parametri funcției între paranteze rotunde, dacă există, dacă nu numai de paranteze

IV. Utilizarea programului

Programul este dedicat cu precădere unui număr redus de utilizatori, prin particularitatea sa, specializat pe o anumită activitate, cea de salubrizare, coroborat cu modul de facturare, încasare, și urmărire a restanțelor aferente abonaților persoane fizice. Acesta rulează la una din firmele de profil, modul de utilizare, rapoartele oferite, informațiile stocate, și satisfacția utilizării lui de către persoanele care l-au utilizat efectiv, luând în calcul faptul că aplicația nu este una foarte greoaie și dificilă, ne duce la concluzia unui program reușit. Programul este conceput pentru un singur utilizator, nu necesită cunoștințe aprofundate de informatică, în utilizarea lui.

Pentru înțelegerea acestui fapt voi prezenta cum funcționează aplicația.

Vom începe prin implementarea ei, care se face prin copiere pur și simplu de pe o unitate de disc externă, în acest sens, prin arhivare, poate foarte bine să intre ca dimensiune a fișierului arhivat, pe o dischetă. Copierea se va face intr-un director cu un nume semnificativ (după bunul plac al utilizatorului), în cazul de față cel ales de mine este c:\abonati. Fiind un fișier executabil și de sine stătător nu necesită căi speciale (path) către diferite alte aplicații din calculator. Odată cu copierea fișierelor *.dbf se vor copia și fișierele necesare rapoartelor *.frt, *.frx, după care prin crearea unei scurtături, sau cu ajutorul comenzii run din taskbar se poate porni programul prin activarea fișierului abonati.exe.

La pornire ne va întâmpina o fereastră prin care ni se solicită data, acest lucru fiind foarte important în informațiile stocate și toate celelalte modificări care se efectuează asupra bazelor de date, implicit este data sistemului.

După tastarea tastei enter ne aflăm în meniul bară principal al aplicației care conține mai multe meniuri și submeniuri cu următoarele opțiuni:

Se remarcă existența unei taste de ieșire rapidă din program F10, în cazul în care apare o blocare a programului din motive independente de utilizator (scanare a fișierelor de către un antivirus, eroare de sistem, etc)

Descrierea meniului:

OPTIUNI

Perioade prelucrări – la activarea acestuia vom fi introduși într-o fereastră unde vom introduce date legate de timp, perioada facturată, respectiv luna de lucru, trimestrul, dacă se fac facturi pe o perioadă determinată, precum și anul în care lucrăm

Mc gunoi/ pers/ luna – conform legislației în vigoare cantitatea de gunoi menajer pe care se presupune că o face o persoană într-un an de zile este de 1.2 mc / an, dar acest lucru depinde mult de particularitățile fiecărei localitate în parte, există diferențe majore chiar și în oraș raportat la abonații care locuiesc la bloc și cei care locuiesc la case, în acest sens s-a prevăzut introducerii acestei cantități de către utilizator,

Informații preturi – se vor introduce valoarea efectiva a serviciului de salubrizare efectuat(in lei). În acest sens există mai multe informații stricte care trebuie introduse, și actualizate, periodic (dacă există modificări de prețuri),

Procent TVA – valoarea taxei pe valoare adăugată, actualmente de 19%

Informații INTEPRINDERE – date despre societatea comercială

Toate aceste informații, în momentul părăsirii aplicației, se vor memora în cele două fișiere vmem.mem vm0506.mem care au fost descrise mai sus. O dată introduse, la pornirea aplicației ele vor fi restaurate în mod automat, nu necesită altă modificare decât în cazul strict în care oportunitatea o cere.

BAZA DATE – conține la rândul său două opțiuni

Actualizare ABONATI – se lucrează direct cu baza de date, ab0506.dbf și se pot face toate modificările necesare unei astfel de activități de la adăugarea unei persoane în baza de date, modificările apărute pe parcurs, schimbare cantități de facturat, schimbare nume, adresa, etc, ștergerea lui din fișier, până la obținerea de informații după cod abonat sau după numele acestuia. Ieșirea din acest meniu se poate face fie direct prin apăsarea tastei 0 sau prin parcurgerea întregului meniu până se ajunge la poziția ”Terminare actualizare ABONATI” .

Adaugare inregistrări – necesită cunoașterea numărului de contract, și codul străzii, după care după cum se remarcă este ușor de introdus toate celelalte informații referitoare abonatului

Modificare informatii generale, modificare cantitati – se deschide aceași fereastră ca și cea de mai sus, unica modificare fiind posibiltatea schimbării numai a câmpurilor strict indicate în meniu. Toate acestea pentru a mări viteza de lucru, nemaifiind necesar parcurgerea intregului ciclu.

Stergere inregistrări – se șterge un abonat din baza de date. Unicul lucru necesar acestui lucru este cunoașterea numărului de cod și codul străzii. În perspectivă pentru activarea acestei opțiuni (practica a dovedit) este necesar o parolă, pentru evitarea ștergerii accidentale din baza de date, sau ștergerea unui abonat de către o persoană neautorizată. Există opțiunea, în cazul în care abonatul nu este cel căutat de a nu se efectua nici o modificare asupra bazei de date, prin opțiunea NU. Dacă se alege opțiunea DA abonatul va fi șters, neexistând nici o posibilitate de recuperare a datelor, doar dacă nu se va introduce încă o data din meniu pe varianta adăugare abonați,

DIFERITE LISTE ABONATI – se remarcă existența a șspte butoane radio care pot fi selectate fie prin plimbarea efectivă prin meniu fie cu cifrele corespunzătoare fiecăruia

Primul buton oferă o listă a abonaților după codul străzii, al doilea o listă completă pe străzi, cel de al treilea se obține lista pe o anumita stradă, după care se poate obține o listă și după sectorul arondat străzii, o listă cu persoanele care refuză serviciul de salubrizare, din diferite motive nu locuiesc o perioada de timp în spațiul respectiv, nu li se efectuează acest serviciu din motive independente de ei (strada prea îngustă, greu accesibilă, neefectuare de servicii din cauza intemperiilor naturii, etc), la contractele active se poate obține, pentru ușurința efectivă a scrierii unui contract, contractul gata tipărit cu datele existente din baza de date abonatului, și în final butonul de reântoarcere în meniul de lucru cu baza de date. Vom trata numai unul dintre aceste opțiuni deoarece există asemănări între ele, ce le diferențiază este raportul care se obține în final. Vom activa butonul 3 O strada unde vom avea posibilitatea de a trimite raportul spre vizualizare la consolă, respectiv monitor, sau spre imprimantă. După această opțiune vom fi nevoiți să scriem exact denumirea străzii, după care prin tastarea tastei enter vom vedea raportul dorit. Atenție, în cazul în care nu s-a tastat corect denumirea străzii rezultatul va fi nul. Pentru ieșirea din meniu se va tasta / urmat de tasta enter, acest lucru se poate remarca și prin sugestiile care se dau în bara de mesaje a programului

VIZUALIZARE dupa cod abonat, VIZUALIZARE dupa nume abonat – sunt două opțiuni foarte utile pentru a obține rapid informații referitoare la o anumită înregistrare. Este simplu de remarcat că în primul caz este nevoie de codul abonatuli iar în cel de al doilea este suficient o parte din nume, indiferent dacă este numele sau prenumele. Aici a fost nevoie de una din bazele de date auxilare, temp.dbf unde sunt copiate numei înregistrările care ne interesaeză si raportul se obține pe seama acestui lucru. În momentul părăsirii modulului aceste baze de date auxiliare sunt golite. La terminarea căutarii suntem anunțați că nu există alte înregistrări avănd opțiunea de continua căutarea după o altă cheie, sau să parasim acest modul.

CERERI MODIFICĂRI DATĂ – această opțiune a intervenit datorită fluctuației apărute în numărul de persoane pe o perioadă determinată de timp. De exemplu o familie care are un membru al ei, student intr-o altă localitate, va solicita ca pe perioada unui an școlar, să nu se întocmească factura decât unui număr mai mic de persoane. În acest sens se va introduce în program data de la care va urma să se factureze noul număr de persoane și câte, iar noul număr de persoane aferent lunii în curs se va modifica direct din program. Se va remarca în meniul din bara principală că există o opțiune de actualizare lunară a modificărilor care s-au efectuat în aceasto secțiune a programului

RESTAURARE FISIERE DATE – se ocupă de readucerea fișierelor salvate și consultarea lor ulterioară. Restaurarea se face de pe unitatea de flopy cu ajutorul programului de arhivare arj.exe. Există în meniu și posibilitate salvării datelor în porțiunea SF. LUNA, care va fi explicată la momentul oportun.

FACTURI acest modul este dedicat în totalitate actului de facturare

Informatii numere facturi – se ocupă cu numerele alocate facturilor. Conform legislației în vigoare formularele de facturi sunt personalizate, adică datele de identificare a firmei, codul fiscal, numărul de înregistrare de la Registrul Comerțuluii, adresa firmei, contul în banca și la care dintre ele precum și capitalus social, sunt tipărite direct pe imprimate, urmâmd ca restl informațiilor să fie completate de către utilizator. În acest sens a fost necesar existența acestei obțiuni. După cum se remarcă, se introduc datele necesare, cu observația necesară că ultimul număr din serie este util pentru a nu depășii numerele alocate în momentul în care se tipăresc efectiv facturile. Ca și datele legate de firma care folosește programul, acestea se salvază în momentul închiderii aplicațieii nefiind necesară actualizarea lor la fiecare pornire a a programului.

Numerotare facturi – calcule – după verificarea numărului primei facturi se poate trece la generarea lor. S-a ales și această variantă care pentru simplitate, fiind vorba de mii de facturi s-a considerat mult mai util a genera în primă faza acestea, și abia ulterior imprimarea lor. Imprimarea se face de pe listing, format A4, cu ajutorul unor imprimante matriciale, care în cazul de față se pretează prin fiabilitate și ușurință în exploatare, unicul inconvienient fiind acela al nivelului de zgomot un pic mai ridicat. Numerotarea se va face, după codul străzii, începând cu primul abonat până la ultimul.

Se poate factura și parțial o stradă, dar acest lucru implică cunoașterea exactă a poziției abonaților în baza de date, de aceea este foarte util obținerea unor liste după codul străzii, ele putând fi obținute din modulele explicate anterior.

După teminarea străzilor care s-au dorit a fi facturate se iese din aceast meniu prin tastarea numerelor 999

Facturi speciale abonații – în cazul în care se dorește emiterea unei facturi, personalizată, adică conține anumite servicii suplimentare, sau vânzare a unui produs, etc acest lucru se poate obține din acest modul. Ca peste tot în această aplicație foarte util este să cunoaștem numărul de contract al abonatului, dupa care se introduc informațiile de identificare a persoanei care face factura, urmând ca ditr-o fereastră ulterioară să ne alegem specificația dorită. În cazul în care ea nu există se poate introduce una nouă prin alegerea din meniul din fereatră o opțiunii adaug specificație. Pasul următor este introducerii de la tastatură a unității de măsură dorită, preț unitar, și a cantității, după care programul face calculul valorii totale. Se poate factura și fără TVA alegând din fereastra următoare opțiunea ca viitorea factură să nu conțină TVA. Există această posibilitate deoarece în legislație, societățile comerciale care dezvoltă o activitate din fonduri de la Uniunea Europeană, pe linie umanitară, nu se percepe această taxă. Etapa imediat următoare este de a adăuga o nouă specificație, dacă dorim, dacă nu alegem opțiunea terminare totodată părăsind acest modul, factura deja fiind trimisă către imprimantă. Toate datele legate de specificație se salvează în fișierul specif.dbf , iar cele legate de factură în cele două fișiere care gestionează acest lucru, respectiv uc0506.dbf și speciale.dbf.

Facturi generate (baza de date) – după ce s-au generat facturile, în momentul în care o persoană dorește să plătească, serviciul de saluibrizare se activează acest meniu, se caută persoana în baza de date după nume, se identifică, și în final obținem o oglindă a serviciilor efectuate pe o perioadă de timp, după cum se vede din imaginea de mai jos.

Se alege care dintre pozițiile afișate se dorește a fi plătită, după ce în prealabil i se comunică persoanei situația efectivă a restanțelor. Acestea se găsesc în fișierul uc0506.dbf și după cum se observă din captură, se poate vedea situația exactă a neplăților. Se poate comunica data emiterii facturii prin consultarea câmpului Datae , numărul de factură Nrf , valoarea fără TVA Leisal , cât reprezintă TVA Leitva și în final valoare totală Leitot. Se remarcă si codul abonatului Acod precum și codul străzii Ascod. Următoarea etapă ne trimite în tastarea informațiilor referitaoare la persoana care emite factura, și prin completarea ultimului cîmp cu litera D se trece la tipărirea efectivă a facturii.

Anulare facturi – În cazul în care din motive externe, independente de utilizator suntem nevoiți a anula o factură, această posibilitate există, și se execută din acest meniu. Pentru activarea lui este necesară o parolă, care este cunoscută numai de către cei care sunt acreditați a utiliza aplicația. După introducerea parolei se actvează o altă fereastră în care ni se cere factura pe care dorim a o anula. Se tastează numărul și factura cu pricina este ștearsă, ireversibil din baza de date. Tocmai din acest motiv am fost nevoiți a accesa acest modul cu parolă, pentru evitarea situațiilor în care se șterge accidental o factură sau o rea intenție

Actualizări modificări lunarei – Pentru actualizarea bazei de date, modificare a numărului de persoane de la o anumită dată, plecarea unora, revenirea altora, luând în calcul luna în care ne aflăm se activează acest modul prin simpla completare a căsuței din fereastră cu litera D . În fereastră există de asemenea o avertizare prin care suntem anunțați de ireversibilitatea modificărilor asupra bazei de date. Acesta s-a considerat a fi necesară deoarece acest modul se execută o singura dată în lună, chiar înaine de a genera facturile, deci utilizarea ei este rară în domeniul aplicației.

URMARIRE FACTURI – acest modul se ocupă cu modul de încasare a facturilor, și obținerea unor rapoarte legate de situația restanțelor și încasărilor.

După cum se poate vedea prin activarea primei obțiuni din meniu vom avea o situație a valorii facturate, încasate în cursul lunii, cât și a restanțelor la data emiterii raportului. Acesta este foarte util către compartimentu contabilitate, si cel managerial, cât și celui care răspunde efectiv de situația încasărilor, putând vedea în ce sector exită probleme, în cazul în care este sectorizată localitatea, restanțe prea mari, încasări prea mici, etc.

Preluare Incasari / Emiteri – se consideră că periodic se fac încasări. În acest sens pentru a avea o evidență cât mai exactă trebuie să introducem facturile încasate. Se va lua în considerare că fiecare încasator are un anumit indice căruia i s-a alocat un câmp de 5 poziții. De exemplu încasările prin casierie, pentru identificarea acestui lucru ulterior se va considera ca indice C0105 unde C- de la casierie, și 0105 – ziua din lună și luna. Deci încasările prin casierie din data de 01/05/2005 se vor găsi în cele cu indicele C0105. Se activează din meniu prima opțiune Preluare incasari.

Se introduce indicele deja cunoscut după care se activează următoarea fereastră

Pare puțin complcat la prim avedere, dar e suficient să cunoaștem numărul facturii care trebuie de încasat, data la care lucrăm, și modul de încasare. La introducerea numărului de factură programul identifică factura cu pricina și ne sunt oferite informații despre ea, valoarea care trebuie încasată, persoana în cauză, data emiterii facturii. Ulterior se va alege din fereastra care se activează dup aceea modul de încasare, adică: IC -încasare totală a facturii prin casă, IB – încasare prin bancă, IO – încasare prin compensare, JR – se obține ulterior o listă cu restanțieri care se va trimite oficiului juridic, primărie, sau compartimentului de mediu. La fiecare din aceste obțiuni există posibiltate de efectare unor plăți parțiale care vor avea ca indici PC, PB, PO. În final pentru a nu greși ni se dă posibiltatea de a verifica dacă toate cele introduse corespund cu realitatea, daca da se activează câmpul CORECT din meniu și se trece la următoarea factura până la epuizarea încasărilor pe ziua respectivă. Dacă nu se actvează câmpul CORECTAȚI si ciclul se reia de la început nefectuându-se nici o modificare asupra bazei de date.

RAPOARTE URMARIRE – acest modul conține posibilitatea de a obține o multitudine de rapoarte legat de restanțe și restanțieri sau încasări. Fiind un modul destul de stufos ne vom ocupa doar de cele mai importante.

Restante pe elemente – la activarea acestui buton, se activează o serie de opțiuni care ne ajută în identificarea restanțelor după: sector; abonat, unde avem posibilitatea alegerii abonatului după numele acestia urmat de activarea opțiunii vizualizării restanțelor le ecran sau trimiterea acestora la imprimantă; după cod stradă; pînă la data, la alegerea acestei opțiuni ni se va activa un alt buton în care vom introduce data până la care vom dori obținerea informațiilor cu posibilitatea ulterioară de a fi vizualizate sau trimise la imprimantă; după nume stradă, foarte important aici de a introduse exact numele străzii; extras de cont, în cazul în care dorim să înștințăm prin poștă abonatul de restanțele acumulte cu ajutorul unui formular tip; pentru terminare putem să tastăm direct cifra 0 sau prin coborâre în meniu până la această obțiune;

Emiteri pe elemente – după sector, sau abonat, se vor obține liste cu valoarea facturilor emise strict în luna curentă, atât la ecran cât și la imprimantă

Se opțin informații diverse și pentru următoarele opțiuni atât la ecran cât și la imprimantă, principiul fiind același.

Ne vom ocupa doar de penultima opțiune fiind mai specială. Încasări pe Chitanțe – după ce s-au introdus încasările din ziua respectivă pentru a putea evidenția acest lucru în contabilitate se activeazăa acest modul. Se va obține o listă aferent încasării, care ulterior se va deconta în casierie. Lista se va diferenția prin indicativul dat în momentul întocmirii ei în modulul Preluare Incasări Emiteri , și în funcție de sector. Pentru o verificare în prealabil s-a lăsat la îndemâna utilizatorului de a alege dacă se face o vizualizare, sau se trimite direct la imprimantă lista.

SF. LUNĂ – operațiuni ce se execută la sfârșitul fiecărei luni o singură dată de preferință, dar se pot consulta rapoartele care le conține și în cursul lunii, iar modulul aferent salvărilor se poate activa zilnic

Producție facturată – se întocmește o listă în conformitate cu Codul de Procedură Fiscală, care se trimite biroului contabilitate. Acesta conține o listă care cuprinde toate facturile emise în luna respectivă, cu individualizarea fiecărei în parte, unde ne sunt aduse la cunoștință numărul de factură, cui este adresată, valoarea acesteia fără TVA, valoarea TVA, și valoarea totală. Există posibilitatea consultării listei la ecran sau trimiterea direct la imprimantă.

Producție încasată – o listă care conform opțiuni avem valoarea încasărilor după indicativul fiecărei zile, fiecărui sector. Ca și în meniul anterior se poate alege consultarea listei la ecran sau trimiterea ei direct la imprimantă.

Terminare – părăsirea aplicației

Creare fișiere luna următoare – modul prin care se activează modificările necesare aplicației pentru luna următoare. În acest sens în cazul în care ne răzgândim putem să completăm cimpul în care suntem interogați dacă suntem pregătiții cu litera N si părasim modulul. Dacă dorim continuarea, vom fi nevoiți a introduce si data inceputului lunii care

dorim să fie activată. În această etapă programul execută ștergerea facturilor care sunt încasate si modificarea unor câmpuri din fișierul abonați.dbf și pregătește fișierele pentru închiderea lunii. La terminarea acestui pas cel mai indicat ar fi salvarea fișierelor aferente perioadei, după care se poate trece la următoarea etapă. Aceasta este activată prin parolă deoarece pregătește fișierle pentru luna următoare în sensul în care se șterg o parte dintre ele respectv ab0506.dbf, și uc0506.dbf, ele fiind înlocuite cu ab0507.dbf , și uc0507.dbf , și golirea anumitor câmpuri.

Salvări – modul necesar salvărilor periodice. Programul de arhivare care este utilizat este arj.exe, și salvarile se pot face doar pe unitatea flopy. Se salvează doar fișierele cu extensia .dbf și cele cu extensia .mem

EXIT Acționarea acestu buton determină părăsirea aplicației.

V. Ghid de utilizare. Implementarea programului

După cum se poate observa, folosirea programului este facilă, permițând o utilizare cât mai eficientă a aplicației. Se instalează foarte ușor prin copierea fișierului executabil într-un director creat în prealabil. Acesta fiind generat de sine stătător, nu necesită căi suplimentare in fișierul config.sys. Aplicația este considerată una relativ simplă, după cunoașterea particularităților ei, respectiv codurile străzilor, prețuri, parole, etc. Introducerea parolelor a fost o necesitate, practica ne-a dovedit-o, pentru siguranța bazelor de date, împiedicarea efectuării de modificări neautorizate. Acestea se cunosc numai de către programator și modificarea lor ulterioară aparține tot lui.

Pentru rularea programului, după cum s-a văzut în capitolul anterior unde am descris programul propriuzis, nu necesită cunoștințe foarte avansate de informatică, activarea și mutarea dintr-un meniu în altul și utilizarea submeniurilor făcându-se cu ajutorul tastei ENTER și TAB, sau cu mous-ul

Pentru început se vor introduce abonații care au efectiv contracte, baza de date fiind goală, numărul de contract fiind și numărul de cod ce ne interesează pe noi. Va exista o codificare în prealabil a străzilor, care rămâne la latitudinea utilizatorului. Se poate face verificarea celor introduse prin listele care se vor consulta prin vizualizare la ecran sau trimiterea ei la imprimanta. La terminarea acestei etape se poate trece la facturarea efectivă a serviciilor. Se va cunoaște prețul, perioada facturată, numerele de facturi arondate. Se generează facturile și se poate începe încasarea celor care vin să plătească la casieria unității. În funcție de aceasta se pot realiza și tipării facturi efective celor care au venit la plată. Se pot edita diferite rapoarte care vor fi prezentate ulterior, iar la sfârșit de lună se vor executa procedurile necesare inițializării lunii următoare.

Bineînțeles, există posibilitatea dezvoltării și modificării acestei aplicații în continuare în funcție de dorințele utilizatorului.

Fiind un program dedicat unei anumite categorii de utilizatori, activitatea lor în legătură cu acest program va include și responsabilitatea cu privire la corectitudinea și confidențialitatea datelor introduse.

Bibliografie

Gabriel și Mihai Dima – Foxpro

Editura Teora 1994

Bob Grommes – Secretele Sistemului FoxPro 2.5

Editura Teora 1996

Codul