Grįžti į sąrašą

Veiklos valdymo informacinės sistemos priežiūros, vystymo ir naudotojų konsultavimo paslaugų pirkimas

Išanalizuota

Raseinių rajono savivaldybės administracija

200 000 €
Atviras konkursasCPV: 72267000 - Programinės įrangos priežiūros ir tvarkymo paslaugos
ID: 77163562026-05-06 05:22
Atidaryti CVP IS

Aprašymas

Perkamos veiklos valdymo informacinės sistemos (VVS) priežiūros, vystymo ir naudotojų konsultavimo paslaugos Raseinių rajono savivaldybės administracijai ir jos biudžetinėms įstaigoms. VVS apima finansų valdymo, personalo, strateginio planavimo, dokumentų valdymo, viešųjų pirkimų ir socialinių išmokų apskaitos sistemas. Paslaugos apima palaikymą, atnaujinimą pagal teisės aktus, incidentų valdymą, konsultavimą, papildomą vystymą, duomenų migravimą, mokymus ir informacijos saugumo užtikrinimą.

Kvalifikaciniai reikalavimai

Kvalifikacinių reikalavimų nerasta

Techniniai reikalavimai

SIAS SMS siuntimas

  • 1Turi būti galimybė, SIAS pildant kreipimosi dokumentą, pažymėti, jog pareiškėją reikia informuoti SMS žinute, pasikeitus prašymo būsenai.
  • 2Turi būti galimybė susikurti standartinius SMS pranešimų tekstus.
  • 3Turi būti galimybė įkeltą šablono tekstą koreguoti ir pritaikyti kiekvienam gavėjui.
  • 4Turi būti sudaryta galimybė išsiųsti gyventojui SMS žinutę. Pakeitus prašymo būseną, per meniu pasirinkus „Gyventojas/SMS žinutės“ arba įrankių juostoje paspaudus mygtuką „Naujas“.
  • 5Maksimalus žinutės ilgis 140 simbolių, jei nenaudojamos lietuviškos raidės. Jei yra bent viena lietuviška raidė - 70 simbolių. Vienu metu galima siųsti iki 3 žinučių, tokiu būdu maksimalus teksto ilgis be lietuviškų raidžių 420 simbolių, su lietuviškomis 210 simbolių.
  • 6Funkcionalumas turi turėti integracinį API servisą, duomenų perdavimui ryšio paslaugų tiekėjui.
  • 7SIAS turi būti realizuotas SMS siuntimo istorijos peržiūros funkcionalumas.

SIAS Virtuali byla

  • 1Gyventojų sąraše pasirinktam gyventojui ar atidarytam konkrečiam prašymui turi būti sukurtas patekimas į modulį per specializuotą mygtuką „VByla“.
  • 2Modulyje turi būti rodomas pasirinkto asmens dokumentų sąrašas. Sąraše turi būti atvaizduojamas informacija pagal šiuos pjūvius: Nuoroda į prašymo numerį; Dokumentų grupė; Dokumento pavadinimas; Patalpinimo data; Bendro pobūdžio dokumentai tinkantys ir kitiems prašymams; Dokumento originalo data; Pastaba/komentaras.
  • 3Turi būti sudaryta galimybė registruoti naują dokumentą nurodant: Nuoroda į prašymą - naudotojo pasirenkamas iš esamų užregistruotų prašymų; Dokumento grupė - pasirenkama iš atitinkamo žinyno; Dokumento pavadinimas - pasirenkama iš atitinkamo žinyno; Patalpinimo data - automatiškai sistemos užpildoma data, kada įkeliamas dokumentas; Bendro pobūdžio dokumentai tinkantys ir kitiems prašymams - įvedant dokumentą naudotojas gali nurodyti ar tai bendro pobūdžio dokumentas; Dokumento originalo vieta - pildo naudotojas; Pastaba/komentaras - laukas papildomai galimai informacija susivesti apie dokumentą.
  • 4Turi būti sudaryta galimybė naują dokumentą įkelti: Bendrame asmens dokumentų sąraše; Pildomo prašymo kortelėje; SIAS suformuoto dokumento peržiūros lange; SPIS sistemos registrų išrašo lange.

Mokymų reikalavimai

  • 1Iki mokymų vykdymo pradžios Tiekėjas turės parengti administratorių ir naudotojų mokymų medžiagą ir naudotojų vadovus.
  • 2Mokymo medžiaga turi apimti visas numatytas sistemos funkcijas ir leisti skaitytojui savarankiškai vykdyti konkrečias užduotis.
  • 3Mokymo medžiagoje turi būti pateikti visų sukurtos programinės įrangos laukų paaiškinimai.
  • 4Mokymų medžiagą turi sudaryti teorinė medžiaga, ir praktinės užduotys.
  • 5Mokymų medžiaga turi būti vientisa – teorinės medžiagos ir praktinių užduočių struktūra ir turinio detalumas turi būti vienodi, kad naudotojui būtų aišku, kaip savarankiškai atlikti kiekvieną užduotį ar jos dalį.
  • 6Mokymai turi būti vykdomi specialiai mokymams Tiekėjas parengtoje aplinkoje, kurios konfigūracija turi atitikti gamybinę aplinką.
  • 7Turi būti parengti ir pateikti visi duomenys reikalingi praktinėms užduotims atlikti.
  • 8Naudotojų ir administratorių mokymai turi būti organizuojami tokiomis grupėmis, užtikrinant, kad naudotojai nebus mokomi naudotis funkcijomis, kuriomis jie nesinaudos.
  • 9Detalų naudotojų grupių sąrašas turi būti suderintas su Užsakovu iki mokymų pradžios.
  • 10Preliminarus naudotojų, kuriuos reikės apmokyti, kiekis – apie 200 naudotojų (tarp jų apie 30 administratorių).

DVS kitos integracijos

  • 1DVS turi būti realizuotas duomenų mainų modulio funkcionalumas (REST API) integracijoms su kitomis išorinėmis sistemomis.

SIAS kiti reikalavimai

  • 1Naudotojo sąsaja turi veikti WEB aplinkoje realizuotoje aplikacijoje (Microsoft Edge, Google Chrome, Mozilla Firefox, Opera, Safari oficialiais gamintojo palaikomose versijose) su galimybe naudoti saugų duomenų apsikeitimo protokolą HTTPS.
  • 2Turi būti galimybė paslaugą naudoti planšetiniuose kompiuteriuose su Android ar iOS operacinėmis sistemomis.
  • 3Sistemoje turi būti užtikrinti šie SIAS reakcijos greičiai (įvertinus, jog su Sistema vienu metu gali dirbti apie 100 sistemos naudotojų).
  • 4Turi būti galimybė naudoti elektroninių dokumentų pasirašymo procesui būtinąsias papildomas priemones.
  • 5Naudotojų, pasirašančiųjų el. parašu, skaičius – neribojamas.

Testavimo reikalavimai

  • 1Tiekėjas turi konsultuoti Užsakovą rengiant testavimo scenarijus.
  • 2Tinkamai veikia atskiros Sistemos funkcijos bei sąsajos tarp jų.
  • 3Tinkamai veikia naudotojo sąsaja.
  • 4Tinkamai realizuoti funkciniai ir nefunkciniai reikalavimai kurie pateikti šiame dokumente.
  • 5Tinkamai sukurtos duomenų peržiūros formos.
  • 6Tinkamai veikia integracinės sąsajos su kitomis sistemomis.
  • 7Atliktas priėmimo testavimas pagal suderintus testavimo scenarijus.
  • 8Visos kritinės klaidos yra išspręstos iki Sistemos paleidimo.
  • 9Yra neišspręstos ne daugiau nei 5 svarbios klaidos.
  • 10Sistemos testavimas bus užbaigtas, kai visų testavimo scenarijų rezultatai atitiks aukščiau įvardintas testavimo rezultatų priėmimo sąlygas.
  • 11Suteiktų paslaugų rezultatų klaidos ir (ar) trikdžiai klasifikuojami: Kritinė klaida – kai nustatytas trikdis ir / ar problema, dėl kurios Sistemos naudotojas negali vykdyti numatytų būtinų funkcijų ir nežinomas joks kitas priimtinas šios funkcijos vykdymas.
  • 12Svarbi klaida - neapibrėžtas funkcijos veikimas, kuris leidžia įvykdyti numatytą VVS funkciją, tačiau naudotojui reikia atlikti papildomus, nenumatytus ar alternatyvius veiksmus.
  • 13Neesminė klaida – kosmetinės ar panašios VVS klaidos, kurios neįtakoja korektiško funkcijų veikimo.
  • 14Sprendimą, kokio tipo (kritinė klaida, svarbi, neesminė) yra nustatyta klaida, priima Užsakovo paskirti atsakingi asmenys, informavę Tiekėjo paskirtus atsakingus asmenis.
  • 15Kritinės klaidos reakcijos trukmė: ne ilgiau kaip per 2 Užsakovo darbo valandas nuo Užsakovo pranešimo pateikimo momento. Sprendimo trukmė: ne ilgiau kaip per 6 Užsakovo darbo valandas nuo reakcijos termino pabaigos.
  • 16Svarbios klaidos reakcijos trukmė: ne ilgiau kaip per 4 Užsakovo darbo valandas nuo Užsakovo pranešimo pateikimo momento. Sprendimo trukmė: ne ilgiau kaip per 10 Užsakovo darbo valandas nuo reakcijos termino pabaigos.
  • 17Neesminės klaidos reakcijos trukmė: ne ilgiau kaip per 8 Užsakovo darbo valandas nuo Užsakovo pranešimo pateikimo momento. Sprendimo trukmė: ne ilgiau kaip per 80 Užsakovo darbo valandas nuo reakcijos termino pabaigos.
  • 18Jei klaidos ar neatitikimo per nurodytą laiką pašalinti negalima, kartu su Užsakovu suderinamas kitas priimtinas klaidos ar neatitikimo šalinimo laikas.
  • 19Tiekėjas su Užsakovu (raštu) gali susiderinti kitus, Perkančiajai organizacijai priimtinus, klaidų pašalinimo terminus.

VPS bendrieji reikalavimai

  • 1Plečiamumas – VPS programinės įrangos architektūra ir jos realizacija turi palaikyti pajėgumų plėtimą, prijungiant papildomą techninę įrangą (angl. Scaling). VPS turi veikti daugiasluoksnės architektūros pagrindu ir turėti galimybę būti integruojama atskirų sluoksnių lygmenyse.
  • 2Prieinamumas (laikas ir vieta) – VPS turi būti technologiškai funkcionali ir pasiekiama pagal principą „24 valandos per dieną, 7 dienos per savaitę, 365 dienos per metus“.
  • 3Privatumas ir saugumas - technologinėmis priemonėmis užtikrinamas subjektų (tikslinių grupių atstovų) ir duomenų apie juos privatumas bei konfidencialumas informacijos teikimo metu, prieš ir po jo. Esminiai informacijos privatumo ir saugos principai, kurie turi būti įgyvendinti: Konfidencialumas (angl. Confidentiality) – siunčiamos ir saugomos informacijos konfidencialumas; Vientisumas (angl. Integrity) – siunčiamos ir saugomos informacijos vientisumas; Susiejimo efektas – siunčiamos ir saugomos informacijos autentiškumas ir įrodomumas (angl. Non-repudiation).

DVS analitikos reikalavimai

  • 1DVS turi būti integruotas SQL programavimo užklausų redaktorius. SQL užklausų redaktorius turi veikti integruotoje DVS sąsajoje be papildomos programinės įrangos diegimo darbo vietos kompiuteriuose.
  • 2DVS turi būti integruotas SQL užklausų grafinis konstruktorius, suteikiantis galimybė SQL užklausą formuoti be programavimo. SQL užklausų grafinis konstruktorius turi veikti integruotoje DVS sąsajoje be papildomos programinės įrangos diegimo darbo vietos kompiuteriuose.
  • 3Grafinis konstravimo įrankis turi būti DVS sudedamoji dalis, pasiekiamas tiesiogiai iš DVS, t. y. naršyklėje konstruojant užklausą „įtempk ir paleisk“ (angl. drag-and-drop) principu.
  • 4DVS turi leisti vykdyti SQL redaktoriuje parašytos užklausos kodą.
  • 5SQL užklausos vykdymo duomenų rezultatas turi būti pateikiamas lentelėje.
  • 6DVS kuriant užklausos įrašą turi būti galimybė pasirinkti parametrus: Pavadinimas; Aprašymas; Formavimo būdas (redaktorius, konstruktorius); Būseną, ar aktyvus.
  • 7DVS turi būti integruotas grafinis konstruktorius suvestinėms (angl. pivot) rengti. Grafinis konstruktorius turi veikti integruotoje DVS sąsajoje be papildomos programinės įrangos diegimo darbo vietos kompiuteriuose.
  • 8Grafinis suvestinių konstravimo įrankis turi būti DVS sudedamoji dalis, pasiekiamas tiesiogiai iš DVS, t. y. naršyklėje konstruojant suvestinę „įtempk ir paleisk“ (angl. drag-and-drop) principu.
  • 9DVS kuriant suvestinės įrašą turi būti galimybė pasirinkti parametrus: Pavadinimas; Aprašymas; SQL užklausa.
  • 10DVS turi būti galimybė suvestinės duomenis pavaizduoti lentelėje.
  • 11DVS turi būti galimybė suvestinės duomenis pavaizduoti stulpelinėje diagramoje.
  • 12DVS turi būti galimybė suvestinės duomenis pavaizduoti taškinėje diagramoje.
  • 13DVS turi būti galimybė suvestinės duomenis pavaizduoti skritulinėje diagramoje.
  • 14DVS turi būti galimybė suvestinės duomenis pavaizduoti plokštuminėje diagramoje.
  • 15DVS turi būti galimybė suvestinės duomenis pavaizduoti juostinėje diagramoje.
  • 16DVS turi būti galimybė išsaugoti į darbalaukio valdiklių sąrašą suvestinės duomenis kaip lentelės (sąrašo) valdiklį.
  • 17DVS turi būti galimybė išsaugoti į darbalaukio valdiklių sąrašą suvestinės duomenis kaip grafiko valdiklį.

Dokumentacijos reikalavimai

  • 1Dokumentinių rezultatų derinimo trukmė priklauso nuo dokumento apimties. Užsakovas pastabas pateikia per 3 d. d., jeigu dokumento apimtis yra iki 10 lapų. Jei dokumento apimtis yra didesnė, Užsakovas pastabas teikia per 5 d. d.
  • 2Užsakovo pastabų teikimas rezultatams ir kitoms pateiktims turi būti vykdomas akumuliuotai (visi Projekto komandos atsakingi asmenys teikia pastabas bendrai viename dokumente).
  • 3Tiekėjo pataisyti dokumentai turi būti teikiami su matomais pakeitimais.
  • 4Visi Projekto dokumentai turi būti suderinti 2 iteracijų apimtyje.
  • 5Užsakovas gali teikti patikslinimus / komentarus pastaboms ir didesniu iteracijų skaičiumi, jei pastabos ir komentarai teikiami toms pačioms, arba nuo jų priklausomoms dokumento dalims, kurioms pastabos buvo teikiamos pirmų 2 iteracijų apimtyje, t. y., 3 iteracijos metu negali būti teikiamos visai naujos pastabos, kurios nėra susijusios su prieš tai teiktomis pastabomis ar nuo jų priklausančiais dokumento pakeitimais.
  • 6Rezultatai yra laikomi priimtais, jei yra gaunamas patvirtinimas iš Užsakovo, jog rezultatai yra tinkami arba jei per numatytą terminą Užsakovas nepateikia jokio atsakymo dėl rezultato tinkamumo.
  • 7Parengtas naujas dokumentas visuomet turi versiją 0.1. Jei dokumentui pateikiamos pastabos, tai naujai jo redakcijai, parengtai po pastabų, nustatoma nauja versija, padidinant turėtą dokumento versijos antrą skaičių vienetu. Suderintam dokumentui suteikiama versija 1.0.
  • 8Jei rengiama patvirtinto dokumento nauja redakcija, kurią reikia derinti, antras skaičius keičiamas į 1, t. y., 1.1, suderintus naują dokumento redakciją.
  • 9Visi Tiekėjo pateikiami rezultatai turi būti teikiami su Užsakovu suderintu redagavimui tinkamu formatu.
  • 10Jei Tiekėjas rezultatus pateikia kitu formatu, kuriam reikalinga atskira programinė įranga, Tiekėjas yra atsakingas už reikalingos programinės įrangos modifikavimą ir įdiegimą, instruktavimus, licencijas ir visus kitus su programine įranga susijusius darbus bei kaštus.
  • 11Visi Tiekėjo rezultatai ir teikiamos paslaugos turi būti teikiami lietuvių kalba nebent su Užsakovu yra suderinamas tam tikrų rezultatų ar jų dalies rengimas kita kalba, pvz., anglų kalba.
  • 12Galutiniai rezultatai turi būti pateikti redaguojamu formatu (įskaitant ir dokumentuose pateikiamas schemas).
  • 13Pasirašius galutinį Sistemos perdavimo–priėmimo aktą, Užsakovui turi būti perduoti visi suderinti Projekto dokumentai.

SIAS pagrindinės funkcijos

  • 1SIAS turi užtikrinti gyventojų, besikreipiančių dėl socialinės paramos, asmens duomenų, taip pat duomenų apie šeimą ir jos narius įvedimą, kaupimą, saugojimą ir vaizdavimą, vadovaujantis asmens duomenų apsaugos teisės aktų reikalavimais.
  • 2SIAS turi užtikrinti prašymų–paraiškų piniginei socialinei paramai gauti registravimą, tvarkymą ir spausdinimą.
  • 3SIAS turi sudaryti galimybę šeimos arba vieno gyvenančio asmens deklaruoto turto duomenų įvedimui, vertinimui ir teisės į socialinę paramą nustatymui.
  • 4SIAS turi užtikrinti informacijos apie paskirtas socialines išmokas įvedimą bei automatinį socialinių išmokų dydžių skaičiavimą pagal nustatytus kriterijus.
  • 5SIAS turi sudaryti galimybę socialinių išmokų skyrimo sprendimų, pažymų ir kitų susijusių dokumentų formavimui ir spausdinimui.
  • 6SIAS turi užtikrinti socialinių išmokų mokėjimo dokumentų formavimą ir spausdinimą, įskaitant: žiniaraščius paštams ir kasoms, sąrašus bankams, vienkartinių kasos išlaidų orderius, pašto perlaidas.
  • 7SIAS turi leisti pervedamų sumų eksportą į finansų įstaigų informacines sistemas (bankų sąskaitas ar mokėjimo korteles), naudojant standartinius elektroninių duomenų formatus, nedetalizuojant konkrečių finansų įstaigų.
  • 8SIAS turi užtikrinti informacijos apie išmokėtas socialines išmokas kaupimą, peržiūrą, spausdinimą ir eksportą pagal naudotojo pasirinktus kriterijus.
  • 9SIAS turi sudaryti galimybę suvestinės informacijos apie gyventojams išmokėtas socialines išmokas generavimui ir spausdinimui.
  • 10SIAS turi užtikrinti šeimų (asmenų), besikreipiančių dėl patalpų šildymo, karšto ir šalto vandens išlaidų kompensavimo, prašymų registravimą ir tvarkymą.
  • 11SIAS turi sudaryti galimybę šeimos pajamų duomenų įvedimui, vidutinių šeimos pajamų apskaičiavimui, automatiškai įtraukiant išmokėtas socialines išmokas, bei šių duomenų kaupimui.
  • 12SIAS turi užtikrinti pažymų apie pajamas formavimą ir spausdinimą, skirtų būsto šildymo bei karšto ir šalto vandens išlaidų kompensacijų apskaičiavimui.
  • 13SIAS turi sudaryti galimybę gyventojų, besikreipiančių dėl kompensacijų, sąrašų formavimui ir spausdinimui pagal pasirinktus kriterijus.
  • 14SIAS turi užtikrinti šeimų, kurioms priklauso kompensacijos, vidutinių pajamų duomenų eksportą ir perdavimą kitoms kompensacijas skaičiuojančioms informacinėms sistemoms.

VPS techniniai reikalavimai

  • 1Atvirų standartų naudojimas (suderinamumas) – programinė sprendimo realizacija turi būti orientuojama į atitikimą atviriems techniniams standartams.
  • 2Interneto naršyklės: Google chrome (vėliausia versija), Mozilla FireFox (vėliausia versija), Opera (vėliausia versija), Safari (vėliausia versija), Microsoft Edge (vėliausia versija) naršyklės turi būti naudojamos kaip vienintelė VP sistemos naudotojų ir VP sistemos paslaugų gavėjų darbo vietos priemonė.
  • 3Perkančiajai organizacijai nėra priimtini tokie sprendimai, kurie skirti istorinėms (angl. legacy) sistemoms dirbtinai perkelti į Web paslaugas (tokie kaip GraphOn GoGlobal ir analogiškomis technologijomis paremti sprendimai).
  • 4XML formatas ir XML pagrįstos technologijos turi būti naudojamos duomenų mainams vykdyti.
  • 5Duomenų matomumas ir prieinamumas – duomenų matomumas ir prieinamumas VP sistemos naudotojams ir VP sistemos paslaugų gavėjams turi būti realizuotas ir užtikrintas pagal principą „Tiek kiek būtina ir kiek įmanoma mažiau“.

DVS nefunkciniai reikalavimai

  • 1Architektūra: DVS realizuota trijų lygių architektūra: duomenų bazės lygis, logikos lygis ir prezentacijos lygis. Prezentacijos lygis pateikiamas interneto naršyklėje.
  • 2DVS komponentai (tinklapis (-iai), duomenų bazė, žiniatinklio paslaugos ir kt.) privalo būti sudaryti iš atskirų funkcinių modulių. Turi būti galimybė atskirus modulius įdiegti skirtingose tarnybinėse stotyse.
  • 3DVS programų moduliai tarpusavyje integruoti – kiekvieno modulio duomenys susieti su kitų modulių duomenimis (atitinkami pakeitimai, atlikti viename modulyje, atsispindi ir kituose moduliuose).
  • 4DVS turi būti pritaikyta darbui su šiomis naudotojų darbo vietų operacinėmis sistemomis: Microsoft Windows7, Windows8, Windows10 ir su ja suderinamomis vėlesnėmis versijomis 32 ir 64 bitų aplinkose.
  • 5DVS turi būti pritaikyta dirbti su šiomis naudotojų darbo vietose naudojamomis naršyklėmis: MS Internet Explorer 11, MS Edge 44 ir vėlesnėmis versijomis, Mozilla Firefox 64 ir vėlesnėmis versijomis, Opera 57 ir vėlesnėmis versijomis, Safari 12 ir vėlesnėmis versijomis, Google Chrome 70 ir vėlesnėmis versijomis (be NPAPI papildinių).
  • 6DVS turi būti paremta HTML 5 standartu ir veikti su visomis HTML 5 palaikančiomis naršyklėmis.
  • 7Duomenų mainams tarp darbo vietos ir tarnybinių stočių turi būti naudojami šie protokolai: TCP/IP, HTTP/HTTPS.
  • 8Turi būti užtikrintas DVS veikimas HTTPS protokolu. SSL sertifikatą pateikia perkančioji organizacija.
  • 9DVS duomenys turi būti saugomi atvirojo kodo nemokamoje duomenų bazių valdymo sistemoje PostgreSQL arba lygiavertėje.
  • 10Naudotojo sąsaja: Visų DVS modulių naudotojo sąsaja turi būti viena bendra: vizualiai; navigacijos dialogai, meniu, naudotojų ekranų langai yra sudaryti naudojant vienodas taisykles.
  • 11Puslapiuose naudojami vienodi informacijos išdėstymo būdai.
  • 12Puslapyje nėra nereikalingų tuščių erdvių ir tarpų.
  • 13Puslapio elementai išdėstyti tvarkingai.
  • 14Meniu pavadinimai unikalūs ir apibendrinantys.
  • 15DVS naudotojo sąsaja naršyklėje turi būti adaptyvi (angl. responsive) priklausomai nuo įrenginio (kompiuteris, planšetinis kompiuteris, mobilus telefonas), kuriuo naudojamasi.
  • 16Greitaveikos reikalavimai: DVS turi būti užtikrintas našus ne mažesnis kaip 200 naudotojų darbas vienu metu.
  • 17Sąrašinių ataskaitų (ne istorinių) generavimo laikas, neskaitant tinklo vėlavimo (angl. latency), 90 procentų atvejų neturi viršyti 3 sek.
  • 18Sąrašinės istorinės ataskaitos, apimančios metų ir daugiau duomenis, yra suformuojamos ne ilgiau kaip per 15 sek.
  • 19Dokumentų paieška pagal dokumento metaduomenis turi būti įvykdyta per ne ilgiau nei 2 sek., o pilnatekstė paieška ne ilgiau nei 10 sek.
  • 20Dokumento kortelės atvaizdavimas turi būti įvykdytas per ne ilgiau nei 2 sek.
  • 21Dokumento registravimas turi būti įvykdytas per ne ilgiau nei 3 sek.
  • 22Augant naudotojų ir/arba apdorojamų duomenų skaičiui DVS programinė įranga neturi būti ribojantis veiksnys didinant DVS veikimo našumą. DVS našumui padidinti turi užtekti pridedamos reikalingos aparatinės įrangos, nekeičiant DVS programinės įrangos išeities tekstų.

