Gestiunea Proceselor Financiar Contabile Utiziand E Buisness Suit

Economie

Gestiunea Proceselor Financiar Contabile Utiziand E Buisness Suit

Byadmin ianuarie 1, 2024

Gestiunea proceselor financiar-contabile utilizând oracle e-business suite: soluția oracle financials

Obiectivul acestei lucrări este prezentarea aspectelor cele mai importante legate de implementarea sistemele informatice integrate într-o organizație.

În primul capitol al lucrării este definit conceptul de sistem informatic de tip Enterprise Resource Planning și sunt evidențiate rolul și importanța acestuia în managementul organizației prin prisma eficientizării proceselor de afaceri. În acest context, sunt identificate principalele soluții de tip ERP existente pe piață și este realizată o analiză comparativă între soluțiile oferite de principalii furnizori din punct de vedere al funcționalităților oferite, costurilor de implementare și flexibilității acestora în vederea satisfacerii cerințelor clientului.

Capitolul 2 descrie cele mai importante concepte utilizate în cadrul soluției integrate oferite de către firma Oracle: E-Business Suite, arhitectura și componentele suitei precum și modul în care aceste componente se integrează în vederea optimizării activității organizațiilor.

Sunt prezentate detaliat modulele soluției de gestiune a proceselor financiar-contabile din Oracle Financials.

În capitolul trei al lucrării este prezentată organizația pe baza căreia a fost realizat studiul de caz – grupul G4S Romania. Sunt identificate cerințele informaționale ale organizației și sunt analizate cele mai importante fluxuri automatizate prin implementarea soluției Oracle Financials.

De asemenea, sunt expuse o parte din configurările realizate pentru adaptarea aplicației la necesitățile identificate anterior în fiecare dintre modulele financiare: Receivables (Clienți), Payables (Furnizori), Fixed Assets (Mijloace Fixe), Cash Management (Lichidități) și General Ledger (Contabilitate Generală).

În capitolul patru sunt prezentate o serie de rapoarte personalizate realizate utilizând instrumentul Oracle Reports Builder. De asemenea, este detaliat un proces de business complex, customizat pentru gestiunea cheltuielilor în avans în cadrul G4S România.

În final, pentru a facilitata înțelegerea modului de lucru și a funcționalităților expuse, în cadrul anexelor se regăsesc capturi de ecran, codurile sursă pentru dezvoltările prezentate în capitolul al patrulea, precum și alte tabele însoțite de explicații.

CAPITOLUL 1: Aspecte teoretice privind sistemele informatice integrate de tip ERP

1.1. Introducere în sisteme informatice de tip ERP

Necesitatea integrării activităților dintr-o organizație a apărut din nevoia unui management rapid și performant, în condițiile în care se lucrează cu volume de date imense iar abordarea clasică, în care fiecare departament avea propriile lui sisteme informatice specializate și optimizate pentru nevoile particulare proprii, a devenit din ce în ce mai ineficientă.

Soluția o reprezintă sistemele integrate de tip ERP (Enterprise Resource Planning) concepute ca aplicații economice multimodulare ce integrează și gestionează toate procesele economice dintr-o organizație. ERP-ul se constituie ca și nucleu în organizație, integrând toate departamentele și funcțiile acesteia într-un singur sistem informatic ce poate servi necesităților particulare din fiecare departament.

1.1.1. Enterprise Resource Planning. Definiții.

Un ERP „reprezintă o infrastructură software multimodulară ce oferă suport de gestiune și coordonare a diferitelor structuri și procese din companie, în vederea realizării obiectivelor de afaceri”.[FOHU04]

T. H. Davenport, specialist în domeniile de management și sisteme informaționale pentru afaceri definește un ERP ca fiind „un pachet care promite integrarea completă a tuturor informațiilor din cadrul unei organizații”.

Un sistem de gestiune a companiei de tip ERP „integrează toate procesele economice: producție, distribuție, contabilitate, financiar, personal, stocuri, service, mentenanță, logistică, gestiune de proiecte, oferind accesibilitate, vizibilitate și consistență informațională în întreaga organizație”. [LUNG07]

Simplificând, un sistem ERP este definit prin două proprietăți fundamentale: integrare și funcționalitate.

Integrarea asigură conectivitatea între fluxurile de procese economice funcționale prin intermediul codului sursă, rețelelor locale și extinse de calculatoare, Internet, email, workflow-uri, instrumente de configurare automată, protocoale, baze de date.

Partea funcțională a unui ERP asigură fluxurile de procese economice prin modulele funcționale furnizate.

Provocarea principală o reprezintă integrarea tuturor proceselor economice și optimizarea resurselor disponibile, astfel încât să permit factorilor de decizie realizarea unor analize complete.

1.1.2. Scurt istoric al sistemelor de tip ERP

Sistemele de tip ERP au apărut în anii 1960 fiind utilizate în procesul de asistare a procesului de producție, primul produs de acest tip fiind MRP (Material Resource Planning) care însă nu își extindea funcționalitățile și spre alte zone de interes dintr-o organizație precum resurse umane, vânzări, contabilitate, logistică.

Începând cu anii ’90 sistemele ERP au evoluat către centralizarea și integrarea funcționalităților într-o platformă comună.

La momentul actual, sistemele ERP au devenit mai eficiente prin integrarea facilităților ERP cu aplicațiile Web, astfel că un client poate avea acces la stadiul unei comenzi sau la stocurile furnizorului de la distanță.

1.1.3. Funcționalități ale unui sistem ERP

În cadrul unui sistem ERP, fiecare arie de activitate din organizație este acoperită de către unul sau mai multe module specifice care funcționează integrat utilizând o bază de date comună, dar pot funcționa și independent:

Producție: planificarea și urmărirea producției;

Gestiune: evidența stocurilor, a furnizorilor, plăților și încasărilor;

Vânzări: activități legate de vânzări, distribuție și facturare;

Contabilitate: evidența contabilă și financiară, imobilizări;

HCM (Human Capital Management) și Payroll managementul resurselor umane și calcul salarial;

SCM (Supply Chain Management): managementul relațiilor cu furnizorii;

CRM (Customer Relationship Management): managementul relațiilor cu clienții;

BI (Business Intelligence): rapoarte, analize, prognoze.

1.1.4. Arhitectura sistemelor de tip ERP

Sistemele ERP se implementează pe o arhitectură de tip client-server, conform unei arhitecturi pe trei niveluri:

Nivelul prezentare: interfața grafică utilizator sau browser-ul pentru accesarea funcțiilor sistemului;

Nivelul aplicație: cuprinde regulile afacerii, logica și funcțiunile sistemului, programele care asigură transferul datelor de la și la serverele de baze de date;

Nivelul bazei de date: asigură gestiunea datelor organizației, inclusiv a metadatelor, cel mai adesea fiind reprezentat de un SGBD.

Această dispunere permite ca interfața sistemului să ruleze pe calculatorul utilizatorului, prelucrarea să se realizeze pe nivelul serverelor de aplicații iar sistemele de baze de date să funcționeze pe servere specializate.

1.2. Implementare sistemelor ERP

1.2.1. Motivația implementării de sisteme ERP

Câteva dintre cele mai importante motive identificate pentru care organizațiile economice trebuie să implementeze un sistem ERP sunt:

Integrarea informațiilor financiare;

Integrarea informațiilor despre comenzile de la clienți;

Standardizarea și creșterea vitezei de producție;

Reducerea timpului pierdut prin inventariere;

Standardizarea informațiilor pentru resursele umane.

1.2.2. Criterii de alegere a unei soluții ERP

Adoptarea unei soluții ERP este o decizie dificilă pentru orice organizație. Alegerea celei mai potrivite soluții, instruirea personalului și planificarea resurselor sunt trei elemente esențiale pentru reușita implementării și utilizarea sistemului în condiții de eficiență maximă.

Criterii de alegere a furnizorului soluției ERP:

Poziția în piață și reputația:

Un sistem ERP nu este este un software pe care o firmă să îl utilizeze o perioadă scurtă de timp, astfel încât trebuie aleasă ca partener o companie solidă, care să nu aibă probleme (insolvență, faliment etc.) în următorii 5-7 ani.

Experiența în industria în care solicitantul activează

Acest aspect trebuie avut în vedere de către client pentru a vedea dacă poate beneficia de pe urma experienței furnizorului din implementări anterioare la companii din aceeași industrie, dacă acesta are în vedere dezvoltarea de funcționalități specifice industriei în care clientul activează.

Sistemul de suport și mentenanță

Niciun sistem nu este perfect, astfel încât va fi nevoie de ajutorul din partea furnizorului în exploatarea sistemului și în adaptarea lui ulterioară. Este importantă astfel viteza cu care acordă suport furnizorul, ce înseamnă „urgent” pentru acesta, dacă există un Service Level Agreement (SLA) și care sunt repercusiunile asupra furnizorului în cazul nerespectării lui.

Sistemul de training

Acest aspect este menit să asigure o exploatare optimă a sistemului ales. Este important astfel de stabilit modul în care este evaluată eficiența trainingului, care sunt etapele și cine îl efectuează (producătorul sistemului sau implementatorul).

Costurile propuse legate de software, hardware, servicii inițiale, suport și mentenanță

Timpul de implementare

Un aspect important al unei implementări este capacitatea furnizorului de a oferi ajutor companiei în reorganizarea proceselor de business.

Criterii de alegere a soluției:

Funcționalitatea

Compatibilitate cu cerințele de business ale companiei – pentru a putea verifica acest lucru, în primul rând clientul trebuie să realizeze o analiză foarte detaliată a cerințelor lui de business

Securitatea sistemului

Interoperabilitatea sistemului

Maturitatea sistemului: ușurința back-up-ului și a recuperării de date, vechimea în piață a sistemului

Ergonomie: interfața trebuie să fie una simplă, ușor de folosit, intuitivă, întrucâ aceasta va determina ușurința cu care utilizatorii vor înțelege sistemul

Eficiența în utilizarea resurselor hardware și software

Mentenanța: capacitatea de customizare, stabilitatea, testabiliatea.

1.2.3. Costul unui sistem ERP

