• Пример за изчисляване на индексацията на заплатата
• Как да коригирате малка грешка зависи от
• Тестване на интервю за счетоводител
• Индексация на заплатите: изберете правилно „базовия“ месец Задаване на базовия месец за изчисляване на индексацията
• Счетоводни тестове
• Как и къде да сменим медицинска застраховка?
• Анонимизиран метален акаунт
• Какво включва задължителната медицинска застраховка - безплатни грижи и услуги, включени в полицата
• Как и къде да получите полица за задължителна медицинска застраховка?
• Коя застрахователна компания да избера за сключване на задължителна медицинска застраховка?

Автоматизирани системи в застрахователната дейност.

Застраховането е система от защитни отношения имуществени интересифизически и юридически лица при настъпване на определени събития (застрахователни събития) за сметка на парични средства, формирани от внесените от тях осигурителни вноски (застрахователни премии).

Историята на застраховането е на няколко века и, както показва опитът, застраховането е мощен положителен фактор, влияещ върху икономиката. Застраховането увеличава инвестиционния потенциал, поддържа стабилност и устойчивост икономическо развитие, формиране на механизми за защита на всички субекти на общественото производство.

много Застрахователни компании, акумулирайки големи средства, се занимават с кредитиране на определени области и отрасли стопанска дейност. Застрахователните компании заемат водещи позиции (след търговските банки) по отношение на размера на активите и възможностите за използването им като инвестиции. Концентрираните в тях ресурси са с дългосрочен характер, което им дава предимства пред търговските банки, привличане на краткосрочни средства.

Застрахователният пазар, част от финансово-кредитния сектор, се регулира от държавата. Регулация и контрол от държавата застрахователен пазарнеобходими за осигуряване на неговата стабилност. Държавно регулиранезастрахователен пазар се осъществява чрез спец данъчна политика, разработване на закони, регулиращи дейността на страните, участващи в осигурителния процес. Контролните функции са възложени на федерална службаРусия относно надзора на застрахователната дейност.

Основното звено на застрахователния пазар е застрахователната компания. Застрахователна компания - определена форма на функциониране осигурителен фонд. Застрахователно дружество е организационно обособена структура, която сключва застрахователни договори и ги обслужва и е юридическо лице. Застрахователното дружество е независима икономическа единица, действаща въз основа на устав.

Анализирайки състоянието на застрахователния пазар и техните възможности, компаниите самостоятелно определят обхвата на дейност и избират видове застраховки.

На застрахователния пазар има различни видове застрахователни компании.

• Акционерни застрахователни дружества;
• Държавни застрахователни компании;
• Презастрахованекомпании лице в лице ( презастраховане- система икономически отношения, според която застрахователят, приел рискове за застраховане, прехвърля част от отговорността за тях при договорени условия на други застрахователи с цел създаване на балансиран застрахователен портфейл);
• Взаимозастрахователни дружества (организационна форма на застрахователна защита, в която всеки притежател на полица е едновременно член застрахователно дружество, т.е. Това е асоциация на притежателите на полици с цел предоставяне на взаимопомощ). То е по-малко търговско ориентирано от застраховането на акции;
• Недържавни Пенсионен фонд(форма на лична осигурителна организация, която гарантира изплащането на допълнителна пенсия при достигане на пенсионна възраст).

Застраховането се класифицира по области на дейност, форми на изпълнение, форма на организация и видове застраховки.

Въз основа на областите на дейност на застрахователните организации се прави разлика между вътрешни и външни застрахователни пазари.

Формата на осигуряване може да бъде задължителна или доброволна.

Възможни са следните форми на организация: държавни, акционерни, взаимоспомагателни, кооперативни дружества.

Основни видове застраховки: имуществени застраховки, лични застраховки, застраховки гражданска отговорност, застраховки икономически рискове.

Днес нито една от руските застрахователни компании не може без използването на автоматизирани информационни системиза различни цели и нива на сложност. Застраховането е особен вид бизнес, който в много голяма степен зависи от способността на компанията да натрупва и бързо да извлича и обработва големи обеми точна и надеждна информация. Следователно въвеждането на пълноценна обработка на данни е един от основни елементипазарен успех и условие за динамично развитие.

Наличност на голямо количество организационни форми, видове застрахователни компании, видове застрахователни дейности, както и разн финансови възможностиотделни фирми, определя изискванията към използваните и проектирани автоматизирани застрахователни системи. Компаниите имат много големи разлики в нивата на техните стремежи, мащаба на проблемите, които трябва да бъдат решени с помощта на компютърни инструменти, както и в самите инструменти. Съответно резултатите от използването на компютърни технологии също се различават. В единия край на скалата започна с използването на локални, не-мрежови, евтини персонални компютри в комбинация с пиратски копия на софтуерни продукти, насочени към индивидуално използване на Word, Excel, ACCESS.

В другия край на скалата са системи, състоящи се от мощни централни компютри на IBM, DEC, Hewlett-Packard или Sun, към които са свързани една или повече локални мрежи от десетки персонални компютри. Системата включва отдалечени офиси, за които е разработен (или се разработва, или закупува) специализиран софтуер, насочен към максимално задоволяване нуждите на дадено застрахователно дружество. Между тези екстремни варианти има цяло разнообразие от междинни комбинации от стратегии, тактики и резултати от автоматизацията в застраховането.

Основни функции на застраховането:

Образуване на специализиран осигурителен фонд Пари;

Обезщетение за щети и лична финансова подкрепа на граждани;

Внимание застрахователно събитиеи минимизиране на щетите

Автоматизираните информационни системи на застрахователните компании трябва да обхващат всички елементи на технологичния процес.

Нека разгледаме основните функционални задачи, изпълнявани в автоматизираните застрахователни информационни системи:

Сключване на застрахователен договор. При сключване на договор е необходимо да се провери наличието на сключени по-рано договори и случаи на застрахователни плащания; изчисление корекционни факторикъм тарифната ставка и определяне на специални условия за всеки застрахован; определяне на комисионна на агента; въвеждане на договори в базата данни, издаване на необходимите документи.

Плащане на застрахователна премия(застрахователна премия - плащане на застрахователния риск на застрахователя към застрахователя по силата на закон или застрахователен договор). Прехвърляне на средства по сметки.

Край на застрахователния договор.Разплащания с притежателя на полицата; преместване на информация в базата данни за формиране на резерви.

Обидно застрахователно събитие . Изчисляване на обезщетение; осчетоводяване на пари в брой; актуализиране на базата данни.

Изчисляване на осн тарифни ставкипо вид застраховка. Натрупване на информация за конкретни видове застраховки, основни застрахователни събития; изчисляване на застрахователни ставки въз основа на статистически данни.

Изчисляване резервен фонд. Анализ на състоянието на сметките по видове застраховки по размер и брой договори; изчисляване на резервния фонд по стандарти и реални условия.

Анализ на застрахователния портфейл.Прогнозиране на тенденциите в развитието на застрахователния пазар, анализиране на състоянието на собствената дейност, моделиране на резултатите от управленските решения.

Анализ Финансово състояниекомпании.

Водене на вътрешно счетоводство.Изчисляване заплатислужители; отчитане на основни и оборотен капитал, изчисляване и превеждане на данъци и др.

Ключов принцип на изграждане автоматизирана системазастраховането е всеобхватност и единно информационно пространство. Този подход ни позволява да осигурим непрекъснатост на технологичния цикъл на компанията, да избегнем дублирането на входната информация, както и нейното прехвърляне към хартиен носителмежду отделите.

При автоматизиране на работата на застрахователна компания се създава база данни, която трябва да съдържа цялата необходима информация:

• застрахователни и презастрахователни договори;
• застрахователни стълбове;
  • парични преводи;
  • молби за изплащане на застрахователно обезщетение;
  • актове по осигурителни случаи и др.

Базата данни трябва да съдържа всички договори за дълъг период от време, тъй като при сключване на нови договори е необходимо да видите информация за всички съществуващи преди това договори и плащания за на този клиент. Такава информация е необходима за по-нататъшна работа с клиента, например предлагане на нови услуги, както и при изчисляване на тарифи и ставки на вноски.

Много застрахователни компании имат сложна географски разпределена структура: организация майка, регионални организации, клонове, представителства или агенции на компании, както и отдалечени потребители на мрежата. Отдалечените потребители са служители, които прекарват работното си време извън офиса на компанията, например инспектори, агенти на застрахователни компании, инспектори или мениджъри на почивка или командировки. Всяко ниво изисква собствена техническа поддръжка и бази данни.

В организациите-майки има една или повече високоскоростни локални компютърни мрежи с мощни компютри, файлови сървъри, използващи мрежова СУБД.

Регионалните организации могат да представляват големи подразделения и трябва да бъдат оборудвани със собствени мощни локални мрежи и снабдени със специални комуникационни канали за обмен на информация с организацията майка.

Клоновете на застрахователните компании имат малки локални мрежи и канали за комуникация с регионалните офиси.

Представителствата или агенциите на застрахователните компании разполагат с един или повече компютри.

Отдалечените потребители на мрежата използват лаптопи или преносими компютри, оборудвани с модеми.

От голямо значение за компаниите с географски разпределена структура е въпросът за организиране на обмен на информация и осъществяване на надеждно информационно взаимодействие между такива подразделения. Необходимо е да се осигури достъп до едни и същи данни на групи потребители, географски отдалечени един от друг. Например в регионалните организации е необходимо да се натрупа информация за транзакции, извършени в клонове, понякога разположени в различни градове на провинцията, или в организацията-майка е необходимо да се събере информация от регионални офиси, разпръснати из цялата страна, в различни страниили дори на различни континенти, въпреки това е необходимо да се организира обработката така, че резултатите от транзакциите да бъдат еднакви на всички нива на застрахователната компания.

В системата от бази данни има три нива:

• към отделите, където възниква по-голямата част от информацията, където се извършва застрахователна работа. Тук се съхранява информация за дейността на този отдел;
• регионалните организации събират данни от целия регион;
• Организацията майка съдържа информация, отразяваща работата на компанията като цяло.

Има два подхода за организиране на обработката на разпределени данни:

технология за разпределена база данни.Такава база данни включва фрагменти от данни, разположени на различни мрежови възли. От гледна точка на потребителите изглежда, че всички данни се съхраняват на едно място. Естествено, такава схема поставя строги изисквания към производителността и надеждността на комуникационните канали.

• репликационна технология.В този случай данните на всички компютри се дублират във всеки мрежов възел. В същото време: предават се само операции за модификация на данни, а не самите данни, предаването може да бъде асинхронно (неедновременно за различни възли), данните се намират там, където се обработват. Това позволява да се намалят изискванията за честотната лента на комуникационните канали; освен това, ако комуникационната линия на компютъра се повреди, потребителите на други възли могат да продължат да работят. Това обаче позволява неравномерни състояния на базата данни за различни потребители в един и същ момент. Следователно е невъзможно да се премахнат конфликтите между две копия на един и същи запис.

За застрахователните компании вторият подход е за предпочитане, тъй като не е необходима пълна синхронизация на информацията, достатъчно е базите данни да се привеждат в съответствие веднъж на ден.

В поделенията на застрахователните компании персоналните компютри са интегрирани в локална мрежа. За всеки специалист се създава специализирано автоматизирано работно място (АРМ), т.е. персоналните компютри са оборудвани с приложни програми, методически и езикови инструменти, които позволяват организиране на работата на специалистите на компанията. На всяко работно място се изпълняват само функциите, изпълнявани от конкретен специалист. Специалистът получава достъп само до тази част от базата данни, която е необходима за естеството на работата му.

Ефективно използване информационни технологииизисква на първо място реорганизация на бизнес процесите. От друга страна, само използването на автоматизирани информационни технологии позволява прилагането на много нови подходи в застрахователния бизнес. Голям западни компанииРазработването на нови автоматизирани системи е предшествано от научни изследвания, които идентифицират обещаващи области за развитие на бизнеса с цел укрепване на позициите му на застрахователния пазар.

Концепцията за предоставяне на достъп до информация по всяко време и от всяко място (за разлика от съществуващата концепция за канали за разпространение) означава предоставяне на потребителя на избор на всеки от много възможни начинидостъп до услугите на компанията. Концепцията вече се използва широко от фирми, работещи в индустрии като финансови услуги и на дребно. Точка за достъп в в такъв случайозначава предоставяне на потребителя на избор на някой от многото възможни начини за достъп до услугите на компанията. За да реализират тази концепция, клиентите се нуждаят от достъп както до специалистите, така и до базите данни на застрахователната компания чрез комуникационни канали ( електронна поща, фирмен уебсайт), чрез абонатна услуга, обикновена поща, телефон, факс.

Разработени са CRM системи (Customer Relationship Management), които осигуряват интегриран подход за автоматизиране на работата с клиенти и са насочени към предоставяне на най-удобната CRM услуга за потребителя. CRM е набор от специфични софтуери технологии, които ви позволяват да автоматизирате и подобрите бизнес процесите в областта на продажбите, маркетинга, обслужването и поддръжката на клиенти. Софтуерът ви позволява да координирате работата на различни канали за взаимодействие между компании и клиенти. Използването на модерни CRM системи също дава възможност да се оцени ефективността на разходите на различни маркетингови програми и промоции.

В същото време може да се анализира не само първоначалният отговор на потенциалните клиенти, но и конкретни финансови показатели, дори ако изминат няколко месеца между промоцията и сключването на договора. По-ясната организация на работата дава възможност да се концентрират усилията върху конкретно целева аудитория, управлява процеса на привличане на клиенти. Внедряването на CRM система позволява не само да се разшири клиентската база, но и да се направят продажбите предвидими. Когато говорим за добро следпродажбено обслужване, имаме предвид преди всичко професионализъм и навременна реакция на клиентските заявки. Сервизна поддръжка високо нивогарантира задържане и лоялност на клиентите, а CRM системата ще спомогне за осигуряване на непрекъсната и висококачествена работа на сервизния отдел.

Всичко това предполага, че внедряването на CRM система не само повишава ефективността на отделните отдели в компанията, но и спомага за установяването на ясно взаимодействие между тях.