SPS integracijų reikalavimai

  • 1SPS turi būti integruota su Dokumentų valdymo sistema. Tikslūs integracijos reikalavimai derinami diegimo metu.
  • 2SPS autentifikacija turi būti vykdoma naudojant LDAP protokolą (Active Directory). Tikslūs integracijos reikalavimai derinami diegimo metu.
  • 3SPS turi būti susieta su FVAS. Tikslūs integracijos reikalavimai derinami diegimo metu.

VPS nefunkciniai reikalavimai

  • 1Reikalavimai naudotojo sąsajai: naudotojo sąsajos turi būti parengtos laikantis bendrinės lietuvių kalbos taisyklių.
  • 2Sąsajai su naudotoju turi būti naudojamos paplitusios technologijos. Naudotojo sąsajos turi būti realizuotos remiantis Web sprendimo (angl. Web based) principais ir prieinamos standartinės interneto naršyklės terpėje.
  • 3Naudotojo sąsajos turi atitikti šiuolaikinius ergonomikos reikalavimus, nurodytus standarte LST EN ISO 9241-110:2006 „Žmogaus ir sistemos sąveikos ergonomika. 110 dalis. Dialogo principai (ISO 9241-110:2006)“.
  • 4Naudotojo sąsajos valdymas turi remtis pelės ir klaviatūros įrenginiais.
  • 5Naudotojo sąsajos turi būti personalizuotos, priklausomai nuo naudotojo tipo ir prieigos teisių. Naudotojo darbui nereikalingas arba neleistinas funkcionalumas neturi būti matomas. Naudotojui turi būti pateikiamos jam aktualiausios funkcijos, jam atsiųstos žinutės ar užduotys.
  • 6Naudotojo sąsajos klaidų pranešimai turi būti suformuluoti taip, kad naudotojui būtų aišku, kas atsitiko ir kokius veiksmus jam toliau reikia daryti, kad galėtų tęsti darbą.
  • 7Reikalavimai naudotojų valdymui ir autentifikavimui/autorizavimui: Naudotojai prie VPS jungiasi naudodami suteiktus prisijungimo duomenis (vartotojo vardas/slaptažodis) arba Active Directory kataloge saugomus naudotojų autentifikavimo duomenis. Naudotojas autentifikavęsis MS Active Directory turi būti automatiškai autorizuotas dirbti VPS modulyje pagal jo turimas teises.
  • 8Jei pasikeičia vartotojo AD atributai, atnaujinta informacija turi būti automatiškai importuojama į VPS.
  • 9Turi būti realizuota galimybė importuoti naudotojus iš kitų šaltinių (pvz. LDAP ir kt., suderinama diegimo metu).
  • 10Turi būti realizuotas naudojimo patogumą užtikrinantis funkcionalumas: TAB klavišo seka einant per įvedimo laukus.
  • 11Pateikiamos užuominos ir paaiškinimai pelės žymeklį užvedus ant objekto.
  • 12Langų/objektų išdėstymas turi atitikti naudotojų veiklos seką.
  • 13Kitos naudotojo patogumą užtikrinančios priemonės gali būti nustatytos ir suderintos projekto diegimo metu.
  • 14Meniu nuorodų pavadinimai ir grupavimas turi būti visiems aiškūs.
  • 15Naudotojams turi būti galimybė pritaikyti naudotojo sąsają pagal savo pageidavimus ir darbo pobūdį.
  • 16Naudotojo sąsaja turi remtis standartiniais komponentais, palaikančiais visas populiarias naršykles šiuo metu ir perspektyvoje.
  • 17VPS greitaveikos reikalavimai: prisijungimas ir darbas prie VPS turi būti interneto naršyklės pagalba.
  • 18Subjektyviam IS greitaveikos suvokimui IS reakcija turi būti nedelsiama.
  • 19Realus reakcijos laikas, neskaitant tinklo vėlavimo (angl. latency) neturi viršyti 3 sekundžių pereinant nuo vieno puslapio rodymo prie kito.
  • 20Atskiri puslapio elementai turi būti pakeičiami greičiau negu per 0,5 sekundės.
  • 21Jeigu vykdomas ilgiau trunkantis procesas, ekrane būtina indikuoti tokio proceso eigą dėmesio neblaškančiu būdu.
  • 22Vartotojas turi turėti galimybę pereiti į kitą puslapį proceso vykdymo metu, tačiau procesas turi tęstis.
  • 23Saugumo reikalavimai: Pagrindiniai saugumo reikalavimai: visi VPS naudotojai turi būti identifikuoti ir jų identifikaciją turi būti įmanoma patikrinti.
  • 24Neautorizuoti bandymai įsiveržti turi būti aptinkami.
  • 25Neautorizuotos piktybinės programos (virusai ir pan.) negali turėti galimybės užkrėsti aplikacijos ar jos komponentų.
  • 26Duomenų perdavimas ir saugomi duomenys turi būti apsaugoti nuo sąmoningo iškraipymo.
  • 27Konfidencialūs duomenys ir duomenų mainai turi išsaugoti veiksmų privatumą.
  • 28Kontroliuoti, kad VPS priežiūros veiksmai netyčia nesugadintų aplikacijos ar komponentų saugos mechanizmų.
  • 29Visi asmens duomenų keitimai turi būti registruojami, įrašant pakeistas reikšmes, keitimo laiką.
  • 30Kiti saugumo reikalavimai: VPS naudotojas turi pateikti prisijungimo informaciją tik vieną kartą.

SIAS integracijų reikalavimai

  • 1Sprendimas turi turėti integracinę sąsają įgyvendintą REST API principu ir jau būti susietas su SIAS.
  • 2Paslauga turi turėti integracinės sąsajos dokumentaciją su integravimo pavyzdžiais, scenarijais ir aprašymais.
  • 3Turi būti galimybė inicijuoti pasirašymą per integracinę API sąsają nenaudojant naudotojo sąsajos, nurodant kuriame įrenginyje reikalingas konkretaus šablono pasirašymas.
  • 4Turi būti galimybė po pasirašymo automatizuotomis priemonėmis gauti pasirašymo būseną.
  • 5Turi būti galimybė inicijuojant pasirašymą nurodyti dokumento šablono versiją.
  • 6Turi būti galimybė gauti užpildytus dokumentų šablono duomenis per integracinę sąsają.
  • 7SIAS turi turėti integraciją su Socialinės paramos šeimai informacine sistema (SPIS).

DVS administravimo reikalavimai

  • 1Visos Sistemos administravimo galimybės turi būti pasiekiamos per internetinės naršyklės sąsają.
  • 2DVS turi būti realizuota galimybė bylas ir registrus administruoti padalinių lygmeniu.
  • 3DVS turi būti realizuota galimybė administratoriui kurti naudotojus, naudotojų grupes, roles.
  • 4DVS turi būti realizuota galimybė administratoriui priskirti naudotojus naudotojų grupėms.
  • 5DVS turi būti realizuota galimybė redaguoti dokumentų kortelių registrų formas.
  • 6DVS turi būti realizuota galimybė redaguoti dokumentų sąrašų išplėstinių paieškų formas.
  • 7DVS turi būti galimybė nukopijuoti (klonuoti) naudotoją su prieigos teisių nustatymais.
  • 8DVS turi būti realizuota galimybė administratoriui riboti/leisti prieigą prie nurodytų dokumentų nurodytiems naudotojams.
  • 9DVS turi būti realizuota galimybė administratoriui, kitam atsakingam asmeniui (pagal teises) siųsti elektroninį laišką visiems sistemos naudotojams (darbuotojams) vienu metu.
  • 10DVS turi būti realizuota galimybė naudotoją priskirti daugiau nei vienai grupei.
  • 11DVS administratoriui, kitam atsakingam asmeniui (pagal teises) turi būti galimybė peržiūrėti ir eksportuoti naudotojų ir naudotojų teisių sąrašus į XLSX ir PDF formatus.
  • 12DVS turi būti galimybe peržiūrėti einamuoju momentų prisijungusius prie sistemos naudotojus.
  • 13Turi būti galimybė peržiūrėti visų sistemos siunčiamų el. laiškų sąrašą.
  • 14Sistemos siunčiamų el. laiškų sąraše turi būti galimybė matyti šiuos duomenis: Būseną (išsiųsta, neišsiųsta); Klaidos pranešimą (neišsiuntimo atveju); Siuntėją; Gavėją; Antraštę; Failus.
  • 15Turi būti galimybė peržiūrėti sistemos siunčiamo el. laiško turinį.

Duomenų migravimo reikalavimai

  • 1Projekto metu turi būti užtikrintas duomenų migravimas iš esamų informacinių sistemų, numatant visų reikalingų klasifikatorių, likučių ir kitos reikalingos informacijos migravimą.
  • 2Detalūs migruojami duomenys turės būti tikslinamas ir suderinamas su Užsakovu.
  • 3Tiekėjas yra atsakingas už duomenų migravimo šablonų parengimą, paruošimą ir suderinimą su Užsakovu.
  • 4Užsakovas atsakingas už visų duomenų pateikimą suderintu būdu.
  • 5Tiekėjas yra atsakingas už paruoštų migravimo dokumentų (šablonų) importavimą į VVS bei, jei importo metu yra aptinkamos duomenų parametrizavimo klaidos, už klaidų identifikavimą ir pateikimą Užsakovui.
  • 6Turi būti atliktas visų tinkamam Sistemos veikimui užtikrinti reikalingų duomenų migravimas.

Sistemos palaikymo reikalavimai

  • 1Sistema turi veikti patikimai, atitikti informacinių technologijų saugumo reikalavimus ir būti atstatoma įvykus sutrikimui.
  • 2Visi Tiekėjo veiksmai, susiję su Sistemos palaikymo paslauga, turi būti vykdomi pagal suderintas su Užsakovu procedūras.
  • 3Sistemos palaikymo paslauga turi būti teikiama Užsakovo darbo valandomis (pirmadienį 8.00–17.30 val., nuo antradienio iki ketvirtadienio 8.00–17.00 val., penktadienį 8.00–15.45 val., pietų pertrauka kiekvieną darbo dieną 12.00–12.45 val.).
  • 4Šalių rašytiniu susitarimu, Sistemos palaikymo paslaugos gali būti teikiamos Užsakovo nedarbo metu.
  • 5Visi palaikymo paslaugų veiksmai turi būti fiksuojami incidentų valdymo informacinėje sistemoje.
  • 6Konsultacijos turi būti teikiamos elektroniniu paštu bei telefonu darbo dienomis 08.00 val. iki 17.00 val.
  • 7Konsultacijų metu Tiekėjas gali prisijungti prie pirkėjo kompiuterių ar duomenų bazės ir patikrinti vykdomas operacijas ar jų teisingumą.
  • 8Labai svarbaus incidento atveju analizė ir/arba problemos šalinimas turi būti atliktas ne vėliau kaip per 8 darbo valandas.
  • 9Vidutiniškai svarbaus incidento atveju analizė ir/arba problemos šalinimas turi būti atliktas ne vėliau kaip per 5 darbo dienas.
  • 10Kitais atvejais analizė ir/arba problemos šalinimas turi būti atliktas ne vėliau kaip per 10 darbo dienų.
  • 11Bet kokie pakeitimai gamybinėje aplinkoje, įskaitant klaidų ištaisymą, gali būti diegiami tik gavus Užsakovo leidimą.

DVS klasifikatorių reikalavimai

  • 1DVS turi būti klasifikatoriams tvarkyti reikalingos priemonės.
  • 2DVS turi būti galimybė pildyti struktūrinių padalinių klasifikatorių.
  • 3DVS turi būti galimybė pildyti įstaigų klasifikatorių.
  • 4DVS turi būti galimybė pildyti fizinių asmenų klasifikatorių.
  • 5DVS turi būti galimybė pildyti darbuotojų klasifikatorių.
  • 6DVS turi būti galimybė pildyti svečių klasifikatorių.
  • 7DVS turi būti galimybė pildyti registrų klasifikatorių.
  • 8DVS turi būti galimybė pildyti gautų ir siunčiamų dokumentų gavimo/siuntimo būdų klasifikatorių.
  • 9DVS turi būti galimybė pildyti gautų ir siunčiamų dokumentų paskirčių klasifikatorių.
  • 10DVS turi būti galimybė pildyti gautų ir siunčiamų dokumentų rūšių klasifikatorių.
  • 11DVS turi būti galimybė pildyti gautų ir siunčiamų dokumentų turinių klasifikatorių.
  • 12DVS turi būti galimybė pildyti gautų ir siunčiamų dokumentų siuntimo būdų klasifikatorių.
  • 13DVS turi būti galimybė pildyti bylų veiklų klasifikatorių.
  • 14DVS turi būti galimybė pildyti dokumentų ruošinių klasifikatorių.
  • 15DVS turi būti galimybė pildyti darbų sekų šablonų tipų klasifikatorių.
  • 16DVS turi būti galimybė pildyti žymelių tipų klasifikatorių.
  • 17DVS turi būti galimybė pildyti pavedimų tipų klasifikatorių.
  • 18DVS turi būti galimybė pildyti piliečių laiškų atsakymų klasifikatorių.
  • 19DVS turi būti galimybė pildyti piliečių laiškų turinių klasifikatorių.
  • 20DVS turi būti galimybė pildyti piliečių socialinių grupių klasifikatorių.
  • 21DVS turi būti galimybė pildyti vietovių klasifikatorių.
  • 22DVS turi būti galimybė pildyti protokolų etapų klasifikatorių.
  • 23DVS turi būti galimybė pildyti protokolų tipų klasifikatorių.
  • 24DVS turi būti galimybė pildyti rezoliucijos veiklos tipų klasifikatorių.
  • 25DVS turi būti galimybė pildyti rezoliucijų veiksmų klasifikatorių.
  • 26DVS turi būti galimybė pildyti sutarčių šalių tipų klasifikatorių.
  • 27DVS turi būti galimybė pildyti sutarties etapų klasifikatorių.
  • 28DVS turi būti galimybė pildyti sutarties tipų klasifikatorių.
  • 29DVS turi būti galimybė pildyti valiutų tipų klasifikatorių.
  • 30DVS turi būti galimybė pildyti teisės aktų etapų klasifikatorių.
  • 31DVS turi būti galimybė pildyti teisės aktų rūšių klasifikatorių.
  • 32DVS turi būti galimybė pildyti vidaus dokumentų grupių klasifikatorių.
  • 33DVS turi būti galimybė pildyti vidaus dokumentų tipų klasifikatorių.
  • 34DVS klasifikatorių įrašų sąrašas neturi būti ribojamas.
  • 35DVS sistemos administratoriui įvedant paprasti klasifikatoriaus įrašo reikšmes turi būti galimybė nurodyti: Kodą; Pavadinimą.
  • 36DVS sistemos administratoriui įvedant hierarchinio klasifikatoriaus įrašo reikšmes turi būti galimybė nurodyti: Kodą; Pavadinimą; Tėvinę šaką.
  • 37Turi būti priemonės administratoriui sukurti neribotą kiekį papildomų klasifikatorių.
  • 38DVS turi būti galimybė sukurti hierarchinio tipo klasifikatorius.
  • 39DVS administratoriui sukuriant klasifikatorių turi būti galimybė nurodyti: Pavadinimą; Aprašymą.
  • 40DVS administratoriui turi būti galimybė pildyti, koreguoti iš šalinti administratoriaus sukurtus klasifikatorius.

DVS pavedimų valdymo reikalavimai

  • 1DVS turi būti pavedimų sukūrimo ir tvarkymo funkcija.
  • 2DVS pavedime turi būti įvedama ši informacija: turinys; teikėjas (darbuotojas, kuris teikia pavedimą); kuratorius (darbuotojas, kontroliuojantis pavedimo vykdymą); atsakingas vykdytojas (-ai) (darbuotojas (-ai), atsakingas už pavedimo įvykdymą); failai, įkelti iš duomenų laikmenų ir (arba) skenuoti dokumentų atvaizdai.
  • 3Jei pavedimo vykdytojas DVS neturi reikiamų teisių į dokumentą, su kuriuo susijusi sukurta pavedimas, sistema turi automatiškai suteikti pavedimo vykdytojui trūkstamas teises.
  • 4DVS turi būti galimybė suformuoti pavedimą ne DVS naudotojui ir informuoti vykdytoją (ne DVS naudotoją) nurodytu el. paštu, pateikti jam susietus dokumentus ir leisti pavedimo kuratoriui įvesti užduoties įvykdymo būseną.
  • 5Tarpinės kontrolės datų ir rezultatų kiekis neturi būti ribojamas.
  • 6Turi būti galimybė įvesti pavedimo tarpinius rezultatus.
  • 7DVS turi būti realizuota galimybė informuoti vykdytoją elektroniniu paštu apie artėjančią pavedimo tarpinės kontrolės datą, jei prie jos neįvesti rezultatai.
  • 8DVS turi būti realizuota galimybė kuriamą pavedimą susieti su sistemoje užregistruotu dokumentu.
  • 9DVS realizuota galimybė elektroniniu paštu informuoti atsakingą vykdytoją, kitus vykdytojus, kuratorių apie pavedimo sukūrimą.
  • 10DVS turi būti realizuota galimybė el. paštu informuoti vykdytoją pasibaigusį pavedimo įvykdymo terminą.
  • 11DVS turi būti realizuota galimybė vykdytojui registruoti pavedimo įvykdymo duomenis.
  • 12DVS pavedimo įvykdymo registravimo funkcija turi leisti išsaugoti šiuos duomenis: įvykdymo rezultato aprašymą (pastabą); įvykdymo datą; failus, įvestus iš išorinių kompiuterinėse duomenų laikmenų.
  • 13DVS numatyta pavedimo įvykdymo patvirtinimo funkcija.
  • 14DVS turi būti realizuota galimybė peržiūrėti pavedimus pagal: būseną; kontroliuojantį asmenį; atsakingą vykdytoją; padalinį; įvykdymo terminą.
  • 15Turi būti galimybė koreguoti pavedimo įvykdymo terminą (pratęsti, anuliuoti).
  • 16Turi būti galimybė informuoti pavedimą kuruojantį asmenį apie klaidingą pavedimo sukūrimą.
  • 17DVS turi būti realizuota galimybė peržiūrėti tik konkrečiam naudotojui skirtus ar jo inicijuotus pavedimus.
  • 18DVS turi būti realizuota galimybė kurti pavedimus nesusietas su registruotu DVS dokumentu.

DVS savitarnos dalies reikalavimai

  • 1Savitarnos portalo pradinis naudotojo langas turi būti parengtas taip, kad kiekvienam naudotojui būtų pateikiama suasmeninta, t. y. konkrečiai jam aktuali, informacija.
  • 2DVS turi būti realizuota galimybė naudotojui nusirodyti, kokia informacija bus rodoma jo pradiniame lange ir keisti šios informacijos išdėstymą.
  • 3DVS turi būti realizuota galimybė iš kiekvieno sąrašo, prie kurio pagal priskirtas teises prieina naudotojas, sukurti sąrašo tipo darbalaukio valdiklį (angl. widget).
  • 4DVS turi būti realizuota galimybė naudotojui susikurti neribotą kiekį pradinio lango darbalaukių ir kiekviename iš jų prisidėti skirtingų tipų fius.
  • 5DVS turi būti realizuota galimybė naudotojui darbalaukyje prisidėti šių tipų valdiklius: Laikas; Užrašai; Nuorodos (Teikiamų dokumentų nuorodos; Laisvai įvedamos nuorodas); Naujienos; Orai; Sąrašas (Gautų dokumentų sąrašas; Teikiamų dokumentų sąrašas).
  • 6Naudotojų pradiniame lange turi būti galimybė talpinti informaciją bent į ne mažiau kaip du tarpusavyje atskirus blokus, t. y. keisti išdėstymo schemą.
  • 7Savitarnos portale turi būti realizuota galimybė naudotojui pateikti iš anksto sukonfigūruotus įvairius dokumentus užpildant dokumentų formas.
  • 8Turi būti galimybė savitarnos portalo teikiamo dokumento formą automatizuotai užpildyti DVS suvestais duomenimis (pvz. įmonė, padalinys, vardas, pavardė, pareigos), kurie reikalingi dokumento pateikimui. Automatizuotai užpildyti duomenys iš DVS negali būti keičiami.
  • 9Savitarnos portalo teikimo dokumento formos duomenys turi būti įrašyti į iš anksto nurodytą formą.
  • 10Turi būti galimybė naudotojui tiesiogiai naršyklėje lange (neatidarant specialių dokumentų redagavimui ar peržiūrai skirtų programų) peržiūrėti ir atsiųsti užpildytą duomenis teikiamo dokumento formą.
  • 11Turi būti galimybė pateikti užpildytą dokumento formą tolimesniam apdorojimui.
  • 12Turi būti galimybė peržiūrėti visų teikiamų dokumentų sąrašą.
  • 13Teikiamų dokumentų sąraše turi būti paieška pagal: sukūrimo datą nuo/iki; pateikimo datą nuo/iki; tipą; būseną.
  • 14Turi būti realizuotos šios teikiamų dokumentų būsenos: Nepateikta; Pateikta, laukiama sprendimo; Pateiktas ir patvirtintas; Pateiktas, tačiau atmestas; Pateiktas, tačiau atšauktas.
  • 15Savitarnos portalo naudotojui turi būti galimybė atšaukti pateikto prašymo apdorojimą.
  • 16Savitarnos portalo naudotojui turi būti galimybė matyti darbuotoją, kurio sprendimo laukiama.
  • 17Iš DVS į savitarnos portalą turi būti galimybė pateikti dokumentą susipažinimui.
  • 18Iš DVS pagal darbų sekos veiksmus turi būti galimybė perduoti dokumentą vykdymui į savitarnos portalą.
  • 19Turi būti galimybė peržiūrėti gautų dokumentų sąrašą.
  • 20Gautų dokumentų sąraše turi būti paieška pagal: Būseną; Antraštę; Gavimo datą nuo/iki; Failo turinį.
  • 21Savitarnos portale turi būti galimybė susipažinti su dokumentu.
  • 22Savitarnos portale turi būti galimybė priimti darbų sekos sprendimą.
  • 23Savitarnos portale turi būti galimybė pildyti ir pateikti naujo darbuotojo formą, kurios duomenys.
  • 24Savitarnos portalo naujo darbuotojo formos duomenys (po pateikimo) turi būti įrašyti į iš anksto nurodytą formą ir nukreipti apdorojimui.
  • 25Savitarnos portalas turi siųsti el. laišką dokumento teikėjui apie patvirtintą ir atmestą pateiktą dokumentą.
  • 26Savitarnos portale turi būti galimybė pateikti naujo darbuotojo priėmimo dokumentus, kurie užpildyti pateiktos ir patvintos formos duomenimis.

DVS modulis Raštinės reikalavimai

  • 1DVS modulis Raštinės (toliau – modulis) turi užtikrinti galimybę Raštinei dirbti autonomiškai su DVS, pilnavertiškai naudotis visomis DVS funkcionalumo galimybėmis.
  • 2DVS turi veikti naudojant populiariausias naršykles: Internet Explorer 11, Mozilla Firefox, Google Chrome, Opera, Safari.
  • 3DVS naudotojo sąsaja turi būti prisitaikanti ekrano dydžiui, galima dirbti su įvairių dydžių monitoriais ir planšetiniais kompiuteriais.
  • 4DVS visi veiksmai su dokumentais turi būti registruojami ir rodomi veiksmų istorijoje.
  • 5DVS turi būti realizuota galimybė pasirašyti dokumentus elektroniniu būdu pagal Lietuvos Respublikos elektroninio parašo įstatymo reikalavimus ir kitų Lietuvos Respublikos teisės aktų reikalavimus, identifikuoti parašus ir juos atpažinti.
  • 6DVS turi būti funkcijos tvarkyti elektroninius dokumentus, užtikrinant jų apsikeitimą su kitomis Lietuvos organizacijomis: priimti ir registruoti elektroniniu parašu pasirašytus dokumentus, siųsti parengtus ir užregistruotus elektroninius dokumentus adresatams, nenaudojant papildomos programinės įrangos.
  • 7DVS turi leisti pasirašyti dokumentus naudojant valstybės tarnautojo pažymėjimą, asmens tapatybės kortelę, saugius USB įrenginius su sertifikatais, mobilų parašą.
  • 8DVS turi būti realizuotas elektroninio parašo tikrinimo funkcionalumas.
  • 9Į DVS įkeliant elektroninį dokumentą, dokumento kortelė turi būti automatiškai užpildoma metaduomenimis, esančiais įkeliamo elektroninio dokumento pakuotėje.
  • 10Elektroniniai dokumentai registre turi būti žymimi simboliu, leidžiančiu atskirti elektroninius dokumentus.
  • 11Elektroniniai dokumentai, kaip ir popieriniai dokumentai, turi būti apskaitomi DVS registruose.
  • 12Rengiamųjų dokumentų modulis turi būti pritaikytas darbui su elektroniniais dokumentais.
  • 13DVS turi būti galimybė užregistruoti siunčiamą dokumentą bei išsiųsti jį elektroniniu paštu, išsiuntimą automatiškai fiksuojant dokumentų veiksmų istorijoje.
  • 14DVS turi būti galimybė nukreipti gautus arba vidaus registruotus dokumentus vykdytojams. Neturi būti ribojamas nukreipimų skaičius. DVS automatiškai turi informuoti elektroniniu paštu paskirtą vykdytoją apie perduotą jam dokumentą.
  • 15DVS turi suteikti priemones, kurios leistų užtikrinti dokumentų, užduočių ir pavedimų vykdymo kontrolę.
  • 16Turi būti realizuota sistemoje registruotų dokumentų paieškos galimybė pagal datą, numerį, pavadinimo fragmentą, dokumento teksto fragmentą.
  • 17DVS turi būti naudojamas vedlio principas kuriant įrašus, kuriems reikalingas didesnis dokumentų įvedimas. Tokiu principu sistemos naudotojas žingsnis po žingsnio bus vedamas į galutinį tikslą – išsaugoti galutinius duomenis. Vedlys turi padėti išvengti pakartotinio ir dubliuojamo informacijos įvedimo.
  • 18DVS turi būti įgyvendinta kontekstinė pagalba, kuri neleis naudotojui pasimesti, jei pamirštamos tam tikros reikšmės.
  • 19DVS turi būti sutarčių filtravimas bei kontrolė. Per nustatytą sistemoje laiko tarpą, elektroniniu paštu, turi būti siunčiami priminimai vykdytojams apie termino pabaigą.
  • 20Turi būti realizuota integracija su Elektroninių pranešimų ir dokumentų pristatymo fiziniams ir juridiniams asmenims informacine sistema (E. pristatymas).
  • 21Naudojantis DVS, Raštinėje turi būti kompiuterizuoti dokumentų rengimo, registravimo, saugojimo, paieškos, pateikimo ir valdymo procesai.
  • 22Modulio funkcionalumas Raštinėms turi suteikti galimybę automatizuotai keistis dokumentais ir užduotimis tarp kitų Raštinių.
  • 23Modulis turi užtikrinti dokumentų ir informacijos valdymo procesų konfidencialumą ir tvarkomų duomenų saugumą. Raštinių duomenys saugomi centralizuotai.