Implementarea unui sistem integrat de tip ERP implică costuri dificil de previzionat, deoarece el depinde de numărul de module ce vor fi instalate, complexitatea proiectului, efortul necesar pentru integrarea sistemelor deja existente, numărul de divizii ale companiei care vor utilize soluția.

În afară de costurile echipamentele hardware, licențele software, serviciile profesionale și costurile interne ale firmei, există și alte costuri ascunse:

Costurile cu pregătirea profesională a angajaților trebuie să învețe noi proceduri si noi procese, nu doar să se familiarizeze cu o nouă interfață.

Costuri cu integrarea și testarea

Personalizarea: aceasta trebuie însă efectuată numai atunci când ERP nu acoperă unul din procesele companiei, și trebuie adaptat să realizeze și acest aspect; personalizarea nucleului pachetului ERP face mult mai dificilă actualizarea atunci când este disponibilă o nouă versiune a acestuia.

Costuri legate de conversia și analiza datelor: transformarea datelor din sistemele vechi și mutarea în sistemul client-server cerut de ERP costă bani și pune destul de multe probleme practice

1.3. Avantajele și dezavantajele sistemelor informatice de tip ERP

Principalele avantaje ale utilizării unui ERP în cadrul unei companii sunt [LUNG07] :

informația este introdusă în sistem o singură dată într-o bază de date foarte complexă;

obligă la folosirea celei mai bune practici din industrie;

permite personalizări;

funcționează pe o structură fiabilă de fișiere;

furnizează funcționalități pentru interacțiunea cu alte module;

furnizează instrumente pentru interogări și rapoarte ad-hoc;

se îmbunătățesc serviciile oferite angajaților și clienților.

În același timp, există și dezavantaje apărute la momentul implementării unei soluții ERP:

costul sistemelor ERP este ridicat

implementarea poate fi dificilă și de lungă durată

implementarea presupune schimbări în modul de lucru al departamentelor din organizații.

1.4. Analiza comparativă între Oracle și SAP

Înainte de a achiziționa un sistem ERP este necesar ca organizația să efectueze o comparație între produsele existente pe piață. Principalii furnizori de sisteme ERP la momentul actual sunt Oracle și SAP.

Criterii de analiză:

Experiența în industrie

Concordanța la cerințele clientului

Metodologia de implementare

Flexibilitate și suport

Principalele module oferite

Ușurința personalizărilor

CAPITOLUL 2: Prezentarea sistemului integrat Oracle e-Business Suite

2.1. Oracle E-Business Suite – soluție integrată pentru managementul companiilor

Oracle e-Business Suite este un pachet complex de aplicații de afaceri integrate destinate întreprinderilor medii și mari prin care se automatizează procesele cheie din organizație, acoperind toate ariile funcționale ale unei afaceri: resurse umane, achiziții, planificarea lanțului logistic, producție, comenzi, service, managementul relațiilor cu clienții, managementul activelor și a resurselor afacerii.

Familia de produse Oracle Applications include următoarele module software care acoperă o plajă vastă de funcțiuni [www.oracle.com]:

1.Customer Relationship Management cuprinde un set de aplicații pentru gestionarea activităților legate de vânzări, servicii și marketing.

Principalele componente sunt:

Oracle Channel Revenue Management

Oracle Order Management

Oracle Service

Oracle Marketing

2. Customer Service Management sprijină companiile să îndeplinească și chiar să depășească așteptările clienților, cele mai importante componente fiind:

Advanced Inbound Telephony & Advanced Outbound Telephony

Advanced Scheduler

Email Center

Interaction Center

iSupport

Mobile Field Service

Service Contracts

TeleService

3. Financial Management – Oracle Financials

Componente:

Receivables

Payables

Assets

Cash Management

General Ledger

4. Human Capital Management oferă funcționalități ce permit creșterea productivității, accelerarea performanței și reducerea costurilor: recrutare, instruire, beneficii, salarizare.

Componente principale:

Global Core Human Capital Management

Workforce Management

Talent Management

Workforce Service Delivery

HR Analytics

5. Project Portfolio Management sprijină întregul ciclu de viață al proiectelor și managementul portofoliului prin componente precum:

Project Analytics

Project Billing

Project Contracts

Project Costing

Project Management

Project Resource Management

Project Portfolio Analysis

6. Advanced Procurement: soluția ajută companiile să minimizeze cheltuielile pentru bunuri și servicii prin cele mai importante componentele oferite:

iProcurement

Services Procurement

Purchasing

Procurement Contracts

7. Supply Chain Management integrează și automatizează procesele cheie ale lanțului de aprovizionare, de la proiectare, planificare, achiziții și până la producție. Cele mai importante componente sunt:

Manufacturing

Value Chain Execution

Product Value Chain Management

Value Chain Planning

8. Value Chain Planning este o soluție de planificare ce permite companiilor să își optimizeze planificarea vânzărilor, a operațiunilor și a managementului performanței prin intermediul componentelor precum:

Advances Supply Chain Planning

Demand Management

Collaborative Planning

Production Scheduling

Inventory Optimization

9. Value Chain Execution – Oracle Logistics: utilizatorii pot planifica, gestiona și controla fluxul și depozitarea de produse și servicii în cadrul unei afaceri. Soluția permite planificarea a stocului pe baza planurilor de producție și a planurilor de materiale generate în condițiile anumitor constrângeri aplicate.

Principalele componente:

Transportation Management

Warehouse Management

Inventory Management

2.2. Arhitectura Oracle Applications R12

Arhitectura Oracle Applications ce stă la baza Oracle e-Business Suite este organizată pe 3 nivele, astfel:

Figura 2.1. Componentele arhitecturii Oracle Applications [ORAC11]

Desktop Tier: reprezintă nivelul aflat pe stația clientului.

Clientul este reprezentat de calculatorul personal care se conectează la o aplicație/bază de date Oracle. Acesta trebuie să fie capabil să ruleze pagini HTML și forme Oracle, rulate sub Java Virtual Machine (JVM), asigurat de Browser.

Application Tier: diverse servere și servicii ce susțin logica business-ului și comunicarea între nivelul desktop și nivelul database – reprezentat de Oracle Application Server 10g.

Sunt 4 servicii la acest nivel ce asigură funcționalitățile de bază ale aplicației:

Web services/servicii web: această componentă procesează cererile primite din rețea de la nivelul Desktop, cuprinzând următoarele:

Web Listener: Oracle HTTP Server (Apache)

Java Servlet Engine: OC4J

Oracle Process Manager: OPMN

Forms services/servicii Forms: furnizat de Forms Listener Servlet – un servlet Java care oferă abilitatea de a rula aplicații Oracle Forms în cadrul unor conexiuni HTTP/HTTPS. Comunică cu nivelul desktop și nivelul database pentru a afișa formele/ecranele la nivel de client.

Concurrent Processing server/servicii pentru procese concurente: permite ca programele să ruleze în background în timp ce utilizatorii continuă să lucreze în aplicație. Procesele care ruleaza in paralel pe server se numesc procese concurente; paginile HTML sau formele trimit cereri catre server, pentru lansarea unui anumit proces

Admin server: permite aplicarea patch-urilor și efectuarea diverselor lucrări de mentenanță asupra bazei de date cu ajutorul utilitarului AD Administration.

Database Tier: nivelul bază de date conține serverul de baze de date Oracle, care stochează toate datele gestionate de Oracle Applications.

2.3. Concepte de bază utilizate în Oracle Applications

a) Responsabilitatea reprezintă o colecție de autorizări care oferă acces la:

o aplicație sau un grup de aplicații

un registru contabil (LEDGER)

o listă restricționată de ferestre (FORME), funcții și rapoarte

Autorizarea de a accesa aplicația se face prin definirea unui user de aplicație, identificat prin nume de utilizator și parolă, cu una sau mai multe responsabilități asignate.

Responsabilitatea determină pentru un utilizator:

meniurile și formele la care are acces

rapoartele pe care le poate rula

registrele contabile pe care le poate accesa

business unit-urile (organizațiile) pe care poate lucra

aplicațiile pe care le poate accesa

b) Grupul de cereri (Request Group)

Grupurile de rapoarte desemnează programele concurente la care responsabilitatea are access (le poate rula). Se poate limita ușor lista de rapoarte la care un utilzator are acces prin gruparea utilizatorilor pe categorii și crearea unui grup de cereri, asignat responsabilității.
Grupul de cereri poate include:

toate rapoartele și programele concurente pe care un user le poate rula

cereri concurente individuale

cereri grupate în seturi

funcții de tip stage

c) Meniuri

Un meniu este un aranjament ierarhic de funcții și meniuri de funcții care apar în zona de navigare din Oracle Applications.

Funcționalitățile meniurilor se folosesc pentru a defini un meniu nou sau pentru a modifica un meniu existent. Se poate construi un meniu complet personalizat, utilizând meniuri deja existente, care fac referințe către funcții și forme existente.

După salvarea modificărilor în forma de definire meniuri, este lansat un proces care va compila meniul creat.

d) Conceptul de câmp flexibil descriptiv (Descriptive Flexfield)

Câmpurile flexibile descriptive (DFF) reprezintă o modalitate de extindere a funcționalităților standard ale aplicației, prin posibilitatea de a configura câmpuri noi de colectare a datelor, în afara celor deja existente.

Câmpurile flexibile descriptive sunt poziționate în formele standard Oracle, o formă putând avea unul sau mai multe câmpuri flexibile descriptive. De regulă, fiecare bloc din cadrul unei forme are un câmp flexibil descriptiv atașat, și el constă dintr-o colecție de segmente (până la 15), mapate 1 la 1 în coloane rezervate din tabelele bazei de date (ATTRIBUTE1, ATTRIBUTE2,…, ATTRIBUTE15) pe care forma le completează sau le modifică la operațiuni de INSERT sau UPDATE.

Câmpurile flexibile descriptive pot fi globale sau contextuale, după tipurile de segmente cu care lucrează. Un segment global, este un segment care va apărea întotdeauna în DFF.

Un segment senzitiv la context este un segment care poate să apară sau nu într-un DFF, în funcție de contextul ales.

