Instrumente DE Raportare A Performanțelor Unei Entități Economice

UNIVERSITATEA CREȘTINĂ „DIMITRIE CANTEMIR“ – BUCUREȘTI

FACULTATEA DE FINANȚE, BĂNCI ȘI CONTABILITATE

LUCRARE DE LICENȚĂ

INSTRUMENTE DE RAPORTARE A PERFORMANȚELOR UNEI ENTITĂȚI ECONOMICE

Coordonator științific:

Conf. Univ. Dr. Căpușneanu Sorinel

Absolvent:

GHIȚĂ V. DANIELA

BUCUREȘTI

2016

CUPRINS

Introducere

Lucrarea de față, “Instrumente de raportare a performanțelor unei entități economice” prezintă principalele instrumente de raportare utilizate în cadrul unei entități economice, începand cu aspectele teoretice și continuând cu aplicarea practică a acestora, toate acestea realizate în cadrul unei aplicații business, globală și integrată și cu ajutorul unui mediu de dezvoltare integrat.

Lucrarea este structurată pe patru capitole, capitole ce cuprind atât partea teoretică, dar și partea practică, ce conține modul de lucru în cadrul sistemului informatic implementat în cadrul unei entități economice.

În Capitolul 1, “Instrumente de raportare a performanțelor” sunt prezentate abordarile generale ale noțiunilor de instrumente de raportare și performanțe, precum și prezentarea instrumentelor de raportare a performanțelor utilizate în contabilitatea financiară și de gestiune.

Capitolul 2, “Cadrul general al contabilității de gestiune” prezintă cadrul legal de aplicare a contabilității de gestiune, principiile și factorii de organizare ai contabilității de gestiune și calculației costurilor. De asemenea, în cadrul acestui capitol se va prezenta tipologia costurilor precum și sistemul informațional și informatic al contabilității de gestiune.

În Capitolul 3, “Proiectarea sistemului informatic” sunt prezentate următoarele: detalii legate de analiza cerințelor sistemului informatic, proiectarea și implementarea funcționalităților sistemului informatic.

Capitolul 4, “ Studiu de caz privind instruméntele de raportare a performanțelor la o entitate economică” descrie entitatea economică, implementarea sistemului informatic în cadrul acesteia precum și intrumentele de raportare a performanțelor utilizate în cadrul entității, cu exemplificare în zona indicatorilor utilizați pentru faza de aprovizionare.

Capitolul 1: Instrumente de raportare a performanțelor

Abordări generale ale noțiunilor de intrumente de raportare și performanțe

Cuvântul performanță este de origine latină, dar semnificația sa vine din limba engleză. În latină, cuvântul “performare” constă în a finaliza o activitate propusă. ” To perform” presupune a realiza ceva care cere abilitate sau o anumită aptitudine. “Performance” traduce maniera cu care o organizație atinge obiectivele care I-au fost propuse.

În domeniul economic, s-au dat mai multe definiții noțiunii de performanță. în diversitatea de definitii se disting trei mari orientari: definitia performantei în funcție de nivelul de realizare a obiectivelor sale strategice, definitia performantei în funcție de crearea valorii și definitia performantei în funcție de productivitatea și eficacitatea întreprinderii.

Performanță în întreprindere reprezintă ceea ce contribuie la ameliorarea cuplului cost-valoare, și nu doar ceea ce contribuie la diminuarea costului sau la creșterea valorii. O întreprindere poate crea două tipuri de valori: o valoare externă și o valoarea internă:

Valoarea externă presupune că întreprinderea are o valoare de piață mai mare decât valoarea contabilă a activelor pe care le deține. Diferența între valoarea de piață a unui activ și valoarea sa contabilă este dată de creșterea preturilor activelor respective pe piață, creștere care nu poate fi influențată de deciziile interne în cadrul întreprinderii, ci de condițiile specifice pieței.

Valoarea internă presupune ca întreprinderea creează valoarea adaugată economică, deci o valoarea netă pozitivă după remunerarea tuturor factorilor de producție, incluzând aici și costul capitalurilor proprii.

În literatura economică din țara noastră, performanță întreprinderii se definește: “ o întreprindere este performanță dacă ea este în același timp productivă și eficace”, productivitatea reprezentând raportul dintre rezultatele obținute și mijloacele angajate pentru obținerea rezultatelor, iar eficacitatea reprezentând raportul dintre rezultatele obtinute și rezultatele asteptate.

Conceptului de performanță i se asociaza trei noțiuni: economicitatea (procurarea resurselor necesare la cel mai mic cost), eficiență (a maximiza rezultatele obținute, pornind de la o cantitate dată de resurse, fie a minimiza cantitatea de resurse pentru un rezultat prestabilit) și eficacitate (rezultatele obtinuțe să atingă rezultatele prevăzute).

Performanță reprezintă realizarea obiectivelor propuse. Poate fi pozitivă, dacă obiectivul propus este de a obține profit și negativa, dacă obiectivul propus este de a obține pierdere.

Rezultatul contabil este considerat principalul indicator pentru măsurarea performantei financiare a întreprinderii.

Prin modul său de calcul este orientat spre trecut, servind ca bază a evaluării rezultatelor obținute în urma desfășurării unui proces, în decursul unei perioade de timp trecute.

Informații despre performanță întreprinderii sunt solicitate de utilizatorii informației contabile. Obiectivul situațiilor financiare este acela de a oferi informații despre poziția și performanțele financiare și despre modificările în poziția financiară a întreprinderii.

Rezultatul contabil are și alte utilizări:

ghid al politicii de dividend și de acumulare; mijloc de predicție a rezultatelor viitoare, cu scopul de a lua decizii de investire sau dezinvestire;

mijloc de evaluare a capacității managementului de a conduce întreprinderea; mijloc de evaluare a deciziilor luate de alte grupuri legate de întreprinderea în cauza;

instrument managerial într-o serie de domenii din interiorul sau din afara întreprinderii(credibilitatea în fața organismelor de credit, reglementarea prețurilor în condiții de monopol).

Performanțele întreprinderii se pot aprecia pe baza unor indicatori, cum ar fi:

– ratele de rentabilitate;

– marja profitului;

– rata profitului;

– volumul absolut al cifrei de afaceri și a profitului.

Orice decizie economică pornește de la poziția financiară a întreprinderii și își propune realizarea unui anumit nivel de performanță.

Ca documente financiare pentru analiza poziției și a performanțelor întreprinderii se utilizează documentele sintetice, care sunt:

bilanțul contabil;

contul de profit și pierdere;

notele explicative.

Contul de profit și pierdere a fost considerat modul adecvat de raportare a performanței financiare, potrivit contabilității în costuri istorice.

Prezentarea intrumentelor de raportare a performanțelor din contabilitatea financiară și contabilitatea de gestiune

Raportarea performanțelor în contabilitatea financiară

Scopul contabilității este producerea de situații financiare a caror obiectiv costa în furnizarea de informații care sa ofere o imagine fidela a pozitiei financiare a entității economice, respectiv a performantei acesteia.

Fiecare componenta a situației financiare reflecta o anumită imagine a tranzactiilor și evenimentelor economice desfășurate în cadrul exercitiului financiar.

Dintre situațiile financiare realizate în cadrul unei entități, contul de profit și pierdere este instrumentul utilizat pentru evidentierea performanțelor întreprinderii.

Contul de profit şi pierdere este situaţia financiară care măsoară succesul sau performanţa activităţii unei entităţi economice, referitoare la o perioadă dată. Este vorba despre performanţa financiară a entităţii respective. Având în vedere faptul că rezultatele contabile sunt consecinţa aplicării unei serii de postulate şi principii contabile, şi în primul rând a independenţei exerciţiilor, constatării veniturilor şi conectării cheltuielilor la venituri, importanţa pe care o acordăm acestui document de sinteză trebuie să fie însoţită de o doză de prudenţă.

Contul de profit şi pierdere furnizează investitorilor şi creditorilor informaţii necesare previziunii valorilor, calendarului şi capacităţii entităţii economice de a genera fluxuri de trezorerie. În felul acesta, investitorii pot să evalueze cu mai mare exactitate valoarea economică a întreprinderii, iar creditorii pot să determine măsura în care entitatea economică va fi capabilă să-şi ramburseze datoriile.

Raportarea performanțelor în cadrul contabilității de gestiune

Contabilitarea de gestiune urmărește o serie de obiectivele de raportare a performanţelor entităţii prin calculul unor indicatori de performanţǎ finali sau intermediari, integrali sau parţiali prin care sǎ se evalueze gestiunea economico-financiarǎ a entitǎţii.

Performanţele raportate prin indicatori finali integrali se axeazǎ pe de o parte pe conceptual de rezultat al exerciţiului, iar pe de altǎ parte performanţele entitǎţii se raporteazǎ şi prin categoria de cost şi se poate dezvolta cu urmǎtoarele paliere:

–  determinarea rezultatelor economico-financiare pe funcţii ale entitǎţii şi a rentabilitǎţii globale;

–  determinarea rezultatelor economico-financiare pe activitǎţi ale entitǎţii şi a rentabilitǎţii acestora;

–  determinarea rezultatelor economico-financiare pe centre de profit şi a rentabilitǎţii centrelor de profit;

–  determinarea rezultatelor economico-financiare pe produse, lucrǎri şi servicii (PLS-uri) şi a rentabilitǎţii;

–  determinarea costului produselor, lucrǎrilor şi serviciilor realizate de entitate dar şi a costului structurilor funcţionale sau activitǎţilor entitǎţii.

Performanţele raportate prin indicatori de performanţǎ intermediari de gestiune se bazeazǎ pe unele concepte care pun în evidenţǎ anumite aspecte esenţiale ale gestiunii economice a entitǎţii în procesul de utilizare şi alocare a resurselor precum şi-n asigurarea autofinanţǎrii sau a echilibrului financiar şi se referǎ la urmǎtorii indicatori:

–  marja comercialǎ;

–  valoarea adǎugatǎ;

–  producţia exerciţiului;

–  excedentul brut de explotare;

–  capacitatea de autofinanţare;

–  rezerva managerialǎ;

–  fondul de rulment;

–  necesarul de fond de rulment;

–  trezoreria netǎ.

Prin aceste obiective, contabilitatea de gestiune “împinge” limitele de asistare a procesului managerial dincolo de cadrul activitǎţii de exploatare, pe terenul activitǎţii financiare a entitǎţilor.

Alte instumente de raportare a performanțelor

Reporting-ul

Reporting-ul este un instrument de evaluare și urmărire a performanțelor marilor firme. Reporting-ul se sprijină pe un sistem de contabilitate managerială adaptată la structura organizației, în așa fel încât fiecare manager să vizualizeze numai aspectele de care este responsabil.

Reportingul are la bază trei concepte și anume:

structura organizației. Multe întreprinderi consideră mai eficientă o descentralizare care ar duce la luarea deciziilor de către specialiști (marketing, resurse umane, finanțe, producție) la un nivel adecvat. Motivul, un manager general nu poate dispune de toate informațiile, în mod regulat pentru a lua decizii optime.

fixarea obiectivelor. Fiecărui manager pentru o anumită perioadă i se fixează obiective, și va lua decizii pentru a le atinge. Reporting-ul va măsura gradul de realizare a obiectivelor pentru perioada prevăzută.

controlabilitate. Fiecare responsabil poate fi controlat numai pentru acele cheltuieli și venituri care se află în aria sa de răspundere.

La origine reporting-ul este o practică specifică firmelor americane. În prezent, reporting-ul este întâlnit în toate companiile multinaționale ca instrument de monitorizare și raportare a performanței. Transmiterea informațiilor de la unitățile descentralizate către sediul societății-mamă se face cu mijloacele cele mai moderne de comunicație ( rețele informatice, rețele de telecomunicații).

Potrivit mai multor studii raportarea se face, în general, pe un formular standard, iar informațiile se transmit zilnic, săptămânal, decadal sau lunar, în grafic cu politica managerială a organizației.

Reporting-ul vizează numai indicatorii financiari axându-se mult pe controlul bugetar, calculul și analiza abaterilor. Prin conținutul informațional, acest instrument furnizează managerului informații financiare detaliate.

Balanța scorecard (Balanced Scorecard)

Balance Scorecard (BSC) este un sistem strategic de management ce gestionează activitățile companiei în funcție de viziunea și strategiile acesteia. Acest concept a fost prezentat pentru prima oară în numărul din februarie, anul 1992, al revistei Harvard Business Review de către profesorii Robert Kaplan și David Norton.

Sistemul constă în 4 procese:
• transpunerea viziunii în obiective operaționale
• comunicarea viziunii și conectarea acesteia la performanțele individuale
• planificarea afacerii
• feedback, învațare și ajustarea strategiei în funcție de parcurs.

Balance Scorecard se prezintă ca un instrument de urmărire a performanțelor organizat în jurul a 4 perspective care răspund la urmatoarele întrebari:

– perspectiva financiară, pentru a răspunde la întrebarea ‘‘Care sunt așteptările acționarilor?’’

– perspectiva clienți, pentru a răspunde la întrebarea ‘‘Care sunt exigențele clienților față de întreprindere?’’