Integracinių sąsajų reikalavimai

  • 1Duomenų mainai turi būti vykdomi naudojant žiniatinklio paslaugas ar lygiavertes technologijas, SOAP, HTTP (RESTfull) ar lygiavertį protokolą.
  • 2Esant objektyvioms priežastims (pvz., neegzistuoja išorinės Sistemos žiniatinklio sąsaja), galimos išimtys.
  • 3Tiekėjas turi suderinti duomenų mainams naudojamas technologijas ir protokolą.
  • 4Tiekėjas turi atsižvelgti į patvirtintą Informacinės visuomenės plėtros komiteto prie Susisiekimo ministerijos direktoriaus 2013 m. kovo 25 d. įsakymą Nr. T-36 „Dėl duomenų teikimo formatų ir standartų rekomendacijų patvirtinimo“.
  • 5Tuo atveju kai per integracinę sąsają yra gaunama daugiau duomenų nei yra reikalinga VVS, pertekliniai duomenys neturi būti įrašomi į VVS duomenų bazę.
  • 6Turi būti galimybė užtikrinti, jog duomenys gauti integracijos būdu nebūtų keičiami, nebent tokios teisės numatytos Sistemos administratoriui.
  • 7Turi būti realizuotos integracijos tarp Strateginio planavimo, biudžeto sudarymo ir vertinimo kriterijų informacinė sistemos ir Finansų valdymo sistemos.
  • 8Turi būti realizuotos integracijos tarp Strateginio planavimo, biudžeto sudarymo ir vertinimo kriterijų informacinė sistemos ir Dokumentų valdymo sistemos.
  • 9Turi būti realizuotos integracijos tarp Dokumentų valdymo sistemos ir Sąskaitų administravimo bendrosios informacinės sistemos SABIS.
  • 10Turi būti realizuotos integracijos tarp Dokumentų valdymo sistemos ir Viešųjų pirkimų valdymo sistemos.
  • 11Turi būti realizuotos integracijos tarp Socialinių išmokų apskaitos sistemos ir Socialinės paramos šeimai informacinės sistemos SPIS.

Konsultavimo paslaugų reikalavimai

  • 1VVS naudotojų konsultavimo paslaugos teikiamos VVS naudotojams (apie 200 naudotojų).
  • 2Teikėjas per 30 dienų nuo Sutarties įsigaliojimo dienos turi parengti konsultavimo standartą. Konsultavimo paslaugos teikiamos pagal su Perkančiąja organizacija suderintą konsultavimo standartą.
  • 3Konsultavimas vykdomas el. paštu, telefonu, konsultavimo sistemoje.
  • 4Konsultacijoms telefonu skirtą infrastruktūrą užtikrins Teikėjas.
  • 5Teikėjas privalo užtikrinti mažiausiai 2 konsultantus, Teikėjas įvertina ir užtikrina pagal sezoniškumą ir skambučių srautą, jei reikia daugiau konsultantų.
  • 6Skambučiai turi būti įrašomi ir Užsakovui paprašius, suteikiama prieiga prie įrašų.
  • 7Konsultacijos teikiamos lietuvių, anglų kalbomis ir bent viena kita kalba (lenkų, rusų, ukrainiečių).
  • 8Nepavykstant prisiskambinti, skambutis turi būti registruojamas ir interesantui perskambinama per 4 darbo val. nuo skambučio gavimo, apie skambučio registracija naudotojas turi būti informuojamas balso žinute.
  • 9Skambutis gali būti iki 5 min. užlaikomas kol linija atsilaisvins.
  • 10Visi skambučiai turi būti registruojami konsultavimo sistemoje.
  • 11Teikėjas turės klasifikuoti suteikiamas konsultacijas telefonu ir raštu pagal konsultacijos temas, klasifikatorius turės būti suderintas per pirmą paslaugų teikimo mėnesį.
  • 12Klasifikatorius galės būti pildomas ar atnaujinamas bet kuriuo Paslaugų teikimo laikotarpiu.
  • 13Konsultacijos telefonu teikiamos kiekvieną darbo dieną nuo 8:00 iki 17:00 valandos. Skambučiai priimami iki 16:00, laikotarpis nuo 16:00 iki 17:00 valandos skiriamas neatsakytų skambučių įvykdymui.
  • 14Teikiant konsultacijas telefonu 95 proc. skambučių turi būti aptarnauti tą pačią dieną.
  • 1595 proc. skambučių, kurių metu linija buvo užimta, turi būti perskambinta per 4 darbo val. nuo skambučio registravimo.
  • 16Užklausos turi būti atsakomos per 8 darbo val.
  • 17Nustatytais terminai turi būti atsakoma 90 proc. užklausų per mėnesį.
  • 18Perkančiosios organizacijos prašymu, Teikėjas turės pateikti konsultavimo paslaugų ataskaitą ir/ arba konsultacijų telefono numerio operatoriaus patvirtintą skambučių išklotinę.
  • 19Perkančiosios organizacija bet kuriuo laiku galės atlikti ataskaitoje pateiktų duomenų auditą.

VPS papildomi procesai (ataskaitos)

  • 1VPS turi būti galimybė generuoti Viešųjų pirkimų tarnybai teikiamas (pirkimo procedūrų, sutarčių įvykdymo (AT – 8), metinės ataskaitos (AT – 6) ir kt.) ataskaitas.
  • 2VPS turi būti galimybė generuoti analitines ataskaitas apie planuojamus, inicijuotus, vykdomus, pabaigtus pirkimus ir pirkimų sutartis įvairiais pjūviais. VPS turi būti įgyvendintos galimybės Užsakovui pačiam kurti analitines ataskaitas iš modulyje kaupiamų duomenų.

SIAS informacijos saugos reikalavimai

  • 1Komunikacija tarp atskirų SIAS komponentų ir išorinių sistemų atliekama naudojant apsaugotą ir šifruotą komunikacijos kanalą.
  • 2Išorinės integruojamos sistemos autentifikuojamos pagal unikalų suteiktą prieigos raktą.
  • 3Parašo biometriniai duomenys turi būti šifruojami ne žemesniu nei 128-bit saugumo lygiu, atitikti aktualias ENISA arba NIST raktų ilgumo ir saugumo rekomendacijas.
  • 4Teisinių ginčų atveju, paslaugos Vykdytojas bendradarbiaudamas su Užsakovu, neatlygintai turi atšifruoti parašo duomenis.
  • 5SIAS turi būti užtikrinama, kad Užsakovo duomenys (data at rest), jų perdavimas (data in transit) yra šifruojami, parenkant naujausias NIST, EISA ar BSI organizacijų rekomendacijas atitinkančius šifravimo algoritmus, šifravimo raktų ilgius.
  • 6Vykdytojas privalo užtikrinti, kad visą SIAS veikimui reikalinga aparatinė ir programinė įranga, įskaitant licencijas, programinį kodą, saugos (šifravimo) raktus ir kt., yra valdoma ir kontroliuojama, užtikrinant, kad Sistemos kūrimui, palaikymui ir vystymui būtų naudojama tik leistina ir licencijuota aparatinė ir programinė įranga.
  • 7Jei to reikia SIAS veikimui, kūrimui ir palaikymui, Vykdytojas ir (arba) kitos Šalys, veikiantys kaip duomenų tvarkytojai ir tvarkantys Užsakovo asmens duomenis, turi įgyvendinti technines ir organizacines priemones, kad apsaugotų Užsakovo duomenis pagal BDAR reikalavimus, užtikrinant, be kita ko, atitikimą pritaikytosios duomenų apsaugos (data protection by design) ir standartizuotosios duomenų apsaugos (data protection by default) (BDAR 25 str.) įskaitant, bet neapsiribojant saugojimo terminų nustatymą, asmens duomenų anonimizavimą ar trynimą automatizuotomis priemonėmis.
  • 8Vykdytojui teikiant paslaugas turi būti įgyvendintos organizacinės ir techninės saugumo valdymo priemonės, atitinkančios ISO27000 šeimos arba lygiaverčių standartų reikalavimus.
  • 9Visų užpildytų ir pasirašytų dokumentu autentiškumas turi būti užtikrinamas pasirašant juos skaitmeniniu spaudu paženklintu kvalifikuota laiko žyma.

DVS informacijos apsaugos reikalavimai

  • 1Turi būti realizuotas paprastas autentikavimo prie DVS mechanizmas (naudotojo vardas/slaptažodis).
  • 2DVS įgyvendintos priemonės, užtikrinančios, kad DVS naudotojas galėtų vykdyti tik tas DVS funkcijas ir matytų tik tuos duomenis, prie kurių numato prieigą jam priskirtos teisės.
  • 3DVS naudotojas, kuris neturi prieigos prie dokumento teisių, turi nematyti nei to dokumento, nei dokumento aprašo, kuriame surašyti dokumento registracijos atributai.
  • 4DVS turi būti realizuotas automatinis naudotojų darbo seanso nutraukimas ir pakartotinės registracijos reikalavimas naudotojui nustatytą laiką aktyviai nesinaudojant sistema.
  • 5DVS turi būti priemonių slaptažodžio sudėtingumui nustatyti (simbolių skaičius, didžiosios/mažosios raidės, skaitmenų skaičius, galiojimo terminas).
  • 6Naujiems DVS naudotojams turi būti suteikiamas vienkartinis slaptažodis, kurį pirmojo prisijungimo metu naudotojas turėtų pasikeisti.
  • 7DVS turi būti galimybė valdyti paskutinių naudotojo slaptažodžių istoriją. Sistemoje turi būti galimybė neleisti naudoti prieš tai buvusių slaptažodžių. Neleidžiamų naudoti slaptažodžių skaičius yra apibrėžtas parametru. Turi būti galimybė keisti parametro reikšmę.
  • 8DVS turi būti galimybė nustatyti naudotojo neteisingų prisijungimų skaičių, po kurio naudotojo prisijungimo vardas būtų blokuojamas. Prisijungimų skaičius yra apibrėžtas parametru. Turi būti galimybė keisti parametro reikšmę. Turi būti galimybė administratoriui atblokuoti naudotoją rankiniu būdu.
  • 9DVS turi būti galimybė nustatyti naudotojo neteisingų prisijungimų skaičių, po kurio sekančio prisijungimo metu papildomai reikalinga įvesti apsaugos kodą (angl. recaptcha). Prisijungimų skaičius yra apibrėžtas parametru. Turi būti galimybė keisti parametro reikšmę.
  • 10DVS turi būti realizuotas prieigos teisių paveldėjimo mechanizmas, leidžiantis naudotojams automatiškai paveldėti kitų naudotojų ar organizacijos struktūros elementų (įstaigos, skyrių) prieigos teises.
  • 11DVS prieigos teisių paveldėjimo mechanizmas turi leisti įtraukti naujus (papildomus) prieigos teisių įrašus, paliekant ir nekeičiant žemiau esančių lygmenų prieigos teisių nustatymų.
  • 12DVS turi būti realizuota išmaniesiems telefonams (angl. smart phones) pritaikytos DVS kliento aplikacijas (angl. app), veikiančios išmaniuosiuose telefonuose. DVS klientų aplikacijos turi būti skirtos Android ir iOS operacinėms sistemoms.
  • 13DVS mobilios kliento aplikacijos turi būti publikuojamos ir pasiekiamos iš oficialių „Google Play“ ir „Apple AppStore“ talpyklų (parduotuvių).
  • 14DVS mobilių aplikacijų vartotojo terpė turi būti specialiai pritaikyta ir optimizuota mobiliajam telefonui (ekrano dydis, valdymas pirštu ir t.t.). Išmaniųjų telefonų interneto naršyklės nėra laikomos DVS klientų aplikacijomis.
  • 15DVS mobilioje aplikacijoje turi būti galimybė peržiūrėti naudotojui nukreiptų dokumentų ir užduočių (pavedimų) sąrašą.
  • 16DVS kliento aplikacijoje turi būti galimybę peržiūrėti pagrindinius dokumento, užduoties (pavedimo) rekvizitus ir prie dokumento, užduoties (pavedimo) pridėtus failus. Turi būti galimybė atsisiųsti pridėtus failus.
  • 17DVS kliento aplikacijoje turi būti galimybė susipažinti su pateiktu dokumentu.
  • 18DVS kliento aplikacijoje turi būti galimybė priimti darbų sekos veiksmų (vizavimas, tvirtinimas, pasirašymas) - sprendimą (pritarta, atmesta).

DVS integracija su MS Active Directory

  • 1DVS turi būti integruotas su organizacijos naudojamu MS Active Directory katalogu, naudojant LDAP protokolą.
  • 2Turi būti galimybė išsaugoti neribotą integracijos su MS Active Directory (AD) nustatymų kiekį, nurodant konfigūracijos pavadinimą, domeno adresą, prisijungimo duomenis.
  • 3Turi būti galimybė susieti DVS lokalius ir AD naudotojus.
  • 4Turi būti galimybė jungtis prie DVS su AD naudotojais.
  • 5Turi būti galimybė automatizuotai sukurti lokalų DVS naudotoją pagal AD duomenis.
  • 6Turi būti galimybė naudotojui pirmą kartą jungiantis su AD duomenis sukurti lokalų DVS naudotoją.
  • 7Turi būti galimybė atnaujinti DVS lokalių naudotojų duomenis iš AD: vardas; pavardė; prisijungimo vardas; padalinys; pareigos; el. paštas; telefono numeris.

SIAS Elektroninių dokumentų archyvas

  • 1Turi būti modernizuotas SIAS modulis „Virtuali byla“ atliekant integraciją su ELPAKO. Funkcionalumas turi būti panaudojamas specialistų suformuotų ir priimtų sprendimų dokumentams ar bet kokiems kitiems dokumentams įkeltiems į modulį „Virtuali byla“ pasirašyti ir saugoti.
  • 2SIAS turi būti sukurtas dokumentų pasirašymo kvalifikuotu elektroniniu parašu funkcionalumas naudojantis stacionariu parašu esančiu USB laikmenoje, asmens tapatybės kortelėje arba valstybės tarnautojo pažymėjime, mobiliu parašu (Mobile-ID), Smart-ID priemonės formuojamu parašu.
  • 3Lietuvos teisės aktuose reglamentuotų PDF-LT bei Europos sąjungoje pripažįstamų ir naudojamų tarptautiniu ASiC formatų elektroninių dokumentų formavimas.
  • 4Elektroninių dokumentų peržiūra ir juose esančių parašų bei metaduomenų patikra (validacija).
  • 5Dokumentų formavimas panaudojant laiko žymas bei elektroninių dokumentų parengimas ilgalaikiam saugojimui.
  • 6Turi būti sukurtas elektroninių dokumentų archyvas skirtas saugoti elektroninius dokumentus su automatizuotu laiko žymų atnaujinimu.

Bandomosios eksploatacijos reikalavimai

  • 1Sistemai taikoma bandomoji eksploatacija, kurios trukmė yra 2 savaitės ir kuri skaičiuojama nuo Sistemos įdiegimo į gamybinę aplinką.
  • 2Užsakovo ir Tiekėjo raštišku sutarimu bandomosios eksploatacijos laikas gali būti pailgintas arba sutrumpintas.
  • 3Bandomosios eksploatacijos metu Tiekėjas privalo taisyti klaidas, registruotas ir neišspręstas priėmimo testavimo metu, ir klaidas, registruotas bandomosios eksploatacijos metu.
  • 4Bandomoji eksploatacija negali būti laikoma baigta, jei Tiekėjas neištaisė visų priėmimo testavimo metu identifikuotų kritinių bei svarbių klaidų.
  • 5Kai neįmanoma ištaisyti klaidų iki bandomosios eksploatacijos pabaigos, Užsakovo ir Tiekėjo sutarimu bandomosios eksploatacijos laikas gali būti pratęstas iki tol, kol bus ištaisytos šio skyriaus 2 punkte nurodytos klaidos ir Sistema visa apimtimi atitiks nustatytus reikalavimus.
  • 6Į bandomosios eksploatacijos trukmę neįskaičiuojamas laikas, kai dėl Sistemos kritinių klaidų tokia bandomoji eksploatacija negalėjo vykti.
  • 7Bandomosios eksploatacijos metu nustačius klaidas, kilusias dėl to, kad projektavimo ir programavimo metu Tiekėjas jų nenumatė, Tiekėjas nemokamai atlieka reikalingus taisymus.
  • 8Sistemos priėmimo aktas nesurašomas anksčiau negu programinė įranga yra sukurta, įdiegta, tinkamai veikia (užbaigta jos bandomoji eksploatacija), Tiekėjas perdavė visus Projekto metu Tiekėjo ir Užsakovo suderintus ir patvirtintus galutinius rezultatus.

DVS darbuotojų pavadavimo reikalavimai

  • 1DVS turi būti realizuota automatinio dokumentų ir užduočių perdavimo pavaduojančiam asmeniui (ligos, atostogų, komandiruočių ir pan. atvejais) funkcija, kuri automatiškai perduoda pavaduojamojo darbuotojo dokumentus ir pavedimus pavaduojančiam darbuotojui.
  • 2Darbuotojo pavadavimą turi galėti konfigūruoti pats darbuotojas, sistemos administratorius, kita, pagal teises, priskirtas asmuo.
  • 3Pavadavimo požymis gali būti nustatomas šiais būdais: Rankiniu būdu, pažymint pavadavimą einamuoju metu; Iš anksto užpildant būsimą pavadavimo datą.
  • 4DVS turi būti galimybė sukonfigūruoti darbuotojo pavadavimo priskyrimą nurodant pavaduojantį asmenį ir pavadavimo pradžios ir pabaigos datas. Pavadavimas pagal nustatytus parametrus veikia automatiškai, atėjus terminui.
  • 5DVS turi būti realizuota galimybė sukonfigūruoti reikalingų teisių perdavimą pavadavimo metu.
  • 6DVS turi būti realizuota galimybė grįžusiam darbuotojui pamatyti dokumentus ir pavedimus, kurie jam nesant buvo perduoti pavaduojančiam asmeniui.
  • 7DVS turi būti realizuota galimybė pavadavimą susieti su dokumentu, pvz. direktoriaus įsakymu, kurio pagrindu sukurtas pavadavimas.
  • 8Pavadavimo konfigūravimo metu turi būti galimybė vienu veiksmu grąžinti paimtus redagavimui dokumentus („srautinis dokumentų grąžinimas“).
  • 9Vienu veiksmu grąžinant paimtus redagavimui dokumentus, turi būti galimybė vieną kartą nurodyti grąžinimo veiksmo pagrindimą (komentarą) ir komentaras turi būti atvaizduojamas grąžinamų dokumentų žurnale.
  • 10Pavadavimo konfigūravimo metu turi būti galimybė vienu veiksmu perduoti darbuotojui nukreiptus dokumentus ir vykdomas pavedimus kitam darbuotojui. Turi būti galimybė sužymėti taip perduodamus dokumentus ir pavedimus ir perduoti ne visas, o tik pasirinktus.
  • 11Grįžusiam darbuotojui pirmojo prisijungimo metu Sistema turi automatiškai informuoti apie aktyvią pavadavimo būseną.
  • 12Turi būti galimybė kitiems naudotojams nukreipiant dokumentą ir kuriant pavedimus matyti, kurie darbuotojai yra šiuo metu pavaduojami.

DVS darbų sekų šablonų reikalavimai

  • 1Turi būti galimybė kurti, redaguoti, peržiūrėti, naikinti darbų sekų šablonus.
  • 2Turi būti galimybė peržiūrėti visų darbų sekų šablonų sąrašą.
  • 3Turi būti galimybė ieškoti darbų sekų šablonų bent pagal šiuos laukus: Antraštė; Dokumento, kuriam skitas šablonas tipas; Tipą; Žymelę; Požymį, ar aktyvus.
  • 4Kuriant darbų sekų šabloną turi būti galimybė nurodyti bent šiuos duomenis: Antraštę; Dokumento tipą, kuriam skirtas šablonas; Tipą; Šablono darbų seką.
  • 5DVS turi būti galimybė konstruojant darbų sekų šablono darbų seką nurodyti sisteminius veiksmus: Derinimas; Vizavimas; Pasirašymas; Tvirtinimas; Registravimas.
  • 6DVS turi būti galimybė kurti veiksmų pavadinimus nurodant: Pavadinimą; Mygtuko pavadinimą; Požymį, ar paskutinis sekos veiksmas.
  • 7Turi būti galimybė naikinti pridėtą veiksmą.
  • 8DVS turi būti galimybė konstruojant darbų sekų šablono darbų seką nurodyti kitus duomenis: Datą nuo/iki ar atlikimo periodą; Pareigybę; Darbuotoją; Grupę.
  • 9DVS turi būti galimybė konstruojant darbų sekų šablono darbų seką keisti (aukštyn/žemyn) veiksmus vietomis.
  • 10DVS turi būti galimybė konstruojant darbų sekų šablono darbų seką turi būti galimybė priskirti sekos vykdytoją nurodant šiuos duomenis: Vykdymo principas; Data nuo/iki ar atlikimo periodas; Pareigybė; Darbuotojas; Grupė; Pastabos.
  • 11DVS turi būti galimybė konstruojant darbų sekų šablono darbų seką keisti (aukštyn/žemyn) veiksmo vykdytojus vietomis.
  • 12Turi būti galimybė naikinti pridėtą vykdytoją.
  • 13Turi būti galimybė visuose dokumentų tipuose, kur naudojamos darbų sekos, užkrauti darbų seką iš šablono.