Pentru segmentele contextuale este nevoie în mod obligatoriu de informația de context (o valoare care dicteză numărul de segmente și care segmente se vor încărca).

e) Conceptul de câmp flexibil cheie (Key Flexfield)

Un câmp flexibil cheie, spre deosebire de cele descriptive, este un „câmp inteligent”, care identifică în mod unic o entitate de importanță majoră a unei aplicații.

Este asemănător ca structură cu câmpurile flexibile descriptive, în sensul că este gestionat prin segmente. Fiecare segment are un nume și un set de valori specific. De asemenea, întreaga structură de segmente concatenată este codificată, identificată în mod unic și utilizată ca o cheie unică în aplicațiile pe care le deservește.

Ca o particularitate, între segmente se pot defini reguli de validare (cross-validation), ceea ce previne construirea anumitor combinații nedorite (combinații invalide).

De asemenea, valorile se pot securiza pe fiecare segment prin reguli (anumite valori să fie vizibile pe o regulă, iar altele nu), aceste reguli urmând a fi asignate la responsabilități, contribuind astfel la realizarea securității în Oracle Applications. Astfel, useri diferiți cu responsabilități diferite, pot vedea doar anumite valori, în funcție de regulile de business și rolul avut în cadrul companiei.

Cel mai cunoscut câmp flexibil cheie din aplicațiile Oracle este Accounting Flexfield din modulul General Ledger, adică flexul pe care se codifică contul contabil în mod analitic.

Unele dintre segmente de pe câmpurile flexibile cheie au atribute speciale și funcționalități specifice recunoscute de aplicație. De exemplu, pentru accounting flexfield, se pot defini atribute pentru segmente ca BALANCING SEGMENT, NATURAL ACCOUNT, COST CENTER SEGMENT, INTERCOMPANY SEGMENT. Asta înseamnă că notele contabile create se vor balansa după segmentul declarat ca fiind BALANCING.

f) Procesele concurente în Oracle Applications prin caracteristicile lor, sunt instrumente puternice în satisfacerea nevoilor de business.

Ele prezintă următoarele particularități:

Procesele rulează pe server, în background, iar în aplicație lucrul poate continua normal, în mod independent de executarea acestor procese

Capacitățile hardware pot fi folosite la maxim, putându-se lansa mai multe procese concurente în același timp

Aplicația Oracle rulează toate procesele și programele sale, ca procese simultane, utilizând forma de lansare programe concurente (Submit Requests)

Administratorul de sistem poate adapta și configura executarea proceselor concurente astfel încât să obțină performanțe maxime și să evite supraîncărcarea de moment a sistemului.

2.4. Prezentarea suitei de aplicații Oracle Financials

Ciclul contabil în aplicația Oracle

Tranzacțiile efectuate în submodulele aplicației se transferă în Cartea Mare/General Legder (Contabilitate Generala) prin procese specifice fiecărui modul, contribuind la elaborarea balanței financiare și a contabilității de gestiune.

Submodulele din care se transferă date în GL, pentru zona financiară, sunt:

Contabilitate furnizori (Payables), unde se efectueaza operațiuni privind furnizorii: facturi, plăți, decontări;

Contabilitate clienți (Receivables), unde se efectuează operațiuni privind clienții: facturi, încasări;

Mijloace fixe (Assets), unde se efectuează operațiuni privind mijloacele fixe: puneri în funcțiune, calcul amortizări, casări;

Lichidități (Cash Management), unde se efectuează operațiuni de casă și bancă;

Figura 2.2. Schema de integrare a submodulelor și integrarea Resursele Umane și Logistica

2.4.1. Modulul Oracle Receivables – Contabilitatea clienților

Modulul Accounts Receivables este un instrument proiectat pentru a răspunde necesităților organizației privind plățile și activitățile de încasare a clienților.

Principalele funcționalități din Accounts Receivables

a) Gestionarea bazei de date a clienților

Oracle AR stochează o serie de informații despre clienți, începând de la cele de bază cum sunt numele clientului, adresa, numărul de telefon, până la informații privind persoana de contact, detalii bancare, modalități de plată, termenul de plată, valoarea creditelor și profilul clientului.

b) Gestionarea facturilor pentru clienți

Posibilitățile de facturare oferite de Oracle Receivables acoperă un mare număr de tranzacții: intrarea angajamentelor, intrarea facturilor, calcularea automată a taxelor, completarea facturilor, crearea tranzacțiilor pentru facturare, generarea și transmiterea către clienți a extraselor de cont.

Facturile pot fi introduse în orice valută, sumele în valută fiind transformate automat în moneda funcțională folosind rata de schimb specificată de utilizator. Informațiile din factură sunt salvate în ambele monede pentru a menține procesul de verificare a tranzacțiilor în diferite valute.

c) Încasări clienți și încasări diverse

În Oracle Receivable încasarea clienților este efectuată în doi pași: introducerea datelor despre încasare și aplicarea încasării pe facturi sau în avans.

Introducerea manuală a încasărilor poate fi făcută individual sau în grup în ecranul de introducere a încasărilor. Prin folosirea formei de introducere a încasărilor, informațiile pot fi introduse, se pot corela încasările cu facturile, se pot crea ajustări și cere plăți suplimentare.

d) Închiderea de lună

La finalul lunii se finalizează toate facturile și se contabilizează toate tranzacțiile (facturi și plăți) prin rularea procesului de contabilizare.

Înainte de transferarea în Contabilitatea generală utilizatorul poate face balanța tranzacțiilor folosind rapoarte standard. De asemenea se rulează rapoartele de închidere de lună și rapoartele de verificare a TVA-ului.

După ce au fost transferate datele în modulul Contabilitate Generală se închide perioada contabilă și se va deschide următoarea perioadă contabilă.

e) Raportare

Oracle Receivables asigură un set de rapoarte standard proiectate pentru asigurarea de răspunsuri și la cele mai dificile întrebări legate de contabilitatea organizației.

Organizația poate rula rapoarte standard pentru identificarea articolelor cu termen de plată scadent sau în discuție. Raportul facturilor depășite permite organizației trecerea în revistă a informațiilor legate de un client: facturi depășite, modificări ale valorii facturii, depozite, valori suplimentare și garanții. Problemele pot fi ulterior identificate și utilizatorul autorizat poate decide asupra acțiunilor ulterioare în ceea ce privește recuperarea debitelor.

2.4.2. Modulul Oracle Payables – Contabilitatea furnizorilor

Modulul de Contabilitate a Furnizorilor oferă facilități pentru a asigura gestionarea facturilor de la furnizori și controlul riguros al plăților, înțelegând prin aceasta: verificarea și aprobarea facturilor pentru plată sau blocarea lor, emiterea (sau înregistrarea) documentelor de plată, efectuarea plăților la termenele scadente și numai pentru bunuri și servicii comandate și efectiv livrate, valorificarea discountului acordat de furnizor, prevenirea plăților duble, prognoza necesarului de lichidități.

Principalele funcționalități din Accounts Payables

a) Gestionarea bazei de date a furnizorilor

Datele furnizorilor sunt grupate în categorii logice:

date de bază: numele și numărul furnizorului;

date privind aprovizionarea: informații privind transportul, modul de plată, moneda în care se face aceasta, prioritate de plată, condiții standard pentru reduceri etc.;

date bancare: numele contului și numărul, numele băncii, tipul contului și informații contabile privind facturile.

Unii furnizorii pot avea mai multe sedii, astfel încât pot exista sedii diferite pentru livrare și pentru plată.

Facilitatea câmpurilor descriptive flexibile poate fi utilizată în perioada de implementare pentru definirea de noi câmpuri pentru furnizori în concordanță cu necesitățile specifice organizației, fără scrierea de cod.

b) Gestionarea facturilor de la furnizori

La introducerea facturilor, pe lângă informația existentă pe factura furnizorului, se adaugă conturile implicate în tranzacție și liniile de distribuție referitoare la modul de distribuire a sumei totale pe conturi de mijloace fixe, materiale, cheltuieli, taxe.

În cazul cheltuielilor, unele din acestea pot genera un număr foarte mare de linii de distribuție, dacă se repartizează pe centrele de cost, precum cheltuielile de chirie sau telefon. În acest caz, se apelează la seturile de distribuție definite în prealabil conținând coeficienții de alocare a sumelor pe centrele de cost, liniile de distribuție generându-se astfel automat, conform șablonului de alocare.

c) Introducerea deconturilor angajaților

Oracle Payables permite tratarea cheltuielilor cu angajații ca orice altă relație cu un furnizor. Datele privind angajații provin din modulul Resurse umane din Oracle pentru a reduce necesarul de date de intrare,însă în absența modulului de HR acestea sunt gestionate în cadrul modulului AP. În multe situații cheltuielile cu angajații sunt simple facturi.

Pentru fluidizarea procesului și reducerea activității de încărcare se poate utiliza Xpense Xpress, un mod rapid și ușor de introducere a cheltuielilor cu angajații – deplasări, transport, diurnă, etc.

d) Gestionare plăților: înregistrarea, reversarea și aplicarea plăților pe facturi

e) Închiderea de lună

Contabilizarea tranzacțiilor se face prin rularea procesului Create Accounting (Creare înregistrări contabile) iar transferul notelor contabile se face rulând procesul de transfer Transfer to GL.

Înainte de a se transfera notele în Cartea mare se rulează raportele necesare verificării tranzacțiilor introduse în sistem și se verifică soldurile creditoare și rulajele furnizorilor interni/externi/investiții.

După ce au fost transferate datele în modulul Contabilitate Generală se închide perioada contabilă și se va deschide următoarea perioadă contabilă.

f) Raportare

Oracle Payables pune la dispoziția utilizatorilor o mare varietate de rapoarte standard despre furnizori, facturi, plăți și contări, dintre care enumerăm: registrul facturilor, balanța de verificare, necesarul de lichidități, raportul facturilor, registrul facturilor scadente neachitate, pe intervale de vechime, registrul de taxe, registrul de plăți efectuate, istoricul plăților furnizorilor.

2.4.3. Modulul Oracle Fixed Assets – Contabilitatea Mijloacelor fixe