– creștere și dezvoltare, pentru a răspunde la întrebarea ‘‘Pentru realizarea obiectivelor propuse, cum se va dezvolta întreprinderea?’’

– procese interne, pentru a răspunde la întrebarea ‘‘Pentru a-i satisface pe acționarii și clienții firmei, ce procese ”cheie” trebuie controlate?’’

“În Balanced Scorecard sunt menținuți indicatori financiari-contabili, însă se prezintă și indicatori privind clienții, privind calitatea, privind eficiența internă a întreprinderii și capacitatea acesteia de ameliorare și creștere pe termen lung.

Balanced Scorecard este destinat managerului unei întreprinderi sau directorului unui domeniu de activitate strategică (strategic business unit); deoarece furnizează indicatori caracteristici pentru patru dimensiuni diferite ale firmei, el poate fi considerat un instrument privilegiat de pilotaj global al performanței.

Prin balanța scorecard autorii au dorit să creeze pentru manageri un instrument care să pună în evidență relațiile cauzale între performanțele operaționale și rezultatele strategice ale firmei. Astfel, pentru a pilota funcționarea întreprinderii și nu doar controla rezulatele, Kaplan și Norton au propus indicatori de măsură a rezultatelor și indicatori generatori de performanță care au rolul de semnal de alarmă privind performanța. De exemplu, la o întreprinderede transport de mărfuri indicatorii de rezultate (cifra de afaceri, rezultatul exercițiului, rentabilitatea financiară, rentabilitatea utilizării activelor, rezultatul exploatării, excedentul de trezorerie din exploatare etc.) se află în relație de cauzalitate cu indicatori considerați ca fiind generatori de performanță ( viteza medie de transport pe distanțe lungi, viteza medie de transport pe distanțe scurte, cheltuieli de întreținere/tonă transportată, consum mediu de carburanți, gradul de încărcare a mijloacelor de transport, absenteism, număr de accidente de muncă etc).

Prin conținutul informațional, acest instrument de control al performanței globale este orientat către acțiune și anticipare, fiind rezultatul unui proces de selecție a datelor, astfel încât informațiile furnizate managerului să nu fie prea detaliate. De aceea, putem considera că, prin conținut și rol, acest instrument este asemănător cu tabloul de bord al direcției generale din practica firmelor franceze”.

Indicatorii Cheie de Performanță – KPIs (Key Performance Indicator)

Performanța strategică, operațională, la nivel de echipă sau individuală este un obiectiv major al oricarei companii. Pentru a putea aprecia în ce masură obiectivele organizaționale sunt atinse și strategiile de afaceri sunt eficiente, este absolut necesar să definim un sistem integrat de indicatori de performanță care să ne poată spune în orice moment dacă afacerea merge în direcția dorită sau nu. Mai mult, orice decizie managerială trebuie să se bazeze pe o foarte bună cunoaștere a stării curente a afacerii, ceea ce nu este posibil în absența unui sistem de indicatori de performanță care să informeze managementul despre rezultatele obținute în toate activitățile și procesele-cheie ale companiei.

Indicatorii Cheie de Performanță (KPIs) pot fi definiți ca măsuri care oferă managerilor cele mai importante informații de performanță care să le permită lor sau acționarilor să înțeleagă nivelul de performanță al organizației. KPI trebuie să fie legati într-un mod clar de obiectivele strategice ale organizației și prin urmare sa ajute la monitorizarea și executarea strategiei de afaceri.

Indicatori Cheie de Performanță (KPIs) ajută organizațiile să înțeleagă cât de performante sunt acestea în raport cu obiectivele și tintele lor strategice. În sensul cel mai larg, un KPI poate fi definit ca punerea la dispoziție a celor mai importante informații de performanță care să permită organizațiilor sau acționarilor să înțelege dacă organizația este pe drumul cel bun sau nu.

Motivele principale pentru măsurarea performanței sunt:

– Pentru a învața și de a îmbunătăți : scopul utilizării KPIs este de a dota angajații cu informațiile de care au nevoie pentru a lua decizii mai bine informați, care să conducă la îmbunătățiri. În acest context, KPI-uri sunt utilizate pe plan intern ca dovezi pentru deciziile de management, pentru a contesta ipotezele strategice și pentru învățarea și perfecționarea continuă.

– Pentru a raporta extern și a demonstra conformitatea: astfel, indicatorii KPIs au rolul de a informa actionariatul și de a respecta reglementările de raportare externe și solicitările de informații. Atunci când se măsoară pentru raportarea externă și respectarea regulamentului, toate rapoartele și indicatorii asociați, trebuie să fie produsi în mod obligatoriu, cum ar fi situațiile financiare anuale, declaratile sau rapoarte de performanță pentru autoritățile de reglementare.

– Pentru a controla și monitoriza oamenii: utilizați într-o manieră de comandă-și-control de sus în jos pentru a ghida și să controla comportamentele și acțiunile oamenilor. Aici, se folosesc măsuri pentru a stabili obiective sau reguli, pentru a accesa în mod obiectiv realizarea acestor obiective, și să ofere feedback cu privire la orice variație nedorită între realizări și obiective. Aici, scopul măsurări este de a elimina variația și de a îmbunătăți concordanța. În acest context, măsurile sunt adesea strâns legate de recompensa și structurile de recunoaștere. Cercetările au arătat că această abordare, dacă nu este bine implementată, poate fi periculoasă și de multe ori duce la o cultură în care oamenii se concentreză pe furnizarea de măsuri, dar nu de performanță.

Capitolul 2: Cadrul general al contabilității de gestiune

2.1 Cadrul legal de aplicare a contabilității de gestiune

Contabilitatea de gestiune este reglementată prin Legea contabilității nr. 82/1991.

Potrivit prevederilor acestei legi, republicată în Monitorul Oficial al României nr. 454/2008, persoanele juridice prevăzute la art. 1 alin. (1) din lege au obligația de a organizeza și de a conduce contabilitatea proprie, inclusiv contabilitatea de gestiune adaptată la specificul activității.

Potrivit prevederilor art. 11 alin. (1) din Legea nr. 82/1991, republicată, răspunderea pentru activitățile de organizare și conducere a contabilității de gestiune, adaptate la specificul activității, revine personei nume în funcția de administrator sau altei persoane juridice care are obligația gestionării unității respective.

Contabilitatea de gestiune trebuie sa asigure, conform activităților desfășurate în cadrul întreprinderii, următoarele activități:

înregistrarea operațiilor privind colectarea și repartizarea cheltuielilor pe destinații, respectiv pe activități, sectii, faze de fabricație, centre de costuri, centre de profit, dupa caz,

calculul costurilor (de achizitie, de producție, de prelucrare al bunurilor, etc.) din unitățile de producție, comerciale, prestatoare de servicii, financiare și alte domenii de activitate.

Utilizând contabilitatea de gestiune, persoanele juridice pot obține informații care să asigure o gestionare eficientă a patrimoniului, respectiv:

informații legate de costul bunurilor, lucrarilor, serviciilor, pentru persoanele juridice care desfasoara activități de producție, prestari de servicii, precum și de costul bunurilor vandute pentru persoanele juridice care desfasoara activitate de comert;

intormații utilizate în cadrul proceselor de bugetare și control al activității de exploatare;

informații utilizate în cadrul analizelor financiare care stau la baza fundamentării deciziilor de management în vederea conducerii activității interne;

alte informații necesare realizării unui management performant.

Contabilitatea de gestiune este organizată de administratorul persoanei juridice utilizand urmatoarele proceduri:

conturi specifice,

prin dezvoltarea conturilor din contabilitatea financiară,

evidența tehnico-operative proprii.

Folosirea conturilor contabile se efectuează astfel încât sistemul gestionare și accesarea informațiilor să fie flexibilă și să permită o gamă largă de opțiuni. Lista conturilor contabile aferente contabilității de gestiune este adaptată scopurilor urmarite:: evidentierea veniturilor și a rezultatelor în funcție de activitatea care le generează, stabilirea fluxului costurilor, determinarea costurilor asociate stocurilor, efectuarea unor previziuni etc.

Contabilitatea de gestiune furnizează informații necesare elaborării de rapoarte și analize interne utilizate de managementul unității în luarea deciziilor. Cerintele de prezentare și analiză a informațiilor oferite de contabilitatea de gestiune nu sunt limitative. În cadrul organizării contabilității de gestiune se are în vedere ca informațiile obținute să satisfacă atât necesitățile de informare existente, cât și pe cele în continuă schimbare.

Procedeele și tehnicile utilizate în contabilitatea de gestiune se stabilesc în funcție de caracteristicile calitative ale informațiilor cerute de utilizatori, precum și de particularitățile activității desfășurate.

În ceea ce privește calculația costurilor, conform Legii Contabilității Nr. 82/1991, aceasta presupune ansamblul lucrărilor efectuate într-o formă organizată cu scopul de a obține informații privind costul bunurilor, lucrărilor, serviciilor, activităților sau altor obiecte de calculație.

Organizarea lucrărilor privind calculația costurilor depinde de o serie de factori, cum ar fi: mărimea unității, structura organizatorică a acesteia, tipul și modul de organizare a producției etc.

Contabilitatea de gestiune clasifică cheltuielile cu scopul determinării costurilor unitare astfel încât bunurile, lucrările, serviciile să poată fi evaluate și recunoscute în contabilitatea financiară, iar prețurile de vânzare să poată fi stabilite și verificate, precum și în vederea realizării unei analize a costurilor și a eficientei activității.

În contabilitatea de gestiune cheltuielile se clasifica în:

costuri de achizitie;

costuri de producție;

costuri de prelucrare;

cheltuieli ale perioadei.

2.2 Principii și factori de organizare ai contabilității de gestiune și calculatia costurilor

Principiile contabilității de gestiune și calculației costurilor

Respectarea principiilor teoretice și metodologice care stau la baza organizării contabilității de gestiune și calculației costurilor duc la calcularea cât mai exactă a costului de producție și exercitarea controlului bugetar, dar asigură și posibilitatea comparării rezultatelor obținute cu ale unității din alte perioade sau cu ale unităților similare din cadrul aceleiași ramuri.

Principiile contabilității de gestiune și calculației costurilor sunt:

Principiul delimitarii cheltuielilor în timp

Respectarea acestui principiu permite aprecierea activității fiecarei perioade de gestiune, respectiv exercitiu financiar.

Acest principiu presupune stabilirea unei legături intre momentul efectuarii cheltuielilor și momentul realizarii producției.

Astfel, cheltuielile se împart în:

– cheltuieli anticipate care se efectuează înainte de desfășurarea activității și se includ eșalonat în costul produsului;

– cheltuieli curente care se efectuează în momentul desfășurării activității;

– cheltuieli previzionate sau cheltuieli cu provizioanele care au loc după efectuarea activității.

Principiul delimitării cheltuielilor în spațiu

Conform acestui principiu, orice cheltuială se poate aloca unui centru de responsabilitate, respectiv loc de desfășurare a activității.

Delimitarea în spațiu sau pe locuri de cheltuieli, respectiv centre de costuri se face atât în scopul evidenței și calculației costurilor care au drept scop stabilirea cât mai reală ca mărime și structura a costurilor la nivelul fiecarei structuri funcționale a unității, cât și cu scop funcțional de conducere eficientă a activității desfășurate în locurile respective pe baza criteriilor de rentabilitate.

Principiul delimitării cheltuielilor productive de cele cu caracter neproductiv

Acest principiu are la bază diferențierea din punct de vedere economic între cheltuielile productive, care sunt creatoare de valoare și cele cu caracter neproductiv, care nu contribuie la procesul de creare a valorii sau mărimii valorii.

Cheltuielile cu caracter productiv se includ în costul produsului, în timp ce cheltuielile cu caracter neproductiv se includ în costul perioadei, exprimând gradul de gospodărire necorespunzătoare și conducerea neeficientă a producției.

Principiul separării cheltuielilor care privesc obținerea bunurilor, lucrărilor, serviciilor de cheltuielile care nu sunt legate de achiziția, producția sau prelucrarea acestora

Acest principiu presupune separarea cheltuielilor atribuite obiectelor de calculație de cheltuielile ocazionate de restul activității. Conform OMFP nr.1826/22.12.2003 pentru aprobarea precizărilor privind unele măsuri referitoare la organizarea și conducerea contabilității de gestiune, în costul produselor, lucrărilor și serviciilor prestate nu se includ:

– cheltuielile financiare : pierderi din vânzarea titlurilor de plasament ; diferențele de curs valutar din operații curente și disponibilități în valută ; pierderi din creanțe legate de participații ; dobânzi curente aferente împrumuturilor primite și altor datorii privind exercițiul în curs ; sconturi acordate clienților. Fac excepție cheltuielile cu dobânzile aferente împrumuturilor contractate pentru producția cu ciclu lung de fabricație, care se pot repartiza asupra costurilor de producție aferente producției respective;

– cheltuielile extraordinare care nu sunt legate de activitatea normală, curentă a unității patrimoniale: amenzi, penalități, despăgubiri, perisabilități, lipsuri la inventar, donații și subvenții acordate, chiar și cele în scopuri umanitare, pierderi din debitori diverși și alte cheltuieli excepționale;