Първото нещо, с което се сблъсква клиент, който се нуждае от помощ от застрахователна компания, е необходимостта да се обади на компанията. Съвременният световен стандарт налага организирането на сервизни центрове, така наречените кол центрове. Call center е система за обработка на голям брой телефонни обаждания, позволяваща паралелно използване на технически и човешки ресурси за работа ефективна работас клиенти.

Руските застрахователни компании - за разлика от западните и дори руските банки - все още не са внедрили тази технология. Компанията, която първа рискува да инвестира в създаването на кол център, ще може да привлече голям брой лоялни клиенти, т.к. Невъзможността да се свържем веднага с вас, ако възникне проблем със застраховката, е добра причина да потърсите друг застраховател.

Клиент, който се обажда, никога няма да остане без отговор и взаимодействието се осъществява професионален персонал, по ясно определен алгоритъм и със задължителна фиксация подробна информацияза всички операции. При получено обаждане на някой от телефонните номера, системата автоматично определя от кой номер е обаждането и за каква тема се отнася. След това, след като определи темата, системата преразпределя обаждането до безплатен оператор, който е компетентен да отговори на темата на разговора. Едновременно с получаването на обаждане операторът вижда на монитора информация за темата на входящото повикване и подкана с алгоритъм за отговор и база данни, която трябва да бъде попълнена по време на отговора на оператора.

Ако всички оператори са заети, тогава системата за интелигентна обработка на повикванията се включва и абонатът получава информация за прогнозираното време на изчакване за отговор от оператора и, използвайки гласови менютаможе да слуша информация по тема, която го интересува. Той също така може самостоятелно да въвежда всякакви данни в системата. Кол центърът ви позволява да разрешите проблемите на повечето обаждащи се клиенти, като превключвате абоната към оператор само в необичайни случаи.

Освен това софтуерът на кол център предоставя широк набор от статистическа информация за обслужването на разговори, която, когато се комбинира с база данни, попълнена от оператора, може да предостави допълнителни данни (например зависимостта на продължителността на разговора или времето на разговора от възрастта на обаждащия се или неговия район на пребиваване).

Разработчиците на автоматизирани застрахователни системи непрекъснато подобряват софтуерните продукти, които създават, разширявайки ги функционалност, прилагайки интегриран подход за обработка на информация, използвайки нови информационни технологии. Застрахователните компании обаче са изправени пред големи проблемипри използване на информационни технологии. Има няколко причини за това:

първо, нестабилността на вътрешното застрахователно законодателство. Само стабилни процеси могат да бъдат автоматизирани;

второ, поради големите различия в дейността на застрахователните компании и динамичното развитие на застрахователния бизнес, застрахователните компании са много труден обект за автоматизиране. Фирмите, работещи на този пазар, не са в състояние да покрият всичко възможни вариантифункционирането на застрахователната компания. От друга страна, ако такъв продукт бъде създаден, би било много скъпо както за първоначална покупка, така и за експлоатация;

трето, и това е проблем не само на застрахователните компании, липсата на правна рамка за поддържане на софтуерните продукти след продажбата. Предлагайки модерни системи за промишлена автоматизация, обещаващи консултации и техническа поддръжка, разработчиците
Те на практика оставят клиентите си сами с проблемите си. И има много такива проблеми:

Обещание за необходимостта от актуализиране на системата (системата става безнадеждно остаряла за 2-3 години),

застрахователни дейности. В момента на пазара има около 5-6 автоматизирани решения за застрахователни компании. След закупуване добро решениеСега, след 2-3 години, застрахователната компания открива, че системата й е безнадеждно остаряла! Тогава те започват да разклащат компанията за разработка, която е продала системата. Обикновено от другия край на телефонната линия отговарят, че скоро си тръгват нова версия, за което ще трябва да платите „малко“ допълнително. В същото време те обещават да направят отстъпки, като редовни клиенти! Обикновено такива отстъпки не надвишават 30-40%.
Има и друг проблем, когато един бизнес започне да се развива много динамично и трябва да се представят нови застрахователни продукти на пазара. Следователно нещо в системата трябва да се подобри, нещо трябва да се коригира някъде... Този вид работа, като правило, се изчислява по отделен ценоразпис! Само не си мислете, че сте сами с нас! Ще трябва да почакате малко... Обадете се утре или след шест месеца...
Това е мястото, където застрахователната компания се закача... още веднъж. След кратка консултация ръководството решава да напише всичко сами или да го повери на някоя софтуерна компания. И всичко се връща към нормалното...
Това са само първите проблеми, с които се сблъскват повечето руски застрахователни компании.

През последните няколко години застрахователните компании са толкова загрижени за проблемите си и конкуренцията на пазара, че технологичният компонент на бизнеса не е на първо място в интересите им. Ето защо вътрешният застрахователен пазар обръща твърде малко внимание на внедряването на ИТ решения.

Има обаче застрахователи, които разбират: високите технологии са бъдещето, но това бъдеще трябва да се гради днес. Председателят на УС на застрахователна компания ВУСО говори за ролята на автоматизацията в застраховането, онлайн продажбите и Александър Шойхеденко.

- Трябва ли застрахователите да инвестират в технологии?

Автоматизацията в застраховането, както във всяка търговска индустрия, която работи с голям брой клиенти, е обективна необходимост. Освен това говорим не само за продажби или сетълмент, но и за всички бизнес процеси. В САЩ и Европа повечето от неоперативните разходи на застрахователната индустрия се изразходват за поддържане и развитие на ИТ инфраструктура. Това е доказателство, че застрахователите разбират важността на използването на съвременни системи, които могат да подобрят ефективността на продажбите, да подобрят управлението на загубите и да не говорим за финансовото счетоводство. Банките например отдавна са автоматизирали процесите си и не могат да си представят как могат да попълнят договор за депозит на ръка и след това да въведат информацията в Информационната система. Украински застрахователи, уви, в по-голямата си част все още не са загрижени за този въпрос. Но съм сигурен, че тенденцията ще се промени в близко бъдеще.

Въпреки това местните компании се опитват да въведат онлайн продажби. Оказва се, че автоматизацията не влияе на развитието на този канал?

Нека ви дам един прост пример. Когато една застрахователна компания има софтуерен пакет, който ви позволява да автоматизирате повечето процеси, тогава можете да „окачите“ определен уеб интерфейс върху него, който ще служи за промоция и комуникация с клиента. След това на базата на попълнените от клиента данни автоматично се създава застрахователен договор; плащането, извършено с карта, автоматично се свързва с договора. Остава само да връчим договора на клиента. Освен това, веднага щом застрахователното законодателство се адаптира към съвременната електронна търговия, доставката на полици вече няма да е необходима и човешко участие в процеса на продажба също ще стане ненужно. Като продажба на билети за влак или самолет. Но ако цялата документация се съхранява архаично на хартиен носител или в счетоводни програмиАко създаването на застрахователни договори не е автоматизирано, тогава дори и най-модерната система за продажби няма да има практически никакъв ефект. И повечето онлайн магазини днес са красива рекламна платформа, където можете да оставите заявка, да изчакате обаждане от компанията и след това да се върнете към стандартния „човешки“ процес на продажба.

- Колко опит има вашата компания в автоматизирането на бизнес процеси?

- “ВУСО” се занимава с автоматизация от 2003г. В тази насока си сътрудничим активно с компанията Nexstep Solutions, с чиято подкрепа успяхме да автоматизираме много процеси в продажбите, сетълмента, подписването, счетоводството и финансите. Днес повечето застрахователни договори се създават в системата, което гарантира тяхното 100% съответствие с фирмените стандарти. Това наистина е прецедент, тъй като в 90% от случаите процесът изглежда различно: първо продавачите сключват договори, след това счетоводителите ги проверяват, след това данните за договорите се въвеждат в бази данни. Автоматизацията намалява човешките разходи и елиминира човешкия фактор. Освен това 80% от застрахователните плащания са автоматично обвързани със застрахователни договори, което позволява рязко намаляване на броя на счетоводния персонал. Основното предимство на използваната система е автоматизацията на процесите, а не само записването на документи.

- Към каква гама застрахователни продукти е насочен вашият онлайн магазин?

Разполагайки с такава мощна система за управление, ние просто нямаше как да не гледаме на Интернет като на обещаваща платформа за продажба на застрахователни продукти. На първо място, това са прости продукти на дребно - MTPL, CASCO и застраховка за пътуване. Първо, това са стандартизирани продукти, които може да се каже, че са при почти еднакви условия за всички застрахователи; второ, има стабилно търсене за тях. В този случай ние рекламираме не продукт, а услуга. По-сложните продукти без човек трудно се продават.

- Каква е същността и предимствата електронна политикаОСАГО?

Днес, с развитието на информационните технологии, е възможно да се обединят всички процеси, свързани с разпространението на формуляри и прилагането на задължителните застраховки „Гражданска отговорност на автомобилистите“ в единна информационна система, последвано от пълен отказ от използване на формуляри и застраховки при условията за предоставяне на притежателя на полицата на електронна полица.

Предимствата на електронната полица са огромни. На първо място, това е инструмент, който ще ви позволи да избегнете всякакви видове застрахователна измамана етап продажби. В края на краищата, това се случва днес, например, в сегмента на гражданската отговорност: застрахователен агент получава 500 формуляра на полици за гражданска отговорност, които в крайна сметка уж губи, но всъщност продава „навън“ и поставя получените застрахователни плащания в джоба си. Но има прецеденти на пазара, когато застрахователните компании загубиха 10 и дори 100 хиляди банки от полици за гражданска отговорност. Второ, значителни спестявания при печат, доставка, пълнене, съхранение хартиени полици. Трето, това е уникален инструмент за наблюдение на застрахователите-членове на MTIBU. Например днес, след отнемане на лиценз, един застраховател остава с десетки хиляди полици.

- Работи ли при вас?

- Кога да очакваме въвеждането на електронна политика на законодателно ниво?

Много разчитаме на приемането на Закона за застраховането през г ново издание, с което ще се легализира електронната форма на застрахователния договор. Наистина, в момента необходимостта да получим „парче хартия“ с печат е една от основните пречки в нашата работа.

- Какви резултати постигна компанията в интернет направление?

Поне динамиката на развитие е добра. Година по-късно делът на този канал в цялото портфолио на компанията е приблизително 1%. И през следващите 2-3 години възнамеряваме да увеличим тази цифра до 10%. Това е съвсем реално. В края на краищата, ако вземем примера на Обединеното кралство, тогава само чрез задължителната автомобилна застраховка продажбите през интернет са над 50%. В допълнение, лоялността на клиентите, получена чрез онлайн магазин, е много по-висока.

- Други застрахователни компании имат ли подобни или подобни интернет проекти?

Някои застрахователи се опитват да реализират подобни проекти, но никой няма такава система в нейната цялост. Някои например нямат възможност за безкасово плащане на полица, а други все още трябва да посетят офиса на застрахователната компания, за да получат своето копие от договора. Затова този сегмент е в начален стадий и ние възнамеряваме сериозно да го развием и да го пуснем на крак. Ако надхвърлим застрахователния пазар, има проект, който смятам за отлично внедряване на интегрирана система - това е онлайн магазинът на Ukrzaliznytsia за продажба на железопътни билети. Много демонстративен, удобен и проверен механизъм. Вярно, успехът му беше до голяма степен улеснен от законодателното прилагане на електронен документ, благодарение на който не е необходимо да се отпечатва или подписва нищо. А това е огромно спестяване на време и пари, както за клиента, така и за компанията, внедрила такъв механизъм.

Как вашата компания възнамерява да популяризира услугата си?Не е тайна, че доверието на украинските потребители в различни иновации е финансов пазармного ниско?

Ние разделяме стратегията за популяризиране на нашата услуга на два компонента, офлайн и онлайн. Всеки има своя задача, която в крайна сметка трябва да ни доведе до желания резултат.
Разбира се, популяризирането на тази услуга е много трудна задача и най-важното не е евтина. В края на краищата на потребителите всъщност ще трябва да се каже „на пръсти“, че има такава услуга, тя е удобна и наистина работи. Но виждаме перспективи в този канал за продажби и сме уверени, че след няколко години той ще покаже растеж.

Въз основа на факта, че основната дейност на застрахователния брокер е продажба на застрахователна защита като финансови услугис най-висок приоритет е автоматизирането на следните направления от дейността на застрахователния брокер:

• · Директно автоматизиране на застрахователната дейност. Автоматизация на фронт офиса, управление на директни застрахователни договори, поддържане на клиентски данни, колекции, работа със строги отчетни форми
• · Автоматизация на управлението на взаимодействието с клиентите. Взаимодействие с клиенти, поддръжка на процеса на продажба, кол център, анализ на клиентски данни, управление на маркетингови данни.
• · Автоматизация на счетоводните процеси. Поддържане на общ бизнес и данъчно счетоводство, изготвяне на регламентирана отчетност.
• Автоматизация управленско счетоводство. Счетоводство на приходите и разходите, каса, управленска отчетност.
• · Автоматизация на търговските обекти. Фронт офис автоматизация, организиране на разпределена база данни.

Нека да разгледаме автоматизирането на работния процес на застрахователен брокер, като използваме примера на програмата Insurance Broker 8.3, която е цялостно решение, което ви позволява да поддържате записи на дейностите на организация, която продава полици от различни застрахователни компании. Гъвкавата и изчерпателна концепция за документооборот ви позволява впоследствие да получите пълен анализ на дейността на брокера за всеки период от време. Тази система се използва както от застрахователни брокери, така и от организации, чиято основна дейност не е застраховане, като например автокъщи. С малко адаптиране програмата може да се използва и от кредитни посредници. Възможно е да се автоматизира агентската мрежа с обмен на информация в в електронен формат, което намалява нуждата от системни оператори и повишава точността на въведените данни.

· Отчитане на застрахователни продукти (видове застраховки).

За съхраняване и използване на информация за необходимите застрахователни полици системата предоставя справочник „Видове застраховки”.

Фигура 3.1.Справочник "Видове застраховки"