Principalele funcționalități din Oracle Fixed Assets

a) Parametrizări

Utilizatorul fixează regulile de amortizare, registrele de amortizare și informația financiară care satisfac cel mai bine obiectivele de raportare financiară.

Oracle Assets permite definirea de subcategorii pentru toate categoriile de mijloace fixe. De exemplu, dacă se creează o categorie pentru calculatoare, se pot crea subcategoriile de calculatoare personale, terminale și imprimante.

b) Introducerea de mijloace fixe

Modulul de Contabilitate a Mijloacelor Fixe (FA) permite introducerea mijloacelor fixe în două moduri: prin adăugare manuala sau adăugare utilizând informații din modulul de Contabilitate a Furnizorilor (AP).

Adăugarea manuală poate fi facuta rapid, prin acceptarea valorilor implicite, sau detaliat, prin introducerea de informatii suplimentare când regulile implicite nu sunt valabile.

Adăugarea utilizând informațiile din modulul de Contabilitate a Furnizorilor (AP) se referă la adăugarea în grup a mijloacelor fixe din linii de factură.

c) Ajustări asupra mijloacelor fixe

Ajustarea unui mijloc fix presupune reclasificarea, schimbarea numărului de unități, ajustarea informațiilor financiare sau ajustarea în masă a mijloacelor fixe.

Reclasificarea presupune trecerea unui mijloc fix dintr-o categorie de mijloace fixe în altă categorie cu preluarea tuturor informațiilor contabile de la vechea categorie la cea nouă.

Se poate schimba numărul de unități pentru un mijloc fix, cu reînnoirea informațiilor de distribuție și asignare.

Ajustarea informațiilor financiare se execută pentru a corecta erorile, reînnoirea informațiilor financiare și de amortizare, trecerea pe cheltuială sau amortizarea ajustărilor făcute asupra unui mijloc fix, după data în care a fost plasat în serviciu.

c) Transferul mijloacelor fixe

Un activ se consideră ca fiind transferat atunci când au loc modificări în ecranul de asignare a activului. De asemenea, când o subunitate este închisă sau un angajat pleacă din companie se poate face transferului unui grup de active spre diferite locații sau diferiți angajați. Transferurile au loc numai în cadrul aceluiași registru de mijloace fixe și se poate face între diferite conturi de cheltuială cu amortizarea, între locații sau între angajați.

d) Scoaterea din funcțiune/casarea mijloacelor fixe

După expirarea duratei normate de viață sau din anumite motive, activele pot fi scoase din funcțiune total sau partial și casate. Un activ poate fi casat total sau parțial când este pierdut, furat, distrus, returnat sau pentru alte motive care determină stoparea folosirii lui.

Se pot casa active după numărul de unități sau după cost.

Se poate executa o casare în masă a unui grup de active.

Se pot replasa în serviciu activele casate, în condițiile în care casarea și replasarea în serviciu sunt făcute în același an fiscal.

e) Inventarierea mijloacelor fixe

Inventarierea fizică este procesul prin care se verifică dacă activele companiei care sunt în sistemul de producție Oracle se găsesc la locațiile fizice indicate.

e) Calculul amortizării si Închiderea de lună

La sfârșitul unei perioade contabile se închide luna prin rularea amortizării. În acel moment calculeză cheltuielile de amortiyare și ajustările, actualizându-se amortizarea cumulată și cea pe anul în curs și generându-se totodată jurnalele corespunzătoare tranzacțiilor care au avut loc în luna care s-a închis.

Înainte de a se rula amortizarea cu opțiunea de închidere de lună, trebuie verificat dacă s-au introdus toate tranzacțiile referitoare la luna ce trebuie închisă, deoarece odată închisă luna ea nu va mai putea fi deschisă niciodată.

e) Raportare

Oracle Assets oferă un set de rapoarte standard privind situația adăugărilor, transferurilor, retragerilor sau a altor modificări neînregistrate, asigurând astfel exactitatea inventarului și posibilitatea corectării lui cu diferențele constatate.

2.4.4. Modulul Oracle Cash Management – Contabilitatea lichidităților

Cu ajutorul acestui modul sunt introduse datele din extrasul de cont, pentru ca apoi liniile din extras să fie reconciliate cu plățile și încasările generate în Oracle Payables (Furnizori) și Oracle Receivables (Clienți), precum și cu jurnalele din Oracle General Ledger (Cartea Mare).

Principalele funcționalități ale modului

a) Definire bănci, conturi bancare, metode de încasare

b) Introducerea extraselor de cont

Din punct de vedere al modulului Contabilitatea trezoreriei, extrasul de cont bancar este compus din două părți: un antet și mai multe linii.

Antetul ajută la identificarea extrasului de cont și conține următoarele informații: numărul și numele contului bancar și data extrasului. Tot în antet se oferă informații despre banca și sucursala la care este deschis contul respectiv, valuta în care sunt exprimate sumele din cont, data de carte mare și totalurile de control.

O linie de extras de cont se referă la una sau mai multe plăți, încasări sau tranzacții diverse. Fiecare linie are număr, un tip de operație, o dată a operației bancare și o sumă. Informațiile opționale pe care le poate oferi o linie de extras bancar includ numărul încasării sau al facturii la care se referă suma, furnizorul către care s-a facut plata sau clientul care a plătit, comentarii auxiliare (o scurtă descriere a operației sau alte detalii).

c) Reconcilierea extraselor cu încasările și plățile

Fiecare linie dintr-un extras de cont va fi reconciliată cu tranzacțiile aferente din submodule.

d) Raportare

La final, pot fi rulate diverse rapoarte standard pentru efectuarea de verificări privind tranzacțiile disponibile pentru reconciliere sau pentru a obține detalii din extrase de cont.

2.4.5. Modulul Oracle General Ledger – Contabilitate generală (Cartea Mare)

Modulul de Contabilitate Generală (GL) oferă o soluție completă de management financiar care facilitează următoarele activități: controlul financiar, colectarea datelor, accesul la informație, raportarea și analiza financiară.

Oracle General Ledger reprezentă nucleul aplicațiilor financiare, concentrând întreaga informație contabilă referitoare la tranzacțiile efectuate și asigură consolidarea bilanțului contabil între mai multe planuri de conturi având aceeași structură sau structuri diferite și monede diferite (conturile se pot consolida după formule definite de beneficiar),

Principalele funcționalități din modulul Contabilitate Generală

a) Definire Set de registre contabile

Pentru a folosi Oracle Applications, în modulul Oracle General Ledger trebuie creat cel puțin un Set de Registre Contabile primar, registru definit de următoarele elemente: planul de conturi, calendarul contabil, moneda funcțională, metoda contabilă.

Definirea contului complet

Contul complet este o extensie multisegment a contului contabil obișnuit, fiind construit din segmente definite de utilizator (câmpul flexibil cheie Accounting Flexfield) și conține pe lângă contul natural alte segmente precum segmentul de companie, centrul de cost, tipul de activitate, tipul de cheltuială, astfel încât să poată urmări distribuția cheltuielilor și veniturilor.

Un element important al segmentelor este posibilitatea de a crea ierarhii în interiorul unui segment, adică relații de tipul copil-părinte; valorile efective ale tranzacțiilor se înregistrează numai în valorile de tip copil, valorile părinte fiind valori de însumare. De exemplu mai multe departamente pot crea regiuni, mai multe conturi analitice pot compune un cont sintetic.

Conturile de sumarizare sunt conturi adiționale în care se înregistrează toate tranzacțiile conturilor componente și se utilizează în scopul raportării mai rapide. Anumite segmente ale conturilor de sumarizare sunt segmente de detaliu, alte segmente sunt de total sau sunt asociate valorilor părinte.

Segmentul de cont contabil este caracterizat printr-un atribut care precizează natura contului: activ, pasiv, capital, venit, cheltuieli.

Reguli de validare și reguli de securitate

Reguli de validare încrucișată stabilesc combinațiile valide de segmente ale unui cod, astfel încât să asigure corectitudinea atribuirii conturilor în tranzacțiile efectuate. De exemplu, un cont de cheltuială nu poate avea un segment fără centru de cost.

Reguli de securitate ale segmentelor definesc pentru diferite categorii de utilizatori intervalele de valori din segmentele codului contabil la care aceștia au acces. Astfel de reguli pot fi atribuite fiecărui tip de utilizator pentru a controla drepturile de acces.

Moneda funcțională

În cadrul Contabilității generale Oracle, fiecărui set de registre contabile (companie) i se asociază o monedă funcțională, folosită pentru a înregistra tranzacții și pentru a păstra datele contabile. Moneda funcțională este în general moneda în care sunt efectuate cele mai multe tranzacții comerciale ale companiei. Sunt permise tranzacții în orice monedă definită în sistem, tranzacția fiind translatară în moneda funcțională, conform cu rata de schimb.

Contabilitatea generală poate lucra cu mai multe cursuri de schimb curent al zilei (al companiei, al user-ului, spot, de raportare), sau istoric, de sfârșit de perioadă, medie ponderată și să efectueze conversii în mod automat și suportă conversii, translații și reevaluări de valute în conformitate cu principiile contabile general acceptate (GAAP, IFRS). Se pot adopta mai multe monede funcționale cu scopul de a păstra moneda națională în contabilitatea statelor din UE care au adoptat moneda unică EURO (pentru perioada de coabitare).

Calendarul contabil

Pot exista diferite tipuri de perioade definite în cadrul modulului Contabilitate generală Oracle. Unele din acestea sunt predefinite (luna, trimestru, an), dar Oracle permite definirea unui număr practic nelimitat de perioade în funcție de necesități.

Definire/modificare formule de alocare în grup

Se definește o singură formulă pentru a aloca soldurile unor conturi către un grup de valori de segmente: conturi, centre de cost, etc. De asemenea, se pot folosi alocări pentru diverse note contabile cu multe conturi, precum închiderea conturilor de venituri și cheltuieli.

b) Importul datelor prin intermediul interfeței standard

Cu import jurnal se crează intrări jurnale din datele contabile care se importă din aplicațiile Oracle sau non-Oracle. Aceste jurnale pot fi revizuite, modificate și postate în același fel ca și jurnalele introduse manual.