– cheltuieli generale de administrație și cheltuielile de desfacere care sunt excluse din calculul costului unitar, excepție făcând cazurile în care conditiile specifice de exploatare impun luarea lor în consideratie ;

– costul subactivității nu se regăsește în costul produselor, regasindu-se direct în rezultatul exercitiului. Tot aici se includ și pierderile datorate calității necorespunzătoare a produselor realizate (rebuturi și deseuri).

Principiul documentarii

Acest principiu constă în fundamentarea întregii calculații a costurilor pe baza documentelor justificative, din care rezultă pentru fiecare element de cost cantitatea și valoarea consumurilor realizate în scopul realizării producției.

Principiul calculației unice

Acest principiu presupune că fiecare cost se calculează o singură dată.

Factori de organizare ai contabilității de gestiune și calculației costurilor

Organizarea contabilității de gestiune se face diferentiat în cadrul unei entități patrimoniale, în funcție de conditiile de desfășurare a activității, de particularitatile specifice activității, particularitati regasite în factorii de organizare.

Factorii de organizare ai contablitatii de gestiune și calculației costurilor sunt :

Mărimea întreprinderii

Mărimea întreprinderii determină și structura organizatorică pe fabrici, secții, ateliere, etc., dar se organizează și activitatea financiară – contabilă în sistem centralizat ( pentru firme mai mici), și/sau în sistem descentralizat pentru întreprinderi mari. Această organizare determină atât fluxul informațional cât și o delimitare și structurare a costurilor.

Caracterul producției

Producția realizată în cadrul unei întreprinderi poate fi permanentă sau sezonieră. În funcție de perioada în care se desfasoară activitatea și se obțin produsele, se repartizează și cheltuielile. Cheltuielile variabile se regăsesc numai în perioada de activitate, iar cheltuielile fixe se regăsesc tot timpul anului ( chiar dacă se realizează o activitate sezonieră).

Tipul producției

Producția realizată în cadrul unei întreprinderi poate fi încadrată în una din urmatoarele categorii : producție de masă, producție de serie sau producție unicat.

În funcție de tipul producției realízate se aplică metoda de calculație a costurilor: metoda globală, metoda pe faze sau metoda pe comenzi.

Tehnologia de fabricație și gradul de automatizare al producției

În funcție de acestea sunt stabilite tehnic etapele parcurse de la intrarea materiei prime și până la obținerea produsului finit. Aceste etape determină și etapele de calculație și implicit structurile pe posturi, procede de calculație și modul de determinare al costului unitar.

2.3 Tipologia costurilor

În ceea ce priveşte clasificarea costurilor, literatura de specialitate relevă, de asemenea, existenţa unei multitudini de criterii, în funcţie de care se pot clasifica cheltuielile încorporate în cost. Însă, în cele ce urmează, vor fi evidentiate cele mai importante dintre aceste criterii şi cele mai des utilizate în practica economică actuală:

A. După posibilitatea identificării cheltuielilor cu produsele realizate, serviciile executate şi lucrările prestate:

1. Costuri directe: reprezintă acele cheltuieli care se încorporează direct în costul produselor, lucrărilor şi serviciilor, în cadrul lor fiind înglobate costurile directe cu materiile prime şi materialele, precum şi costurile directe cu munca vie, cum ar fi salariile directe ale celor implicaţi în mod direct în activitatea de producţie.

2. Costuri indirecte: sunt acele costuri care înglobează cheltuieli ce nu pot fi alocate în mod direct asupra produselor realizate, serviciilor prestate, lucrărilor executate. Exemple de astfel de cheltuieli sunt: cheltuieli cu salariile personalului din biroul de contabilitate; cheltuieli cu materialele; cheltuieli cu amortizarea echipamentelor utilizate în activitatea de producţie. Aceste costuri indirecte trebuie să fie repartizate pe baza unor chei de alocare (de repartizare), pentru ca împreuna cu costurile directe să formeze costul total.

B. După comportamentul lor în raport cu activitatea de producţie se disting:

1. Costuri fixe: reprezintă costuri care încorporează cheltuieli care apar indiferent de volumul activităţii desfăşurate şi al căror nivel nu depinde de volumul producţiei. Exemple de astfel de cheltuieli sunt: cheltuieli cu asigurarea imobilelor; cheltuieli cu plata chiriei; cheltuieli cu întreţinerea spaţiilor.

2. Costuri variabile: sunt acele costuri care sunt direct proporţionale cu volumul producţiei şi variază în raport cu aceasta. În cadrul acestor costuri variabile se disting: costurile material directe care intră direct în costul produselor şi a serviciilor şi costurile generale variabile, care sunt influenţate de capacitatea de producţie realizată. Un exemplu de cost general variabil este costul energiei electrice consumate de către echipamentele de fabricaţie.

C. După funcţia lor în cadrul ciclului de afaceri:

1. Costul produsului: include toate elementele de cost care sunt generate de realizarea unui

produs, executarea unei lucrări sau prestarea unui serviciu. Astfel, costul produsului

cuprinde costurile materiale, costurile salariale şi alte costuri de producţie.

2. Costul perioadei: are în vedere toate elementele de cost care nu au fost incluse în costul produsului, dar înglobează cheltuieli care s-au realizat în cursul exerciţiului financiar de referinţă. Exemple de cheltuieli recunoscute în costul perioadei ar fi: cheltuieli general administrative, cheltuieli de distribuţie, cheltuieli cu plata chiriilor pentru spaţiile de birouri, cheltuieli cu asigurarea clădirii administrative. Costurile de vânzare şi cele administrative sunt tratate ca fiind costuri ale perioadei, fiind considerate ca având un caracter indirect.

D. În funcţie de gradul de control şi posibilitatea managementului de a influenţa costurile:

1. Costuri controlabile: reprezintă acele elemente de cost asupra cărora managerul are posibilitatea de a-l influenţa. Exemplu de cost controlabil: costul salarial.

2. Costuri necontrolabile: include acele elemente de cost care sunt determinate de terţe părţi din mediul extern al entităţii şi asupra cărora managerul nu poate interveni. Exemplu de cost necontrolabil: costul generat de primele de asigurare ale spaţiului productiv.

E. În funcţie de contribuţia lor la asistarea procesului decizional al managementului:

1. Costul marginal: reprezintă costul ultimei unităţi de produs asociat unei creşteri de la un volum al producţiei la altul. Acesta poate avea numai caracterul unui cost variabil.

2. Costul diferenţial: este un concept de cost mai larg decât cel marginal, deoarece are în vedere costul ultimei unităţi de produs datorat oricărei schimbări în costul total al activităţii, incluzând atât creşterile de cost, cât şi şi reducerile de cost între doua alternative ale volumului de producţie. Costul diferenţial poate avea atât caracterul unui cost fix, cât şi caracterul unui cost variabil.

3. Costul de oportunitate: acest cost se stabileşte ca şi un cost al alegerii generat de acţiunea realizată în două situaţii (alternative) diferite. Sau altfel spus, este un cost determinat de alegerea unei alternative atunci când se dispune de resurse limitate. Prin renunţarea la un plan de acţiune, elementele pozitive ale planului de acţiune respins devine un cost de oportunitate.

Un concept de cost relevant în practica entităţilor economice este costul complet, care reprezintă acel cost care încorporează toate consumurile generate de obţinerea şi desfacerea unui produs (obiect de cost), incluzând în structura sa atât costul de producţie, cât şi costul non-producţie.

Fig. 1 : Elementele costului complet

2.4 Sistemul informațional și informatic al contabilității de gestiune

Legăturile dintre diversele părți ale unei entități economice trebuie să satisfacă cerințe de calitate și promptitudine care pot proveni fie din interiorul entității economice, fie din exteriorul entității economice (de exemplu de la clientul care vrea să știe starea în care se află execuția unei comenzi lansate în producție).

Orice analiză economică a unei entități economice are la bază informația și modul în care aceasta este vehiculată, astfel încât degradarea ei să fie minimă și fără pierderi de semnificație.

Un sistem informațional se compune dîntr-o mulțime de subsisteme intercorelate care lucrează împreună pentru colectarea, prelucrarea, stocarea, transformarea și distribuirea informației pentru planificare, luarea deciziilor și control.

Fiecare sistem informațional se poate descompune în trei componente principale: intrările, prelucrările și rezultatele. Intrarea într-un sistem informatic poate fi formată din date sau din informații.

Operând cu informații, ca și materie primă, contabilitatea este văzută ca fiind „o tehnică de ordin cantitativ, de colectare, prelucrare și analiză a informațiilor privind fluxurile economice din activitatea unei întreprinderi.

Privită ca și activitate specializată în măsurarea, evaluarea, cunoașterea, gestiunea și controlul activelor, datoriilor și capitalurilor proprii, precum și a rezultatelor obținute, contabilitatea trebuie să asigure – potrivit art. 2, alin. (1) al Legii contabilității nr. 82/1991 republicată – înregistrarea cronologică și sistematică, prelucrarea, publicarea și păstrarea informațiilor.

Sistemul informațional contabil poate fi definit ca fiind ansamblul mijloacelor, procedeelor și metodelor utilizate pentru colectarea, consemnarea, prelucrarea, transmiterea, utilizarea și stocarea informațiilor contabile.

Funcția de informare a contabilității constă în furnizarea informațiilor în scopul fundamentării deciziilor. Contabilitatea are o funcție de informare internă (pentru managementul întreprinderii) și o funcție de informare externă (a terților). Informațiile furnizate de contabilitate stau la baza procesului decizional atât în interiorul cât și în exteriorul întreprinderii.

Contabilitatea furnizează informații cu privire la modul de gospodărire a resurselor de care dispune (materiale, financiare, umane), evoluția producției obținute, costurile de producție, veniturile realizate etc. După gradul de transparență, informațiile furnizate de contabilitate se grupează în două mari categorii:

– informații total transparente: cele care se referă la poziția și performanța financiară.

Acestea fac obiectul contabilității financiare. Se obțin după reguli precizate de Ministerul Finanțelor Publice, au deci un caracter normat, publicându-se în vederea informării corecte a tuturor persoanelor interesate;

– informații mai puțin transparente: cele care se referă la calculația costurilor, structura bugetelor întreprinderii, cunoașterea performanțelor interne etc. Acestea fac obiectul contabilității de gestiune. Nu au un caracter normat și nu sunt divulgabile marelui public, întrucât țin de secretul de întreprindere.

Având în vedere această delimitare a informațiilor, sistemul informațional contabil al întreprinderii are două componente: una care se ocupă de furnizarea informațiilor în exterior – contabilitatea financiară și alta, care furnizează informații doar celor din întreprindere – contabilitatea de gestiune. Astfel, contabilitatea de gestiune (internă, managerială, de exploatare, analitică) considerată „fața internă” a întreprinderii.

Contabilitate de gestiune este întâlnită în literatura de specialitate și sub denumirea de managerială, internă, analitică sau de exploatare, făcâdu-se referire la acea contabilitate care tinde să descompună cât mai analitic posibil activitatea unei entități patrimoniale, și care trebuie să servească managerilor de la diferite nivele organizatorice, pentru necesitățile lor de informare.

Contabilitatea de gestiune este orientată către conducătorii (gestionarii) întreprinderii, adică utilizatorii interni de fonduri. Aceasta, prin informațiile furnizate, vine în completarea contabilității financiare. Aceasta furnizează managerilor informații despre conducerea activității, cunoașterea costurilor și rezultatelor, nu numai global ca în cazul contabilității financiare, ci și pe activități și obiecte de calculație etc.

Caracterul intern, confidențial, al informațiilor furnizate de contabilitatea de gestiune reprezintă o recunoaștere a autonomiei decizionale a agenților economici într-o economie de piață concurențială. „Contabilitatea analitică „mulează” informațiile relativ rigide ale contabilității generale și le adâncește în funcție de specificul productiv-comercial și de structurare internă al fiecărui agent economic, argument pentru care organizarea contabilității analitice rămâne atributul exclusiv al unității”.

Persoanele juridice pot obține, prin contabilitatea de gestiune, informații care să asigure o gestionare eficientă a patrimoniului, respectiv:

– informații legate de costul bunurilor, lucrărilor, serviciilor, pentru persoanele juridice care desfășoară activități de producție, prestări de servicii, precum și de costul bunurilor vândute pentru persoanele juridice care desfășoară activitate de comerț;

– informații care stau la baza bugetării și controlului activității de exploatare;

– informații necesare analizelor financiare în vederea fundamentării deciziilor manageriale privind conducerea activității interne;

– alte informații impuse de realizarea unui management performant.

Contabilitatea de gestiune, prin sistemul informațional, asigură furnizarea informațiilor despre evoluția fenomenelor economice din cadrul întreprinderilor, informații de care managerii au nevoie în condițiile de concurență ale economiei de piață.

Întrucât managerii fiecărei întreprinderi sunt cei care știu de ce informații au nevoie, în legătură cu ce, cât de detaliate, la ce intervale de timp, în funcție de acestea, ei vor recurge la un mod specific de organizare a unui sistem informațional al contabilității de gestiune, în vederea satisfacerii propriilor necesități de informații.