DVS savitarnos portalo DVS reikalavimai

  • 1Turi būti galimybė į DVS įkelti per savitarnos portalą teikiamų dokumentų šablonus docx formatu.
  • 2Turi būti galimybė sudaryti ir konfigūruoti teikiamų dokumentų pildymo formas įkeltų dokumentų šablonų pagrindu.
  • 3Sudarant ir konfigūruojant teikiamų dokumentų pildymo formas turi būti galimybė nurodyti: lauko pavadinimą; lauko tipą: data; tekstas; skaičius; redaktorius; klasifikatorius; sisteminis laukas; Požymį, ar laukas privalomas; Pastabą prie lauko.
  • 4Pasirinkus lauko tipą „sisteminis laukas“ turi būti galimybė nurodyti subtipą: Adresas; Asmens kodas; Aukščiausias padalinys; Aukštesnysis padalinys; Einamoji data; El. paštas; Įstaiga; Vardas; Pavardė; Pareigybė; Telefonas.
  • 5Teikiamo dokumento ruošinio šablone turi būti galimybė nurodyti padalinius, kuriems bus suteikta teisės pildyti šabloną.
  • 6Teikiamo dokumento ruošinio šablone turi būti galimybė nurodyti, ar bus reikalinga pridėti failus pildant šabloną. Turi būti galimybė nurodyti failų pastabos tekstą.
  • 7Teikiamo dokumento ruošinio šablone turi būti galimybė nurodyti teikiamų dokumentų registrus, į kuriuos automatizuotai bus registruojami teikiami dokumentai.
  • 8Teikiamo dokumento ruošinio šablone turi būti galimybė nurodyti požymį, ar bus rengiamas dokumentas teikiamo dokumento pagrindu.
  • 9Teikiamo dokumento ruošinio šablone turi būti galimybė nurodyti rengiamo dokumento (įsakymo tipo) ruošinį.
  • 10Teikiamo dokumento ruošinio šablone turi būti galimybė sutinkinti pasirinkto rengiamo dokumento (įsakymo tipo) ruošinio laukus su teikimo dokumento ruošinio laukais. Pagal laukų sutinkinimą į rengiamo dokumento pildymo formą turi persikelti laukų reikšmės iš teikiamo dokumento formos.
  • 11Turi būti galimybė sudaryti ir konfigūruoti rengiamų dokumentų (įsakymo tipo) pildymo formas.
  • 12Teikiamo dokumento ruošinio šablone turi būti galimybė nurodyti darbų seką, pagal kurią bus apdorojamas pateiktas dokumentas.
  • 13Teikiamo dokumento ruošinio šablone turi būti galimybė kiekvienai pareigybei ar visoms nurodyti skirtingas darbų sekas, pagal kurias bus apdorojamas pateiktas dokumentas.
  • 14Teikiamo dokumento ruošinio šablone priskiriant darbų sekas turi būti galimybė pridėti šiuos darbų sekos veiksmus: Vizavimas; Pasirašymas; Tvirtinimas; Registravimas (pateikto dokumento); Sukūrimas (rengiamo dokumento).
  • 15Teikiamo dokumento ruošinio šablone priskiriant darbų sekas turi būti galimybė darbų sekos veiksmo vykdytoją nurodyti: konkretų darbuotoją; nurodyti pareigybę; darbuotojų grupę.
  • 16Turi būti galimybė kiekvienai iš pareigybių užkrauti darbų sekos šabloną.
  • 17Teikiamo dokumento ruošinio šablone nurodant darbų sekos vykdytoją konkrečia pareigybę turi būti realizuotas funkcionalumas, kad DVS suranda ir įrašo į darbų seką konkretų darbuotoją pagal nurodytas pareigybes iš dokumento teikėjo padalinio.
  • 18Teikiamo dokumento ruošinio šablone nurodant darbų sekos vykdytoją konkrečia darbuotojų grupę turi būti realizuotas funkcionalumas, kad DVS išsiunčia el. laiškus visiems grupės nariams, o vienam iš jų, kuris vykdys dokumento apdorojimą, turi būti galimybė prisiskirti dokumentą sau.
  • 19DVS turi būti galimybė sukonstruoti naujo darbuotojo duomenų užpildymo formą.
  • 20DVS konstruojant naujo darbuotojo duomenų įvedimo formą, turi būti galimybė pridėti ir redaguoti laukų grupes nurodant šiuos parametrus: Pavadinimas; Pastaba prie lauko; Išdėstymas (kairė, dešinė, abipusis).
  • 21DVS konstruojant naujo darbuotojo duomenų įvedimo formą, turi būti galimybė pridėti ir redaguoti šių tipų laukus: data; data/laikas; failas; išsiskleidžiantis sąrašas; klasifikatorius; laikas; pasirinkimų rinkinys; pažymimas langelis; sisteminis; skaičius; tekstas (1 eilutės, 3 eilučių).
  • 22DVS konfigūruojant lauko tipą „data“ turi būti galimybė nurodyti: Požymį, ar redaguojamas; Požymį, ar privalomas; Datos formatą (mišrus, trumpas); Numatytą reikšmę.
  • 23DVS konfigūruojant lauko tipą „data/laikas“ turi būti galimybė nurodyti: Požymį, ar redaguojamas; Požymį, ar privalomas; Datos formatą (mišrus, trumpas); Numatytą reikšmę.
  • 24DVS konfigūruojant lauko tipą „failas“ turi būti galimybė nurodyti: Požymį, ar redaguojamas; Požymį, ar privalomas; Suflerį.
  • 25DVS konfigūruojant lauko tipą „išsiskleidžiantis sąrašas“ turi būti galimybė nurodyti: Požymį, ar redaguojamas; Požymį, ar privalomas; Pasirinkimų skaičių (vienas, kelis); Suflerį; Reikšmę: Tekstas; Priskiriama reikšmė; Numatyta reikšmę.
  • 26DVS konfigūruojant lauko tipą „klasifikatorius“ turi būti galimybė nurodyti: Sistemos klasifikatorių; Požymį, ar redaguojamas; Požymį, ar privalomas; Pasirinkimų skaičių (vienas, kelis); Suflerį; Numatyta reikšmę.
  • 27DVS konfigūruojant lauko tipą „laikas“ turi būti galimybė nurodyti: Požymį, ar redaguojamas; Požymį, ar privalomas; Formatas (pilnas, sutrumpintas); Numatyta reikšmę.
  • 28DVS konfigūruojant lauko tipą „pasirinkimų rinkinys“ turi būti galimybė nurodyti: Požymį, ar redaguojamas; Požymį, ar privalomas; Pasirinkimo įrašą: Tekstą; Priskiriamą reikšmę.
  • 29DVS konfigūruojant lauko tipą „pažymimas langelis“ turi būti galimybė nurodyti: Požymį, ar redaguojamas; Požymį, ar privalomas; Tekstas už lauko; Priskiriama reikšmė, kai pažymėta; Priskiriama reikšmė, kai nepažymėta.
  • 30DVS konfigūruojant lauko tipą „pažymimas langelis“ turi būti galimybė nurodyti: Potipį; Požymį, ar redaguojamas; Požymį, ar privalomas; Suflerį; Numatytą reikšmę.
  • 31DVS naujo darbuotojo duomenų įvedimo formoje nurodžius lauko tipą „sisteminis“, turi būti galimybė pasirinkti potipį: Vardas; Pavardė; Adresas; Asmens kodas; Banko sąskaitos numeris; Darbo užmokestis; Darbo valandų apskaita; Darbo valandų skaičius per dieną; Einamoji data; El. paštas; Įstaiga; Mobilus telefonas; Telefonas; Sutarties tipas; Vaikų skaičius.
  • 32DVS konfigūruojant lauko tipą „skaičius“ turi būti galimybė nurodyti: Požymį, ar redaguojamas; Požymį, ar privalomas; Suflerį; Formatą (sveikas, su kableliu); Numatyta reikšmę.
  • 33DVS konfigūruojant lauko tipus „Tekstas (1 eilutė)“ ir „Tekstas (3 eilutės)“ turi būti galimybė nurodyti: Požymį, ar redaguojamas; Požymį, ar privalomas; Suflerį; Numatytą reikšmę.
  • 34DVS turi būti galimybė peržiūrėti ir patvirtinti naujo darbuotojo pateiktus duomenis.
  • 35DVS po naujo darbuotojo duomenų pavirtinimo automatizuotai turi būti sukuriamas naudotojas ir išsiunčiamas el. laiškas darbuotojui su visa reikalinga prisijungimui prie savitarnos portalo informacija.
  • 36DVS po naujo darbuotojo duomenų pavirtinimo automatizuotai turi darbuotojo pateikti duomenys turi būti įkelti į iš anksto sukonfigūruotą dokumento ruošinį.
  • 37DVS turi būti galimybė peržiūrėti visų darbuotojų pateiktų duomenų sąrašus.
  • 38DVS turi būti galimybė ieškoti darbuotojų pateiktų duomenų pagal išvardintus laukus.
  • 39DVS turi būti galimybė peržiūrėti visus per savitarnos portalą pateiktus dokumentus.
  • 40DVS turi būti galimybė užregistruoti į oficialų registrą per savitarnos portalą pateiktą dokumentą.
  • 41DVS turi būti galimybė užregistruoti rengiamą dokumentą (teisės akto tipo) per savitarną pateiktos dokumento pagrindu.
  • 42DVS turi būti galimybė užregistruoti į oficialų registrą rengiamą dokumentą (teisės akto tipo).

VPS pirkimų inicijavimo funkcionalumas

  • 1VPS turi būti galimybė inicijuoti pirkimą iš konkrečios pirkimų plano eilutės, neplaninio pirkimo atveju turi būti galimybė nukreipti į metinio pirkimų plano papildymo funkciją bei inicijuoti pirkimų plano papildymą / koregavimą (t. y. pradėti metinio pirkimų plano koregavimo / pildymo procesą).
  • 2VPS inicijuojant pirkimą informacija turi būti automatiškai perkeliama iš pirkimų plano.
  • 3VPS inicijuojant pirkimą turi būti galimybė koreguoti / pildyti duomenis iš pirkimų plano.
  • 4Pirkimo inicijavimo funkcionalumas turi leisti pridėti papildomus dokumentus įvairiais visuotinai pripažįstamais formatais (.doc(x), .xls(x), .pdf, .jpg, .gif ir pan.) – techninę specifikaciją ir jos priedus, kitus aktualius inicijavimui dokumentus.
  • 5Pirkimo inicijavimo funkcionalumas turi leisti pateikti informaciją apie siūlomus standartinius / nestandartinius specialiuosius kvalifikacijos reikalavimus ir pan.
  • 6VPS turi būti galimybė nustatyti užduočių (vizavimo, tvirtinimo, vykdymo, susipažinimo) eigą: vizuoti, tvirtinti, grąžinti koregavimui įvairių lygių naudotojams.
  • 7VPS turi būti galimybė automatiškai ir / ar rankiniu būdu registruoti pirkimo inicijavimo dokumentus iki / po galutinio suderinimo.
  • 8VPS turi būti galimybė pirkimo inicijavimo formos duomenis automatiškai perkelti į tolesnius pirkimo procesų žingsnius.

Bendrieji paslaugų teikimo reikalavimai

  • 1Paslaugų teikėjas turi turėti teisę teisėtai teikti priežiūros paslaugas ir užtikrinti, kad paslaugų teikimas nepažeis trečiųjų asmenų intelektinės nuosavybės teisių.
  • 2Sistemos palaikymas turi būti teikiamas 24 mėn. po sutarties pasirašymo arba iki kol suteiktų paslaugų kiekis pasiekia Sutarties kainą, jei tai įvyksta anksčiau.
  • 3Sistemos palaikymas apima Sistemos palaikymą, atnaujinamą ir pritaikymą pagal galiojančius ir naujai įsigaliojančius Lietuvos Respublikos įstatymus, Vyriausybės nutarimus bei jų pasikeitimus, susijusius su pirkimo objektu.
  • 4Eksploatuojamos Sistemos darbingumo atstatymą, pvz., įvykus duomenų bazės ar atskirų jos komponentų darbų sutrikimams.
  • 5Sistemos Autorių klaidų taisymas.

DVS ataskaitos ir analitikos reikalavimai

  • 1Turi būti galimybė atspausdinti dokumento ir (arba)/užduoties kortelę.
  • 2Turi būti galimybė suformuoti suvestinę apie susipažinimą su dokumentais.
  • 3Susipažinimo su dokumentais suvestinėje turi būti galimybė ieškoti duomenų pagal išvardintus laukus.
  • 4Susipažinimo suvestinėje turi būti išvedami išvardinti duomenys.
  • 5Susipažinimo suvestinės dokumentus turi būti galimybė grupuoti pagal darbuotojus, kuriems skirtas susipažinimas.
  • 6Turi būti galimybė suformuoti ataskaitą apie pavedimų įvykdymą.
  • 7Turi būti galimybė pavedimų ataskaitą suformuoti pagal išvardintus kriterijus.
  • 8Turi būti galimybė sudaryti dokumentacijos planų ataskaitą.
  • 9Turi būti galimybė sudaryti dokumentų įvykdymo suvestinę.
  • 10Dokumentų įvykdymo suvestinėje turi būti galimybė ieškoti dokumentų pagal išvardintus laukus.
  • 11Dokumentų įvykdymo suvestinėje turi būti išvedami išvardinti duomenys.
  • 12Dokumentų įvykdymo suvestinėje duomenys turi būti grupuojami pagal padalinį ir kiekviename iš jų pagal būseną (Neįvykdyti, Įvykdyti pavėluotai, įvykdyti laiku, įvykdyti be termino).
  • 13Turi būti galimybė sudaryti gautų dokumentų suvestinę pagal veiklos istoriją.
  • 14Gautų dokumentų pagal veiklos istoriją turi būti galimybė ieškoti dokumentų pagal išvardintus laukus.
  • 15Gautų dokumentų pagal veiklos istoriją suvestinėje turi būti išvedami išvardinti duomenys.
  • 16Turi būti galimybė sudaryti gautų dokumentų ataskaitą pagal gavėją ir dokumento rūšį.
  • 17Turi būti galimybė sudaryti gautų dokumentų ataskaitą pagal gavėją ir dokumento rūšį parenkant išvardintus parametrus.
  • 18Gautų dokumentų ataskaitoje pagal gavėją ir dokumento rūšį turi būti išvedami duomenys, kiek kiekvienam gavėjui skirta dokumentų pagal dokumento rūšį.
  • 19Turi būti galimybė sudaryti gautų dokumentų ataskaitą pagal dokumentų skaičių.
  • 20Turi būti galimybė sudaryti gautų dokumentų ataskaitą pagal dokumentų skaičių parenkant išvardintus parametrus.
  • 21Gautų dokumentų ataskaitoje pagal dokumentų skaičių turi būti išvedami duomenys, kiek kiekvienam gavėjui skirta dokumentų pagal dokumentų skaičių.
  • 22Turi būti galimybė sudaryti gautų dokumentų ataskaitą einamajam periodui.
  • 23Turi būti galimybė sudaryti gautų dokumentų ataskaitą einamajam periodui parenkant išvardintus parametrus.
  • 24Gautų dokumentų ataskaitoje einamajam periodui turi būti išvedami duomenys, kiek kiekvieno sudarytojo nurodytam laikotarpiui pateikta dokumentų.
  • 25Turi būti galimybė sudaryti gautų dokumentų ataskaitą pagal sudarytoją ir dokumento rūšį.
  • 26Turi būti galimybė sudaryti gautų dokumentų ataskaitą pagal sudarytoją ir dokumento rūšį parenkant išvardintus parametrus.
  • 27Gautų dokumentų ataskaitoje pagal sudarytoją ir dokumento rūšį turi būti išvedami duomenys, kiek kiekvienas sudarytojas pateikė dokumentų pagal dokumento rūšį.
  • 28Turi būti galimybė sudaryti gautų dokumentų ataskaitą pagal sudarytojus ir gavėjus.
  • 29Turi būti galimybė sudaryti gautų dokumentų ataskaitą pagal sudarytojus ir gavėjus parenkant išvardintus parametrus.
  • 30Gautų dokumentų ataskaitoje pagal sudarytojus ir gavėjus turi būti išvedami duomenys, kiek kiekvieno sudarytojo dokumentų priskirta atitinkamam gavėjui.
  • 31Turi būti galimybė sudaryti gautų dokumentų registro ataskaitą.
  • 32Turi būti galimybė sudaryti gautų dokumentų registro ataskaitą parenkant išvardintus parametrus.
  • 33Gautų dokumentų registro ataskaitoje turi būti išvedami išvardinti dokumentų duomenys.
  • 34Turi būti galimybė sudaryti dokumentų-pavedimų ataskaitą.
  • 35Turi būti galimybė sudaryti dokumentų-pavedimų ataskaitą nurodant išvardintus parametrus.
  • 36Dokumentų-pavedimų ataskaitoje turi būti išvedami duomenys apie pavedimus ir jų vykdytojus.
  • 37Turi būti galimybė tiesiai iš DVS išsiųsti suformuotą dokumentų-pavedimų ataskaitą.
  • 38Turi būti galimybė sudaryti dokumentų-pavedimų ataskaitą su veiklos istorija.
  • 39Turi būti galimybė sudaryti dokumentų-pavedimų ataskaitą nurodant išvardintus parametrus.
  • 40Dokumentų-pavedimų ataskaitoje turi būti išvedami duomenys apie pavedimus ir jų vykdytojus su veiklos istorija.
  • 41Turi būti galimybė tiesiai iš DVS išsiųsti suformuotą dokumentų-pavedimų ataskaitą.
  • 42Turi būti galimybė sudaryti neįvykdytų ir vėluojančių pavedimų ataskaitą.
  • 43Turi būti galimybė sudaryti neįvykdytų ir vėluojančių pavedimų ataskaitą nurodant išvardintus parametrus.
  • 44Neįvykdytų ir vėluojančių pavedimų ataskaitoje turi būti išvedami išvardinti duomenys.
  • 45Turi būti galimybė sudaryti neįvykdytų ir vėluojančių pavedimų ataskaitą pagal vykdytojus.
  • 46Turi būti galimybė sudaryti neįvykdytų ir vėluojančių pavedimų ataskaitą pagal vykdytojas nurodant išvardintus parametrus.
  • 47Neįvykdytų ir vėluojančių pavedimų ataskaitoje pagal vykdytojus turi būti išvedami išvardinti duomenys.
  • 48Turi būti galimybė sudaryti siunčiamų dokumentų ataskaitą pagal adresatus.
  • 49Turi būti galimybė sudaryti siunčiamų dokumentų ataskaitą pagal adresatus nurodant išvardintus kriterijus.
  • 50Siunčiamų dokumentų ataskaitoje pagal adresatus turi būti išvedami išvardinti duomenys.
  • 51Turi būti galimybė sudaryti siunčiamų dokumentų ataskaitą pagal adresatus datos periodui.
  • 52Turi būti galimybė sudaryti siunčiamų dokumentų ataskaitą pagal adresatus datos periodui nurodant išvardintus kriterijus.
  • 53Siunčiamų dokumentų ataskaitoje pagal adresatus datos periodui turi būti išvedimi išvardinti duomenys.
  • 54Turi būti galimybė sudaryti siunčiamų dokumentų ataskaitą pagal adresatus ir dokumentų rūšis.
  • 55Turi būti galimybė sudaryti siunčiamų dokumentų ataskaitą pagal adresatus dokumentų rūšis nurodant išvardintus kriterijus.
  • 56Siunčiamų dokumentų ataskaitoje pagal adresatus ir dokumentų rūšis turi būti išvedimi išvardinti duomenys.
  • 57Turi būti galimybė sudaryti siunčiamų dokumentų ataskaitą pagal adresatus ir rengėjus.
  • 58Turi būti galimybė sudaryti siunčiamų dokumentų ataskaitą pagal adresatus ir rengėjus nurodant išvardintus kriterijus.
  • 59Siunčiamų dokumentų ataskaitoje pagal adresatus ir dokumentų rūšis turi būti išvedimi išvardinti duomenys.
  • 60Turi būti galimybė sudaryti siunčiamų dokumentų išsiuntimų ataskaitą.
  • 61Turi būti galimybė sudaryti siunčiamų dokumentų išsiuntimų ataskaitą nurodant išvardintus parametrus.
  • 62Siunčiamų dokumentų išsiuntimų ataskaitoje turi būti išvedimi išvardinti duomenys.
  • 63Turi būti galimybė sudaryti siunčiamų dokumentų rengėjų pagal periodą ataskaitą.
  • 64Turi būti galimybė sudaryti siunčiamų dokumentų rengėjų pagal periodą ataskaitą nurodant išvardintus parametrus.
  • 65Siunčiamų dokumentų rengėjų pagal periodą ataskaitoje turi būti išvedami išvardinti duomenys.
  • 66Turi būti realizuota galimybė tipines ataskaitas eksportuoti XLSX, DOCX, PDF formatais.
  • 67Turi būti realizuota galimybė tipines suvestines eksportuoti XLSX, PDF formatais.

Elektroninio parašo modulio reikalavimai

  • 1DVS turi būti galimybė pasirašyti el. dokumentus Lietuvos Respublikos teisės aktų reikalavimus atitinkančiu kvalifikuotu elektroniniu parašu naudojant mobiliojo ryšio operatorių išduodamus sertifikatus (mobilų parašą) ir valstybės tarnautojo pažymėjimus.
  • 2Turi būti galimybė naudoti Lietuvos mobiliojo ryšio operatorių: UAB „Bitė Lietuva“, AB „Telia Lietuva“, UAB „Tele2“ kvalifikuotus sertifikatus mobiliai pasirašymo paslaugai.
  • 3El. parašo transakcijas sudaro: parašo sudarymas bet kokiu būdu (į tai įeina dokumento pakuotės sudarymas, metaduomenų pildymas, sertifikatų patikra); dokumento patikrinimas (tikrinamas atitikimas el. dokumento specifikacijai, parašo sertifikatų tikrinimas realiu laiku, parašų tikrinimas); parašo paruošimas ilgalaikiam saugojimui (dokumento parašų galiojimo pratęsimas/archyvavimas); laiko žymos uždėjimas (ne pasirašymo metu); metaduomenų redagavimas.
  • 4DVS turi būti realizuotas funkcionalumas el. parašo transakcijų fiksavimui ir peržiūrai.
  • 5Tiekėjas turi užtikrinti 99,00% mėnesinį paslaugų pasiekiamumą. Tiekėjas neatsako už trečiųjų šalių infrastruktūros prieinamumą (mobilaus parašo, SMART-ID, kitų eID priemonių ir patikimumo užtikrinimo paslaugų teikėjų).
  • 6Elektroninio parašo modulio funkcionalumas privalo gebėti suformuoti ADOC (su XAdES formato parašais), PDF, PDF-LT (su PAdES formato parašais), ASiC-E specifikacijų dokumentus pagal eIDAS reglamento reikalavimus.

Papildomų vystymo paslaugų reikalavimai

  • 1Paslaugų teikimo sutarties vykdymo metu Užsakovas, esant poreikiui, teikdama atskirus raštiškus Papildomų paslaugų užsakymus, turi teisę užsakyti Papildomas paslaugas, pagal Tiekėjo pasiūlyme nurodytą valandinį įkainį. Užsakovas neįsipareigoja išpirkti viso nurodyto valandų kiekio.
  • 2Papildomų modifikavimo darbai nenumatytoms sritims ar funkcijoms – darbas užsakomas esant poreikiui realizuoti papildomą Sistemos funkcionalumą, atlikti sukurtų funkcijų pakeitimą, kuris nėra numatytas.
  • 3Papildomų integracinių sąsajų įgyvendinimas – darbas užsakomas esant poreikiui realizuoti papildomą integracinę sąsają su kita informacine sistema duomenų gavimui arba perdavimui.
  • 4Papildomi instruktavimai, papildomos konsultacijos.
  • 5Kiti papildomi su Užsakovu suderinti darbai.
  • 6Papildomų paslaugų poreikiai, turi būti suderinti su Užsakovo projekto vadovu.
  • 7Sistemos vystymo poreikių (pakeitimų) inicijavimo ir vykdymo eiga: Užsakovas pateikia užsakymą Paslaugų teikėjo pagalbos sistemoje, kurioje aprašomi pakeitimo reikalavimai.
  • 8Išskirtiniais atvejais užsakymas teikiamas el. paštu pagal atskirą susitarimą.
  • 9Paslaugų teikėjas pateikia aprašytų reikalavimų vertinimą, apimantį preliminarius atlikimo terminus ir apimtis. Atnaujinama modifikuotos Sistemos dokumentacija.
  • 10Teikiamos Papildomos paslaugos neturi sutrikdyti nepertraukiamo Sistemos veikimo. Priešingu atveju Tiekėjas privalo atstatyti Sistemos veikimą per nurodytus klaidų šalinimo terminus savo lėšomis.
  • 11Turi būti atliekamas visų atliktų papildomų Sistemos pakeitimų testavimas.

SIAS pasirašymo įrenginių reikalavimai

  • 1Turi būti galimybė užregistruoti turimus įrenginius (planšetinius kompiuterius), nurodant jų pavadinimus ir prisijungimo duomenis.
  • 2Turi būti galimybė matyti, ar įrenginys yra prijungtas ir pasiekiamas.
  • 3Turi būti galimybė naikinti nenaudojamų įrenginių registraciją.
  • 4Įrenginio prisijungimo sesija turi būti neapribota laiko parametrais. Įrenginys turi turėti galimybę atjungimui rankiniu būdu.
  • 5Įrenginys turi turėti laukimo langą, kuriame rodoma užsklanda.
  • 6Turi būti galimybė įkelti/pasirinkti įrenginio ekrano užsklandą.
  • 7Turi būti kontroliuojama, ar tuo pat metu yra prijungtas tik vienas įrenginys, kad pasirašymas nebūtų inicijuojamas keliuose įrenginiuose tuo pat metu.
  • 8Turi būti galimybė pasirinktą dokumento formą išsiųsti į pasirinktą įrenginį.
  • 9Turi būti galimybė pasirinktą dokumento formą siųsti pasirašymui į tą patį įrenginį, iš kurio vyksta inicijavimas.
  • 10Turi būti galimybė pasirašymui naudoti specialų rašiklį, kuris leidžia surinkti pasirašančio asmens biometrinę parašo informaciją pagal standartą ISO/IEC 19794-7:2021.

DVS dokumentų formų valdymo reikalavimai

  • 1DVS turi būti galimybė konfigūravimo būdu (be programavimo) kiekvienai dokumento tipo registro kortelei sukurti neribotą kiekį įvairių tipų papildomų atributų (laukų).
  • 2Kuriant naujus atributus, turi būti nurodoma ši informacija: a) atributo (lauko) pavadinimas, pastaba; b) atributo (lauko) tipas; c) kiti atributo (lauko) parametrai.
  • 3DVS turi būti galimybė pridėti neribotą kiekį naujų tekstinio (1 (vienos), 3 (trijų) eilučių) tipo atributų.
  • 4DVS turi būti galimybė sukurti neribotą kiekį naujų skaičiaus tipo atributų.
  • 5DVS turi būti galimybė sukurti neribotą kiekį naujų datos / laiko tipo atributų.
  • 6DVS turi būti galimybė sukurti neribotą kiekį naujų pažymimo langelio (angl. check box) tipo atributų.
  • 7DVS turi būti galimybė sukurti neribotą kiekį naujų pasirinkimo rinkinio (angl. radio buttons) tipo atributų.
  • 8DVS turi būti galimybė sukurti neribotą kiekį naujų išsiskleidžiančio sąrašo (angl. dropdown) tipo atributų. Turi būti galimybė nurodyti, ar pasirenkamos kelios reikšmės (angl. multiselect).
  • 9DVS turi būti galimybė sukurti neribotą kiekį išsiskleidžiančio (angl. dropdown) sąrašo tipo atributų, pasirenkant reikšmes iš sistemoje įvestų žinynų/klasifikatorių.
  • 10Turi būti galimybė nustatyti „privalomumo“ požymį kiekvienam atributui individualiai. Pažymėjus šį požymį, DVS neturi leisti išsaugoti kuriamo/redaguojamo dokumento, jeigu neužpildyta atributo reikšmė.

