Implementare Sistem Informatic Erp
Implementare sistem informatic ERP
Context
Descriere generala
Activitatile si diviziile grupului
Divizia produse chimice
Divizia agricultura
Obiectivele si aria de cuprindere a proiectului
Obiectivele generale
Aria de cuprindere
Cerintele sistemului
Cerinte generale
Cerinte arhitecturale
Cerinte functionale
Financiar
Contabilitate generala
Contabilitatea furnizorilor si a platilor
Contabilitatea clientilor si a incasarilor
Managementul trezoreriei
Imobilizari corporale si necorporale
Contabilitatea de gestiune
Gestiunea bugetelor
Managementul achizitiilor
Gestiune stocuri
Vanzari
Gestiune flota auto
Productie chimica
Mentenanta echipamentelor
Managementul proiectelor
Contracte de arenda
Productie vegetala
Conditionare-depozitare
Cerinte non-functionale
Cerinte de servicii
Formatul ofertelor
Metodologie evaluare oferta
Context
Descriere generala
S.C. EURO TSA S.A. este o companie cu capital privat mixt romano – britanic, inființata in anul 1994, avand ca principale obiecte de activitate producerea și comercializarea ingrașamintelor și a altor produse chimice obținute prin chimizarea gazelor naturale, cultura cerealelor, a plantelor tehnice etc.
Grupul EURO TSA este unul dintre cele mai mari grupuri agro-industriale din Romania cu peste 10000 de angajati, liderul industriei de ingrasaminte chimice din tara si un jucator important la nivel regional (capacitati totale de productie de 3.000.000 tone/an) si unul dintre cei 3 mari producatori, la nivel de national, de cereale si plante tehnice, cu suprafete cultivate de peste 50.000 ha in fiecare an.
Grupul EURO TSA care sarbatoreste 17 ani de activitate in Romania, este detinut si condus de domnul presedinte Ioan Niculae, prin principala sa companie EURO TSA fondata in 1994. Principala strategie a grupului a fost sa atinga un nivel de integrare verticala cat mai mare in cele doua domenii principale de activitate: industria ingrasamintelor chimice si agricultura.
In anul 2009 grupul a finalizat investitia greenfield in cea mai mare fabrica de bioetanol din sud-estul Europei cu o capacitate de productie de 96.000 tone/an.
Activitatile si diviziile grupului
In interiorul grupului activitatile au fost structurate in jurul și sub controlul lui EURO TSA in 2 divizii principale: divizia produse chimice, divizia agricultura.
Divizia produse chimice
Grupul EURO TSA, prin intermediul combinatelor chimice pe care le controleaza sau cu care lucreaza in parteneriat, este unul dintre cei mai importanți jucatori din peisajul industriei chimice și agricole din Romania. Combinatele se ocupa, in principal dar nu exclusiv, cu: producția de bioetanol, metanol, amoniac, fabricarea de ingrașaminte chimice, producerea și comercializarea de produse azotoase, fabricarea explozivilor.
EURO TSA activeaza ca un centru comercial pentru companiile din grup, controland politica comerciala si portofoliul de clienti (90% export) si principalul contractor si furnizor de gaze naturale si energie electrica pentru cele 7 fabricile ale sale.
EURO TSA achizitioneaza centralizat gazul natural si energia electrica si asigura, in baza unui contract de procesare, necesarul de consum de energie pentru fiecare fabrica. Contractele stabilesc tarife de procesare a materiei prime (gazul natural) pentru productia semifabricatelor si produselor finite in baza carora, in functie de cantitatea produsa, fiecare combinat factureaza serviciile de procesare catre Interagro SA.
Materialele auxiliare din import sunt achizitionate centralizat prin Interagro si vandute combinatelor. Gazul natural si energia electrica nu sunt vandute combinatelor.
La finalul fiecarei luni se intocmeste documentul “proces verbal de procesare” in baza caruia combinatul factureaza catre Interagro serviciile de procesare. Documentul contine urmatoarele date:
valoarea costurilor de procesare pentru fiecare produs (finite si semifabricate) in functie de cantitatea realizata si a tarifelor stabilite prin contract
consumul de energie electrica(SEN+productie proprie) si gaze naturale pentru fiecare produs
consumul de semifabricate pentru produse finite
in functie de pretul diferit de productie/achizitie al semifabricatelor se urmaresc detaliat produsele finite dupa:
semifabricat stocat
semifabricat produs in luna curenta
semifabricat achizitionat de la unitatile din grup
cantitatile totale livrate (intern/extern) pentru fiecare produs
Raportarea datelor operationale se face zilnic in baza unui document standardizat la nivelul diviziei chimice ce contine urmatoarele date:
productia realizata (zilnic si cumulat pe luna in curs)
stocurile pentru produse finite si semifabricate
consumul de energie electrica (SEN+productie proprie), gaze naturale si produse semifabricate
cantitatile livrate (zilnic si cumulat pe luna in curs) intern si extern pe tip de transport (feroviar/auto/fluvial)
EURO TSA este proprietarul marfurilor produse, in baza contractelor de procesare, si gestioneaza toate comenzile de productie si contractele de vanzare, combinatele asigurand serviciile de livrare.
Divizia agricultura
Divizia agricultura are doua domenii de activitate ce se desfasoara in cadrul a sapte societati comerciale: productia vegetala si conditionarea si depozitarea cerealelor:
EURO TSA – Bucuresti
Intercereal SA Fetesti
Cerealcom SA Teleorman
Interagro SRL
Comcereal SA Prahova
Intercereal SRL Zimnicea
Cerealcom SA Bacau
Divizia agricultura are urmatoarea structura de organizare:
5 puncte de lucru ale EURO TSA cu activitati de productie vegetala:
Punct de lucru Alexandria
Punct de lucru Rosiori de Vede
Punct de lucru Ploiesti
Punct de lucru Dragos Voda
Punct de lucru Perisoru
4 ferme ale EURO TSA cu activitati de productie vegetala – servicii externalizate la alte doua societati din grup
Arenda Traianu
Concesiunea Legumicola
Concesiunea Zimnicele
Concesiunea Piatra
3 societati comerciale cu activitati de productie vegetala si conditionare depozitare cereale:
Intercereal Fetesti SA
productie vegetala
3 locatii de depozitare
Siloz Movila
Siloz Fetesti
Siloz Carpinis (Timis)
Cerealcom SA Teleorman
productie vegetala
productie vegetala – prestari servicii pentru Interagro SA
Arenda Traianu
13 locatii de depozitare
Siloz Alexandria
Siloz Olteni
Siloz Rosiori de Vede
Siloz Videle
Siloz Port Turnu Magurele
Siloz Port Zimnicea
Depozit Tiganesti
Depozit Slavesti
Depozit Necsesti
Depozit Silistea
Depozit Ciolpani
Depozit Balta Sarata
Depozit Suhaia
Interagro SRL Zimnicea
productie vegetala
productie vegetala – prestari servicii pentru Interagro SA
Concesiunea Legumicola
Concesiunea Zimnicele
Concesiunea Piatra
3 societati comerciale cu activitati de conditionare depozitare cereale:
Comcereal SA Prahova
10 locatii de depozitare
Baza de receptie cereale Crivina
Baza de receptie cereale Ciorani
Baza de receptie cereale Floresti
Baza de receptie cereale Mizil
Baza de receptie cereale Inotesti
Baza de receptie cereale Zanoaga
Siloz Ploiesti
Depozit R.S. Floresti Gara
Depozitul R.S. Gageni
Depozitul R.S. Targusorul Nou
Cerealcom SA Bacau
1 locatie de depozitare
Siloz Bacau
Intercereal SRL Zimincea
1 locatie de depozitare
Siloz Intercereal Zimincea
Punctul de lucru Alexandria gestioneaza achizitia centralizata a pieselor de schimb pentru utilajele agricole depozitarea si distributia acestora catre ferme.
Intercereal S.A Fetesti gestioneaza achizitia centralizata a pesticidelor si distributia acestora catre ferme.
Societatile ce presteaza servicii de depozitare pentru Interagro SA primesc, prin compensare, ingrasaminte chimice folosite pentru productia vegetala proprie si vandute clientilor interni din zonele locatiilor de depozitare.
Obiectivele si aria de cuprindere a proiectului
Obiective generale
Implementarea acestui proiect urmareste urmatoarele obiective generale:
consolidarea informatiilor din sistemul informatic la nivel de sediu central si furnizarea unei surse unice de informatii pentru asistarea deciziilor;
asigurarea unei baze de raportare si analiza multidimensionala a datelor;
controlul riguros al activitatilor financiare, de productie, stocare si desfacere;
centralizarea si urmarirea documentelor de productie de la lansarea tehnologica si antecalcul, urmarirea productiei, pana la evaluarea unitara a costurilor prin postcalcul;
eficientizarea proceselor legate de aprovizionarea, desfacerea si gestionarea stocurilor in scopul generarii unor decizii corecte de achizitie si minimizarii costurilor de stocare si regie;
controlul riguros al costurilor si cheltuielilor la nivel de produs, centru de cost, profit sau proiect, si analiza profitabilitatii pe produs, centru de profit sau alte criterii ale afacerii;
inregistrarea datelor privind activitatile de planificare si urmarire a reparatiilor si mentenantei instalatiilor si alocarea cheltuielilor pe centre de cost;
interfatarea sistemului cu intrumentele de masurare a productiei realizate, a consumului de semifabricate si cantarire a produselor livrate pentru inregistrarea automata a datelor;
Proiectul se va implementa in patru etape:
proiect pilot divizia produse chimie
la nivelul societatilor Donau Chem si Interagro S.A
in cazul Interagro S.A implementarea se va face doar la sediul central fara extindere la punctele de lucru
proiect pilot divizia agricultura
la nivelul punctelor de lucru Interagro SA
proiect rollout divizia produse chimie
proiect rollout divizia agricultura
Aria de cuprindere
Societatile grupului Interagro la nivelul carora se doreste implementarea sistemului informatic sunt prezentate in tabelul de mai jos:
Urmatoarele arii functionale vor fi acoperite de implementarea sistemului informatic:
– implementarea modulelelor standard ale unei solutii de tip ERP ( contabilitatea financiara si de gestiune, mijloace fixe, gestiune stocuri, achizitii si vanzari)
– implementarea unui modul de gestiune a activitatilor de productie chimica
– implementarea unui modul de gestiune a contractelor de arenda, activitatilor de productie vegetala si conditionare-depozitare
– implementarea unui modul de gestiune a activitatilor de mentenanta a echipamentelor si instalatiilor
– implementarea unui modul de gestiune a flotei auto
Pentru fiecare organizatie vor fi implementate urmatoarele functionalitati:
Codificarea functionalitatilor:
FI Financiar
MA Managementul achizitiilor
GS Gestiune stocuri
VZ Vanzari
TR Gestiune flota auto
PC Productie chimica
MN Mentenanta
MP Managementul proiectelor
CA Contracte de arenda
PV Productie vegetala
CD Conditionare-depozitare
Cerintele sistemului
Cerinte generale
Sistemul trebuie sa fie integrat, transferurile de date sa se faca in mod automat si transparent pentru utilizator, sa permita trasabilitatea datelor introduse si unicitatea acestora.
Sistemul trebuie sa respecte legislatia romaneasca si recomandarile Ministerului de Finante pentru aplicatiile informatice.
Sistemul trebuie sa permita interfatarea cu alte echipamente de masura digitale (cantare, debitmetre, analizoare) pe baza protocoalelor de comunicatie standard deschise.
Sistemul informatic si structurile bazei de date trebuie sa asigure:
– redundanta minima a informatiilor, transformarea datelor analitice in date sintetice si accesul rapid la informatie. Informatia primara trebuie sa fie introdusa o singura data.
– multivaluta: sa permita tranzactii in orice valuta si sa asigure posibilitatea reflectarii fenomenelor economice si a rapoartelor (registre contabile, rapoarte de baza, rezultate interogari etc) in valuta de baza (lei) si intr-o valuta de referinta(euro, usd), pentru evidentierea influentei inflatiei.
Cerinte arhitecturale
Sistem la cheie
Solutia ofertata trebuie sa fie de tip COTS (Commercial Off The Shelf), modulare si integrate. Solutia trebuie sa aduca valoare adaugata grupului de firme prin cele mai bune practici specializate si dedicate proceselor economise.
Sistemul informatic si structurile bazei de date trebuie sa asigure:
– redundanta minima a informatiilor, transformarea datelor analitice in date sintetice si accesul rapid la informatie. Informatia primara trebuie sa fie introdusa o singura data.
– multivaluta: sa permita tranzactii in orice valuta si sa asigure posibilitatea reflectarii fenomenelor economice si a rapoartelor (registre contabile, rapoarte de baza, rezultate interogari etc) in valuta de baza (lei) si intr-o valuta de referinta(euro, usd), pentru evidentierea influentei inflatiei.
Cerinte arhitecturale
Sistem la cheie
Solutia ofertata trebuie sa fie de tip COTS (Commercial Off The Shelf), modulare si integrate. Solutia trebuie sa aduca valoare adaugata grupului de firme prin cele mai bune practici specializate si dedicate proceselor economice specifice ale Interagro.
Implementatorul sistemului va oferi un sistem complet functional, incluzand toate componentele hardware si software necesare, manualele si procedurile de operare si instalare, precum si orice produs rezultat (fisiere de configurare, scripturi de instalare etc) cu ocazia dezvoltarii si implementarii sistemului.
Sistemul implementat trebuie sa fie scalabil tranzactional si functional. Arhitectura si modularitatea sistemului trebuie sa asigure evolutia functionala astfel incat sistemul sa poata fi extins cu aplicatii modulare, integrate, consacrate si disponibile COTS.
Solutia propusa trebuie sa acopere intreaga stiva tehnologica (atat baza de date, cat si serverul de aplicatii), suita integrata, cu componenta de management inclusa, mecanisme de audit si platforma de dezvoltare si configurare.
Sistemul informatic trebuie sa fie la ultima versiune lansata pe piata interna si internationala, sa permita utilizarea in limba romana si sa corespunda legislatiei romane in vigoare.
Sistemul va fi dezvoltat plecand de la produse comerciale (COTS). Aceste produse vor fi folosite in masura maxima posibila, iar dezvoltarea de componente proprietare va fi minimizata.
Ofertantii vor descrie componentele bazate pe produse comerciale si componentele care vor fi dezvoltate.
Conformitate cu principiul ACID (Atomicity, Consistency, Isolation, Durability)
Un sistem informatic este conform cu principiul ACID daca tranzactiile acestuia sunt atomice, consistente, izolate si durabile. Principiul ACID trebuie sa se aplice atat tranzactiilor SQL de la nivelul bazei de date cat si la nivelul aplicatiei.
Atomicitate
Tranzactiile sistemului trebuie sa fie atomice in sensul ca modificarile respecta regula “totul sau nimic”. Astfel se spune ca fiecare tranzactie este “atomica”. Daca o parte a tranzactiei nu se poate termina cu succes atunci intreaga tranzactie trebuie sa poate face roll-back. O tranzactie “atomica” nu poate fi divizata in sub-componente. Astfel sistemul informatic si nu utilizatorii trebuie sa gestioneze efectele unei tranzactii incomplete. O tranzactie poate sa nu se finalizeze cu succes din diverse motive cum ar fi:
Erori hardware (defectare de server, HDD etc.)
Erori de sistem (utilizatorii sunt deconectati de la aplicatie din motive de acces limitat la retea)
Erori de baza de date (baza de date nu mai are suficient spatiu pe HDD)
Erori de aplicatie (aplicatia ar incerca sa introduca o valoare pentru o cheie care exista deja la nivelul unei tabele)
Consistenta
Aceasta proprietate a sistemului informatic se refera la faptul ca sistemul ramane intr-o stare consistenta de la o tranzactie la alta, oricare ar fi aceasta. Aceasta proprietate se refera cu precadere la validitatea tuturor datelor ce sunt introduce in sistem prin intermediul aplicatiei. Sistemul informatic trebuie sa aiba validari cu privire la tipul si natura datelor si sa implementeze mecanisme de protectie atat la nivelul bazei de date cat si la nivelul aplicatiei.
Izolare
Aceasta proprietate a sistemului informatic se refera la capacitatea sa de a garanta ca datele implicate intr-o tranzactie in desfasurare sa nu poata fii modificate de alte operatii.
Durabilitate
Aceasta proprietate a sistemului informatic garanteaza ca odata ce utilizatorul a fost anuntat ca tranzactia sa s-a finalizat cu success datele salvate sunt protejate si pot fi recuperate chiar si in cazul unei defectiuni a sistemului.
Structura centralizata, pe 3 niveluri
Sistemul va fi centralizat, instalat la sediul din Bucuresti si accesibil utilizatorilor din tara prin intermediul infrastructurii de comunicatii.
Structura sistemului informatic trebuie organizata pe trei niveluri:
– Baza de date
– Server de aplicatie
– Aplicatie client
Mediile de lucru ale sistemului
Implementarea sistemului informatic trebuie sa aiba la baza o arhitectura compusa din minim trei medii de lucru. Functiile acestor medii sunt:
– Productie: pe acest server vor rula aplicatiile de productie ale sistemului
– Dezvoltare: pe acest server consultantii efectueaza configurari
– Asigurarea calitatii si instruire: pe acest server sunt testate si validate configurarile iar utilizatorii efectueaza intruirea. Pentru asigurarea calitatii, in acest mediu va fi instalata o solutie de testare a aplicatiilor dezvoltate, atat din punct de vedere functional cat si al performantei.
Securitatea sistemului
Solutia propusa trebuie sa aiba incluse mecanisme de securitate, capabilitati de gestiune a identitatii incluse in platforma tehnologica. Sistemul intergrat trebuie sa fie construit pe o platforma care sa nu permita accesul nesecurizat la informatii. Administrarea sistemului si a bazei de date trebuie sa posede instrumente puternice pentru asigurarea protectiei si confidentialitatii datelor, bazate pe un sistem consistent de profile si autorizatii de acces.
Gestiunea solutiei oferite
Sistemul trebuie sa puna la dispozitie instrumente analitice standard, indicatori de performanta predefiniti, raportari operationale pentru monitorizarea proactiva a sistemului.
Baza de date a sistemului informatic integrat trebuie sa permita urmatoarele facilitati:
– salvarea/restaurarea si arhivarea/dezarhivarea datelor in regim de lucru online
– salvarea totala si/sau partiala a bazei de date
– efectuarea de backup automat intr-o forma unitara, centralizata si usor de administrat
– rapoarte locale si consolidate asupra intregului mediu de backup cat si a operatiunilor de backup
– inregistrarea tuturor modificarilor bazei de date pentru a permite recuperarea bazei de date (inregistrarea tranzactiilor)
– recuperarea totala si/sau partiala a bazei de date de la un moment de timp specificat de utilizator
Arhitectura tehnica a sistemului
Mediul de productie
In mediul de productie aplicatia ERP va fi instalata pe doua servere. Cele doua servere vor fi plasate intr-o configuratie de inalta disponibilitate de tipul activ-activ sau activ-pasiv.
Datele aplicatiei ERP vor fi stocate intr-o baza de date centralizata ce va rezida pe doua servere. Pentru asigurarea disponibilitatii datelor, cele doua servere vor fi plasate intr-un cluster activ-activ. Datele aplicatiei vor fi stocate pe un echipament extern de stocare, care va include capabilitati de redundanta suficiente pentru a proteja informatiile in mod corespunzator.
Mediul de dezvoltare
In mediul de dezvoltare se va realiza dezvoltarea sistemului, precum si a oricaror modificari ce vor interveni dupa darea in folosinta a acestuia. Aplicatia si baza de date vor fi plasate pe acelasi server.
Mediul de asigurare a calitatii
In mediul de asigurare a calitatii se va realiza testarea aplicatiilor dezvoltatate, atat din punct de vedere functional cat si al performantei.
Cerinte functionale
Financiar
Contabilitate generala
CG1. Folosirea planului de conturi astfel incat acesta sa raspunda specificului companiei, asigurand o imagine completa a situatiei financiare a acesteia.
CG2. Sistemul informatic integrat trebuie sa raspunda mai multor raportari financiare in paralel in conformitate cu standardele romanesti de contabilitate (RAS) si cu standardele de contabilitate internationale (IAS, GAAP).
CG3. Sa nu conditioneze prelucrarea informatiilor dintr-o perioada de finalizare a lucrarilor intr-o alta perioada.
CG4. Sistemul sa permita adaugarea de documente auxiliare prin diverse note contabile.
CG5. Sa asigure posibilitatea reflectarii fenomenelor economice si a rapoartelor in valute diferite: una de BAZA (LEU) si alta de REFERINTA ($, Euro, etc).
CG6. Sistemul sa permita consolidarea conturilor in vederea intocmirii situatiilor financiare consolidate aferente reglementarilor legale in vigoare.
CG7. Sistemul sa fie complet configurabil:
sa contina un plan de conturi general care sa poata fi ulterior dezvoltat;
definirea si intretinerea planului de conturi al institutiei si posibilitatea de a dezvolta conturi sintetice de gradul 1 si 2, precum si conturi analitice ;
sa permita o monografie completa a oricarei tranzactii;
contabilitatea tranzactiilor sa fie propusa/executata de catre sistem pe baza monografiilor intocmite (contare implicita/automata);
activitatea sa se desfasoare pe baza unei multimi de variabile de setare, stabilite de catre administrator, dand astfel posibilitatea alegerii unei metode de organizare si conducere;
CG8. Sa permita obtinerea registrelor contabile obligatorii.
CG9. Sa realizeze toate rapoartele financiare impuse de legislatia si practica romaneasca: fisa cont sintetica si analitica, cartea mare, balanta de verificare sintetica si analitica,registrul jurnal, jurnale TVA, bilant, contul de profit si pierdere, cash- flow, notele la bilant, etc.
CG10. Posibilitatea contabilizarii automate a tuturor operatiunilor contabile in baza unor sabloane definite de utilizator.
CG11. Operatii de inchidere: pregatirea si executarea tuturor procedurilor care sunt necesare pentru:
inchiderea unei zile;
inchiderea unei luni;
inchiderea unui an;
CG12. Posibilitatea inregistrarii tuturor operatiunilor atat in lei cat si intr-o valuta de conversie (USD, EUR).
CG13. Sistemul trebuie sa permita introducerea si auditarea starilor unui document:
– pregatirea documentului;
– listarea (optional);
– validarea documentului din punct de vedere tehnic-operativ;
– modificarea, daca este cazul, a inregistrarilor contabile propuse de sistem;
– validarea din punct de vedere contabil;
CG14. Sistemul trebuie sa permita reevaluarea la sfarsit de an a soldurilor conturilor gestionate in valuta.
CG15. Sistemul trebuie sa permita inchiderea automata pentru TVA, venituri si cheltuieli.
CG16. Sistemul trebuie sa permita inchiderea perioadei contabile, recalcul/corectie/simulare.
CG17. Obtinerea situatiilor contabile – in special pentru conturile de venituri si cheltuieli pe locatie, sucursala sau pe toata compania.
CG18. Stabilirea de campuri obigatorii de completat la inregistrarea notelor contabile.
CG19. Sistemul trebuie sa permita exportul fisierelor (bilant, Declaratia 394, Declaratia 390) in formatul stabilit de Ministerul de Finante.
CG20. Sistemul trebuie sa intocmeasca toate formularele de rapoarte contabile prevazute de reglementarile legale in vigoare.
Contabilitatea furnizorilor si a platilor
CF1. Sa permita ca un furnizor sa aiba mai multe adrese.
CF2. Sa permita ca un furnizor sa fie in acelasi timp client.
CF3. Sa asigure introducerea si gestionarea in sistem a facturilor de la furnizori. Vor fi gestionate diversele tipuri de facturi: facturi standard, facturi de avans,facturi investitii, facturi imobilizari ,facturi leasing, facturi taxare inversa (in tara si intracomunitare), note de debit si credit.
CF4. Contabilitatea Furnizorilor trebuie sa asigure functiuni si facilitati pentru gestionarea facturilor de la furnizori si controlul riguros al platilor, intelegand prin aceasta: verificarea si aprobarea facturilor pentru plata, sau blocarea lor, emiterea (sau inregistrarea) documentelor de plata, efectuarea platilor la termenele scadente, valorificarea discountului acordat de furnizor, prevenirea platilor duble, prevenirea inregistrarii duble a facturilor, prognoza necesarului de lichiditati.
CF5. Este necesar un mecanism prin care sa se introduca lunar conform contractului tranzactiile pentru leasing (masini, echipamente, etc), cu calculul diferentelor de curs.
CF6. Intocmirea, gestionarea si urmarirea clara a deconturilor de justificare de avansuri si a ordinelor de deplasare pe fiecare salariat. Sistemul sa cuprinda un nomenclator cu toti salariatii.
CF7. Posibilitatea intocmirii diverselor rapoarte cu privire la avansurile primite ( salariat, perioade de timp, sold initial, rulaje si sold final pe fiecare salariat).
CF8. Tranzactiile aprobate vor fi transferate automat in Contabilitatea Generala, preluate de aceasta si inregistrate in conturile din planul de conturi.
CF9. Sistemul va asigura controlul termenelor de plata la nivele diferite, incluzand nivelul articolului din catalogul de furnizori.
CF10. Sistemul trebuie sa permita definirea si gestionarea termenelor de plata.
CF11. Conturile care participa la tranzactii vor fi predefinite in cadrul configurarii sistemului si vor aparea automat pe documente.
CF12. Factura de la furnizor poate incarca contul de stoc, sau de cheltuieli; este important ca sumele din liniile facturii sa fie distribuite in conturile corespunzatoare.
CF13. In privinta facturilor in moneda straina, se va retine valoarea in moneda respectiva si suma convertita in lei (moneda functionala), dupa rata de schimb dorita (a institutiei, sau a utilizatorului, sau oficiala). Tranzactionarea in diverse valute pastrand ca moneda de baza a tranzactiei moneda RON. In cazul platilor in avans in moneda straina, sa permita calculul diferentelor de curs.
CF14. Generarea automata a inregistrarilor contabile in cazul : TVA-ului si a diferentelor de curs.
CF15. Analizarea facturilor pe scadente, posibilitatea modificarii intervalelor stabilite pentru afisarea scadentelor.
CF16. Sistemul va permite corectarea, sau stornarea facturilor, sau liniilor de factura.
CF17. Blocarile de la plata ale facturilor vor putea fi anulate de utilizator, cu conditia ca acesta sa aiba autorizarea necesara.
CF18. Inregistrari manuale sau automate plati. Platile se pot efectua in moduri diferite: prin cecuri, ordine de plata, etc.; plata poate fi manuala (de exemplu: cec-urile se scriu manual si doar se inregistreaza in sistem), sau automata – de exemplu: cec-urile se genereaza automat si se tiparesc de sistem. In ultimul caz, este necesara o evidenta riguroasa a cec-urilor emise.
CF19. Sistemul trebuie sa nu aiba limitari in privinta numarului de banci si conturi bancare.
CF20. Metodele de plata, discount-ul, data de referinta pentru plata, eventuale dobanzi la intarzierea platilor sunt parametri care se stabilesc la nivelul sistemului si al furnizorilor.
CF21. O plata sa se poata referi la una sau mai multe facturi.
CF22. O plata sa poata fi partiala sau totala.
CF23. Daca pentru un furnizor s-au efectuat plati in avans, la plata unei facturi catre acel furnizor, sistemul va atentiona existenta platilor in avans pentru furnizorul respectiv.
CF24. Pe o factura platita sa nu se mai poata aplica alte plati.
CF25. Sistemul va prevedea un mod de urmarire riguroasa a cec-urilor, inregistrand cec-urile -numar, data, suma, factura la care se refera si starea cecului- daca este in asteptare, trimis, sau anulat.
CF26. Periodic, la nivelul unei luni, sistemul va realiza inchiderea perioadei si transferul tranzactiilor in Jurnale din Contabilitatea generala pentru a fi inregistrate in conturile din Cartea mare. Anterior transferului, sistemul ofera instrumente de auditare a informatiei stocate, on-line si prin rularea unor rapoarte. Sistemul sa ofere posibilitatea modificarii datelor intr-o perioada anterioara inchisa.
CF27. Transferul in Contabilitatea generala se va realiza la diferite niveluri de detaliere – de detaliu (nivelul audit complet), nivelul facturii (audit partial), sau la nivelul sumelor pe conturi.
CF28. Sistemul va asigura un acces rapid on-line la facturile pe care utilizatorul doreste sa le vizualizeze, inclusiv documentele in legatura cu acestea cum ar fi comenzile, platile, platile in avans, etc. Selectia se va face prin furnizor, interval calendaristic, starea facturilor.
CF29. Sistemul va oferi rapoartele legale si rapoarte care sa permita auditul proceselor din contabilitatea platilor:
– Registrul de facturi
– Registrul de plati
– Evidenta platilor in avans
– Registrul de cec-uri
– Lista facturilor in ordinea vechimii
– Necesarul de numerar
– Diferente nerealizate de schimb valutar
– Fise de cont
CF30. Sistemul va permite reconcilierea platilor cu extrasele de cont bancar
CF31.Sistemul va permite obtinerea automata a Registrului de casa
CF32. Sa permita listarea scrisorilor de confirmare sold ale furnizorilor la o anumita data
CF33. Sistemul va permite prognoza necesarului de lichiditati.
CF34. Sa permita inregistrarea operatiunilor de compensare (inclusiv situatia cand furnizorul este si client)
Contabilitatea clientilor si a incasarilor
CC1. Sa permita mai multe locatii si adrese ale clientului;
CC2.Sa permita fuzionarea clientilor definiti multiplu;
CC3. Sa asigure posibilitatea de a efectua diferite tipuri de tranzactii: facturi, incasari, note de debit si note de credit, incasari in avans;
CC4. Sa permita inregistrarea tranzactiilor in perioada curenta, chiar daca perioada anterioara nu a fost inchisa;
CC5. Sa permita inregistrari de tranzactii in perioade trecute si urmatoare;
CC6. Sa poata crea facturi recurente pentru tranzactii care se repeta;
CC7. Sa genereze un numar unic pentru fiecare document creat sau introdus in sistem, cu posibilitatea ca utilizatorul sa defineasca propriile intervale de numere pentru diversele tipuri de documente;
CC8. Sa poata anula, storna facturi;
CC9. Sa introduca facturi in alte valute, sa converteasca valoarea in lei (moneda functionala) la cursul predefinit in sistem si sa salveze informatia in ambele monede;
CC10. Sa predefineasca conturile pentru clienti, taxe etc astfel incat sa apara automat la introducerea unei facturi;
CC11. Incasarea sa poata fi aplicata unei facturi, sau unei linii a facturii;
CC12. Sa permita incasari partiale ale unei facturi;
CC13. Sa inregistreze incasarile fara factura corespondenta intr-un cont rezervat pentru actiuni in asteptare;
CC14. La incasarea facturilor, sa ia in consideratie incasarile in avans, sau depozitul clientului;
CC15. Sa permita reconcilierea platilor cu extrasul de cont bancar;
CC16. Sa asigure accesul on-line la intreaga informatie stocata, informatia despre clienti, facturi, incasari prin selectii dupa criterii multiple, cum ar fi:
client
perioada
starea facturii
CC17. Sistemul trebuie sa asigure calculul automat de dobanzi/penalitati pentru scadente depasite, posibilitatea definirii perioadelor de gratie pentru anumiti clienti si emiterea facturii pentru aceste creante.
CC18. In cazul incasarilor in valuta, sistemul sa calculeze automat diferentele de curs.
CC19. Sa ofere cel putin urmatoarele rapoarte:
Registrul de tranzactii
Jurnal de vanzari pe conturi de carte mare
Registrul de incasari
Registrul de TVA din vanzari
Raportul de TVA incasat
Registrul de reconciliere TVA
Balanta de verificare
Raport de facturi neplatite dupa transe de perioade scadente, pe vechime
Fisa contului
Managementul Trezoreriei
MT1. Gestionarea conturilor de disponibilitati;
MT2. Sistemul va putea sa lucreze cu valute multiple;
MT3. Se va crea posibilitatea definirii principalelor trezorerii si conturi bancare cu care se lucreaza in mod curent (se vor putea defini conturile proprii precum si cele ale clientilor/furnizorilor);
MT4. Pentru conturile bancare vor fi gestionate: trezoreria, contul bancar, valuta contului, unitatea proprietara a contului bancar respectiv (client, furnizor sau firma proprietara);
MT5. Se va asigura preluarea electronica a extraselor bancare (prin multicash)
MT6. Se va crea posibilitatea de a indica (atasa) la operatia specifica trezoreriei, documentul de incasare/plata pe baza caruia se realizeaza operatia respectiva;
MT7. Functiunea va contine situatii de raportare, care vor sintetiza principalele operatii bancare efectuate intr-o anumita perioada, pe un anumit cont
MT8. Se va crea posibilitatea de a indica (atasa) la operatia specifica trezoreriei, documentul de incasare/plata pe baza caruia se realizeaza operatia respectiva;
MT9. Functiunea va contine situatii de raportare, care vor sintetiza principalele operatii bancare efectuate intr-o anumita perioada, pe un anumit cont;
MT10. Sistemul va permite urmarirea in permanenta a soldului pe fiecare cont bancar.
MT11. Inregistrarea incasarilor/platilor clienti/furnizori:
Posibilitatea de a se face operatii de compensare (la nivel de document sau la nivel de partener) intre doi sau mai multi parteneri de afaceri. Compensarea documentelor se va face prin incasarea/plata documentelor partial sau total.
Incasarile/platile sa se poata face la nivel de document primar gestionat in sistem sau la nivel de partener (fara specificarea documentului primar).
Sa existe posibilitatea de a se face incasari/plati in alta moneda decat in moneda documentului primar.
Sa existe posibilitatea inregistrarii zilnice a cursurilor valutare pentru valutele utilizate in operatiunile curente.
MT12. Incasarile/platile prin banca trebuie sa permita:
posibilitatea operarii pe conturi analitice
evidentierea soldurilor pe documentele de banca (extrase) conform cu operatiile zilnice prelucrate ; in cazul in care este nevoie sistemul sa permita modificarea soldurile initiale propuse pentru extrasul curent
specificarea numarului si a datei extrasului ce se inregistreaza
specificarea contului bancar pentru care se face inregistrarea extrasului respectiv
specificarea valutei
modificarea extraselor de cont anterioare
specificarea documentului pregatitor pentru incasare/plata (CEC, ordin de plata, etc)
specificarea partenerului pentru care se face inregistrarea respectiva
specificarea documentului primar la care se refera operatiunea inregistrata (daca operatia se refera la un document primar)
specificarea sumei aferente inregistrarii curente atat in valuta cat si cea convertita in lei (in cazul in care este referitoare la un document primar sa se poata face incasare/plata totala sau partiala)
afisarea informativa a soldului actual pe documentul primar pe care se face operatia respectiva
este de dorit ca pentru anumite tipuri de tranzactii sa se defineasca reguli de distributie a sumelor pe conturile contabile
posibilitatea ca pentru o tranzactie sa se poata specifica defalcarea sa pe mai multe perechi de conturi contabile
posibilitatea ca pentru inregistrarea unei pozitii de extras referitoare la un document primar sa se poata face operarea la nivel de pozitie din cadrul documentului,
specificarea centrului de cost pentru care se face inregistrarea (cand este cazul),
specificarea numar/data nota de banca (sau nota contabila) asociata inregistrarii respective
posibilitatea ca pentru operatiile in valuta se se poata inregistra automat diferentele de curs valutar; in cazul in care se doreste, aceste propuneri de diferente de curs sa se poata modifica
sa existe posibilitatea de a se face incasari/plati in alta moneda decat in moneda documentului primar
posibilitatea de a se introduce pozitii de extras, de incasare/plata, care sa nu afecteze soldul extrasului.
evidentierea tranzactiilor pe un anumit cont pe o perioada de timp specificata, atat detaliat cat si centralizat.
evidenta tuturor tranzactiilor pe zi, luna, detaliat si centralizator.
preluarea datelor privind activitatea de trezorerie in vederea intocmirii fluxului de numerar (Cash flow).
MT13. Inregistrarea incasarilor/platilor prin casierie va permite:
evidentierea soldurilor (initiale si finale) conform cu operatiile zilnice prelucrate, intocmirea registrului de casa in lei si in valuta
posibilitatea de a se defini mai multe casierii pentru care se fac inregistrarile; pentru fiecare dintre ele sa se poata defini la inceput, daca este cazul, soldul initial de casa
specificarea valutei si a cursului valutar
specificarea partenerului pentru care se face inregistrarea respectiva,
sa se poata face inregistrarea operatiilor specifice de casa la nivel de tip de partener (ex. Particular, Client, Furnizor, Salariat, Centru de Cost)
specificarea documentului primar la care se refera operatiunea inregistrata (daca operatia se refera la un document primar)
specificarea sumei aferente inregistrarii curente atat in valuta cat si cea convertita in lei (in cazul in care este referitoare la un document primar sa se poata face incasare/plata totala sau partiala)
afisarea informativa a soldului actual al documentului primar pentru care se face operatia respectiva
este de dorit ca pentru anumite tipuri de tranzactii sa se defineasca reguli de distributie a sumelor pe conturile contabile
posibilitatea ca pentru o tranzactie sa se poata specifica defalcarea sa pe mai multe perechi de conturi contabile
posibilitatea de a se specifica numarul chitantei de casa cu care s-a facut incasarea-plata
posibilitatea ca pentru inregistrarea unei pozitii de casa referitoare la un document primar sa se poata face operarea la nivel de pozitie din cadrul documentului
specificarea centrului de cost pentru care se face inregistrarea (cand este cazul)
specificarea numar/data nota contabila asociata inregistrarii respective
posibilitatea ca pentru operatiile in valuta sa se poata inregistra automat diferentele de curs valutar; in cazul in care se doreste, aceste propuneri de diferente de curs sa se poata modifica
posibilitatea inregistrarii si urmaririi operatiilor privind avansurile de decontare cu salariatii
sa existe posibilitatea de a se face incasari/plati in alta moneda decat in moneda documentului primar.
evidentierea tranzactiilor pe un anumit cont pe o perioada de timp specificata, atat detaliat cat si centralizat
evidenta tuturor tranzactiilor pe zi, luna, detaliat si centralizat.
MT14. Gestiunea si urmarirea avansurilor clienti/furnizori:
inregistrarea unui avans : numar avans, partener, valuta
adaugarea de documente ce constituie avans (ordin de plata, casa, extras),
posibilitatea de a se ‘stinge’ documente primare din avansul constituit (partial sau total document)
posibilitatea de a se modifica, sterge un document primar care a diminuat un avans
posibilitatea de a se inregistra din punct de vedere contabil operatia de ‘stingere’ a documentelor din avansuri.
MT15. Incasarile/platile prin compensare trebuie sa permita:
posibilitatea de a se realiza compensari in valute diferite
posibilitatea de a se realiza compensarea intre mai multi parteneri (nu numai firma proprietara cu clientul/furnizorul)
posibilitatea de se specifica documentele ce intra intr-o compensare
posibilitatea ca intr-o compensare sa intre nu numai documente ci si sume ce se refara la incasari/plati pentru partenerul respectiv
posibilitatea de a se inregistra automat in conturi compensarea efectuata
posibilitatea de a se evidentia in mod automat si eventualele diferente de curs rezultate din compensare
posibilitatea de a se realiza compensarea pe sume diferite (suma de incasari diferita de cea de plati), rezultatul putand fi urmarit prin intermediul documentelor de incasare-plata (de ex. Ordin de plata) sau avansurilor.
MT16. Sistemul trebuie sa permita urmatoarele rapoarte:
liste de rapoarte referitoare la tertele parti si obligatii cu defalcarea sumelor restante in functie de vechime (30, 60, 90, … zile),
balante analitice pentru un cont contabil care sa contina detaliat informatii privind : solduri initiale pe partener-valuta, rulaje curente, sold final (si componenta soldului)
listarea rapoartelor : Fisa Clienti si Fisa Furnizori (detaliat pe operatiile efective realizate si centralizat la nivel de client/furnizor), pe o perioada specificata
listarea de rapoarte specifice care vor permite urmarirea incasarilor de la clienti si a platilor catre furnizori, conform termenelor de incasare/plata scadente.
listarea documentelor de incasare/plata de la clienti/catre furnizori, cu legatura la documentele primare (daca acestea sunt gestionate in baza de date).
rapoarte speciale pentru urmarirea incasarii/platii documentelor, precum si a situatiei debitorilor/creditorilor.
datele primare, la nivel de clienti/furnizori, vor fi prelucrate si vor putea fi raportate sub forma unor situatii statistice, ce vor face obiectul analizelor in cadrul instrumentelor suport de decizie.
situatii privind operatiile realizate prin intermediul unui cont bancar
situatii privind operatiile efectuate pe o anumita nota contabila (defalcat si centralizat la nivel de grupe de conturi)
situatie cu incasarile pe unul sau mai multi clienti, zilnic/lunar.
Imobilizari corporale si necorporale
IM1. Modulul va trata contabilitatea mijloacelor fixe, asigurand atat functiuni financiare – valori, amortizari, tranzactii, cat si o gestiune fizica transparenta a acestora – inventarul fizic, amplasarea in spatiu.
IM2. Trebuie sa fie asigurata posibilitatea urmaririi evidentei mijloacelor fixe atat din punct de vedere economic cat si din punct de vedere fiscal( permitand urmarirea influientelor fiscale asupra rezultatelor companiei).
IM3. Trebuie sa fie asigurata posibilitatea urmaririi evidentei mijloacelor fixe (cladiri si mijloace de transport) in vederea intocmirii declaratiilor privind calculul impozitelor pentru Bugetul Local.
IM4. Trebuie sa fie asigurata posibilitatea urmaririi evidentei mijloacelor fixe gajate.
IM5. Contabilitatea mijloacelor fixe trebuie sa acopere intreaga viata a acestora, de la achiziție, punere in funcțiune si pana la retragerea acestora.
IM6. Contabilitatea mijloacelor fixe trebuie sa fie integrata cu componentele de management achiziții, stocuri, vanzari, intretinere si reparații, contabilitate de gestiune; inregistrarile aferente unui mijloc fix sa poata fi accesate in timp real din toate componentele menționate anterior.
IM7. Sa fie posibil sa se inregistreze elemente din componenta de gestiune a materialelor direct in componenta de mijloace fixe. Cand un mijloc fix este aprovizionat din exterior sau din producție proprie, sa se poate inregistra direct factura primita sau bunurile primite.
IM8. De asemenea, trebuie sa se poata transfera amortizarea si alte cheltuieli legate de mijloacele fixe in componentele de Contabilitate financiar-contabila si de gestiune interna.
IM9. Din componenta de gestiune a intreținerii echipamentelor trebuie sa se poata deconta activitațile de intretinere care sunt cerute de capitalizarea mijloacelor fixe.
IM10. Gestionarera informatiilor despre mijloacele fixe – nr. de inventar, locatie , cod de clasificare, durata de viata, reguli de amortizare;
IM11. Calcul amortizare- informatii lunare despre fiecare imobilizare;
IM12. Gestionarea documentelor privind tranzactiile de imobilizari – intrari, iesiri, transferuri, reevaluari, plusuri si minusuri la inventar, donatii, casari, modernizari;
IM13. Transferul datelor referitoare la tranzactiile efectuate catre modulul de contabilitate generala, alocand cheltuiala cu amortizarea pe centrul de cost corespunzator;
IM14. Sa se poata gestiona Registrul mijloacelor fixe, valorile de inventar, amortizarea, durata de viata, datele istorice;
IM15. Sa se poata controla tranzacțiile ocazionale efectuate asupra mijloacelor fixe: achiziții, postcapitalizari, transferuri, retrageri, reevaluari;
IM16. Sa ofere funcționalitați de definire si urmarire a componentelor unui mijloc fix pe baza numerelor seriale ale acestora.
IM17. Sa se poata controla tranzacțiile periodice – calculul si inregistrarea amortizarii mijloacelor fixe (cu cele doua metode in paralel: economica si fiscala), pe baza unor reguli predefinite de utilizator. Este preferabil sa se asigure posibilitatea mai multor moduri de calcul al amortizarii, ceea ce conduce la gestionare a mai multe valori in paralel pentru mijloacele fixe;
IM18. Sa asigure identificarea mijloacelor fixe, amplasarea in spațiu, apartenența la o gestiune si la un gestionar;
IM19. Soluția informatica sa ofere informații despre istoricul mișcarii mijlocului fix: data mișcarii, locația sursa/tinta, parintele sursa/tinta, comenzi/liste de lucru si costuri de mișcare
IM20. Sa controleze colectarea costurilor in perioada de construcție, grupa de M.F. de "Investiții In curs" si sa le aloce pe mijloacele fixe rezultate in urma lucrarilor de investiții efectuate pe baza de registru;
IM21. Sa ofere instrumente de vizualizare a istoricului de costuri ale locului/echipamentului dupa perioada fiscala
IM22.Sa fie ținuta evidenta obiectelor de inventar in folosința;
IM23. Sa transfere datele referitoare la tranzacțiile efectuate catre modulul de contabilitate generala;
IM24. Sa realizeze contabilitatea mijloace fixe (inclusiv amortizare legala si gestiune costuri legate de acesta);
IM25. Funcții de simulare (prognoza amortizarii si simulare a modificarilor valorilor de amortizare; prognoza va include amortizarea fondurilor fixe generate de investițiile curente si cele viitoare planificate)
IM26. Sa ofere funcționalitați pentru identificarea, prioritizarea si prognoza momentului in care mijloacele fixe vor necesita inlocuirea/innoirea
IM27. Se vor clasifica mijloacele fixe si se vor stabili durata de viata si regulile de amortizare in conformitate cu legislația in vigoare;
IM28. Sa asigure informații privind soldurile si rulajele lunare ale fiecarui cont pe fiecare cont analitic pe care este dezvoltat;
IM29. Sa asigure informatii privind tranzacții contabile care conțin si informații privind analiticele pe care se realizeaza tranzacția respectiva.
IM30. Sa asigure informatii privind mijloacele fixe gajate.
IM31. Sa asigure informatii privind mijloacele fixe (cladiri si mijloace de transport) supuse impozitelor si taxelor locale.
IM32. Sa ofere principalele rapoarte aferente modulului de Mijloace fixe:
– Note contabile mijloace fixe
– Centralizator mijloace fixe
– Centralizatoare tip productie
– Fisa mijlocului fix
– Inventar mijloace fixe pe locuri de consum
– Jurnal privind amortizarea
– Lista mijloace fixe propuse spre casare
– Lista de inventar
– Registrul mijloacelor fixe
– Lista mijloacelor fixe
– Balanța analitica cont
Contabilitatea de gestiune
GT1. Sistemul trebuie sa permita raportarea costurilor si veniturilor pe produse, pentru a se putea analiza profitabilitatea acestora, atat la nivelul intregii companii, cat si la nivelul fiecarei sucursale.
GT2. Contabilitatea interna trebuie sa fie in stransa legatura cu contabilitatea financiara, astfel incat tranzactiile din contabilitatea financiara relevante, ce presupun inregistrari pe conturi de profit si pierdere, sa fie transmise automat contabilitatii de gestiune. De asemenea, sistemul trebuie sa permita reconcilierea dintre contabilitatea financiara si cea interna.
GT3. Modulul de contabilitate de gestiune trebuie sa permita definirea obiectelor de cost (centre de cost, centre de profit) conform cu cerintele societatii, planificarea costurilor si veniturilor companiei, inregistrarea tuturor costurilor si veniturilor specifice activitatii desfasurate, respectiv obtinerea de rapoarte relevante, conform cu necesitatile exprimate.
GT4. Sistemul va permite gestiunea costurilor in trei monede (RON ,USD, EURO)
GT5. Pentru proiecte este necesara posibilitatea de a defini bugete si de a face analize ale costurilor efective versus cele bugetate.
GT6. Posibilitatea de definire de ierarhii de centre de cost/ profit.
GT7. Este necesar sa fie puse la dispozitie functionalitati specifice de verificare, control, corectie de inregistrari costuri la inchidere de perioada.
GT8. Sistemul trebuie sa permita generarea de scenarii de antecalcul pentru semifabricate, produse finite si servicii care sa cuprinda: materii prime si cheltuieli materiale, utilitati, costuri comune ale sectiilor, cheltuieli generale ale intreprinderii actualizate
Sistemul trebuie sa permita:
GT9. Structurarea detaliata a companiei pe centre de cost, din perspectiva organizationala si pe activitați (pe departamente, activitați direct productive (producție si furnizare), activitați de suport), astfel incat informațiile despre costuri sa fie obținute si analizate la aceste nivele;
GT10. Inregistrarea individuala si detaliata a costurilor directe cu producția, cu activitațile de reparații si restul activitaților de suport, prin comenzi de costuri cu posibilitatea de compensare cu centrele de cost beneficiare, sau cu produsul rezultat;
GT11. Inregistrari lunare, in contabilitatea centrelor de cost, a cheltuielilor ce corespund activitaților de baza, suplimentar inregistrarilor directe pe comenzile de cost;
GT12. Planificarea automata a elementelor de cost determinate automat de sistem (salarii, amortizare).
GT13. Funcționalitați specifice in managementul costurilor si ale generarii de management intern al costurilor, precum:
Inregistrarea volumului activitații prestate in cadrul companiei;
Transfer manual al costurilor;
Inregistrarea cifrelor statistice cheie;
Distribuții si alocari de costuri pe diverse obiecte de cost
3.3.1.7. Gestiunea bugetelor
Sistemul trebuie sa permita:
GB1. Planificarea si urmarirea valorilor bugetare la toate nivelele, de la bugetul general de venituri si cheltuieli la bugete locale pana la cea mai mica entitate organizatorica, asigurand concomitent posibilitatea de alocare si urmarire a bugetului pentru anumite activitati/proiecte.
GB2. Definirea bugetului si a structurii bugetare.
GB3. Definirea flexibila a indicatorilor care compun bugetul, intr-o structura care sa poata fi configurata dinamic.
GB4. Structurarea bugetului pe perioade de analiza definite de utilizator (luna, trimestru, semetru, an).
GB5. Controlul automat al disponibilitatii bugetului in momentul realizarii cheltuielii.
GB6. Gestionarea versiunilor si rectificarilor bugetare.
GB7. Interogarea bugetelor pe toate nivelele si intervalele de timp definite.
GB8. Modelarea bugetelor tinand seama de faptul ca unele proiecte depasesc un an fiscal.
GB9. Posibilitatea rezervarii sau blocarii fondurilor pentru o anumita activitate/proiect.
GB10. Raportarea rapida a bugetatului vs. realizatului, centralizat, dimensionat pe centre de analiza și articole de calculație.
Managementul achizitiilor
MA1. Modulul trebuie sa ofere suport pentru gestionarea contractelor si mecanisme de avertizare automate in cazul in care un contract urmeaza sa expire.
MA2. Pe contracte se vor preciza produsele si preturile, discount-uri, cheltuieli de transport, termene de livrare, conditii de livrare, conditii de plata.
MA3. Modulul trebuie sa permita atat intrarea bunurilor cu referinta la contractele existente cat si fara referinta la un contract (achizitii directe de valori mici).
MA4. In cazul intrarii bunurilor cu referinta la un contract existent, aplicatia va aduce din contract liniile respective cu toate datele aferente, solicitand operatorului numai confirmarea cantitatii receptionate.
MA5. Sistemul va permite tiparirea notei de intrare-receptie (NIR) in formatul specificat de lege.
MA6. Modulul trebuie sa verifice automat daca prin insumarea pozitiilor facturii si a taxelor se obtine valoarea totala a facturii. Va verifica si daca taxele sunt introduse corect. In caz de erori va avertiza operatorul.
MA7. Sistemul va permite blocarea la plata a unor facturi sau a unor furnizori.
MA8. Modulul trebuie sa permita planificarea si gestionarea programului anual de achizitii de produse/ servicii/ lucrari.
MA9. Modulul va usura urmarirea derularii contractelor si va permite inregistrarea tuturor miscarilor de materiale atat in interiorul companiei cat si catre / dinspre terti.
MA10. Modulul trebuie sa permita definirea in sistem a tuturor tipurilor de documente de aprovizionare necesare desfasurarii proceselor specifice:
• Referate de necesitate;
• Cereri de oferta;
• Oferte;
• Comenzi de aprovizionare (simple sau cu referinta la contracte);
• Contracte;
• Grafice de livrare (generale pe perioade mai lungi sau detaliate pentru perioade scurte);
MA11. Posibilitatea definirii unui flux de aprobare pentru orice document de aprovizionare.
MA12. Posibilitatea utilizarii altor monede in afara celei de referinta in raport cu fiecare furnizor.
MA13. Posibilitatea definirii unor parametrii specifici pentru fiecare material in relatia cu un anumit furnizor:
• Termeni de livrare;
• Taxe;
• Conditii de pret specifice cu posibilitatea definirii acestora pe anumite perioade de timp;
• Conditii de livrare;
• Posibilitatea definirii de preturi diferite in functie de unitati de masura diferite;
• Limite de sublivrare sau supralivrare specifice furnizorului;
• Cantitati minime de livrare;
• Durate minime pana la expirarea produsului;
• Producator preferat in cazul unor intermediari.
MA14. Definirea furnizorilor agreati pentru orice produs achizitionat.
MA15. Definirea de conditii speciale de pret si evidentierea separata a acestora in documente pentru taxe, discount-uri, cheltuieli de transport, vama, etc..
MA16. Posibilitatea existentei unui istoric al preturilor in relatia cu furnizorii.
MA17. Posibilitatea definirii unor adrese de livrare diferite;
MA18. Posibilitatea definirii in documentele de aprovizionare a tipului de aprovizionare (standard, in custodie, subcontractare, livrare catre o terta parte).
MA19. Posibilitatea tiparirii in formatul dorit a documentelor trimise furnizorilor.
MA20. Posibilitatea identificarii si procesarii tuturor referatelor de necesitate alocate unui furnizor in momentul introducerii unei comenzi de aprovizionare catre acesta.
MA21. Posibilitatea generarii automate a comenzilor pe baza referatelor de necesitate aprobate si care au furnizor cunoscut, in conditii determinate.
MA22. Posibilitatea verificarii on-line din documentele de aprovizionare a situatiei stocurilor de materiale existente, precum si a tuturor cerintelor existente la momentul respectiv si a stadiilor in care se afla acestea.
MA23. Posibilitatea evaluarii automate a furnizorilor in functie de pret, calitatea produselor, respectarea termenelor de livrare si a cantitatilor specificate.
MA24. Sistemul trebuie sa permita anularea documentelor de aprovizionare numai in cazul in care nu exista documente ulterioare create cu referinta la ele.
MA25. Pentru materiale necesare activitatii ce trebuie aprovizionate in mod curent, sistemul trebuie sa permita urmatoarele functionalitati:
• Determinarea automata a necesarului de aprovizionare in cazul materialelor pentru care exista posibilitatea stabilirii unor nivele de stoc. Sistemul trebuie sa determine necesarul pe baza nivelului minim si maxim al stocurilor, al stocului de siguranta si al timpului planificat de livrare. De asemenea, trebuie sa tina cont de posibilele rotunjiri necesare ale cantitatilor de aprovizionat;
• Crearea automata de referate de necesitate in cazul celorlalte materiale, pe baza unor rezervari introduse in sistem;
• Generarea unui centralizator al disponibilitatii materialelor, care sa cuprinda situatia acestora in functie de consumul istoric mediu si de documentele de aprovizionare existente (acoperire de stoc);
Gestiunea stocurilor
In aria de gestiune a stocurilor, sistemul trebuie sa raspunda, in principal, urmatoarelor cerinte:
GS1. Posibilitatea introducerii in timp real a tuturor miscarilor de material si recalcularea automata a stocurilor rezultate in urma acestor miscari.
GS2. Crearea automata a unor documente financiar-contabile corespunzatoare si, eventual, a unor documente de costuri in modulul de gestiune a costurilor.
GS3. Modulul trebuie sa permita operarea tuturor miscarilor de stocuri necesare functionarii unei companii: intrari, iesiri, transferuri, casari, diferente de inventar; stornari, etc. Aplicatia va permite tiparirea documentelor aferente miscarilor de stocuri in forma solicitata prin lege.
GS4. Sistemul va permite inregistrarea tuturor miscarilor de materiale atat in interiorul companiei cat si catre / dinspre terti.
GS5. Modulul va permite gestionarea unei game complete de materii prime, piese de schimb, materiale consumabile, marfuri, obiecte de inventar, etc. Totodata, modulul/aplicatia va permite gestionarea materialelor aflate in stoc in magazii cat si a celor in tranzit sau in custodie.
GS6. Descarcarea stocurilor se va face prin una din metodele prevazute de reglementarile contabile (FIFO, LIFO….) la alegerea utilizatorului . Pentru stocurile care vor deveni obiecte de inventar sau mijloace fixe valoarea stocului trebuie descarcata cu metoda FIFO, la nivel de sucursala.
GS7. Modulul trebuie sa permita gestiunea stocurilor, stoc de siguranta, avertizari ca stocurile au scazut sub un minim, operatii de completare stoc (replenishment). Este necesar ca operatiile de aprovizionare sa decurga cit se poate de repede pentru a nu se intirzia operatiunile viitoare din cauza lipsei stocului necesar.
GS8. Posibilitatea verificarii on-line din documentele de aprovizionare a situatiei stocurilor de materiale existente, precum si a tuturor cerintelor existente la momentul respectiv si a stadiilor in care se afla acestea.
GS9. Modulul va permite operatii de inventariere, de inregistrare a diferentelor cantitative rezultate in urma inventarului dar numai dupa o etapa de analiza si eventual corectie a diferentei. Inventarierea se face pentru o data anterioara, inregistrarea diferentelor trebuie facuta retroactiv, pentru acea data.
GS10. Modulul va integra cat mai bine partea logistica cu partea financiara prin generarea automata, imediata, de note contabile aferente operatiunilor logistice inregistrate (acolo unde e cazul).
GS11. Pentru fiecare material se vor defini cel putin urmatoarele informatii:
• Unitatile de masura, formulele de transformare dintr-o unitate de masura in alta
• Dimensiunile, volumul, greutatea
• Conditiile de depozitare
• Conturile (care apar implicit in tranzactii dar pot fi modificate de operator inainte de salvarea tranzactiei) de material si de cheltuieli pentru materialul respectiv (pentru inregistrarea automata a notelor contabile aferente miscarilor de materiale).
• Categorie material.
GS12. Modulul va permite lucrul cu loturi de materiale. Un lot va grupa o anumita cantitate dintr-un material cu proprietati similare (produsa la aceeasi data, cu aceeasi data de expirare, etc).
GS13. Modulul va permite lucrul cu numere seriale pentru materiale.
GS14. Este necesar sa existe nativ o varietate de rapoarte referitoare la stocuri si miscari de stocuri, cu diferite marimi dupa care se face selectie, sortare, totalizare, afisare:
Balanta stocurilor la o data pe cod/ furnizor/ tip produs/ gestiune/ locatie/ etc
Registrul stocurilor la o anumita data
Miscari de stocuri intr-o perioada, etc
GS15. In cazul receptiei de materiale pe baza de comanda, sistemul trebuie sa propuna pentru receptie cantitatile din comanda de aprovizionare pentru a usura introducerea acestora si sa verifice automat tolerantele admise la livrare din punct de vedere cantitativ;
GS16. Permita introducerea materialelor in stocuri speciale, pentru inspectie de calitate sau blocate;
GS17. Posibilitatea crearii de rezervari si utilizarea acestora ca referinta pentru miscarile de materiale.
GS18. Inregistrarea tuturor tipurilor posibile de miscari, inclusiv la nivel de lot, daca este cazul:
GS19. Receptii de materiale, atat pentru comenzi de aprovizionare, cat si pentru comenzile de productie;
GS20. Consumuri de materiale pentru toate obiectele de cost definite si eventuale retururi la magazie;
• Transferuri de materiale;
• Esantionari pentru inspectii de calitate;
• Casari de materiale;
• Retururi la furnizori;
GS21. Tiparirea tuturor documentelor de material create (receptii, consumuri, etc.).
GS22. Gestionarea stocurilor de materiale la nivel de lot, sau in cazuri speciale, la nivel de numar serial.
GS23. Gestionarea stocurilor speciale de materiale:
• Stocuri in custodie ale furnizorilor sau la clienti
• Stocuri la subcontractori
• Stocuri de ambalaje returnabile, etc..
GS24. Sa nu permita consumul de materiale din stocuri blocate sau aflate inca in inspectie de calitate.
GS25. Introducerea datei de expirare a materialelor si, in anumite conditii, sa poata bloca receptia acestora daca data de expirare este sub o limita prevazuta.
GS26. Monitorizarea stocurilor pe magazii, atat a celor nerestrictionate, cat si stocurilor speciale, inclusiv la nivel de lot.
GS27. Anularea unor documente de material si, implicit a documentelor contabile corespunzatoare.
GS28. Sistemul trebuie sa ofere cel putin urmatoarele metode de planificare automatizata a stocurilor
– min/max
– punct de lansare a comenzii
GS29. Rapoartele de stocuri trebuie sa indeplineasca urmatoarele cerinte:
Sa prezinte situatia exacta a acestora in timp real, inclusiv la nivel de lot;
Sa prezinte istoricul situatiei materialelor pentru fiecare magazie;
Sa prezinte, in functie de diverse criterii, toate documentele de material sau contabile aferente miscarilor de stoc;
Sa permita compararea valorii stocurilor cu valoarea contabila a acestora din modulul financiar si sa evidentieze posibilele diferente;
Sa permita identificarea stocurilor nefolosite intr-o perioada de timp sau a celor cu miscare lenta;
Sa prezinte cerintele de consum existente la un moment dat impreuna cu situatia stocurilor.
GS30. Executarea tuturor functiilor necesare realizarii inventarului fizic, pe magazii, ori de cate ori este nevoie:
Crearea automata sau manuala de documente cu toate materialele supuse inventarierii, inclusiv la nivel de lot daca este cazul;
Introducerea cantitatilor numarate in cadrul procesului de inventariere;
Renumararea materialelor in cazul in care este necesar;
Blocarea sau inghetarea stocurilor pe perioada inventarierii;
Crearea de documente de diferente de inventar intre stocul scriptic si cel numarat;
Crearea de documente contabile pe baza documentelor de diferenta;
Reevaluarea stocurilor in caz de necesitate.
GS31. Sistemul sa permita evidentierea stocului de natura obiectelor de inventar.
Vanzari
Sistemul trebuie sa permita:
VZ1. Posibilitatea definirii informatiilor generale complete despre clienti: adrese diferite in cazul unor sedii diferite, persoane de contact, termeni de cautare, limba de comunicare, termeni si metode de plata, etc.
VZ2. Inregistrarea urmatoarelor tipuri de documente specifice procesului de vanzare:
Cereri de oferta de la clienti si oferte catre clienti;
Comenzi de vanzare;
Contracte;
Retururi, reclamatii cu posibilitati de livrari suplimentare,etc
VZ3. Verificarea eventualei disponibilitati de stoc si verificarea posibilitatii de livrare a produsului la termenul cerut. Daca termenul cerut nu poate fi respectat, sistemul trebuie sa propuna o data de livrare posibila in functie de comenzile de productie in curs de executie si planificate.
VZ4. Gestiunea centralizata a preturilor si conditiilor de formare a preturilor (discount-uri, promotii , taxe, etc.) si existenta unui istoric al tuturor preturilor, dicounturilor, taxelor, etc, structurate pe perioade de valabilitate.
VZ5. Posibilitatea blocarii totale sau partiale a operatiilor pentru un anumit client.
VZ6. Modulul trebuie sa realizeze gestiunea facturilor emise clientilor care se fac in baza unui contract.
In cadrul proceselor livrare sunt necesare urmatoarele functionalitati:
VZ7. Monitorizarea datelor scadente ale livrarilor.
VZ8. Crearea si procesarea livrarilor scadente la nivel individual, pentru fiecare comanda in parte, cit si colectiv, pe baza listei de livrari scadente – sistemul poate propune crearea de livrari comune in cazul in care exista mai multe livrari scadente pentru acelasi client, sau livrari separate pentru fiecare comanda in parte.
VZ9. Monitorizarea disponibilitatii produselor si procesarea comenzilor de iesire din stoc.
VZ10. Planificarea livrarilor si a transportului, rute si mijloace de transport.
VZ11. Inregistrarea si tiparirea dispozitiilor de livrare si a avizelor de expeditie.
VZ12. Actualizarea automata a stocurilor la iesirea produselor si crearea automata a notelor contabile si de gestiune a costurilor, aferente iesirii produselor din stoc.
VZ13. Posibilitatea blocarii livrarilor.
VZ14. Generarea urmatoarelor rapoarte atat cantitativ, cat si valoric:
Comenzi de vanzare: deschise, total comenzi
Liste Oferte
Liste Contracte
Lista Livrari
Livrari total
Livrari de prelucrat (ridicare din depozit si iesire din gestiune)
Lista Facturi
Documente de facturat
Documente blocate
Documente incomplete
Gestiune flota auto
Sistemul trebuie sa permita:
TR1. Gestionarea documentelor specifice activitatii de transport si notificarea utilizatorului inaintea datelor de expirare:
licente de transport privind transportul de marfa si calatori
examen medical si examen psihologic pentru conducatorii auto, persoana desemnata si consilier de siguranta
certificatul de atestare profesionala a conducatorilor auto pentru transport marfuri generale si calatori
certificatul de atestare profesionala pentru conducatori auto privind transportul de marfuri periculoase ( ADR)
asigurarea obligatorie (RCA), asigurarea CASCO , taxa de drum (rovigneta), contractele de leasing si inchirieri pentru fiecare autovehicul in parte
inspectia tehnica periodica pentru autovehicule
TR2. Administrarea completa, detaliata si istorica a reviziilor, reparațiilor și a tuturor intevențiilor de service-auto efectuate pe vehicul
TR3. Evidenta consumului de piese si materiale, a consumului de combustibil si ulei pentru fiecare autovehicul
TR4. Evidenta orelor lucrate, a kilometrilor parcursi, a consumului normat si a consumului efectiv de carburant pentru fiecare autovehicul
TR5. Urmarirea cheltuielilor materiale si salariale pe centre de cost (utilaje, autovehicule)
TR6. Introducerea foilor de parcurs, pe baza fișelor de activitate zilnica, impreuna cu rutele parcurse și serviciile auxiliare efectuate:
pentru autovehicule
pentru transport calatori
pentru utilaje speciale (consum normat in functie de gradul de incarcare, coeficientul de remorca, ore de functionare in regim special)
TR7. Calculul automat al restului de carburant in rezervor la sfarsitul lunii, in functie de alimentari si consumul normat.
Productie chimica
Sistemul trebuie sa permita:
PC1. Integrarea cu modulul Bugete pentru planificarea productiei pe termen scurt, mediu si lung (luna, trimestru, semestru, 1 an, 2 ani, 3 ani, 5 ani, 7 ani, 10 ani).
PC2. Elaborarea de scenarii de bugete prin variatia preturilor intrarilor (materiilor prime, energie, salarii, chelt. de distributie, alte chelt. fixe, etc.) si iesirilor (produse finite).
PC3. Definirea necesarurilor de aprovizionare materii prime, materiale, energie electrica, costuri cu salarii, alte costuri, cantitativ si valoric (unde este cazul) pe baza normelor specifice de consum pentru o comanda de productie planificata.
PC4. Analiza comparativa, cantitativ si valoric, a productiei bugetate, planificate si realizate, precum si a normelor specifice de consum de proiect, planificate si realizate.
PC5. Definirea capacitatilor de productie, a normelor de consum de proiect si planificate, precum si posibilitatea modificarii lor atunci cand se fac investitii care afecteaza capacitatea sau normele de proiect.
PC6. Definirea fiselor tehnologice pe fiecare produs cu posibilitatea evidentierii fazelor procesului tehnologic.
PC7. Evidentierea in cadrul fiecarei faze:
• consumurilor de materii prime, materiale si semifabricate;
• echipamentelor, utilajelor utilizate;
• urmarirea altor cheltuieli de productie, materii prime, materiale, utilitati;
• organigrama procesului de productie;
PC8. Sa permita planificarea lansarii in fabricatie a comenzilor in functie de termenele de executie si livrare.
PC9. Sa asigure urmarirea productiei lansate in fabricatie pe baza comenzilor care la randul lor sa poata fi urmarite pe baza contractelor.
PC10. Sa permita evaluarea gradului de folosire a capacitatii de productie si a gradului de incarcare al sectiilor de productie.
PC11. Sa permita calculul automat al cantitatilor de materii prime, energie electrica si materiale necesare realizarii programului de productie pe o perioada delimitata de timp, precum si a existentei acestora in stoc in momentul lansarii in fabricatie a comenzii, iar daca existentul nu este suficient pentru onorarea integrala a comenzii:
• evaluarea gradului de satisfacere a comenzii in condiile stocului existent;
• determinarea necesarului de aprovizionat pentru indeplinirea comenzii tinand seama si de stocurile de siguranta;
PC12. Estimarea automata a altor consumuri (alte materii prime, auxiliare, utilitati, consumabile, catalizatori) aferente obtinerii de produse finite pe baza fiselor tehnologice (norme planificate de consum pe fiecare produs).
PC13. Sa permita o analiza care sa determine gradul de asigurare a calitatii atat pentru un anumit produs cat si pentru mai multe produse din aceeasi comanda sau comenzi diferite pe baza unor identificatori de asigurare a calitatii predefiniti (fisa tehnica a produsului sau specificatia tehnica solicitata de client).
PC14. Repartizarea cheltuielilor de productie atat pe comenzi cat si pe produse sau loturi de produse in functie de fisa tehnologica dar si de posibilele neconcordante dintre dintre aceasta si desfasurarea faptica a procesului de productie.
PC15. Introducerea si actualizarea notelor de productie.
PC16. Crearea unui istoric al notelor de productie, care sa permita vizualizarea in orice moment a unei Note de Productie existenta.
PC17. Contabilizarea automata a productiei cu posibilitatea evidentierii eventualelor pierderi aparute in cadrul procesului de productie in aer si apa (NH3, NOx, AN praf, uree praf, NH4, NO3, uree).
PC18. Urmarirea gradului de respectare al fisei tehnologice din punct de vedere al consumurilor normate.
PC19. Posibilitatea evaluarii nivelului de respectare a gradului de realizare a productiei raportat la planul de productie si capacitatea de productie.
PC20. Prioritizarea comenzilor de productie in functie de urgenta de onorare si de stocul de materii prime si materiale necesar pentru onorarea lor integrala.
PC21. Definirea testelor si specificatiilor de calitate pentru tot fluxul de productie.
PC22. Posibilitatea definirii mai multor unitati de masura pentru un articol cat si a relatiilor de converisie intre acestea.
PC23. Lansarea automata a comenzilor de aprovizionare catre magazia de materii prime si/sau catre furnizorii de materii prime.
PC24. Descarcarea automata a stocurilor de materii prime si/sau produse intermediare imediat dupa lansarea in productie sau pe parcursul desfasurarii procesului de productie
PC25. Posibilitatea elaborarii de rapoarte de performanta si analize de indicatori
gradul de utilizare a capacitatii de productie
gradul de realizare a programului de productie
gradul de realizare a normelor de consum de proiect si planificate la materii prime, energie electrica
productivitatea fizica realizata raportata la personalul direct productiv si la total personal
Mentenanta echipamentelor
Cerinte generale
Scopul pe care sistemul de intretinere si mentenanta trebuie sa il indeplineasca este:
MN1. Reprezentarea structurilor organizatorice din punctul de vedere al activitatii de intretinere;
MN2. Sa permita reprezentarea structurii tehnice ale echipamentelor si instalatiilor care vor fi subiectul activitatii de intretinere;
MN3. Planificarea si executia detaliata a activitatilor de intretinere:
• Inspectii privind starea sistemelor aflate in intretinere;
• Intretinerea preventiva a echipamentelor si instalatiilor;
• Reparatii accidentale ale echipamentelor si instalatiilor;
MN4. Planificarea capacitatilor si a resurselor;
MN5. Planificarea si calculul final al costurilor;
MN6. Crearea unui sistem statisitic al activitatii de intretinere si intretinerea unui istoric al activitatilor desfasurate;
MN7. Sistemul de intretinere si reparatii sa fie complet integrat cu sistemele de planificarea productiei, gestiunea materialelor si a serviciilor externe, financiar-contabil, mijloace fixe, gestiunea costurilor, resurse umane;
Cerinte specifice privind structurarea echipamentelor si instalatiilor
Un sistem informatic in domeniul intretinerii si mentenantei poate functiona corect doar daca obiectele si sistemele tehnice vizate de aceste activitati sunt reprezentate corect. Din acet motiv, reprezentarea sistemelor tehnice trebuie sa indeplineasca cateva cerinte de baza:
MN8. Posiblitatea de structurare variabila a echipamentelor si instalatiilor cu un numar nelimitat de nivele ierarhice. Aceasta structurare variabila trebuie sa permita instalarea sau dezinstalarea unui subechipament la un echipament superior, inlocuirea unui echipament cu altul, etc.;
MN9. Istoricul acestor operatii de structurare trebuie sa existe in sistem impreuna cu datele aferente;
MN10. Posibilitatea de individualizare a oricarui echipament si instalatie, a.i. la nivelul obiectelor tehnice sa se poata:
• gestiona date individuale de intretinere;
• realiza sarcini individuale de intretinere;
• pastra evidenta sarcinilor de intretinere efectuate;
• colecta si evalua date despre obiect in perioade mari de timp;
MN11. Posibilitati de intretinere centralizata a structurilor utilizand structuri de referinta si posibilitatea de transfer ierarhic de date in cadrul unei structuri pentru obtinerea unor avantaje in activitatea curenta:
• reducerea timpului necesar gestionarii obiectelor;
• simplificarea gestionarii mentenantei si solicitarilor de intretinere;
• reducerea timpului necesar introducerii datelor de intretinere;
• datele referitoare la intretinere pot fi evaluate individual, rapid si in detaliu;
MN12. Posibilitatea de reprezentare a legaturilor existente intre diferite echipamente si instalatii
MN13. Posibilitatea de regasire rapida in sistem a codurilor ecipamentelor si instalatiilor in cazul in care nu sunt cunoscute
MN14. Posibilitatea introducerii in sistem a masuratorilor privind activitatea unui echipament sau a unor parametri de functionare;
MN15. Posibilitatea de a introduce in sistemul informatic date despre garantiile oferite de producatori sau executantii de lucrari
MN16. Posibilitate de definire in sistem a unei liste de materiale (piese de schimb,etc.) sau subansamble continand componentele echipamentului sau instalatiei respective
MN17. Posibilitatea de a accesa un istoric al tuturor interventiilor executate asupra unui obiect tehnic in decursul timpului si al costurilor aferente;
MN18. Posibilitatea de a urmari eventuale stocuri de obiece tehnice, la nivel individual
MN19. Posibilitatea de a crea o legatura intre obiectele tehnice si obiecte din domeniul financiar (mijloace fixe, centre de cost,etc.) sau logistic (echipa de intretinere, etc.)
Cerinte specifice proceselor de intretinere preventiva
Intretinerea preventiva reprezinta un complex de activitati ce are ca scop mentinerea functionalitatilor unui sistem tehnic pe o durata mare de timp. Pentru realizarea acestui deziderat, sistemul trebuie sa permita:
MN20. Crearea unor liste de sarcini de intretinere pentru fiecare obiect tehnic sau pentru grupe de obiecte tehnice pentru definirea activitatilor ce trebuie realizate (operatii ce trebuie efectuate, consumuri normate de materiale sau servicii externe, timpi de masina sau manopera normati, utilaje necesare, etc.);
MN21. Evaluarea volumului sarcinilor de intretinere preventiva si inspectii, precum si momentele la care trebuie efectuate asupra echipamentelor si locatiilor functionale;
MN22. Stabilirea automata a frecventei (ciclurilor) intretinerii periodice (bazata pe timp, performanta sau alte strategii specifice) si sincronizarea activitatilor pentru mai multe obiecte tehnice;
MN23. Calculul costurilor aferente intretinerii preventive si inspectiilor planificate a avea loc in viitor;
MN24. Crearea de planuri de intretinere care sa tina cont de recomandarile producatorului sau de cerintele legale sau de mediu;
MN25. Planificarea necesarului de materiale sa tina cont de cerintele planurilor de intretinere preventiva;
MN26. De asemenea, aceste planuri sa fie luate in calcul de sistemul de planificare a capacitatilor;
MN27. Simularea activitatii de planificare pentru a analiza posibilele incarcari de capacitate sau costuri;
Cerinte specifice proceselor de executie a intretinerii si reparatiilor
Executia operatiilor de intretinere si mentenanta se refera atat la activitatile planificate, cat si la cele accidentale. Functionalitatile sistemului informatic in acest domeniu trebuie sa permita:
MN28. Crearea, in cazul defectiunilor, a unui document primar de constatare si instiintare, care sa poata furniza anumite informatii necesare:
• Obiectul la care s-a produs evenimentul;
• Tipul de eveniment;
• Motivul care au dus la producerea evenimentului;
• Sarcinile trasate pentru rezolvarea problemei aparute;
• Activitatile executate pentru rezolvarea problemei;
MN29. Crearea, atat in cazul intretinerii planificate, cat si a reparatiilor, a unei comenzi de intretinere cu urmatoarele functii:
• Identificarea operatiilor ce trebuie efectuate, a parametrilor normati si a altor informatii liber definibile necesare;
• Posibilitatea calcularii costurilor planificate;
• Posibilitatea verificarii capacitatilor si resurselor existente, a disponibilitatii materialelor necesare si planificarii operatiilor;
• Posibilitatea transmiterii catre sistemul de planificare a productiei starea de eventuala nefunctionare a sistemului tehnic pentru replanificarea activitatilor de productie;
• Crearea unei rezervari automate de materiale pentru comanda respectiva sau a unor referate de necesitate pentru servici externe sau piese speciale care nu sunt in stoc;
MN30. Introducerea comenzilor de reparatii piese de schimb, care sa permita repararea unor loturi de piese de schimb si sa fie complet integrate cu sistemul de gestiune a stocurilor.
MN31. Introducerea datelor despre realizarea activitatilor necesare, pe parcursul executie sau la final. Aceste date trebuie sa se refere la:
• Materialele utilizate;
• Manopera sau timpii masina utilizati;
• Cantitatile reparate in cazul comenzilor de reparatii piese schimb;
MN32. Calculul costurilor efective pe comanda in urma introducerii datelor despre activitatile realizate.
MN33. Toate informatiile despre activitatile si elementele utilizate in cadrul comenzilor de intretinere sa poata fi regasite in sistem ca date istorice pe tipuri de activitati sau de obiecte tehnice.
Cerinte privind indicatorii de performanta ai activitatii de mentenanta:
Indicatori de performanta pentru mentenanta trebuie sa permita generarea rapoartelor lunare, trimestriale si anuale cu cu privire la urmatorii indicatori:
MN34. Indicatori economici:
• Costuri cu mentenanta in raport cu productia
• Costul comenzilor de lucru: servicii de mentenanta exceptand materialele si costul cu materialele
MN35. Indicatori tehnici de fiabilitate a echipamentelor:
• Timpul mediu dintre defectiuni a echipamentelor (MTBF)
• Topul echipamentelor cu cele mai multe defectiuni
• Procentajul utilajelor ISCIR cu scadenta depasita
• Productia pierduta datorita nefunctionarii echipamentelor
MN36. Indicatori privind managementul comenzilor de mentenanta:
• Gradul de terminare a lucrarilor de mentenanta bazata pe timp
• Gradul de executie a comenzilor de mentenata corectiva
• Total comenzi de lucru de reparatii accidentale si corective
• Procentajul modificarilor in instalatii
• Numarul comenzilor receptionate si terminate intr-o luna
Managementul Proiectelor
Proiectele vor trata atat proiectele de investitii, cat si alte activitati care pot fi incadrate in
categoria de proiecte.
Sistemul trebuie sa permita:
MP1. Definirea proiectelor dupa urmatoarele criterii de clasificare:
Durata
termen scurt (pana la 12 luni)
termen mediu (1-2 ani)
termen lung (3-5 ani)
Finantare
surse proprii (capital circulant, amortizari, cota profit)
surse atrase (credit bancar, aport de capital)
fonduri europene (rambursabile, nerambursabile)
Executie
regie proprie
contractori / subcontractori
mixta
Tip
modernizari
mediu (reducerea poluarii)
RK, RG, inlocuiri de echipamente
MP2. Coordonarea si controlul pentru toate fazele de proiectului pornind de la oferta,
proiectare si aprobare, pana la managementul resurselor si decontarea costurilor.
MP3. Posibilitatea elaborarii de bugete anuale si multianuale (termen scurt, mediu si lung) pentru proiecte.
MP4. Posibilitatea derularii de proiecte pe mai multi ani, gestionarea de proiecte cu finantare din surse multiple, in moneda corespunzatoare fiecarei surse.
MP5. Posibilitatea alocarii resurselor interne pe proiecte in functie de disponibilitate si gestionarea pachetelor de lucru pentru contractori si subcontractori.
MP6. Executia sincronizata si monitorizarea proiectelor cu resurse comune, interne si externe organizatiei.
MP7. Urmarirea platilor, restantelor si restului de plata catre furnizori pe proiecte.
MP8. Alocarea costurilor pe proiecte din tranzactiile realizate in celelalte module care pot colecta costuri (servicii terti, manopera proprie, utilizarea echipamentelor proprii, sau decontul de cheltuieli).
MP9. Urmarirea achizitiilor pe proiecte, prin integrarea cu modulul managementul achizitiilor.
MP10. Contabilizarea comenzilor de lucru executate in regie proprie pe proiecte.
MP11. Gestionarea contractelor cu furnizorii de servicii, cu posibilitatea administrarii mai multor contracte pentru acelasi proiect.
MP12. Trecerea in starea de mijloc fix, a unui obiectiv rezultat al unui proiect de investitii,
atunci cand trece in faza de exploatare. Acesta va avea valoarea rezultata
din colectarea costurilor de productie. Noul mijloc fix trebuie sa pastreze istoricul de
detaliu al costurilor de realizare.
MP13. Raportarea rezultatelor proiectelor in functie de bugetele si termenele de finalizare planificate si activitatile si costurile realizate.
MP14. Monitorizarea costurilor pe perioade de timp si posibilitatea indentificarii si vizualizarii documentelor ce le-au generat.
3.3.9. Contracte de arenda si concesiune
CA1. Sistemul trebuie sa permita introducerea urmatoarelor date legate de contract:
numar si data contract, data expirare contract, date de indentificare si date de contact arendator (persoana fizica/persoana juridica), actul de proprietate, alte mentiuni.
CA2. Pentru fiecare contract trebuie sa existe posibilitatea introducerii mai multor parcele cu urmatoarele date: categoria de folosinta, numar parcela, numar sola, suprafata parcela.
CA3. Sistemul trebuie sa permita introducerea obligatiilor si termenelor de plata stabilite prin contract: redeventa produs agricol (to/ha), pret/tona produs agricol, termenele de plata pentru ambele tipuri de redevente.
CA4. Sistemul trebuie sa permita actualizarea in masa a contractelor pentru pretul/tona al produsului agricol stabilit ca redeventa (se stabileste in momentul recoltei).
CA5. Sistemul trebuie sa permita gestiunea actelor aditionale ce modifica cuantumul redeventei sau tipul produsului agricol, stabilite initial in contract.
CA6. Sistemul trebuie sa aiba dezvoltate mecanisme de atentionare in cazul introducerii unei parcele pentru un contract care exista deja alocata altui contract.
CA7. Modulul trebuie sa fie integrat cu modulul de contabilitate financiara si contabilitate de gestiune pentru evidenta platilor redeventelor in produse agricole si financiare (prin casa si banca) si calculul restului de plata pentru fiecare arendator.
3.3.10. Productie vegetala
Sistemul trebuie sa permita:
PV1. Definirea fermelor pentru fiecare societate sau punct de lucru care desfasoara activitati de productie vegetala.
PV2. Gestiunea multiplelor forme de detinere a parcelelor (arenda, concesiune, proprietate) pentru fiecare ferma.
PV3. Inregistrarea si actualizarea datelor despre calitatea solului (ex: cantitatea de azot/mp)
PV4. Planificarea culturilor, la inceperea anului agricol, la nivel de sola.
PV5. Planificarea mai multor culturi pentru o sola cadastrala cu specificarea suprafetei si pozitiei geografice pentru fiecare cultura.
PV6. Afisarea informatiilor istorice despre sole in momentul planificarii culturilor (agrochimia solului, istoricul culturilor, istoricul tratamentelor)
PV7. Definirea unui nomenclator cu toate tipurile de activitati specifice:
arat, scarificat, discuit, tavalugit
fertilizare, semanat, erbicidare, tratare insecticid, prasit cu incorporat uree
transport, deplasare, incarcat/descarcat ingrasaminte
recoltat
PV8. Definirea unor nomenclatoare pentru tipurile de culturi, utilaje motorizate si nemotorizate.
PV9. Definirea unui nomenclator de tipuri lucrari, fiecare lucrare avand urmatoarele atribute:
tip activitate
tip cultura
tip utilaj motorizat
tractor (pentru lucrarile definte la cerinta PV7. punctele 1,2,3)
combina (pentru lucrarea definita la cerinta PV7. punctul 4)
tip utilaj
PV10. Definirea normelor de consum si tarifelor de plata si decontare pentru fiecare tip de lucrare:
norma de lucru (ha/zi)
norma de consum de motorina (l/ha)
consum de motorina (l/ora) – pentru lucrarile definite la punctul 3
tariful de plata pentru mecanizatori (lei/ha) necesar pentru calculul ulterior al salariilor in acord
tariful de decontare (lei/ha) necesar pentru lucrarile efectuate pentru terti.
PV11. Planificarea lucrarilor pe perioade pentru fiecare sola in functie de suprafata acesteia si utilajele disponibile.
PV12. Comenzile de lucru se vor inregistra zilnic si vor contine cel putin urmatoarele date:
data efectuarii lucrarii
tipul lucrarii
utilajul utilizat (numarul de indentificare)
mecanizatorul
suprafata lucrata
PV13. Inregistrarea si actualizarea datelor calitative pentru fiecare tip de cultura pe tot ciclul vegetatie.
Modulul trebuie sa fie integrat cu cel de contabilitate de gestiune si sa permita:
PV14. Definirea utilajelor ca centre de cost
PV15. Definirea solelor ca centre de cost si profit
PV16. Inregistrarea bonurilor de consum de motorina pe utilaj motorizat
PV17. Inregistrarea bonurilor de consum si retur de materiale auxiliare (ingrasaminte/pesticide/seminte) pe comenzile de lucru definite la cerinta PV7. punctul 3.
PV18. Gestiunea ambalajelor de pesticide folosite, inregistrate cu bon de retur in urma unei comenzi de erbicidare/tratare insecticid.
PV19. Calculul consumurilor de materiale pe comenzi de lucru/culturi.
PV20. Calculul costurilor cu manopera pe mecanizatori si comenzi de lucru in functie de tariful specific lucrarii si suprafata executata.
PV21. Calculul costurilor comenzilor de reparatie pe utilaje.
PV22. Transferul costurilor de reparatie si amortizare a utilajelor pe sole.
PV23. Calculul costurilor comenzilor de lucru si alocarea acestora pe sole.
PV24. Calculul costurilor pentru productia in curs de executie pe suprafata(ha) si culturi.
PV25. Compararea rezultatelor postcalculului cu datele stabilite in antecalcul.
Modulul trebuie sa fie integrat cu cel de gestiune a flotei auto si sa permita:
PV26. Alocarea unui anumit utilaj motorizat pe comanda de lucru dupa numarul unic de indentificare.
PV27. Calculul consumului de motorina pe utilaj in functie de norma de consum specifica lucrarii si suprafata executata.
PV28. Calculul restului de motorina in rezervor pe utilaj.
PV29. Calculul orelor de functionare pe fiecare utilaj motorizat in functie de suprafata executata totala.
PV30. Gestiunea comenzilor de reparatie pe utilaj (inregistrarea bonurilor de consum de piese de schimb pe comanda deschisa pe utilaj) si alocarea costurilor pe utilaj.
3.3.11. Conditionare-depozitare
Sistemul trebuie sa permita:
CD1. Introducerea contractelor de achizitie si servicii de depozitare pentru care sa permita definirea unei matrici de preturi pentru operatiunile specifice:
receptie
conditionare
recirculare
aerare
uscare cu gaz/combustibil
gazare
depozitare
livrare auto/cf
CD2. Definirea unor liste de reduceri comerciale ale tarifelor de baza in functie de cantitatea contractata.
CD3. Receptia recoltei in baza buletinului de cantarire, analiza si receptie (BCAR) raport emis de sistem pe baza introducerii urmatoarelor date si documente:
avizelor de insotire marfa
tichetelor de laborator
notelor de cantar
date calitative pentru fiecare lot: corpuri straine, impuritati
CD4. Emiterea documentului BCAR pentru mai multe avize de expeditie de la acelasi client
CD5. Inregistrarea rezultatelor analizelor de calitate efectuate la receptia/livrarea marfii si emiterea tichetului de laborator:
– produsul si soiul
– umiditatea si greutatea hectolitrica
– greutatea specificata in aviz
– celula unde va fi depozitata marfa
CD6. Definirea parametrilor specifici de calitate pentru fiecare cultura si inregistrarea acestora in BCAR conform grupelor principale:
Corpuri straine
Defecte
starea sanitara (infestata/neinfestata)
caracteristici organoleptice
CD7. Interfatarea cu cantarele digitale pentru inregistrarea automata a datelor rezultate in urma cantaririlor si emiterea notelor de cantar.
CD8. Posibilitatea blocarii emiterii notei de cantar in cazul in care nu exista un contract de depozitare inregistrat.
CD9. Efectuarea tranzactiilor intre companii membre ale unui holding: vizualizarea documentelor de tip BCAR emise de societatea care depoziteaza, validarea si inregistrarea acestora in cadrul societatii producatore, fara reintroducerea datelor.
CD10. Stabilirea preturilor de achizitie a cerealelor fara ca utilizatorul final sa aiba posibilitatea de modificare in momentul procesarii comenzii de achizitie.
CD11. Definirea unor nivele de calitate cu limite inferioare si superioare in functie de paramateri specifici fiecarui produs pornind de la valorile STAS. Aceste nivele de calitate sunt necesare pentru determinarea abaterii de calitate fata de STAS a produsului receptionat si a calculului fizicului de plata (cantitatea fizica ce corespunde cerintelor de calitate stabilite prin STAS).
CD12. Emiterea buletinului de receptie si plata (BRP) ce contine suma totala de plata calculata ca produs dintre cantitatea fizica de plata si pretul de achizitie unic in sistem pentru fiecare tip de cultura.
CD13. Calculul si retinerea impozitului de 2 % pentru venituri din activitati agricole pentru clientii persoane fizice ce depoziteaza produsele agricole.
CD14. Introducerea situatiilor rezultatelor conditionarii (SRC), proces necesar pentru eliminarea corpurilor straine sau reducerii umiditatii. Pentru fiecare SRC este necesara introducerea analizelor de calitate inainte si dupa procesul de conditionare si a notei de cantar rezultata in urma cantaririi produsului final.
CD15. Introducerea cantitatilor de subproduse rezultate in urma conditionarii si actualizarea automata a stocurilor in urma validarii SRC-ului.
CD16. Calculul costurilor activitatilor de conditionare pentru tona de produs:
tarare (conditionare)
aerare
recirculare
uscare
gazare
CD17. Calculul costurilor de depozitare pe tip de produs.
CD18. Facturarea serviciilor de conditionare pe baza SRC-urilor.
CD19. Facturarea serviciilor de depozitare, ce necesita calculul stocului mediu de marfa in depozit in decursul unei luni pentru fiecare client. Stocul mediu se calculeaza ca medie ponderata intre cantitatile depozitate si numarul de zile de depozitare in functie de intrari si iesiri.
CD20. Calculul gradului de ocupare al silozului in functie de capacitatea totala de depozitare.
Cerinte non-functionale
Disponibilitatea sistemului
Sistemul va avea o configuratie de disponibilitate inalta, in care nu vor exista puncte unice de defectare (Single Point Of Failure). Se recomanda utilizarea clusterelor de tip activ-activ, acolo unde tehnologia permite acest lucru.
Fiecare echipament de tip server va include elemente de redundanta pentru cel putin urmatorele conponente: surse de alimentare, discuri, porturi LAN, porturi SAN.
Conectarea serverelor la LAN si SAN trebuie realizata astfel incat sa se asigure redundanta comunicatiilor, fiecare server avand conexiuni catre minim 2 echipamente active de retea LAN/SAN.
Scalabilitatea sistemului
Performanta sistemului este determinata practic de:
viteza de raspuns a bazei de date
putera de procesare a serverelor de aplicatie
viteza de raspuns a conexiunii server de aplicatie
puterea de procesare a statiei de lucru a utilizatorilor
Sistemul va fi scalabil atat pe verticala (serverele vor permite cresterea capacitatii proprii de procesare), cat si pe orizontala, prin adaugarea de noduri pentru fiecare componenta a sistemului. Performanta sa trebuie sa poata fi marita intr-un mod facil, fara ca un upgrade ulterior sa presupuna inlocuiri de echipamente ci doar adaugari la cele existente.
Capacitate si performanta
Sistemul trebuie sa fie dimensionat avand in vedere numarul de 360 utilizatori cu urmatoarea distributie:
Parametrii de performanta ai sistemului (timp de raspuns, timp de prelucrare) vor fi stabiliti impreuna cu furnizorul in etapa de analiza a proiectului.
Salvarea si recuperarea datelor
Sistemul va fi prevazut cu o solutie de backup centralizat, care sa permita definirea de politici de salvare si restaurare a datelor. Pentru baza de date vor exista agenti speciali, care vor permite salvarea datelor direct din baza de date, folosind facilitatile oferite de aceasta.
Salvarea datelor trebuie sa se realizeze in timp ce sistemul este functional.
Arhivarea datelor
Sistemul trebuie sa includa un modul dedicat pentru arhivarea datelor istorice si stocarea lor pe perioada lunga de timp.
Bugetele si proiectele ce traverseaza multiplii ani fiscali, necesitatile de analize financiar-economice bazate pe un trend semnificativ de informatii, duc la necesitatea pastrarii in baza de date a informatiilor pe minim 5 ani fiscali, cu posibilitate de arhivare si backup.
Sistemul informatic integrat si baza de date trebuie concepute si organizate pentru a opera intervalele de timp curente si date cu caracter istoric, dar sa si ofere acces la arhive.
Mangementul utilizatorilor si securitatea sistemului
Utilizatorii vor trebui sa aiba acces limitat la date si functionalitatea aplicatiei prin verificare parole si drepturi de acces controlate.
Accesul la aplicatie se va realiza printr-un sistem de drepturi si parole de acces la nivel de utilizator, rol si modul.
Sistemul trebuie sa permita administrarea drepturilor de acces la functionalitati in conformitate cu responsabilitatile alocate utilizatorilor.
Siguranta in functionare
Sistemul va produce in mod consistent aceleasi rezultate in diferite conditii de functionare.
In cazul actiunilor incheiate cu esec, sistemul trebuie sa trimita inapoi utilizatorului un mesaj relevant de eroare insotit de instructiuni clare privind modul de continuare al lucrului.
Cerinte de servicii
Planul preliminar de proiect
Ofertantul trebuie sa prezinte un plan preliminar de proiect, care trebuie sa acopere urmatoarele puncte:
metodologia de management a proiectului;
organizarea proiectului;
livrare;
analiza si proiectare;
instalare si configurare;
dezvoltare in cadrul componentelor sistemului;
instruire;
testare;
planificarea activitatilor, timpul de desfasurare si resursele implicate in suport, mentenanta si garantie;
Implementarea solutiei
Urmatoarele faze ale implementarii trebuie urmate de catre ofertant:
Faza de analiza si proiectare;
Faza de implementare;
Faza de executie a testarii;
Faza de trecere in productie;
Faza de suport, garantie si mentenanta;
Planul de implementare
Ofertantul trebuie sa specifice un plan de implementare a solutiei in care sa detalieze urmatoarele activitati:
Planul de proiect, reprezentand planul de proiect al implementarii
Organizare de implementare, continand rolurile, responsabilitatile si calificarea necesara persoanelor care vor efectua implementarea si operarea
Factorii de risc, continand riscurile existente sau anticipate in legatura cu implementarea
Cerinte de hardware/software/resurse pentru fiecare faza a implementarii
Planul de intruire si educatie pentru utilizatori si pentru echipele de implementare
Planul de suport, continand procedurile si resursele furnizate de implementator si beneficiar
Planul de comunicare, descriind modul cum se efectueza comunicarea intre echipele de implementare
Constrangeri de timp, continand limitarile asupra efectuarii fazei de implementare
Testarea si aceptanta sistemului
Testarea sistemului se va face in mai multe etape, astfel:
Testare functionala pe date relevante
Testare de performanta (timp de raspuns)
Teste de stres ( volum de date, numar de utilizatori concurenti)
Testare pentru acceptanta finala
Este obligatoriu ca ofertantul sa introduca in planul general de proiect si activitatile aferente testarii, in conformitate cu etapele enumerate mai sus.
Criterii de acceptanta
Criteriile de acceptanta de la fiecare nivel de testare vor fi stabilite in acord cu beneficiarul/utilizatorii sistemului, astfel incat sa asigure conformitatea executiei testelor cu specificatiile de testare si acceptarea livrabilelor.
Criteriile de acceptanta vor include ca cerinte elaborarea documentatiei de utilizare si efectuarea instruirii privind utilizarea si administrarea sistemului.
Procedura de acceptanta
Procedura de acceptanta la nivelul testelor de acceptanta trebuie sa sumarizeze in cadrul raportului de acceptanta toate activitatile efectuate, rezultatele si problemele identificate. Acceptanta sistemului se va realiza prin semnarea raportului final de acceptanta de catre Comisia de Acceptanta desemnata de beneficiar.
Documentatie
Ofertantul trebuie sa descrie documentatia care va fi pusa la dispozitia beneficiarului pe parcursul proiectului si sa explice in ce mod va fi organizata aceasta documentatie: categorii de documente, conventii de numerotare si denumire, machete de documente:
specificatii detaliate pentru toate modulele aplicatiei la nivel functional. Se vor descrise deasemenea si integrarea intre module.
documentatie hardware: descrierea completa a specificatiilor hardware si a intructiunilor de instalre, configurare, operare si depanare
documentatie a software-ului comercial: descrierea completa, atat functionala cat si tehnica. Se vor avea in vedere instructiuni de instalare, configurare, operare si depanare
ghidul de operare si administrare: acesta trebuie sa acopere arhitectura tehnica si functionala a tututor modulelor sistemului propus si defineste atat cerintele fundamentale de functionare a sistemului cat si metode de intretinere zilnica. Acest document trebuie sa contina:
versiunea pentru care a fost creat ghidul
configurarea pentru fiecare componenta interna
configurarea pentru colaborarea cu sistemele externe
managementul erorilor
documentatie de administrare a fiecarui modul in parte
salvarea si restaurarea sistemului
Instruire
Serviciile de instruire vor avea in vedere doua categorii de audienta:
utilizatori finali
administratorii sistemului
Instruirea utilizatorilor finali ai sistemului
Instruirea utilizatorilor finali ai sistemului se va face prin:
metoda train the trainers de catre echipa de proiect a beneficiarului
ofertantul va sustine prin template-uri de manuale si va oferi suport echipei de formatori a beneficiarului
ofertantul se obliga sa instruiasca echipa de formatori a beneficiarului
Ofertantul trebuie sa descrie modul de organizare al acestor cursuri, necesar de infrastructura, materiale de curs etc.
Instruirea administratorilor de sistem
Administratorii vor fi instruiti de catre constractant astfel incat sa poate asigura functionarea sistemului independent de contractant, incepand cu perioada de post-implementare in domeniile:
administrarea sistemelor hardware
administrarea sistemelor de operare
administrarea bazei de date
administrarea software-ului de tip middleware pe care se bazeaza sistemul (server de aplicatii)
Ofertantul trebuie sa descrie modul de organizare al acestor cursuri, consideratii de pret, locatie, necesar de infrastructura, materiale de curs etc. De asemenea, ofertantul trebuie sa specifice urmatoarele:
etapele in desfasurarea proiectului in care vor avea loc activitati de instruire
strategia de instruire
nivel de cunostinte al celor care vor sustine sedintele de instruire
metodologia de instruire
In plus ofertantul va include si instruire in timpul implementarii pentru utilizatorii din echipa de proiect ai beneficiarului prin implicarea lor in diferitele etape ale proiectului. In acest sens, ofertantul trebuie sa prezinte in oferta modul in care va asigura acest lucru.
Se vor realiza manuale tehnice care vor fi puse la dispozitia administratorilor responsabili cu mentenanta sistemului si utilizarea acestuia. Manualele vor include procedurile uzuale de lucru cu componentele sistemului (oprire, pornire, recuperare in caz de eroare).
Formatul ofertelor
Oferta tehnica va include cel putin urmatoarele elemente:
Rezumat executiv
Intelegerea cerintelor proiectului
Modul in care oferta raspunde cerintelor
prezentarea solutiei propuse ( descrierea arhitecturii sistemului, descrierea componentelor, descrierea interactiunii dintre componente pentru realizarea functionalitatilor solicitate, descrierea infrastructurii hardware si de comunicatii)
raspuns la fiecare cerinta functionala a caietului de sarcini sub forma unei matrici de conformitate; fiecare cerinta poate avea una dintre urmatoarele valori:
indeplinita
neindeplinita
indeplinita prin integrarea cu un alt sistem
necesita dezvoltare/configurare
in cazul in care pentru indeplinirea unei cerinte este nevoie de dezvoltari/configurari suplimentare, raspusurile trebuie sa fie explicative, cu cat mai multe detalii despre modul in care se va realiza respectiva cerinta;
Metodologia de lucru
Detalierea scopului proiectului si continutul livrabilelor
Preconditii si ipoteze de lucru
Descrierea activitatilor, incluzand: responsabilitati implementator, responsabilitati beneficiar, detaliere activitati, criterii de finalizare si livrabile.
Plan de proiect estimat
Echipa de proiect (roluri cheie, cv-uri persoane cheie)
Oferta comerciala va fi compusa din patru elemente conform etapelor de implementare definite la capitolul 2:
oferta proiect pilot divizia produse chimie
oferta proiect pilot divizia agricultura
oferta proiect rollout divizia produse chimie
oferta proiect rollout divizia agricultura
Metodologie evaluare oferta
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Implementare Sistem Informatic Erp (ID: 149856)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.