Este în responsabilitatea fiecarei unități să își definească un sistem informațional propriu (canale proprii de comunicare, persoane responsabile etc.). Astfel, sistemul informațional al contabilității de gestiune poate fi definit ca fiind totalitatea procedeelor, mijloacelor și regulilor utilizate pentru culegerea, prelucrarea, transmiterea, utilizarea și stocarea informațiilor contabile nedivulgabile publicului.

Sistemul informațional al contabilității de gestiune trebuie să fie unul foarte bine dezvoltat, structurat corespunzător, astfel încât, prin multiplele subdiviziuni organizatorice pe care le are sub lupă și prin informațiile furnizate echipei de conducere, pentru fundamentarea deciziilor, să asigure derularea în bune condiții a activității întreprinderii. Responsabilitatea creării unui sistem informațional al contabilității de gestiune, propriu întreprinderii revine contabilului de gestiune, o persoană care este implicată activ în tot ceea ce înseamnă organizarea și conducerea contabilității de gestiune la nivelul întreprinderii.

Capitolul 3: Proiectarea sistemului informatic

Analiza cerințelor sistemului informatic

Analiza nevoilor și fluxurilor de lucru specifice unui companii este un demers important, care precede ofertarea unui sistem informatic dedicat.

Obiectivul analizei este de a indentifica cerințele prezente și viitoare și de a veni în întampinarea lor cu o soluție fiabilă, scalabilă, completă.

Decizia de a face o investiție într-un sistem informatic trebuie dublată de o analiză corectă a cerințelor și necesităților și a modului în care software-ul ofera soluții pentru acestea.

O astfel de analiză presupune:

întelegerea mecanismelor și a procedurilor;

identificarea nevoilor de raportare și frecventa lor;

propunerea celei mai bune soluții din punct de vedere al timpului de implementare, al costurilor sau al posibilității de interconectare și de extindere pe viitor;

propunerea unei soluții care întrunește cerințele de securitate, consistență și arhivare a datelor.

În această etapă inițială se examinează posibilitatea realizării unui nou sistem informatic – în cadrul sistemului informațional pentru conducere – sau modificării sistemului existent. Scopul principal al acestei etape este de a răspunde la următoarea întrebare: este noul sistem pe care dorim să-l introducem în organizație oportun din punct de vedere tehnic, economic și operațional?

Pentru relizarea unei analize preliminare există trei concepte de bază:

– se face o evaluare sumară a organizației, pentru a putea obține o justificare a folosirii sistemului de calcul

– se studiază obiectivele și domeniile de probleme generale și specifice ale organizației respective, pentru a încerca să se demonstreze beneficiile aduse de automatizare.

– se studiază amanunțit organizația pentru a întelege structura organizatorică, modul ei de funcționare, scopul și obiectivele acesteia.

Abordarea unuia sau altuia dintre concepte depinde de o serie de factori: timpul disponibil, personalul afectat și complexitatea lucrărilor, gradul de precizare al obiectivelor sistemului, nivelul de pregatire al unității, al conducerii și al personalului pentru introducerea unui sistem informatic.

Prelucrarea computerizată a datelor va ușura munca operatorilor și va reduce din timpul alocat ținerii acestei evidențe.

Proiectarea sistemului informatic

Proiectarea logică

Etapa are un triplu scop:

– determinarea cerintelor logice ale noului sistem, în concordantă cu obiectivele ce urmeaza a fi atinse;

– (re)proiectarea sistemului informațional, plecând de la cerintele stabilite, cu precizarea zonelor unde va interveni prelucrarea automată a datelor;

– întocmirea specificațiilor de definire a sistemului, care vor constitui fundamentul pe care se va realiza etapa următoare (proiectare tehnică).

Proiectarea logică reprezintă practic o examinare mult mai amănunțită a elementelor care au fost abordate în cadrul analizei preliminarii, nivelul de detaliu la care se coboară trebuie să permită:

– verificarea ca sistemul propus va asigura îndeplinirea obiectivelor;

– elaborarea unui raport de costuri și beneficii (cantitative și calitative) care să ajute conducerea în luarea deciziei de continuare a lucrărilor.

Prin activitățile ce se desfasoară în această etapă, trebuie în fond determinate, ținând seamă de cerințe, prelucrarile logice și posibile ce vor fi efectuate în noul sistem (ce este logic și posibil să se facă).

Proiectarea tehnică (fizică)

Este etapa în care se definitivează mijloacele tehnice necesare (echipamente, programe, fisiere, proceduri manuale) prin care fluxul informațional stabilit anterior este trasformat într-un flux cu prelucrare automată a datelor. Pricipala activitate va fi deci elaborarea unor specificații (denumite specificații de realizare) pentru componentele de bază ale sistemului informatic și pentru procedurile de interfață cu sistemul informațional.

Efortul principal este de proiectare pură, dar cu tehnici și metode specifice prelucrării automate, accentul trebuind pus pe calitatea specificațiior întocmite, în sensul asigurării tuturor elementelor necesare pentru realizare unor rezultate corespunzătoare în etapele care urmează.

Frecvent, datele din proiectarea logică pot fi gasite incomplete, astfel că vor fi necesare iterații și corecții care pot afecta soluția propusă din punct de vedere tehnologic, economic sau operațional. în special în acest caz estimările trebuie revăzute și soluțiile reavizate.

Dacă în etapa de proiectare logică se definitivează, în primul rând ce trebuie făcut, acum se stabilește cum să se facă.

Proiectarea tehnică se împarte în două sub-etape distincte:

– proiectarea sistemului cu întocmirea specificatiilor de realizare (definitivarea soluțiilor tehnice) la nivel de sistem.

– proiectarea componetelor sistemului (subsisteme si/sau aplicatii) cu elaborarea specificatiilor pe componente.

Trecerea la a doua sub-etapă se recomandă să se facă numai după ce rezultatele primeia au fost avizate și însușite de beneficiar. Activitățile vor fi astfel desfășurate și detaliate încăt să permită să se definitiveze în special urmatoarele aspecte:

– care este structura sistemului pe componente (subsisteme și aplicații), cum se face legătura între componente,

– ce probleme vor fi rezolvate cu ajutorul sistemului electronic de calcul, integral sau partial,

– ce date, programe de calcul și proceduri manuale sunt necesare pentru aceasta,

– cum vor fi asigurate datele,

– ce configurații de calcul (hardware și software) sunt necesare,

– care sunt legăturile între procedurile automate, manuale și combinate,

– care sunt costurile și beneficiile noului sistem,

– cum se va face trecerea de la vechiul la noul sistem (conversia).

3.3 Implementarea sistemului informatic

Etapa începe când componentele individuale, care au fost testate și acceptate, pot fi ansamblate pentru testarea și includerea în sistem/sub-sistem, pe baza specificațiilor și manualelor elaborate în etapa anterioară.

Principalele etape alte implementarii sunt:

Realizarea planului de proiect, împreună cu beneficiarul, pentru a evidenția aria de acoperire a proiectului, etapele, durata lor și persoanele implicate;

Realizarea unei analize amănunțite a cerințelor la nivel de utilizator, maparea fluxurilor de lucru și ale celor de raportare;

Propunerea celei mai bune soluții din punct de vedere software și hardware, conform cu nevoile beneficiarului și evidențierea eventualelor riscuri;

Importul datelor din istoric sau din aplicații terte în noua platformă informatică;

Configurarea layout-urilor conform nevoilor fiecărui departament, urmarte de trainingul utilizatorilor;

Asistența acordată utilizatorilor post-implementare pentru a asigura buna funcționare și utilizare a sistemului informatic;

Etapa se termină când sistemul sau subsistemul este acceptat de organizatie și este luat în primire de compartimentul de exploatare, împreună cu documentația definită.

Capitol 4: Studiu de caz privind instrumentele de raportare a performanțelor la o entitate economică (Orange România)

4.1 Prezentare generală

Orange România S.A. este cel mai mare operator GSM din România. Până în aprilie 2002, Orange a operat sub brand-ul Dialog, marca fiind gestionată de firma Mobil Rom. La sfârșitul anului 2013, Orange România avea peste 10,4 milioane de clienți, ceea ce îi conferea o cotă de piață de peste 40%.

Orange România este filiala românească a operatorului global de telefonie mobilă Orange SA, divizia de telecomunicații mobile a France Telecom. Orange România este deținut în proporție de 96,8% de France Telecom.

Orange România controlează de asemenea 4,33% din activele operatorului moldovean Orange Moldova (fost Voxtel).

În cadrul companiei sunt mai multe departamente care asigură desfăsurea activităților. Printre aceste departamente se numără și departamentul Financiar.

Misiunea departamentului Financiar al companiei constă în a se asigura că investiția acționarilor este optimizată, în contextul îndeplinirii regulilor interne ale companiei și al legislației țării, în a stimula valoarea creată în cadrul business-ului, în a oferi informații financiare care sa faciliteze luarea de decizii, în a oferi suport pentru eficientizarea costurilor, adaptat nevoilor operaționale și în optimizarea managementului riscului în concordanță cu legile și regulile naționale și internaționale.

Să asigure corectitudinea situațiilor/informațiilor financiare (raportare și balantă)

Să optimizeze fluxurile specifice de trezorerie

Să optimizeze riscul monetar al companiei și profitabilitatea, cu scopul atingerii targetelor de profit și lichidități

Să măsoare performanța competiției în domeniul telecom (pentru a facilita luarea de decizii)

Să optimizeze calculul taxelor pentru bugetele de stat locale și centrale și să ofere consultanta financiară altor departamente

Să stabilească și să aplice procesele de management administrativ și financiar (angajamente, numiri și delegări)

Să protejeze Orange România de pierderea/scurgerea de venituri și fraudă, prin stabilirea unor controale care nu restrictionează veniturile

Să centralizeze și să îmbunatatească calitatea și funcționarea proceselor în cadrul departamentului Financiar

Să centralizeze și să îmbunătătească funcția de raportare (atât actual, cât și planning)

Să fie un vector de progres pentru manageri

Să asigure și să optimizeze procesul de achiziție în ceea ce privește calitatea și prețurile pentru bunurile și serviciile cerute de toate departamentele Orange România

Să genereze plus valoare și să optimizeze alocarea de resurse

Să acceleze eforturile de transformare și să protejeze crearea de cash flow

Să continue oferirea de suport pentru eficientizarea costurilor adaptate cerințelor de business.

Diego Martinez Lopez este Chief Financial Officer în cadrul Orange România din anul 2013 și are în subordine cele 6 sub-departamente ale departamentului Financiar:

• Accounting &Tax

• Controlling

• Cash & Risk

• Real Estate& Car Fleet Management

• Purchasing

• Security

Departamentul Financiar utilizează pentru înregistrarea tuturor operatiilor, precum și realizarea raportării aplicația de tip ERP (Enterprise Resouce Planning), Oracle E-Business Suite.

Implementarea sistemului informatic

Tehnologiile informatice utilizate

Oracle E-Business Suite (EBS) este o soluție completă de management al informației care vine să satisfacă la cel mai înalt nivel al încrederii, provocările apărute ca urmare a globalizării. EBS este o suită de aplicații integrate la cel mai înalt nivel tehnologic.

Aceasta soluție completă, deschisă și perfect integrată asigură o dublare a perfomanțelor procesării în loturi și gestionează de patru ori mai mulți utilizatori online.

Oracle optimizează performanțele fiecărei componente a Oracle E-Business Suite pe ansamblul de discuri individual, ca parte a ansamblului, de la aplicații prin Oracle Database și sistemul de operare Oracle Solaris, la servere și la stocare. Software-ul Oracle este proiectat pentru a beneficia de caracteristicile speciale ale serverelor Oracle Sun SPARC și ale Sun Storage, inclusiv de nivelurile ridicate de tehnologie cache threading și flash, fără a neglija standardele open și interoperabilitatea. Clienții pot implementa rapid această soluție și își pot îmbunătați rentabilitatea investiției. Integrarea completă asigură fiabilitate, securitate și disponibilitate îmbunătățite.

Avantajele implementării soluției Oracle E-Business Suite:

Table 1 : Avantajele implementării soluției Oracle E-Business Suite

PL/SQL (Procedural Language/Structured Query Language) este un limbaj procedural creat de Oracle. PL/SQL permite ca manipularea datelor și procedurile de interogare din SQL să fie incluse în blocuri stucturate.

Se pot defini variabile și structuri de tip tablouri indexate și record în memorie. Permite definirea elementelor de tip Cursor pentru prelucrarea individuală și secvențială a înregistrărilor rezultate din interogările SQL. Asigură definirea unor programe, proceduri și funcții stocate în BD. Permite controlul informațiilor și accesului la nivel superior prin proceduri de tip TRIGGER asociate comenzilor de modificare. Permite definirea unor clase de obiecte utilizator, care permit implementarea conceptului de baze de date relațional obiectuale. Accesul la PL/SQL se face de către utilizatori prin SQL*Plus și nu direct. În PL/SQL se execută numai comenzile proprii, iar comenzile SQL care accesează baza de date se execută pe Serverul SQL. PL/SQL are câteva sute de funcții și proceduri proprii.