Потребителят може лесно да добавя или променя информация за конкретен застрахователен продукт. Възможно е да се свържете с една или повече застрахователни компании.

· Осчетоводяване на продадени полици.

Системата ви позволява да съхранявате неограничен набор от данни за всяка продадена застрахователна полица. В допълнение към стандартния набор от полета за попълване (пълно име на застрахователя, обект на застраховка с всички данни, период на застраховка, цена на полицата, размер на собствени и агентски комисионни и др.), е възможно да създадете необходимите полета от потребителя. Всяка политика може да съхранява прикачени към нея файлове. Това могат да бъдат сканирани документи или снимки.

Ориз. 3.2.

Възможна е продажба на полици с плащане на вноски по разплащателен график. Плащането в системата може да бъде три вида: в брой, безкасово и директно. Директно плащане възниква, когато клиентът плаща на застрахователната компания, а брокерът получава комисионна от застрахователната компания.

Възможността за автоматично изчисляване на вашите собствени и агентски комисионни според предварително определени условия ще улесни работата на служителя на финансовите услуги и ще помогне да се избегнат грешки в изчисленията. В допълнение към простото изчисляване на сумата на комисионната е възможно да се посочи дали агентът/брокерът трябва да я преведе и след това да я получи обратно в отделно плащане, или може да изпрати плащането минус дължимата комисиона.

Ориз. 3.3.

Анализът на системата ви позволява да следите датите на изтичане на полиците и датите на следващите плащания.

За намаляване на разходите за труд за въвеждане на полици в системата е възможно автоматично въвеждане на полици от отчета на агента в Excel форма.

· Взаимоотношения със застрахователни компании.

Въз основа на данните от застрахователните полици системата позволява автоматично генериране на справки за застрахователните компании. За попълване на данни е предвиден набор от механизми за улесняване на работата на служителите на финансовите услуги.

Финансовите документи (bordero), генерирани според отчетните данни, могат да бъдат отпечатани или запазени в електронен вид (excel, html формати и др.) с последваща обработка.

· Осчетоводяване на молбите за кредит.

За брокерите, участващи в подготовката на документи за банките за кредитиране, ще бъде полезна подсистема за регистриране на движението на документи за кредитиране. Заявлението за кредит записва банките, до които са изпратени документите, а вградената система за напомняне ще напомня на мениджъра за необходимостта да следи състоянието на определена дата.

Ориз. 3.4.

Въз основа на данните, въведени в системата Застрахователен брокер 8.3, ръководителят на предприятието може да генерира редица аналитични справки за финансови дейностив различни раздели.

Докладвай " Финансови резултати» ви позволява да оцените обема на продажбите на полици и рентабилността за конкретна застрахователна компания.

Ориз. 3.5.

Отчетът на агента показва колко полици е продал даден агент и какъв размер на комисионата му се дължи.

Ориз. 3.6.

Докладът за сетълмент показва данни за паричния поток и крайния баланс.

Всички анализи имат пълна детайлност, тоест можете да генерирате списък с документи, въз основа на които данните са включени в отчета, което позволява на служител на финансовата служба да проследи задълбочено всички възможни счетоводни грешки.

· Отчитане на бланките за строга отчетност.

Подсистемата за отчитане на формуляри за строга отчетност (SSR) ви позволява да проследявате пълния път на движение на формулярите от застрахователната компания до крайния купувач.

Ориз. 3.7.

Поддържат се както прости, така и сложни схеми за номериране на формуляри. За улесняване работата на оператора са предвидени механизми за въвеждане на голям брой форми.

Ориз. 3.8.

Системата за контрол на баланса ви позволява да следите минимално необходимото количество в офиса, както и статуса на всеки формуляр с помощта на отчета "BSO Remains"

Ориз. 3.9.

Докладът за движение предоставя подробна информация какво и кога се е случило с конкретна форма.

Ориз. 3.10

Типовете формуляри (полица MTPL, полица CASCO, разписка) се създават от самия потребител в съответната директория. Възможно е свързване по застрахователни компании и видове застраховки. Броят на видовете формуляри в системата е неограничен. Всеки формуляр в системата може да бъде придружен с произволен коментар.

Съществуващите в системата документи ви позволяват да отразявате следните движения на BSO:

разписка / връщане към застрахователната компания

трансфер / връщане от агент

прехвърляне на формуляри директно между агенти

отписване на формуляра, ако е изгубен

въвеждане на начални салда

Всеки документ може да бъде отпечатан под формата на сертификат за приемане. Възможно е също така да свържете печатни формуляри, използвани във вашия документен поток.

· Управление на агентска мрежа.

Програмата предвижда обмен на данни в електронен вид между брокера и субагента. Субагентът може да води записи както в подобна програма, така и в обикновен Excel. Документи за приемане и предаване на формуляри за строга отчетност и застрахователни полици директно са достъпни за обмен. Така брокерът намалява необходимостта операторите да въвеждат данни за полицата в програмата. При използване на Excel се използва файл с определен набор от колони, който се попълва от субагента и се предава на брокера.

· Интеграция с други счетоводни системи.

За работа системата използва платформата 1C Enterprise 8.1, което прави системата многопотребителска и практически неограничена от локалната мрежа.

За предаване и получаване на информация ( финансови документии т.н.) се използва механизъм за обмен на данни в XML формат.

· Други възможности.

Счетоводно отчитане на застрахователни събития - за да може да се отчетат щетите на застрахования се осигурява запис на всичките му застрахователни събития.

Доклад за оценка на работата на операторите по въвеждане на документи в базата данни.

Описание на работните процеси на застрахователен брокер в програмата:

• · Анализ на продажбите на застрахователни брокери;
• · Анализ на продажбите по агенти;
• · Представяне на нова застрахователна компания, агент, застраховател;
• · Въвеждане на нов вид застраховка;
• · Разлепване на бланки за строга отчетност;
• · Проследяване на регулярни премии по полици, платени на вноски;
• · Проследяване на изтичането на застрахователните полици;
• · Предаване на формуляри на агента;
• · Разпродажба застрахователна полица;
• · Създаване на отчет за застрахователна компания.

ь Анализ на продажбите на застрахователен брокер.

За анализ на продажбите програмата предоставя отчет „Финансови резултати” (меню „Финанси” - „Финансови резултати”). Тази справка показва данни за сключени застрахователни договори за определен или цял период от време. В допълнение към общите резултати, справката може да показва резултати за отделни застрахователни компании и видове застраховки. В долната част на справката се извежда информация за броя на новосключените договори и броя на приетите вноски (за разсрочени договори).

Ориз. 3.11.

В допълнение към посочването на периода за генериране на отчета, застрахователният брокер може да посочи конкретна организация, застрахователна компания и вид застраховка (Гражданска отговорност, КАСКО, Гражданска отговорност). Настройките на отчета могат да бъдат запазени за по-късна употреба чрез бутона. Така следващия път, когато го отворите с натискане на бутона, можете бързо да възстановите настройките.

Застрахователната премия е сумата, която клиентът трябва да заплати по застрахователния договор. Застрахователна премия минус отстъпка - сумата, платена от клиента по договора минус отстъпката, направена от брокера на база собствената му комисионна.

Отстъпка - размерът на отстъпката, направена от брокера на база собствената му комисионна.

Собствена комисионна - процентът и размерът на собствената комисионна на брокера.

Застрахователна премия минус комисионна - сумата за превод към застрахователната компания без брокерска комисионна.

Агентско комисионно - размерът на комисионното на агента, сключил застрахователния договор.

Печалбата е сумата на комисионната на застрахователния брокер минус комисионната на агента.

Справката „Финансови резултати” в програмата „Застрахователен брокер 8.3” ще покаже по-подробна информация (с детайли до конкретен документ), ако щракнете двукратно с курсора на мишката върху реда за групиране по вид застраховка. Това ще отвори отделен прозорец за отчет.

Ориз. 3.12

Потребителят на програмата може да получи достъп до документите, показани в този прозорец, като щракне два пъти с курсора на мишката върху желания ред.

Данните в този прозорец могат да бъдат генерирани наново, като първо зададете параметрите на отчета (период, организация, застрахователна компания, вид застраховка, контрагент) и щракнете върху бутона „Генериране“.

Информацията от всеки прозорец може да бъде отпечатана чрез менюто „Файл“ - „Печат“. Ако бутонът „Печат“ в менюто не е наличен, трябва да щракнете веднъж с курсора на мишката където и да е в отчета и след това да опитате да отпечатате отново. Можете също да запишете данни във външен файл. За да направите това, щракнете върху бутона „Запазване на копие“ в менюто „Файл“. В прозореца, който се отваря, изберете името на файла и неговия тип. За да запазите в Excel, трябва да изберете тип „Excel97 Sheet“.

ь Анализ на продажбите по агенти.

За анализ на продажбите на застрахователни полици от агенти, програмата Insurance Broker 8.3 предоставя справка „Отчет по агенти” (меню „Финанси” - „Отчет по агенти”). Този отчет показва данни за застрахователни договори, сключени от агенти за определен или цял период от време.

За да генерирате отчет, трябва да щракнете върху бутона „Генериране“.

Колоните на отчета показват следната информация:

Сума на плащане - сумата, която притежателят на полицата е платил за застрахователната полица.

Комисионна - размерът на комисионната на агента, сключил договора.

Ориз. 3.13.

Ако е необходимо, отчетът може да генерира данни за конкретни, а не за всички агенти и организация, като първо ги изберете в полетата за настройки на отчета.

“Отчет за агенти” в програмата “Застрахователен брокер 8.3” ще покаже по-подробна информация (с детайли до конкретен документ), ако щракнете двукратно с курсора на мишката върху реда за групиране по вид застраховка. Това ще отвори отделен прозорец за отчет.

b Влизане в нова застрахователна компания, агент, титуляр на полица.

• 1. Щракнете върху менюто „Директории“, „Контрагенти“. Ще се отвори директория „Контрагенти“.

Ориз. 3.14.

3. Попълнете полетата:

Име. Въведете името на контрагента.

Законни / физически лице. Ако контрагентът е образувание(например застрахователна компания) в полето трябва да изберете с бутона "Юридическо лице", ако това е частно лице (например агент), изберете "Физическо лице".

Група от контрагенти. Тук трябва да посочите в коя група искате да поставите новия контрагент, за застрахователна компания изберете групата „Застрахователни компании“.

Пълно име/пълно име. Второто име може да се различава от първото. Например, за застрахователна компания можете да въведете „ROSNO“ в името и OJSC IC „ROSNO“ в пълното име.

ТИН. TIN на контрагента.

Документ. За физическо лице тук въведете данните за вашия документ за самоличност.

рожден ден. Рожденият ден на дадено лице обикновено се въвежда за притежателите на полици.

Източник на информация. Тук можете да посочите откъде притежателят на полицата е научил за вас. Стойността се избира от директорията "Източници на информация" чрез натискане на бутона.

Коментар. Безплатен текст на коментар.

4. В раздела договори можете да въведете данни за договора между вашата организация и контрагента. Това е задължително застрахователната компания, в противен случай нейното име няма да фигурира в списъка за избор, където е необходимо. За да добавите нов договор, щракнете върху „Действия“, „Добави“ или бутона. Ще се отвори формулярът за нов елемент от директория.

Ориз. 3.15.

Попълнете полетата:

Организация. Изберете името на собствената си организация, с която се сключва договорът, като щракнете върху бутона.

Име. Името на договора е произволно, но е по-добре да посочите неговия номер тук.

Дата на споразумението. Дата на сключване на договора.

Валута. Валута на договора.

След попълване щракнете върху "OK".

• 5. В раздела "Контакти" попълнете необходимата информация за контакт.
• 6. Щракнете върху OK.

ь Въвеждане на нов вид застраховка.

1. Щракнете върху менюто „Указатели“, „Видове застраховки“. Ще се отвори директорията „Видове застраховки“.

Ориз. 3.16.

• 2. Щракнете върху Действия, Добавяне или бутон. Ще се отвори формулярът за нов елемент от директория.
• 3. Попълнете полетата:

Име. Въведете името на застрахователния продукт, под който ще бъде отчетен в програмата (например „MTPL“)

• 4. Ако е необходимо вид застраховка да се предлага само за една или няколко (не всички) застрахователни компании, добавете имената им в таблицата „Застрахователни компании“:
• 4.1 Щракнете върху бутона под „Застрахователни компании:“, за да добавите нова линиякъм масата.
• 4.2 В колона „Застрахователна компания” на нов ред щракнете върху бутона. Ще се отвори директория „Контрагенти“.

Ориз. 3.17.

4.3 Намерете желаната застрахователна компания и щракнете двукратно върху нея с курсора на мишката. Компанията ще бъде прехвърлена на масата.

Натиснете OK.

ь Разлепване на бланки за строга отчетност.

1. Изберете елемент от менюто „BSO Accounting“, „BSO Receipt“. Ще се отвори дневникът на документа за разписки на BSO.

Ориз. 3.18.

Ориз. 3.19.

Списъчните данни за избора са взети от директория "Контрагенти". Ако не е в списъка правилната компаниятрябва да проверите:

Компанията има споразумение с организацията; това може да се провери в раздела „Споразумения“ във формуляра на контрагента.

• 4. Щракнете върху бутона "Попълване". Ще се отвори прозорец за попълване на формуляри.
• 5. Попълнете полетата в секцията „Номериране на формуляри“:

Вид на формулярите. Изберете името на типа формуляр (например OSAGO), като щракнете върху бутона.

Данните от списъка за избор са взети от директорията BSO Types.

Серия. Ако формулярът има серия, посочете я в това поле (например BBB).

Номер на първата форма. В това поле въведете номера на първата бланка от пакета (например 0469815971). Ако номерът на формуляра има сложен формат, например - 012/0234/08, където променящият се номер е 0234, тогава трябва да въведете номер - 234 в полето и след това да изберете шаблон за номериране в полето „Шаблон“.

Количество. Тук въведете броя на формулярите в пакета (например 10).

6. Ако номерът на формуляра и номерът на полицата не съвпадат, тогава в секцията „Номериране на полици“ попълнете полетата:

Първи номер на полица. Тук номерът на първата политика се задава, съответстващ на номера на първия формуляр в стека от формуляри.

проба. Това поле става видимо, ако след избора на типа формуляр програмата е намерила шаблон за номер за него. Може да има няколко шаблона; това поле показва този, който е необходим в момента. Шаблон за номер се създава в директория "Шаблони за номериране" на меню "BSO Счетоводство" и се използва за сложен номер формат, например - 012/0234/08.

Използвайте шаблон. Ако не поставите отметка в това квадратче, шаблонът за номериране няма да се използва.

• 7. Щракнете върху OK. Табличната част на документа за получаване трябва да бъде попълнена.
• 8. Ако трябва да отпечатате документа, щракнете върху „Записване“, след което върху „Печат“. Бутонът "Печат" ще бъде видим, ако за документ е в директория "Външни". печатни форми„регистрирани са печатни формуляри.
• 9. За да публикувате формулярите в баланса, щракнете върху „OK“. Документът ще бъде публикуван и затворен.

ь Проследяване на следващи вноски за разсрочени полици.

За проследяване на плащания за полици, платени на няколко плащания в различно време, програмата "Застрахователен брокер 8.3" предоставя отчета "График на редовните плащания" (меню "Застраховка")

Този отчет се генерира за служители на компанията, които се занимават с уведомяване на притежателите на полици за необходимостта от извършване на следващото плащане по застрахователната полица.

За да генерирате отчет, първо трябва да посочите периода от време, в който се очаква да бъдат получени пари от застрахованите. След това трябва да кликнете върху бутона "Генериране".

Ориз. 3.20.

Генерираният отчет показва данни, групирани за всяка отделна политика. Тази група показва следната информация:

Номер на полица, застрахователна компания

Информация за контакт - Име на притежателя на полицата и неговата информация за контакт.

За всяка политика има две допълнителни групи от записи:

„Трябва да се плати“ - тук са посочени планираните плащания, които попадат в даден период. Данните се вземат от таблиците „График за плащане” на документите „Застрахователна полица”.

“Платено” - тук са посочени получените плащания за даден период от време. Данните в тази група идват от въведените документи „Плащане” (за редовни вноски) и „Застрахователна полица” (за първа вноска)

Информацията от прозореца на отчета може да бъде отпечатана чрез менюто „Файл” - „Печат”. Ако бутонът „Печат“ в менюто не е наличен, трябва да щракнете веднъж с курсора на мишката където и да е в отчета и след това да опитате да отпечатате отново. Можете също да запишете данни във външен файл. За да направите това, щракнете върху бутона „Запазване на копие“ в менюто „Файл“. В прозореца, който се отваря, изберете името на файла и неговия тип. За да запазите в Excel, трябва да изберете тип „Excel97 Sheet“.

b Проследяване на изтичането на застрахователните полици.

За проследяване на полици, които изтичат, програмата Insurance Broker 8.3 предоставя отчета „Изтичане на застрахователните полици“ в менюто „Застраховка“. Този отчет се използва от служители, участващи в уведомяването на застрахованите за необходимостта от сключване на нов застрахователен договор. За да генерирате справка, трябва да изберете периода, в който да изтече застрахователната полица и да кликнете върху бутона „Генериране“.

Данните от отчета се показват в следните колони:

Застраховател – за когото е сключен застрахователният договор.

Застрахователна компания - с коя застрахователна компания е сключен застрахователният договор.

Срок на валидност - срокът на валидност на полицата.

Обект на застраховане - предмет на застраховка по договора.

Контакти - информация за контакт на притежателя на полицата.

Застрахователната премия е цената на полицата.

Отчетът включва полици със стойност на атрибута “Застрахователен период за”, който попада в избрания период. Ако е необходимо, можете да генерирате отчет за всякакви допълнителни подробности за правилата, като ги посочите предварително в настройките на отчета.

Фиг.3.21.

Освен това в документа „Застрахователна полица“ този допълнителен детайл трябва да има определена стойност (да не е празна). Такива допълнителни подробности могат да бъдат например „Периодът на използване приключва“. За да се появят такива допълнителни подробности в документа „Застрахователна полица“ в таблицата „Допълнителни подробности“, той трябва да бъде създаден в директорията „Допълнителни подробности“

Информацията от прозореца на отчета може да бъде отпечатана чрез менюто „Файл” - „Печат”. Ако бутонът „Печат“ в менюто не е наличен, трябва да щракнете веднъж с курсора на мишката където и да е в отчета и след това да опитате да отпечатате отново. Можете също да запишете данни във външен файл. За да направите това, щракнете върху бутона „Запазване на копие“ в менюто „Файл“. В прозореца, който се отваря, изберете името на файла и неговия тип. За да запазите в Excel, трябва да изберете тип „Excel97 Sheet“.

ь Предаване на формуляри на агента.

Ориз. 3.22.

• 2. Щракнете върху Действия, Добавяне или бутон. Ще се отвори нов формуляр за документ.
• 3. Попълнете задължителните полета:

Организация. Изберете името на вашата организация, като щракнете върху бутона.

Данните за списъка за избор се вземат от справочник "Организации".

агент. Изберете името на агента, като щракнете върху бутона. Ще се отвори директория "Контрагенти". Намерете желания агент, щракнете двукратно върху него с курсора на мишката.

4. Щракнете върху бутона "Попълване". Ще се отвори прозорец за избор на формуляри, в таблицата ще бъдат изброени всички формуляри, които избраната организация има на склад.

Ориз. 3.23.

5. За да изберете формуляр, трябва да поставите отметка на съответния ред от таблицата.

Можете също да използвате бутоните за групово маркиране, като първо маркирате необходимите редове (когато щракнете върху ред, той се маркира в синьо) и можете да използвате клавишите „SHIFT“ и „Ctrl“. Ако трябва да намерите формуляр с конкретен номер, щракнете с курсора на мишката в колоната „Номер“ на произволен ред и след това въведете номера от клавиатурата. Програмата ще търси формата по първите знаци. Ако списъкът с формуляри е много голям, тогава той може да бъде съкратен с помощта на полетата за персонализиране чрез избиране необходими параметриформи:

Застрахователно дружество. Изберете името на застрахователната компания, като щракнете върху бутона. Списъчните данни за избора са взети от директория "Контрагенти". Ако фирмата, от която се нуждаете, не е в списъка, трябва да проверите:

фирмата е в директория "Контрагенти" и се намира в папка "Застрахователни компании" (името на папката е изписано в константите на програмата).

компанията има споразумение с организацията; това може да се провери в раздела „Споразумения“ във формуляра на контрагента.

Вид на формулярите. Изберете името на типа формуляр (например OSAGO), като щракнете върху бутона. Данните от списъка за избор са взети от директорията BSO Types.

Серия. Посочено е кои серии трябва да бъдат показани формулярите.

• 5. Щракнете върху OK. Избраните формуляри ще бъдат прехвърлени в документа.
• 6. Ако трябва да отпечатате документа, щракнете върху „Записване“, след което върху „Печат“. Бутонът „Печат“ ще бъде видим, ако формуляри за печат са регистрирани за документа в директорията „Външни формуляри за печат“.
• 7. За да преместите формулярите в баланса на агента, щракнете върху „OK“. Документът ще бъде публикуван и затворен.

Търсене на съществуващ документ за редактиране:

• 1. Изберете елемента от менюто „Счетоводство на BSO“, „Прехвърляне на формуляри към агент“. Ще се отвори регистърът на документите за прехвърляне на BSO към агенти.
• 2. Ако списъкът с документи е много голям, използвайте бутоните за управление на журнала
• 3. Кликнете два пъти върху необходимия документ. Ще се отвори формулярът на документа.
• 4. Направете необходимите промени и щракнете върху OK.

ь Продавам застрахователна полица.

За въвеждане на данни за продадена застрахователна полица програмата използва документ „Застрахователна полица”.

Създаване на нов документ:

• 1. Изберете елемент от менюто "Застраховка", "Застрахователна полица". Ще се отвори регистърът на документите на продадените полици.
• 2. Щракнете върху Действия, Добавяне или бутон. Ще се отвори нов формуляр за документ.

Ориз. 3.24.

3. Попълнете задължителните полета:

Организация. Изберете името на вашата организация, като щракнете върху бутона.

Данните за списъка за избор се вземат от справочник "Организации".

Застрахователно дружество. Изберете името на застрахователната компания, като щракнете върху бутона.

фирмата е в директория "Контрагенти" и се намира в папка "Застрахователни компании" (името на папката е изписано в константите на програмата).

Компанията има споразумение с организацията; това може да се провери в раздела „Споразумения“ във формуляра на контрагента.

Видът застраховка изобщо не е свързан със застрахователни компании или избраната застрахователна компания е в обвързващия списък и също е маркирана в директорията „Видове застраховки“.

Притежател на полица. Въведете името на притежателя на полицата. Полето се попълва в произволна форма. Има два варианта за попълване на полето:

Натисни бутона. Ще се отвори директория "Контрагенти". Намерете желания застраховател и кликнете два пъти върху него с курсора на мишката. Ако това, от което се нуждаете, не съществува, създайте го.

Въведете името директно в полето “Застрахован”, програмата ще търси директорията “Контрагенти” по първите букви и ако не я намери, автоматично ще създаде нова.

В това поле трябва да посочите обекта на застраховка, например автомобил. В прозореца, който се отваря, въведете данни за застрахователния обект и щракнете върху „OK“. След това прозорецът ще се затвори и обектът ще се появи в директорията, щракнете двукратно върху него с курсора на мишката.

Дата на сключване. Тук посочете датата на сключване на застрахователния договор.

Период на застраховката от - до - Посочете срока на валидност на полицата.

Премиум застраховка. Въведете цената на полицата. В полето вдясно посочете валутата от списъка, като кликнете върху бутона. Данните за списъка са взети от директория "Валути".

4. Попълнете полетата:

Сума за плащане. В това поле въведете сумата за плащане от разписката. Ако сумата на плащането не е равна на размера на застрахователната премия, тогава следващи плащания от притежателя на полицата трябва да бъдат посочени в таблицата „График на плащане“ в раздела „График на плащане“ (вижте по-долу). Стойност на намалението. Ако застрахователният брокер е направил отстъпка на притежателя на полицата въз основа на собствената си комисионна, трябва да я посочите в това поле. Вид плащане. Как притежателят на полицата е платил за полицата, се посочва чрез избиране на съответната стойност в това поле.

Ориз. 3.25.

Парични средства - парите се превеждат по разписка.

Безкасово - парите се превеждат по разплащателна сметка на застрахователния брокер. Директно - парите се превеждат по банковата сметка на застрахователната компания. Смесен - сумата е разделена на няколко плащания, платени по различни начини.

комисия. Тук посочете собствената си комисионна и нейното движение. При необходимост комисионната може да бъде разделена на две части, основна и за допълнителни услуги.

Движението на комисионната показва как тя отива при брокера:

Запазване означава, че брокерът превежда пари на застрахователната компания минус собствената си комисионна.

Превод - брокерът превежда получената сума за полицата в пълен размер, а застрахователната компания трябва да върне комисионната в бъдеще.

Получаване означава, че притежателят на полицата е платил полицата директно от застрахователната компания и тя трябва да върне комисионната в бъдеще.

Има три начина за попълване на комисионната:

Въведете сумата на комисионната в първото поле и посочете нейното движение.

Във второто поле въведете процента на комисионната, който се изчислява от сумата на плащането и посочете движението.

Настройте автоматично изчислениекомисионна в директория "Проценти на комисионата" на меню "Финанси" и след това комисионната ще бъде изчислена автоматично в зависимост от конфигурираните условия. Комисионна за доп услуги. Ако комисионната на брокера трябва да бъде разделена на две части (официална и неофициална), тогава втората част трябва да бъде посочена в това поле. агент. Ако агент е участвал в сключването на застрахователния договор, той се посочва в това поле, а неговата комисионна е в полето „Комисионна на агента“, която, както и собствената комисиона на брокера, може да се изчисли автоматично, ако това е посочено в „Комисионна на агентите“. "комисионна процент" директория в "меню" Финанси".

• 5. Попълнете формулярите, използвани при кандидатстване за полицата.
• 6. В раздела за кредитиране въведете подробностите за договора за заем.
• 7. Информация, за която не е предвидено отделно поле, може да бъде посочена в раздела „Допълнителни подробности“.
• 8. Ако полицата се плаща от притежателя на полицата на вноски, тогава в раздела „График на плащане“ е необходимо да посочите кога и колко пари трябва да донесе.
• 9. В раздела “Допълнителни” можете да посочите застрахователната сума по полицата.
• 10. Ако е необходимо застрахователната полица да се свърже с реална счетоводни документи(PKO, RKO, PP входящи/изходящи), това може да стане в раздела „Платежни документи“
• 11. За да прикачите външни файлове (сканирани документи, снимки и др.) към застрахователния документ, натиснете бутона "Файлове".
• 12. Щракнете върху бутона "OK", документът ще бъде записан и публикуван.

ь Създаване на отчет за застрахователна компания.

За генериране на отчет към застрахователна компания за продадени полици в програмата Insurance Broker 8.3 се използва документът „Отчет за застрахователна компания”.

Създаване на нов документ:

• 1. Изберете елемент от менюто "Застраховка", "Отчет за застрахователната компания". Ще се отвори дневникът на отчетния документ.
• 2. Щракнете върху Действия, Добавяне или бутон. Ще се отвори нов формуляр за документ.

Ориз. 3.26.

3. Попълнете задължителните полета:

Организация. Изберете името на вашата организация, като щракнете върху бутона.

Данните за списъка за избор се вземат от справочник "Организации".

Застрахователно дружество. Изберете името на застрахователната компания, като щракнете върху бутона.

Списъчните данни за избор се вземат от справочник "Контрагенти". Ако фирмата, от която се нуждаете, не е в списъка, трябва да проверите:

фирмата е в директория "Контрагенти" и се намира в папка "Застрахователни компании" (името на папката е изписано в константите на програмата).