Importul de jurnal crează jurnale din datele existente în tabela GL_INTERFACE, aplicația validând datele din interfață înainte de a crea jurnalele.

c) Introducerea manuală de jurnale

Necesitatea introducerii manuale de jurnale este determinată de închiderea lunii și/sau a anului fiscal. Se lucrează în ipoteza în care se introduc numai note contabile de corecție, de închidere perioadă sau pentru activitați necuprinse în diferitele surse de date. Se folosesc pe cât posibil note contabile standardizate.

d) Închiderea de perioadă

Datele se transmit în modulul Contabilitatea Generală lunar (conform procedurii de lucru). Se rulează procesele de transfer al datelor din submodule (Payables, Receivables, Assets) la modulul Contabilitate Generală. Asfel, se generează jurnalele cu tranzacțiile contabile rezultate în urma operațiunilor din submodule.

Deschiderea și închiderea perioadelor contabile controlează introducerea și postarea jurnalelor. Perioadele contabile pot avea una din următoarele stări:

• Deschisă (Open): Este permisă introducerea și postarea jurnalelor;

• Închisă (Closed): Nu este permisă introducerea și postarea jurnalelor până ce perioada nu este redeschisă. Este permisă raportarea și consultarea;

• Permanent închisă: Nu este permisă introducerea și postarea jurnalelor. Este permisă raportarea și consultarea;

• Viitoare înregistrare (Future – Entry): Este permisă introducere de jurnale, dar nu și postarea.

e) Raportarea

În afară de rapoartele standard, Contabilitate generală pune la dispoziția utilizatorului Generatorul de situații Financiare (FSG), o unealtă flexibilă ce poate fi utilizată pentru construirea de rapoarte personalizate fără programare

CAPITOLUL 3: Studiu de caz

3.1. Prezentarea companiei G4S România

G4S România reprezintă una dintre cele mai mari rețele de operațiuni de securitate la nivel global, cu 530.000 de angajați care operează în peste 110 țări, pe 6 continente. Sediul central și managementul executiv al G4S se află la Londra. Grupul G4S operează în Romania prin cele 3 companii în trei sectoare cheie și anume proiectare sisteme de securitate, servicii de securitate și servicii de administrare a numerarului, astfel:

Compania G4S Cash Solutions este specializată în furnizarea serviciilor de administrare a numerarului, compuse din: colectare și transport valori, procesare și depozitare numerar, alimentare și întreținere de nivel I ATM-uri.

G4S Secure Solutions este cea mai importantă companie de securitate din Romania, având mai mult de 12 ani de experiență în domeniu și activitate pe tot teritoriul țării. Compania are reprezentare la nivel național și management local la nivelul tuturor județelor țării. Calitatea prestației este asigurată atât de reprezentanții managementului cât și de structurile de audit intern care monitorizează permanent activitățile de toate tipurile, la toate nivelurile.

G4S Security Systems are o experiență de 10 ani pe piața de securitate din Romania, compania proiectând sisteme complete de securitate pentru obiective civile, industriale și comerciale, instituții guvernamentale, clădiri administrative, instituții financiar – bancare; instalează și asigură service-ul în garantie și postgaranție pentru un număr de peste 1500 de locații aparținând clienților săi.

3.2. Identificarea cerințelelor afacerii

Analiza cerințelor reprezintă o etapă importantă în cadrul procesului de parametrizare și adaptare a produsului software ERP, aceasta oferind o perspectivă realistă asupra așteptărilor clientului.

În cadrul G4S, soluția Oracle a apărut ca o necesitate de eficientizare a proceselor de business, care au crescut exponențial și care riscau să nu mai poată fi controlate. Ea trebuie să facă față exigențelor tot mai mari privind nevoile companiei și să îmbunătățească raportul cost eficiență, furnizând în același timp o valoare mai mare clienților.

Soluția Oracle vizează standardizarea proceselor financiare, logistice, de HR și Payroll. Utilizarea soluției ERP a instituit structuri organizatorice comune la nivel de grup, însă fiecare companie își poate păstra autonomia pentru îndeplinirea necesităților locale. Soluția simplifică procesele de management al vânzărilor de servicii de securitate și pază, reduce costurile de transport datorită procedurilor sincronizate de gestiune a proceselor de distribuție și face posibilă alocarea foarte exactă a veniturilor și cheltuielilor pe centre de cost, tipuri de activități, clienți, proiecte. Soluția Oracle trebuia să răspundă și consolidării și raportării la nivel de grup, pe conturi US GAAP, prin mecanisme simple, exacte și eficiente.

Soluția de financiar a fost construită pe principalele fluxurile operaționale mari de business: gestiunea mijloacelor fixe, fluxul de facturare a clienților, fluxul de înregistrare a facturilor de la furnizori, avansurilor și a deconturilor angajaților:

Figura 3.1. Diagrama fluxurilor de proces – module financiare

Toate aceste soluții au fost integrate într-o procedură globală de securitate, pe organizații, plecând de la entitatea legală de raportare, registre contabile, registre de mijloace fixe până la organizații de inventar și utlizatorul de aplicație.

3.2.1. Cerințe funcționale

Cerințele funcționale sunt identificate printr-o serie de afirmații privind funcționalitățile pe care sistemul trebuie să le satisfacă, modul în care trebuie să răspundă la anumite intrări și modul în care trebuie să reacționeze în anumite situații.

Cele mai importante cerințe funcționale identificate la nivelul companiei G4S în zona financiară sunt:

Implementarea unui sistem comun pentru cele 3 firme din cadrul grupului care să permită raportarea la nivel de grup dar care să mențină securitatea la nivel de organizație, în sensul că utilizatorii să aibă acces doar la informațiile din organizația pe care își desfășoară activitatea;

Sistemul să permita integrarea datelor din toate modulele operationale astfel încât să furnizeze informațiile necesare managementului pentru analiză;

Utilizarea mai multor planuri de conturi și sisteme contabile;

Posibilitatea înregistrării cheltuielilor și a veniturilor pe centre de cost/venit, tipuri de activități, tipuri de cheltuieli, clienți, proiecte.

Înregistrarea facturilor de la furnizori, a plăților, avansurilor, deconturilor angajaților;

Înregistrarea facturilor emise către clienți, urmărirea încasărilor;

Posibilitatea definirii de registre de mijloace fixe multiple prin care să se gestioneze activele și tranzacțiile efectuate asupra acestora, calcul automat al amortizării;

Introducerea extraselor de cont și reconcilierea liniilor acestora cu tranzacțiile din submodule în vederea evidențierii fluxurilor de numerar pe conturi bancare, generarea registrelor de casă;

Posibilitatea creării unor registre contabile secundare, de consolidare;

Opțiunea de a genera rapoarte standard precum și de a beneficia de rapoarte personalizate conform nevoilor interne de raportare, care să poată fi exportate în diverse formate (word, excel pdf, html, xml): balanțe, fișe de cont, extrase de cont, rapoarte privind soldurile sau rulajele, bilanț, declarații financiare, etc.

De asemenea, în ceea ce privește arhitectura funcțională a sistemului, acesta trebuie să permită extinderea facilă în vederea gestionării unor noi procese de business, toate funcționalitățile sistemului ERP trebuind să fie integrate.

3.2.2. Cerințe non-funcționale

Cerințele non-funcționale definesc proprietăți și constrângeri ale sistemului, precum: fiabilitatea, timpul de răspuns, cerințe pentru spațiul de stocare, performanța, standarde de calitate, securitatea, resursele.

Câteva cerințe non-funcționale identificare în cazul implementării sistemului ERP la G4S Romania sunt:

Serverul de baze de date trebuie să asigure prelucrări și regăsiri rapide pe volum mare de date;

Eliminarea redundanței datelor;

Posibilitatea configurării utilizatorilor sistemului și a drepturilor de acces în sistem;

Accesul la datele companiei să fie permis pe bază de utilizator și parolă și conform rolurilor aferente;

Posibilitatea de a accesa în orice moment informațiile din baza de date;

Arhitectura sistemului informatic integrat trebuie sa confere sistemului flexibilitate, scalabilitate si modularitate.

3.3. Configurări de bază

Definirea structurii de cont contabil

În aplicațiile Oracle, contul complet este o extensie multisegment a contului contabil obișnuit. Astfel, la preluarea informațiilor contabile se înregistrează informațiile structurat conform mai multor criterii. Fiecare segment are un număr, un nume și atasat un set de valori.

La G4S, contul complet se formează din următoarele segmente:

1. Compania, care poate lua una din valorile definite în setul XXROR_COMPANIA:

RO001 – G4S Secure Solutions

RO002 – G4S Cash Solutions

RO100 – G4S Security Systems

și indică organizația pentru care se face o înregistrare;

2. Cont contabil: orice cont valid din planul de conturi definit în aplicație; valorile pentru segmentul cont se definesc în setul XXROR_ACCOUNT;

3. Centru de cost: centrul de cost pe care se dorește a fi facută înregistrarea și care trebuie să aparțină organizației alese în segmentul de companie; valorile pentru centrele de cost se definesc în setul XXROR_COST_CENTER;

4. Activitate: activitatea pe care se dorește a fi făcută înregistrarea; valorile pentru activități sunt definite în setul XXROR_ACTIVITY;

5. Client: valorile pentru segmental privind clientul pe care se face înregistrarea sunt definite în setul XXROR_CLIENT;

6. Proiect: valorile pentru segmentul proiect sunt definite în setul XXROR_PROIECT;

7. Tip cheltuiala: valorile pentru tipurile de cheltuieli sunt definite în setul XXROR_TYPE;

8. Rezerva: valorile pentru acest segment de rezervă sunt definite în setul XXROR_SPARE.

Definirea tipurilor de perioade și a calendarului contabil

Tipurile de perioade standard în aplicație sunt saptamana, luna, trimestrul, anul.

La nivelul G4S, calendarul este format din 13 perioade, date de cele 12 luni calendaristice, plus o perioadă de ajustare. Aceasta din urma este ultima zi a anului calendaristic și se folosește pentru diverse ajustări, cum ar fi cele legate de schimbarea planului de conturi.