SIAS Elektroninių dokumentų pasirašymas

  • 1Naudotojų, pasirašančiųjų el. parašu skaičius neturi būti ribojamas.
  • 2Elektroninio parašo modulio funkcionalumas turi gebėti suformuoti XAdES ir PAdES formato parašą be laiko žymos. Toks parašas turi galioti iki parašo sertifikato galiojimo pabaigos arba iki parašo sertifikato atšaukimo momento.
  • 3Elektroninio parašo modulio funkcionalumas turi gebėti pakelti parašo apsaugos lygį iki XAdES-T ir PAdES-T (parašas su laiko žyma). Toks parašas turi galioti iki parašo sertifikato galiojimo pabaigos.
  • 4Elektroninio parašo modulio funkcionalumas turi gebėti pakelti parašo apsaugos lygį iki XAdES-XL ir PADES-LT (parašas su atšaukimo duomenimis). Tokiame paraše turi būti įtraukiami parašo sertifikato atšaukimo duomenys, leidžiantys patikrinti parašo galiojimą, net jei vėliau parašo sertifikatas buvo atšauktas. ADOC specifikacijos atveju parašo apsaugos lygį iki XAdES-XL galima pakelti tik praėjus 24 val. nuo XAdES parašo suformavimo.
  • 5Elektroninio parašo modulio funkcionalumas turi gebėti pakelti parašo apsaugos lygį iki XAdES-XL/A ir PAdES-LT/A (parašas su atšaukimo duomenimis ir archyvine laiko žyma) iki baigiant galioti XAdES-XL lygio paraše esančiai laiko žymai arba PAdES formato paraše nusilpus parašo sudarymo algoritmui. Archyvinės laiko žymos uždėjimas pratęstų parašo galiojimą iki laiko žymos galiojimo pabaigos.

SPS biudžeto sudarymo dalies reikalavimai

  • 1SPS biudžeto planavimo (sudarymo), vykdymo ir kontrolės funkcionalumas turi būti suderinamas su galiojančiomis LR valstybės biudžeto ir savivaldybių biudžetų sudarymo ir vykdymo taisyklėmis.
  • 2SPS biudžeto planavimo ir vykdymo funkcionalumas turi būti susietas su strateginio planavimo funkcionalumu. Turi būti sąsaja tarp programų ir kitų elementų.
  • 3SPS turi būti numatyta galimybė asignavimų valdytojams sąmatas įvesti, taisyti, peržiūrėti bei formuoti Finansų ministerijos patvirtintas formas WEB aplinkoje realizuotoje aplikacijoje, palaikomoje interneto naršyklių.
  • 4SPS turi būti galimybė įvesti sąmatas pagal segmentus ir dimensijas.
  • 5SPS turi būti palaikomas programų sąmatos gyvavimo ciklo funkcionalumas – projektas, sukūrimas, peržiūra, patvirtinimas, anuliavimas, duomenų užblokavimas redaguoti, pasibaigus ataskaitiniam laikotarpiui, ir kt.
  • 6SPS turi būti galimybė įstaigos specialistui (ar keliems specialistams) įvestus ar importuotus duomenis patvirtinti. SPS turi palaikyti keleto lygių patvirtinimus.
  • 7SPS turi būti galimybė apibrėžti ir administruoti skirtingas duomenų tvirtinimo taisykles skirtingiems duomenų rinkiniams.
  • 8SPS turi neleisti koreguoti patvirtintų duomenų, tačiau patvirtinęs duomenis naudotojas pagal nustatytas taisykles turi turėti galimybę patvirtinimą atšaukti.
  • 9SPS sąmatos išlaidų straipsniai turi būti hierarchinio lygio, o tėvinės sąmatos straipsnių reikšmės turi būti sumuojamos automatiškai.
  • 10SPS turi būti galimybė planinius ir faktinius duomenis paskirstyti ketvirčiais.
  • 11SPS turi būti galimybė sekti planinius ir faktinius biudžeto duomenis pagal visus strateginio planavimo elementus, dimensijas ir detalizavimo požymius.
  • 12SPS turi būti galimybė nukopijuoti praėjusių metų biudžeto struktūrą.
  • 13SPS turi būti galimybė parengti biudžeto pajamų ir programų finansavimo planą.
  • 14SPS turi būti galimybė suvesti ir valdyti kitų, ne savivaldybės biudžeto, finansavimo šaltinių sąmatas.

Naudotojo sąsajos ergonomikos reikalavimai

  • 1Naudotojo sąsaja turi atitikti šiuolaikinius ergonomikos reikalavimus, tenkinti Elektroninių paslaugų tinkamumo naudotojams metodinėje medžiagoje pateikiamus reikalavimus bei būti projektuojama vadovaujantis gerosiomis praktikomis, pvz., ISO 9241-210 Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systems ar lygiavertėmis.
  • 2Naudotojui turi būti pateikiamos pagalbos priemonės padedančios greičiau išmokti naudotis VVS (pvz., pagalbos mygtukai, naudotojo vadovas).
  • 3Atliekamas loginis tikrinimas tarp formos elementų – vieno formos elemento parinkimas (įvedimas) turi galėti įjungti/ išjungti kitus formos elementus ir atlikti kitus veiksmus, kurie turės būti suderinti su Užsakovu.
  • 4VVS komponentų ir modulių naudotojo sąsaja turi būti prieinama naudojant interneto naršyklę.
  • 5Turi būti realizuotas naudojimo patogumą užtikrinantis funkcionalumas: TAB klavišo seka einant per duomenų įvedimo laukus.
  • 6Užuominų ir paaiškinimų pateikimas pelės žymeklį užvedus ant grafinio objekto (lietuvių kalba).
  • 7Duomenų įvedimo formose duomenų laukai turi būti užpildomi automatiškai, jeigu Sistemoje yra saugomi atitinkami duomenys.
  • 8Sistemos veiksmai, kurie gali būti vykdomi fone, turi būti taip realizuojami, kad naudotojas galėtų naudoti kitas Sistemos funkcijas.
  • 9Duomenų sąrašai turi būti Filtruojami pagal sąrašui aktualius kriterijus (vieną ar daugiau kriterijų vienu metu). Tiekėjas, su Užsakovu detalios analizės ir projektavimo etapo metu, turės identifikuoti kiekvieno sąrašo filtravimo kriterijus ir juos realizuoti.
  • 10Duomenų sąrašai turi būti Rikiuojami pagal sąrašo rikiuotinus elementus.
  • 11Naudotojui pateikiami pranešimai turi būti suformuluoti taip, kad naudotojui būtų aiški pranešimo pateikimo priežastis. Informacija apie pranešimo pateikimą sąlygojančią priežastį privalo būti pateikiama nurodant konkrečius Sistemos duomenų objektus (pavyzdžiui, laukų pavadinimus).
  • 12Jeigu naudotojui atlikus veiksmus rezultatai turės didelės įtakos, prieš atliekant veiksmą VVS turi pateikti pranešimą ir paprašyti naudotojo patvirtinti, kad tikrai norima vykdyti.
  • 13Naudotojui pateikiamame klaidos pranešime privalo būti nurodoma, kokius veiksmus naudotojas privalo atlikti tam, kad galėtų pašalinti pranešimo pateikimo priežastis ir tęsti darbą su VVS. Įvykus klaidai naudotojas apie tai turi būti aiškiai informuojamas (pvz., nukreipiamas į klaidą sąlygojančią ekraninės formos vietą, paryškinami netinkamai užpildyti formos laukai ir pan.).
  • 14Naudotojui turi būti pateikiami sėkmės pranešimai, nurodantys, kad naudotojo atlikti veiksmai yra sėkmingi (pavyzdžiui, informuojama, kad įrašas išsaugotas / ištrintas / pakoreguotas, duomenys sėkmingai įkelti ir pan.).
  • 15Klaidų pranešimai, sėkmės pranešimai ir informaciniai pranešimai turi būti išskirti skirtingomis spalvomis ar skirtingais simboliais, kad vizualiai būtų galima atskirti.
  • 16Naudotojo sąsajoje esantys duomenų įvedimo laukai turi turėti duomenų validavimo taisykles ir tikrinti įvedamų duomenų logikos korektiškumą. Laukai ir laukų validavimo taisyklės turi būti suderinti su Užsakovu.
  • 17Naudotojui pateikiama informacija turi būti ribojama pagal jam suteiktas roles bei prieigos teises prie konkretaus objekto informacijos.

SIAS dokumentų formų kūrimo reikalavimai

  • 1Turi būti galimybė sukurti parametrizuojamas formas.
  • 2Turi būti galimybė valdyti formų versijas. Sistema neturi riboti kuriamų ir saugomų formų versijų skaičiaus.
  • 3Turi būti galimybė įkelti .pdf formato dokumentą kaip pagrindą formai.
  • 4Turi būti galimybė konstruoti formą jos elementus nutempiant pele iš pateikto sąrašo į aktyvų lauką – .pdf formato dokumentą (drag&drop principu).
  • 5Turi būti galimybė pasirinkti šiuos elementų (laukų) tipus: Tekstas; Skaičius; El. paštas; Data; „Dropdown“ – pasirinkimas iš sąrašo; „Radio“ – pasirinkimas vienas iš daugelio; „Checkbox“ – pažymimas laukas; Bylos prisegimas; Parašas.
  • 6Turi būti galimybė nustatyti lauko dydį ir vietą formoje.
  • 7Turi būti galimybė prie formos elemento nustatyti, ar jis yra privalomas pildyti.
  • 8Turi būti galimybė prie formos elemento nustatyti lauko pavadinimą (antraštę), suflerį ir numatytą reikšmę.
  • 9Turi būti galimybė kurti sąryšiais susietus laukus.
  • 10Turi būti galimybė formatuoti laukus pasirenkant šrifto stilių, dydį, spalvą.
  • 11Turi būti galimybė automatiškai įrašyti einamąją datą.
  • 12Turi būti galimybė riboti įvedamų simbolių kiekį.
  • 13Turi būti galimybė nustatyti duomenų formatus, pvz. datos, skaičiaus.

SIAS dokumentų formų pildymo reikalavimai

  • 1Turi būti galimybė pildyti formą veidrodiniu principu – specialisto kompiuteryje ir įrenginyje tuo pačiu metu.
  • 2Turi būti galimybė prisiartinti/atitolinti formos atvaizdavimą.
  • 3Turi būti galimybė patikrinti, ar visi formos laukai užpildyti, atvaizduoti pranešimą ir vizualiai parodyti neužpildytus/netinkamai užpildytus laukus.
  • 4Turi būti galimybė bet kuriam pasirašymo proceso etape nutraukti pasirašymo sesiją.
  • 5Turi būti galimybė bet kuriame pasirašymo proceso etape grįžti į prieš tai buvusį žingsnį.
  • 6Turi būti neribojamas parašo duomenų surinkimo kartų kiekis su galimybe atšaukti/išvalyti/išsaugoti parašo vaizdą.
  • 7Turi būti galimybė peržiūrėti užpildytą formą su duomenimis ir skaitmenizuotu parašu prieš patvirtinant galutinį pasirašytą dokumentą.

VPS pirkimų vykdymo procesų funkcionalumas

  • 1VPS turi būti galimybė automatiškai nustatyti pirkimo būsenos statusą ir bet kuriuo metu patikrinti pirkimo statusą (inicijuojamas, vykdomas, baigtas).
  • 2VPS turi būti galimybė priskirti ir pakeisti pirkimo vykdymui priskirtą specialistą.
  • 3VPS turi būti galimybė automatiškai suformuoti užduotį pirkimą vykdysiančiam specialistui.
  • 4VPS turi būti galimybė nustatyti pirkimo vykdymo etapus, trukmes.
  • 5VPS turi būti galimybė pildyti įvairius pirkimo dokumentus (pvz., techninę specifikaciją, pirkimo paraišą, pirkimo sutartį, dokumentų pakeitimus).
  • 6VPS turi būti galimybė registruoti ir / ar siųsti kvietimus potencialiems tiekėjams.
  • 7VPS turi būti galimybė pildyti gautus tiekėjų pasiūlymus.
  • 8VPS turi būti galimybė pildyti apklausos pažymą, pirkimų komisijų protokolus.
  • 9VPS turi būti galimybė automatiškai generuoti pirkimų komisijų protokolus, apklausos pažymas, vertinimo išvadas iš tipinių Užsakovo formų ir įvestų specialiųjų duomenų, kitus su pirkimais susijusius dokumentus.

DVS dokumentų apskaitos valdymo reikalavimai

  • 1DVS turi leisti klasifikuoti dokumentus pagal organizacijos nustatytas taisykles.
  • 2DVS turi leisti į vieną bylą talpinti skirtingų tipų dokumentus (pvz. į susirašinėjimo bylą talpinti tiek gautus, tiek siunčiamus dokumentus).
  • 3DVS turi leisti valdyti šiuos dokumentacijos apskaitos dokumentus: a) dokumentacijos planus; b) dokumentacijos plano papildymų sąrašus; c) dokumentų registrų sąrašą; d) apyrašų sąrašus; e) apyrašus.
  • 4DVS turi būti galimybė sudaryti ir valdyti kalendorinių metų dokumentacijos planą. Dokumentacijos planas turi būti formuojamas bylų.
  • 5DVS turi būti galimybė kalendorinių metų pabaigoje automatiškai vienu veiksmu uždaryti visas bylas, kurios pažymėtos kaip automatiškai uždaromos / atidaromos kiekvienais metais.
  • 6Turi būti galimybė einamųjų kalendorinių metų dokumentacijos planą kopijuoti ateinantiems kalendoriniams metams, tvarkyti veiklų klasifikatorių, automatiškai skaičiuoti naują bylos indeksą atsižvelgiant į pasirinktą veiklą. Veiklos sritys numeruojamos iš eilės, kaip punktai, o kiekvienos srities bylos – atskirai, kaip papunkčiai. Turi būti galimybė bylai priskirti daugiau kaip vieną į ją dokumentus įkeliantį padalinį.
  • 7DVS turi būti galimybė valdyti dokumentacijos planą hierarchinėje dokumentų bylų struktūroje (hierarchinio bylų tvarkymo kompiuterio failų sistemoje atitikmuo), neribojant nei struktūros dydžio, nei gylio. Turi būti galimybė suglausti ir išplėsti konkretaus lygio struktūrą.
  • 8DVS turi būti galimybė užpildyti šiuos dokumentacijos plano laukus: bylos indeksas; bylos antraštė; bylos saugojimo terminas; bylos saugojimą reglamentuojančio teisės akto punktas ir jo nuoroda; už bylos sudarymą atsakingo struktūrinio padalinio pavadinimas arba darbuotojo vardas ir pavardė; pastabos.
  • 9DVS turi būti galimybė, esant poreikiui, kalendoriniais metais papildyti dokumentacijos planą nauja byla arba atlikti kitus pakeitimus, susijusius su struktūriniais pokyčiais.
  • 10Turi būti galimybė pasibaigus metams pradėti naujas bylas pagal kiekvienais metais tvirtinamą dokumentacijos planą ir leisti užbaigti praėjusių metų bylas ir registrus.
  • 11DVS turi būti galimybė: pridėti naują bylą/registrą; pašalinti bylą/registrą; kiekvienai bylai/registrui keisti bylos/registro parametrus; keisti bylos/registro prieigos teises.
  • 12DVS turi leisti nurodyti, ar registras pildomas kasmet iš naujo, ar jo numeracija tęsiama. Turi būti galimybė „užrakinti“ registrą nuo tolesnio jo pildymo, nurodant galiojimo datą iki. Turi būti galimybė užregistruoti dokumentą rankiniu būdu įrašant dokumento registracijos numerį (į registrą įterpti papildomą registracijos numerį išlaikant dokumentų registravimo chronologiją).
  • 13DVS turi būti galimybė kalendorinių metų pabaigoje automatiškai vienu veiksmu uždaryti visus dokumentų registrus, kurių pildymo laikotarpis yra nurodytas „metų“ tipo (t. y. ne „tęstinis“).
  • 14Turi būti įgyvendinta galimybė įstaigos struktūriniam padaliniui valdyti savo dokumentus, t. y. registruoti dokumentus jiems teisės aktų nustatyta tvarka priskirtuose registruose.
  • 15Registruojant gautą dokumentą turi galimybė dokumentų kortelėje nurodyti bylą (bylos indeksą) iš dokumentacijos plano, į kurią įtraukiamas dokumentas.
  • 16DVS turi būti galimybė atvaizduoti visus (tiek aktualius, tiek archyvuotus) DVS saugomus dokumentus, nepriklausomai nuo dokumentų tipo viename lange su paieškos galimybėmis.
  • 17Turi būti sukurta bylų pagal dokumentacijos planą valdymo galimybė – kiekvienai bylai turi būti nurodomi: saugojimo terminas ir veiksmai (perkelti, naikinti, pratęsti saugojimo terminą, nesusidarė byla ir t. t.), kuriuos reikia atlikti, kai pasibaigia dokumentacijos plane nurodytas bylos saugojimo terminas.

DVS savitarnos portalo bendrieji reikalavimai

  • 1DVS turi būti realizuotas atskiras supaprastintas savitarnos (angl. self services) portalas, kuriame sistemos naudotojai galėtų teikti ir gauti įvairių tipų dokumentus.
  • 2DVS ir savitarnos portalo duomenys turi būti saugomi toje pačioje duomenų bazėje.
  • 3Turi būti galimybė naudotojui persijungti iš savitarnos portalą į DVS ir atvirkščiai, neįvedant iš naujo prisijungimo duomenų.

DVS sąskaitų faktūrų valdymo reikalavimai

  • 1DVS turi būti galimybė registruoti sąskaitas faktūras.
  • 2DVS turi būti galimybė registruojant sąskaitą faktūrą dokumentą nurodyti išvardintus parametrus.
  • 3DVS turi būti galimybė peržiūrėti sąskaitų faktūrų sąrašą atvaizduojant išvardintus duomenis.
  • 4DVS turi būti galimybė ieškoti sąskaitų faktūrų pagal išvardintus parametrus.

Programinės įrangos licencijų reikalavimai

  • 1Tiekėjas, įvertinęs specifikacijos reikalavimus, turi pateikti reikiamą programinę įrangą ir licencijas (ar bet kokius kitus leidimus (sertifikatus, prenumeratas ir pan.) naudoti programinę įrangą), reikalingas siūlomo sprendimo realizacijai.
  • 2Sistemos programinės įrangos ar kitos Sistemos veikimui reikalingos licencijos turi būti neterminuoto galiojimo, o jeigu yra terminuoto galiojimo (ar kaip kitaip apriboto naudojimo), tai turi būti pateiktos tokios licencijos (ar leidimai), kad Užsakovui nereikėtų įsigyti papildomų licencijų ar kitaip patirti išlaidų programinės įrangos veikimui sutarties galiojimo metu.
  • 3Tiekėjas turi užtikrinti naudotojų licencijas numatytam VVS naudotojų skaičiui.
  • 4Jeigu siūloma programinė įranga yra licencijuojama priklausomai nuo sistemą naudojančių naudotojų (žmonių ar sistemų), naudojamų modulių, darbuotojų kiekio, tai Tiekėjas turi pateikti licencijas, kurios užtikrintų racionalų ir efektyvų VVS veikimą ir naudojimą.
  • 5Užsakovas turi turėti teisę naudotis Sistema net ir neįsigijus gamintojo palaikymo.
  • 6Licencijuojama programinė įranga turi turėti galiojančias licencijas jos veikimui ir naudojimui bei gamintojo palaikymą: atnaujinimų parsisiuntimą ir diegimą, naujų komponentų pateikimą, pagalbos tarnybos paslaugas sutarties galiojimo metu.
  • 7Tiekėjas turi pasiūlyti tokią licencijų apimtį, kuri tenkina visus Užsakovo keliamus funkcinius ir nefunkcinius reikalavimus.
  • 8Visi reikalingos programinės įrangos kaštai (licencijų kaštai ir kiti papildomi kaštai, jeigu taikomi programinės įrangos perdavimui ar kiti reikalingi kaštai pagal reikalavimus apibrėžtus šioje Specifikacijoje), turi būti įskaičiuoti į pasiūlymo kainą.
  • 9Tiekėjas turi pateikti tokią programinę įrangą ir licencijas visoms numatomoms įdiegti VVS aplinkoms.
  • 10Visos reikalingos licencijos turi būti įgyjamos ir, jeigu reikia, registruojamos Užsakovo vardu.
  • 11Pateikiamų licencijų (ir sertifikatų) galiojimo pradžia turi būti ne vėlesnė nei Sistemos palaikymo pradžia.
  • 12Nuosavybės teise Užsakovui turi būti perduotas tik tas VVS komponentų išeities kodas (pvz.: skriptai, programos, integraciniai komponentai, bibliotekos), kuris bus sukurtas šios Sutarties apimtyje ir neįeina į licencijuojamos standartizuotos programinės įrangos sudėtį (t.y. Tiekėjo sukurtas ir intelektinėmis ir komercinėmis nuosavybės teisėmis apsaugota komercinė produkto dalis (produkto CORE) neturi būti perduota Užsakovui).

VPS pirkimo sutarčių valdymo funkcionalumas

  • 1VPS turi būti galimybė kiekvienos sutarties kortelėje formuoti el. katalogą užsakymų pagal sutartį valdymui.
  • 2VPS turi būti galimybė suformuoti atnaujinto varžymosi užsakymą pagal preliminariąsias sutartis.
  • 3VPS turi būti galimybė suvesti duomenis ir automatiškai perkelti duomenis apie sudarytą sutartį iš kitų procesų žingsnių.
  • 4VPS turi būti galimybė kontroliuoti užsakymų vykdymą pagal šiuos sutarčių galiojimo parametrus: iki termino; iki kainos; iki kainos ir termino; iki kiekio ir kainos; iki kiekio ir termino.
  • 5VPS turi būti numatytas išankstinis informavimas el. paštu apie besibaigiančias sutartis pagal pasirinktus nustatymus: iki pilno sutarties sumos išnaudojimo likus nustatytai ribinei sumai; iki tam tikro sutarties sumos limito; iki sutarties galiojimo pabaigos likus nustatytam laikotarpiui; iki sutarties galiojimo pabaigos termino.
  • 6VPS turi būti galimybė įkelti sąskaitas faktūras ir susieti jas su atitinkama sutartimi, paraiška ir / ar užsakymu bei stebėti sutarčių likučius, t.y. VP sistemoje turi būti galimybė įvykdžius užsakymą automatiškai perskaičiuoti, kokia suma išnaudota ir kokia liko.
  • 7VPS turi būti galimybė eksportuoti duomenis apie sutartis, jų galiojimą, atsakingus asmenis, likučius visuotinai pripažįstamais formatais.

Alternatyvių sprendimų siūlymo reikalavimai

  • 1Tiekėjams leidžiama siūlyti alternatyvius (lygiaverčius ar inovatyvius) sprendimus vietoje perkančiosios organizacijos šiuo metu naudojamų ar numatytų sprendimų, tačiau tokie sprendimai privalo atitikti visus pirkimo dokumentuose ir techninėje specifikacijoje nustatytus minimalius reikalavimus bei užtikrinti ne prastesnius funkcinius, techninius ir kokybinius parametrus.
  • 2Visi Tiekėjo kaštai turi būti įskaičiuoti į pasiūlymo kainą.
  • 3Jei tiekėjas siūlo sprendimą, kuris pakeičia perkančiosios organizacijos šiuo metu naudojamus sprendimus (t. y. nėra siūlomas esamų sprendimų palaikymas ar vystymas), tiekėjas privalo apmokyti Užsakovo naudotojus ir administratorius dirbti su siūlomu sprendimu.
  • 4Atlikti ne mažiau kaip 2 savaičių bandomąją eksploataciją.
  • 5Užtikrinti visų esamų duomenų perkėlimą (migravimą) į siūlomą sprendimą, išsaugant duomenų vientisumą, tikslumą ir pilnumą.
  • 6Pateikti aiškų duomenų migravimo planą, apimantį migravimo etapus, naudojamas priemones, rizikas ir jų valdymo priemones.
  • 7Užtikrinti, kad duomenų migravimo metu ir po jo nebus prarasti ar pažeisti duomenys, taip pat bus išlaikytas veiklos tęstinumas.
  • 8Numatyti ir įgyvendinti testavimo bei validavimo procedūras, patvirtinančias sėkmingą duomenų perkėlimą.
  • 9Užtikrinti visų reikalingų integracijų realizaciją.
  • 10Perkančioji organizacija pasilieka teisę vertinti siūlomų alternatyvių sprendimų atitiktį nustatytiems reikalavimams bei atmesti pasiūlymus, kurie neužtikrina tinkamo duomenų migravimo ar neatitinka kitų pirkimo dokumentuose nustatytų sąlygų.

VPS pirkimo sutarčių sudarymo funkcionalumas

  • 1VPS turi būti galimybė susieti sudarytą sutartį su inicijuotu pirkimu.
  • 2VPS turi būti galimybė prie kiekvieno vykdyto pirkimo išsaugoti sudarytą pirkimo sutartį.
  • 3VPS turi būti galimybė derinti, vizuoti, tvirtinti, susipažinti su sutartimi / susijusiais dokumentais.
  • 4VPS turi būti galimybė pridėti ir saugoti sutartis ir sutarčių priedus įvairiais visuotinai pripažįstamais formatais (doc(x), pdf, pasirašytus elektroniniu kvalifikuotu parašu ir kt.,)