4. Следните полета не са задължителни, но се препоръчват:

споразумение. Тук можете да видите договора от директорията „Споразумения за контрагенти“, по който организацията работи със застрахователната компания. Данните за договора (номер в заглавието, дата на сключване и др.) могат да се използват при отпечатване на справка.

Вид застраховка. Изберете името на вида застраховка (застрахователен продукт) от списъка с натискане на бутона.

Списъчните данни за избор са взети от справочник „Видове застраховки”. Ако желаният вид не е в списъка, трябва да проверите:

Видът на застраховката е в директория "Видове застраховки" в меню "Указатели".

видът застраховка изобщо не е свързан със застрахователни компании или избраната застрахователна компания е в обвързващия списък, отбелязва се и в директорията „Видове застраховки“.

Номер на доклада. Ако посочите номер тук, следващите документи ще бъдат номерирани автоматично от него.

Отчетен период. Периодът, за който брокерът отчита.

5. Попълнете таблицата "Застрахователни полици". Тук трябва да посочите документите „Застрахователна полица” и „Плащане”, за които се отчита брокерът. Можете да попълните таблицата, като добавите нов ред чрез бутона или в автоматичен режим:

Кликнете върху бутона "Попълване". Ще се отвори формата за попълване на отчета:

Попълнете периода, за който трябва да се обработват документите.

Поставете отметка в полето „Избор на документи по дата на подаване“, ако е необходимо документите да бъдат избрани по атрибут „Дата“, в противен случай ще се използват реквизитите „Дата на приключване“ и „Дата на плащане“.

Ако трябва да обработвате документи само за определен вид застраховка, посочете го в полето „Вид застраховка“.

Ако трябва да обработвате документи само с определен вид плащане (в брой, безкасово, директно), посочете го в полето "Вид плащане".

Ако е необходимо, че в таблицата с документи срещу всеки документ реалното счетоводство платежен документ(това може да е необходимо за отпечатване на отчет към някои застрахователни компании), посочете го в полето "Документ за плащане".

Можете също така да избирате документи по Агент и Отговорник (който е въвел документа в програмата)

Квадратчето „Задаване на знак“ поставя знак до всеки документ. В бъдеще операторът, който ще проверява с автоматично попълнената таблица голям брой политики, подготвени за изпращане, може да премахне маркировката, като по този начин провери данните в програмата.

Кликнете върху "Попълване".

Документът ще бъде попълнен с полици и плащания, които са продадени, но все още не са включени в отчетите; втори път (в друг документ „Отчет за застрахователна компания“), полиците и плащанията няма да бъдат включени в таблицата, когато автоматично се попълва.

Ние ще ви помогнем да намерите тесните места в бизнеси от всякакъв размер. Ние ще посъветваме. Автоматизиране или предварително автоматизиране. Ние ще ви обучим.

Нека получим резултата:

• Растеж на приходите
• Намаляване на разходите
• Повишена контролируемост и прозрачност

Ще се изненадате от бързите резултати!Според статистиката истинската автоматизация се изплаща през първите 3 месеца от пускането в предприятието.

Специалистите на нашата компания са обучени и сертифицирани по технологията на работа, разработена от 1C, и ще помогнат, използвайки предимствата на платформата 1C:Enterprise, да повишат ефективността на бизнес процесите на компанията, които не са свързани с поддържането на съответствие със законодателството и отчитането.

Какво е реална автоматизация?

Често за ефективно управлениебизнесът изисква автоматизация на „тесните“, индивидуални фирмени процеси. Например, трябва да настроите специално счетоводство на складови единици или да вземете предвид нестандартните размери на стоките, или е важно собственикът да получава анализи за компанията в определен контекст; може да има много примери.

Автоматизирането на основните процеси на компанията помага за намаляване на броя на рутинните операции, повишава прозрачността и ефективността. Използвайки 1C решения, персонализирани за задачите на вашия бизнес, вие ще можете ясно да структурирате работата на компанията и да анализирате нейното представяне според важни за вас показатели, вземайки информирани решения.

Специалистите от Real Automation Centers са наричани на шега „истински глигани” заради способността им да решават най-сложните проблеми, поради което дивата свиня се е превърнала в символ на Real Automation Centers.

Ако сте мислили за необходимостта от автоматизация, но не знаете откъде да започнете, или ни се обадете

защо ти трябва това

Нашият екип може:
. определяне на кои процеси автоматизацията ще помогне
. изберете решения и ги персонализирайте, за да отговарят на спецификата на вашата компания
. научите как да работите ефективно в системата 1C:Enterprise

Това ще помогне за намаляване на разходите за ръчни операции, оптимизиране на бизнес процесите и увеличаване на рентабилността на компанията.

Увеличете ефективността на бизнеса с нас! Станете лидер във вашата индустрия с 1C решения!

Автоматизация на застраховането

Застрахователният отдел на консултантската група BUSINESS RELATIONSHIP GROUP е създаден през 2004 г. от професионален екип от програмисти и ИТ консултанти. Към днешна дата нашите специалисти са внедрили Повече ▼ 200 успешни проектаавтоматизация на застрахователни, търговски и производствени фирми.

Ние сме специализирани в внедряването, адаптирането, разработването и поддръжката на ИТ системи на платформата 1C:Enterprise 8 и заемаме първо място в Insurance Automation сред водещите партньори на компанията 1C в областта на застрахователната автоматизация. Нашите ИТ решения работят в застрахователни компании OSJSC "Русия", "БИН Застраховка", "СК Москва"и много други.

Избират ни, защото:

• имаме опит в успешни внедрявания и изпълнение на големи проекти
• Специалистите на отдела са добре координиран и балансиран екип; професионалисти, познаващи спецификата на застрахователния бизнес
• Ние работим изключително в рамките на фиксиран бюджет и стриктно спазваме срокове
• Ние гарантираме внимателно и компетентно управление на проекти

Качеството на работата на специалистите от отдела се потвърждава от международния сертификат ISO 9001:2000, както и различни сертификати 1C. Нашият коз е опитът и професионализмът.

Изпратете добрата си работа в базата знания е лесно. Използвайте формата по-долу

Студенти, докторанти, млади учени, които използват базата от знания в обучението и работата си, ще ви бъдат много благодарни.

Публикувано на http://www.allbest.ru/

• Съдържание
• Формулиране на проблема
• Въведение
• 1. Проектиране на системата
• 1.1 Застраховането, неговото място в социално-икономическата политика на държавата
• 1.2 Застрахователен договор
• 1.3 Характеристики на конструиране на застрахователни тарифи
• 2. Функционален дизайн
• 2.1 Обосновка за избора на методи и средства за разработка
• 2.2 Разработване на приложения
• 2.2.1 Разработване на UML диаграми
• 2.2.2 Изграждане на диаграма на използване
• 2.2.3 Изграждане на диаграма на последователност
• 2.2.4 Проектиране на класова диаграма
• 2.3 Разработване и изграждане на функционален модел
• 2.4 Разработване на информационен модел
• 2.5. Упътване за употреба
• Заключение
• Списък на използваните източници
• Приложение 1. Списък с програмни кодове

Формулиране на проблема

Курсовата работа е система за автоматизиране на работата на застрахователна компания. Основните характеристики, необходими на потребителите за използване на системата, са потребителско име и парола. Потребителите са разделени на три групи в зависимост от нивото на достъп до различни операции:

· администратор – има достъп до всички възможни операции;

· агент – има достъп до всички операции, свързани с работа с документи (клиенти, застрахователни полици);

· потребител - има ограничен достъп до данни (само търсене и четене на документи).

Има следния набор от документи и действия по тях.

Документация:

· информация за клиента;

· застрахователна полица на клиента;

· информация за регистрирания потребител.

Действия:

· създаване, редактиране, изтриване на документи;

· търсене на документи;

· преглед на списъка с документи;

· възстановяване на изтрити документи;

· импорт на статистически данни;

· изчисляване на различни показатели за ефективност на застрахователните компании въз основа на налични документи и статистически данни.

Всички данни се съхраняват на сървъра в база данни. Информацията може да бъде достъпна от няколко потребители едновременно. Тъй като приложението е предназначено за използване в Интернет, то е клиент-сървър приложение, обменът на данни се осъществява чрез HTTP протокола. Клиентската част е HTML страница, съдържаща информация. Сървърната част на проекта е приложение, реализирано с помощта на сървлети, които обработват данни, идващи от страницата, и генерират отговор. Функционалността за изчисляване на параметрите е реализирана под формата на отделни компоненти, които са продукт на трета страна и могат да бъдат добавени към програмата като разширение с помощта на конфигурационен файл.

Въведение

IN модерен святИнтернет се превърна в неразделна част от живота на много хора. Бизнес мениджъри, служители на компании, служители, студенти, ученици прекарват значителна част от работното и свободното си време в Интернет. Интернет дава възможност за производство парични транзакции, пазаруване, чат с приятели, запознаване. Интернет също е източник на изчерпателна информация, където можете да намерите отговор на почти всеки въпрос.

В наши дни Интернет е достъпен за почти всеки и навсякъде. Поради това системите, които са интернет приложения, които позволяват достъп до данни, когато е необходимо, са широко разпространени.

С навлизането на новите технологии и в частност езика за програмиране JAVA, ориентиран към Интернет, реализирането на тези нужди става по-лесно и се появяват нови възможности и пространство за реализиране на всички идеи.

Това курсова работае система за автоматизиране на работата на застрахователна компания. С помощта на тази система работата на застрахователната компания става по-лесна, улеснява работата на застрахователните агенти, тъй като вече няма нужда да се свързвате с агенцията, за да получите застраховка, сега агентът може да дойде на всяко място, удобно за вие и сключете споразумение. Системата също така ви позволява да поддържате статистика и да анализирате дейностите на застрахователната компания, което прави работата на застрахователната компания по-продуктивна, тъй като показателите за изпълнение на компанията са ясно видими, въз основа на които може да се коригира по-нататъшната работа, за да увеличаване на печалбите и своевременно коригиране на допуснати грешки.

1. Впроектиране на системата

1.1 Застраховането, мястото му в социално-икономическата политика на държавата

Застраховката е договор, в който една страна (наречена застраховател), в замяна на възнаграждение (наречена премия), се задължава да плати на друга страна (наречена застрахован) определена сума пари или нейния еквивалент в натура след настъпването на определено събитие, засягащо интереса на застрахования. Икономическа същностзастраховката се състои в образуването от специализирани организации - застрахователни компании - на застрахователен фонд, образуван от вноските на притежателите на полици (премия), от който се компенсират загубите, понесени от притежателите на полици в резултат на застрахователни събития, покрити от застраховката. Застраховката се дели на имуществена, лична и гражданска отговорност и може да бъде в задължителна форма, възникваща по силата на закона, или в доброволна форма, въплътена в застрахователен договор между застрахователя и застрахователя.

1 .2 Застрахователен договор

Застрахователният договор е двустранна сделка, в която една от страните е гражданин (притежател на полицата), а другата е застрахователна организация, която има право да сключва такива сделки. Застрахователният договор се сключва в обикновена писмена форма, независимо от размера на застрахователната сума нотариална заверкане е задължително.

При договор за лична застраховка едната страна (застрахователят) се задължава да заплати определена в договора такса ( премиум застраховка), платени от другата страна (притежателя на полицата), да плащат наведнъж или да плащат периодично сумата, предвидена в договора (застрахователна сума) в случай на увреждане на живота или здравето на самия притежател на полицата или на друг гражданин ( застраховано лице), посочено в договора, достигане на определена възраст или смърт в живота му друго събитие (застрахователно събитие), предвидено в договора.

Правото да получи застрахователната сума има лицето, в чиято полза е сключен договорът.

Договорът за лична застраховка се счита за сключен в полза на застрахованото лице, ако друго лице не е посочено в договора като ползващо се лице. В случай на смърт на лице, застраховано по договор, в който не е посочено друго бенефициент, наследниците на застрахованото лице се признават за бенефициенти.

Личен застрахователен договор в полза на лице, което не е застраховано лице, включително в полза на притежател на полица, който не е застраховано лице, може да се сключи само с писменото съгласие на застрахованото лице. При липса на такова съгласие договорът може да бъде обявен за недействителен по иск на застрахованото лице, а в случай на смърт на това лице - по иск на неговите наследници.

Сключват се смесени застраховки "Живот" с лица на възраст от 16 до 65 години, детски застраховки - без ограничение във възрастта, брачни застраховки - от 20 до 67 години. Възрастта на притежателя на полицата в заявлението за застраховка се посочва в пълни години, не се изисква документално доказателство за възраст от притежателя на полицата.

Възрастта на лицето, в чиято полза е сключена смесената застраховка "Живот", няма значение. Друго нещо е възрастта на трети лица, т.е. деца, в чиято полза се сключват договори за застраховка за деца и застраховка за брак. Трябва да бъде записано в заявлението за осигуряване.

Родителите (осиновителите), роднините на детето и неговите настойници имат право да сключат застрахователен договор за сватбата, ако възрастта на детето е не по-малко от 2 и не повече от 15 години. Договорите за застраховка на дете се сключват при условие, че детето е навършило 15 години.

Застрахователна декларация - Важно легален документ, който по правило се попълва от застрахователния агент (инспектор), но според думите на застрахователя. Заявление за застраховка не може да бъде прието, ако не е подписано от лицето, от чието име се подава, тъй като в този случай застрахователният договор е недействителен.

Застрахователната организация не проверява повторно информацията, предоставена от притежателя на полицата в заявлението за възраст, здравословно състояние, липса на група инвалидност и др., Но има право в определени случаи да проверява информацията, предоставена от притежателя на полицата.

Заявлението за застраховка трябва да посочи месеца, в който притежателят на полицата се е съгласил да плати първата застрахователна премия, както и формата на плащане в бъдеще (съгласно безналични плащанияили пари в брой). Смесени застраховки "Живот" не се сключват с хора с увреждания от I и II група и с лица, страдащи от заболявания като: всички видове сърдечни пороци, хипертония, ангина пекторис, инфаркт на миокарда, язва на стомаха и дванадесетопръстника, туберкулоза, злокачествени тумори и др. и др. Тези заболявания са включени в противопоказанията, тъй като могат да доведат до преждевременна смърт на застрахования.

