Povezave: uvoz - stanje, uvoz - splošno, MuLeMa.
Poglavje je v prvi vrsti namenjeno zavarovalnicam, ki pripravljajo ali posodabljajo podatke za elektronsko izmenjavo z agencijami. Služilo naj bi kot priporočilo in pripomoček, hkrati razkriva pomen in uporabnost podatkov, ki so opisani na koncu.
Program MuLeMa omogoča elektronski vnos podatkov o mesečni produkciji (strankah, policah), plačilih in proviziji, statusu polic, opominih... Te podatke je sicer možno vnašati v program tudi ročno. Prepišemo jih lahko iz sklenjenih polic, poročil zavarovalnic o provizijah, opominih, stornacijah ipd. Vendar je ročno vnašanje vseh teh podatkov zamudno, podvrženo tipkarskim napakam, predvsem pa nepotrebno, saj so le-ti že vnešeni in preverjeni v zavarovalnici. Zato je veliko bolj smiselno in tudi v interesu zavarovalnic, da podatke iz svojega informacijskega sistema posreduje svojim partnerjem (agencijam in zastopnikom) v elektronski obliki, primerni za neposreden uvoz v programsko opremo, ki jo agencije in zastopniki uporabljanje za svoje obračune in evidence.
Program MuLeMa podpira vse oblike izmenjave podatkov, ki jih lahko ponudi zavarovalnica. Za vsako zavarovalnico posebej izdelamo algoritem in se tako v največji možni meri prilagodimo možnostim zavarovalnice.
Običajno izmenjava poteka preko t.i. uvoznih datotek, ki jih zavarovalnice generirajo v začetku meseca in zajemajo podatke za predhodni mesec. Datoteke so lahko v različnih formatih, največkrat enem od tekstovnih (.csv, .txt, .xml,...) ali v formatu excel (.xls).
Podatki so lahko v eni ali več datotekah. Zavarovalnice lahko pošiljajo datoteke agencijam mesečno po elektronski pošti ali jih same ročno prevzemajo iz portala zavarovalnice.
Kot najbolj zaželen način za prevzem podatkov priporočamo, da lahko program MuLeMa kot odjemalec na zahtevo uporabnika ali samodejno avtomatsko prevzame podatke iz strežnika zavarovalnice na osnovi predpisanega API-ja (GET/POST metode, RMT funkcije,...), saj s tem agencije še dodatno razbremenimo rutinskih opravil. Seveda pa nam mora zavarovalnica v tem primeru poslati navodila za povezavo na strežnik in prevzem podatkov, agenciji pa posredovati prijavne podatke za dostop.
Če je možno izbirati, priporočamo t.i. .csv (Comma Separated Value) format zapisa s tabulatorjem kot ločilom med polji in variabilno širino polj, z naslovno vrstico z enoličnimi (neponavljajočimi) imeni polj, ki ji sledijo podatkovni zapisi.
Tekst naj bo shranjen v kodnem zapisu utf-8, ki omogoča standardiziran zapis šumnikov ali drugih nacionalnih in posebnih znakov.
Tak format zapisa je kompakten, trivialen, ročno ga je možno pregledovati v različnih programih za delo s preglednicami, algoritem za uvoz podatkov je preprost in hiter. Hkrati je format fleksibilen, lahko ga razširjamo z novimi podatki. Oznake podatkov v naslovni vrstici se pozneje ne smejo spreminjati.
Bolj optimalno je, ni pa obvezno, da je vsaka vrsta podatkov (stranke, police, produkti, plačila, opomini,...) v svoji datoteki, ker se tako posamezni podatki ne podvajajo in so datoteke manjše. Vendar morajo biti v tem primeru zagotovljene relacijske povezave med zapisi posameznih datotek na osnovi ustreznega referenčnega podatka (številke police, DŠ ali šifre stranke, oznake/indeksa produkta...).
Še bolj kot format in oblika izmenjave podatkov je pomembna njihova vsebina. Da je algoritem smiselen, mora vsebovati vsaj najnujnejše podatke. V nadaljevanju bodo opisani podatki, za katere je izdelana podpora v uvoznih algoritmih in obdelavah programa MuLeMa.
Podatki so v opisih razdeljeni na več skupin. Podatki iz posameznih skupin se lahko nahajajo v svojih datotekah, lahko pa so združeni v skupno. Priporočamo, da se pred podatkovnimi zapisi nahaja naslovna vrstica z enoličnimi (neponavljajočimi) nazivi stolpcev. V tem primeru se pred naslovno vrstico lahko nahajajo še drugi podatki (opisi, komentarji...), ki jih bo uvozni algoritem preskočil.
Priporočamo, da so podatki zasnovani tako, da z njimi lahko opišemo vse produkte, ne glede na njihovo vrsto, zavarovalno dobo ipd. Vsi produkti naj bodo po možnosti vsebovani v enem kompletu datotek. Če je zaradi narave informacijskega sistema to težko izvedljivo, so lahko v več kompletih.
Nekateri podatki so neobvezni, vendar zaželeni. Zavarovalnica jih lahko doda, posebno tiste, ki vsebujejo dodatne informacije o strankah, policah in produktih. Podatki, ki so obvezni, morajo biti prisotni, v nasprotnem primeru je smisel obdelav vprašljiv.
Nekateri podatki so lahko podani na različne načine. Zavarovalnica mora posredovati spremno dokumentacijo, iz katere je razvidno, kako je določen podatek podan. Še posebno je pomembno, da je posredovan nedvoumni opis šifrantov z vsemi možnimi vrednostmi, ki jih lahko zavzamejo.
Priprava kvalitetenih uvoznih podatkov ni preprosto opravilo, ki ga lahko zadnji informatik v zavarovalnici opravi na hitro, po trenutnem navdihu. Žal imajo nekatere (tudi velike) zavarovalnice zelo nekvalitetne uvozne podatke in se niti ne zavedajo, kako s tem škodujejo predvsem sebi, saj imajo agencije zaradi tega veliko težav pri obračunih, obremenjujejo sebe in referente v zavarovalnici z vsakomesečnim razčiščevanjem nejasnosti, so obremenjene z ročnim dopolnjevanjem podatkov ali iskanjem po fasciklih, namesto da bi koristneje izrabile čas za delo s strankami.
Veseli smo, kadar na strani zavarovalnice najdemo sogovornike, ki so pripravljeni ponuditi polno podporo v okviru možnosti, ki so jim v okviru njihovega informacijskega sistema na razpolago. V takšnem primeru lahko s skupnimi močmi kvalitetno servisiramo agencije in zavarovalne zastopnike, jim ponudimo ustrezne informacije, jih razbremenimo zoprnih rutinskih in administrativnih opravil, da jim ostane več časa za pravo delo in so pri njem učinkovitejši.
V primeru, da v zavarovalnici pripravljate nov format podatkov za pošiljanje agencijam, bomo zelo veseli, če nas povabite k sodelovanju, nas po potrebi povprašate za nasvet, ali nam pošljete podatke v predogled ali oceno, preden algoritem opredelite kot dokončen. Naši kontaktni podatki so tukaj. Veseli bomo tudi pobud, da v program MuLeMa vključimo dodatne informacije, ki bi bile v pomoč agencijam pri njihovem delu.
Seznam in opis podatkov za posamezne subjekte, ki je podan v nadaljevanju, smo pripravili z namenom, da kakšnega pomembnega podatka pri pripravi izmenjevalnih datotek nehote ne spregledate. Lahko pa nas opozorite še na morebitne dodatne podatke, ki so pomembni za agencije ali zastopnike, da z njimi dopolnimo informacijski sistem agencije.
Zaželeno je, ne pa obvezno, da se podatki o strankah nahajajo v ločeni datoteki, v ostalih datotekah pa je za sklicevanje navedena davčna številka ali enolična oznaka stranke.
Ime in priimek sta osnovna podatka o stranki, zaželeno je, da sta v ločenih poljih. V primeru, da gre za naziv firme, je ta lahko zapisan v polju priimek, lahko pa v dodatnem polju.
Davčna številke ja zelo pomembna, saj enolično določa osebo, omogoča združevanje in osveževanje zapisov o isti osebi iz različnih virov in omogoča ugotavljanje iste osebe na različnih policah.
Pravni status ni obvezen. Če je na voljo, se shrani skupaj z osebo in omogoča programsko razločevanje med fizičnimi in pravnimi osebami.
Enolična oznaka stranke je nadomestek v primeru, ko ni na voljo davčna številka. To je koda, običajno iz šifranta strank, ki enolično določa stranko v okviru zavarovalnice in tako omogoča ugotavljanje in osveževanje iste osebe na različnih policah.
Naslov je zelo pomembne podatek. vsaka komponenta naslova naj bo po možnosti v ločenem polju.
Telefon je zelo pomemben podatek, saj omogoča tako govorno kot sporočilno (SMS) komunikacijo. Pomembnejši je mobilni telefon. Če je na voljo tudi fiksni, naj bo po možnosti v ločenem polju. Telefon naj vedno vsebuje tudi omrežno skupino. Fax ni pomemben; če je na voljo, se bo shranil skupaj s stranko, vendar naj bo v ločenem polju.
Elektronski naslov je pomemben podatek in naj bo vsebovan, če je na voljo.
Enotna matična številka, ki vsebuje tudi rostni datum in spol, ni posebno pomemben podatek, je pa dobrodošel. Če ni na voljo EMŠO, je zaželen vsaj rostni datum, po možnosti tudi spol. Na osnovi starosti lahko agencije strankam bolje prilagodijo ponudbo nekaterih zavarovanj, rostni dan pa omogoča, da jim ob osebnem prazniku izkažejo tudi kakšno pozornost.
Poklic in izobrazba nista pomembna podatka, omogočata pa agencijam bolje prilagoditi ponudbo zavarovanj. Če sta prisotna, eden, drugi, ali oba, se shranita skupaj s podatki o stranki.
Nekateri izmed spodaj naštetih podatkov (na primer status, stanje opominov, premijski saldo) se lahko nahajajo tudi v posebni datoteki, ki ima povezavo z osnovno datoteko preko številke pogodbe ali ponudbe.
Številka ponudbe je obvezen podatek, saj je znan že med sklepanjem zavarovanja in na njegovi osnovi agencije vodijo podatke o tem, kateri sodelavec je sklenil ali pripomogel k sklenitvi posameznega zavarovanja, kar vpliva na razdelitev zaslužene provizije.
V kolikor je različna od številke ponudbe, je tudi številka pogodbe obvezen podatek. Omogoča spremljanje ostalih podatkov (plačila, opomini, storni...), ki jih o polici vodi in pošilja zavarovalnica.
Za nekatere zavarovalnice je tip police obvezen podatek, saj pomaga pri razločevanju tipov zavarovanj.
V primerih, kjer polica lahko nadomesti, zamenja ali podaljša obstoječa zavarovanja, je številka predpolice pomemben podatek, saj agencijam in zastopnikom omogoča sledenje. V koliko je tip police prisoten in se na novi polici lahko spremeni, mora biti v ločenem polju prisoten tudi tip predpolice.
Podatek o stranki je za polico obvezen podatke. V kolikor so stranke v ločeni datoteki, je v datoteki o policah lahko prisotna le davčna številka ali enolična koda pošiljatelja za povezavo, sicer pa morajo biti posebej navedeni vsi podatki.
V kolikor je na voljo, naj bo prisoten tudi podatek o agenciji in/ali zastopniku, ki je sklenil zavarovanje (običajno je to koda zastopnika ali agencije).
Status police je pomemben podatek, saj skupaj s statusom produkta sporoča informacije o tem, kaj se s polico dogaja (aktivna, storno, smrt, odkup, kapitalizacija...).
Za agencije in zastopnike je pomemben podatek pri komunikaciji s strankami, da vedo, če jim je zavarovalnica poslala opomine in kakšne vrste. Možni so podatki o stopnjah in vrstah opomina, če je potrebno naj bodo podani v vel poljih.
Premijski saldo je stanje dolga ali preplačil stranke na posamezni polici. Iz tega podatke lahko zastopniki in agencije spremljajo, ali stranka redno plačuje premijo.
Zelo pomemben podatek. Način plačila je lahko periodičen (npr. mesečno, četrtletno, polletno, letno), kar je običajno pri večletnih zavarovanjih ali v več zaporednih mesečnih obrokih (enoletna ali enkratna zavarovanja). Iz podatka mora nedvoumno jasno, za kakšno vrsto palčila in periodo oz. število obrokov plačila gre. Na osnovi tega podatka namreč program računa termine in zneske pričakovane provizije in ugotavlja morebitne zamude plačil.
Ni pomemben ali obvezen podatek. V nekaterih redkih primerih, če ni drugače urejeno, lahko program pri preračunih neto/bruto premije računa odbitke na način plačila, če obstajajo.
Manj pomemben podatek. Če je na voljo, se zgolj kot informacija vodi na polici.
V splošnem je na zavarovalni polici lahko več produktov (na primer avto-obvezno, avto-kasko,... ali življenjsko in dodano nezgodno zavarovanje), med zavarovalno dobo se lahko nekateri ukinjajo in drugi dodajajo. Na tem modelu sloni tudi model vhodnih podatkov. V primerih, ko je na eni polici lahko le en zavarovlani produkt, se podatki produkta lahko smatrajo kot podatki police.
V kolikor se pdatki o produktu nahajajo v ločeni datoteki, je ta podatek obvezen zaradi povezave na pripadajoče podatke o polici.
Obvezen podatek.
Obvezen podatek, eden ali drugi.
Vsaka vrsta produkt mora biti določena z enolično kodo ali oznako, na osnovi katere ga nedvoumno ločimo od vseh ostalih produktov. Ta koda je v programu uporablja za razpoznavanje produktov in razvrščanje v ustrezno provizijsko skupino. SLuži tudi za povezavo z datoteko provizij, če se ti podatki nahajajo v ločeni datoteki.
Obvezen podatek. V večini primerov je hkrati osnova za izračun provizije.
Neobvezen, a zaželen podatek. Ima informativni značaj in je v pomoč pri komunikaciji s stranko, da je zastopnik seznanjen, kolikšna je obveznost stranke.
Obvezen podatek, če so možna enkratna vplačila ali doplačila. Podatek je še posebej aktualen pri naložbenih zavarovanjih ali skladih. Če so enkratna vplačila podana drugače, na primer v polju Neto letna premija, ali neposredno v podatkih o plačilih, naj bo to iz kakšnega drugega podatka nedvoumno jasno, da gre za enkratno vplačilo in v kolikšnem znesku.
Običajno zgolj informativen podatek. Obvezen v primeru, da služi kot osnova za izračun provizije.
Obvezen podatek, pogojno se lahko nahaja tudi med podatki o plačilih, v kolikor so v ločeni datoteki. Označuje, ali je produkt aktiven, storniran...
Neobvezen podatek. Če ni vključen ali manjka, se smatra, da je zavarovana oseba ali premoženje osebe, ki je sklenitelj.
V kolikor se podatki o plačilu nahajajo v ločeni datoteki, je ta podatek obvezen zaradi povezave na pripadajoče podatke o polici.
V kolikor so podatki o plačilih v ločeni datoteki, je koda ali oznaka produkta obvezna in služi kot povezava na produkt, na katerega se nanaša plačilo.
Obvezen podatek. Nanaša se na obdobje, za katerega je obračunano plačilo. Lahko je podan na več načinov in v več poljih, mora pa biti iz podatka možno nedvoumno razbrati ali izračunati dolžino obdobja (na primer 3 mesece) in do kdaj je plačana premija oziroma obračunana provizija (na primer do 31.10.2011).
Če je možno, predlagamo datumski podatek za obdobje plačila v obliki od - do (na primer: od 1.8.2011 do 31.10.2011).
Če ni možno, lahko na primer tudi število mesecev za plačilo in skupno mesecev kritje od začetka zavarovanja (na primer obračunani 3 meseci, skupno kritje 18 mesecev).
Če tudi to ni možno, je lahko podan znesek trenutnega plačila, znesek dosedanjih plačil, in pričakovani skupni znesek. Vendar mora biti tudi nedvoumno jasno, na katero zavarovalno leto se vse skupaj nanaša, če gre za večletna zavarovanja.
Nedvoumno mora biti tudi jasno, če gre za obračun enkratnega vplačila ali doplačila (lahko je podano obdobje od začetka do konca zavarovanja ali v Vrsti obračuna ali dodatnem polju posebej označeno, da gre za obračun enkratnega vplačila ali doplačila).
Obvezen podatek. Podana mora biti izplačana provizija za obračunano plačilo premije stranke. Za vsak produkt na polici mora biti podan ločen zapis.
Obvezen podatek, vendar je lahko različno podan. Iz podatka mora biti nedvoumno razvidno, za kakšno vrsto obračuna gre (redno plačilo, indeksacija, poračun, delna stornacija, odvzem zaradi stornacije...).
Neobvezen podatek in pomeni znesek vplačila stranke.
Neobvezen podatek in pomeni osnova, iz katere se izračuna provizija.
Neobvezen podatek in pomeni odstotek, po katerem se od osnove obračunava provizija.
Neobvezen podatek in pomeni skupno doslej obračunana provizija po produktu.
Neobvezen podatek. Lahko je podan znesek provizije, ki bo izplačan do konca zavarovanja, če ne bo prišlo do sprememb. Namesto tega je lahko podan skupni znesek provizije, ki jo bo dobila agencija za ta produkt v celotni predvideni dobi zavarovanja, če ne bo prišlo do sprememb.
Obvezen podatek, še se podatki o opominih nahajajo v ločeni datoteki.
Če so opomini več vrst ali imajo več stopenj, naj bo navedena vrsta ali stopnja opomina.
Datum, ko je bil opomin poslan stranki.
Znasek, ki ga dolguje stranka.
Datum, do katerega mora prispeti plačilo, da polica ne bo šla v stornacijo.