DVS pradinis puslapis (darbalaukis) reikalavimai

  • 1DVS pradinis naudotojo langas turi būti parengtas taip, kad kiekvienam naudotojui būtų pateikiama suasmeninta, t. y. konkrečiai jam aktuali, informacija.
  • 2DVS turi būti realizuota galimybė naudotojui nusirodyti, kokia informacija bus rodoma jo pradiniame lange ir keisti šios informacijos išdėstymą.
  • 3DVS turi būti realizuota galimybė iš kiekvieno sąrašo, prie kurio pagal priskirtas teises prieina naudotojas, sukurti sąrašo tipo darbalaukio valdiklį (angl. widget).
  • 4DVS turi būti realizuota galimybė naudotojui susikurti neribotą kiekį pradinio lango darbalaukių ir kiekviename iš jų prisidėti skirtingų tipų valdiklius.
  • 5DVS turi būti realizuota galimybė naudotojui darbalaukyje prisidėti šių tipų valdiklius: Laikas; Užrašai; Nuorodos; Naujienos; Orai; Sąrašas (Mano dokumentai; Vėliausiai redaguoti/peržiūrėti dokumentai; Dažniausiai naudojami dokumentai (angl. favorites); Skelbimai; Sisteminės nuorodos).
  • 6Naudotojų pradiniame lange turi būti galimybė talpinti informaciją bent į ne mažiau kaip du tarpusavyje atskirus blokus, t. y. keisti išdėstymo schemą.

Elektroninio parašo modulio transakcijų kiekiai

  • 1Mobile-ID preliminarus transakcijų kiekis per mėnesį – 3000 vnt.
  • 2SMART-ID preliminarus transakcijų kiekis per mėnesį – 300 vnt.
  • 3LT-ID preliminarus transakcijų kiekis per mėnesį – 20 vnt.
  • 4Laiko žymų uždėjimo preliminarus transakcijų kiekis per mėnesį – 1000 vnt.
  • 5Užsakovas atsiskaito už faktinį elektroninio parašo paslaugų panaudojimą.

DVS dokumentų ruošinių (šablonų) reikalavimai

  • 1Turi būti galimybė kurti, redaguoti, peržiūrėti, naikinti dokumentų ruošinius (šablonus).
  • 2Turi būti galimybė peržiūrėti visų dokumentų ruošinių (šablonų) sąrašą.
  • 3Turi būti galimybė ieškoti dokumentų ruošinių (šablonų) bent pagal šiuos laukus: Antraštė; Tipas; Dokumento tipas; Skirta.
  • 4Kuriant dokumento ruošinį (šabloną) turi būti galimybė nurodyti bent šiuos duomenis: Antraštę; Dokumento tipą, kuriam skirtas ruošinys; Tipą; Failą (docx) formatu.
  • 5DVS turi būti dokumentų projektų ruošinių (šablonų) kūrimo funkcijos. Kuriant dokumento projekto šabloną (ruošinį) turi būti galimybė sukonfigūruoti šablono pildymo formą.
  • 6Turi būti galimybė naudoti MS Word (*.docx) formato failus dokumentų projektų šablonų (ruošinių) formos pildymo konstravimui.
  • 7DVS konfigūruojant dokumento šablono pildymo formą turi būti galimybė nurodyti: Formos laukų pavadinimus; Lauko tipą: Tekstas; Data; Redaktorius; Skaičius; Sisteminis laukas; Požymį, ar privalomas; Pastabą prie lauko.
  • 8DVS turi būti realizuota galimybė kuriant dokumento projektą, failą pasirinkti iš sistemoje registruoto šablono (ruošinio).
  • 9Kuriant dokumentą iš dokumento projekto šablono, turi būti perkeliamos jame nurodytų laukų reikšmės, įskaitant pradinį būsimo dokumento projekto turinį.

DVS naudotojų veiksmų protokolavimo reikalavimai

  • 1DVS visi naudotojų veiksmai, atliekami su dokumentais, jų projektais, užduotimis, turi būti protokoluojami (fiksuojami sistemoje).
  • 2DVS turi būti kaupiama tokia informacija apie veiksmus: a) veiksmas, kuris buvo atliktas sistemoje; b) naudotojas, kuris atliko šį veiksmą; c) data ir laikas, kada veiksmas buvo atliktas.
  • 3DVS turi būti galimybė kiekvieno dokumento kortelėje peržiūrėti atliktus veiksmu: Veiksmai, atlikti su dokumentu, pvz. sukurta, registruota ir kt.; Kiekvieno kortelės atributo pakeitimai (DVS privalo stebėti visų kortelės atributų pasikeitimus).
  • 4DVS veiksmų protokole informacija turi būti neprieinama jokiam modifikavimui, nepaisant naudotojų teisių.
  • 5DVS turi fiksuoti kiekvieno dokumento kortelės (ekrano formos) atidarymą ir dokumento veiksmų protokole įrašyti kortelės peržiūros datą ir peržiūrėjusį naudotoją.
  • 6DVS turi fiksuoti kiekvieno dokumento turinio (prisegto failo) atidarymą ir dokumento veiksmų protokole įrašyti peržiūros datą ir peržiūrėjusį naudotoją. Šis reikalavimas taip pat taikomas dokumento turinį peržiūrint tiesiogiai naršyklėje.
  • 7DVS turi būti bendras su dokumentais atliktų visų veiksmų peržiūros įrankis, kuriame atliktų veiksmų duomenis galima ieškoti pagal dokumento tipą, atliktą veiksmą, veiksmo autorių, veiksmo pastabą.