Личният застрахователен договор по своята правна същност е договор в полза на трето лице. Следователно на притежателя на полицата е дадено неоспоримото право да посочи в заявлението за смесена застраховка „Живот“ всяко лице (или няколко лица), което посочи да получи застрахователната сума в случай на смърт. Въпреки това, като трета страна може да бъде само лица(граждани).

За всеки вид застраховка се установяват различни осигурителни периоди, т.е. периоди, през които застрахователната организация изпълнява задълженията си. Смесените застраховки "Живот" се сключват за точно определен срок - 5, 10, 15 или 20 години. По застраховки за деца, както и по застраховки за брак, няма предварително определени осигурителни периоди. При застрахователните договори за деца обаче максималният осигурителен период не може да надвишава 18 години.

При смесен договор за животозастраховане размерът на премиите се определя в зависимост от застрахователния период, застрахователната сума и възрастта на притежателя на полицата, а при договорите за застраховка на деца размерът на премиите зависи от възрастта на детето, застрахователната сума , осигурителния период и продължителността на плащане на премиите.

Условията на всички видове застраховки "Живот" предвиждат месечно плащане на вноски, а при договори за застраховка за деца и смесена застраховка "Живот" те могат да се плащат наведнъж. По правило месечните премии трябва да се плащат през целия застрахователен период, но при застрахователни договори за деца те могат да се плащат и за съкратен период, който зависи от възрастта на детето.

Внасянето на вноски в съкратен срок не дава право на получаване на застрахователната сума по-рано от изтичането на периода, за който е сключен осигурителният договор. Притежателят на полицата се освобождава само от необходимостта да плаща премии през годините, оставащи до края на застрахователния период, и гарантира на детето да получи застрахователната сума дори в случай на смърт.

За начало на застрахователния период се счита 1-ви ден от месеца, в който притежателят на полицата се е съгласил да плати първата (или еднократна) премия, а за край - последният ден от предходния месец след толкова години, колкото е е сключена застрахователна полица. това споразумениезастраховка.

Началото на осигурителния период следва да се разграничава от влизането в сила на застрахователния договор. Попълването на заявление за застраховане и издаването на застрахователен сертификат означава само факта на сключване на застрахователен договор; за да може такъв застрахователен договор да поражда задължения на застрахователната организация, свързани с плащането на застрахователната сума, е необходимо тя да влизат в сила.

При договорите за смесена застраховка живот и застраховка на деца, притежателите на полици имат право да намалят размера на застрахователната сума по всяко време и във връзка с това да плащат по-малки премии. За целта притежателят на полицата трябва да подаде съответно заявление, придружено от застрахователен сертификат.

При намаляване на застрахователната сума, част от предварително платените премии (резерв) се оказват безплатни, тъй като при изтичане на застрахователния период застрахователната компания ще трябва да плати по-малка сума от предвидената при сключване на договора. Тази част от премиите не се връща на притежателя на полицата, а се зачита към плащането на бъдещи премии. В случай, че свободният резерв от вноски е достатъчен за изплащане на застрахователния договор до края на срока и дори има излишък, то последният се връща на застрахователя, а договорът продължава да важи в намалена застрахователна сума до изтичане на посочения в него срок, но без да плаща вноски. Намаляване на застрахователната сума може да се направи не само от месеца, през който е подадено заявлението, но и от всеки друг месец по желание на застрахователя.

Смесените животозастрахователни договори могат да бъдат прекратени предсрочно в определени случаи. Застрахователният договор, въпреки че е доброволно споразумение между две страни - притежателя на полицата и застрахователната организация, може да бъде прекратен предсрочно само по инициатива на едната страна - притежателя на полицата. Застрахователната компания няма такова право.

1.3 Характеристики на конструиране на застрахователни тарифи

Конструкцията на тарифите за животозастраховане има следните характеристики:

1. Изчисленията се правят с помощта на демографска статистикаи теория на вероятностите.

2. При извършване на изчисления се използват методи за дългосрочни финансови изчисления.

3. Нетните тарифни ставки се състоят от няколко части, всяка от които е предназначена да формира застрахователен фонд за един от видовете застрахователна отговорност, включени в застрахователните условия.

Комбинацията от математически методи, използвани в статистиката, теорията на вероятностите и дългосрочните финансови изчисления, породи специален клон на науката - теорията на актюерските изчисления, въз основа на които се установяват тарифните ставки и резервът от премии за животозастраховане. Актюерските изчисления са система от математически и статистически методи, които се използват за определяне на финансовите взаимоотношения между застрахователя и притежателя на полица за дългосрочно животозастраховане.

Тарифната ставка определя колко пари всеки притежател на полица трябва да внесе в общия осигурителен фонд за единица застрахователна сума. Следователно тарифите трябва да бъдат изчислени така, че размерът на събраните вноски да е достатъчен за плащане на плащанията, предвидени в условията на застраховката. По този начин тарифната ставка е цената на услугата, предоставена от застрахователя на населението, т.е. уникална цена за застрахователна защита. Какво определя неговия размер и как да определите цената за този или онзи вид застраховка живот?

Пълната тарифна ставка се нарича брутна ставка. Състои се от нетна ставка и натоварване. Целта на нетната ставка е да осигури изплащането на застрахователните суми, т.е. производителност финансови задължениязастраховател по застрахователни договори. Натоварването е предназначено да компенсира разходите за извършване на застрахователни операции.

Уникалността на животозастрахователните операции се проявява при конструирането на нетен процент. Условията на животозастраховането обикновено предвиждат плащания във връзка с преживяването на застрахования до края на застрахователния договор или в случай на неговата смърт през този период. Освен това се предоставят плащания във връзка със загуба на здраве поради нараняване и определени заболявания.

По този начин, за да се изчисли обемът на осигурителния фонд, е необходима информация колко от осигурените лица ще оцелеят до изтичането на осигурителните им договори и колко от тях могат да умрат всяка година, колко от тях и до каква степен ще има загуба на здраве. Броят на плащанията, умножен по съответните застрахователни суми, ще определи размера на предстоящите плащания, т.е. ще може да се разбере колко ще трябва да се натрупа застрахователният фонд.

Продължителността на живота на отделните хора варира значително. Той принадлежи към категорията на случайните променливи, числената стойност на които зависи от много фактори, толкова далечни и сложни, че изглежда невъзможно да бъдат идентифицирани и изследвани. Теорията на вероятностите и статистиката изучават случайни явления от масивен характер, включително смъртността на населението. Реши това демографски процессмяната на поколенията, изразяваща се в промени в нивото на възрастово-специфичната смъртност, е подчинена на закона на големите числа, станала е еднаква в своите прояви и толкова надеждна в своите резултати, че може да служи като основа за финансови изчисления в застраховането.

Демографската статистика е идентифицирала и изразила с помощта на математически формули зависимостта на смъртността от възрастта на хората. Разработена е специална методика за съставяне на така наречените таблици на смъртността, където конкретни цифри показват последователното изменение на смъртността след възрастта. Тези таблици застрахователни организацииизползвани за изчисляване на тарифите.

В допълнение към моделите, свързани с процеса на оцеляване и смъртност, при конструирането на тарифите се взема предвид дългосрочният характер на животозастрахователните операции, тъй като тези договори се сключват за дълги периоди: 3 или повече години. През целия период на тяхната валидност (или в самото начало на осигурителния период в случай на еднократно плащане) осигурителните органи получават вноски. Плащанията на застрахователните суми се извършват по време на застрахователния период или след определен период от началото на договора, ако застрахованото лице почине или загуби здравето си.

Временно наличните средства, натрупани от застрахователната организация, се използват като кредитни ресурси. За ползването им има такса лихва по заема. Но ако по време на спестовна транзакция доходът от лихви се добави към депозита, тогава при застраховането дължимите премии на застрахования се намаляват (сконтират) предварително с размера на този доход. За да се намалят предварително тарифните ставки за доходите, които ще се натрупват в продължение на няколко години, се използват методи на теорията за дългосрочните финансови изчисления.

Тарифите в животозастраховането се състоят от няколко части. Да вземем за пример смесено животозастраховане. Която комбинира няколко вида застраховки, които могат да бъдат независими: 1) застраховка за оцеляване; 2) застраховка в случай на смърт; 3) застраховка срещу злополука. За всеки от тях с помощта на тарифа се създава застрахователен фонд, поради което тарифната ставка при смесената застраховка се състои от три части, включени в нетната ставка, и четвъртата част - натоварването. Подобна е структурата на тарифните ставки при останалите видове животозастраховане.

2. Ффункционален дизайн

2. 1 Обосновка за избора на методи и средства за разработка

За решаване на проблема е избран езикът за програмиране JAVA. Изборът на този език за програмиране се определя от следните причини:

- Този език за програмиране е междуплатформен, така че използването на софтуерен продукт, написан на този език, е възможно на всяка платформа и за всяка операционна система;

- Има редица стандартни библиотеки, които включват набор от класове, предназначени да улеснят разработването на приложения. Те включват редица често срещани класове, като клас, който реализира работа с динамичен масив, хеш таблица, низове и т.н.;

- Програмният език JAVA е специално създаден за внедряване на Интернет приложения. Има и много различни технологии, които могат да направят разработването на проекти лесно и приятно.

Курсовият проект е интернет приложение, така че за написването му е използвана технология като JSP (Java Server Pages). Тази технология опростява писането на сървърни приложения, тъй като ви позволява да комбинирате HTML тагове и програмен код, написан на езика за програмиране JAVA. Също така е възможно да разширите набора от стандартни компоненти, като внедрите свои собствени.

Курсовият проект е написан с помощта на модела MVC (Model-View-Control). Тази технология ви позволява да създавате разширяеми програми, които са лесни за поддръжка. Този подход ви позволява да комбинирате сървлети, JSP и beans, с които можете да разделите бизнес обекти и презентационния слой (JSP документи), което е много важно за големи и сложни проекти, където бизнес логиката непрекъснато се променя.

Моделът MVC е изграден върху концепцията Model 2. Според тази концепция всички заявки се обработват от един сървлет (т.нар. servlet controller). Описанието на събития (действия) се извършва с помощта на конфигурационен файл, който съдържа името на събитието и класа на манипулатора за това събитие. Контролерът при получаване на събитие проверява наличието му в контейнера за събития. Ако има събитие, тогава контейнерът създава съответния манипулатор на събитие и извиква своя метод за обработка на това събитие.

Средата за разработка IntelliJ IDEA беше използвана като инструмент за разработка на приложения. The софтуерима набор от функции, предназначени да улеснят процеса на разработка: има доста голям брой клавишни комбинации; В допълнение към съществуващите вградени възможности на тази среда за разработка, има цял набор от помощни програми (плъгини), предназначени да разширят вече съществуващите възможности на средата.

2.2 Разработка на приложения

2.2.1 Разработване на диаграмаUML

UML (Unified Modeling Language) – унифициран език за моделиране – стандартна нотация за визуално моделиране на софтуер.

Визуалното моделиране в UML може да бъде представено като определен процес на спускане ниво по ниво от най-общия и абстрактен концептуален модел на изходната система към логическия и след това към физическия модел на съответната софтуерна система.

При визуално моделиране в UML се използват седем вида диаграми, всяка от които може да съдържа елементи от определен тип. Типовете разрешени елементи и връзките между тях зависят от вида на диаграмата. Нека да разгледаме диаграмите, използвани за моделиране на този курсов проект.

2.2.2 Изграждане на диаграма на използване

Диаграмата на случая на използване е диаграма, която описва функционалността на информационна система, която ще бъде видима за потребителите на системата.

Диаграмата на случая на използване е първоначалното концептуално представяне или концептуален модел на система по време на нейния процес на проектиране и разработка.

Диаграмата на UseCase се използва за:

1. определяне на общите граници и контекста на моделираната предметна област в началните етапи на проектиране на системата;

2. формулиране на общи изисквания към функционалното поведение на проектираната система;

3. разработване на първоначален концептуален модел на системата за последващото му детайлизиране под формата на логически и физически модели;

4. изготвяне на първоначална документация за взаимодействие на разработчиците на системата с нейните клиенти и потребители.

Проектираната система е представена като набор от обекти или участници, които взаимодействат със системата, използвайки случаи на употреба.

Случаите на използване (прецедентите) и актьорите (акторите) определят обхвата на приложение на създадената система (проект). В този случай случаите на използване описват всичко, което се случва вътре в системата, а актьорите описват всичко, което се случва извън нея.

Актьор може да бъде човек, техническо устройство, програма или всяка друга система, която може да служи като източник на влияние върху моделираната система, както е определено от самия разработчик.

Можете също така да забележите, че случаят на използване служи за описание на услугите, които системата предоставя на актьора. С други думи, всеки случай на използване определя определен набор от действия, извършвани от системата по време на диалог с актьора.

Ориз. 2.2.2.1 Диаграма на случаите на използване

При стартиране на приложението, потребителят получава възможност да се авторизира за влизане в системата. След влизане в системата се определя ролята на потребителя, въз основа на която за него става възможен определен набор от действия. След приключване на работата с приложението, потребителят може да напусне приложението, като се върне на страницата за оторизация, за да позволи на други потребители да работят.

2 . 2 . 3 Изграждане на диаграма на последователност

Една от характерните особености на различни по характер и предназначение системи е взаимодействието между отделните елементи, от които се образуват тези системи. Въпросът е, че различните съставни елементи на системите не съществуват изолирано, а имат определено влияние един върху друг, което отличава системата като интегрална формация от проста съвкупност от елементи.

В езика UML взаимодействието на елементите се разглежда в информационния аспект на тяхната комуникация, т.е. взаимодействащите обекти обменят някаква информация помежду си. В този случай информацията е под формата на попълнени съобщения. С други думи, въпреки че съобщението има информационно съдържание, то придобива допълнителното свойство да упражнява насочено въздействие върху своя получател.