Definirea monedelor

Aplicația are predefinite toate monedele ISO (International Standards Organization), permițând definirea de alte monede, care pot fi folosite în diverse tranzacții.

Definirea de reguli de securitate

Aceste reguli sunt utilizate pentru a controla accesul la intervale de valori ale segmentelor prin definirea unor reguli de securitate pentru o responsabilitate specifică unui utilizator.

Întrucât configurația de față cuprinde 3 organizații, segmentul Compania a fost securizată, astfel încât utilizatorii să poată efectua înregistrări și să poată vizualiza datele doar din organizația în care are acces:

Stabilirea de reguli de validare între segmentele câmpurilor flexibile

Sunt folosite pentru a preveni crearea de combinații de conturi invalide sau nesemnificative la introducerea tranzacțiilor, limitându-se accesul la diferite valori din structura de cont G4S.

În exemplul de mai jos se definește o regulă care specifică faptul că orice combinație de pe compania RO002 Cash Solutions ce conține unul din conturile specificate, în combinație cu alt tip de cheltuială decât 102 și 201 nu poate fi utilizată.

Definirea utilizatorilor și acordarea accesului

Accesul în aplicație se face prin definirea unui unui utilizator de către administratorul de sistem și atașarea responsabilităților la care va avea acces, în funcție de operațiunile pe care trebuie să le execute.

CAPITOLUL 4: Dezvoltări realizate în cadrul modulului Oracle Payables

4.1. Configurări de bază în modulul Contabilitate Furnizori

Creare profil de plăți

Configurare → Plată → Administrator plăți

Setup → Payment → Payment Administrator

Nume formă: Configurare plăți (Oracle Payments Setup)

Se va deschide următoarea pagină HTML:

Se alege „Payment process profile”:

Se apasă butonul (B) Creare.

Se completează informațiile conform datelor de mai jos.

Zona Reguli de utilizare:

Zona Format instrucțiuni de plată:

Se apasă butonul (B) Aplicare.

Starea sarcinii se alege ca fiind Finalizata și se apasă butonul (B) Aplicare:

Definire opțiuni financiare

Configurare → Opțiuni → Opțiuni Financiare

Setup → Options → Financials Options

Nume formă: Opțiuni Financiare (Financials Options)

În tab-ul Contabilitate se adaugă următoarele conturi de Cartea Mare:

Definire seturi de distribuții

Configurare → Factură → Seturi de distribuție

Setup → Invoice → Distribution Sets

Nume formă: Seturi de distribuție (RO Payables Manager) (Distribution Sets)

Definire opțiuni furnizori

Configurare → Opțiuni → Configurare sistem Payables

Setup → Options → Payables System Setup

Nume formă: Configurare sistem Payables (RO Payables Manager) (Payables System Setup)

Sunt setate următoarele opțiuni:

Definire opțiuni contabilitate furnizori

Configurare → Opțiuni → Opțiuni Payables

Setup → Options → Payables Options

Nume formă: Opțiuni AP (RO Payables Manager) (Payables Options)

Se stabilesc opțiunile astfel:

Tab-ul Opțiuni de contabilizare

În tab-ul Monedă se stabilesc conturile de Cartea Mare astfel:

Tab-ul Raportare fiscală:

Tab-ul Factură:

Tab-ul Aprobare:

Tab-ul Identificare:

Tab-ul Dobândă:

Tab-ul Decont de cheltuieli:

Tab-ul Plată:

Tab-ul Taxă cu reținere la sursă:

Tab-ul Furnizor:

Tab-ul Rapoarte:

Definire termene de plată

Configurare → Factura → Condiții de plată

Setup → Invoice → Payment Terms

Nume formă: Condiții de plată (RO Payables Manager) (Payment Terms)

În forma accesată se definesc termenele de plată, stabilindu-se: denumirea condiției de plată, descrierea acesteia, datele efective, procentul din scadență, numărul de zile.

Definire bănci și conturi bancare

Acest pas se efectuează în modulul Cash Management.

Definire șablon pentru deconturi de cheltuieli

Configurare → Factură → Șabloane pt. deconturi de cheltuieli

Setup → Invoice → Expense Reports Templates

Nume formă: Șabloane pentru deconturi de cheltuieli (Expense Report Template)

Se setează șablonul pt. deconturi de cheltuieli conform figurii de mai jos:

Definire calendar de aging

Configurare → Calendar → Grupe de vechime

Setup → Calendar → Aging Periods

Nume formă: Perioade din scadențar (Aging Periods)

Pentru a crea un nou set de perioade de Aging, se completează: „Nume”, „Descriere” și se definesc coloanele cu regulile aferente, precum în figura următoare:

Deschidere perioadă contabilă pe AP

Contabilitate → Control perioade AP

Accounting → Control Payables Periods

Nume formă: Control perioade AP (Control Payables Periods)

Pentru a deschide o perioadă se poziționează cursorul în câmpul „Stare periodă” aferent numelui perioadei care se dorește a fi deschisă și se selectează din listă starea “Open” /“Deschis”.

4.2. Dezvoltări în cadrul modulului Oracle Payables

Dezvoltările realizate în cadrul modului Contabilitatea Furnizorilor constă într-o serie de rapoarte și procese customizate în vederea adaptării produsului software la cerințele apărute în cadrul G4S România.

Pentru satisfacerea cerințelor de raportare au fost utilizate drept instrumente de dezvoltare produsele Toad for Oracle, Oracle Reports Builder și Oracle BI Publisher precum și limbajul de interogare SQL, limbajul PL/SQL și standardul XML.

Modelul entitate-relație simplificat pentru structura modulul de furnizori se prezintă astfel:

4.2.1. Metodologia de realizare a rapoartelor utilizând Oracle Reports Builder

Principalele etape parcurse în realizarea rapoartelor sunt următoarele:

Crearea instrucțiunii SQL cu ajutorul TOAD for Oracle, o aplicație software utilizată pentru dezvoltarea și administrarea bazelor de date relaționale folosind SQL sau o oricarui alt instrument [ANEXA 1], [ANEXA 5], [ANEXA 2], [ANEXA 14], [ANEXA 3], [ANEXA 25].

Crearea manuală a unui nou proiect în Oracle Reports Builder și copierea instrucțiunii SQL din TOAD în acesta [ANEXA 15], [ANEXA 26].

Salvarea proiectului ca fișier .rdf și generarea fișierului XML pe baza instrucțiunii SQL.

Crearea template-ului pentru raport în Microsoft Word și salvarea acestuia ca fișier .rtf .

Încărcarea datelor din fișierul XML în template în cazul în care raportul se realizează utilizând Oracle Reports Builder [ANEXA 16], [ANEXA 27] sau a fișierului XML cu definiția raportului [ANEXA 6], [ANEXA 7] dacă se utilizează doar XML Publisher și maparea corespunzătoare a câmpurilor.

Inserarea de funcții de grup la nivelul template-ului dacă este necesar.

Previzualizarea raportului în format PDF și verificarea corectitudinii acestuia.

Încărcarea instrucțiunii SQL, adică a fișierului .rdf generat în Oracle Reports Builder pe server-ul aplicației [ANEXA 17], [ANEXA 28].

Definirea seturilor de valori pentru parametrii raportului dacă este cazul, din responsabilitatea de System Administrator, pe calea Application – Validation – Set [ANEXA 10], [ANEXA 18], [ANEXA 30].

Crearea executabilului din responsabilitatea de System Administrator, pe calea Concurrent – Program – Executable [ANEXA 22], [ANEXA 34].

Crearea programului concurent din aceeași responsabilitate pe calea Concurrent – Program – Define [ANEXA 11], [ANEXA 21], [ANEXA 33],.

Asocierea cererii unei responsabilități se face din responsabilitatea de System Administrator, pe calea Security – Responsibility – Define și apoi System Administrator – Security – Responsibility – Request [ANEXA 12], [ANEXA 23], [ANEXA 35].

Crearea Data Definition – care face legătura dintre programul concurrent și template. Acest lucru se realizează din responsabilitatea de XML Publisher, pe calea Data Definitions – Create Data Definition [ANEXA 8], [ANEXA 19], [ANEXA 31].

Definirea Template-ului se face astfel: XML Publisher Administrator – Templates – Create Template [ANEXA 9], [ANEXA 20], [ANEXA 32].

Din responsabilitatea asociată raportului creat se trimite cererea de rulare a raportului după care se poate verifica output-ul raportului generat [ANEXA 13], [ANEXA 24], [ANEXA 36].

4.2.2. Raportul Balanța furnizori

Utilitatea economică:

Raportul oferă contabililor posibilitatea de a obține rapid situații privind soldurile furnizorilor pe diverse conturi, reflectând soldurile inițiale și mișcările pe debit respectiv credit într-o anumită perioadă de timp, respectiv soldurile finale pentru perioada interogată.

Parametri de rulare:

– De la: data de început a intervalului pentru care se dorește obținerea situației;

– Până la: data de final a intervalului pentru care se rulează raportul ;

– Contul: parametru opțional ; dacă nu se selectează un cont, este obținută situația pentru toate conturile în care au fost implicați furnizorii în intervalul selectat ;

– Furnizor : parametru opțional ; dacă nu se selectează un furnizor, se va obține situația pentru toți furnizorii pe care au fos înregistrate tranzacții în intervalul selectat ;

– Organizația: parametru obligatoriu dar care nu apare în lisăa la momentul rulării raportului, se inițializează automat în funcție de responsabilitatea de pe care se rulează raportul.

Codul sursă, modul de construire a raportului, câmpurile acestuia și rezultatele se regăsesc în anexele : [ANEXA 1], [ANEXA 5], [ANEXA 6], [ANEXA 7], [ANEXA 8], [ANEXA 9], [ANEXA 10], [ANEXA 11], [ANEXA 12], [ANEXA 13].

4.2.3. Raportul Situația plății facturilor

Utilitatea economică:

Acest raport oferă detalii privind plățile și încasărilor raportate la furnizori pe o anumită perioadă de timp și pe conturi bancare.