PL/SQL Developer este un mediu de dezvoltare integrat, care este destinat dezvoltării de programe pentru bazele de date Oracle. De-a lungul timpul s-a constatat că din ce în ce mai multe aplicații se mută în zona Oracle Server, deci programarea PL/SQL a devenit o parte importantă a procesului de dezvoltare. PL/SQL Developer se caracterizează prin ușurință în folosire, calitatea codului, avantaje în timpul dezvoltării aplicațiilor în Oracle.

Facilitățile utilizării acestui program software de dezvoltare sunt următoarele:

• editor PL/SQL puternic;

• depanator integrat (necesita Oracle 7.3.4 sau mai mult);

• PL/SQL Beautifier;

• SQL Window;

• Command Window;

• rapoarte;

• proiecte;

• articole To-Do;

• manuale HTML;

• obiecte Non-PL/SQL;

• Template List;

• Query Builder;

• Compare User Objects;

• Export User Objects;

• unelte;

• autorizare;

• instalare facila.

Cerințele sistemului sunt: PL/SQL Developer rulează sub Windows 95, 98, ME, NT4, 2000 și XP. Versiunile Oracle Server suportate sunt 7.x, 8.x, 8i, 9i și 10g pe orice platformă. Pentru conectare la o baza de date Oracle, PL/SQL Developer necesită 32-bit SQL*Net, Net 8, Net 9 sau Net 10.

Implementarea funcționalităților sistemului informatic

Funcționalitățile sistemului informatic sunt următoarele: crearea anumitor tipuri de documente necesare în procesul de aprovizionare, precum documentele care conțin necesarul de aprovizionat (Requisition), documente care conțin comanda de achiziție (Purchase Order), lansarea documentelor spre aprobare la persoanele care au autorizația necesară de a realiza acest lucru, recepția comenzilor de achiziție și operațiile de setup în sistem pentru definirea rapoartelor și rularea acestora de către utilizatori din sistem.

Fig.2: Procesul de business de la Aprovizionare la Plata

Documentele care conțin necesarul de aprovizionat sau documentele de tip Requisition se introduc în sistem de către utilizatorii desemnați cu rol de Requester, Contract Supervisor.

Fig.3: Interfața de creare documente de tip Requisition

După ce se completează informațiile dorite în interfața Requisitions, documentul se trimite mai departe pe flux, pentru a putea fi aprobat de către superiorii ierarhici.

În interfața folosită pentru aprobarea documentelor de tip Requisition, utilizatorul aprobă documentul respectiv.

Primul pas este acela de căutare a documentelor de Requisition lansate pe fluxul de aprobare. Se caută după anumite criterii, printre care și numele intern al tipului de flux: „REQAPPRV”.

Fig.4: Interfața pentru aprobarea documentelor de tip Requisition (1)

Al doilea pas este acela de a selecta documentul dorit a se aproba.

Fig.5: Interfața pentru aprobarea documentelor de tip Requisition (2)

Al treilea pas este acela de aproba notificarea primită prin accesare iconiței din dreptul câmpului Notification și aprobarea în sine în cadrul ferestrei nou deschise.

Fig.6: Interfața pentru aprobarea documentelor de tip Requisition (3)

Fig.7: Interfața pentru aprobarea documentelor de tip Requisition (4)

În figura următoare se poate observa terminarea procesului de aprobare și totodată, sfârșitul fluxului de aprobare pentru documentul de tip Requisition.

Fig.8: Interfața pentru aprobarea documentelor de tip Requisition (5)

După etapa de aprobare a documentelor de tip Requisition de către superiorii ierarhici, pasul următor este acela de a crea comenzi de achiziție (Purchase Orders) prin procesul de autocreare pe baza documentului aprobat.

Documentele de tip Purchase Orders (PO) se emit de catre utilizatorii cu rol de Purchasing Administrator, dupa marcarea informațiilor necesare de catre utilizatorul cu rol Buyer ( Purchaser), prin opțiunea de autocreare din documente de tip Requisition.

Utilizatorul cu rol Buyer are posibilitarea de a realiza modificari pe linia de requisition, poate popula informații legate de furnizorul alocat comenzii, precum și marcarea conditilor de facturare negociate și evidentierea Saving-urilor, respectiv a procentului KPI realizat pentru fiecare linie din comanda.

Inițial se deschide o fereastră în care se caută liniile care aparțin documentului de Requisition creat și aprobat. Se pot introduce mai multe criterii de cautare.

Fig.9 Interfața pentru căutarea liniilor documentelor de tip Requisition

După terminarea căutării, în fereastra de autocreare a documentelor de tip Purchase Order, se selectează linia pentru care se dorește editarea informațiilor și se apasa butonul Zoom din bara de meniu.

Fig.10: Interfața pentru autocreare a documentelor de tip Purchase Order pentru documentele de tip Requisition create și aprobate

Fig.11: Forma custom utilizata pentru configurarea detaliilor financiare pe liniile de requisition aprobate

Dupa configurarea informațiilor necesare, utilizatorul cu rol Purchaser aloca documentul de tip Requisition catre un Purchasing Administrator pentru generarea bonului de comanda.

Fig.12: Interfața pentru căutarea liniilor documentelor de tip Requisition

După terminarea căutării, în fereastra de autocreare a documentelor de tip Purchase Order, se selectează linia pentru care se dorește crearea automată a comenzii de achiziție.

Fig.13: Interfața pentru autocreare a documentelor de tip Purchase Order pentru documentele de tip Requisition create și aprobate

După inițierea creării automate, se creează documentul de tip Purchase Order și se trimite spre aprobare.

Fig.14: Interfața care prezintă documentul de tip Purchase Order creat automat și care permite trimiterea acestuia spre aprobare

Aprobarea comenzii de achiziție se realizează în cadrul aceleași interfețe ca și în cazul aprobării documentelor de tip Requisition.

Fig.15: Interfața pentru aprobarea documentului de tip Purchase Order

Tranzacțiile de tip Receipt (sau recepțiile comenzilor de achiziție) se folosesc în cazul în care se face recepția efectivă a articolului livrat conform scrisorii de acceptare/notei interne de recepție întocmite de către un utilizator cu rol de Receiver și după verificarea conformității dintre articolele de pe documentul de recepție și cele din comanda de achiziție.

Recepția se face accesând o anumită responsabilitate și funcție din cadrul acesteia și completand criteriile de căutare în fereastra de căutare, precum în Fig.16:

Fig.16: Fereastra de căutare pentru crearea de recepții a comenzilor de achiziție

Fereastra care prezintă antetul documentului de recepție prezintă informații generale cu referire la recepția respectivă.

Fig.17: Fereastra care prezintă antetul documentului de recepție

Fereastra alternativă de linii este fereastra în care se face tranzacția de recepționare. Liniile recepției afișate în această fereastră corespund shipment-urilor aprobate și deschise ale comenzii de achiziție. În momentul poziționării pe una din aceste linii, în josul ecranului într-o fereastra neactualizabilă apar informații despre respectivul shipment preluate din documentul de tip Purchase Order: tipul documentului OA, furnizorul, descrierea articolului, locul de distribuție, nota către utilizatorul cu rol de receiver introdusă în comanda de achiziție la nivel de header (TERMS) sau la nivel de shipment, etc.

Fig.18: Fereastra în care se face tranzacția de recepționare

Rapoartele dezvoltate și parametrii acestora de rulare sunt descriși în tabelul din Anexa 2.

Implementarea funcționalității de definire și rulare a rapoartelor dezvoltate procedural în programul software PL/SQL Developer este descrisă în pașii următori:

este construită procedura în PL/SQL Developer;

se definește în cadrul Oracle E-Business Suite, executabilul care are la bază shema bazei de date sub care s-a creat pachetul și procedura (opțional), numele pachetului și numele procedurii;

Fig.19: Interfața pentru definirea executabilului

Toate executabilele definite în cadrul sistemului sunt prezentate în tabelul următor:

Table 2: Tabel cu executabilele definite în sistem

se definesc liste de valori corespunzătoare parametrilor definiți în pasul următor;

Fig.20: Interfața de definire a listei de valori (1)

Fig.21: Interfața de definire a listei de valori (2)

Listele de valori definite în cadrul sistemului pentru rapoartele dezvoltate sunt prezentate în tabelul următor:

Table 3: Tabel cu listele de valori definite în sistem

se definește în cadrul Oracle E-Business Suite, programul / raportul prin definirea unui nume după care se va identifica în sistem, a parametrilor și a altor caracteristici precum: formatul de afișare a rezultatelor, caracteristicile de afișare a parametrilor etc. Printre raportele dezvoltate se numara: ORO – KPI2F informațion report, per period (pentru vizualizarea codului unei proceduri stocate care stă la baza raportului, a se vedea Anexa 2);

Fig.22: Interfața pentru definirea programului

Fig.23: Interfața pentru definirea parametrilor

Un exemplu de program / raport definit în raport, alături de parametri și alte caracteristici legate de afișarea câmpului de completat din interfață corespunzător parametrului sunt prezentate în tabelul următor:

Table 4: Tabel cu programele definite în sistem

se definește în cadrul Oracle E-Business Suite, grupul de responsabilități de unde utilizatorul poate rula raportul;

Fig.24: Interfața pentru asignarea raportului la un grup de responsabilități

Toate programele / rapoartele asignate la diferite grupuri de responsabilități.

rularea propriu-zisă a rapoartelor se realizează prin accesarea de către utilizator a responsabilității corespunzătoare grupului de responsabilități la care s-a atașat raportul, de unde în continuare se procedează astfel: în fereastra corespunzătoare responsabilității de unde se rulează, se accesează din partea superioară a ferestrei, View Requests : Submit a New Request Single Request (Fig. 25) și se alege din lista de valori, numele raportului. Se completează parametrii, apoi se apasă butonul Submit.

Fig. 25: Interfața din care se lanseaza rularea raportului

Fig.26: Interfața unde se selectează numele raportului și se completează parametrii raportului

Rezultatele sunt afișate prin acționarea butonului View Output, iar eventualele erori, prin acționare butonului View Log din fereastra de mai jos:

Fig.27: Fereastra de vizualizare a rapoartelor

Rezultatele se afișează într-o fereastră de browser. Rezultatele pot fi transferate intr.-un document excel, pentru analiza.

Instrumente de raportare a performanțelor

În cadrul Orange România se utilizează o serie de indicatori de performanță specifici fiecarui sub-department din cadrul departamentului Financiar.

Pentru sub-departamentul de achiziții, analizat în cadrul acestui proiect, raportarea performenței este realizată prin evidențierea următorilor indicatori:

Indicatori de eficiență ai procesului de achiziție

Indicatori de eficiență ai etapei de negociere

4.3.1 Indicatori raportare a eficienței procesului de achiziție

Următorii indicatori sunt utilizați pentru a măsura eficiența procesului de aprovizionare. Rezultatele sunt integrate într-un tablou de bord trimestrial prezentat de responsabilul din sub-departamentul de achiziții.

Tabloul de bord este emis trimestrial și este parțial completat și validat de către manageri. După verificarea și validarea informației, tabloul este prezentat șefului departamentului de Aprovizionare iar la sfârșitul anului, CFO .

Timpul mediu de emitere al bonului de comandă (PO) de la data aprobării necesarului de aprovizionare (Requisition) – pentru a fi considerat un flux eficient, angajatul cu rol Purchasing Administrator trebuie să emită bonul de comandă (Purchase Order) în două zile lucrătoare de la data aprobării transmiterii necesarului de aprovizionare (Requisiton), interval calculat de la data primirii documentului de la angajatul cu rol Buyer.

Fig. 28: Raport ORO – Requisitions Approval Time

Timpul mediu de aprobare al bonului de comandă (Purchase Order) – pentru raportarea acestor informații se utilizează raportul „PO Approval Time” disponibil în aplicația Oracle Application, în modului de achiziții. Acest raport calculează timpul mediu de aprobare al documentelor emise în intervalul marcat în parametrii raportului, fiind luate în considerare zilele dintre data emiterii bonului de comandă și data aprobării acestuia (inclusiv zile nelucratoare) .

Fig. 29: Raport ORO – PO Approval Time Details

Fig. 30: Output Raport ORO – PO Approval Time Details

Raportarea se face trimestial, la începutul fiecarui trimestru fiind evidențiate valorile trimestrului anterior.

Valorile țintă pentru acest indicator sunt :

3 zile pentru bonurile de comandă de tip Release

5 zile pentru bonurile de comandă Standard.

4.3.2 Indicatori de raportare a eficienței a etapei de negociere

În modului de achiziție din Oracle Application au fost definite o serie de raporte pentru evidențiarea indicatorilor de performanță de tip KPI. Acestea sunt utilizate pentru monitorizarea periodică a evoluției procentelor de economisire și corelarea planificării bugetare cu valorile realizate.

Raportarea este realizată lunar, în conformitate cu programul de raportare comunicat de grup.

În cadrul raportării sunt evidențiați următorii indicatori de tip KPI:

Saving (Year-to-Date) realizat de la începutul anului raportat sub formă de:

Saving CR(Cost Reduction – K€) – economisire realizată prin reducerea costului efectuat în comparație cu prima ofertă obținută de la furnizor (discount).

Saving CA (Cost Avoidance – K€) – economisire realizată prin evitarea unor costuri în cadrul unui proiect, prin obținerea unor produse/servicii în mod gratuit din partea furnizorului la achiziționarea unei oferte.

Saving CI (Cash In – K€) – economisire realizată sub forma unui discount primit la facturare, exprimat printr-o factură de tip storno.

KPI2F – indicator calculat ținând cont de economisirea totală realizată raportată la bugetul alocat unui proiect.

2. Spend before negotiation – prima oferta obtinuta de la furnizor, calculat ca sumă a valorilor livrate în perioada raportată și valoarea saving-urilor realizată în acea perioadă.

3. Saving procentual (%) – calculat ca raport între Saving-urile efectiv realizate de la începutul anului și cheltuielile anticipate înaintea etapei de negociere

4. Saving procentual (%) versus target stabilit – calculat ca raport între Saving-urile efectiv realizate de la începutul anului și obiectivul de economisire asociat unui an.

Indicatorii de performanță KPI sunt declarați trimestrial în tabloul de bord al sub-departamentului de achiziții. Această raportare este trimisă către CFO, către șeful de departamentului de achiziții și către toți managerii din zona de achiziții.

Model rapoarte Oracle Application utilizate pentru raportarea indicatorilor KPI:

ORO – KPI2F informațion report, per period

Request-ul realizeaza un export al informațiilor de tip KPI/Saving asociate documentelor, în funcție de document type, buyer sau de data crearii acestora.

Fig. 31: Raport ORO – KPI2F informațion report, per period

Fig. 32: Rezultat Raport ORO – KPI2F informațion report, per period

Document Type – Requisition

Fig. 33: Rezultat Raport ORO – KPI2F informațion report, per period

Document Type – Purchase Order

ORO – Sourcing performane report – Actual KPIs

Raportul este rulat de angajatul cu rol Sourcing Coordinator și afișează coloanele din matricea de Demand Plan Codes existenta (indiferent de status active sau inactive sau dacă au valori în perioada selectată) și se completează coloanele de KPI cu recepțiile efectuate într-o anumită perioada, respectiv PO-urile/Releasurile create într-o anumită perioada și saving-urile aferente.

Fig. 33: Raport ORO – Sourcing performane report – Actual KPIs

Raportul calculează pe fiecare semestru în parte ce valori s-au recepționat și în funcție de procentele salvate la nivel de header PO/BPA, respectiv linii PO se calculează saving-urile aferente.

ORO – Sourcing performane report – Effective KPIs

Raportul este rulat de angajatul cu rol Sourcing Coordinator și afișează coloanele din matricea de Demand Plan Codes existenta (indiferent de status active sau inactive sau dacă au valori în perioada selectată) și se completează coloanele de KPI cu PO-urile/Releasurile create într-o anumită perioada și saving-urile aferente.

Fig. 34: Raport ORO – Sourcing performane report – Effective KPIs

Raportul calculează pe fiecare perioada în parte ce valori s-au comandat și în funcție de procentele salvate la nivel de header PO, respectiv linii PO se calculează saving-urile aferente.

ORO – Requestor KPI Verif

Raportul este construit în scopul verificarii activităților efectuate de angajatii cu rol Requestor. Raportul afișează linii de PO, release-urile aferente și detaliile corespunzatoare pentru PO-urile cu date_to_be_received sau promised_date <= ultima zi a lunii actuale în care se ruleaza request-ul. Bonurile de comanda afisate sunt aprobate sau în curs de aprobare, fiind eliminate cele nu sunt anulate.

Rezultatele se afișează în output, în format text.

ORO – Export KPI (all)

Raportul este construit în scopul verificarii activităților efectuate de angajatii cu rol angajatilor care interactioneaza cu fluxul de achizitie Requester/ Buyer . Raportul afișează linii de PO, release-urile aferente și detaliile corespunzatoare pentru aceste documente.

Informațiile returnare contin detalii cu privire la Saving-urile/KPIs realizate în funcție de tipul acestora.

Fig. 35:: Raport ORO – Export KPI (all)

Concluzii

În lucrare s-au descris cadrul organizatoric al companiei ca spațiu de desfășurare a activităților prezentate în lucrare, noțiunile generale despre instrumentele de raportare a perfomantelor, proiectarea și implementarea unui sistem informatic precum și procesul de aprovizionare din cadrul companiei, etapa de recepție și etapa de depozitare a bunurilor achiziționate.

Prin analiza cerințelor sistemului informatic, au fost prezentate funcționalitățile sistemului informatic în care se desfășoară activitățile.

Proiectarea sistemului informatic a prezentat etapa proiectare logica realizata prin analiză și proiectarea tehnica prin realizarea interfețelor sistemului, proiectarea bazei de date, schema conceptuală a bazei de date și descrierea tabelelor folosite.

Implementarea funcționalităților sistemului informatic a descris tehnologiile informatice utilizate și implementarea funcționalităților sistemului informatic.

Scopul lucrării a fost acela de a prezenta modul de raportare a indicatorilor de performanță raportați în cadrul unei companii, exemplificând cazul sub-departamentului de achizitii, parte a departamentului financiar, prin descriererea pasilor începand cu procesul de aprovizionare, prin utilizarea celui mai complet portofoliu de soluții integrate business inteligence, ca fiind cea mai adaptabilă platformă globală de afaceri și cu strategia de aplicații cea mai orientată spre client, Oracle E-Business Suite folosit pentru introducerea de date în sistem, prin crearea diverselor documente și pentru raportare, unde se prezintă informații din baza de date utilizatorilor pentru o fluidizare a activității de aprovizionare, pentru o reducere a numărului de erori datorate diverselor cauze, pentru o reducere a timpului de analiză a anumitor date, raportarea indicarilor de performanță, ajutând utilizatorii în luarea unor decizii și asigurând o bună monitorizare a performanței procesului de aprovizionare.

Mai pe scurt, lucrarea „Instrumente de raportare a performanțelor unei entități economice” a prezentat notiuni generale teoretice legate de modul de raportare a performanțelor unei entități, integrarea informațiilor în cadrul unei aplicatii informatice, precum și evidențierea procesului de raportare al indicatorilor de la introducerea datelor în sistemul informatic până la construirea și rularea rapoartelor, toate acestea fiind realizate în cadrul unei aplicații business, globală și integrată, cu ajutorul unui mediu de dezvoltare integrat.

BIBLIOGRAFIE

Achim S.(coordonator), Contabilitate managerială, Suport de curs, 2014

Briciu Sorin, Sistemul informațional al contabilității de gestiune, Universitatea „1 Decembrie 1918” Alba Iulia

Bădoi Maria, Legea contabilității comentată, Universul Juridic, București, 2013

Chirața Caraiani, Mihaela Dumitrana (coordonatori) – Contabilitate de gestiune și control de gestiune, Ediția II – a – Editura Universitară, București 2008

Chirața Caraiani, Mihaela Dumitrana (coordonatori) – Costurile. Concepte, structuri. Costul în procesul decizional

Chirilă Emil – Definirea și măsurarea performanței întreprinderilor, Universitatea din Oradea, Facultatea de Ştiinte Economice, Oradea 2004

Drăgan C. M., Noua contabilitate managerială, Editura „Hercules”, București, 1992

Ion Ionașcu (coordonator) – Control de gestiune, Editura ASE, 2002, București

Lepădatu Gheorghe, Contabilitate financiară, Ed. Pro Universitaria,2015, București

Mihalciuc Camelia, Contabilitate Financiară aprofundată, Curs pentru învăţământ la distanţă, Universitatea „Ştefan Cel Mare”, Facultatea de Ştiinţe Economice şi Administraţie Publică , Suceava 2008

Monitorul Oficial al României nr. 48/2005

Oprea Calin, “Contabilitate de gestiune și calculatia costurilor” Ed. Genicod, București, 2002

Vasilescu Ramona, Sisteme Informatice De Contabilitate, Note de curs pentru uzul studenților de la ÎFR, Universitatea Tibiscus Timișoara, Timișoara, 2008

Oracle Purchasing User Guide, Release 11i, Volum 1, Mai 2003

Documentație internă care aparține unei organizații:

“Documentație funcțională pentru modulul Oracle Purchasing”,

“Manual de utilizare pentru modulul Oracle Purchasing”

http://www.ap-institute.com/what-is-a-key-performance-indicator.aspx

Acasa

https://epmromania.wordpress.com

http://www.hamorsoft.ro

http://www.investopedia.com/terms/k/kpi.asp

http://intraapp.office.orange.intra

http://www.manageranticriza.ro

http://education.oracle.com

https://ro.wikipedia.org

http://teamnet-dedalus.ro

ANEXE

Anexa 1: Glosarul privind abrevierile și explicațiile aferente, pentru termenii folosiți în lucrare.

ERP = Enterprise Resource Planning.

OA = Oracle Applications.

BOQ = Listă de produse și servicii.

BE = Business Engagement subdepartment (TD/BE).

BIS = Business Informațion Systems sub epartment (TD/BIS).

NET = Neworks subdepartment (TD/NET).

TD = Technology Department.

TP, TPUR = Technical Purchasing.

Supplier = furnizor de produse/servicii care este cuprins în baza de date Oracle.

Requester = orice angajat permanent al companiei care identifică nevoia unui produs/serviciu și inițiază o cerere de achiziție.

Project Coordinator (Proj Co) = persoana din Technology Department / Business Engagement /Pre–Sales Support care verifică din punct de vedere transversal achiziția, verificând cantitatea cerută, stocul, încadrarea bugetară și planificarea. PC finalizează achiziția prin emiterea documentelor de acceptanță.

Document OA = oricare din cele patru tipuri de înregistrări Oracle care corespund unor documente de achiziție folosite în companie (Standard Purchase Order, Blanket Purchase Agreement, Blanket Release, Contract Purchase Agreement).

Document de recepție = scrisoare de acceptare/nota internă de recepție.

Purchasing Administrator (PA) = persoană din cadrul sub-departamentului Purchasing Administration, care:

– emite și urmărește documentele de achiziție (standard și contracte);

– emite OP imprimate, le trimite pentru semnare și le prezintă angajaților cu rol de Buyer;

– aprobă plata facturilor;

– asigură legătura cu furnizorii pentru rezolvarea problemelor legate de facturare;

– furnizează rapoarte legate de achiziții.

Cerere de Oferta (RFQ) = cerere scrisă trimisă către furnizori, în scopul de a afla specificațiile produselor, prețurile și condițiile de cumpărare.

Cotație = document Oracle prin care se înregistrează oferta primita de la furnizor în urma transmiterii unei cereri de cotație (RFQ).

Requisition (REQ) = document Oracle utilizat pentru definirea și aprobarea nevoii de achiziție și pe baza căruia se creează un PO.

Standard Purchase Order (PO) = document Oracle prin care se înregistrează cererea de bunuri sau servicii către un anumit furnizor.

Blanket Purchase Agreement (BPA) = document Oracle care corespunde unui contract ce are stabilite articolele, iar prețurile și valoarea totală au fost agreate.

Blanket Release (BR) = comandă de achiziție emisă dîntr-un acord de achiziție de tip BPA.

Contract Purchase Agreement (CPA) = document Oracle care corespunde unui acord cadru

Receiver = persoană care recepționeaza bunuri sau servicii furnizate de un furnizor și emite documentele de primire.

Buyer/Purchaser = persoană în cadrul sub-departamentului Purchasing (Aprovizionare) sau sub-departamentului Tehnic, numit pentru fiecare domeniu de achiziție, care:

investighează piața furnizorilor și găsește potențiali furnizori;

trimite documentele contractuale către furnizori (PO-urile semnate și contracte) și sprijină Supervisorii (Contract)/receptorii din cadrul departamentelor beneficiare care se ocupă cu recepția , livrarea și alte probleme contractuale.

acționează ca punct unic de contact pentru departamentul de cumpărare;

coordonează procesul de RFQ/achiziție pentru departamentul beneficiar, după cum urmează:

eliberează documentele de tip cerere de cotatie (RFQ) – specificații comerciale, contract, scrisori comerciale;

selectează furnizoriii în conformitate cu procedurile interne și cu domeniul de aplicare al specificațiilor tehnice emise de către Supervisor Contract;