Диаграмата на последователността изобразява само тези обекти, които са пряко включени във взаимодействието и не показва възможни статични асоциации с други обекти. За диаграма на последователност ключова точкае именно динамиката на взаимодействието на обектите във времето. В този случай диаграмата на последователността има две измерения. Едната - отляво надясно под формата на вертикални линии, всяка от които изобразява линия на живота самостоятелен обектучастващи във взаимодействието. Графично всеки обект е изобразен като правоъгълник и е разположен в горната част на жизнената си линия. Вътре в правоъгълника са името на обекта и името на класа, разделени с двоеточие. В този случай целият запис е подчертан, което е знак за обект, за който е известно, че е екземпляр на клас.

Ориз. 2.2.3.1 Диаграма на последователността (упълномощаване на потребителя).

Като пример на фиг. 2.2.3.1 предоставя диаграма, описваща жизнения цикъл и взаимодействието на приложните слоеве по време на оторизацията на потребителя.

При въвеждане на данни за оторизация потребителят изпраща заявка до приложението. Заявката отива към контролера на действие (Controller), който контролира работата на манипулаторите на събития. След това контролерът пренасочва заявката към нивото на бизнес логиката (модел). Което извършва необходимите действия за изпълнение на заявката (създаване на връзка към базата данни, генериране на заявка, изпълнението й, получаване на резултат, анализиране на получените данни, генериране на резултат въз основа на получените данни). След това резултатът се връща обратно към контролера, който в зависимост от получения резултат пренасочва отговора към нивото на представяне (View), което директно показва необходимата информация на потребителя.

2 . 2 . 4 Проектиране на класова диаграма

Диаграмата на класа е основната диаграма за създаване на код на приложение. Използване на класова диаграма за създаване вътрешна структурасистема, наследяване и относителната позиция на класовете един спрямо друг са описани. Това описва логическото представяне на системата. Тази диаграма не предоставя информация относно времевите аспекти на работата на системата. Класовата диаграма е граф, чиито върхове са елементи, които са свързани различни видовеструктурни отношения. Трябва да се отбележи, че една класова диаграма може също да съдържа интерфейси, пакети, релации и дори отделни екземпляри като обекти и релации.

Класовете в един проект могат да бъдат разделени на няколко части според тяхната функционална натовареност:

· класове, които реализират DAL (слой за достъп до данни);

· класове, които имплементират ниво “Контролер” за управление на работата на приложението;

· класове, които реализират обработка на заявки (обработващи действия);

· класове, предназначени за съхраняване и предаване на данни между ниво клиент, сървър и приложение (beans);

· помощни класове (помощници).

Ориз. 2.2.4.1 Класове, които реализират слоя за достъп до данни (DAL)

· IDataDAO е интерфейс, който всички класове, които описват конкретна DAO реализация на ниво документ, трябва да внедряват.

· PersonDataDAOImpl - внедряване на DAO на ниво документ „Контакт“.

· PolicyDataDAOImpl - внедряване на DAO на ниво документ „Политика“.

· UserDataDAOImpl - внедряване на DAO на ниво документ „Потребител“.

· SearchDataDAOImpl - внедряване на ниво DAO на логика за търсене на документи.

· ListDataDAOImpl - реализация на логиката на ниво DAO за генериране на страници за показване на списък с документи.

· ImportDataDAOImpl - внедряване на DAO ниво на логика, която импортира статистически данни, които се използват за изчисляване на параметри, характеризиращи работата на застрахователна компания.

· DataDAOHelper – клас, който включва общата логика на ниво DAO (отваряне на транзакция, създаване на екземпляр на имплементация на ниво DAO за конкретен документ, описан в конфигурацията).

· UserDataDAOHelper - клас, който разширява общата логика на ниво DAO и включва специфична логика за работа с документа „Потребител“.

· SearchDataDAOHelper – клас, който разширява общата логика на нивото на DAO и включва спецификата на нивото на DAO при извършване на търсене.

Ориз. 2.2.4.2 Контролен слой

· ActionHelper - проектиран помощен клас

· за работа с входно/изходни данни.

· ServletController е основният клас на това ниво,

· контролира изпълнението на действия в зависимост от данните, получени от потребителя.

· ActionHandlerFactory - клас - предназначена фабрика

· за създаване на екземпляри на манипулатори на събития, които са описани в конфигурационния файл.

Ориз. 2.2.4.3 Класове, които изпълняват обработка на заявки

· IActionHandler е интерфейс, който всички манипулатори на събития трябва да внедряват.

· LoginActionHandler - клас - манипулатор на събития, идващи от страницата за авторизация.

· HomeActionHandler - клас - манипулатор на събития, идващи от началната страница на приложението.

· AdminActionHandler - клас - манипулатор на събития, идващи от страницата за администриране.

· ImportActionHandler - клас - манипулатор на събития, идващи от страницата за импортиране на статистически данни.

· PersonActionHandler - манипулатор на събития при работа с документа “Контакт”.

· PolicyActionHandler - манипулатор на събития при работа с документа “Политика”.

· UserActionHandler - манипулатор на събития при работа с документа “Потребител”.

· AbstractSearchActionHandler – клас, съдържащ общата логика за обработка на събития при извършване на търсене.

· PersonSearchActionHandler - клас - манипулатор на събития, възникващи при търсене на документи от типа “Контакт”.

· PolicySearchActionHandler - клас - манипулатор на събития, възникващи при търсене на документи от тип “Политика”.

· UserSearchActionHandler - манипулатор на събития, който възниква при търсене на документи от типа „Потребител“.

Ориз. 2.2.4.3 Класове, предназначени за съхраняване/предаване на данни (Beans)

· IEntity е интерфейс, съдържащ методи, които трябва да бъдат внедрени в контейнерни класове.

· PersonBean е клас, който съхранява данни за документи от типа „Контакт“.

· PolicyBean е клас, който съхранява документни данни от типа „Политика“.

· UserBean е клас, който съхранява данни за документи от типа „Потребител“.

2 . 3 Разработване и изграждане на функционален модел

диаграма на дизайна на застраховката uml

Специализиран инструмент за създаване и разработване на функционални модели на системи е пакетът BPwin.

Моделът в BPwin е колекция от SADT диаграми, всяка от които описва отделен процес, като го разделя на стъпки и подпроцеси. С помощта на свързващи дъги се описват обекти, данни и ресурси, необходими за изпълнение на функция.

Въз основа на заданието на този курсов проект целта на системното моделиране е да опише функционалността на разработваната система за по-нататъшното използване на създадения модел при разработването на информационен модел.

Диаграмите са основните компоненти на модела, всички функции и интерфейси са представени на тях като блокове и дъги. Диаграмите се изграждат с помощта на блокове. Всеки блок описва завършено действие. Четирите страни на блока имат различни цели:

– вляво се показват входните данни и началните ресурси за функцията, описана от блока;

– вдясно са описани изходните ресурси - това са резултантните ресурси, получени в резултат на изпълнение на функцията, описана от блока;

– отгоре – контролът е това, което влияе върху процеса на изпълнение на функцията, описана от блока, и ви позволява да повлияете на резултата от действието (правила, стратегии, процедури или стандарти, които ръководят работата);

- отдолу - механизмът е този, по който се осъществява това действие.

IDEF3 е стандарт за документиране на технологични процеси, протичащи в предприятието, и предоставя инструменти за визуално изучаване и моделиране на техните сценарии.

В стандарта IDEF3 има два типа диаграми, които представляват описание на един и същ сценарий на процес от различни гледни точки:

1) Диаграми за описание на потока на процеса (PFDD);

2) диаграми на състоянието на обекта и неговите трансформации в процеса (Object State Transition Network, OSTN).

При моделирането на курсовия проект е използвана само PFDD диаграмата.

Правоъгълниците в PFDD диаграмата се наричат ​​единици за поведение (UOB) и представляват събитие, етап на процес или решение. Стрелките или линиите представляват движението на информация между UOB блокове по време на процес.

Съединенията се използват, за да покажат логиката на взаимодействието на стрелките (потоците) при сливане и разклоняване или за показване на множество събития, които могат или трябва да бъдат завършени, преди да може да започне следващата работа.

В тази работа стандартът IDEF3 е използван за визуално илюстриране на процесите на работа с автоматизирана система за анализ на финансови транзакции в застраховането.

Ориз. 2.3.1 Функционална схема „Автоматизация на работата на застрахователна компания“

За да влезе в системата, потребителят има възможност да се авторизира. След успешно влизане в системата, на потребителя се предоставя набор от действия (добавяне на нови данни, преглед, търсене на данни, изчисляване на индикатори). След като завърши следващата операция, потребителят може да избере следващата операция или да излезе от системата.

Ориз. 2.3.2 Декомпозиция на блока „Добавяне на нова информация“

За да добави нови документи към базата данни, потребителят трябва да попълни предложения формуляр, след което данните се проверяват за коректност, ако данните са правилни, те се запазват, ако данните са неправилни, потребителят ще получи съответно съобщение .

Ориз. 2.3.3 Декомпозиция на блока „Търсене на данни“.

Да търсите необходимата информацияпотребителят трябва да попълни формуляра с данните за търсене. След това данните се проверяват за коректност; ако данните са правилни, резултатът от търсенето ще се покаже на екрана; ако данните са неправилни, потребителят ще получи съобщение, което описва кои данни са неправилни и защо.

2. 4 Разработване на информационен модел

Това приложение работи с голямо количество данни, така че има нужда от правилно изградена структура за съхранение на данни. Инструментът CASE на Erwin беше използван за решаване на този проблем.

ERwin е инструмент за разработване на структура на база данни. ERwin съчетава графичен интерфейс на Windows, инструменти за изграждане на ER диаграми, редактори за създаване на логическо и физическо описание на модела на данни и прозрачна поддръжка за водещи релационни СУБД и настолни бази данни. С ERwin можете да създавате или извършвате обратно инженерство на бази данни.

Този инструмент предоставя редица възможности за проектиране, като например:

- директна връзка с базата данни: създаване на структура на база данни

директно от ERwin, възстановявайки модела на съществуваща база данни:

- преход от една целева база данни към друга използване

едно към едно съответствие на характеристиките на СУБД;

- управление на физическите характеристики на съхранението на данни (за

Oracle и Sybase - таблично пространство и съответно сегменти);

- съхранени набори от параметри на дисплея за изграждане на отчети и

диаграми;

- процедурите и тригерите са описани при изграждането на модел и

се създават автоматично в базата данни при генериране;

- способност за манипулиране на атрибути;

- възможност за съхраняване на диаграмата в целевата база данни или в DBF файлове:

- поддръжка на системата за контрол на версиите IVCS;

- избор на шрифт и цвят. Внедряване на симулация и ERwin

се основава на теорията на релационните бази данни и методологията IDEF1X.

Методологията IDEF1X дефинира стандарт за терминологията, използвана в информационното моделиране и графичното представяне на типични елементи в диаграми.

Има две възможни гледни точки върху информационния модел и съответно две нива на модела. Първият - логически (гледна точка на потребителя) - описва данните, включени в бизнеса на предприятието. Вторият – физическият – определя представянето на информацията в базата данни. ERWIN ги комбинира в една диаграма, която има няколко нива на представяне.

Ориз. 2.4.1 Логическо представяне на данните

Нека разгледаме целта на таблиците на базата данни на това приложение:

Таблицата с контакти е таблица, предназначена да съхранява информация за клиенти. Той съдържа следните данни:

· id - идентификатор на запис (PK);

· firstName - име на клиента;

· lastName - фамилно име на клиента;

· middleName - бащино име на клиента;

· адрес – клиентски адрес;

· телефон - телефонен номер на клиента;

· имейл - имейл адрес на клиента.

Таблица на полиците - таблица, съдържаща информация за застрахователните полици. Структура:

· id - идентификатор на застрахователна полица (ПК);

· contactID - идентификатор на потребителя, за когото е създадена политиката (FK);

· policeNumber - номер на застрахователната полица;

· activationDate - начало на откриване на застрахователната полица;

· expirationDate - изтичане на застрахователната полица;

· policyStatusID - идентификатор на състоянието на тази политика (FK);

· policySumm - застрахователната сума по тази полица.

Таблицата Users е таблица, която съхранява информация за потребителите на това приложение. Има следната структура:

· id - потребителски идентификатор (PK);

· вход - потребителско регистрационно име;

· парола – парола;

· firstName - потребителско име;

· lastName - фамилия;

· roleID - идентификатор на ролята на този потребител (FK).

Таблица с роли - съдържа списък на текущите потребителски роли на системата. Има следната структура:

· id - идентификатор на роля (PK).

· roleName - името на тази роля.

Таблица със статуси - съхранява списък с текущи статуси по застрахователни полици. Структура:

· id - идентификатор на статус (ПК);

· statusName - име на статуса.

Таблица TempTables - съхранява списък с временни таблици, които са създадени за временно съхраняване на резултатите от търсенето. Има следната форма:

· id - идентификатор на таблица (PK);

· tableName - име на временната таблица;

· userName - име на сесията на потребителя, за който е създадена таблицата

Статистическа таблица - съхранява статистически данни, които се използват за анализ на дейността на компанията. Структура:

· id - идентификатор на параметър (PK);

· име - име на статистическия параметър;

· value - стойността на статистическия параметър.

Ориз. 2.4.2 Физическо представяне на данните

2. 5 Ръководство за потребителя

Приложението има доста удобен за потребителя интерфейс и навигация, така че потребителят няма да има никакви проблеми при използването му. Принципът на работа с различни видове документи е един и същ, така че ще демонстрираме работата на приложението, като използваме примера на документа „Контакт“.

Когато приложението стартира, се появява страница за оторизация (фиг. 2.5.1), която изисква данни за идентификация на потребителя (вход, парола).

Фиг.2.5.1 Страница за оторизация на потребител

При успешна авторизация, потребителят отива на главната страница на приложението, където може да избере по-нататъшно действие (фиг. 2.5.2).

Когато изберете действието „Контакти“, на екрана се появява списък със съществуващи клиенти (фиг. 2.5.3). Първоначалният размер на страницата е 10 публикации, но ако желаете, можете да изберете различен размер и ако не всички публикации се поберат на страницата, се появяват връзки за навигация.