Parametri de rulare:

– Organizația: parametru obligatoriu dar care nu apare în listă la momentul rulării raportului, se inițializează automat în funcție de responsabilitatea de pe care se rulează raportul;

– Furnizor : parametru opțional ce permite obținerea situației pentru un anumit furnizor sau pentru toți furnizorii de pe organizația respectivă ;

– De la data facturii: permite obținerea situației pentru facturile dintr-un interval;

– Până la data facturii: permite obținerea situației pentru facturile dintr-un interval;

– De la data plății: permite obținerea situației în funcție de plățile înregistrate într-un interval;

– Până la data plății: permite obținerea situației în funcție de plățile înregistrate într-un interval;

– Banca: se poate obține situația privind plățile efectuate printr-o anumită bancă specificată prin acest parametru opțional ;

– Contul bancar : raportul permite obținerea detaliilor privind plățile aferente efectuate printr-un anumit cont bancar.

Codul sursă, modul de construire a raportului, câmpurile acestuia și rezultatele se regăsesc în anexele : [ANEXA 2], [ANEXA 14], [ANEXA 15], [ANEXA 16], [ANEXA 17], [ANEXA 18], [ANEXA 19], [ANEXA 20], [ANEXA 21], [ANEXA 22], [ANEXA 23], [ANEXA 24].

4.2.4. Raportul Aging furnizori

Utilitatea economică:

Registrul scadențar se folosește pentru evidența achitării furnizorilor detaliată pe furnizori, respectiv pe facturi, și pe perioade, astfel încât să se poată efectua analize privind fluxurile de lichidități pentru perioada viitoare.

Parametri de rulare:

– Registrul contabil: parametru obligatoriu, se inițializează automat în funcție de responsabilitatea de pe care se rulează raportul;

– As of date : data la care se dorește obținerea situației ;

– Liability account from : de la contul

– Liability account to : până la contul

– Supplier name : parametru opțional, se poate obține scadențarul fie pentru un anumit furnizor, fie pentru toți furnizorii de pe organizația respectivă.

Codul sursă, modul de construire a raportului, câmpurile acestuia și rezultatele se regăsesc în anexele : [ANEXA 3], [ANEXA 25], [ANEXA 26], [ANEXA 27], [ANEXA 28], [ANEXA 29], [ANEXA 30], [ANEXA 31], [ANEXA 32], [ANEXA 33], [ANEXA 34], [ANEXA 35], [ANEXA 36].

4.3. Soluția de gestiune a cheltuielilor în avans

Cu ajutorul acestei soluții se ține evidența cheltuielilor efectuate în avans care urmează a se suporta eșalonat pe cheltuieli, pe baza unui scadențar, în perioadele/exercițiile viitoare.

Cheltuiala în avans este cheltuiala efectuată în prezent dar înregistrată numai în momentul în care ea devine relevantă; în momentul înregistrarii, cheltuiala este considerată un activ, de exemplu, plata chiriei sau a unei prime de asigurare în avans, abonamente sau alte cheltuieli efectuate anticipat.

Soluția permite evidența cheltuielilor înregistrate în avans (471) și trecerea în mod automat a acestora pe contul de cheltuială efectivă, lună de lună, până la stingerea integrală, conform scandețarelor.

Repartizarea cheltuielilor în avans pe perioade se face automat, conform unui plan prestabilit.

Tratamentul financiar-contabil al cheltuielilor în avans
Cheltuielile în avans trebuie repartizate în perioadele fiscale la care se referă.
Exemplu: Avem o chirie plătită în ianuarie 2013 pentru următoarele 24 luni, în sumă de 120.000 lei, corespunzatoare sumei de 5000 ron în fiecare lună.
La înregistrarea chiriei, se evidențiază cheltuiala în avans prin articolul contabil:

471 Cheltuieli în avans = 401 Furnizori, cu suma de 120.000 ron. În fiecare luna, se efectuează înregistrarea: 612 Chelt. cu chirii și locații de gestiune = 471 Chelt. în avans, cu suma de 5.000 ron. De abia în acest moment această cheltuială va afecta impozitul pe profit.

Schema proceselor:

Setup necesar:

Se definesc Seturile de distribuții:

În acest caz 47101 este contul pe care se va înregistra cheltuiala în avans cu RCA-urile iar 613003 este contul pe care se va descărca în fiecare lună cheltuiala efectivă în Contabilitatea generală.

Setarea câmpului descriptiv Invoice Lines, astfel încât la nivel de linie factură contextul să se stabilească în funcție de setul de distribuție selectat:

Se apasă butonul Segments pentru a defini segmentele componente ale câmpului descriptiv, corespunzătoare informațiilor care se doresc a fi introduse referitoare la cheltuiala în avans. În cazul asigurărilor de răspundere civilă auto se vor defini 2 segmente: unul pentru înregistrarea numărului de mașină pe care se va aloca cheltuiala și unul pentru introducerea numărului de rate reprezentând numărul de perioade viitoare pe parcursul cărora cheltuiala se eșalonează:

Numărul de mașină se va selecta la nivel de linie factură dintr-un set de valori XXROR_AP_SSYS_NR_MASINA.

Se îngheață câmpul flexibil descriptiv prin bifarea opțiunii “Freeze flexfield” și se compilează descriptivul.

Pentru ca pe liniile din jurnalele ce vor fi generate în Contabilitea Generală să se poată urmări cu ușurință alocarea cheluielilor pe furnizor/factură/număr de mașină/rate, se customizează câmpul descriptiv Enter Journals: Lines astfel:

– se definește contextul cu aceeași denumire cu a setului de distribuții

-se introduc segmentele componente reprezentând detaliile pe care dorim să le înregistrăm pe liniile din jurnale generate

La final, se îngheață câmpul descriptiv bifând opțiunea Freeze Flexfield Definition și se compilează.

Modul de funcționare:

Dezvoltare:

Se definesc procesele XXROR_FIN_INSERT_471, respectiv XXROR Alocare cheltuieli în avans:

Se crează și raportul de verificare XXROR Situația cheltuieli în avans (471):

Codul sursă pentru acest raport se găsește în [ANEXA 4].

Mod de operare

Pasul 1: Introducerea facturii

Se introduce antetul facturii și se trece la completarea detaliilor de pe linii:

– Se alege din listă setul de distribuții ( Distribution set).

– Se completează câmpurile obligatorii din câmpul descriptiv Invoice Lines – care este sincronizat cu setul de distribuții ales.

Se merge în ecranul de Distribuții și se completează segmentele aferente cheltuielii viitoare pe contul de 471. Este important să fie completate aceste informații (Centrul de cost, Activitatea, Tip cheltuiala) pentru alocarea lunară pe contul de 6xx și pentru a evita erorile:

În cazul în care sunt mai multe combinații se pot adăuga linii de distribuții noi, important este ca totalul din Distribuții să fie egal cu total linie:

În liniile de factură se pot adauga și alte cheltuieli în avans sau alte cheltuieli curente.

Se validează și se contabilizează factura:

Pasul 2: Rulare și verificare proces XXROR_FIN_INSERT_471

Procesul va insera în tabela intermediară XXROR_FIN_471 toate liniile din facturi eligibile, adică pe cele care conțin cheltuială în avans înregistrată conform procedurii descries anterior.

Se apasă butonul OK și apoi Submit.

După finalizarea cererii se consultă fișierul de log rezultat pentru a verifica suma totală:

Pasul 3: Rulare și verificare process XXROR Alocare cheltuieli în avans din responsabilitate de GL

Automat va fi lansat procesul de import jurnale.

Se poate consulta rezultatul importului apăsând butonul View Output:

Dacă importul se finalizează cu success nota contabilă generată poate fi verificată în aplicație:

Se observă cum cheltuiala trece din creditul contului 47101 în debitul contului 613003.

În câmpul descriptiv asociat fiecărei linii pot fi consultate detaliile privind factura din care provine suma descărcată precum și alte informații:

În acest moment, în tabela XXROR_FIN_471 au fost actualizate datele privind descărcarea cheltuielilor în GL:

Pentru verificare se poate rula raportul XXROR Situația cheltuieli în avans (471):

La final, dacă sumele sunt corecte, jurnalul se poate posta pentru ca sumele să se reflecte în Balanță.

CONCLUZII

Cel mai mare beneficiu al implementării unui sistem integrat de tip ERP este organizarea proceselor de business, întrucât dacă o companie nu reușește să-și pună în ordine activitățile, este greu de presupus că este capabilă să obțină performanța economică. Aprovizionarea, managementul stocurilor, urmărirea clienților, organizarea depozitelor, urmărirea cash-flow-ului, bugetarea, managementul centrelor de cost, sunt doar câteva exemple semnificative despre zonele în care soluția de financiar, integrată cu celelalte soluții din ERP acționează în mod direct.

Un alt beneficiu evident este redirecționarea activităților departamentelor dinspre zona operațională repetitivă către analiză și control. Acest lucru este generat de eliminarea redundanțelor în operarea documentelor și prin automatizarea anumitor procese repetitive, mari consumatoare de timp.

Instrumentele de raportare operațională în timp real, precum și cele de analiză managerială complexă adresează nevoia fundamentală existentă la nivelul fiecărei verigi organizaționale de a avea informații relevante, utile, prezentate într-o formă intuitivă, flexibilă, pentru a putea susține decizii corecte.

O companie care aprovizionează, gestionează și vinde mii și zeci de mii de produse și servicii are nevoie de un control absolut al acestora prin nomenclatoarele de produse, servicii.

În definirea proceselor de lucru folosind o soluție care lucrează online, controlul nomenclatoarelor este centralizat, iar răspunderea revine unui numar limitat de persoane specializate, care au responsabilități clar definite.

În cazul dezvoltării distribuite geografic, așa cum este G4S, soluția favorizează dezvoltarea scalabilă a companiei. Deschiderea unei noi filiale sau al unui nou punct de lucru și integrarea rapidă a acestuia cu organismul companiei sunt făcute cu rapiditate și costuri semnificativ reduse. De asemenea, costurile de upgrade sunt reduse substanțial, noile versiuni îmbunătățite, sau adăugarea de module suplimentare putând fi realizate foarte ușor.