negociază termeni comerciali (preț / termenele de plată / termeni de livrare / și condiții / sancțiuni pentru companie;

elaborează contracte cu sprijinul Contract Supervisor și consilier juridic și coordonează procesul de evaluare a performanței furnizorilor;

semnează fiecare pagină a contractului pentru conformitatea între documentul negociat (ultima versiune) și documentul de execuție;

cere și obține dovezi cu privire la împuternicirea reprezentantului legal al furnizorului;

evaluează proiectele de achiziție / ofertele comerciale și propune lista scurtă și alege furnizorul final din punct de vedere comercial și contractual;

urmărește desfășurarea contractelor în timpul procesului de transfer între diferite entități din cadrul departamentului de beneficiar;

oferă previziuni privind volumele de achiziție și furnizorii strategici pentru produsele reglementate.

– oferă suport pentru Purchasing Administrator în relațiile cu furnizorii pentru problemele legate de facturare;

– oferă suport pentru Purchasing Administrator în raportarea lunară a dispozițiilor financiare și angajamente.

Purchasing Administrator = este cel care introduce PO-ul și îi urmărește livrările, plațile, iar Purchaser-ul este cel care a negociat cu furnizorul respectiva comandă/contract

Contract Supervisor = persoană autorizata să inițieze cereri de achiziție într-un sistem extern, responsabil cu monitorizarea operațională a unui contract, care:

– inițiază procesul de achiziție prin definirea necesității / proiectului (domeniul de aplicare a contractului);

– participă la selectarea furnizorului în conformitate cu procedura de gestionare a furnizorilor și procedura de achiziție;

– participă la negocierea contractelor și este responsabil pentru: definirea domeniului de aplicare a contractului, definirea drepturilor de furnizorul /livrabilele, definirea riscurilor asociate cu încălcare a contractului din partea furnizorului;

– îndeplinește toate formalitățile / procedurile legate de aprobarea contractului și a cheltuielilor aferente;

– urmărește punerea în aplicare și închiderea contractului (îndeplinirea obligațiilor contractuale de către furnizor), informează superiorul direct și Buyer-ul;

– supraveghează livrările de bunuri / servicii și îndeplinirea clauzelor contractuale de către furnizor;

– după livrare, asigură distribuția de bunuri/ servicii comandate pentru Requester-i;

– semnează acceptanța pentru bunurile/serviciile livrate și informează Buyer-ul cu privire la aspectele legate de performanța furnizorului și starea proiectului, dacă este cazul, inclusiv escaladarea problemelor.

Budget Control/ Controller = persoană din cadrul Departamentului Financiar/Controlling responsabil cu validarea PO-urilor emise în OA modulul Purchasing, verifică dacă există buget disponibil, dacă PO a fost corect emis din punct de vedere de bugetar și contabil (natura bugetului, centrul de cost, codul de proiect și contul).

TVA = impozit general care se aplică pe fiecare stadiu al circuitului de producție al produsului final.

Anexa 2 : Raporte definite în sistem pentru raportare indicatorilor KPI aferenți fluxului de Aprovizionare

Anexa 3: Exemplificare sursă cod raport evidențiere informații indicatori KPI

procedure xxmds_kpi2f_info_period(errbuf OUT VARCHAR2,

retcode OUT VARCHAR2,

p_doc_type în varchar2,

p_creation_date_from în varchar2,

p_creation_date_to în varchar2,

p_buyer în varchar2);

–ORO – KPI2F informațion report, per period

procedure xxmds_kpi2f_info_period(errbuf OUT VARCHAR2,

retcode OUT VARCHAR2,

p_doc_type în varchar2,

p_creation_date_from în varchar2,

p_creation_date_to în varchar2,

p_buyer în varchar2) is

v_req_value number;

v_po_value number;

v_req_no number;

i number := 0;

v_req varchar2(20);

v_po_no number;

i1 number := 0;

v_po varchar2(20);

v_bpa_no number;

i2 number := 0;

v_bpa varchar2(20);

begin

if p_doc_type = 'REQUISITION'

then

apps.fnd_file.put_line(apps.fnd_file.output,

'Document No.' || '|' || 'Line' || '|' ||

'Document Submitted Date' || '|' ||

'Document Approval Date' || '|' ||

'Document Type' || '|' ||

'Document Description' || '|' ||

'Document Value' || '|' || 'Currency' || '|' ||

'Line Value în Euro' || '|' || 'Buyer' || '|' ||

'Purchaser' || '|' || 'Requester' || '|' ||

'Promised Date' || '|' || 'Need by Date' || '|' ||

'Budget Code(Activity)' || '|' ||

'Organisation (Cost Center)' || '|' ||

'Project Code' || '|' || 'KPI2F Value(Keuro)' || '|' ||

'KPI2F Value(%)');

for rec1 în (select distinct prh.segment1 doc_no,

prh.requisition_header_id,

prla.line_num line_num,

(select trunc(pahh.action_date)

from PO_ACTION_HISTORY pahh

where pahh.action_code = 'SUBMIT'

and pahh.object_id =

prh.requisition_header_id

and pahh.object_type_code =

'REQUISITION'

and pahh.sequence_num =

(select min(sequence_num)

from PO_ACTION_HISTORY

where action_code = 'SUBMIT'

and object_id =

prh.requisition_header_id

and object_type_code =

'REQUISITION')) req_submit_date,

(select trunc(pahh.action_date)

from PO_ACTION_HISTORY pahh

where pahh.action_code = 'APPROVE'

and pahh.object_id =

prh.requisition_header_id

and pahh.object_type_code =

'REQUISITION'

and pahh.sequence_num =

(select max(sequence_num)

from PO_ACTION_HISTORY

where action_code = 'APPROVE'

and object_id =

prh.requisition_header_id

and object_type_code =

'REQUISITION')) req_approved_date,

'Requisition' doc_type,

replace(replace(replace(replace(prh.description,

chr(10),

null),

chr(13),

null),

'|',

' '),

chr(09),

null) doc_desc,

nvl(prla.currency_code,

'RON') currency_code,

(select distinct per.full_name

from per_all_people_f per

where per.person_id =

prla.suggested_buyer_id) buyer,

(select distinct per1.full_name

from per_all_people_f per1

where per1.person_id = prh.attribute6) purchaser,

(select distinct per2.full_name

from per_all_people_f per2

where per2.person_id = prh.preparer_id) requester,

null promised_date,

prla.need_by_date,

gcc.segment13 budget_code_activity,

gcc.segment4 organisation_cost_center,

gcc.segment7 project_code,

to_char(replace(prla.global_attribute11,

',',

''),

'FM999,990.0999') kpi2f,

round((prla.quantity * prla.unit_price) /

decode(nvl(prla.currency_code,

'RON'),

'EUR',

1,

hr_currency_pkg.get_rate('EUR',

nvl(prla.currency_code,

'RON'),

prla.creation_date,

'Corporate')),

4) doc_value_euro,

case

when replace(prla.global_attribute11,

',',

'') < 1 then

to_char(round((prla.quantity *

prla.unit_price) *

nvl(replace(prla.global_attribute11,

',',

''),

0) /

(1 – nvl(replace(prla.global_attribute11,

',',

''),

0)) /

decode(nvl(prla.currency_code,

'RON'),

'EUR',

1,

hr_currency_pkg.get_rate('EUR',

nvl(prla.currency_code,

'RON'),

prla.creation_date,

'Corporate')) / 1000,

4),

'FM999,990.0999')

when replace(prla.global_attribute11,

',',

'') >= 1 then

to_char(round((prla.quantity *

prla.unit_price) *

nvl(replace(prla.global_attribute11,

',',

''),

0) /

decode(nvl(prla.currency_code,

'RON'),

'EUR',

1,

hr_currency_pkg.get_rate('EUR',

nvl(prla.currency_code,

'RON'),

prla.creation_date,

'Corporate')) / 1000,

4),

'FM999,990.0999')

end kpi2f_value_eur

from po_requisition_headers_all prh,

po_req_distributions_all prda,

po_requisition_lines_all prla,

gl_code_combinations gcc,

po_agents_v pav

where prda.requisition_line_id =

prla.requisition_line_id

and prh.requisition_header_id =

prla.requisition_header_id

and gcc.code_combination_id = prda.code_combination_id

and prh.authorization_status in

('APPROVED',

'IN PROCESS',

'REJECTED',

'RETURNED'

)

and pav.agent_id = prla.suggested_buyer_id

and nvl(pav.attribute4,

'N') != 'Y'

and trunc(prh.creation_date) between

to_date(p_creation_date_from,

'YYYY/MM/DD HH24:MI:SS') and

to_date(p_creation_date_to,

'YYYY/MM/DD HH24:MI:SS')

and prla.suggested_buyer_id =

nvl(p_buyer,

prla.suggested_buyer_id)

group by prh.segment1,

prh.requisition_header_id,

prla.line_num,

prh.description,

prla.currency_code,

prla.suggested_buyer_id,

prh.attribute6,

prh.preparer_id,

prla.need_by_date,

gcc.segment13,

gcc.segment4,

gcc.segment7,

prla.global_attribute11,

prla.creation_date,

prla.quantity,

prla.unit_price

order by doc_no)

loop

v_req := rec1.doc_no;

v_req_value := xxmds_auto_saving_reporting.mds_get_req_value(rec1.requisition_header_id);

apps.fnd_file.put_line(apps.fnd_file.OUTPUT,

rec1.doc_no || '|' || rec1.line_num || '|' ||

rec1.req_submit_date || '|' ||

rec1.req_approved_date || '|' ||

rec1.doc_type || '|' || rec1.doc_desc || '|' ||

v_req_value || '|' || rec1.currency_code || '|' ||

rec1.doc_value_euro || '|' || rec1.buyer || '|' ||

rec1.purchaser || '|' || rec1.requester || '|' ||

rec1.promised_date || '|' ||

rec1.need_by_date || '|' ||

rec1.budget_code_activity || '|' ||

rec1.organisation_cost_center || '|' ||

rec1.project_code || '|' ||

rec1.kpi2f_value_eur || '|' || rec1.kpi2f);

end loop;

elsif p_doc_type = 'PO+Release'

then

apps.fnd_file.put_line(apps.fnd_file.output,

'Document No.' || '|' || 'Line' || '|' ||

'Document Submitted Date' || '|' ||

'Document Approval Date' || '|' ||

'Document Type' || '|' ||

'Document Description' || '|' ||

'Document Value' || '|' || 'Currency' || '|' ||

'Line Value în Euro' || '|' || 'Buyer' || '|' ||

'Purchaser' || '|' || 'Requester' || '|' ||

'Promised Date' || '|' || 'Need by Date' || '|' ||

'Budget Code(Activity)' || '|' ||

'Organisation (Cost Center)' || '|' ||

'Project Code' || '|' || 'KPI2F Value(Keuro)' || '|' ||

'KPI2F Value(%)');

for rec2 în (select distinct ph.segment1 doc_no,

ph.po_header_id,

pl.line_num line_num,

(select trunc(pahh.action_date)

from PO_ACTION_HISTORY pahh

where pahh.action_code = 'SUBMIT'

and pahh.object_id = ph.po_header_id

and pahh.object_type_code = 'PO'

and pahh.sequence_num =

(select min(sequence_num)

from PO_ACTION_HISTORY

where action_code = 'SUBMIT'

and object_id = ph.po_header_id

and object_type_code = 'PO')) po_submit_date,

(select trunc(pahh.action_date)

from PO_ACTION_HISTORY pahh

where pahh.action_code = 'APPROVE'

and pahh.object_id = ph.po_header_id

and pahh.object_type_code = 'PO'

and pahh.sequence_num =

(select max(sequence_num)

from PO_ACTION_HISTORY

where action_code = 'APPROVE'

and object_id = ph.po_header_id

and object_type_code = 'PO')) po_approved_date,

'PO' doc_type,

replace(replace(replace(replace(ph.comments,

chr(10),

null),

chr(13),

null),

'|',

' '),

chr(09),

null) doc_desc,

nvl(ph.currency_code,

'RON') currency_code,

round((pl.quantity * pl.unit_price) /

decode(nvl(ph.currency_code,

'RON'),

'EUR',

1,

hr_currency_pkg.get_rate('EUR',

nvl(ph.currency_code,

'RON'),

ph.creation_date,

'Corporate')),

4) doc_value_euro,

(select distinct per.full_name

from per_all_people_f per

where ph.agent_id = per.person_id) buyer,

(select distinct per1.full_name

from per_all_people_f per1

where ph.attribute6 = per1.person_id) purchaser,

(select distinct per2.full_name

from per_all_people_f per2

where per2.person_id =

pda.deliver_to_person_id) requester,

trunc(pll.promised_date) promised_date,

trunc(pll.need_by_date) need_by_date,

gcc.segment13 budget_code_activity,

gcc.segment4 organisation_cost_center,

gcc.segment7 project_code,

xxmds_auto_saving_reporting.mds_get_po_value(ph.po_header_id) doc_value,

to_char(nvl(replace(pl.global_attribute11,

',',

''),

0),

'FM999,990.0999') kpi2f,

case

when replace(pl.global_attribute11,

',',

'') < 1 then

to_char(round(pl.quantity *

pl.unit_price *

nvl(replace(pl.global_attribute11,

',',

''),

0) /

(1 – nvl(replace(pl.global_attribute11,

',',

''),

0)) /

decode(ph.currency_code,

'EUR',

1,

hr_currency_pkg.get_rate('EUR',

ph.currency_code,

ph.creation_date,

'Corporate')) / 1000,

4),

'FM999,990.0999')

when replace(pl.global_attribute11,

',',

'') >= 1 then

to_char(round(pl.quantity *

pl.unit_price *

nvl(replace(pl.global_attribute11,

',',

''),

0) /

decode(ph.currency_code,

'EUR',

1,

hr_currency_pkg.get_rate('EUR',

ph.currency_code,

ph.creation_date,

'Corporate')) / 1000,

4),

'FM999,990.0999')

end kpi2f_value_eur

from po_headers_all ph,

po_lines_all pl,

po_distributions_all pda,

po_line_locations_all pll,

gl_code_combinations gcc,

po_agents_v pav

where ph.po_header_id = pl.po_header_id

and pda.po_header_id = ph.po_header_id

and pda.po_line_id = pl.po_line_id

and pll.po_header_id = ph.po_header_id

and pll.po_line_id = pl.po_line_id

and pll.po_header_id = pda.po_header_id

and gcc.code_combination_id = pda.code_combination_id

and pll.line_location_id = pda.line_location_id

and ph.authorization_status in

('REQUIRES REAPPROVAL',

'IN PROCESS',

'REJECTED',

'PRE-APPROVED',

'APPROVED')

and pav.agent_id = ph.agent_id

and nvl(pav.attribute4,

'N') != 'Y'

and nvl(ph.cancel_flag,

'N') <> 'Y'

and nvl(pll.cancel_flag,

'N') <> 'Y'

and ph.type_lookup_code = 'STANDARD'

and trunc(ph.creation_date) between

to_date(p_creation_date_from,

'YYYY/MM/DD HH24:MI:SS') and

to_date(p_creation_date_to,

'YYYY/MM/DD HH24:MI:SS')

and ph.agent_id = nvl(p_buyer,

ph.agent_id)

group by ph.segment1,

pl.line_num,

ph.comments,

ph.agent_id,

ph.attribute6,

pda.deliver_to_person_id,

ph.currency_code,

ph.creation_date,

pll.promised_date,

pll.need_by_date,

gcc.segment13,

gcc.segment4,

gcc.segment7,

pl.global_attribute11,

pl.quantity,

pl.unit_price,

ph.po_header_id

union all

select distinct ph.segment1 doc_no,

pra.po_header_id,

pl.line_num line_num,

(select trunc(pahh.action_date)

from PO_ACTION_HISTORY pahh

where pahh.action_code = 'SUBMIT'

and pahh.object_id = ph.po_header_id

and pahh.object_type_code = 'PA'

and pahh.sequence_num =

(select min(sequence_num)

from PO_ACTION_HISTORY

where action_code = 'SUBMIT'

and object_id = ph.po_header_id

and object_type_code = 'PA')) po_submit_date,

(select trunc(pahh.action_date)

from PO_ACTION_HISTORY pahh

where pahh.action_code = 'APPROVE'

and pahh.object_id = ph.po_header_id

and pahh.object_type_code = 'PA'

and pahh.sequence_num =

(select max(sequence_num)

from PO_ACTION_HISTORY

where action_code = 'APPROVE'

and object_id = ph.po_header_id

and object_type_code = 'PA')) po_approved_date,

'RELEASE' doc_type,

replace(replace(replace(replace(ph.comments,

chr(10),

null),

chr(13),

null),

'|',

' '),

chr(09),

null) doc_desc,

nvl(ph.currency_code,

'RON') currency_code,

round((pll.quantity * pll.price_override) / –Ticket_2016041810001348

decode(nvl(ph.currency_code,

'RON'),

'EUR',

1,

hr_currency_pkg.get_rate('EUR',

nvl(ph.currency_code,

'RON'),

ph.creation_date,

'Corporate')),

4) doc_value_euro,

(select distinct per.full_name

from per_all_people_f per

where pra.agent_id = per.person_id) buyer,

(select distinct per1.full_name

from per_all_people_f per1

where pra.attribute1 = per1.person_id) purchaser,

(select distinct per2.full_name

from per_all_people_f per2

where per2.person_id =

pda.deliver_to_person_id) requester,

trunc(pll.promised_date) promised_date,

trunc(pll.need_by_date) need_by_date,

gcc.segment13 budget_code_activity,

gcc.segment4 organisation_cost_center,

gcc.segment7 project_code,

xxmds_auto_saving_reporting.mds_get_release_value(pra.po_header_id) doc_value,

to_char(replace(pl.global_attribute11,

',',

''),

'FM999,990.0999') kpi2f,

case

when replace(pl.global_attribute11,

',',

'') < 1 then

to_char(round(pll.quantity * pll.price_override * –Ticket_2016041810001348

nvl(replace(pl.global_attribute11,

',',

''),

0) /

(1 – nvl(replace(pl.global_attribute11,

',',

''),

0)) /

decode(ph.currency_code,

'EUR',

1,

hr_currency_pkg.get_rate('EUR',

ph.currency_code,

ph.creation_date,

'Corporate')) / 1000,

4),

'FM999,990.0999')

when replace(pl.global_attribute11,

',',

'') >= 1 then

to_char(round(pll.quantity * pll.price_override * –Ticket_2016041810001348

nvl(replace(pl.global_attribute11,

',',

''),

0) /

decode(ph.currency_code,

'EUR',

1,

hr_currency_pkg.get_rate('EUR',

ph.currency_code,

ph.creation_date,

'Corporate')) / 1000,

4),

'FM999,990.0999')

end kpi2f_value_eur

from po_releases_all pra,

po_headers_all ph,

po_lines_all pl,

po_distributions_all pda,

po_line_locations_all pll,

gl_code_combinations gcc,

po_agents_v pav

where ph.po_header_id = pl.po_header_id

and ph.po_header_id = pda.po_header_id

and ph.po_header_id = pll.po_header_id

and pll.po_header_id = pda.po_header_id

and pra.po_header_id = pll.po_header_id

and pra.po_release_id = pll.po_release_id

and ph.po_header_id = pra.po_header_id

and pda.po_release_id = pra.po_release_id

and pl.po_line_id = pda.po_line_id

and pl.po_line_id = pll.po_line_id

and pll.po_line_id = pda.po_line_id

and pll.line_location_id = pda.line_location_id

and gcc.code_combination_id = pda.code_combination_id

and ph.authorization_status in

('IN PROCESS',

'REJECTED',

'APPROVED')

and pav.agent_id = ph.agent_id

and nvl(pav.attribute4,

'N') != 'Y'

and ph.type_lookup_code = 'BLANKET'

and trunc(pra.creation_date) between

to_date(p_creation_date_from,

'YYYY/MM/DD HH24:MI:SS') and

to_date(p_creation_date_to,

'YYYY/MM/DD HH24:MI:SS')

and pra.agent_id = nvl(p_buyer,

pra.agent_id)

group by ph.segment1,

pra.po_header_id,

pl.line_num,

ph.comments,

pra.agent_id,

pra.attribute1,

pda.deliver_to_person_id,

ph.currency_code,

ph.creation_date,

pll.promised_date,

pll.need_by_date,

gcc.segment13,

gcc.segment4,

gcc.segment7,

pl.global_attribute11,

pl.quantity,

pl.unit_price,

ph.po_header_id,

pll.price_override, –Ticket_2016041810001348

pll.quantity –Ticket_2016041810001348 )

loop

apps.fnd_file.put_line(apps.fnd_file.OUTPUT,

rec2.doc_no || '|' || rec2.line_num || '|' ||

rec2.po_submit_date || '|' ||

rec2.po_approved_date || '|' ||

rec2.doc_type || '|' || rec2.doc_desc || '|' ||

rec2.doc_value || '|' || rec2.currency_code || '|' ||

rec2.doc_value_euro || '|' || rec2.buyer || '|' ||

rec2.purchaser || '|' || rec2.requester || '|' ||

rec2.promised_date || '|' ||

rec2.need_by_date || '|' ||

rec2.budget_code_activity || '|' ||

rec2.organisation_cost_center || '|' ||

rec2.project_code || '|' ||

rec2.kpi2f_value_eur || '|' || rec2.kpi2f);

v_po := rec2.doc_no;

end loop;

elsif p_doc_type = 'BPA'

then

apps.fnd_file.put_line(apps.fnd_file.output,

'Document No.' || '|' ||

'Document Submitted Date' || '|' ||

'Document Approval Date' || '|' ||

'Document Description' || '|' ||

'Document Value' || '|' || 'Currency' || '|' ||

'Document Value EURO' || '|' || 'Buyer' || '|' ||

'Purchaser' || '|' || 'Requester' || '|' ||

'Effective Date From' || '|' ||

'Effective Date To' || '|' || 'Line No.' || '|' ||

'Line Description' || '|' || 'Unit price' || '|' ||

'Unit price EURO' || '|' || 'KPI2F Line' || '|' ||

'Quantity Agreed' || '|' || 'Amount Agreed' || '|' ||

'End Date Line');

for rec3 în (select distinct ph.segment1 doc_no,

(select trunc(pahh.action_date)

from PO_ACTION_HISTORY pahh

where pahh.action_code = 'SUBMIT'

and pahh.object_id = ph.po_header_id

and pahh.object_type_code = 'PA'

and pahh.sequence_num =

(select min(sequence_num)

from PO_ACTION_HISTORY

where action_code = 'SUBMIT'

and object_id = ph.po_header_id

and object_type_code = 'PA')) po_submit_date,

(select trunc(pahh.action_date)

from PO_ACTION_HISTORY pahh

where pahh.action_code = 'APPROVE'

and pahh.object_id = ph.po_header_id

and pahh.object_type_code = 'PA'

and pahh.sequence_num =

(select max(sequence_num)

from PO_ACTION_HISTORY

where action_code = 'APPROVE'

and object_id = ph.po_header_id

and object_type_code = 'PA')) po_approved_date,

replace(replace(replace(replace(ph.comments,

chr(10),

null),

chr(13),

null),

'|',

' '),

chr(09),

null) doc_desc,

ph.blanket_total_amount doc_value,

ph.currency_code,

ph.blanket_total_amount /

decode(nvl(ph.currency_code,

'RON'),

'EUR',

1,

hr_currency_pkg.get_rate('EUR',

nvl(ph.currency_code,

'RON'),

ph.creation_date,

'Corporate')) doc_value_eur,

per.full_name buyer,

per1.full_name purchaser,

per2.full_name requester,

ph.start_date,

ph.end_date,

pl.line_num,

replace(replace(replace(replace(pl.item_description,

chr(10),

null),

chr(13),

null),

'|',

' '),

chr(09),

null) item_desc,

pl.unit_price,

pl.unit_price /

decode(nvl(ph.currency_code,

'RON'),

'EUR',

1,

hr_currency_pkg.get_rate('EUR',

nvl(ph.currency_code,

'RON'),

ph.creation_date,

'Corporate')) unit_price_eur,

replace(pl.global_attribute11,

',',

'') kpi2f_value,

pl.quantity_committed Qty_Agreed,

pl.committed_amount Amount_Agreed,

pl.expiration_date

from po_headers_all ph,

po_lines_all pl,

po_distributions_all pda,

po_line_locations_all pll,

per_all_people_f per,

per_all_people_f per1,

per_all_people_f per2,

gl_code_combinations gcc,

po_agents_v pav

where ph.po_header_id = pl.po_header_id

and ph.po_header_id = pda.po_header_id

and ph.po_header_id = pll.po_header_id

and pll.po_header_id = pda.po_header_id

and pl.po_line_id = pda.po_line_id

and pl.po_line_id = pll.po_line_id

and pll.po_line_id = pda.po_line_id

and pll.line_location_id = pda.line_location_id

and gcc.code_combination_id = pda.code_combination_id

and ph.agent_id = per.person_id

and ph.attribute6 = per1.person_id

and per2.person_id = pda.deliver_to_person_id

and ph.authorization_status in

('REQUIRES REAPPROVAL',

'IN PROCESS',

'REJECTED',

'PRE-APPROVED',

'APPROVED')

and pav.agent_id = ph.agent_id

and nvl(pav.attribute4,

'N') != 'Y'

and ph.type_lookup_code = 'BLANKET'

and nvl(ph.cancel_flag,

'N') <> 'Y'

and nvl(pll.cancel_flag,

'N') <> 'Y'

and trunc(ph.creation_date) between

to_date(p_creation_date_from,

'YYYY/MM/DD HH24:MI:SS') and

to_date(p_creation_date_to,

'YYYY/MM/DD HH24:MI:SS')

and ph.agent_id = nvl(p_buyer,

ph.agent_id))

loop

apps.fnd_file.put_line(apps.fnd_file.OUTPUT,

rec3.doc_no || '|' || rec3.po_submit_date || '|' ||

rec3.po_approved_date || '|' ||

rec3.doc_desc || '|' || rec3.doc_value || '|' ||

rec3.currency_code || '|' ||

rec3.doc_value_eur || '|' || rec3.buyer || '|' ||

rec3.purchaser || '|' || rec3.requester || '|' ||

rec3.start_date || '|' || rec3.end_date || '|' ||

rec3.line_num || '|' || rec3.item_desc || '|' ||

rec3.unit_price || '|' ||

rec3.unit_price_eur || '|' ||

rec3.kpi2f_value || '|' || rec3.qty_agreed || '|' ||

rec3.amount_agreed || '|' ||

rec3.expiration_date);

end loop;

end if;

end xxmds_kpi2f_info_period;

Similar Posts