Duomenų apsaugos ir informacijos saugumo valdymas

  • 1Duomenų sauga turi būti užtikrinta vadovaujantis Raseinių rajono savivaldybės administracijos tinklų ir informacinių sistemų kibernetinio saugumo politika.
  • 2Asmens duomenų apsauga turi būti užtikrinta remiantis Lietuvos Respublikos asmens duomenų teisinės apsaugos įstatymu ir 2016 m. balandžio 27 d. Europos Parlamento ir Tarybos reglamentu (ES) 2016/679 dėl fizinių asmenų apsaugos tvarkant asmens duomenis ir dėl laisvo tokių duomenų judėjimo ir kuriuo panaikinama Direktyva 95/46/EB (Bendrasis duomenų apsaugos reglamentas).
  • 3Sistemoje saugomi duomenys turi būti apsaugoti nuo nesankcionuoto priėjimo, naudojimo, pakeitimo, atskleidimo, sunaikinimo ar praradimo.
  • 4Asmens duomenys perduodami viešais duomenų perdavimo kanalais turi būti šifruojami.
  • 5Draudžiama fizinių asmenų asmens kodus skelbti viešai.
  • 6Sistema turi užtikrinti korektišką avarinių situacijų, kurias sukėlė neteisingi naudotojo ar kitos informacinės sistemos veiksmai, neteisingas įvedimo duomenų formatas arba neleidžiamos įvedamų duomenų reikšmės, valdymą. Naudotojas ar informacinė sistema turi būti informuojami apie tokios situacijos susidarymą ir galimus tolimesnius veiksmus.
  • 7Sistema turi būti apsaugota nuo saugumo spragų, pažeidžiamumo programinėje neautentifikuotos prieigos, nesankcionuoto naudotojo sesijos perėmimo, nesankcionuoto duomenų perėmimo ar jų įterpimo, žalingo kodo įterpimo (angl. Injection, XSS (Cross-sitescripting)) ir kitų saugumo pažeidimų, kurių sąrašas skelbiamas Atviro tinklo programų saugumo (angl. The Open Web Application Security Project (OWASP) interneto svetainėje www.owasp.org).
  • 8Įrangoje, kurią naudojant teikiamos paslaugos, Teikėjas, kurdamas programinę įrangą, turi vadovautis visuotinai pripažintais saugaus kodavimo standartais ir gerąja praktika (angl. The Open Web Application Security Project, OWASP) Secure Coding Practices ar lygiaverte).
  • 9Kuriama programinė įranga neturi turėti nesankcionuotos prieigos prie duomenų ir kitų saugumo pažeidimų, kurie įvardijami naujausiame OWASP Testing Guide (neapsiribojant „OWASP Top 10“ pažeidžiamumais) (https://www.owasp.org) sąraše, The OWASP API Security sąraše ir kt. OWASP parengtose IS saugumo metodikose arba lygiaverčiuose dokumentuose.
  • 10Saugumo patikrinimai (grėsmių modeliavimai, išeities kodo pažiūros ir kt. saugaus kodavimo standartuose ir gerojoje praktikoje numatyti saugumo patikrinimai) turi būti vykdomi kiekviename programinės įrangos kūrimo etape, vadovaujantis Elektroninių paslaugų kūrimo metodika, patvirtinta Lietuvos Respublikos susisiekimo ministro 2015 m. spalio 7 d. įsakymu, nustatančią reikalavimus atsparumo įsilaužimui testavimui, kurį turi atlikti nuo elektroninių paslaugų kūrimą vykdančio subjekto (Teikėjo) nepriklausomas paslaugų teikėjas.
  • 11Atliekant saugumo patikrinimus turi būti remiamasi visuotinai pripažintuose metodikose nurodytais saugumo patikrinimo metodais (OWASP application security verification standard, OWASP Testing Guide, Penetration Testing Execution Standard (PTES), Open Source Security Testing Methodology Manual (OSSTMM), Information Systems Security Assessment Framework (ISSAF), SANS, NIST SP 800-30“ ar lygiavertėmis saugumo patikrinimo metodikomis).
  • 12Sistemos teikiamų žiniatinklio paslaugų sauga turi būti vykdoma vadovaujantis WS-S (Web Services Security) standarto reikalavimais.
  • 13Teikėjas turi naudoti Užsakovo pateiktus reikiamus sertifikatus, skirtus užtikrinti žiniatinklio paslaugų saugą.
  • 14Teikėjas turi nedelsiant informuoti apie sutarties vykdymo metu Užsakovo informacinių technologijų infrastruktūroje pastebėtus elektroninės informacijos, asmens duomenų saugos incidentus, neveikiančias arba netinkamai veikiančias saugos užtikrinimo priemones, informacijos saugumo reikalavimų nesilaikymą, nusikalstamos veikos požymius, Informacinių sistemų saugumo spragas, pažeidžiamumą, kitus svarbius saugai įvykius bei, suderinus su Užsakovu, imtis atitinkamų priemonių ir veiksmų siekiant nustatyti elektroninės informacijos saugos incidentų priežastis, išvengti susijusios rizikos.
  • 15Taip pat pagal kompetenciją vykdyti visus Užsakovo nurodymus ir pavedimus, susijusius su saugos politikos įgyvendinimu.
  • 16Teikdamas paslaugas pagal Sutartyje nustatytus reikalavimus, Teikėjas įsipareigoja laikytis taikomų kibernetinio saugumo reikalavimų ir taikyti tinkamas organizacines ir technines priemones, skirtas apsaugoti informacinių sistemų elektroninę informaciją nuo atsitiktinio ar neteisėto sunaikinimo, pakeitimo, atskleidimo, taip pat nuo bet kokio kito neteisėto tvarkymo, naudoti suteiktą prieigą tik sutarties vykdymo tikslais.

VPS metinio pirkimų plano parengimo funkcionalumas

  • 1VPS turi būti galimybė surinkti pirkimų poreikius metiniam pirkimų planui šiais būdais: pirkimų iniciatoriams pildant metinio pirkimų plano eilutes, įvedant įstaigos nustatytus duomenis; suformuojant metinio pirkimų plano eilutes iš istorinių duomenų, sudarytų iš ankstesniais metais sukauptų duomenų.
  • 2VPS turi būti galimybė pildyti neplanines eilutes ar koreguoti patvirtintas plano eilutes bei siųsti užduotis atsakingiems asmenims tvirtinimui.
  • 3Pirkimų plane turi būti šie laukai, su galimybe redaguoti skirtingus laukus pagal suteiktas teises: unikalus plano eilutės kodas (plano eilutės identifikatorius turi būti sugeneruojamas automatiškai); pirkimo objektas; preliminari pirkimo vertė; planuojama sutarties trukmė; BVPŽ kodas; pirkimo rūšis (prekės, paslaugos, darbai); iniciatorius; projektas (-ai), kuriems skirtas pirkimas; kita svarbi, reikalinga metinio pirkimų plano informacija.
  • 4VPS turi būti galimybė priskirti BVPŽ kodą iš žodyno (turi būti realizuotas BVPŽ kodų klasifikatorius).
  • 5VPS turi būti teisės aktuose nustatyti pirkimo būdai, galimybė juos papildyti, keisti ir galimybė kurti individualius pirkimo būdus.
  • 6VPS turi būti galimybė nustatyti ir keisti siūlomus pirkimo būdus.
  • 7VPS turi būti galimybė centralizuoti (konsoliduoti) pirkimus, inicijuotus skirtingų padalinių. Centralizuoto pirkimo atveju turi būti aiškiai matoma, kurios pirkimų plano eilutės apjungtos, kiekvieno pirkimo detali informacija.
  • 8VPS turi būti galimybė derinti, vizuoti, tvirtinti, teikti susipažinimui metinio pirkimų plano projektą ir patvirtintą planą, jo pakeitimus, remiantis įstaigos organizacine struktūra, su galimybe įtraukti papildomus naudotojus.
  • 9VPS turi būti galimybė tvirtinti, keisti, eksportuoti, spausdinti metinio pirkimų plano versiją.
  • 10VPS turi būti galimybė peržiūrėti visas ankstesnes pirkimų plano versijas bei pirminę plano versiją.
  • 11VPS turi būti galimybė eksportuoti metinio pirkimų plano duomenis į xls(x), pdf formatus bei importui į CVP IS sistemai tinkamu formatu.
  • 12VPS turi būti galimybė pasirinkti visus arba tik dalį pagal įstaigos pasirinktus kriterijus pirkimų, kurie bus eksportuojami į xls(x), pdf formato bylas bei importui į CVP IS sistemą paruoštą formą.
  • 13VPS turi būti galimybė filtruoti metinio pirkimų plano eilutes pagal atskirus požymius (pvz., pirkimų būdai, padaliniai, vertės, objektai, inicijavimo terminai ir kt.).
  • 14VPS turi būti galimybė iš pirkimų plano eilutės inicijuoti tolesnius pirkimo žingsnius (pirkimo inicijavimo dokumento rengimas, pirkimo bylos rengimas).
  • 15Metinis pirkimo planas gali būti formuojamas įtraukiant tik iš poreikių kataloge esančių prekių / paslaugų / darbų.
  • 16VPS turi būti galimybė pirkimų plano eilutę susieti su pirkimo sutartimi, sąskaita faktūra, ataskaita.
  • 17VPS turi būti galimybė viešinti metinį pirkimų planą, mažos vertės pirkimų įstaigos ataskaitas svetainėje, importuojant duomenis tiesiogiai iš VP sistemos.

DVS dokumentų archyvavimo ir naikinimo reikalavimai

  • 1DVS turi būti įgyvendinta galimybė automatizuoti dokumentų archyvavimo procesus bei archyvuotų dokumentų saugojimo valdymą.
  • 2DVS turi būti galimybė kurti archyvavimo taisykles skirtingiems objektams (dokumentams, pavedimams, sutartims).
  • 3DVS turi būti galimybė kurti šias automatizuotas taisykles: Dokumentų priskyrimas byloms; Ilgalaikio saugojimo bylų atrinkimas perdavimui į archyvą; Archyvinių bylų atrinkimas naikinti; Archyvinių bylų naikinimas; Trumpalaikio saugojimo bylų atrinkimas perdavimui į archyvą; Trumpalaikio saugojimo bylų naikinimas; Kitų sistemos objektų atrinkimas į archyvą naikinti; Kitų sistemos objektų naikinimas; Registrų duomenų naikinimas.
  • 4DVS turi galimybė susieti dokumentą su archyvuotu dokumentu.
  • 5DVS turi būti galimybė sudaryti archyvuotų bylų ataskaitas.
  • 6DVS automatizuotai pagal nustatytas taisykles turi paruošti perkelti dokumentus į archyvą.
  • 7DVS turi leisti perkelti skirtingus objektus į archyvą rankiniu būdu.
  • 8DVS turi būti galimybė kurti naikinimo taisykles nurodant datą ir laiką, kada bus vykdomas dokumentų perkėlimas archyvą ir naikinimas.
  • 9DVS turi būti įgyvendinta nesaugotinos informacijos pašalinimo iš archyvo funkcija. Atlikus šią funkciją, turi būti: fiziškai ištrinami įrašai iš duomenų bazės; fiziškai ištrinamas dokumentų turinys (failai).

DVS veiklos procesų (workflow) valdymo reikalavimai

  • 1DVS turi būti realizuota galimybė konfigūravimo būdu (be programavimo) kurti dokumentų procesų ruošinius ir juos redaguoti.
  • 2Dokumentų procesai ir jų ruošiniai turi būti rengiami ir redaguojami integruotoje grafinėje DVS sąsajoje be papildomos programinės įrangos diegimo darbo vietos kompiuteriuose.
  • 3Grafinis procesų konstravimo įrankis turi būti DVS sudedamoji dalis, pasiekiama tiesiogiai iš DVS, t. y. naršyklėje konstruojant proceso eigą „įtempk ir paleisk“ (angl. drag-and-drop) principu.
  • 4DVS turi būti galimybė kiekvienam dokumento tipui individualiai pasirinkti procesus, kurie galimi atitinkamam dokumento tipui.
  • 5DVS turi būti galimybė peržiūrėti visų proceso ruošinių sąrašą, kuriame pateikiami duomenys: Reg. Nr.; Reg. Data; Antraštė; Objekto tipas.
  • 6DVS turi būti galimybė kuriant veiklos procesą nurodyti: Registrą; Antraštę; Objektą, kuriam skirtas; Objekto registrą; Galiojimo datą nuo/iki.
  • 7Veiklos procesų ruošinius galima vykdyti tik tada, kai ateina nustatyta data.
  • 8Sistemoje sukūrus dokumentą ar jo projektą (pirmą kartą išsaugojus dokumento kortelę), turi būti galimybė automatiškai pradėti/startuoti numatytą procesą be jokių naudotojo atliekamų veiksmų.
  • 9Turi būti galimybė įjungti/išjungti šios funkcijos vykdymą kiekvieno dokumento tipo registro kortelėje nurodant, koks veiklos procesas turi pradėti būti vykdomas ar pašalinant parinktą šabloną.
  • 10Turi būti galimybė rankiniu būdu inicijuoti proceso vykdomą. Inicijuoti galima tik tuos procesus, kurių šablonai leidžiami atitinkamam dokumentų tipui.
  • 11Vykdant procesą, turi būti galimybė iš dokumento, kuriam vykdomas procesas, kortelės peržiūrėti vykdomo proceso eigą grafinėje aplinkoje (UML flowchart tipo arba lygiaverčiame grafike), aiškiai išskiriant tuo metu vykdomą (-us) žingsnį (-ius).
  • 12Aprašant naudotojo atliekamus žingsnius, turi būti galimybė rankiniu būdu nurodyti kuratorių – asmenį, kuris kontroliuos užduoties vykdymą.
  • 13Proceso žingsnių vykdytojai ir kuratoriai turi turėti galimybė sustabdyti ir atšaukti procesą, jeigu jiems tokia teisė buvo suteikta konstruojant atitinkamą proceso šabloną.
  • 14Proceso žingsnių vykdytojai ir kuratoriai turi turėti galimybę praleisti proceso žingsnį (-ius), jeigu jiems tokia teisė buvo suteikta konstruojant atitinkamą proceso šabloną.
  • 15Kuriant procesų ruošinius grafinėje aplinkoje, DVS turi pateikti galimus proceso konstravimui panaudoti veiksmus: Nurodyti proceso pradžią ir pabaigą; Naudotojų atliekamus žingsnius; Automatinius sistemos atliekamus žingsnius; Proceso eigos išsišakojimus ir susijungimus.
  • 16Kuriant procesų ruošinius grafinėje aplinkoje ir aprašant proceso eigos išsišakojimus, turi būti galimybė aprašyti išsišakojimo sąlygas, priklausančias nuo dokumento, kuriam vykdomas procesas, metaduomenų reikšmių, pvz. sutartis turi būti pateikta susipažinti vienu iš kelių galimų 2 (dviejų) kelių priklausomai nuo atributo „Suma“ reikšmės.
  • 17Aprašant išsišakojimo sąlygas, priklausančias nuo dokumento metaduomenų reikšmių, turi būti galimybė aprašyti sudėtines sąlygas, naudojant šiuos duomenis: Imant kelių atributų reikšmes; Imant kitas DVS saugojamas reikšmes, susijusias su konkretaus dokumento, kuriam vykdomas procesas, reikšmėmis. Turi būti galimybė sudėtines sąlygas tarpusavyje sujungti naudojant loginius operatorius IR („and“) , ARBA („or“).
  • 18Pasirinkus veiklos proceso pradžios elementą turi būti galimybė nurodyti pavadinimą.
  • 19Pasirinkus veiklos proceso pabaigos elementą turi būti galimybė nurodyti pavadinimą.
  • 20Pasirinkus veiklos proceso jungties elementą turi būti galimybė nurodyti pavadinimą.
  • 21Pasirinkus veiklos proceso veiklos elementą turi būti galimybė nurodyti: Pavadinimą; Aprašymą; Veiksmo tipą (sisteminis, naudotojo); Veiksmą.
  • 22Turi būti galimybė pasirinkti veiksmo tipo „Sisteminis“ veiksmą „El. laiško išsiuntimas“.
  • 23Turi būt galimybė pasirinkus veiksmą „El. laiško išsiuntimas“ nurodyti šiuos parametrus: Gavėjus (tiesioginiai); Gavėjai (kopija); Gavėjai (slapta kopija); Antraštė; Požymis, ar siunčiami failai; Turinys.
  • 24Turi būti realizuotas teksto redaktorius veiksmo „El. laiško išsiuntimas“ turinio nurodymui. Turi būti galimybe įterpti paveikslėlius, lenteles, lygiuoti, numeruoti, paryškinti, paversti turinio tekstą.
  • 25Turi būti galimybė pasirinkti veiksmo tipo „Sisteminis“ veiksmą „Darbų seko šablono priskyrimas“.
  • 26Turi būt galimybė pasirinkus veiksmą „Darbų seko šablono priskyrimas“ nurodyti iš anksto sukurtą konkrečia darbų seką.
  • 27Turi būti galimybė pasirinkti veiksmo tipo „Sisteminis“ veiksmą „Darbų sekos veiksmas“.
  • 28Turi būt galimybė pasirinkus veiksmą „Darbų sekos veiksmas“ nurodyti šiuos parametrus: Veiksmo parametrus: Data nuo/iki; Veiksmas (vizavimas, pasirašymas, tvirtinimas); Turi būti galimybė sukurti veiksmą, priskiriant mygtuko pavadinimą. Turi būti galimybė nurodyti, ar tai paskutinis sekos veiksmas; Subjekto informaciją; Data nuo/iki ar atlikimo periodas; Subjektas; Grupė; Pastabos.
  • 29Turi būti galimybė pasirinkti veiksmo tipo „Sisteminis“ veiksmą „Dokumento pateikimas susipažinti“.
  • 30Turi būt galimybė pasirinkus veiksmą „Dokumento pateikimas susipažinti“ nurodyti šiuos parametrus: Subjektai; Grupės; Pareigybės; Pastabos; Požymis, ar susipažinimo faktas pasirašomas el. parašu; Požymis, ar dokumentas pateikiamas „žiniai“.
  • 31Turi būti galimybė pasirinkti veiksmo tipo „Sisteminis“ veiksmą „Pavedimo sukūrimas“.
  • 32Turi būt galimybė pasirinkus veiksmą „Pavedimo sukūrimas“ nurodyti šiuos parametrus: Registras; Byla; Reg. data; Tipas; Turinys; Patikslinimas; Pastabos; Teikėjas; Kuratorius; Vykdytojai (su galimybe nurodyti požymį, kuris pagrindinis).
  • 33Turi būti galimybė pasirinkti veiksmo tipo „Sisteminis“ veiksmą „Rezoliucijos sukūrimas“.
  • 34Turi būt galimybė pasirinkus veiksmą „Rezoliucijos sukūrimas“ nurodyti šiuos parametrus: Registras; Teikimo data; Teikėjas; Teikėjo patikslinimas; Įvykdyti iki; Veiklos tipas; Rezoliucijos turinys; Požymis, ar įtraukti rezoliucijos tekstą į skenuojamą dokumentą; Vykdytojai (su galimybe nurodyti požymį, kuris pagrindinis).
  • 35Turi būti galimybė pasirinkti veiksmo tipo „Sisteminis“ veiksmą „Rengiamo dokumento registravimas“. Vykdant procesą su tokiu žingsniu, dokumentas turi būti automatiškai užregistruojamas be jokių naudotojo atliekamų veiksmų.
  • 36Turi būti galimybė pasirinkti veiksmo tipo „Naudotojo“ veiksmą „Darbų sekos sprendimo priėmimas“.
  • 37Turi būt galimybė pasirinkus veiksmą „Darbų sekos sprendimo priėmimas“ nurodyti šiuos parametrus: Priimantį sprendimą subjektą; Veiksmą (derinimas, vizavimas, pasirašymas, Tvirtinimas, Registravimas); Sprendimą (Pritarta, atmesta, nepritarta); Kuratorių; Požymį, ar leisti kuratoriui nutraukti procesą; Požymį, ar leisti kuratoriui stabdyti procesą; Požymį, ar leisti kuratoriui praleisti proceso žingsnį; Požymį, ar leisti vykdytojui nutraukti procesą; Požymį, ar leisti vykdytojui stabdyti procesą; Požymį, ar leisti vykdytojui praleisti proceso žingsnį.
  • 38Turi būti galimybė pasirinkti veiksmo tipo „Naudotojo“ veiksmą „Susipažinimas su dokumentu“.
  • 39Turi būt galimybė pasirinkus veiksmą „Susipažinimas su dokumentu“ nurodyti šiuos parametrus: Subjektą; Kuratorių; Požymį, ar leisti kuratoriui nutraukti procesą; Požymį, ar leisti kuratoriui stabdyti procesą; Požymį, ar leisti kuratoriui praleisti proceso žingsnį; Požymį, ar leisti vykdytojui nutraukti procesą; Požymį, ar leisti vykdytojui stabdyti procesą; Požymį, ar leisti vykdytojui praleisti proceso žingsnį.
  • 40Turi būti galimybė žingsnio pavadinimą imti iš dokumento metaduomenų reikšmių, t. y. dokumento, cesas, pasirinkto atributo reikšmės.
  • 41Grafinė procesų modeliavimo sąsaja turi leisti proceso vykdymo grafinę seką eksportuoti į grafinio formato failus: jpg, png, bmp, svg formatais.

DVS informacijos paieškos ir peržiūros reikalavimai

  • 1DVS turi būti informacijos paieškos ir peržiūros priemonės.
  • 2DVS paieškos mechanizmas turi grąžinti tik tą informaciją, kuri paiešką vykdančiam naudotojui yra prieinama pagal saugumo nustatymus (prieigos teises).
  • 3DVS turi būti realizuota pilnatekstės paieškos funkcija dokumento kortelės rekvizituose ir turinyje (tarp jų ir MS Office, Libre Office formatu paruoštose bylose bei atpažintuose skenuotuose dokumentuose).
  • 4DVS turi būti realizuota galimybė atlikti visų registruotų DVS dokumentų paiešką „Bendroji paieška“ pagal išvardintą dokumentų registravimo informaciją.
  • 5DVS turi būti realizuota galimybė „Bendrąją dokumentų“ paiešką vykdyti vieno lauko principu.
  • 6DVS turi būti galimybė išsaugoti paieškos rezultatus XLSX, PDF formatais.
  • 7DVS turi būti galimybė ekrane matomus dokumentų sąrašus eksportuoti į MS Excel ir PDF rinkmenas, t. y. į Excel ir PDF bylą įtraukiant ekrane matomus duomenis.
  • 8DVS turi būti realizuota galimybė sukurti sistemines ir asmenines dokumentų išplėstinės paieškos formas, pažymint: nustatyti paieškos formos pavadinimą; nustatyti, ar aktyvi; nustatyti, ar paieškos forma naudojama pagal nutylėjimą; pažymėti standartinius paieškos kriterijus kaip naudojamus ar nenaudojamus. Turi būti galimybė keisti išplėstinės paieškos laukų grupes ir laukus grupėse vietomis.
  • 9DVS turi būti realizuota galimybė naudotojams išsisaugoti paieškos kriterijus ir vėliau galimybė jais pasinaudoti.
  • 10DVS turi būti realizuota galimybė ieškoti dokumentų pagal dokumento tipus, t. y. pasirinkus konkretų dokumento tipą, naudotojas turi galimybę užpildyti tik konkrečiam dokumentų tipui galimus paieškos kriterijus.
  • 11Turi būti realizuota galimybė peržiūrėti DVS patalpintų dokumentų (MS Office bylų, PDF dokumentų, atvaizdų) turinį tiesiogiai naršyklės lange, neatidarant specialių dokumentų redagavimui ar peržiūrai skirtų programų.
  • 12DVS turi būti galimybė pagrindiniuose dokumentų sąrašuose keisti stulpelius vietomis.
  • 13DVS turi būti galimybė pagrindiniuose dokumentų sąrašuose išjungti/įjungti stulpelių rodymą.
  • 14DVS turi būti galimybė pagrindiniuose dokumentų sąrašuose rikiuoti duomenis didėjimo/mažėjimo tvarka.
  • 15DVS turi būti galimybė pagrindiniuose dokumentų sąrašų pagrindiniuose stulpeliuose vykdyti paiešką su loginiais operatoriais „IR“ ir „ARBA“.
  • 16DVS turi būti galimybė pagrindiniuose dokumentų sąrašų pagrindiniuose stulpeliuose vykdyti paiešką nurodant paieškos žodžio fragmentas: Lygu; Nelygu; Prasideda; Turi; Neturi; Baigiasi.
  • 17DVS turi būti galimybė pagrindiniuose dokumentų išsaugoti sudarytą vaizdą iš sukeistų, išjungtų stulpelių vietomis, atliktu rikiavimu.
  • 18DVS turi būti galimybė neribotai kurti pagrindinių dokumentų sąrašų vaizdus kiekvienam naudotojui.

Finansų valdymo ir apskaitos sistemos (FVAS) reikalavimai

  • 1Turto valdymas ir apskaita: FVAS turto valdymo funkcionalumas turi apimti sisteminį turto objektų duomenų administravimą ir būti suskirstytas į du atskirus modulius: ilgalaikio turto ir atsargų apskaitą.
  • 2FVAS turto valdymo sistema turi užtikrinti automatizuotą turto objektų kortelių generavimą pagal registruotus gautus dokumentus (pvz., sąskaitas faktūras), taip sukuriant sąsają su pirminiais dokumentais.
  • 3FVAS turto valdymo sistema turi užtikrinti atskirų modulių veikimą pagal skirtingus apskaitos principus ir taisykles, nustatytus VSAFAS.
  • 4Ilgalaikio turto modulis turi suteikti galimybę kaupti informaciją apie nekilnojamojo turto nuomos, panaudos ar kitų perdavimo sutarčių duomenis.
  • 5Ilgalaikio turto modulis turi registruoti turto draudimo informaciją, remonto išlaidas, kadastro duomenis ir kitus identifikavimo požymius.
  • 6Ilgalaikio turto modulis turi vykdyti automatizuotą periodinį nusidėvėjimo skaičiavimą.
  • 7Atsargų modulis turi būti skirtas medžiagų ir ūkinio inventoriaus apskaitai (balansinei ir užbalansinei).
  • 8Atsargų modulis turi būti skirtas duomenų sisteminimui ir turto inventorizacijos vykdymui.
  • 9Atsargų modulis turi būti skirtas standartinių ataskaitų formų generavimui kasdieniam naudojimui.
  • 10Gautinų ir mokėtinų sumų apskaita: FVAS pinigų valdymo modulis turi būti skirtas gautinų ir mokėtinų sumų apskaitai bei kontrolei.
  • 11Gautinų ir mokėtinų sumų modulis turi užtikrinti savalaikį atsiskaitymą už prekes, paslaugas ir darbus.
  • 12Gautinų ir mokėtinų sumų modulis turi užtikrinti dvigubo apmokėjimo rizikos prevenciją.
  • 13Gautinų ir mokėtinų sumų modulis turi užtikrinti įsiskolinimų valdymą tiek įstaigos, tiek pirkėjų atžvilgiu.
  • 14Gautinų ir mokėtinų sumų modulis turi automatiškai registruoti finansavimo pajamų pripažinimo įrašus pagal VSAFAS reikalavimus, kai patiriamos sąnaudos, kurioms kompensuoti skirtos finansavimo lėšos.
  • 15Gautinų ir mokėtinų sumų modulis turi leisti formuoti mokėjimo nurodymų sąrašus ir eksportuoti juos LITAS ESIS ar SEPA formatais, tinkamais elektroninės bankininkystės sistemoms.
  • 16Biudžeto vykdymas ir kontrolė: FVAS finansavimo modulis turi būti skirtas biudžeto vykdymo duomenų administravimui ir kontrolei.
  • 17Biudžeto vykdymo modulis turi užtikrinti asignavimų valdytojų (pavaldžių įstaigų) duomenų (sąmatų, paraiškų, biudžeto vykdymo ataskaitų) įvedimą.
  • 18Biudžeto vykdymo modulis turi užtikrinti šių duomenų perdavimą savivaldybės Finansų ir strateginio planavimo skyriui.
  • 19Biudžeto vykdymo modulis turi užtikrinti savivaldybės Finansų ir strateginio planavimo skyriui biudžeto vykdymo apskaitos ir kontrolės funkcionalumą.
  • 20Biudžeto vykdymo modulis turi sudaryti galimybę pavaldžioms įstaigoms automatizuotai teikti paraiškas, o savivaldybės finansų ir strateginio planavimo skyriaus darbuotojams – jas tvirtinti, atmesti, analizuoti ir priimti sprendimus dėl finansavimo.
  • 21Paraiškų valdymas turi būti griežtai susietas su sąmatų vykdymu, taip užtikrinant automatinę biudžeto vykdymo kontrolę.
  • 22Biudžeto vykdymo modulis turi leisti automatiškai parengti biudžeto vykdymo ataskaitas asignavimų valdytojams.
  • 23Biudžeto vykdymo modulis turi leisti formuoti konsoliduotas biudžeto vykdymo ataskaitas.
  • 24Biudžeto vykdymo modulis turi leisti eksportuoti ataskaitas LR finansų ministerijos patvirtintu formatu.
  • 25Darbo užmokesčio apskaita: FVAS darbo užmokesčio modulis turi būti sukurtas vadovaujantis Lietuvos Respublikos darbo kodeksu, Valstybės tarnybos įstatymu ir kitais teisės aktais, reglamentuojančiais darbo užmokesčio apskaičiavimą.
  • 26Darbo užmokesčio modulis turi užtikrinti detalių darbo užmokestį sudarančių elementų apskaitą pagal kiekvieno darbuotojo sutarties tipą.
  • 27Darbo užmokesčio modulis turi užtikrinti skirtingų sutarčių rūšių (valstybės tarnautojų, darbo, autorinių, pedagogų) darbo užmokesčio apskaičiavimo ypatumų taikymą.
  • 28Darbo užmokesčio modulis turi užtikrinti galimybę kurti individualius priskaitymų ir išskaitymų tipus, taikomus konkrečioje įstaigoje.
  • 29Darbo užmokesčio modulis turi užtikrinti darbo užmokesčio skaičiavimą iš kelių finansavimo šaltinių.
  • 30Darbo užmokesčio modulis turi užtikrinti ataskaitų formavimą ir duomenų eksportą į SODRA, VMI patvirtintus formatus bei jų perdavimą į atitinkamas institucijų sistemas.
  • 31Įnašų (rinkliavų) apskaita: FVAS įnašų modulis turi būti skirtas rinkliavų iš paslaugų gavėjų apskaitai ir automatiniam įnašų apskaičiavimui.
  • 32Įnašų modulis turi suteikti galimybę apskaičiuoti kiekvieno paslaugos gavėjo įnašo sumą pagal paslaugos tipą ir įkainį.
  • 33Įnašų modulis turi suformuoti kvitus apmokėjimui.
  • 34Įnašų modulis turi stebėti kiekvieno paslaugos gavėjo įsiskolinimus.
  • 35Maisto produktų apskaita: FVAS maisto produktų modulis turi būti skirtas maisto produktų darželyje ar kitose įstaigose apskaitai pagal VSAFAS reikalavimus.
  • 36Maisto produktų modulis turi užtikrinti maisto produktų apskaitą taikant FIFO metodą.
  • 37Maisto produktų modulis turi užtikrinti produktų nurašymą pagal valgančiųjų kategorijas, mitybos normas ir produktų kainas.
  • 38Maisto produktų modulis turi užtikrinti galimybę stebėti maisto sąnaudų ekonomiją ir efektyvumą.
  • 39Finansinės atskaitomybės sudarymas: FVAS didžiosios knygos modulyje ir atskirų funkcinių sričių moduliuose turi būti galimybė generuoti finansines ataskaitas pagal VSAFAS reikalavimus remiantis sistemoje registruotų ūkinių operacijų ir ūkinių įvykių įrašų naudotojo pageidaujamu detalumo lygiu.
  • 40Rengiant konsoliduotas finansinės atskaitomybės ataskaitas, Sistema turi užtikrinti galimybę eliminuoti įrašus tarp susijusių subjektų.
  • 41Konsolidavimas: Turi būti užtikrintas subjektų duomenų paruošimas perdavimui į konsolidavimo sistemą.
  • 42FVAS konsolidavimo modulio funkcionalumas turi užtikrinti galimybę parengti finansinės atskaitomybės ataskaitų rinkinius, tinkamus perduoti į LR finansų ministerijos Viešojo sektoriaus apskaitos ir ataskaitų konsolidavimo informacinę sistemą VSAKIS.

DVS dokumentų registravimo, kaupimo ir valdymo reikalavimai

  • 1DVS turi turėti realizuotą dokumentų registravimo funkciją, kuria būtų galima užfiksuoti visus dokumentą identifikuojančius duomenis.
  • 2DVS turi būti galimybė registruoti šių tipų dokumentus: Gauti dokumentai (juridinių ir fizinių asmenų); Siunčiami dokumentai; Vidaus dokumentai; Teisės aktai; Protokolai; Sutartys.
  • 3DVS turi būti galimybė registruojant gautą dokumentą iš juridinio asmens nurodyti išvardintus parametrus.
  • 4DVS turi būti galimybė peržiūrėti gautų iš juridinių asmenų dokumentų sąrašą atvaizduojant išvardintus duomenis.
  • 5DVS turi būti galimybė ieškoti gautų iš juridinių asmenų dokumentų pagal lauką „Rodyti“, kurio reikšmės: atsakyti per 3 dienas, atsakyti per 7 dienas, kontroliuojami, nauji, nekontroliuojami, nėra „mano“ vykdymo įrašo, nukreipta man, pakeisti, pavedimo pagrindas, vėluojantys.
  • 6DVS turi būti galimybė ieškoti gautų iš juridinių asmenų dokumentų pagal išvardintus laukus.
  • 7DVS turi būti galimybė registruojant gautą dokumentą iš fizinio asmens nurodyti išvardintus parametrus.
  • 8DVS turi būti galimybė peržiūrėti gautų iš fizinių asmenų dokumentų sąrašą atvaizduojant išvardintus duomenis.
  • 9DVS turi būti galimybė ieškoti gautų iš fizinių asmenų dokumentų pagal išvardintus parametrus.
  • 10DVS turi būti galimybė registruojant siunčiamą dokumentą nurodyti išvardintus parametrus.
  • 11DVS turi būti galimybė peržiūrėti siunčiamų dokumentų sąrašą atvaizduojant išvardintus duomenis.
  • 12DVS turi būti galimybė ieškoti siunčiamų dokumentų pagal išvardintus parametrus.
  • 13DVS turi būti galimybė registruojant vidaus dokumentą nurodyti išvardintus parametrus.
  • 14DVS turi būti galimybė peržiūrėti vidaus dokumentų sąrašą atvaizduojant išvardintus duomenis.
  • 15DVS turi būti galimybė ieškoti vidaus dokumentų pagal išvardintus parametrus.
  • 16DVS turi būti galimybė registruojant teisės aktą nurodyti išvardintus parametrus.
  • 17DVS turi būti galimybė peržiūrėti teisės aktų sąrašą atvaizduojant išvardintus duomenis.
  • 18DVS turi būti galimybė ieškoti teisės aktų pagal išvardintus parametrus.
  • 19DVS turi būti galimybė registruojant protokolą nurodyti išvardintus parametrus.
  • 20DVS turi būti galimybė peržiūrėti protokolų sąrašą atvaizduojant išvardintus duomenis.
  • 21DVS turi būti galimybė ieškoti protokolų pagal išvardintus parametrus.
  • 22DVS turi būti galimybė registruojant sutartį dokumentą nurodyti išvardintus parametrus.
  • 23DVS turi būti galimybė peržiūrėti sutarčių sąrašą atvaizduojant išvardintus duomenis.
  • 24DVS turi būti galimybė ieškoti sutarčių pagal išvardintus parametrus.
  • 25DVS turi leisti į dokumento kortelėje esantį skenuotą dokumento atvaizdą PDF formate automatiškai įdėti dokumento gavimo arba kitą žymą („spaudą“).
  • 26DVS turi būti galimybė kurti ir modifikuoti skirtingas žymas („spaudus“) PDF formato dokumentams ir jų konfigūracijas.
  • 27Kuriant ir modifikuojant skirtingus dokumento žymas („spaudus“) PDF formato dokumentams, turi būti galimybės: Nurodyti „spaudo“ pavadinimą; Nurodyti „spaudo“ šriftą ir jo dydį, spalvą, vietą PDF dokumente ir kitus parametrus, apibrėžiančius „spaudo“ išvaizdą ir vietą.
  • 28Kuriant ir modifikuojant skirtingus elektroninio dokumento žymas („spaudus“) PDF formato dokumentams, turi būti galimybė aprašyti duomenų pateikimo struktūras, nurodant tiek statinį tekstą, tiek galimybę gauti duomenis iš konkretaus dokumento metaduomenų (pvz.: registracijos numeris, registracijos data).
  • 29DVS turi būti galimybė dokumento turinį (*.docx, *.xlsx, *.pptx, grafinio formato bylas) konvertuoti į vieną ar atskiras *.pdf bylas; Turi būti galimybė konvertavimo į PDF metu kiekvienam formuojamam PDF failui nurodyti žymą („spaudą“), kuri bus įkeliama konvertavimo metu.
  • 30DVS turi leisti susieti registruojamą dokumentą su kitais, sistemoje jau užregistruotais, dokumentais.
  • 31DVS turi leisti susieti registruotą dokumentą su neribotu kiekiu kitų dokumentų, pasirenkant norimus sieti dokumentus iš sąrašo.
  • 32DVS registruojant dokumentą turi leisti pridėti ir į sistemą įvesti išorinėse kompiuterizuotų darbo vietų (KDV) duomenų laikmenose saugomas rinkmenas įvairiais formatais (pvz.: *.doc, *.docx, *.rtf, *.wav, *.xls, *.xlsx, *.ppt, *.html, *.jpg, *.gif, *.png, *.tiff, *.pdf).
  • 33DVS turi leisti tiesiai iš sistemos skenuoti dokumentus (be būtinybės atidaryti atskirą programą ir išsaugoti skenuotą dokumentą darbo vietos kompiuteryje) ir juos automatiškai patalpinti į sistemą PDF, BMP, JPEG, TIFF, PNG formatais.
  • 34Skenavimo į DVS funkcija turi leisti: iškirpti nuskenuoto dokumento sritį (angl. crop); pasukti nuskenuotą lapą; nurodyti, kokia rezoliucija (skiriamąją gebą) skenuojama; nurodyti, skenavimo spalvą: spalvotai, pilkais atspalviais, juodai baltai (jei skeneris tai leidžia); Pasirinkti, ar dokumento šaltinį: vienpusis, dvipusis (jei skeneris tai leidžia).
  • 35DVS turi leisti sukurti visus organizacijoje naudojamus dokumentų registrus neribojant jų kiekio.
  • 36DVS registruojant dokumentą turi būti galimybė pasirinkti reikiamą registrą iš konkrečiam padaliniui priskirto registrų sąrašo.
  • 37DVS turi būti realizuota funkcija automatiškai generuoti dokumento registracijos numerį.
  • 38DVS turi būti realizuota funkcija, leidžianti sistemos administratoriui aprašyti dokumento registracijos numerio generavimo taisykles (formatą).
  • 39DVS suteiktas dokumento registracijos numeris turi būti unikalus.
  • 40DVS turi būti galima papildyti dokumento aprašą (registracijos kortelę) šia informacija: tema; turinys (pridėtos rinkmenos); pastabos; dokumento lapų skaičius; priedų lapų skaičius; dokumento rūšis (raštas, įsakymas, potvarkis, sutartis ir kt.); darbuotojų, rengusių dokumentą, sąrašas; darbuotojų, vizavusių dokumentą, sąrašas; darbuotojų, susipažinusių su dokumentu, sąrašas; dokumento siuntėjas ir gavėjas.
  • 41DVS turi būti vykdoma interaktyvi gautų dokumentų registracijos dubliavimo išvengimo kontrolė (turi veikti tikruoju laiku, registratoriui neatliekant jokių papildomų veiksmų).
  • 42DVS turi būti realizuota galimybė užregistravus siunčiamą dokumentą, tiesiai iš dokumento kortelės išsiųsti jį gavėjui el. paštu.
  • 43DVS turi būti galimybė nukreipti registruotus dokumentus rezoliucijai užrašyti.
  • 44DVS turi būti realizuota galimybė informuoti apie klaidingą siuntimą rezoliucijai užrašyti.
  • 45DVS turi būti realizuota galimybė įvesti kelias rezoliucijas lygiagrečiai.
  • 46DVS realizuota galimybė rezoliucijoje nurodyti daugiau kaip vieną atsakingą vykdytoją.
  • 47DVS turi būti realizuota galimybė atšaukti rezoliuciją.
  • 48DVS turi būti realizuota galimybė perduoti toliau rezoliuciją. Perduodant toliau rezoliuciją, neturi būti ribojamas persiuntimų kiekis.
  • 49DVS turi būti realizuota galimybė elektroniniu paštu informuoti rezoliucijos vykdytoją (-us) apie perduotą toliau dokumentą.
  • 50DVS rezoliucijos rašymo metu turi būti nurodyta ši informacija: rezoliucijos teikėjas; teikėjo patikslinimas; rezoliucijos turinys; veiklos tipas; atsakingi vykdytojai (darbuotojai, atsakingi už rezoliucijos vykdymą). Turi būti galimybė nurodyti pagrindinį vykdytoją; įvykdymo terminas.
  • 51DVS turi būti realizuota galimybė elektroniniu paštu informuoti rezoliucijoje nurodytus asmenis apie rezoliucijos paskyrimą.
  • 52Turi būti galimybė formuoti rezoliucijas (paskiriant dokumentus vykdyti) pažymint keletą dokumentų ir vienu metu paskiriant vienodas rezoliucijas (tokia pat rezoliucija, tas pats rezoliucijos autorius, tas pats kuratorius ir (ar) vykdytojas).
  • 53Dokumento rezoliucijų vykdymo istorija turi būti vaizduojama tiek sąrašu, tiek grafiniu medžio tipo elementu. Turi būti galimybė suskleisti/išskleisti konkretaus lygio rezoliucijų vykdymo istorijos medžio šakas.
  • 54DVS turi būti realizuota darbuotojų supažindinimo su dokumentu funkcija, leidžianti darbuotojui pažymėti susipažinimo faktą. Funkcijos inicijavimo metu turi būti nurodomas darbuotojų ir (ar) jų grupių, kuriems (-ioms) reikia susipažinti su dokumentu, sąrašas.
  • 55DVS turi būti realizuota galimybė dokumentą perduoti „žiniai“. Tokio dokumento kortelėje nebūtina pažymėti susipažinimo fakto, tačiau darbuotojui suteikiama galimybė peržiūrėti dokumento kortelės metaduomenis, skaityti turinio rinkmenas.
  • 56DVS turi būti realizuota galimybė darbuotojui pažymėti susipažinimą su dokumentu.
  • 57DVS turi būti realizuota galimybė matyti konkretaus darbuotojo susipažinimo su dokumentu faktą ir susipažinimo datą.
  • 58DVS turi būti realizuota galimybė sukurti dokumentą iš kito dokumento kortelės (kopijuoti dokumentą).
  • 59Nukopijavus dokumentą, DVS turi leisti iškart pakeisti naujos dokumento kopijos reikšmes dar prieš išsaugant dokumentą sistemoje.
  • 60DVS turi leisti aprašyti įvairius dokumentų tipus, nurodant kiekvienam tipui būdingus registracinius rekvizitus, su galimybe administratoriui pridėti naujus informacinius rekvizitus.
  • 61DVS turi leisti klasifikuoti dokumentus pagal organizacijos nustatytas taisykles.
  • 62DVS turi būti realizuota galimybė turėti skirtingus metaduomenimis, aprašančius dokumentą, priklausomai nuo dokumento rūšies (įsakymas, raštas, sutartis, leidimas/licencija ar kt.).
  • 63Siunčiant dokumentą el. paštu, turi būti galimybė pasirinkti gavėjus, siunčiamas failus (arba prieš siunčiant pašalinti nereikalingus failus), nurodyti turinį (turi būti galimybė formatuoti tekstą, įkelti paveikslėlius), kam siunčiama kopija, slapta kopija.

DVS optinio simbolių atpažinimo (OCR) šablonų reikalavimai

  • 1DVS turi būti galimybė konfigūruoti optinio simbolių atpažinimo (angl. OCR) šablonus.
  • 2DVS turi būti galimybė sąskaitoms faktūroms konfigūruoti optinio simbolių atpažinimo šablonus.
  • 3DVS konfigūruojant OCR šablonus turi būti galimybė nurodyti PDF failą arba nuskenuoti dokumentą.
  • 4DVS turi būti realizuotas įrankis OCR sritims žymėti. Turi būti galimybė tiek horizontaliai, tiek vertikaliai plėsti OCR atpažinimo sritis, iš kurių nuskaitomi duomenys.
  • 5DVS Turi būti galimybė nurodyti OCR srities duomenis: pavadinimą; x, y ašis; Aukštį, plotį; požymį, ar kontrolinė sritis; kontrolinius žodžius.
  • 6DVS turi būti realizuotas funkcionalumas pagal kontrolinės srities požymį ir kontrolinius žodžius identifikuoti naują dokumento lapą.
  • 7DVS turi būti galimybė priskirti atpažinimo sritis ir numatytas reikšmes sąskaitos faktūros kortelės laukams.
  • 8DVS turi būti galimybė skenuoti dokumentus priskiriant OCR ruošinį.
  • 9DVS turi būti realizuotas funkcionalumas užpildyti sąskaitos faktūros formos laukus iš skenuojamo dokumento pagal nurodyto OCR ruošinio konfigūraciją.
  • 10DVS turi būti realizuotas funkcionalumas nuskaityti, pagal skenavimo įrenginio talpos galimybes, neribotą kiekį dokumentų pasirinktam OCR šablonui.
  • 11DVS turi būti galimybė peržiūrėti visus vienu metu nuskaitytus visus dokumentus. Nuskaitytų dokumentų peržiūrai turi būti naudojamas vedlys.
  • 12Peržiūrint dokumentą vedlyje turi būti galimybė pakeisti nuskaitomų sričių vietas, kad iš naujo automatizuotai būtų inicijuotas OCR.
  • 13Peržiūrint dokumentą vedlyje turi būti galimybė rankiniu būdu užpildyti sąskaitos faktūros kortelės formą, jei dėl nekokybiško dokumento nebuvo nuskaityti simboliai.
  • 14Turi būti realizuotas funkcionalumas sąskaitų faktūrų duomenų (formos duomenų ir nuskaitytų failų) registravimui.

SPS duomenų peržiūros, paieškos ir filtravimo reikalavimai

  • 1SPS turi būti galimybė visus įvestus duomenis peržiūrėti ekrane ir atsispausdinti.
  • 2SPS turi būti galimybė atlikti įrašų (duomenų lentelės eilučių) paiešką pagal pasirinktus parametrus. Paieškos parametrais gali būti ir pilna frazė, ir frazės fragmentas.
  • 3SPS turi būti galimybė vykdyti išplėstinę (pvz., kompleksinę, pagal fragmentą ir pan.) paiešką.
  • 4SPS turi būti galimybė peržiūrėti paieškos rezultatų skaičių bei paieškos rezultatų sąrašą.
  • 5SPS turi būti galimybė iš paieškos rezultatų sąrašo pasirinkti ir atidaryti duomenis.
  • 6SPS turi būti galimybė išsaugoti paieškos rezultatus ir juos vėliau panaudoti nevykdant naujos paieškos.
  • 7SPS turi būti galimybės filtruoti, grupuoti duomenis pagal užduotus parametrus.

Strateginio planavimo sistemos (SPS) funkcionalumo reikalavimai

  • 1SPS strateginio planavimo funkcionalumas turi būti suderinamas su galiojančia LR Strateginio planavimo metodika.
  • 2Strateginio planavimo funkcionalumas turi būti susietas su biudžeto ir kitų finansavimo šaltinių planavimu ir vykdymu.
  • 3SPS turi leisti įvesti atskirus savarankiškus strateginius planus, remiantis galiojančia LR strateginio planavimo metodika: strateginį plėtros planą (ilgalaikis), strateginį veiklos planą, metinį veiklos planą (trumpalaikiai).
  • 4SPS turi būti galimybė nustatyti skirtingas strateginių planų struktūros taisykles (hierarchijų apibrėžimus). Hierarchijos apibrėžimų skaičius turi būti neribotas.
  • 5SPS turi būti galimybė įvestus strateginius planus susieti hierarchiniais ryšiais.
  • 6SPS turi būti valdomas strateginių planų gyvavimo ciklas: turi būti galimybė keisti planų būsenas, kaupti versijų istoriją.
  • 7SPS turi būti galimybė importuoti ir įvesti strateginių planų struktūros elementus, jų pavadinimus, tipus, aprašymus, svertinius svorius, vykdymo laikotarpius, nustatyti tik tokius lygmenis, kokie yra leidžiami pagal plano hierarchijos apibrėžimus.
  • 8SPS turi turėti priemones, kuriomis naudotojas, be programuotojo pagalbos, galėtų įvesti naujus planų elementus ir jų atributus, tolerancijos intervalus, siektinas reikšmes, svorius.
  • 9SPS turi būti galimybė bet kuriam plano elementui priskirti bet kokį skaičių atsakingų asmenų. Priskiriant atsakomybę turi būti nurodomas jos tipas.
  • 10SPS apibrėžtas kriterijus turi turėti tokius atributus: kodą, pavadinimą, detalų aprašymą, tipą (efekto, rezultato, produkto, proceso ir indėlio), savininką, atsakingą asmenį(-is), matavimo vienetus, pageidaujamą tendenciją, tolerancijos intervalus, matavimo periodiškumą ir kiti, kurie reikalingi įgyvendinti LR Strateginio planavimo metodikos reikalavimus.
  • 11SPS turi numatyti galimybę veiklos vertinimui naudoti skirtingus elementų matavimo vienetus.
  • 12SPS turi atvaizduoti, leisti analizuoti bet kurio elemento dinamiką laike.
  • 13SPS turi būti galimybė grafiškai atvaizduoti kriterijų reikšmes, jo siektinų reikšmių bei įverčių zonų kitimą laiko atžvilgiu.
  • 14SPS turi suteikti funkcines galimybes veiklos vertinimo bei strateginio valdymo įrašams nagrinėti ir iš bendrojo lygio pereiti į detalųjį lygį (angl. drill down funkcija).
  • 15SPS turi būti galimybė vartotojui pačiam aprašyti veiklos vertinimo metodikos specifinius parametrus bei juos koreguoti.
  • 16SPS turi numatyti galimybę išsaugoti reikiamą informaciją pdf, xlsx, word formatu.
  • 17SPS turi leisti kriterijų reikšmes įvesti rankiniu būdu.
  • 18SPS turi būti galimybė vertinimo kriterijų ir jų nuokrypių reikšmes įvesti ne tik skaitinėmis reikšmėmis, bet ir paaiškinti jas tekstinėmis (pvz., pastatų būklė, kt.).
  • 19SPS turi leisti prie vertinimo kriterijų pridėti nuorodas į dokumentus, esančius dokumentų valdymo sistemoje.
  • 20SPS turi būti galimybė matyti visų stebėsenos objektų sąrašą.
  • 21SPS turi būti galimybė kiekvienai bet kurio strateginio plano programai ir jos elementams priskirti finansavimo šaltinius (nepriklausomai, ar jie patenka į savivaldybės biudžetą ar ne).
  • 22SPS turi būti galimybė planų struktūras kopijuoti iš vieno plano į kitą, apimant ir plano elemento atributus, ir jų vertinimo kriterijus, jų planuojamas bei faktines reikšmes, priskirtas atsakomybes.
  • 23Prie bet kurio plano elemento turi būti galima prisegti duomenų bylas. Bylų skaičius neturi būti ribojamas.
  • 24SPS turi būti galimybė nurodyti, iki kokios datos turi būti užbaigtas duomenų pateikimas ir tvirtinimas.
  • 25SPS turi būti galimybė be programavimo žinių reikalaujančių veiksmų keisti stebėsenos darbų atlikimo datas.
  • 26SPS turi būti galimybė atsakingam asmeniui matyti tik savo ir jo kuravimo srities pavaldžių įstaigų darbų būklę.
  • 27SPS turi būti realizuotas funkcionalumas leidžiantis iš strateginio planavimo ir vykdymo proceso metu sukauptų duomenų, parengti strateginio veiklos plano ataskaitas pagal LR Strateginio planavimo metodiką.

Dokumentų valdymo sistemos (DVS) bendrieji funkciniai reikalavimai

  • 1DVS turi apimti šiuos organizacijos dokumentų rengimo, tvarkymo ir valdymo procesus: dokumentų (parengtų ir su organizacijos veikla susijusių gautų dokumentų) registravimą ir paskirstymą vadovo nustatyta tvarka; atsakingų darbuotojų paskyrimą vykdyti su organizacijos veikla susijusius darbus ir jų vykdymo kontrolę; bendruosius darbo su dokumentais ir pavedimais principus: dokumentų suradimą ir jų peržiūrą, ataskaitų rengimą ir spausdinimą; organizacijos rengiamų dokumentų kaupimą ir saugojimą, derinimo su organizacijos darbuotojais, vizavimo ir pasirašymo etapus; dokumentų archyvavimą, archyvuotų dokumentų saugojimą.
  • 2DVS turi būti pritaikyta organizacijos struktūrai.
  • 3DVS turi leisti aprašyti organizacinę struktūrą (padalinių hierarchiją ir darbuotojus, nurodant darbuotojų pareigybes, darbuotojų kontaktinę informaciją).
  • 4Turi būti realizuota galimybė atpažinti (angl. OCR) skenuoto dokumento tekstą lietuvių kalba. Tiekėjas turi pateikti reikiamas licencijas (jei funkcionalumas licencijuojamas atskirai), kurios būtų neterminuotos laike ir neribotų naudotojų skaičiaus, techninės įrangos resursų ar atliekamų operacijų skaičiaus.
  • 5Realizuota galimybė iš DVS atsispausdinti dokumentus, dokumentų sąrašus, statistines ataskaitas, dokumentų metaduomenis, elektroninių dokumentų parašų informaciją.
  • 6DVS turi būti galimybė priskirti žymeles (angl. tags) dokumentams.
  • 7DVS turi būti galimybė kurti sistemines ir asmenines žymeles. Sistemines žymeles turi kurti sistemos administratorius, asmenines – sistemos naudotojai.
  • 8Turi būti realizuoti naudotojo nustatymai, kuriuose galima nurodyti: Bendri duomenys (rodyti negaliojančius registrus, siųsti el. pranešimus apie vėluojančius dokumentus, laikotarpį iki pranešimų siuntimo, siųsti el. paštu pranešimus apie naujai užregistruotus dokumentus, rodyti išskleistą greitąjį filtrą).
  • 9Turi būti realizuoti naudotojo nustatymai, kuriuose galima nurodyti: Sutarčių duomenys (procentinę išraišką iki kurios likus nepanaudotai sumai siųsti el. pranešimą sutarties atsakingam asmeniui; dienų skaičių iki kurių likus sutarties termino datai siųsti el. pranešimą atsakingam asmeniui).
  • 10Turi būti realizuota galimybė per naudotojo nustatymus parinkti skenavimo parametrus (Skeneris; Spalva; Skiriamoji geba; Dokumento šaltinis; Skenuojamų failų registras; Saugomo failo tipas (PDF, BMP, JPEG, TIFF, PNG); PDF žyma (spaudas)).
  • 11Turi būti realizuota galimybė per naudotojo nustatymus keisti naudotojo meniu vietomis, išjungti/įjungti meniu punktus.
  • 12Turi būti realizuota galimybė per naudotojo nustatymus sukurti asmenines žymeles.
  • 13DVS turi būti realizuota dokumente sritis darbų sekos tvarkymui.
  • 14DVS turi būti realizuota dokumente sritis ryšių tvarkymui.
  • 15DVS turi būti realizuota dokumente sritis rezoliucijų tvarkymui.
  • 16DVS turi būti realizuota dokumente sritis pavedimų tvarkymui.
  • 17DVS turi būti realizuota dokumente sritis veiklos žurnalo tvarkymui.
  • 18DVS turi būti realizuota dokumente sritis žymelių tvarkymui.
  • 19DVS turi būti realizuota dokumente sritis pateikimų tvarkymui.
  • 20DVS turi būti realizuota dokumente sritis susipažinimo su dokumentu faktų peržiūrai.
  • 21DVS turi būti realizuota dokumente sritis veiksmų žurnalui peržiūrėti.
  • 22Turi būti realizuota galimybė dirbti su elektroniniais dokumentais (ADOC;PDF-LT) pagal reglamentuojančių teisės aktų reikalavimus.

Viešųjų pirkimų sistemos (VPS) bendrieji techniniai reikalavimai

  • 1Visa pirkimui pateikiama dokumentacija turi būti parengta lietuvių kalba.
  • 2VPS funkcionalumas turi užtikrinti viešųjų pirkimų proceso optimizavimą, sumažinti naudojamų rankinių veiksmų (dokumentų rengimo, skaičiavimo, vertinimo, analizavimo) skaičių, taupant darbuotojų resursus.
  • 3VPS funkcionalumas turi užtikrinti bendrą pirkimų procesų patogumą ir operatyvumą naudotojams.
  • 4VPS funkcionalumas turi užtikrinti informacijos prieinamumą realiu laiku tarp padalinių.
  • 5VPS funkcionalumas turi užtikrinti galimybę analizuoti, vertinti, stebėti pirkimų ir jų vykdymo analitinius duomenis.
  • 6VPS funkcionalumas turi užtikrinti veiksmų atsekamumą, kontrolę, dokumentų saugojimą elektroninėse bylose.
  • 7VPS funkcionalumas turi leisti VPS naudotojams kurti teisių rinkinius, juos grupuojant į roles.
  • 8VPS turi apimti: metinį pirkimų planavimą, pirkimų plano sudarymą, jo keitimą ir tvirtinimą; pirkimų inicijavimo procesą; pirkimų vykdymą ir stebėseną; pirkimo sutarčių sudarymą, jų keitimą; pirkimo sutarčių valdymą ir stebėseną; PVM sąskaitų-faktūrų valdymas; pirkimų ir veiklos ataskaitų paruošimą.
  • 9VPS sistemos naudotojų tipai ir teisės: VIP-vartotojas (administratoriaus teisės: apima visus procesus ir modifikacijų, kurias gali atlikti Užsakovas, teisės); pirkimų specialistas (pirkimų vykdymas); iniciatorius (apimantis tik procesus, susijusius su pirkimo iniciatoriaus funkcijomis); pirkimų skyriaus vadovas (kontrolės ir valdymo funkcijos).
  • 10Detali VPS sistemos naudotojų teisių matrica turės būti suderinta VPS įstaigoje diegimo metu.
  • 11VPS sistema turi turėti integraciją su dokumentų valdymo sistema ir finansų valdymo ir apskaitos sistema.
  • 12VPS sistemoje turi būti galimybė kurti viešųjų pirkimų dokumentų šablonus, sugeneruoti viešojo pirkimo dokumentus įtraukiant VPS sistemoje įvestus viešojo pirkimo duomenis, rengti viešojo pirkimo paraiškas, sutartis ir sutarčių pakeitimus bei kitus su pirkimais susijusius dokumentus.

Socialinių išmokų apskaitos sistemai (SIAS) bendrieji reikalavimai

  • 1Skaitmenizuotų dokumentų pasirašymo metu turi būti surenkama ir išsaugoma biometrinė parašo informacija pagal ISO/IEC 19794-7:2021 standartą.
  • 2Parašo duomenų surinkimas turi būti atliekamas taikant gerąsias praktikas, kurios apibrėžtos ISO/IEC 19794-7:2021 Annex B reikalavimuose.
  • 3Paslaugos teikimo metu Vykdytojas privalo palaikyti Biometrinio parašo paslaugos funkcionalumą bei užtikrinti, kad Socialinių išmokų apskaitos sistema (toliau – SIAS) tenkina Sistemos dokumentacijoje apibrėžtus reikalavimus. Į šią sąvoką įeina ir Užsakovo darbuotojų konsultavimas darbo su SIAS klausimais, SIAS funkcionalumo atstatymas, įvykus duomenų bazės ar atskirų jos komponentų funkcionavimo sutrikimams.

DVS dokumentų rengimo, vizavimo, pasirašymo, tvirtinimo reikalavimai

  • 1DVS turi būti realizuota rengiamo dokumento projekto sukūrimo funkcija.
  • 2DVS rengiamo dokumento projekto sukūrimo funkcija turi užfiksuoti šiuos dokumento projektą identifikuojančius duomenis: dokumento pavadinimą; dokumento turinį; rengiamo dokumento rūšį; adresatą (jeigu rengiamas siunčiamas dokumentas); su rengiamu dokumentu susijusius dokumentus; dokumentą derinančius asmenis; dokumentą vizuojančius asmenis; dokumentą pasirašančius asmenis; dokumentą tvirtinančius asmenis; dokumentą registruojantį asmenį; pastabas.
  • 3DVS rengiamo dokumento projekto sukūrimo funkcija turi leisti įkelti į sistemą failą, kuris bus derinamas.
  • 4DVS rengiamo dokumento projekto sukūrimo funkcija turi leisti pasirinkti failą iš dokumentų ruošinių (šablonų), kuris bus derinamas.
  • 5DVS rengiamo dokumento projekto sukūrimo funkcija pasirinkus dokumentą iš dokumentų ruošinių (šablonų) turi leisti užpildyti ruošinio (šablono) formos laukus. Suvesti duomenys turi būti sukelti į pasirinktą ruošinį (šabloną) ir pridėti prie dokumento projekto kortelės.
  • 6DVS turi būti realizuota galimybė iš anksto nurodyti, kas turi derinti, vizuoti, pasirašyti, tvirtinti dokumento projektą, susipažinti su juo, jį registruoti.
  • 7DVS turi būti realizuota galimybė kurti ir išsaugoti dokumentų projektų versijas. DVS neriboja kuriamų ir saugomų dokumentų projektų versijų skaičiaus.
  • 8DVS turi būti galimybė rankiniu būdu šalinti pasirinktas dokumento projekto versijas.
  • 9DVS turi būti galimybė automatiškai šalinti dokumentų projektų versijas užregistravus dokumentus.
  • 10DVS turi būti realizuotos nuoseklaus ir lygiagretaus dokumentų derinimo būdų funkcijos.
  • 11DVS turi neleisti vienu metu redaguoti to paties sistemoje saugomo dokumento projekto keliems naudotojams (angl. check-in/check-out funkcija).
  • 12DVS turi būti realizuotos dokumentų siuntimo derinti, vizuoti, pasirašyti, tvirtinti, registruoti funkcijos.
  • 13DVS dokumentų siuntimo derinti funkcija turi leisti: nurodyti darbuotojus, su kuriais reikia suderinti rengiamą dokumentą; nurodyti derinimo tipą (lygiagretus, nuoseklus); pažymėti, ar derinimo metu galimas dokumento turinio keitimas, ar tik komentarų rašymas rengiamam dokumentui; galimybė nurodyti komentarą/pastabą perduodant dokumentą derinti; nurodyti terminą, iki kada turi būti atliktas derinimo/vizavimo darbas.
  • 14DVS dokumentų siuntimo vizuoti funkcija turi leisti: nurodyti darbuotojus, su kuriais reikia vizuoti rengiamą dokumentą; nurodyti vizavimo tipą (lygiagretus, nuoseklus); galimybė nurodyti komentarą/pastabą perduodant dokumentą derinti; nurodyti terminą, iki kada turi būti atliktas derinimo/vizavimo darbas.
  • 15DVS dokumentų siuntimo pasirašyti funkcija turi leisti: nurodyti darbuotojus, su kuriems reikia pasirašyti rengiamą dokumentą; nurodyti pasirašymo tipą (lygiagretus, nuoseklus); galimybė nurodyti komentarą/pastabą perduodant dokumentą derinti; nurodyti terminą, iki kada turi būti atliktas derinimo/vizavimo darbas.
  • 16DVS dokumentų siuntimo tvirtinti funkcija turi leisti: nurodyti darbuotojus, su kuriems reikia tvirtinti rengiamą dokumentą; nurodyti tvirtinimo tipą (lygiagretus, nuoseklus); galimybė nurodyti komentarą/pastabą perduodant dokumentą derinti; nurodyti terminą, iki kada turi būti atliktas derinimo/vizavimo darbas.
  • 17Naudodamas DVS, derintojas turi galėti: rašyti komentarus rengiamam dokumentui; keisti rengiamo dokumento derinimui skirtą failą (-us), atsižvelgdamas į siuntimo derinti metu nurodytą požymį; teigiamai vizuoti dokumentą, nurodydamas komentarą/pastabą; neigiamai vizuoti dokumentą, nurodydamas komentarą/pastabą.
  • 18Naudodamas DVS, vizuotojas, pasirašantysis, tvirtintojas turi galėti: rašyti komentarus rengiamam dokumentui; teigiamai vizuoti dokumentą, nurodydamas komentarą/pastabą; neigiamai vizuoti dokumentą, nurodydamas komentarą/pastabą.
  • 19DVS turi būti realizuota galimybė elektroniniu paštu informuoti derintoją, vizuotoją, pasirašantįjį, tvirtintoją, registratorių apie paskirtą atlikti veiksmą su dokumentu.
  • 20DVS turi būti realizuota galimybė elektroniniu paštu informuoti derintoją, vizuotoją, pasirašantįjį, tvirtintoją, registratorių apie vėluojantį derinimo, vizavimo, pasirašymo, tvirtinimo, registravimo terminą.
  • 21DVS turi būti realizuota galimybė inicijuoti pasirašytų dokumentų registravimą.
  • 22DVS turi būti galimybė darbuotojus supažindinti su rengiamu dokumento projektu.
  • 23DVS turi būti realizuota galimybė vienu metu vizuoti, pasirašyti ir tvirtinti daugiau negu vieną dokumentą.
  • 24Naudodamas DVS, dokumento rengėjas turi turėti galimybę nutraukti rengiamo dokumento vykdymo procesą.
  • 25DVS turi būti realizuota galimybė vienu metu vizuoti, pasirašyti (sisteminiu nekvalifikuotu parašu) daugiau negu vieną dokumentą („srautinis“ vizavimas pasirašymas).

DVS Raštinės naudotojo darbo vietos programinei įrangai reikalavimai

  • 1DVS turi turėti lietuvišką naudotojo sąsają, kuri turi atitikti Valstybinės lietuvių kalbos įstatymą.
  • 2DVS naudotojo sąsaja turi būti įgyvendinta ir palaikoma interneto naršyklėje (Internet Explorer 11, Mozilla Firefox, Google Chrome, Opera, Safari) su galimybe naudoti saugų duomenų apsikeitimo protokolą HTTPS.
  • 3DVS turi kelti minimalius kompiuterinio raštingumo reikalavimus sistemos naudotojams, turėti paprastą taikomosios programinės įrangos administravimo funkcijų rinkinį.
  • 4DVS turi užtikrinti saugų (šifruotą) duomenų tarp naudotojų kompiuterių ir serverio perdavimą, t. y. užtikrinti saugų sesijos režimą.

DVS mano ir kontroliuojamų dokumentų ir pavedimų sąrašo reikalavimai

  • 1DVS turi būti realizuotas „mano“ dokumentų ir pavedimų sąrašas, į kurį turi patekti visi dokumentai, nukreipti naudotojui tiesiogiai, per rezoliucijas, per darbų sekas, pateikti susipažinimui ir pavedimai.
  • 2Turi būti realizuota galimybė peržiūrėti „Mano“ dokumentų ir pavedimų sąraše su išvardintais duomenimis.
  • 3Turi būti realizuota galimybė „Mano“ dokumentų ir pavedimų sąraše vykdyti paiešką pagal išvardintus parametrus.
  • 4Turi būti realizuota galimybė perkelti dokumentą į neaktualių dokumentų sąrašą ir atvirkščiai.
  • 5Turi būti realizuota galimybė iškviesti masinių veiksmų operaciją „Derinimas“.
  • 6Turi būti realizuota galimybė iškviesti masinių veiksmų operaciją „Vizavimas“.
  • 7Turi būti realizuota galimybė iškviesti masinių veiksmų operaciją „Pasirašymas (nekvalifikuotu parašu)“.
  • 8Turi būti realizuota galimybė iškviesti masinių veiksmų operaciją „Tvirtinimas“.
  • 9Turi būti realizuota, kad iškvietus masinių veiksmų operacijų „Derinimas“, būtų atidaromas sąrašas su dokumentais, kurie nukreipti naudotojui pagal darbų sekos veiksmą „Derinimas“. Turi būti galimybė ties kiekvienu dokumentu pažymėti sprendimą: pritarta, atmesta.
  • 10Turi būti realizuota, kad iškvietus masinių veiksmų operacijų „Vizavimas“, būtų atidaromas sąrašas su dokumentais, kurie nukreipti naudotojui pagal darbų sekos veiksmą „Vizavimas“. Turi būti galimybė ties kiekvienu dokumentu pažymėti sprendimą: pritarta, atmesta.
  • 11Turi būti realizuota, kad iškvietus masinių veiksmų operacijų „Pasirašymas (nekvalifikuotu parašu)“, būtų atidaromas sąrašas su dokumentais, kurie nukreipti naudotojui pagal darbų sekos veiksmą „Pasirašymas“. Turi būti galimybė ties kiekvienu dokumentu pažymėti sprendimą: pritarta, atmesta.
  • 12Turi būti realizuota, kad iškvietus masinių veiksmų operacijų „Tvirtinimas“, būtų atidaromas sąrašas su dokumentais, kurie nukreipti naudotojui pagal darbų sekos veiksmą „Tvirtinimas“. Turi būti galimybė ties kiekvienu dokumentu pažymėti sprendimą: pritarta, atmesta.
  • 13DVS turi būti realizuotas „kontroliuojamų“ dokumentų ir pavedimų sąrašas, į kurį turi patekti kontroliuojamo padalinio/skyriaus darbuotojų dokumentai, nukreipti naudotojui tiesiogiai, per rezoliucijas, per darbų sekas, pateikti susipažinimui ir pavedimai.
  • 14Turi būti realizuota galimybė peržiūrėti „Kontroliuojamų“ dokumentų ir pavedimų sąraše su išvardintais duomenimis.
  • 15Turi būti realizuota galimybė „Mano“ dokumentų ir pavedimų sąraše vykdyti paiešką pagal išvardintus parametrus.

Dokumentai8

  • espd-request.pdf
  • README.txt
  • 7716356_Contract notice - general directive, standard regime_0.pdf
  • espd-request.xml
  • 1306_7716356.pdf
  • 1_Pirkimo sąlygos 05.05.docx
  • 2_2 priedas. VVS priežiūros techninė specifikacija.docx
  • 4_c4t_7716356_1.xml
tendis.lt · Sukurta recodin.lt