AGENT24 WEB-AGENT Biztosítási Ajánlat/Felmondás átvétel és leadás folyamata O002.0119
Feladat terv 2010.12.26
1/19
A biztosítási szerződések megkötése során sajnos figyelembe kell venni a meglévő rendszer hiányosságait is, melyek beépültek a folyamatba. Ilyen többek között a tesztkötések alkalmazása is, hiszen hiába kerül bevezetésre az új rendszerben – web agent – a test user fogalma, ha a felhasználók továbbra is kötnek R státuszban – éles – teszt típusú szerződéseket. A fentiek miatt szükséges a szerződés rekordban az alábbi mezők alkalmazása. • F_RECORD_STATUS – értéke T / R Az éles – R – típusú szerződés még nem jelenti azt valójában, hogy az tényleg éles célból kötődött, ezért szükséges a manuális ellenőrzés: •
F_CHECKED – ellenőrzött mező – értéke Y / N / S(storno)
A rendszer az alábbi ajánlat állapotkódokra épül: • N – Nem ellenőrzött. • C – Complette – azaz a szerződés létrejött. • S – Storno • R – Received – ügynöktől átvett • D – Delivered – Biztosító felé leadott. A folymat megismeréséről tudni kell az alábbi rövidített folymatot. A rendszer a működése során az 1-4 képernyők esetében ajánlatról beszélünk, azaz a kalkuláció végéig, amíg a kliens nem dönt a szerződés kötéséről, ajánlatról beszélünk – a 4M képernyővel bezárólag. A 05-ös képernyő a háttérben fut, ha bejelentkezett felhasználóról van szó, ellenben felhívja a figyelmet a bejelentkezésre. A 06-10 / 06-11 képernyők esetében beszélünk szerződésről, annak állapotkódjairól. Nem ellenőrzött ajánlat/szerződés (N) A 003-1-0046.001-es verzióig,ahol a STEP értéke kisebb, mint 9, nem jött létre szerződés, azaz félbeszakadt feldolgozásról beszélünk. Ennek oka az is lehet, hogy a felhasználó egyszerűen kilépett a PDF letöltéseket követően, de lehetséges, hogy elfogyott a rendelkezésre álló időlimit a feldolgozásra. Régebben a nevezett verzióig lehetséges volt a PDF képek letöltésére, s így a felhasználó azt gondolhatta, hogy létrejött a szerződés – de valójába az ehhez tartozó bejegyzések nem készültek el teljes mértékben. A biztosító élő szerződésszám tartományából kiadásra kerül a soron következő,de a rendszerbe a szerződés – alkuszi párosítás már nem kerül bejegyzésre, így nem kerülhet feltöltésre sem semmilyen dokumentum. A nevezett verziót követően csak a STEP=A vagy B értékű szerződések tekinthetők majd létrejöttnek. 2/19
3/19
Complette (C) Azon szerződések minősülnek a nevezett verzió óta C típusú szerződésnek, ahol a felhasználó a 10-es képernyőn a vízjeles ajánlatot megtekintve vállalta annak befogadását, azaz a STEP értéke így minimum „A” lesz. Ez még nem jelenti azt, hogy a szerződés leadható, azaz ügynöktől átvehető, mivel még szükséges a leadandó tételek teljes megléte, feltöltött állapotban, az adatbázisban. Storno (S) Storno állapot csak Complette állapotú szerződésből képezhető, azaz létre nem jött szerződést, megszakadt folyamatot nem lehet átminősíteni. A sztorno állapot csak az üzletkötő vagy az ügyfél írásos elállására állítható be a rendszerben, megfelelő jogosultság birtokában, de előtte csatolva a dokumentumot. Dokumentumnak minősül a fax-on, személyesen benyújtott kérelem, illetve az ügyfél/ügynök által megadott e-mail címről érkezett kérés. Jelenleg csak SA (System Administrator) jogosultsággal érhető el a funkció. Ügynöktől átvett szerződés még sztornózható, de leadott szerződés már nem – ehhez a biztosító felé kell továbbítani a sztornó kérelmet. Amennyiben a biztosító a sztorno kérelmet befogadja, akkor a WA-ben is sztornózhatóa tétel. Received (R) Ügynöktől átvett szerződés állapotkódja felületről nem állítható be. A rendszer által meghatározott leadandó dokumentumok adatbázisban való megléte esetében a rendszer automatikusan beállítja ezt az állapotkódot. A jövőben a leadandó szerződések listájában csak az R típusú szerződések fognak megjelenni. A szerződés megkötésétől számított egy munkanap elteltével a rendszer jelzi az üzletkötő felé a hiánypótlást, majd a 2. napon már az üzleti felettes felé. Ennek oka, hogy a törvényben szabályozott 15 napos határidőt a biztosító tudja tartani, szükséges a WA rendszerben kódtárban beállítani a biztosító alkusz felé meghatározott szerződéssel kapcsolatos leadási határidejét. A határidők betartása érdekében a minőségi jutalékkulcs 2010.01.01-től 1%-ról 2%-ra változott és minden jutalék elszámolása a biztosító szerződésre történő átutalásáig előlegnek minősül. Az átadás/átvétel csak teljeskörű lehet, azaz addig nem adható tovább biztosító felé, amíg az nem teljeskörű. Minden átvételi kísérletnél a rendszer kiírja, hogy miért nem vehető át, erről az átadó (ügynök) is értesül, hogy az átvételi kísérlet sikeres/sikertelen volt.
Delivered (D) A biztosító felé leadott szerződések a biztosító felé meghatározott módon is határidőre történő teljesítése érdekében a rendszerben a megfelelő táblázatokban be kell állítani a biztosító elvárásait a határidő, leadandó dokumentumok és a leadási mód vonatkozásában. A leadás során törekedni kell a biztosítóval a fent leírtak szerződésbe foglalását a későbbi félreértések, felelősségek miatt. Az átadás/átvétel csak teljeskörű lehet, azaz addig nem adható tovább pl. az adminisztratív terület felé, amíg az nem teljeskörű. Minden átvételi kísérletnél a rendszer kiírja, hogy miért nem vehető át, erről az átadó (ügynök) is értesül, hogy az átvételi kísérlet sikeres/sikertelen volt.
4/19
A fen leírtak alapján az adminisztráció nem tud közvetlenül az ügynöktől átvenni ajánlatot. A folyamat naplózott eseményeinek létrehozásában az alábbi sturktura kialakítása valósullt meg: • A t_slip_mtpl táblában az alábbi mezők kerültek kialakítása: o F_STEP – a lépés,ahol a feldolgozás tart/befejeződött o F_AGENT_DELIVERY – ügynöktől átvett (Y / N) o F_AGENT_DELIVERY_DATE – ügynöktől átvétel dátuma o F_INS_DELIVERY_M – biztosító felé manuális módon történő leadás sorszáma o F_INS_DELIVERY_E – ahol elektronikus leadás is van, annak sorszáma. Ahol egy időben manuális és elektronikus leadás is van, ott ügyelni kell a sorszámok konzisztenciájára, azaz az x számú manuális leadáshoz x számú elektronikusnak kell tartoznia. Ennek biztosítása érdekében a szerződések leadása menüpontban bevezetésre kerül zárolás fogalma, azaz az úton lévő tételek fogalma,melynek leadása már elkezdődött, de még nem zárult le. A leadások zártságát a t_insurance delivery tábla tartalmazza, ahol biztosítónként feltüntetésre kell leadási sorszámonként annak dátuma, tételszáma és végrehajtója. A t_next_slip tartalmazza biztosítónként és leadási módonként a soron következő sorszámot. Az átadás-átvétel riportja értelemszerűen a mellékelt – slip_riport.xls- excel táblázat kitöltésével, de csak a biztosítók felé. Az éjszakai futás során történik egy leválogatás, ahol a kötés dátuma az előző napi dátummal bezárólag és az F_CHECKED értéke =’N’. A leválogatott tételek manuális áttekintése elsősorban az ajánlat valódiságára terjed ki, azaz éles vagy teszt tételről van szó. Amennyiben a leválogatott rekord éles szerződést takar, úgy a következő folyamat az átvét az ügynöktől. A folyamat annyiban tér el a jelenlegi folyamattól, hogy nem a felhasználónak kell ügynökönként lekérdezni az átvételre kijelölt tételeket, hanem ezt a rendszer minden nap felkínálja, így nem maradhatnak ki tételek és csökken az emberi mulasztás veszélye. Az átvételre felkínált tételeket az üzleti hierarchia alapján – mely a szuperjutalék számfejtés alapja is – osztja szét a rendszer a felhasználókra, azaz az üzleti átvétel a szuperjutalékért cserbe végzendő feladat. Az átadás/átvételekhez határidő limit állítható be, azaz az átvétel 1. fázisához pl. 5 nap, azaz ennyi idő áll rendelkezésre az átvételhez. Az átvételt segíti a módozat által meghatározott leadandó dokumentumoknak, mely az adott szerződéshez pl. az MTPL esetében a 10-es képernyőn felugró ablakban is megjelennek. Az ajánlat/átvétel bejegyzés nem vonható vissza. A belső átadások során nem készülnek riportot, nem kell semmit sem kinyomtatni, minden elektronikusan történik, költséghatékonysági célok miatt is. Nyomtatott dokumentum csak a biztosítók felé történik, de ott csak ahol ezt a biztosító megköveteli.
5/19
Az átadás/átvétel kitér az első díj beszedésére is, azaz az elutalt első díj csekk azonosítóját be kell rögzíteni az ügynöknek a postára adás dátumának megjelölésével. Ehhez szükséges a kiadott csekk intervallumok berögzítése központilag illetve az ügynökök fegyelmezett, szabályos munkavégzésére. Ügynök által történi banki utalás esetében az utalás napját és a feladó bankszámlaszámot kel megjelölni. Az első díj nem tartható vissza ügynök által. Az ügynök által a 3A csekken történő befizetést a biztosító felé nem csekken, hanem utalással kell az összeget továbbítani, amennyiben a biztosító másképpen nem rendelkezik – így könnyebb az utólagos ellenőrzés. Amennyiben irodai kötésről beszélünk, ott a belső pénztári bevételi bizonylat sorszámát kell berögzíteni. A biztosító által történő átvétel visszaigazolása legkésőbb a biztosító által adott állománylista alapján történik meg. A lejárt időpontú és még mindig sikertelen átvételről az adott cég vezetői is értesítést kapnak e-mailben, ami ebben beavatkozásra hívja fel a figyelmet. Jelenleg nem megoldott a szabadság és egyéb távollét miatti jogosultság átadása, de erre van hasonló modulom, de ehhez be kell vezetni a személyes jogosultság fogalmát. A tervezett távollétek esetében maga a dolgozó ruházza át a jogait egy másik dolgozóra, a hatály dátumok megjelölésével – ennek eredménye, hogy távolról belépve is csak akkor tud dolgozni a már átadott folyamatokon, hogy azt visszaveszi, azaz egy jogosultsággal nem lehet egy időben 2 félnek dolgozni. Igaz még azt is meg kell oldani, hogy egy időben egy azonosítóval csak egy bejelentkezett user legyen – ehhez az alapokat a 001-7-0021-es verzió megteremtette. Nem tervezett távollét esetében a vezető jogosult átruházni bizonyos jogosultságokat a működés biztosítása érdekében.
6/19
Az átruházás kialakítására szolgáló alábbi mintaképernyő kerül felhasználásra, jelentős átalakítással.
A helyettesítés a hatály dátumokkal oldható meg A törzs feltöltése a felhasználói rendszergazda jogköre, de a helyettesítést csak a helyettesítendő személy végezheti A rendszer jogosultsági módosítása csak jövőbe mutató lehet, hatálya minimum másnaptól. A rögzítéseket követően a rendszer ellenőrzi a jogosultságok zártáságát, ellenben az adott költséghelyre letiltja a rögzítési funkciókat. A jogosultságok bejegyzéséről e-mail is kiküldésre kerül a felhasználó részére az általa a rendszerben meglévő adatok alapján. Bizonyos személyes modulok is beépítésre kerülnek az adott funkció miatt: A felhasználóstátuszának változatása képernyővel több esetben is találkozhat a felhasználó:
7/19
A belépés során, amennyiben egy felhasználó több érvényes jogosultsággal rendelkezik, választania kell azok közül. Továbbá, ha olyan menüpontot kíván használni, ahova a jogosultsága nem biztosít lehetőséget, akkor szintén felkínálásra kerül az összes érvényes jogosultság, mely közül ki kell választani a megfelelőt. Minden módosítást követően e-mailben értesítést kap a felhasználó a jelszóváltozásának tényéről. A jelszó cseréjét követően a rendszer kilépteti a felhasználót, ismételt belépés szükséges a további munkavégzéshez. A jelszó sikeres cseréjéről e-mail is kiküldésre kerül a felhasználó részére az általa a rendszerben meglévő adatok alapján. A jelszavakat természetesen kódolt formában kell tárolni az adatbázisban. A jelszó cseréjét az alábbi képernyő biztosítja a Személyes beállítások 1. menüpontban, illetve az első belépéskor az új jelszó megküldését követően:
8/19
a. Az adatkezelés előfeltétele Személyes adat akkor kezelhető, ha ahhoz az érintett hozzájárul, vagy jogszabály elrendeli. Elsősorban az önkéntes hozzájárulást kívánó adatkezelés a gyakori, a törvény alapján kötelező adatkezelés kivételnek tekinthető. Különleges adat (a faji eredetre, a nemzeti és etnikai kisebbséghez tartozásra, a politikai véleményre vagy pártállásra, a vallásos vagy más világnézeti meggyőződésre, az érdek-képviseleti szervezeti tagságra, az egészségi állapotra, a káros szenvedélyre, a szexuális életre vonatkozó adat, valamint a bűnügyi személyes adat)11 esetében a hozzájárulás írásbeli kell legyen, míg a személyes adatnál akár ráutaló magatartással is meg lehet adni a hozzájárulást. Mindkét esetben fontos követelmény, hogy a hozzájárulását adó személy kellően informálva legyen adatainak kezeléséről. Amennyiben az érintett személy nem tájékozódott és erre az adatkezelő lehetőséget sem biztosított, nem tekinthető hozzájárulása megadottnak. "Az érintettet - egyértelműen és részletesen - tájékoztatni kell az adatai kezelésével kapcsolatos minden tényről, így különösen az adatkezelés céljáról és jogalapjáról, az adatkezelésre és az adatfeldolgozásra jogosult személyéről, az adatkezelés időtartamáról, illetve arról, hogy kik ismerhetik meg az adatokat. A tájékoztatásnak ki kell terjednie az érintett adatkezeléssel kapcsolatos jogaira és jogorvoslati lehetőségeire is."12 11 Avtv. 2. § 2. 12 Avtv. 5. § (2) b. Célhoz kötöttség elve Személyes adatot csak meghatározott célból lehet kezelni. A felvett és kezelt adatnak elengedhetetlennek és alkalmasnakkell lennie a cél elérésére. Az adatkezelés minden fázisában meg kell felelnie e célhoz kötöttségnek. A cél megvalósulása esetén az adatokat törölni kell. A készletre tárolás nem megengedett. c. Adatok minőségének követelménye Az adatok felvétele és kezelése tisztességes, törvényes, pontos, teljes és időszerű kell legyen. Az adatokat úgy kell tárolni, hogy e követelményeknek folyamatosan eleget lehessen tenni, módosításra lehetőséget kell biztosítani. Az adatok a cél megvalósulásakor, illetve az érintett kérésére törölhetők kell legyenek. d. Adattovábbítás korlátozása Személyes adatokat harmadik személy részére továbbítani, illetve más adatbázissal összekapcsolni csak akkor lehet, ha ahhoz az érintett kifejezetten hozzájárult, vagy törvény megengedi. A külföldre (Európai Unión kívüli országba) irányuló adattovábbítást ezen felül nemzetközi szerződés is megengedheti, de minden esetben csak akkor, ha a fogadó ország joga megfelelő védelmet biztosít az átadott adatok kezelése során. e. Automatizált egyedi döntések korlátozása A számítástechnikai eszközzel, matematikai módszerrel az érintett személyes adataiból történő automatizált egyedi döntéssel létrehozott értékelés csak az érintett kifejezett hozzájárulása, vagy törvény engedélye alapján lehetséges, az érintett álláspontja kifejtésének lehetőségével (pl. személyiségi, érzelmi, intelligencia és hasonló tesztek esetében). f. Adatbiztonság követelménye Az adatkezelő, illetve adatfeldolgozó köteles védeni az adatok biztonságát, "különösen jogosulatlan hozzáférés, megváltoztatás, továbbítás, nyilvánosságra hozatal, törlés vagy megsemmisítés, valamint a véletlen megsemmisülés és sérülés ellen"13. Hálózati (pl. internet) továbbítás esetén külön védelmi intézkedéseket kell tenni. Az adatbiztonság alapkövetelményei: rendelkezésre állás, sérthetetlenség, bizalmasság, hitelesség, működőképesség14.
9/19
g. Adatfeldolgozó igénybevételének lehetősége Az adatkezelő - írásbeli megbízási szerződés alapján - a különböző adatkezelési feladatok technikai megvalósítására külső adatfeldolgozót vehet igénybe. Az adatfeldolgozó az adatkezelő utasítása alapján jár el. Az utasítások jogszerűségéért az adatkezelő felel. h. Bejelentkezés az adatvédelmi nyilvántartásba Néhány kivételtől eltekintve - az adatkezelő, ide értve az adatfeldolgozót is, tevékenysége megkezdése előtt köteles bejelenteni adatkezelési tevékenységét az adatvédelmi biztos nyilvántartásába. Be kell jelentenie az adatkezelő, adatfeldolgozó személyét és adatait, adatkezelés célját, az adatok forrását, törlési határidejét, fajtáját és kezelésük jogalapját. A - nagyközönség számára az adatvédelmi biztos honlapján elérhető nyilvántartásnak tartalmaznia kell az érintettek körét, információkat az adattovábbításról és a belső adatvédelmi felelős nevét és elérhetőségét.
10/19
Az átvett ajánlatok leadása azon tétele esetében kerül felkínálásra, ahol az F_SLIP_STATUS értéke = ’R’, azaz ügynöktől átvett. Azon szerződések felelnek meg ennek a feltételnek, ahol a leadandó bizonylatok mindegyike feltöltésre került. A szerződések rögzítése során az MTPL / CASCO / FLAT módozatok esetében az ajánlat feltöltése – F_SLIP_UPLOAD - és alkuszi szerződés feltöltése – F_MAKLER_UPLOAD mezők tartalmazzák majd a feltöltés meglétét. Amennyiben már létezett az aláírt alkuszi szerződés a rögzítés során, úgy a szükséges flag tartalma ’Y’ értéket vesz fel, ellenkező esetben az értéke ’N’. A szerződéseken az F_ATT_NEED mező tartalmazza a szerződéshez tartozó mellékletek számát, míg az F_ATT_UPLOAD a már feltöltött mellékletek darabszámát. Az aláírt ajánlat / az aláírt alkuszi szerződés / a mellékletek feltöltése programok a feltöltést követően azonnal módosítják az értékeket, amely alapján, ha az F_SLIP_UPLOAD = ’Y’, az F_MAKLER_UPLOAD = ’Y’ és az F_ATT_NEED értéke megegyezik az F_ATT_UPLOAD értékével, úgy az F_SLIP_STATUS értéke azonnal ’R’ értékre változik, azaz leadható. Külön táblában kerül meghatározásra, hogy biztosítónként mi az elvárt leadás módja és a mellékelten leadandó dokumentumok átadásának formája. A leadás elvárt időintervalluma is itt kerül meghatározásra. A t_insurance_delivery tábla tartalmazza az ajánlatok manuális leadásának állapotát, míg a t_insurance_e_delivery tábla tartalmazza az ajánlatok elektronikus leadásának állapotát. Az, hogy melyik biztosító melyik termékénél mi a szabály, azt a t_insurance_product_wsdl tábla tartalmazza. Az induló állapot beállítására célprogram került megírásra – PATCH_012 Az ajánlatok leadása csak adminisztratív funkción belül érhető el.
11/19
A szerződések leadása menüpontot választva az alábbi lehetőségek közül választhatunk:
A leadott szerződések a már eddig a biztosító felé dokumentált módon átadott szerződések visszakeresését segíti. A leadandó szerződések pedig kizárólag csak az ügynöktől átvett szerződéseket tartalmazza. A Hiányos szerződés menüpont azon Megkötött szerződéseket jeleníti meg, melyek még az ügynöktől való átvételre várnak. A leadott szerződések gombra kattintva az alábbi menü látható:
12/19
A válasszon gomb hatására menüben megjelenik az eddig leadott összes átadás főbb adatai megtekinthetők – a jövőben a biztosító előválasztása is bekapcsolásra kerül – amennyiben nem lesz kiválasztva tétel, úgy mindegyik leválogatásra kerül majd.
A fentiekben a már ismert menürendszer logika alapján láthatók a leválogatott/átadott elemek.
13/19
Az első mező tartalmazza a biztosító kódját, klikkelve megjelenik annak megnevezése. A mellette lévő sorszám tartalmazza a leadás sorszámát, mely biztosítónként 1-ről indul. Erre történő klikk hatására, magát a leadás részletes adatait láthatjuk, majd a későbbiekben ez részletezésre kerül.
14/19
A leadás módja M – gomb jelenti a manuális leadás tényét, ahol klikkelve két értéket láthatunk: • Postai – Postai feladás. Ebben az esetben az ajánlott feladási szelvény maga az igazolás a leadás tényéről. • Személyes – Amikor személyesen a biztosítónál történik a leadás. Ilyen esetben az átadott jegyzékre kerül a biztosító átvevőjének igazolása. A mellette lévő értéke a leadás dátuma. A leadás mellett lévő üres kocka a jövőben a leadás PDF képnek a helye. A leadás során leválogatásra kerülő PDF kép kerül feltöltésre, majd ezt kell a PDF feltöltése menü segítségével lecserélni a leadás igazolását bizonyító átadási jegyzék PDF képére.
15/19
A személy ikonra kattintva a leadást végző dolgozó adatai láthatók. Az E gomb hatása jövőbeni, az elektronikus leadást jelenti. Az utolsó gomb az elektronikus leadás dátuma. Visszatérve a leadás sorszámára, ez a gomb további részletes adatokkal szolgál a leadásban résztvevő szerződések állapotáról – ami nem a leadáskori állapotot, hanem a gomb megnyomásának időpontjában lévő állapotot tartalmazza – azaz időközben már megszűnt szerződésről is szó lehet – de a leadásban ez a szerződés vett részt, ahol a szerződő adatai és maga az ajánlat látható.
A fenti menüben a választott biztosító kódja és a leadás sorszáma látható, mint előválasztott érték.
16/19
Ezt követően van lehetőség a leadott szerződések tételes megjelenítésére egy más ismert – Szerződés keresés - program meghívásával.
Itt már a program által megismert működési funkció hatása érvényesül. A Leadott_jegyzék_xls menüpont hatására a most látható adatok excel táblázatba is legyűjtésre kerülnek, mely a legyűjtés végén PDF formátumban is rendelkezésre áll – de nem írja felül a már meglévő eredeti PDF listát.
A képernyőn látható Tételszám mező és maga a PDF ikon nem jelenik meg azonnal, csak a program sikeres lefutását követően. A PDF ikonra kattintva a leválogatott lista letölthető.
17/19
A Leadandó szerződés menüre kattintva választható a leadandó biztosító kódja.
Amennyiben a Zárolásra is klikkelünk, úgy a leválogatás nem időleges, hanem végleges lesz és a szükséges átadási lista mellett – az elektronikus leadás állomány is elkészül, a konzisztencia biztosítása érdekében. – csak abban az esetben készül elektronikus állomány, ha ez az adott biztosítónál beüzemelésre került – A funkció további működése azonos a már megismert tevékenységgel, azzal a különbséggel, hogy számtalanszor ismételhető mindaddig, amíg a Zárolás nem történik meg, onnantól új sorszámon történik a leválogatás. Az új sorszám a biztosítón belüli következő sorszám. A Hiányos_szerződés esetében azon létrejött szerződések szerepelnek, melyek még nem kerültek átvételre az ügynöktől. F_SLIP_STATUS értéke = ’C’,
18/19
Az ajánlatok leadása folyamán biztosítónként és termékenként a t_insurance_product_wsdl táblában meghatározásra kerül az ajánlatok leadásának folyamata, mely lehet: • • • • •
Manuális – papír alapú Elektronikus – txt állományban Elektronikus – xls formátumban Elektronikus – wsdl folyamatban A fentiek kombinációja
A fentieket az F_TRANSFER _MODE mező tartalmazza M / E (Manual / Electronic) jelöléssel. Amennyiben az érték E, akkor a F_TRANSFER_DATA lehetséges értékei: • TXT • XLS • WSDL A táblázatban szerepel a program neve, mely előállítja a kérdéses elektronikus formátumú állományt. A manuális riport minden esetben elkészül és annak sikeres futását követően történik egy bejegyzés az elektronikus állomány elkészítésére – ami önmagában többször is futtatható azon az állományon, amely a manuális riporton szerepel. – az elektronikus állományok elkészítése ütemezetten az éjszakai órákban, a mentést követően fut.
19/19