ANEXE

ANEXA 1: Codul aferent raportului Balanța furnizori

select

ROW_NUMBER () OVER (PARTITION BY cont ORDER BY vendor_name) NRCRT,

VENDOR_ID,

VENDOR_NAME,

CONT,

COMPANIE,

SOLD_INITIAL,

DEBIT_RON,

CREDIT_RON,

SOLD_FINAL,

DATE_START,

DATE_END,

SUM(SOLD_INITIAL) OVER (PARTITION BY CONT) SUM_SOLD_INITIAL,

SUM(DEBIT_RON) OVER (PARTITION BY CONT) SUM_DEBIT_RON,

SUM(CREDIT_RON) OVER (PARTITION BY CONT) SUM_CREDIT_RON,

SUM(SOLD_FINAL) OVER (PARTITION BY CONT) SUM_SOLD_FINAL

from(

– BALANTA PE PARTENERI ––––––––––––––––––––-

SELECT

VENDOR_ID,

MAX(VENDOR_NAME) VENDOR_NAME,

MAX(SEGMENT2) CONT,

max(description) COMPANIE,

decode (MAX(gl_account_type) , 'L', (SUM(SI_CREDIT_RON) – SUM(SI_DEBIT_RON)), (SUM(SI_DEBIT_RON) – SUM(SI_CREDIT_RON))) SOLD_INITIAL,

SUM(DEBIT_RON) DEBIT_RON,

SUM(CREDIT_RON) CREDIT_RON,

decode (MAX(gl_account_type) , 'L',(SUM(SI_CREDIT_RON) – SUM(SI_DEBIT_RON) + SUM(CREDIT_RON) – SUM(DEBIT_RON)),(SUM(SI_DEBIT_RON) – SUM(SI_CREDIT_RON) + SUM(DEBIT_RON) – SUM(CREDIT_RON)))SOLD_FINAL,

to_char(to_date(:p_date_start,'yyyy/mm/dd hh24:mi:ss'), 'DD-MON-YYYY') date_start,

to_char(to_date(:p_date_end,'yyyy/mm/dd hh24:mi:ss'), 'DD-MON-YYYY') date_end

FROM

(

–- DETALII LINII CONTABILE AP–––––––––––

select

sup.vendor_id,

sup.vendor_name,

gcc.segment2,

gcc.concatenated_segments,

xlal.accounting_date,

gl.description,

gcc.gl_account_type,

case when accounting_date < to_date(:p_date_start,'yyyy/mm/dd hh24:mi:ss') then NVL(xlal.accounted_dr,0) else 0 end SI_debit_RON,

case when accounting_date < to_date(:p_date_start,'yyyy/mm/dd hh24:mi:ss') then NVL(xlal.accounted_cr,0) else 0 end SI_credit_RON,

case when accounting_date >= to_date(:p_date_start,'yyyy/mm/dd hh24:mi:ss') then NVL(xlal.accounted_dr,0) else 0 end debit_RON,

case when accounting_date >= to_date(:p_date_start,'yyyy/mm/dd hh24:mi:ss') then NVL(xlal.accounted_cr,0) else 0 end credit_RON

from xla_ae_lines xlal,

gl_code_combinations_kfv gcc,

ap_suppliers sup,

gl_ledgers gl

where 1=1

and xlal.code_combination_id = gcc.code_combination_id

and sup.vendor_id = xlal.party_id

and xlal.accounting_date <= to_date(:p_date_end,'yyyy/mm/dd hh24:mi:ss')

and sup.vendor_id = nvl(:p_vendor_id, sup.vendor_id)

and gcc.segment2 = nvl(:p_cont, gcc.segment2)

and xlal.ledger_id = :p_ledger_id

and xlal.ledger_id = gl.ledger_id

and xlal.application_id = 200

)

GROUP BY segment2, VENDOR_ID

)

WHERE NOT (SOLD_INITIAL = 0 AND DEBIT_RON=0 AND CREDIT_RON = 0 AND SOLD_FINAL = 0 )

ORDER BY cont, NRCRT

ANEXA 2: Codul aferent raportului Situația plății facturilor

Q1:

SELECT vendor_name, invoice_num, invoice_date, invoice_amount, amount_paid,

amount_remaining, invoice_id, invoice_currency_code

FROM (SELECT DISTINCT pov.vendor_name, i.invoice_num, i.invoice_date,

i.invoice_amount, NVL (i.amount_paid,

0) amount_paid,

(i.invoice_amount – NVL (i.amount_paid, 0)

) amount_remaining,

i.invoice_id, i.invoice_currency_code

FROM po_vendors pov,

ap_invoices_all i,

ap_invoice_payments_all ip,

hz_parties hzp,

ap_checks_all apc,

ce_bank_acct_uses_all auo,

ce_bank_accounts cba

WHERE pov.vendor_id = i.vendor_id

AND pov.vendor_name = NVL (:p_vendor, pov.vendor_name)

AND i.invoice_date BETWEEN NVL (:p_invoice_date_from,

TO_DATE ('1900/1/1',

'YYYY/MM/DD'

)

AND NVL (:p_invoice_date_to,

SYSDATE

)

AND i.invoice_id = ip.invoice_id

AND ip.check_id = apc.check_id

AND hzp.party_id = cba.bank_id

AND cba.bank_account_id = auo.bank_account_id

AND auo.bank_acct_use_id = apc.ce_bank_acct_use_id

AND hzp.party_id = NVL (:p_banca, hzp.party_id)

AND apc.bank_account_name =

NVL (:p_cont_bancar, apc.bank_account_name)

AND i.amount_paid <> 0

AND i.cancelled_date IS NULL

AND i.invoice_id IN (

SELECT ip.invoice_id

FROM ap_invoice_payments_all ip,

ap_checks_all apc,

ce_bank_acct_uses_all auo,

ce_bank_accounts cba,

hz_parties hzp

WHERE ip.check_id = apc.check_id

AND hzp.party_id = cba.bank_id

AND cba.bank_account_id = auo.bank_account_id

AND auo.bank_acct_use_id =

apc.ce_bank_acct_use_id

AND hzp.party_id =

NVL (:p_banca, hzp.party_id)

AND apc.bank_account_name =

NVL (:p_cont_bancar,

apc.bank_account_name

)

AND apc.check_date

BETWEEN NVL (:p_payment_date_from,

TO_DATE ('1900/1/1',

'YYYY/MM/DD'

)

AND NVL (:p_payment_date_to,

SYSDATE

)

AND apc.status_lookup_code != 'VOIDED'

AND NVL (ip.amount, 0) != 0)

AND i.org_id = :p_org_id

UNION ALL

SELECT DISTINCT pov.vendor_name, i.invoice_num, i.invoice_date,

i.invoice_amount, NVL (i.amount_paid,

0) amount_paid,

(i.invoice_amount – NVL (i.amount_paid, 0)

) amount_remaining,

i.invoice_id, i.invoice_currency_code

FROM po_vendors pov, ap_invoices_all i

WHERE

pov.vendor_name = NVL (:p_vendor, pov.vendor_name)

AND pov.vendor_id = i.vendor_id

AND (i.amount_paid IS NULL OR i.amount_paid = 0)

AND i.invoice_date BETWEEN NVL (:p_invoice_date_from,

TO_DATE ('1900/1/1',

'YYYY/MM/DD'

)

AND NVL (:p_invoice_date_to,

SYSDATE

)

AND i.cancelled_date IS NULL

AND i.invoice_id IN (

SELECT ip.invoice_id

FROM ap_invoice_payments_all ip,

ap_checks_all apc,

ce_bank_acct_uses_all auo,

ce_bank_accounts cba,

hz_parties hzp

WHERE ip.check_id = apc.check_id

AND hzp.party_id = cba.bank_id

AND cba.bank_account_id = auo.bank_account_id

AND auo.bank_acct_use_id =

apc.ce_bank_acct_use_id

AND hzp.party_id =

NVL (:p_banca, hzp.party_id)

AND apc.bank_account_name =

NVL (:p_cont_bancar,

apc.bank_account_name

)

AND apc.check_date

BETWEEN NVL (:p_payment_date_from,

TO_DATE ('1900/1/1',

'YYYY/MM/DD'

)

AND NVL (:p_payment_date_to,

SYSDATE

)

AND apc.status_lookup_code != 'VOIDED'

AND i.org_id = :p_org_id

AND NVL (ip.amount, 0) != 0))

ORDER BY vendor_name, invoice_date

Q2:

SELECT ip.invoice_id, ip.amount paid_amount, apc.check_date data_platii,

apc.check_number doc_num, apc.ce_bank_acct_use_id,

apc.bank_account_name, hzp.party_name

FROM ap_invoice_payments_all ip,

ap_checks_all apc,

ce_bank_acct_uses_all auo,

ce_bank_accounts cba,

hz_parties hzp

WHERE ip.check_id = apc.check_id

AND hzp.party_id = cba.bank_id

AND cba.bank_account_id = auo.bank_account_id

AND auo.bank_acct_use_id = apc.ce_bank_acct_use_id

AND hzp.party_id = NVL (:p_banca, hzp.party_id)

AND apc.bank_account_name = NVL (:p_cont_bancar, apc.bank_account_name)

AND apc.check_date BETWEEN NVL (:p_payment_date_from,

TO_DATE ('1900/1/1', 'YYYY/MM/DD')

)

AND NVL (:p_payment_date_to, SYSDATE)

AND apc.status_lookup_code != 'VOIDED'

AND ip.org_id = :p_org_id

Q3:

select substr(name,1,length(name)-2) organization_name

,to_char(sysdate,'DD-MON-YYYY HH24:MI:SS') data_rularii

from hr_all_organization_units

where organization_id = :P_ORG_ID

ANEXA 3: Codul aferent raportului Aging furnizori

SELECT liability_acc, vendor_name, invoice_num, invoice_date, gl_date,

due_date, invoice_currency_code, invoice_amount,

invoice_amount + payment_amount + prepayment_amount amount_remaining,

CASE

WHEN TO_DATE (:p_as_of_date) – due_date <= 0