Фиг.2.5.2 Главна страница на приложението. Избор на действие

Всеки контакт може да бъде прегледан (и ако потребителските права позволяват, след това редактиран или изтрит), като щракнете върху връзката, която е стойността на колоната Име. След избор на конкретен клиент се отваря форма за преглед (редактиране) на този контакт (фиг. 2.5.4). Тази страница съдържа връзки Save&Close (запазване със затваряне на този контакт и отиване на страницата за избор на действие), Save (запазване на променените данни), Delete (изтриване на този контакт) и Cancel (отмяна на редактирането и затваряне на този контакт с отиване на страницата за избор на действие) .

Фиг.2.5.3 Страница за изглед на списък с клиенти

Фиг.2.5.4 Страница за редактиране на контакт

Фиг.2.5.5 Създайте нова страница за контакт

Когато изберете действието „Създаване на контакт“, се отваря страница със същата форма, само с празни полета. След като попълни полетата, потребителят има възможност да извърши три действия: да запази този контакт, да затвори формата и да отиде на страницата за избор на следващо действие; запишете контакта и останете на същата страница (в същото време се появява връзка към новото действие „Изтриване“) или отменете запазването на попълнените данни и отидете на страницата за избор на следващо действие.

Ако трябва да намерите набор от контакти по някакъв критерий (например по адрес), можете да използвате страницата за търсене на контакти (фиг. 2.5.6). Това е същата форма за контакт, само празна.След като попълни формуляра, потребителят има следните действия: стартира търсене и отидете на страницата за преглед на резултата от търсенето или отменете търсенето и отидете на страницата за избор на действие.

Фиг.2.5.6 Страница за генериране на заявка за търсене

Фиг.2.5.7 Страница за преглед на резултатите от търсенето

Когато изберете действието „Търсене“, вие отивате на страницата за изглед на резултатите (Фиг. 2.5.7), на която са налични всички същите действия като на страницата за изглед на списъка с клиенти.

Ззаключение

В резултат на написването на курсов проект беше внедрено интернет приложение, предназначено да автоматизира работата на застрахователна кампания. Приложението съдържа всички изисквания, има приятелски интерфейс и лесна навигация. Проектът е реализиран на езика за програмиране Java, така че приложението е кросплатформено, което позволява инсталиране на сървъри с всяка операционна система. По време на процеса на разработка бяха взети предвид точки като персонализиране, рефакторинг и разширяване на функционалността. Следователно архитектурата на приложението има такава структура и конфигурация, че горните процеси ще бъдат по-малко болезнени.

Приложението използва езика за заявки SQL по такъв начин, че да работи на всяка СУБД, така че превключването към друга СУБД включва само промяна на конфигурационния файл.

Крайният потребител на приложението са застрахователни компании и по-специално застрахователни агенти (регистрация на нови клиенти) и застрахователни анализатори (анализ на дейността на компанията въз основа на изчисления на параметри).

Изчисляването на актюерските параметри се извършва от компоненти на трети страни (EJB), които са свързани с приложението, като ги описват в конфигурационния файл. Следователно добавянето на нови изчислителни компоненти може да се извърши дори без преинсталиране на приложението.

Като допълнителна персонализация е възможно да се добавят нови компоненти за изчисление, нови видове документи, нови видове застраховки.

СЪСсписък на използваните източници

1. Дейвид М. Гери „Сървърни страници на Java“, Москва 2002 г

2. G. Shield, P. Naughton „Java 2“.

4. С.Б. Дунаев „Достъп до бази данни от Java програми“

5. Мислене в Java, 2-ро издание

6. S.A. Трофимов „Кейсови технологии. Практическа работав Rational Rose"

7. Sun Microsystems „Enterprise JavaBeans“ TMСпецификация"

8. Живот и здравно осигуряване / Кенет Блек, мл., Харолд Д. Скипър, мл. - 13-то изд. ISBN 0-13-891250-5.

9. Основи на застрахователната дейност, под редакцията на Т. А. Федорова. М. Издателство БЕК, 2000г.

10. Медведев Г.А. Математически модели финансови рискове. Част 1. Рискове поради несигурност лихвени проценти. - Мн.: БСУ, 1999.

ППриложение 1. Лisting програмен код

_____________________________________________________________

Конфигурационен файл с параметри на базата данни dbconfig.xml:

com.sybase.jdbc2.jdbc.SybDriver

jdbc:sybase:Tds:localhost:2638/insurance

dba

sql

Клас - конфигурационен анализатор DBConfigParser.java:

packageinsurance.utils;

импортиране на insurance.config.DBPropertiesContainer;

импортиране на org.apache.commons.digester.Digester;

импортиране на org.xml.sax.SAXException;

импортиране на java.io.IOException;

* Дата: 21.4.2007г

* Час: 23.37.37

публичен клас DBConfigParser имплементира IConfigParser(

public void parse(String fileName) хвърля IOException, SAXException (

Дигестер дигестер = нов дигестер();

setRules(дигестер);

digester.parse(име на файл);

private void setRules(Дигестер дигестер) (

digester.setValidating(false);

digester.push(DBPropertiesContainer.getInstance());

igester.addCallMethod("база данни/драйвер", "setDbDriver", 1);

digester.addCallParam("база данни/драйвер", 0);

digester.addCallMethod("база данни/url", "setUrl", 1);

digester.addCallParam("база данни/url", 0);

digester.addCallMethod("база данни/вход", "setLogin", 1);

digester.addCallParam("база данни/вход", 0);

digester.addCallMethod("база данни/парола", "setPassword", 1);

digester.addCallParam("база данни/парола", 0);

Класът, който изпълнява общи действияза работа с базата данни DataDAOHelper.java:

packageinsurance.dao;

import insurance.config.DAOContainer;

импортиране на insurance.dao.connector.DBConnector;

импортиране на java.sql.Connection;

импортиране на java.sql.SQLException;

* Дата: 23.04.2007г

* Час: 28.19.42

публичен клас DataDAOHelper (

public void save(IEntity entity) хвърля SQLException, ClassNotFoundException (

dao.save(против, обект);

) catch (SQLException e) (

public void delete(String docType, int id) хвърля SQLException, ClassNotFoundException (

Connection con = DBConnector.getConnection();

dao.delete(con, id);

) catch (SQLException e) (

хвърля ново SQLException(e.getSQLState());

public void undelete(String docType, int id) хвърля SQLException, ClassNotFoundException (

IDataDAO dao = getDAOByType(docType);

Connection con = DBConnector.getConnection();

dao.undelete(con, id);

) catch (SQLException e) (

хвърля ново SQLException(e.getSQLState());

public void update(IEntity entity) хвърля SQLException, ClassNotFoundException (

IDataDAO dao = getDAOByType(entity.getEntityType());

Connection con = DBConnector.getConnection();

dao.update(con, entity);

) catch (SQLException e) (

хвърля ново SQLException(e.getSQLState());

public void load(int id, IEntity entity) хвърля SQLException, ClassNotFoundException (

IDataDAO dao = getDAOByType(entity.getEntityType());

Connection con = DBConnector.getConnection();

dao.load(con, id, entity);

) catch (SQLException e) (

хвърля ново SQLException(e.getSQLState());

public IDataDAO getDAOByType(String docType) (

DAOContainer контейнер = DAOContainer.getInstance();

IDataDAO резултат = нула;

Class dao = Class.forName(container.getDAOForEntity(docType));

резултат = (IDataDAO) dao.newInstance();

) catch (ClassNotFoundException e) (

e.printStackTrace();

) catch (IllegalAccessException e) (

e.printStackTrace();

) catch (InstantiationException e) (

e.printStackTrace();

публичен статичен низ nullToEmpty(стойност на низ) (

връщане (стойност!= нула)? стойност: "";

Внедряване на работа с база данни за документ Контакт:

packageinsurance.dao;

вносна застраховка.beans.IEntity;

вносна застраховка.beans.PersonBean;

импортиране на java.sql.Connection;

импортиране на java.sql.PreparedStatement;

импортиране на java.sql.ResultSet;

импортиране на java.sql.SQLException;

* Дата: 22.4.2007г

публичен клас PersonDataDAOImpl имплементира IDataDAO (

частен финален статичен низ SAVE_QUERY = "INSERT INTO Person" +

"(Собствено име, Фамилия, Бащино име, адрес, телефон, имейл, версия)" +

"СТОЙНОСТИ (?, ?, ?, ?, ?, ?, ?)";

private final static String DELETE_QUERY = "UPDATE Person SET Version = -1 WHERE ID = ?";

частен финален статичен низ UNDELETE_QUERY = "АКТУАЛИЗИРАНЕ НА Лице НАБОР Версия = 1 WHERE ID =?";

private final static String UPDATE_QUERY = "UPDATE Person SET FirstName = ?," +

"Фамилия = ?, Средно име = ?, Адрес = ?, Телефон = ?, имейл = ? WHERE id = ?";

частен финален статичен низ LOAD_QUERY = "ИЗБЕРЕТЕ име, фамилия, бащино име," +

„Адрес, телефон, имейл, версия FROM Person WHERE id = ?“;

public void save(Connection con, IEntity entity) хвърля SQLException (

PersonBean person = (PersonBean) обект;

PreparedStatement ps = null;

ps = con.prepareStatement(SAVE_QUERY);

ps.setString(1, person.getFirstName());

ps.setString(2, person.getLastName());

ps.setString(3, person.getMiddleName());

ps.setString(4, person.getAddress());

ps.setString(5, person.getPhone());

ps.setString(6, person.getEmail());

ps.setInt(7, person.getVersion());

ps.executeUpdate();

assert ps != null;

public void delete(Connection con, int id) хвърля SQLException (

PreparedStatement ps = null;

ps = con.prepareStatement(DELETE_QUERY);

ps.setInt(1, id);

ps.executeUpdate();

assert ps != null;

public void undelete(Connection con, int id) хвърля SQLException (

PreparedStatement ps = null;

ps = con.prepareStatement(UNDELETE_QUERY);

Подобни документи

Разработване на функционален модел на предметната област. Изграждане на UML диаграми в средата на Pacestar UML Diagrammer. Избор на инструменти за разработка на софтуер. Разработване на логически и физически модел на данни. Разработка на клиентско ИС приложение в среда на Access.

курсова работа, добавена на 09.03.2011 г


Избор, обосновка и характеристики на СУБД. Характеристики на езиците за програмиране. Разработване на структурно-функционален модел на аптечна информационна система. Проектиране на софтуерната среда на АИС и нейния интерфейс. Изграждане на модел на база данни.

курсова работа, добавена на 21.04.2012 г


Анализ на входната информация и процеси, ниво на автоматизация в предприятието. Идентифициране на обекта и задачата на автоматизацията. Разработване на концепция за изграждане на информационен модел на информационна система. Разработване на структура на база данни и клиентско приложение.

дисертация, добавена на 22.11.2015 г


Проектиране на многопотребителска информационна система за автоматизиране на работата на диспечер в отдела за превоз на товари. Избор на среда за програмиране. Разработка на софтуер, ASOI бази данни таблици. Конструиране на диаграми на класове и дейности.

курсова работа, добавена на 03.06.2014 г


Проектиране на приложение за автоматизиране на застрахователния процес, което ще помогне на застрахователните агенти да намалят времето за работа с документацията. Разработване на приложна програма за достъп до база данни в среда Delphi. Система за управление на бази данни.

курсова работа, добавена на 14.01.2015 г


Създаване на информационна система за автоматизиране на процеса на управление на базата данни на Rosneft LLC. Изисквания към характеристиките на техническите средства. Обосновка за избора на CASE инструмент. Разработка на софтуер, изчисляване на разходите и печалбата.

дисертация, добавена на 24.03.2012 г


Основи на методологията за проектиране на информационни системи. основни характеристикии класификация на CASE инструменти. Разглеждане на логическия, функционалния и физическия модел на данни на система "Студент". Изчисляване на трудоемкостта на разработването на софтуерен продукт.

дисертация, добавена на 16.03.2012 г


Анализ на решения за автоматизация на домейн. Избор на методология за проектиране на информационна система. Обосновка за избор на платформа. Взаимодействие на приложението с източници на данни. Избор жизнен цикълразработване на софтуер.

дисертация, добавена на 18.12.2010 г


Организация и продажба на офис оборудване. Цели на автоматизираната система и автоматизирани функции. Характеристика на функционалната структура на информационната система. Проектиране на функционалната част на обекта за автоматизация. Обосновка на избора на подсистема.

курсова работа, добавена на 19.12.2010 г


Преглед на принципите на изграждане и ефективно използване на системи за управление на бази данни, инструменти за автоматизация на дизайна на CASE. Анализ на възможностите на методологията и инструментите. Разработване на модел на хотелски бизнес процеси в среда All Fusion.

• Кой е архитект и с какво се занимава?
• Какво да вземете, за да станете одитор
• Стратегия „Победа“ – печеливш скалп на Forex
• Нека направим пари на фондовата борса в кампанията за един играч!
• Потенциалният БВП се измерва чрез обем
• Концепцията, функциите и значението на финансовите отчети в руската и международната практика
• Микроикономика и макроикономика
• Ние работим правилно: всички инструкции за бюджетно счетоводство P 153 инструкции 174n
• Лош дълг от задбалансова сметка Когато дълговете на контрагентите са признати за лоши
• Консолидирана отчетност Консолидирана отчетност бюджет 21 отдел образование otcdi

• Пример за изчисляване на индексацията на заплатата
• Как да коригирате малка грешка зависи от
• Тестване на интервю за счетоводител
• Индексация на заплатите: изберете правилно „базовия“ месец Задаване на базовия месец за изчисляване на индексацията
• Счетоводни тестове
• Как и къде да сменим медицинска застраховка?
• Анонимизиран метален акаунт
• Какво включва задължителната медицинска застраховка - безплатни грижи и услуги, включени в полицата
• Как и къде да получите полица за задължителна медицинска застраховка?
• Коя застрахователна компания да избера за сключване на задължителна медицинска застраховка?