SPIN2-wiki - Príspevky používateľa [sk]

Dlhopisy - Splatkové kalendare, Investor, vynos

2025-01-14T12:40:30Z

Roman.adamjak:

<div>


= Dlhopisy – VYNOS, SK, Investor =

<blockquote>KTFINANCE-1672
</blockquote>
<blockquote>
</blockquote>

== Produkt ==

''P2P – Číselníky – šípka – Produkt''

Riešený v úlohe https://jira.assecosol.eu/browse/KTFINANCE-1699

== Zápis investičnej zmluvy ==

Riešený v úlohe https://jira.assecosol.eu/browse/KTFINANCE-1699

== Splátkový kalendár dlžníka, investora ==

Pri produkte označenom dlhopis. Bude možné mať nastavený spôsob výpočtu anuitný štandard, bez vstupného poplatku. Splátkový kalendár dĺžníka sa bude počítať bez úroku investora.

Splátka investora = splátka istina

Xirr úročiteľ pre investora = 0.

Investorský kalendár:

[[File:Dl1.png|604x158px]]

Dlžnícky kalendár:

[[File:Dl2.png|604x144px]]

Vzor:

== ZZP ==

Pri ZZP postúpenie, predčasné splatenie, vypovedanie, konsolidácia – tam kde sa počítajú zostatky úroku je potrebné, aby počítalo zostatok úroku 0, nerobilo prepočet.

Vzhľadom nato, že splátkový kalendár investora bude mať nulový úročiteľ a žiadny úrok, padali by dané ZZP na výpočte zostatku úroku.

Postúpenie – nebude možné medzi rôznymi produktmi – dlhopisový a nedlhopisový. Postúpi sa istina

== Generovanie dokladov ==

Reinvestícia - Došlá faktúra na presun peňazí z účtu na účet pri reinvestícii z nastavenia v 2.8..

Reinvestícia - Interný doklad z nastavenia v 2.8.

Investičná zmluva – Evidencia výnosov - Zálohová došlá faktúra na vyplatenie výnosu v nastavení 2.8..

== Reinvestícia ==

<s>Setup na minimálnu reinvestíciu pre všetky typy – dlhopis a aj pôvodný spôsob investovania.</s>

Reinvestícia – voľné financie3= z posledného záznamu nového výpočtu bez ohľadu na typ

Reinvestícia z dlhopisov vytvorí záznam do nového sledovania investovania.

Reinvestícia – generuje pri reinvestícii dlhopisov interný doklad z nastavenia v 2.8., došlá faktúra – z nastavenia v 2.8..

Reinvestičná investičná zmluva môže vzniknúť z voľných financií pôvodného systému reinvestície voľné financie 2 alebo dlhopisového systému reinvestície – voľné financie3. Nemôžu byť použité voľné financie 2 a 3 na novej reinvestičnej zmluve. Pri dlhopisovej reinvestícii nemôže byť dodatočný vklad investora. Vzniká automaticky – nie službou.

== Výnos investora ==

''P2P > Zmluvy > Investičná zmluva > [karta] Výnos''

Nová karta. % výnosu z doby investovania. Výnos sa bude počítať denne jobom, v poslednom dni nastane zápis

''P2P > Klient > Investor > [karta]'' ''Vyplatenie výnosu''

<ul>
<li><ul>
<li><blockquote>'''Hodnoty:''' </blockquote>
<ul>
<li><blockquote>'''Mesačne''' – vyplatenie výnosu mesačne - (vynos sa reinvestuje 1. polovicu mesiaca), istina sa reinvestuje (2)</blockquote></li>
<li><blockquote>'''Ročne''' – vyplatenie výnosu ročne a reinvestujeme do októbra a potom začnem zbierať peniaze na vyplatenie, istina sa reinvestuje (1) výberom na konci roka, zostáva istina </blockquote></li>
<li><blockquote>'''Všetko mesačne''' – vyplatenie všetkého z voľných financií výnos aj uhradená istina (3)</blockquote></li>
<li><blockquote>'''Na vyžiadanie''' – Nevyplácame - vždy všetko reinvestujeme, čo je vo voľných financiách. Ukončenie je na vyžiadanie a potom sa budú zbierať financie na vyplatenie (1) výnos</blockquote></li></ul>
</li></ul>
</li></ul>

Pri programovaní z Marketingových údajov:

[[File:Dl3.png|519x308px]]

'''4 Varianty:'''

<ol style="list-style-type: decimal;">
<li><blockquote>'''Ročne alebo na vyžiadanie vyplatenie – výnos a uhradená istina sa reinvestuje'''</blockquote></li></ol>

[[File:Dl4.png|604x242px]]

<ol start="2" style="list-style-type: decimal;">
<li><blockquote>'''Mesačne vyplácanie výnosu, uhradená istina sa reinvestuje'''</blockquote></li></ol>

[[File:Dl5.png|604x197px]]

<ol start="3" style="list-style-type: decimal;">
<li><blockquote>'''Všetko mesačne – vyplatenie výnosu aj uhradenej istiny'''</blockquote></li></ol>

[[File:Dl6.png|604x174px]]

<ol start="4" style="list-style-type: decimal;">
<li><blockquote>'''Reinvestícia'''</blockquote></li></ol>

[[File:Dl7.png.png|604x198px]]

'''Bez ohľadu na variant pri príznuku, že ide o reinvestičnú investičnú zmluvu počítajú sa len voľné finanancie z uhradenej istiny.'''

Výnos sa počíta denne pri variante 1, keď je možná reinvestícia ihneď, zápis nastáva pri reivestícii, následujúci výnos sa počíta z posledného záznamu výnosu

'''Typ''' – Vklad (úhrada zálohovej faktúry s dátumom faktúry), Začiatok ( prvý deň mesiaca od prvého vkladu), Výnos (výpočet nižšie), Vyplatenie (zaslanie peňazí na základe akcie alebo pravidelne )

'''Výnos''' = %výnosu*zostatok istiny z koncomesačného zostatku typ výnos/100/365*Rozdiel dátumov (zaokrúhlenie matematicky 2 des. Čísla)

'''Zrážková daň''' = 19*Výnos/100 (zaokrúhlenie matematicky 2 des. Čísla)

'''Čistý výnos''' = Výnos – Zrážková daň

'''Reinvestovanie''' = suma, ktorá sa reinvestovala – variant1 výnos a uhradená istina, variant2 uhradená istina.

'''Zostatok''' = zostatok z predchádzajúceho záznamu výnosu, pripočítame výnos daného mesiaca a odpočítame vyplatenie výnosu. Ak je v danom mesiaci vklad, pripočíta sa k zostatku. Zostatok pre variantu 3 je ponížený o uhradenú istinu.

'''Reinvestícia''' – suma reinvestície, vytvorí sa zo systému tvorby reinvestičných zmlúv 2.6.

'''Voľné financie''' = výpočet závislí od varianty. Pre variantu 1: zostatok voľných financií pred. Mesiac + čistý výnos +uhradená istina – reinvestíce. Nepočítajú sa tu vklady

'''% Vynos''' = z doby financovania investičnej zmluvy

'''% Zrážkovej dane''' – z nastavenia v 2.8.

'''Uhradená istina''' – súčet úhrad istiny priebežne k výnosu, následne zápis, ak bude zapísaný výnos a výpočet od posledného zápisu do konca mesiaca za ktorý sa robí prepočet

'''Uzávierka''' – z bodu 2.8.

'''Doklad vyplatenia''' – z bodu 2.8.

Zmena Varianty sa prejaví pri výpočte nasledujúceho mesiaca. Daný mesiac sa počíta z nastavenia predchádzajúceho mesiaca.

Príklad – spôsob výpočtu Mesačne sa zmení na Ročne 15.3., za marec bude výpočet a vyplatenie výnosu podľa nastavenia Mesačne, v mesiaci marec sa zapíše Variant Ročne.

== Evidencia dlhopisov ==

Nové okno v šípke Iné evidencie.

'''Karty:'''

<ol style="list-style-type: decimal;">
<li><blockquote>Dávka</blockquote></li>
<li><blockquote>Riadky dávky</blockquote></li>
<li><blockquote>Karta Nastavenie</blockquote></li></ol>

'''Akcie:'''

Prepočet – prepočíta dávku, uzamkne všetky vygenerované predpisy a vyplatenie za mesiac, za ktorý bude spustená. Vstupný argument mesiac.

Zmazanie dávky – zmaže prepočítanú dávku

Generovanie dokladov – vygeneruje zálohové faktúry na vyplatenie a zapíše ich k výnosom.

'''Karta Dávka'''

'''Stĺpce : '''Mesiac a rok uzávierky, Názov : Evidencia dlhopisov, Užívateľ, Dátum prepočtu (sysdate)

'''Karta Riadky dávky'''

'''Stĺpce:'''

Investičná zmluva web_id

Typ – výnos, vyplatenie, reinvestícia, vklad

Vynos – hodnota vyplatenia, hodnota výnosu

Zrážková daň – ak typ výnos, tak hodnota z výnosu

Čistý výnos – ak typ výnos, tak hodnota z výnosu

'''Karta Nastavenie'''

[[File:Dl8.png|563x109px]]

== Job ==

Job každý deň prepočíta výnos za D-1 pracovný deň. Vklad bude priradený k zmluve napr. 2.4.2024, ale spracuje sa 2.4.2024 s dátumom vkladu 28.3.2024. Ak nasledujúci deň bude prvý deň nového mesiaca, vytvorí sa nový riadok. Ak nastane reinvestícia, vytvorí sa nový riadok.

== Voľné financie3 ==

Vytvorenie nového výpočtu voľných financíí – do voľných financií vstupuje:

<ol style="list-style-type: decimal;">
<li><blockquote>Varianta – uhradená istina a výnos</blockquote></li>
<li><blockquote>Varianta – uhradená istina</blockquote></li>
<li><blockquote>Varianta – nič</blockquote></li></ol>

Reinvestícia – voľné financie3 = uhradená istina

Príznak reinvestícia https://jira.assecosol.eu/browse/KTFINANCE-1688

==== Akcia Vyplatenie ====

''P2P > Zmluvy > Investičná zmluva > [karta] Investičná zmluva''

Akcia Vyplatenie bude mať 2 režimy vyplatenia pre WEBID investičného plánu investora, ktorý:

<ol style="list-style-type: upper-alpha;">
<li><blockquote>Investičný plán investora má príznak Dlhopis = Nie (nemá dlhopisové investičné zmluvy) – súčasný stav</blockquote>
<ol style="list-style-type: lower-alpha;">
<li><blockquote>Akcia bude fungovať ako teraz bez zmeny</blockquote></li></ol>
</li>
<li><blockquote>Investičný plán investora má príznak Dlhopis = Áno (má dlhopisové investičné zmluvy)</blockquote>
<ol style="list-style-type: lower-alpha;">
<li><blockquote>Akciu bude možné spustiť pre všetky typy spôsobu vyplatenia výnosu investora (nekontroluje sa)</blockquote></li>
<li><blockquote>Zadaním sumy pre vyplatenie systém nájde zmluvy investičného plánu investora podľa rovnakého algoritmu ako v bode A. Pre dlhopisové zmluvy bude na investičných zmluvách pozerať na voľné financie 3. Z investičnej zmluvy bude vyplatená suma max do výšky voľných financií 3 investičnej zmluvy (platí aj pre reinvestičné zmluvy)</blockquote></li>
<li><blockquote>Súčasťou vyplatenia vznikne záznam '''''„Výnos“''''' a '''''„Vyplatenie manuál“''''' v karte výnos k dátumu vyplatenia (sysdate) Vyplatenie bude formou dod. faktúry(bez zmeny) a ponižuje hodnotu voľné financie 3 a zostatok (viď obr a excel v [[#anchor-17|Výnos investora]] )</blockquote></li></ol>
</li></ol>

[[File:Dl9.png|604x266px]]

== Tlačové výstupy ==

Úpravy v tlačivách, kde je požité voľné financie. Niesú predmetom zmenového listu.

== Služby náhrada voľné financie ==

Úprava služieb s voľnými financiami – náhrada Voľné financie3. Vo vymenovaných službách bude systém v prípade, ak ide o investičný plán typu Dlhopis = Áno, nahradená hodnota voľných financií za novú hodnotu z Voľných financií 3 v prípade:

<ul>
<li><blockquote>GET /ptp/invest_offer/ {clientWebId}</blockquote></li>
<li><blockquote>GET /ptp/invest_offer2/{clientWebId}</blockquote></li>
<li><blockquote>GET /ptp/invest_withdrawal/ {clientWebId}</blockquote></li>
<li><blockquote>GET /ptp/invest_main/ {birthNumber}</blockquote></li></ul>

</div>

[[category:PTP (person to person)]]

Dlhopisy - Splatkové kalendare, Investor, vynos

2025-01-14T12:39:30Z

Roman.adamjak:

Súbor:Dl9.png

2025-01-14T12:34:01Z

Roman.adamjak:

Súbor:Dl8.png

2025-01-14T12:33:38Z

Roman.adamjak:

Súbor:Dl7.png

2025-01-14T12:33:28Z

Roman.adamjak:

Súbor:Dl6.png

2025-01-14T12:33:08Z

Roman.adamjak:

Súbor:Dl5.png

2025-01-14T12:32:58Z

Roman.adamjak:

Súbor:Dl4.png

2025-01-14T12:32:46Z

Roman.adamjak:

Súbor:Dl3.png

2025-01-14T12:32:26Z

Roman.adamjak:

Súbor:Dl2.png

2025-01-14T12:32:14Z

Roman.adamjak:

Súbor:Dl1.png

2025-01-14T12:31:59Z

Roman.adamjak:

Dlhopisy - Splatkové kalendare, Investor, vynos

2025-01-14T12:29:27Z

Roman.adamjak: Vytvorená stránka „<div> = Dlhopisy – VYNOS, SK, Investor = <blockquote>KTFINANCE-…“

<div>


= Dlhopisy – VYNOS, SK, Investor =

<blockquote>KTFINANCE-1672
</blockquote>
<blockquote>
</blockquote>

== Produkt ==

''P2P – Číselníky – šípka – Produkt''

Riešený v úlohe https://jira.assecosol.eu/browse/KTFINANCE-1699

== Zápis investičnej zmluvy ==

Riešený v úlohe https://jira.assecosol.eu/browse/KTFINANCE-1699

== Splátkový kalendár dlžníka, investora ==

Pri produkte označenom dlhopis. Bude možné mať nastavený spôsob výpočtu anuitný štandard, bez vstupného poplatku. Splátkový kalendár dĺžníka sa bude počítať bez úroku investora.

Splátka investora = splátka istina

Xirr úročiteľ pre investora = 0.

Investorský kalendár:

[[File:Pictures/10000000000003DA00000103A59F87B9.png|604x158px]]

Dlžnícky kalendár:

[[File:Pictures/1000000000000315000000BDEA029326.png|604x144px]]

Vzor:

== ZZP ==

Pri ZZP postúpenie, predčasné splatenie, vypovedanie, konsolidácia – tam kde sa počítajú zostatky úroku je potrebné, aby počítalo zostatok úroku 0, nerobilo prepočet.

Vzhľadom nato, že splátkový kalendár investora bude mať nulový úročiteľ a žiadny úrok, padali by dané ZZP na výpočte zostatku úroku.

Postúpenie – nebude možné medzi rôznymi produktmi – dlhopisový a nedlhopisový. Postúpi sa istina

== Generovanie dokladov ==

Reinvestícia - Došlá faktúra na presun peňazí z účtu na účet pri reinvestícii z nastavenia v 2.8..

Reinvestícia - Interný doklad z nastavenia v 2.8.

Investičná zmluva – Evidencia výnosov - Zálohová došlá faktúra na vyplatenie výnosu v nastavení 2.8..

== Reinvestícia ==

<s>Setup na minimálnu reinvestíciu pre všetky typy – dlhopis a aj pôvodný spôsob investovania.</s>

Reinvestícia – voľné financie3= z posledného záznamu nového výpočtu bez ohľadu na typ

Reinvestícia z dlhopisov vytvorí záznam do nového sledovania investovania.

Reinvestícia – generuje pri reinvestícii dlhopisov interný doklad z nastavenia v 2.8., došlá faktúra – z nastavenia v 2.8..

Reinvestičná investičná zmluva môže vzniknúť z voľných financií pôvodného systému reinvestície voľné financie 2 alebo dlhopisového systému reinvestície – voľné financie3. Nemôžu byť použité voľné financie 2 a 3 na novej reinvestičnej zmluve. Pri dlhopisovej reinvestícii nemôže byť dodatočný vklad investora. Vzniká automaticky – nie službou.

== Výnos investora ==

''P2P > Zmluvy > Investičná zmluva > [karta] Výnos''

Nová karta. % výnosu z doby investovania. Výnos sa bude počítať denne jobom, v poslednom dni nastane zápis

''P2P > Klient > Investor > [karta]'' ''Vyplatenie výnosu''

<ul>
<li><ul>
<li><blockquote>'''Hodnoty:''' </blockquote>
<ul>
<li><blockquote>'''Mesačne''' – vyplatenie výnosu mesačne - (vynos sa reinvestuje 1. polovicu mesiaca), istina sa reinvestuje (2)</blockquote></li>
<li><blockquote>'''Ročne''' – vyplatenie výnosu ročne a reinvestujeme do októbra a potom začnem zbierať peniaze na vyplatenie, istina sa reinvestuje (1) výberom na konci roka, zostáva istina </blockquote></li>
<li><blockquote>'''Všetko mesačne''' – vyplatenie všetkého z voľných financií výnos aj uhradená istina (3)</blockquote></li>
<li><blockquote>'''Na vyžiadanie''' – Nevyplácame - vždy všetko reinvestujeme, čo je vo voľných financiách. Ukončenie je na vyžiadanie a potom sa budú zbierať financie na vyplatenie (1) výnos</blockquote></li></ul>
</li></ul>
</li></ul>

Pri programovaní z Marketingových údajov:

[[File:Pictures/100000000000028900000182161FF02F.png|519x308px]]

'''4 Varianty:'''

<ol style="list-style-type: decimal;">
<li><blockquote>'''Ročne alebo na vyžiadanie vyplatenie – výnos a uhradená istina sa reinvestuje'''</blockquote></li></ol>

[[File:Pictures/100000000000064600000285354256CD.png|604x242px]]

<ol start="2" style="list-style-type: decimal;">
<li><blockquote>'''Mesačne vyplácanie výnosu, uhradená istina sa reinvestuje'''</blockquote></li></ol>

[[File:Pictures/100000000000045A0000016C684DDEE2.png|604x197px]]

<ol start="3" style="list-style-type: decimal;">
<li><blockquote>'''Všetko mesačne – vyplatenie výnosu aj uhradenej istiny'''</blockquote></li></ol>

[[File:Pictures/10000000000004500000013F63BF5F13.png|604x174px]]

<ol start="4" style="list-style-type: decimal;">
<li><blockquote>'''Reinvestícia'''</blockquote></li></ol>

[[File:Pictures/100000000000045D0000016F94D39AA5.png|604x198px]]

'''Bez ohľadu na variant pri príznuku, že ide o reinvestičnú investičnú zmluvu počítajú sa len voľné finanancie z uhradenej istiny.'''

Výnos sa počíta denne pri variante 1, keď je možná reinvestícia ihneď, zápis nastáva pri reivestícii, následujúci výnos sa počíta z posledného záznamu výnosu

'''Typ''' – Vklad (úhrada zálohovej faktúry s dátumom faktúry), Začiatok ( prvý deň mesiaca od prvého vkladu), Výnos (výpočet nižšie), Vyplatenie (zaslanie peňazí na základe akcie alebo pravidelne )

'''Výnos''' = %výnosu*zostatok istiny z koncomesačného zostatku typ výnos/100/365*Rozdiel dátumov (zaokrúhlenie matematicky 2 des. Čísla)

'''Zrážková daň''' = 19*Výnos/100 (zaokrúhlenie matematicky 2 des. Čísla)

'''Čistý výnos''' = Výnos – Zrážková daň

'''Reinvestovanie''' = suma, ktorá sa reinvestovala – variant1 výnos a uhradená istina, variant2 uhradená istina.

'''Zostatok''' = zostatok z predchádzajúceho záznamu výnosu, pripočítame výnos daného mesiaca a odpočítame vyplatenie výnosu. Ak je v danom mesiaci vklad, pripočíta sa k zostatku. Zostatok pre variantu 3 je ponížený o uhradenú istinu.

'''Reinvestícia''' – suma reinvestície, vytvorí sa zo systému tvorby reinvestičných zmlúv 2.6.

'''Voľné financie''' = výpočet závislí od varianty. Pre variantu 1: zostatok voľných financií pred. Mesiac + čistý výnos +uhradená istina – reinvestíce. Nepočítajú sa tu vklady

'''% Vynos''' = z doby financovania investičnej zmluvy

'''% Zrážkovej dane''' – z nastavenia v 2.8.

'''Uhradená istina''' – súčet úhrad istiny priebežne k výnosu, následne zápis, ak bude zapísaný výnos a výpočet od posledného zápisu do konca mesiaca za ktorý sa robí prepočet

'''Uzávierka''' – z bodu 2.8.

'''Doklad vyplatenia''' – z bodu 2.8.

Zmena Varianty sa prejaví pri výpočte nasledujúceho mesiaca. Daný mesiac sa počíta z nastavenia predchádzajúceho mesiaca.

Príklad – spôsob výpočtu Mesačne sa zmení na Ročne 15.3., za marec bude výpočet a vyplatenie výnosu podľa nastavenia Mesačne, v mesiaci marec sa zapíše Variant Ročne.

== Evidencia dlhopisov ==

Nové okno v šípke Iné evidencie.

'''Karty:'''

<ol style="list-style-type: decimal;">
<li><blockquote>Dávka</blockquote></li>
<li><blockquote>Riadky dávky</blockquote></li>
<li><blockquote>Karta Nastavenie</blockquote></li></ol>

'''Akcie:'''

Prepočet – prepočíta dávku, uzamkne všetky vygenerované predpisy a vyplatenie za mesiac, za ktorý bude spustená. Vstupný argument mesiac.

Zmazanie dávky – zmaže prepočítanú dávku

Generovanie dokladov – vygeneruje zálohové faktúry na vyplatenie a zapíše ich k výnosom.

'''Karta Dávka'''

'''Stĺpce : '''Mesiac a rok uzávierky, Názov : Evidencia dlhopisov, Užívateľ, Dátum prepočtu (sysdate)

'''Karta Riadky dávky'''

'''Stĺpce:'''

Investičná zmluva web_id

Typ – výnos, vyplatenie, reinvestícia, vklad

Vynos – hodnota vyplatenia, hodnota výnosu

Zrážková daň – ak typ výnos, tak hodnota z výnosu

Čistý výnos – ak typ výnos, tak hodnota z výnosu

'''Karta Nastavenie'''

[[File:Pictures/10000000000002C000000089CEB609AD.png|563x109px]]

== Job ==

Job každý deň prepočíta výnos za D-1 pracovný deň. Vklad bude priradený k zmluve napr. 2.4.2024, ale spracuje sa 2.4.2024 s dátumom vkladu 28.3.2024. Ak nasledujúci deň bude prvý deň nového mesiaca, vytvorí sa nový riadok. Ak nastane reinvestícia, vytvorí sa nový riadok.

== Voľné financie3 ==

Vytvorenie nového výpočtu voľných financíí – do voľných financií vstupuje:

<ol style="list-style-type: decimal;">
<li><blockquote>Varianta – uhradená istina a výnos</blockquote></li>
<li><blockquote>Varianta – uhradená istina</blockquote></li>
<li><blockquote>Varianta – nič</blockquote></li></ol>

Reinvestícia – voľné financie3 = uhradená istina

Príznak reinvestícia https://jira.assecosol.eu/browse/KTFINANCE-1688

==== Akcia Vyplatenie ====

''P2P > Zmluvy > Investičná zmluva > [karta] Investičná zmluva''

Akcia Vyplatenie bude mať 2 režimy vyplatenia pre WEBID investičného plánu investora, ktorý:

<ol style="list-style-type: upper-alpha;">
<li><blockquote>Investičný plán investora má príznak Dlhopis = Nie (nemá dlhopisové investičné zmluvy) – súčasný stav</blockquote>
<ol style="list-style-type: lower-alpha;">
<li><blockquote>Akcia bude fungovať ako teraz bez zmeny</blockquote></li></ol>
</li>
<li><blockquote>Investičný plán investora má príznak Dlhopis = Áno (má dlhopisové investičné zmluvy)</blockquote>
<ol style="list-style-type: lower-alpha;">
<li><blockquote>Akciu bude možné spustiť pre všetky typy spôsobu vyplatenia výnosu investora (nekontroluje sa)</blockquote></li>
<li><blockquote>Zadaním sumy pre vyplatenie systém nájde zmluvy investičného plánu investora podľa rovnakého algoritmu ako v bode A. Pre dlhopisové zmluvy bude na investičných zmluvách pozerať na voľné financie 3. Z investičnej zmluvy bude vyplatená suma max do výšky voľných financií 3 investičnej zmluvy (platí aj pre reinvestičné zmluvy)</blockquote></li>
<li><blockquote>Súčasťou vyplatenia vznikne záznam '''''„Výnos“''''' a '''''„Vyplatenie manuál“''''' v karte výnos k dátumu vyplatenia (sysdate) Vyplatenie bude formou dod. faktúry(bez zmeny) a ponižuje hodnotu voľné financie 3 a zostatok (viď obr a excel v [[#anchor-17|Výnos investora]] )</blockquote></li></ol>
</li></ol>

[[File:Pictures/100002010000054D0000025796488D38.png|604x266px]]

== Tlačové výstupy ==

Úpravy v tlačivách, kde je požité voľné financie. Niesú predmetom zmenového listu.

== Služby náhrada voľné financie ==

Úprava služieb s voľnými financiami – náhrada Voľné financie3. Vo vymenovaných službách bude systém v prípade, ak ide o investičný plán typu Dlhopis = Áno, nahradená hodnota voľných financií za novú hodnotu z Voľných financií 3 v prípade:

<ul>
<li><blockquote>GET /ptp/invest_offer/ {clientWebId}</blockquote></li>
<li><blockquote>GET /ptp/invest_offer2/{clientWebId}</blockquote></li>
<li><blockquote>GET /ptp/invest_withdrawal/ {clientWebId}</blockquote></li>
<li><blockquote>GET /ptp/invest_main/ {birthNumber}</blockquote></li></ul>

</div>

[[category:PTP (person to person)]]

Nákupný faktoring

2024-04-12T06:17:53Z

Roman.adamjak:

KTFINANCE-1571 Nákupný faktoring

=== Okno Faktoring ===

''P2P – Úhrady – šípka – okno Faktoring''

'''Doplnenie kariet Sadzby odmeny, Nákupný faktoring'''

[[Image:NF1.png]]

===== Karta Sadzby odmeny =====
ICO – vyberač z číselníka firiem

Názov firmy – zobrazenie

Dni omeškania – number počet dní

Odmena - %odmeny za nákupný faktoring

===== Karta Nákupný faktoring =====
Podobne ako v Nastavení

[[Image:NF2.png]]

=== Úpravy akcií v okne Faktoring ===

===== Úprava importu =====
Pri importe nákupného faktoringu – typ N sa budú počítať 5 možných odmien. Ak zaplatí včase do prvého intervalu bude to hodnota nižšia ako pre druhý interval. Ak nebude existovať pre danú firmu žiadna sadzba vyhlásiť chybu: Pre danú firmu musí byť zadaná minimálne jedna hodnota odmeny.

Doplniť do okna Faktoring 5 stĺpcov: Odmena1, Odmena2, Odmena3, Odmena4, Odmena5.

Systém vypočíta toľko odmien, koľko bude mať sadzbie – max. 5.

Príklad:

{| border="1"
|'''Počet dní'''
|'''Istina'''
|'''%'''
|'''Suma'''
|-

|20
|1000
|1,2
|12
|-

|30
|1000
|2
|20
|-

|40
|1000
|2,3
|23
|-

|50
|1000
|2,5
|25
|-

|999
|1000
|3,5
|35
|}

Výpočet odmeny – istina* sadzba

Ak bude splnená splatnosť od počet dní prvej skupiny – čo bude zrejme do splatnosti. Predávajúci musí zaplatiť okrem istiny aj hodnotu odmeny.

===== Úprava akcie Generovanie dokladov =====
Vybavenie nastáva, ak bude sedieť zaplatená suma – istina + odmena pre interval zadaný v karte Sadzby odmeny. Suma vypočítaná v odmene je minimálna, ak bude prekročenie je to splnenie podmienok.

Príklad:

Ak vychádzame z príkladu na istinu 1000,-- a možné odmeny 12,20,23,25,35. Faktúra bola uhradená do 20 dní a má úhradu 1012, tak začína generovanie dokladov, ak nie

===== Výpočet ostatných hodnôt =====
Fond sa počíta rovnako ako pre riadny a fondový. Max však do výšky odmeny.

Interný výnos je rozdiel Úhrada – istina – odmena.

Príklad:

{| border="1"
|Odmeny
|

|

|

|-

|Počet dní
|Istina
|%
|Suma
|-

|20
|1000
|1,2
|12
|-

|30
|1000
|2
|20
|-

|40
|1000
|2,3
|23
|-

|50
|1000
|2,5
|25
|-

|999
|1000
|3,5
|35
|-

|

|

|

|

|}

{| border="1"
|Príklad
|'''Platič 1'''
|'''Platič odmena2'''
|-

|Suma faktúry
|1000
|1000
|-

|%1 splatky
|100
|100
|-

|Istina
|1000
|1000
|-

|Odmena %
|1,2
|2
|-

|Suma odmeny
|12
|20
|-

|Datum aktivacie
|2.5.2023
|1.3.2023
|-

|Datum splatnosti
|15.5.2023
|15.3.2023
|-

|Dátum úhrady
|3.5.2023
|25.3.2023
|-

|Denna sadzba_platič
|0,164383562
|0,17260274
|-

|Denna sadzba_neplatič
|

|0,215753425
|-

|%fond
|5
|4
|-

|%overboard
|1
|2,3
|-

|%neplatič
|3
|1,25
|-

|Vynos fond
|0,328767123
|4,746575342
|-

|Vynos interny
|11,67123288
|7,253424658
|-

|Suma úhrady
|1012
|1012
|}

=== Generovanie dokladov ===

===== Interný doklad na začiatku =====
Z nastavenia pre Nákupný faktoring.

Účtuje a generuje sa rovnako ako v riadnom a fondovom faktoringu.

===== Výnosová faktúra =====
Z nastavenia pre Nákupný faktoring.

Rovnako ako v riadnom a fondovom faktoringu.

Suma = výnos interný.

Výpočet : Suma úhrady-suma faktury-výnos fond

===== Nákladová faktúra =====
Z nastavenia pre Nákupný faktoring.

Suma – výnos fond.

===== Interný doklad na konci =====
Účtuje a generuje sa rovnako ako v riadnom a fondovom faktoringu.

[[category:PTP (person to person)]]

Súbor:NF2.png

2024-04-12T06:17:17Z

Roman.adamjak:

Súbor:NF1.png

2024-04-12T06:17:05Z

Roman.adamjak:

Nákupný faktoring

2024-04-12T06:16:14Z

Roman.adamjak: Vytvorená stránka „KTFINANCE-1571 Nákupný faktoring === Okno Faktoring === ''P2P – Úhrady – šípka – okno Faktoring'' '''Doplnenie kariet Sadzby odmeny, Nákupný faktoring'''…“

KTFINANCE-1571 Nákupný faktoring

=== Okno Faktoring ===

''P2P – Úhrady – šípka – okno Faktoring''

'''Doplnenie kariet Sadzby odmeny, Nákupný faktoring'''

[[Image:]]

===== Karta Sadzby odmeny =====
ICO – vyberač z číselníka firiem

Názov firmy – zobrazenie

Dni omeškania – number počet dní

Odmena - %odmeny za nákupný faktoring

===== Karta Nákupný faktoring =====
Podobne ako v Nastavení

[[Image:]]

=== Úpravy akcií v okne Faktoring ===

===== Úprava importu =====
Pri importe nákupného faktoringu – typ N sa budú počítať 5 možných odmien. Ak zaplatí včase do prvého intervalu bude to hodnota nižšia ako pre druhý interval. Ak nebude existovať pre danú firmu žiadna sadzba vyhlásiť chybu: Pre danú firmu musí byť zadaná minimálne jedna hodnota odmeny.

Doplniť do okna Faktoring 5 stĺpcov: Odmena1, Odmena2, Odmena3, Odmena4, Odmena5.

Systém vypočíta toľko odmien, koľko bude mať sadzbie – max. 5.

Príklad:

{| border="1"
|'''Počet dní'''
|'''Istina'''
|'''%'''
|'''Suma'''
|-

|20
|1000
|1,2
|12
|-

|30
|1000
|2
|20
|-

|40
|1000
|2,3
|23
|-

|50
|1000
|2,5
|25
|-

|999
|1000
|3,5
|35
|}

Výpočet odmeny – istina* sadzba

Ak bude splnená splatnosť od počet dní prvej skupiny – čo bude zrejme do splatnosti. Predávajúci musí zaplatiť okrem istiny aj hodnotu odmeny.

===== Úprava akcie Generovanie dokladov =====
Vybavenie nastáva, ak bude sedieť zaplatená suma – istina + odmena pre interval zadaný v karte Sadzby odmeny. Suma vypočítaná v odmene je minimálna, ak bude prekročenie je to splnenie podmienok.

Príklad:

Ak vychádzame z príkladu na istinu 1000,-- a možné odmeny 12,20,23,25,35. Faktúra bola uhradená do 20 dní a má úhradu 1012, tak začína generovanie dokladov, ak nie

===== Výpočet ostatných hodnôt =====
Fond sa počíta rovnako ako pre riadny a fondový. Max však do výšky odmeny.

Interný výnos je rozdiel Úhrada – istina – odmena.

Príklad:

{| border="1"
|Odmeny
|

|

|

|-

|Počet dní
|Istina
|%
|Suma
|-

|20
|1000
|1,2
|12
|-

|30
|1000
|2
|20
|-

|40
|1000
|2,3
|23
|-

|50
|1000
|2,5
|25
|-

|999
|1000
|3,5
|35
|-

|

|

|

|

|}

{| border="1"
|Príklad
|'''Platič 1'''
|'''Platič odmena2'''
|-

|Suma faktúry
|1000
|1000
|-

|%1 splatky
|100
|100
|-

|Istina
|1000
|1000
|-

|Odmena %
|1,2
|2
|-

|Suma odmeny
|12
|20
|-

|Datum aktivacie
|2.5.2023
|1.3.2023
|-

|Datum splatnosti
|15.5.2023
|15.3.2023
|-

|Dátum úhrady
|3.5.2023
|25.3.2023
|-

|Denna sadzba_platič
|0,164383562
|0,17260274
|-

|Denna sadzba_neplatič
|

|0,215753425
|-

|%fond
|5
|4
|-

|%overboard
|1
|2,3
|-

|%neplatič
|3
|1,25
|-

|Vynos fond
|0,328767123
|4,746575342
|-

|Vynos interny
|11,67123288
|7,253424658
|-

|Suma úhrady
|1012
|1012
|}

=== Generovanie dokladov ===

===== Interný doklad na začiatku =====
Z nastavenia pre Nákupný faktoring.

Účtuje a generuje sa rovnako ako v riadnom a fondovom faktoringu.

===== Výnosová faktúra =====
Z nastavenia pre Nákupný faktoring.

Rovnako ako v riadnom a fondovom faktoringu.

Suma = výnos interný.

Výpočet : Suma úhrady-suma faktury-výnos fond

===== Nákladová faktúra =====
Z nastavenia pre Nákupný faktoring.

Suma – výnos fond.

===== Interný doklad na konci =====
Účtuje a generuje sa rovnako ako v riadnom a fondovom faktoringu.

[[category:PTP (person to person)]]

Evidencia/zápis zmlúv pre FOP do Spinu

2024-04-11T12:40:14Z

Roman.adamjak:

ZSPINCFH-12583
== Návrh Dátový model ==
=== Nová tabuľka LEA_STATUTAR: ===

'''LEA_STATUTAR'''

{| border="1"
|'''Stlpec názov'''
|'''TYP'''
|'''nullable'''
|'''popis'''
|-

|ZAKAZNIK_ID
|integer
|N
|FK lea_zakaznik
|-

|OSOBA_ID
|integer
|N
|FK dl_osoba
|-

|CIS_ID
|integer
|A
|

|-

|RODNE_CISLO
|Varchar(10)
|N
|

|-

|CISLO_OP
|Varchar2(10)
|N
|

|-

|''PLATNOST_DO''
|''Date''
|''A''
|

|-

|

|

|

|

|}

=== Rozšírenie tabuľky LEA_TYP_ZAKAZNIKA ===

{| border="1"
|'''Stlpec názov'''
|'''TYP'''
|'''nullable'''
|'''popis'''
|-

|TYP_FIRMY_ID
|integer
|A
|TYP_FIRMY_ID
|}

=== Rošírenie Číselníka typy zákazníkov ===

Do číselníka pridáme možnosť vybrať typ firmy z číselníka Firma->Typy firiem

[[Image:FOP1.png]]

=== Nová záložka Štatutár: ===

Záložka sa bude zobrazovať v oknách Zákaznik evidencia, Zaevidovanie Quatro, Správa zmluvy

Záložka bude aktívna len pre typ zákazníka, ktorý ma väzbu na typ firmy.

Záložka bude mať polia:

CIS_IS, Rodné číslo, meno, priezvisko, Číslo OP

adresa trvalého bydliska štatutára ( ulica, súpisne číslo, popisné číslo, PSČ, Obec, štát),

Platnosť do (Číslo OP),

kontaktné údaje – tel.č. a mailová adresa

Nepovinný údaj - CIS_ID

[[Image:FOP2.png]]

'''Popis:'''

Ak sa vyberie rodné číslo, ktoré existuje v databáze zákazníkov, tak sa všetky hodnoty pred plnia a môžu sa meniť. Zápisom sa zmení aj existujúci zákazník.

Ak sa použije rodné číslo, ktoré neexistuje v databáze zákazníkov, vtedy obsluha vyplní všetky povinné údaje.

Štatutár sa zapíše do číselníka osoba: nove osoba_id, Meno, Priezvisko, Adresy, A do tabuľky LEA_STATUTAR zapíšeme:

OSOBA_ID

CIS_ID

RODNE_CISLO

CISLO_OP

PLATNOST_DO

Osoba- štatutár bude mať väzbu aj na firmu dl_osoba.firma_id

1) ''Štatutár nie je zákazníkom( neexistuje LEA_ZAKAZNIK kde zakaznik_id=osoba_id)''
''V tomto prípade sa zobrazujú údaje z tabuly '''''''lea_statutar'''''

1) ''Štatutár je zákazníkom(existuje LEA_ZAKAZNIK kde zakaznik_id=osoba_id''
''V tomto prípade sa zobrazujú údaje z tabuly '''''''lea_zakazník'''''

== Evidovanie zákazníka ==
=== Okno Zaevidovanie quatro ===

Ak sa pri zaevidovaní zákazníka vyberie typ zákazníka, ktorý bude mat väzbu aj na typ firmy, tak sa súčasne založí aj firma do evidencie firiem(Spoločné->Firma) a v osobe sa spraví prepojenie na túto firmu dl_osoba.firma_id.

=== '''Okno zaevidovanie quatro – formulár''' ===

, ak sa vyberie taký typ zákazníka, ktorý má väzbu na typ firmy,

tak sa zobrazia polia pre zaevidovanie firmy:

Názov firmy, IČO, DIČ, IČ DPH.

Trvalá adresa ->Sídlo firmy

Telefón a email povinné

Súčasná adresa -> Korešpondenčná adresa

Do interného kódu firmy sa zapíše IČO

[[Image:FOP3.png]]

Osoba sa založí s priezviskom, kde bude názov firmy max 30 znakov.

'''IČO zapíšeme aj do lea_zakaznik.rodne_cislo, lea_zakaznik.ico, aby bolo možne v rôznych oknách zachovať vyberače na rodné čislo.'''

'''DIČ zapíšeme aj do lea_zakazník.dic'''

1) Firma sa zapíše aj k zákazníkovi do lea_zakaznik.firma_id
1) Všetky informácie budeme ale naďalej zapisovať k osobe (adresy, spojenia, bankové účty).
1) Na firmu zapísané len zakladane informácie o firme IČO,DIČ,IČ DPH, typ firmy, Názov firmy.
1) Adresa trvale bydlisko na osobe bude teda Sídelná adresa
1) A prechodné bydlisko bude korešpondenčná adresa.

Schované budú celé časti časti o:

Zamestnávateľ, Potvrdenie zamestnávateľa o prijme, Ostatné

=== Záložku editácia pre FOP ===

Záložka bude upravená rovnako ako formulár pre zaevidovanie zákazníka vykresľovanie polí vo formulári bude závisieť od typu zákazníka.

== Uprava okna Zákazník- evidencia. ==
=== Záložka - zákazník ===

Do záložky zákazník pridáme stĺpce: Názov firmy, I

Dph, ktoré budú zobrazovať dáta z firmy a to len v prípade, keď, na tabuľke lea_zakaznik stĺpec firma_id nebude prázdna hodnota.

Informácie o zamestnávateľovi ponecháme.

=== Záložka - zmluvy ===

Zobrazovať budeme zmluvy, ktoré patria zákazníkovi na ktorom je kurzor (pôvodne)

a súčasne, ak zákazník na ktorom je kurzor existuje v tabuľke lea_statutar stĺpec zakaznik_id,

tak sa zobrazia aj zmluvy zo zákazníka, kde lea_statutat.osoba_id=lea_zakaznik.zakaznik_id

a súčasne, ak zákazník, na ktorom je kurzor sa nachádza v tabuľke lea_statutar stĺpec osoba_id získa sa zakaznik_id a zobrazia sa zmluvy aj pre tohto zákazníka_id.

Cieľom je, aby sa na zákazníkovi zobrazovali jeho zmluvy, ale aj zmluvy na ktorých je štatutár, resp. aj zmluvy, ktoré sú na štatutárovi.

=== Záložky -adresa, spojenia, Bankové účty Marketingové údaje ===

Bez zmeny - všetky tieto záložky majú väzbu na osobu

=== Okno zákazník - informácie ===

Uprava okna - Nebude predmetom tejto poziadavky

== Okno správa zmluvy ==
=== Záložka Zákazník ===

Ak bude na zmluve typ zákazníka s väzbou na typ firmy, vtedy zobrazíme informácie o firme.

Políčko IČO bude vyberač zo zákazníkov, ktorí majú vyplnené lea_zakaznik.firma_id

[[Image:FOP4.png]]

=== Záložka editácia ===

Správa zmluvy-> Editácia rovnako ako pre okno zákazník evidencia – zobrazene závisí od typu zákazníka.

== Zápis FOP a FON cez služby ==Rozšírime službu post '''client''' o údaje potrebne pre zápis FOP A FON

Do hlavnej sekcie pre klienta pridáme

Nové Atribúty:

'''''Client''''''': {''

''companyName: názov firmy''

''idNumber: i''

''o''

''TaxIDNumber: di''

''VATIDNumber: i''

''dph''

Vytoríme podsekciu v klientovi

S nazvom

'''StatutoryOfficer'''

{StatutoryCisId

StatutoryName

StatutorySurname

StatutoryPin

StatutoryidCardNumber

StatutoryEmail

StatutoryMobile

Statutory adresa1

Statutory city

Statutory zipCode

StatutorycountryCode

}

=== Popis k zapisu statutara: ===

''ak príde ''StatutoryCisId = ''null alebo príde ''StatutoryCisId''s takou hodnotou, ktorá sa nenachádza v tabuľke zákazníkov a ostatné údaje pre statutára sú vyplnené tak sa zakladá nová osoba dl_osoba a tato osoba sa zapíše do tabuľky lea_statutár (stĺpec osoba_id+ plus ďalšie doplnkové údaje k štatutárovi)''

''ak príde ''StatutoryCisId'' vyplnené a existuje zákazník s týmto CIS_ID, tak sa vyhľadá zákazník s týmto CIS_ID a založí sa záznam do tabuľky lea_statutar s osoba_id =zakaznik_id(tento zákazník podľa vyhľadaného CIS_ID) a zaktualizuje sa priamo zákazníka s rovnakým CIS_ID ostatne údaje v tomto prípade už nezapisujeme do tabuľky štatutár (pre zobrazenie v okne budú hodnoty preberané zo zákazníka)''

''Pre zápis klienta FON pridáme kontrolu, ''

''i nová osoba sa už nenachádza ako štatutár –''

''kontrola na základe rodného čísla.''

''Ak sa nájde zhoda že už existuje taký štatutár ako zákazník FON ktorý sa aktuálne vytvára, tak sa prevezme jeho osoba_id a založí zakaznik_id s týmto osoba_id, týmto sa doplní väzba medzi štatutárom a zákazníkom FON ktorý vzniká.''

=== Popis k zápisu Firmy: ===

A typ zákazníka clientType príde hodnota, ktorá má v číselníku väzbu na typ firmy

Potom sú povinne tieto údaje:

companyName

idNumber

TaxIDNumber

''Nepovinné''

VATIDNumber

Spin na základe týchto údajov zakladá štandardne osobu zákazníka

Address{} zapis do osoby

Contacts{} zápis do osoby

a zároveň aj Firmu s údajmi (companyName

idNumber

TaxIDNumber

''Nepovinné''

VATIDNumber,

== GDPR – odpojenie FOP ==
=== AKCIE ===

Odpojenie zmlúv - bez zmeny - pri realizácii sa zmení zákazník, za toho v nastavení

a na pôvodnom zákazníkovi sa nastaví dátum odpojenia poslednej zmluvy.

Anonymizácia klienta – návrh bez zmeny vyhodnocovať sa bude, dátum odpojenia poslednej zmluvy na zákazníka

'''Realizácia'''''' –''' pri realizácii sa vymažú údaje z tabuľky lea_statutar pre zákazníka FOP ktorý sa anonymizuje, zruší sa väzba dl_osoba.firma_id ,lea_zakaznik.firma_id pre zákazníka FOP,

ak na firmu neexistuje ďalšia väzba na inú osobu, alebo zákazníka tak sa pokúsime vymazať firmu.

Ak sa firmu nepodarí vymazať z dôvodu väzby na nejaký doklad (faktúra), vtedy firmu zachováme a vyplníme dátum platnosti do na sysdate a pokračujeme štandardne, vymazáva sa zákazník a nakoniec osoba.

''kontrola pri vytváraní návrhu, ak pre zákazníka FON existuje záznam v tabuľke Štatutár tak zákazník nepadane ani do návrhu.(najprv musí dôjsť k anonymizácii FOP a až v ďalšej dávke k anonymizacii FON, keď nebude existovať FON ako štatutár)''

== Úprava Služby na doplŇanie chýbajucich CIS ==
Aktuálne procedúra '''pklea4VUB.pDoplnenieChybajucichCisId''' funguje tak že pre všetkých zákazníkov ktorým chyba cis_id . vyhľadáva v bankovej službe.

Procedúru upravíme, aby dopĺňala chýbajúce CIS aj pre štatutárov, čiže posielať budeme rodné číslo, také kde chýba CIS_ID z tabuľky lea_statutar.

== Online úprava DáT pre štatutára ==

Aktualizácia údajov pre FOP nebude predmetom tejto požiadavky

Aktuálna funkcionalita upravuje len zákazníkov FON.

Ak bude štatutár súčasne aj zákazník FON vtedy to funguje povodne cez CIS_ID sa upraví zákazníka po starom.

Môže ale nastať situácia, že vy systéme SPIN bude osoba zaevidovaná len ako štatutár nie ako zákazník a dôjde u aktualizácii údajov pravé na štatutára.

Upravíme funkcie, aby pre aktualizáciu nevyhľadávalo CIS_ID len z lea_zakaznik ale v prípade ak CIS_ID nenajde v tabulke lea_zakaznik, tak hľadá aj v tabuľke lea_statutar.

Zaktualizujeme informácie len k osobe nie k zákazníkovi.

Niektoré informácie, ktoré si zapisujeme k zákazníkovi napr: rodinny_stav tak si ich aktuálne nemáme kde zapísať, keďže zákazník neexistuje, tak ich aktualizáciu preskočíme.

Dotknuté funkcie:

pklea4VUB.FCUSTOMERCI

pklea4VUB.FCUSTOMERPI

pklea4vub.fcisdupdate - Upravíme službu aby menila kontrolovala aj cis_id na štatutárovi.

== DWH ==
Nová tabuľka

'''J_LEA_STATUTAR'''

{| border="1"
|'''Stlpec názov'''
|'''TYP'''
|'''nullable'''
|-

|ZAKAZNIK_ID
|integer
|N
|-

|OSOBA_ID
|integer
|N
|-

|CIS_ID
|integer
|A
|-

|RODNE_CISLO
|Varchar(10)
|N
|-

|CISLO_OP
|Varchar2(10)
|N
|-

|''PLATNOST_DO''
|''Date''
|''A''
|-

|''J_DATUM''
|''date''
|''N''
|-

|''J_TYP''
|''Char''
|''N''
|-

|''J_ID''
|''integer''
|''N''
|}

Rožširenie tabuľky '''J_LEA_TYP_ZAKAZNIKA'''

{| border="1"
|TYP_FIRMY_ID
|integer
|A
|}

[[category:Leasing]]

Súbor:FOP4.png

2024-04-11T12:38:54Z

Roman.adamjak:

Súbor:FOP3.png

2024-04-11T12:38:21Z

Roman.adamjak:

Súbor:FOP2.png

2024-04-11T12:38:09Z

Roman.adamjak:

Súbor:FOP1.png

2024-04-11T12:37:55Z

Roman.adamjak:

Evidencia/zápis zmlúv pre FOP do Spinu

2024-04-11T12:35:55Z

Roman.adamjak:

ZSPINCFH-12583
== Návrh Dátový model ==
=== Nová tabuľka LEA_STATUTAR: ===

'''LEA_STATUTAR'''

{| border="1"
|'''Stlpec názov'''
|'''TYP'''
|'''nullable'''
|'''popis'''
|-

|ZAKAZNIK_ID
|integer
|N
|FK lea_zakaznik
|-

|OSOBA_ID
|integer
|N
|FK dl_osoba
|-

|CIS_ID
|integer
|A
|

|-

|RODNE_CISLO
|Varchar(10)
|N
|

|-

|CISLO_OP
|Varchar2(10)
|N
|

|-

|''PLATNOST_DO''
|''Date''
|''A''
|

|-

|

|

|

|

|}

=== Rozšírenie tabuľky LEA_TYP_ZAKAZNIKA ===

{| border="1"
|'''Stlpec názov'''
|'''TYP'''
|'''nullable'''
|'''popis'''
|-

|TYP_FIRMY_ID
|integer
|A
|TYP_FIRMY_ID
|}

=== Rošírenie Číselníka typy zákazníkov ===

Do číselníka pridáme možnosť vybrať typ firmy z číselníka Firma->Typy firiem

[[Image:]]

=== Nová záložka Štatutár: ===

Záložka sa bude zobrazovať v oknách Zákaznik evidencia, Zaevidovanie Quatro, Správa zmluvy

Záložka bude aktívna len pre typ zákazníka, ktorý ma väzbu na typ firmy.

Záložka bude mať polia:

CIS_IS, Rodné číslo, meno, priezvisko, Číslo OP

adresa trvalého bydliska štatutára ( ulica, súpisne číslo, popisné číslo, PSČ, Obec, štát),

Platnosť do (Číslo OP),

kontaktné údaje – tel.č. a mailová adresa

Nepovinný údaj - CIS_ID

[[Image:]]

'''Popis:'''

Ak sa vyberie rodné číslo, ktoré existuje v databáze zákazníkov, tak sa všetky hodnoty pred plnia a môžu sa meniť. Zápisom sa zmení aj existujúci zákazník.

Ak sa použije rodné číslo, ktoré neexistuje v databáze zákazníkov, vtedy obsluha vyplní všetky povinné údaje.

Štatutár sa zapíše do číselníka osoba: nove osoba_id, Meno, Priezvisko, Adresy, A do tabuľky LEA_STATUTAR zapíšeme:

OSOBA_ID

CIS_ID

RODNE_CISLO

CISLO_OP

PLATNOST_DO

Osoba- štatutár bude mať väzbu aj na firmu dl_osoba.firma_id

1) ''Štatutár nie je zákazníkom( neexistuje LEA_ZAKAZNIK kde zakaznik_id=osoba_id)''
''V tomto prípade sa zobrazujú údaje z tabuly '''''''lea_statutar'''''

1) ''Štatutár je zákazníkom(existuje LEA_ZAKAZNIK kde zakaznik_id=osoba_id''
''V tomto prípade sa zobrazujú údaje z tabuly '''''''lea_zakazník'''''

== Evidovanie zákazníka ==
=== Okno Zaevidovanie quatro ===

Ak sa pri zaevidovaní zákazníka vyberie typ zákazníka, ktorý bude mat väzbu aj na typ firmy, tak sa súčasne založí aj firma do evidencie firiem(Spoločné->Firma) a v osobe sa spraví prepojenie na túto firmu dl_osoba.firma_id.

=== '''Okno zaevidovanie quatro – formulár''' ===

, ak sa vyberie taký typ zákazníka, ktorý má väzbu na typ firmy,

tak sa zobrazia polia pre zaevidovanie firmy:

Názov firmy, IČO, DIČ, IČ DPH.

Trvalá adresa ->Sídlo firmy

Telefón a email povinné

Súčasná adresa -> Korešpondenčná adresa

Do interného kódu firmy sa zapíše IČO

[[Image:]]

Osoba sa založí s priezviskom, kde bude názov firmy max 30 znakov.

'''IČO zapíšeme aj do lea_zakaznik.rodne_cislo, lea_zakaznik.ico, aby bolo možne v rôznych oknách zachovať vyberače na rodné čislo.'''

'''DIČ zapíšeme aj do lea_zakazník.dic'''

1) Firma sa zapíše aj k zákazníkovi do lea_zakaznik.firma_id
1) Všetky informácie budeme ale naďalej zapisovať k osobe (adresy, spojenia, bankové účty).
1) Na firmu zapísané len zakladane informácie o firme IČO,DIČ,IČ DPH, typ firmy, Názov firmy.
1) Adresa trvale bydlisko na osobe bude teda Sídelná adresa
1) A prechodné bydlisko bude korešpondenčná adresa.

Schované budú celé časti časti o:

Zamestnávateľ, Potvrdenie zamestnávateľa o prijme, Ostatné

=== Záložku editácia pre FOP ===

Záložka bude upravená rovnako ako formulár pre zaevidovanie zákazníka vykresľovanie polí vo formulári bude závisieť od typu zákazníka.

== Uprava okna Zákazník- evidencia. ==
=== Záložka - zákazník ===

Do záložky zákazník pridáme stĺpce: Názov firmy, I

Dph, ktoré budú zobrazovať dáta z firmy a to len v prípade, keď, na tabuľke lea_zakaznik stĺpec firma_id nebude prázdna hodnota.

Informácie o zamestnávateľovi ponecháme.

=== Záložka - zmluvy ===

Zobrazovať budeme zmluvy, ktoré patria zákazníkovi na ktorom je kurzor (pôvodne)

a súčasne, ak zákazník na ktorom je kurzor existuje v tabuľke lea_statutar stĺpec zakaznik_id,

tak sa zobrazia aj zmluvy zo zákazníka, kde lea_statutat.osoba_id=lea_zakaznik.zakaznik_id

a súčasne, ak zákazník, na ktorom je kurzor sa nachádza v tabuľke lea_statutar stĺpec osoba_id získa sa zakaznik_id a zobrazia sa zmluvy aj pre tohto zákazníka_id.

Cieľom je, aby sa na zákazníkovi zobrazovali jeho zmluvy, ale aj zmluvy na ktorých je štatutár, resp. aj zmluvy, ktoré sú na štatutárovi.

=== Záložky -adresa, spojenia, Bankové účty Marketingové údaje ===

Bez zmeny - všetky tieto záložky majú väzbu na osobu

=== Okno zákazník - informácie ===

Uprava okna - Nebude predmetom tejto poziadavky

== Okno správa zmluvy ==
=== Záložka Zákazník ===

Ak bude na zmluve typ zákazníka s väzbou na typ firmy, vtedy zobrazíme informácie o firme.

Políčko IČO bude vyberač zo zákazníkov, ktorí majú vyplnené lea_zakaznik.firma_id

[[Image:]]

=== Záložka editácia ===

Správa zmluvy-> Editácia rovnako ako pre okno zákazník evidencia – zobrazene závisí od typu zákazníka.

== Zápis FOP a FON cez služby ==Rozšírime službu post '''client''' o údaje potrebne pre zápis FOP A FON

Do hlavnej sekcie pre klienta pridáme

Nové Atribúty:

'''''Client''''''': {''

''companyName: názov firmy''

''idNumber: i''

''o''

''TaxIDNumber: di''

''VATIDNumber: i''

''dph''

Vytoríme podsekciu v klientovi

S nazvom

'''StatutoryOfficer'''

{StatutoryCisId

StatutoryName

StatutorySurname

StatutoryPin

StatutoryidCardNumber

StatutoryEmail

StatutoryMobile

Statutory adresa1

Statutory city

Statutory zipCode

StatutorycountryCode

}

=== Popis k zapisu statutara: ===

''ak príde ''StatutoryCisId = ''null alebo príde ''StatutoryCisId''s takou hodnotou, ktorá sa nenachádza v tabuľke zákazníkov a ostatné údaje pre statutára sú vyplnené tak sa zakladá nová osoba dl_osoba a tato osoba sa zapíše do tabuľky lea_statutár (stĺpec osoba_id+ plus ďalšie doplnkové údaje k štatutárovi)''

''ak príde ''StatutoryCisId'' vyplnené a existuje zákazník s týmto CIS_ID, tak sa vyhľadá zákazník s týmto CIS_ID a založí sa záznam do tabuľky lea_statutar s osoba_id =zakaznik_id(tento zákazník podľa vyhľadaného CIS_ID) a zaktualizuje sa priamo zákazníka s rovnakým CIS_ID ostatne údaje v tomto prípade už nezapisujeme do tabuľky štatutár (pre zobrazenie v okne budú hodnoty preberané zo zákazníka)''

''Pre zápis klienta FON pridáme kontrolu, ''

''i nová osoba sa už nenachádza ako štatutár –''

''kontrola na základe rodného čísla.''

''Ak sa nájde zhoda že už existuje taký štatutár ako zákazník FON ktorý sa aktuálne vytvára, tak sa prevezme jeho osoba_id a založí zakaznik_id s týmto osoba_id, týmto sa doplní väzba medzi štatutárom a zákazníkom FON ktorý vzniká.''

=== Popis k zápisu Firmy: ===

A typ zákazníka clientType príde hodnota, ktorá má v číselníku väzbu na typ firmy

Potom sú povinne tieto údaje:

companyName

idNumber

TaxIDNumber

''Nepovinné''

VATIDNumber

Spin na základe týchto údajov zakladá štandardne osobu zákazníka

Address{} zapis do osoby

Contacts{} zápis do osoby

a zároveň aj Firmu s údajmi (companyName

idNumber

TaxIDNumber

''Nepovinné''

VATIDNumber,

== GDPR – odpojenie FOP ==
=== AKCIE ===

Odpojenie zmlúv - bez zmeny - pri realizácii sa zmení zákazník, za toho v nastavení

a na pôvodnom zákazníkovi sa nastaví dátum odpojenia poslednej zmluvy.

Anonymizácia klienta – návrh bez zmeny vyhodnocovať sa bude, dátum odpojenia poslednej zmluvy na zákazníka

'''Realizácia'''''' –''' pri realizácii sa vymažú údaje z tabuľky lea_statutar pre zákazníka FOP ktorý sa anonymizuje, zruší sa väzba dl_osoba.firma_id ,lea_zakaznik.firma_id pre zákazníka FOP,

ak na firmu neexistuje ďalšia väzba na inú osobu, alebo zákazníka tak sa pokúsime vymazať firmu.

Ak sa firmu nepodarí vymazať z dôvodu väzby na nejaký doklad (faktúra), vtedy firmu zachováme a vyplníme dátum platnosti do na sysdate a pokračujeme štandardne, vymazáva sa zákazník a nakoniec osoba.

''kontrola pri vytváraní návrhu, ak pre zákazníka FON existuje záznam v tabuľke Štatutár tak zákazník nepadane ani do návrhu.(najprv musí dôjsť k anonymizácii FOP a až v ďalšej dávke k anonymizacii FON, keď nebude existovať FON ako štatutár)''

== Úprava Služby na doplŇanie chýbajucich CIS ==
Aktuálne procedúra '''pklea4VUB.pDoplnenieChybajucichCisId''' funguje tak že pre všetkých zákazníkov ktorým chyba cis_id . vyhľadáva v bankovej službe.

Procedúru upravíme, aby dopĺňala chýbajúce CIS aj pre štatutárov, čiže posielať budeme rodné číslo, také kde chýba CIS_ID z tabuľky lea_statutar.

== Online úprava DáT pre štatutára ==

Aktualizácia údajov pre FOP nebude predmetom tejto požiadavky

Aktuálna funkcionalita upravuje len zákazníkov FON.

Ak bude štatutár súčasne aj zákazník FON vtedy to funguje povodne cez CIS_ID sa upraví zákazníka po starom.

Môže ale nastať situácia, že vy systéme SPIN bude osoba zaevidovaná len ako štatutár nie ako zákazník a dôjde u aktualizácii údajov pravé na štatutára.

Upravíme funkcie, aby pre aktualizáciu nevyhľadávalo CIS_ID len z lea_zakaznik ale v prípade ak CIS_ID nenajde v tabulke lea_zakaznik, tak hľadá aj v tabuľke lea_statutar.

Zaktualizujeme informácie len k osobe nie k zákazníkovi.

Niektoré informácie, ktoré si zapisujeme k zákazníkovi napr: rodinny_stav tak si ich aktuálne nemáme kde zapísať, keďže zákazník neexistuje, tak ich aktualizáciu preskočíme.

Dotknuté funkcie:

pklea4VUB.FCUSTOMERCI

pklea4VUB.FCUSTOMERPI

pklea4vub.fcisdupdate - Upravíme službu aby menila kontrolovala aj cis_id na štatutárovi.

== DWH ==
Nová tabuľka

'''J_LEA_STATUTAR'''

{| border="1"
|'''Stlpec názov'''
|'''TYP'''
|'''nullable'''
|-

|ZAKAZNIK_ID
|integer
|N
|-

|OSOBA_ID
|integer
|N
|-

|CIS_ID
|integer
|A
|-

|RODNE_CISLO
|Varchar(10)
|N
|-

|CISLO_OP
|Varchar2(10)
|N
|-

|''PLATNOST_DO''
|''Date''
|''A''
|-

|''J_DATUM''
|''date''
|''N''
|-

|''J_TYP''
|''Char''
|''N''
|-

|''J_ID''
|''integer''
|''N''
|}

Rožširenie tabuľky '''J_LEA_TYP_ZAKAZNIKA'''

{| border="1"
|TYP_FIRMY_ID
|integer
|A
|}

[[category:Leasing]]

Evidencia/zápis zmlúv pre FOP do Spinu

2024-04-11T12:33:08Z

Roman.adamjak:

ZSPINCFH-12583
== Návrh Dátový model ==
=== Nová tabuľka LEA_STATUTAR: ===

'''LEA_STATUTAR'''

{| border="1"
|'''Stlpec názov'''
|'''TYP'''
|'''nullable'''
|'''popis'''
|-

|ZAKAZNIK_ID
|integer
|N
|FK lea_zakaznik
|-

|OSOBA_ID
|integer
|N
|FK dl_osoba
|-

|CIS_ID
|integer
|A
|

|-

|RODNE_CISLO
|Varchar(10)
|N
|

|-

|CISLO_OP
|Varchar2(10)
|N
|

|-

|''PLATNOST_DO''
|''Date''
|''A''
|

|-

|

|

|

|

|}

=== Rozšírenie tabuľky LEA_TYP_ZAKAZNIKA ===

{| border="1"
|'''Stlpec názov'''
|'''TYP'''
|'''nullable'''
|'''popis'''
|-

|TYP_FIRMY_ID
|integer
|A
|TYP_FIRMY_ID
|}

=== Rošírenie Číselníka typy zákazníkov ===

Do číselníka pridáme možnosť vybrať typ firmy z číselníka Firma->Typy firiem

[[Image:]]

=== Nová záložka Štatutár: ===

Záložka sa bude zobrazovať v oknách Zákaznik evidencia, Zaevidovanie Quatro, Správa zmluvy

Záložka bude aktívna len pre typ zákazníka, ktorý ma väzbu na typ firmy.

Záložka bude mať polia:

CIS_IS, Rodné číslo, meno, priezvisko, Číslo OP

adresa trvalého bydliska štatutára ( ulica, súpisne číslo, popisné číslo, PSČ, Obec, štát),

Platnosť do (Číslo OP),

kontaktné údaje – tel.č. a mailová adresa

Nepovinný údaj - CIS_ID

[[Image:]]

'''Popis:'''

Ak sa vyberie rodné číslo, ktoré existuje v databáze zákazníkov, tak sa všetky hodnoty pred plnia a môžu sa meniť. Zápisom sa zmení aj existujúci zákazník.

Ak sa použije rodné číslo, ktoré neexistuje v databáze zákazníkov, vtedy obsluha vyplní všetky povinné údaje.

Štatutár sa zapíše do číselníka osoba: nove osoba_id, Meno, Priezvisko, Adresy, A do tabuľky LEA_STATUTAR zapíšeme:

OSOBA_ID

CIS_ID

RODNE_CISLO

CISLO_OP

PLATNOST_DO

Osoba- štatutár bude mať väzbu aj na firmu dl_osoba.firma_id

1) ''Štatutár nie je zákazníkom( neexistuje LEA_ZAKAZNIK kde zakaznik_id=osoba_id)''
''V tomto prípade sa zobrazujú údaje z tabuly '''''''lea_statutar'''''

1) ''Štatutár je zákazníkom(existuje LEA_ZAKAZNIK kde zakaznik_id=osoba_id''
''V tomto prípade sa zobrazujú údaje z tabuly '''''''lea_zakazník'''''

== Evidovanie zákazníka ==
=== Okno Zaevidovanie quatro ===

Ak sa pri zaevidovaní zákazníka vyberie typ zákazníka, ktorý bude mat väzbu aj na typ firmy, tak sa súčasne založí aj firma do evidencie firiem(Spoločné->Firma) a v osobe sa spraví prepojenie na túto firmu dl_osoba.firma_id.

=== '''Okno zaevidovanie quatro – formulár''' ===

, ak sa vyberie taký typ zákazníka, ktorý má väzbu na typ firmy,

tak sa zobrazia polia pre zaevidovanie firmy:

Názov firmy, IČO, DIČ, IČ DPH.

Trvalá adresa ->Sídlo firmy

Telefón a email povinné

Súčasná adresa -> Korešpondenčná adresa

Do interného kódu firmy sa zapíše IČO

[[Image:]]

Osoba sa založí s priezviskom, kde bude názov firmy max 30 znakov.

'''IČO zapíšeme aj do lea_zakaznik.rodne_cislo, lea_zakaznik.ico, aby bolo možne v rôznych oknách zachovať vyberače na rodné čislo.'''

'''DIČ zapíšeme aj do lea_zakazník.dic'''

1) Firma sa zapíše aj k zákazníkovi do lea_zakaznik.firma_id
1) Všetky informácie budeme ale naďalej zapisovať k osobe (adresy, spojenia, bankové účty).
1) Na firmu zapísané len zakladane informácie o firme IČO,DIČ,IČ DPH, typ firmy, Názov firmy.
1) Adresa trvale bydlisko na osobe bude teda Sídelná adresa
1) A prechodné bydlisko bude korešpondenčná adresa.

Schované budú celé časti časti o:

Zamestnávateľ, Potvrdenie zamestnávateľa o prijme, Ostatné

=== Záložku editácia pre FOP ===

Záložka bude upravená rovnako ako formulár pre zaevidovanie zákazníka vykresľovanie polí vo formulári bude závisieť od typu zákazníka.

== Uprava okna Zákazník- evidencia. ==
=== Záložka - zákazník ===

Do záložky zákazník pridáme stĺpce: Názov firmy, I

Dph, ktoré budú zobrazovať dáta z firmy a to len v prípade, keď, na tabuľke lea_zakaznik stĺpec firma_id nebude prázdna hodnota.

Informácie o zamestnávateľovi ponecháme.

=== Záložka - zmluvy ===

Zobrazovať budeme zmluvy, ktoré patria zákazníkovi na ktorom je kurzor (pôvodne)

a súčasne, ak zákazník na ktorom je kurzor existuje v tabuľke lea_statutar stĺpec zakaznik_id,

tak sa zobrazia aj zmluvy zo zákazníka, kde lea_statutat.osoba_id=lea_zakaznik.zakaznik_id

a súčasne, ak zákazník, na ktorom je kurzor sa nachádza v tabuľke lea_statutar stĺpec osoba_id získa sa zakaznik_id a zobrazia sa zmluvy aj pre tohto zákazníka_id.

Cieľom je, aby sa na zákazníkovi zobrazovali jeho zmluvy, ale aj zmluvy na ktorých je štatutár, resp. aj zmluvy, ktoré sú na štatutárovi.

=== Záložky -adresa, spojenia, Bankové účty Marketingové údaje ===

Bez zmeny - všetky tieto záložky majú väzbu na osobu

=== Okno zákazník - informácie ===

Uprava okna - Nebude predmetom tejto poziadavky

== Okno správa zmluvy ===== Záložka Zákazník ===

Ak bude na zmluve typ zákazníka s väzbou na typ firmy, vtedy zobrazíme informácie o firme.

Políčko IČO bude vyberač zo zákazníkov, ktorí majú vyplnené lea_zakaznik.firma_id

[[Image:]]

=== Záložka editácia ===

Správa zmluvy-> Editácia rovnako ako pre okno zákazník evidencia – zobrazene závisí od typu zákazníka.

== Zápis FOP a FON cez služby ==Rozšírime službu post '''client''' o údaje potrebne pre zápis FOP A FON

Do hlavnej sekcie pre klienta pridáme

Nové Atribúty:

'''''Client''''''': {''

''companyName: názov firmy''

''idNumber: i''

''o''

''TaxIDNumber: di''

''VATIDNumber: i''

''dph''

Vytoríme podsekciu v klientovi

S nazvom

'''StatutoryOfficer'''

{StatutoryCisId

StatutoryName

StatutorySurname

StatutoryPin

StatutoryidCardNumber

StatutoryEmail

StatutoryMobile

Statutory adresa1

Statutory city

Statutory zipCode

StatutorycountryCode

}

=== Popis k zapisu statutara: ===

''ak príde ''StatutoryCisId = ''null alebo príde ''StatutoryCisId''s takou hodnotou, ktorá sa nenachádza v tabuľke zákazníkov a ostatné údaje pre statutára sú vyplnené tak sa zakladá nová osoba dl_osoba a tato osoba sa zapíše do tabuľky lea_statutár (stĺpec osoba_id+ plus ďalšie doplnkové údaje k štatutárovi)''

''ak príde ''StatutoryCisId'' vyplnené a existuje zákazník s týmto CIS_ID, tak sa vyhľadá zákazník s týmto CIS_ID a založí sa záznam do tabuľky lea_statutar s osoba_id =zakaznik_id(tento zákazník podľa vyhľadaného CIS_ID) a zaktualizuje sa priamo zákazníka s rovnakým CIS_ID ostatne údaje v tomto prípade už nezapisujeme do tabuľky štatutár (pre zobrazenie v okne budú hodnoty preberané zo zákazníka)''

''Pre zápis klienta FON pridáme kontrolu, ''

''i nová osoba sa už nenachádza ako štatutár –''

''kontrola na základe rodného čísla.''

''Ak sa nájde zhoda že už existuje taký štatutár ako zákazník FON ktorý sa aktuálne vytvára, tak sa prevezme jeho osoba_id a založí zakaznik_id s týmto osoba_id, týmto sa doplní väzba medzi štatutárom a zákazníkom FON ktorý vzniká.''

=== Popis k zápisu Firmy: ===

A typ zákazníka clientType príde hodnota, ktorá má v číselníku väzbu na typ firmy

Potom sú povinne tieto údaje:

companyName

idNumber

TaxIDNumber

''Nepovinné''

VATIDNumber

Spin na základe týchto údajov zakladá štandardne osobu zákazníka

Address{} zapis do osoby

Contacts{} zápis do osoby

a zároveň aj Firmu s údajmi (companyName

idNumber

TaxIDNumber

''Nepovinné''

VATIDNumber,

== GDPR – odpojenie FOP ==
=== AKCIE ===

Odpojenie zmlúv - bez zmeny - pri realizácii sa zmení zákazník, za toho v nastavení

a na pôvodnom zákazníkovi sa nastaví dátum odpojenia poslednej zmluvy.

Anonymizácia klienta – návrh bez zmeny vyhodnocovať sa bude, dátum odpojenia poslednej zmluvy na zákazníka

'''Realizácia'''''' –''' pri realizácii sa vymažú údaje z tabuľky lea_statutar pre zákazníka FOP ktorý sa anonymizuje, zruší sa väzba dl_osoba.firma_id ,lea_zakaznik.firma_id pre zákazníka FOP,

ak na firmu neexistuje ďalšia väzba na inú osobu, alebo zákazníka tak sa pokúsime vymazať firmu.

Ak sa firmu nepodarí vymazať z dôvodu väzby na nejaký doklad (faktúra), vtedy firmu zachováme a vyplníme dátum platnosti do na sysdate a pokračujeme štandardne, vymazáva sa zákazník a nakoniec osoba.

''kontrola pri vytváraní návrhu, ak pre zákazníka FON existuje záznam v tabuľke Štatutár tak zákazník nepadane ani do návrhu.(najprv musí dôjsť k anonymizácii FOP a až v ďalšej dávke k anonymizacii FON, keď nebude existovať FON ako štatutár)''

== Úprava Služby na doplŇanie chýbajucich CIS ==
Aktuálne procedúra '''pklea4VUB.pDoplnenieChybajucichCisId''' funguje tak že pre všetkých zákazníkov ktorým chyba cis_id . vyhľadáva v bankovej službe.

Procedúru upravíme, aby dopĺňala chýbajúce CIS aj pre štatutárov, čiže posielať budeme rodné číslo, také kde chýba CIS_ID z tabuľky lea_statutar.

== Online úprava DáT pre štatutára ==

Aktualizácia údajov pre FOP nebude predmetom tejto požiadavky

Aktuálna funkcionalita upravuje len zákazníkov FON.

Ak bude štatutár súčasne aj zákazník FON vtedy to funguje povodne cez CIS_ID sa upraví zákazníka po starom.

Môže ale nastať situácia, že vy systéme SPIN bude osoba zaevidovaná len ako štatutár nie ako zákazník a dôjde u aktualizácii údajov pravé na štatutára.

Upravíme funkcie, aby pre aktualizáciu nevyhľadávalo CIS_ID len z lea_zakaznik ale v prípade ak CIS_ID nenajde v tabulke lea_zakaznik, tak hľadá aj v tabuľke lea_statutar.

Zaktualizujeme informácie len k osobe nie k zákazníkovi.

Niektoré informácie, ktoré si zapisujeme k zákazníkovi napr: rodinny_stav tak si ich aktuálne nemáme kde zapísať, keďže zákazník neexistuje, tak ich aktualizáciu preskočíme.

Dotknuté funkcie:

pklea4VUB.FCUSTOMERCI

pklea4VUB.FCUSTOMERPI

pklea4vub.fcisdupdate - Upravíme službu aby menila kontrolovala aj cis_id na štatutárovi.

== DWH ==
Nová tabuľka

'''J_LEA_STATUTAR'''

{| border="1"
|'''Stlpec názov'''
|'''TYP'''
|'''nullable'''
|-

|ZAKAZNIK_ID
|integer
|N
|-

|OSOBA_ID
|integer
|N
|-

|CIS_ID
|integer
|A
|-

|RODNE_CISLO
|Varchar(10)
|N
|-

|CISLO_OP
|Varchar2(10)
|N
|-

|''PLATNOST_DO''
|''Date''
|''A''
|-

|''J_DATUM''
|''date''
|''N''
|-

|''J_TYP''
|''Char''
|''N''
|-

|''J_ID''
|''integer''
|''N''
|}

Rožširenie tabuľky '''J_LEA_TYP_ZAKAZNIKA'''

{| border="1"
|TYP_FIRMY_ID
|integer
|A
|}

[[category:Leasing]]

Evidencia/zápis zmlúv pre FOP do Spinu

2024-04-11T12:30:38Z

Roman.adamjak: Vytvorená stránka „ ZSPINCFH-12583 == Návrh Dátový model ===== Nová tabuľka LEA_STATUTAR: === '''LEA_STATUTAR''' {| border="1" |'''Stlpec názov''' |'''TYP''' |'''nullable''' |'''po…“

ZSPINCFH-12583
== Návrh Dátový model ===== Nová tabuľka LEA_STATUTAR: ===

'''LEA_STATUTAR'''

{| border="1"
|'''Stlpec názov'''
|'''TYP'''
|'''nullable'''
|'''popis'''
|-

|ZAKAZNIK_ID
|integer
|N
|FK lea_zakaznik
|-

|OSOBA_ID
|integer
|N
|FK dl_osoba
|-

|CIS_ID
|integer
|A
|

|-

|RODNE_CISLO
|Varchar(10)
|N
|

|-

|CISLO_OP
|Varchar2(10)
|N
|

|-

|''PLATNOST_DO''
|''Date''
|''A''
|

|-

|

|

|

|

|}
=== ===

=== Rozšírenie tabuľky LEA_TYP_ZAKAZNIKA ===

{| border="1"
|'''Stlpec názov'''
|'''TYP'''
|'''nullable'''
|'''popis'''
|-

|TYP_FIRMY_ID
|integer
|A
|TYP_FIRMY_ID
|}
=== ===

=== Rošírenie Číselníka typy zákazníkov ===

Do číselníka pridáme možnosť vybrať typ firmy z číselníka Firma->Typy firiem

[[Image:]]

=== Nová záložka Štatutár: ===

Záložka sa bude zobrazovať v oknách Zákaznik evidencia, Zaevidovanie Quatro, Správa zmluvy

Záložka bude aktívna len pre typ zákazníka, ktorý ma väzbu na typ firmy.

Záložka bude mať polia:

CIS_IS, Rodné číslo, meno, priezvisko, Číslo OP

adresa trvalého bydliska štatutára ( ulica, súpisne číslo, popisné číslo, PSČ, Obec, štát),

Platnosť do (Číslo OP),

kontaktné údaje – tel.č. a mailová adresa

Nepovinný údaj - CIS_ID

[[Image:]]

'''Popis:'''

Ak sa vyberie rodné číslo, ktoré existuje v databáze zákazníkov, tak sa všetky hodnoty pred plnia a môžu sa meniť. Zápisom sa zmení aj existujúci zákazník.

Ak sa použije rodné číslo, ktoré neexistuje v databáze zákazníkov, vtedy obsluha vyplní všetky povinné údaje.

Štatutár sa zapíše do číselníka osoba: nove osoba_id, Meno, Priezvisko, Adresy, A do tabuľky LEA_STATUTAR zapíšeme:

OSOBA_ID

CIS_ID

RODNE_CISLO

CISLO_OP

PLATNOST_DO

Osoba- štatutár bude mať väzbu aj na firmu dl_osoba.firma_id

1) ''Štatutár nie je zákazníkom( neexistuje LEA_ZAKAZNIK kde zakaznik_id=osoba_id)''
''V tomto prípade sa zobrazujú údaje z tabuly '''''''lea_statutar'''''

1) ''Štatutár je zákazníkom(existuje LEA_ZAKAZNIK kde zakaznik_id=osoba_id''
''V tomto prípade sa zobrazujú údaje z tabuly '''''''lea_zakazník'''''

== Evidovanie zákazníka ===== Okno Zaevidovanie quatro ===

Ak sa pri zaevidovaní zákazníka vyberie typ zákazníka, ktorý bude mat väzbu aj na typ firmy, tak sa súčasne založí aj firma do evidencie firiem(Spoločné->Firma) a v osobe sa spraví prepojenie na túto firmu dl_osoba.firma_id.

=== '''Okno zaevidovanie quatro – formulár''' ===

, ak sa vyberie taký typ zákazníka, ktorý má väzbu na typ firmy,

tak sa zobrazia polia pre zaevidovanie firmy:

Názov firmy, IČO, DIČ, IČ DPH.

Trvalá adresa ->Sídlo firmy

Telefón a email povinné

Súčasná adresa -> Korešpondenčná adresa

Do interného kódu firmy sa zapíše IČO

[[Image:]]

Osoba sa založí s priezviskom, kde bude názov firmy max 30 znakov.

'''IČO zapíšeme aj do lea_zakaznik.rodne_cislo, lea_zakaznik.ico, aby bolo možne v rôznych oknách zachovať vyberače na rodné čislo.'''

'''DIČ zapíšeme aj do lea_zakazník.dic'''

1) Firma sa zapíše aj k zákazníkovi do lea_zakaznik.firma_id
1) Všetky informácie budeme ale naďalej zapisovať k osobe (adresy, spojenia, bankové účty).
1) Na firmu zapísané len zakladane informácie o firme IČO,DIČ,IČ DPH, typ firmy, Názov firmy.
1) Adresa trvale bydlisko na osobe bude teda Sídelná adresa
1) A prechodné bydlisko bude korešpondenčná adresa.

Schované budú celé časti časti o:

Zamestnávateľ, Potvrdenie zamestnávateľa o prijme, Ostatné

=== Záložku editácia pre FOP ===

Záložka bude upravená rovnako ako formulár pre zaevidovanie zákazníka vykresľovanie polí vo formulári bude závisieť od typu zákazníka.

== Uprava okna Zákazník- evidencia. ===== Záložka - zákazník ===

Do záložky zákazník pridáme stĺpce: Názov firmy, I

Dph, ktoré budú zobrazovať dáta z firmy a to len v prípade, keď, na tabuľke lea_zakaznik stĺpec firma_id nebude prázdna hodnota.

Informácie o zamestnávateľovi ponecháme.

=== Záložka - zmluvy ===

Zobrazovať budeme zmluvy, ktoré patria zákazníkovi na ktorom je kurzor (pôvodne)

a súčasne, ak zákazník na ktorom je kurzor existuje v tabuľke lea_statutar stĺpec zakaznik_id,

tak sa zobrazia aj zmluvy zo zákazníka, kde lea_statutat.osoba_id=lea_zakaznik.zakaznik_id

a súčasne, ak zákazník, na ktorom je kurzor sa nachádza v tabuľke lea_statutar stĺpec osoba_id získa sa zakaznik_id a zobrazia sa zmluvy aj pre tohto zákazníka_id.

Cieľom je, aby sa na zákazníkovi zobrazovali jeho zmluvy, ale aj zmluvy na ktorých je štatutár, resp. aj zmluvy, ktoré sú na štatutárovi.

=== Záložky -adresa, spojenia, Bankové účty Marketingové údaje ===

Bez zmeny - všetky tieto záložky majú väzbu na osobu

=== Okno zákazník - informácie ===

Uprava okna - Nebude predmetom tejto poziadavky

== Okno správa zmluvy ===== Záložka Zákazník ===

Ak bude na zmluve typ zákazníka s väzbou na typ firmy, vtedy zobrazíme informácie o firme.

Políčko IČO bude vyberač zo zákazníkov, ktorí majú vyplnené lea_zakaznik.firma_id

[[Image:]]

=== Záložka editácia ===

Správa zmluvy-> Editácia rovnako ako pre okno zákazník evidencia – zobrazene závisí od typu zákazníka.

== Zápis FOP a FON cez služby ==Rozšírime službu post '''client''' o údaje potrebne pre zápis FOP A FON

Do hlavnej sekcie pre klienta pridáme

Nové Atribúty:

'''''Client''''''': {''

''companyName: názov firmy''

''idNumber: i''

''o''

''TaxIDNumber: di''

''VATIDNumber: i''

''dph''

Vytoríme podsekciu v klientovi

S nazvom

'''StatutoryOfficer'''

{StatutoryCisId

StatutoryName

StatutorySurname

StatutoryPin

StatutoryidCardNumber

StatutoryEmail

StatutoryMobile

Statutory adresa1

Statutory city

Statutory zipCode

StatutorycountryCode

}

=== Popis k zapisu statutara: ===

''ak príde ''StatutoryCisId = ''null alebo príde ''StatutoryCisId''s takou hodnotou, ktorá sa nenachádza v tabuľke zákazníkov a ostatné údaje pre statutára sú vyplnené tak sa zakladá nová osoba dl_osoba a tato osoba sa zapíše do tabuľky lea_statutár (stĺpec osoba_id+ plus ďalšie doplnkové údaje k štatutárovi)''

''ak príde ''StatutoryCisId'' vyplnené a existuje zákazník s týmto CIS_ID, tak sa vyhľadá zákazník s týmto CIS_ID a založí sa záznam do tabuľky lea_statutar s osoba_id =zakaznik_id(tento zákazník podľa vyhľadaného CIS_ID) a zaktualizuje sa priamo zákazníka s rovnakým CIS_ID ostatne údaje v tomto prípade už nezapisujeme do tabuľky štatutár (pre zobrazenie v okne budú hodnoty preberané zo zákazníka)''

''Pre zápis klienta FON pridáme kontrolu, ''

''i nová osoba sa už nenachádza ako štatutár –''

''kontrola na základe rodného čísla.''

''Ak sa nájde zhoda že už existuje taký štatutár ako zákazník FON ktorý sa aktuálne vytvára, tak sa prevezme jeho osoba_id a založí zakaznik_id s týmto osoba_id, týmto sa doplní väzba medzi štatutárom a zákazníkom FON ktorý vzniká.''

=== ===

=== Popis k zápisu Firmy: ===

A typ zákazníka clientType príde hodnota, ktorá má v číselníku väzbu na typ firmy

Potom sú povinne tieto údaje:

companyName

idNumber

TaxIDNumber

''Nepovinné''

VATIDNumber

Spin na základe týchto údajov zakladá štandardne osobu zákazníka

Address{} zapis do osoby

Contacts{} zápis do osoby

a zároveň aj Firmu s údajmi (companyName

idNumber

TaxIDNumber

''Nepovinné''

VATIDNumber,

== GDPR – odpojenie FOP ===== AKCIE ===

Odpojenie zmlúv - bez zmeny - pri realizácii sa zmení zákazník, za toho v nastavení

a na pôvodnom zákazníkovi sa nastaví dátum odpojenia poslednej zmluvy.

Anonymizácia klienta – návrh bez zmeny vyhodnocovať sa bude, dátum odpojenia poslednej zmluvy na zákazníka

'''Realizácia'''''' –''' pri realizácii sa vymažú údaje z tabuľky lea_statutar pre zákazníka FOP ktorý sa anonymizuje, zruší sa väzba dl_osoba.firma_id ,lea_zakaznik.firma_id pre zákazníka FOP,

ak na firmu neexistuje ďalšia väzba na inú osobu, alebo zákazníka tak sa pokúsime vymazať firmu.

Ak sa firmu nepodarí vymazať z dôvodu väzby na nejaký doklad (faktúra), vtedy firmu zachováme a vyplníme dátum platnosti do na sysdate a pokračujeme štandardne, vymazáva sa zákazník a nakoniec osoba.

''kontrola pri vytváraní návrhu, ak pre zákazníka FON existuje záznam v tabuľke Štatutár tak zákazník nepadane ani do návrhu.(najprv musí dôjsť k anonymizácii FOP a až v ďalšej dávke k anonymizacii FON, keď nebude existovať FON ako štatutár)''

== Úprava Služby na doplŇanie chýbajucich CIS ==Aktuálne procedúra '''pklea4VUB.pDoplnenieChybajucichCisId''' funguje tak že pre všetkých zákazníkov ktorým chyba cis_id . vyhľadáva v bankovej službe.

Procedúru upravíme, aby dopĺňala chýbajúce CIS aj pre štatutárov, čiže posielať budeme rodné číslo, také kde chýba CIS_ID z tabuľky lea_statutar.

== Online úprava DáT pre štatutára ==

Aktualizácia údajov pre FOP nebude predmetom tejto požiadavky

Aktuálna funkcionalita upravuje len zákazníkov FON.

Ak bude štatutár súčasne aj zákazník FON vtedy to funguje povodne cez CIS_ID sa upraví zákazníka po starom.

Môže ale nastať situácia, že vy systéme SPIN bude osoba zaevidovaná len ako štatutár nie ako zákazník a dôjde u aktualizácii údajov pravé na štatutára.

Upravíme funkcie, aby pre aktualizáciu nevyhľadávalo CIS_ID len z lea_zakaznik ale v prípade ak CIS_ID nenajde v tabulke lea_zakaznik, tak hľadá aj v tabuľke lea_statutar.

Zaktualizujeme informácie len k osobe nie k zákazníkovi.

Niektoré informácie, ktoré si zapisujeme k zákazníkovi napr: rodinny_stav tak si ich aktuálne nemáme kde zapísať, keďže zákazník neexistuje, tak ich aktualizáciu preskočíme.

Dotknuté funkcie:

pklea4VUB.FCUSTOMERCI

pklea4VUB.FCUSTOMERPI

pklea4vub.fcisdupdate - Upravíme službu aby menila kontrolovala aj cis_id na štatutárovi.

== DWH ==Nová tabuľka

'''J_LEA_STATUTAR'''

{| border="1"
|'''Stlpec názov'''
|'''TYP'''
|'''nullable'''
|-

|ZAKAZNIK_ID
|integer
|N
|-

|OSOBA_ID
|integer
|N
|-

|CIS_ID
|integer
|A
|-

|RODNE_CISLO
|Varchar(10)
|N
|-

|CISLO_OP
|Varchar2(10)
|N
|-

|''PLATNOST_DO''
|''Date''
|''A''
|-

|''J_DATUM''
|''date''
|''N''
|-

|''J_TYP''
|''Char''
|''N''
|-

|''J_ID''
|''integer''
|''N''
|}

Rožširenie tabuľky '''J_LEA_TYP_ZAKAZNIKA'''

{| border="1"
|TYP_FIRMY_ID
|integer
|A
|}

[[category:Leasing]]

Virtualna karta

2024-04-10T11:48:35Z

Roman.adamjak: /* WEBAPI */

Add Your Content Here

[[category:PTP (person to person)]]

= Virtuálna karta =

=== Virtuálna karta ===

''[''''Menu] P2P -> Zmluvy -> ''''[''''šípka] Virtuálna karta''

V module P2P vznikne nové okno ''„Virtuálna karta“'' kde budú importované dávky z csv súboru v dohodnutej štruktúre.

Okno bude mať 2 karty:

1) 1.karta ''„Dávka“ ''bude obsahovať stĺpce
1) Dávka – poradové číslo importovanej dávky, generované systémom
1) Dátum a čas importu
1) Používateľ – používateľ, ktorý dávku importoval
1) Platnosť do – určuje platnosť ponuky
1) 2.karta „''Zmluvy''“ stĺpce
1) WEBID – z importu
1) VS - zobrazenie zo zmluvy podľa WEBID
1) VS2 - zobrazenie zo zmluvy WEBID
1) Dátum - Dátum konsolidácie zmluvy = sysdate importu
1) Suma navýšenia – z importu
1) Stav - Nový/Realizovaný
1) Výsledok spracovania – popis spracovania/chyby
1) WEBID novej zmluvy – vyplnené po realizácie
1) '''VS novej zmluvy''' - pre novú zmluvu vyplnené cez služby v CRM – pri importe bude prázdne
1) '''Počet splátok novej zmluvy''' – informatívny stĺpec vypočítaný k dňu importu pre novú zmluvu
1) '''Zmluvná cena''''''novej zmluvy''' – informatívny stĺpec vypočítaný k dňu importu pre novú zmluvu
1) '''Istina novej zmluvy '''– informatívny stĺpec vypočítaný k dňu importu pre novú zmluvu

==== Akcia Import súboru ====

V okne ''Virtuálna karta'' bude nová akcia ''Import súboru'' spustením akcie sa otvorí okno kde bude možnosť prehľadávať cestu k súboru v PC a nastaviť platnosť do(povinný údaj) pre dávku. Stlačení OK sa csv súbor naimportuje ako dávka do okna s definovanou platnosťou do . Naimportovaním súboru vznikne nový záznam dávky s priradenými zmluvami v záložke zmluvy. Pri zmluvách budú vypočítané údaje informatívneho charakteru k dátumu importu - '''Počet splátok novej zmluvy, Zmluvná cena''''''novej zmluvy'''''', ''''''Istina novej zmluvy''''''.'''

Súbor csv s oddeľovačom bodkočiarka v štruktúre súboru:

1) WEBID – WEBID zmluvy, ktorá bude predčasne splatená
1) Suma navýšenia – suma o koľko bude navýšená nová zmluva - Suma navýšenia je hodnota finančného plnenia novej zmluvy.
Príklad

111111;200,50

===== Spracovanie súboru =====
V prípade, chybného WEBID v súbore, podľa ktorého nebude možné zmluvu identifikovať, súbor nebude naimportovaný a používateľ bude o chybe v súbore informovaný. Súbor opraví a spustí import znova.

===== View =====
Pre účely vytvárania ponúk bude vytvorené nove View. Štruktúra popísaná v kapitole View dávky

==== Akcia Zmena stavu ====

V okne ''Virtuálna karta'' bude nová akcia ''Realizácia. ''Akcia bude spúšťaná v záložke zmluvy nad označenými zmluvami z dávky. Akcia bude meniť stav zmlúv z dávky.

Pri spustení akcie používateľ si bude môcť vybrať zo stavov:

1) Nová
1) Zamietnutá

==== Akcia Realizácia ====

V okne ''Virtuálna karta'' bude nová akcia ''Realizácia. ''Akcia bude spúšťaná v záložke zmluvy nad označenými zmluvami z dávky. Akcia spustí realizáciu len nad zmluvami, ktoré majú stav ''„Schválená“ ''a Platnosť dávky do >= sysdate.Spracovaním záznamu sa zmení stav zmluvy v okne na ''„Realizovaný“. ''Akciu nebude možné spúšťať opakovane nad záznamom, ak bol spracovaný. V prípade chyby bude v stĺpci ''Výsledok spracovania'' zapísaná chyba spracovania. Akcia nebude mať spätný chod.

Akcia bude nad označenými zmluvami z dávky vytvárať nové konsolidované zmluvy (pôžičky) s novým číslom a VS. Pôvodná zmluva bude vyrovnaná na 0 s dátumom d-1 z aktuálneho dátumu. Prepojenie Pôvodnej zmluvy a novej konsolidovanej zmluvy bude pomocou nového stĺpca ''Variabilný symbol 2 ''(viď kapitola Variabilný symbol 2). Zákazník bude uhrádzať splátky podľa pôvodného VS. Proces realizácie bude opakovaný v slede zmlúv niekoľkokrát (odhad 3x) záver sa vytvorí konsolidácia cez CRM.

===== Kroky Realizácie =====
Realizáciu bude možné spúšťať ručne pomocou akcie ''Realizácia'' alebo Automaticky ( kroky 1 a 2 ) súčasťou volania webapi schvaľovania.

====== 1. krok - Spustenie ======

Spustením akcie spracovanie na označených zmluvách z dávky sa otvorí okno s vyberačom na produkt (nepovinný údaj).

1) Ak pri spustení bude produkt vyplnený v novej zmluve bude požitý vybraný produkt
1) Ak pri spustení nebude produkt vyplnený na novej zmluve sa použije produkt z pôvodnej zmluvy
====== 2. krok – Vytvorenie novej zmluvy ======

Výberom produktu vzniká nová konsolidovaná zmluva s väzbami na pôvodnú zmluvu. Číslo novej konsolidovanej zmluvy bude pridelené číslo podľa VS, ktoré poslalo CRM cez služby '''. '''Nová zmluva bude mať dátum evidencie = dátum z dávky a nový variabilný symbol z CRM (VS = WEBID) ( v rámci modulu P2P je VS jedinečný). A VS pôvodnej zmluvy sa zapíše do nového stĺpca ''Variabilný symbol 2''(viď kapitola Variabilný symbol 2).

Pôvodná zmluva bude vyrovnaná na 0 a nová zmluva bude mať istinu ako suma zostatku istiny + alikvotný úrok + suma navýšenia. Suma navýšenia(z importu) bude z pravidla hodnota uhradených splátok klientom.

{| border="1"
|VS
|VS2
|Mesiac splátka
|Istina
|Úrok
|-

|999
|
|1
|20
|50
|-

|999
|
|2
|30
|40
|-

|999
|
|3
|40
|30
|-

|999
|
|4
|410
|4
|-

| Nova zmluva
|
|

|
|
|-

|801
|999
|1
|624
|
|}

Istina 624€ na novej zmluve vznikol súčtom 410 + 4 + 210.

Počet splátok novej zmluvy – pri tvorbe novej zmluvy sa bude vypočítavať počet splátok. Poznáme istinu, úročiteľa a výšku splátky. Hľadá sa počet splátok, aby posledná splátka bola nižšia ako hodnota splátky. Príklad výpočtu v súbore.

'''Riešenie je postavene len pre výpočet kalendára anuitný štandard.'''

Prípadné preplatky na pôvodnej zmluve budú vyriešené cez funkčnosť preplatkov a prevedenia preplatku na konsolidovanú zmluvu. Výsledok o realizácii a WEBID novej zmluvy bude zapísaný v stĺpci ''Výsledok spracovania, ''kde bude vyplnený text ''„OK. Vytvorená nová konsolidovaná zmluva“. ''V stĺpci nové WEBID bude zobrazená hodnota novej zmluvy.

====== 3. krok – Párovanie ======

Konsolidovaná zmluva sa spáruje s investíciami. Vznikne finančné plnenie v hodnote navýšenia.

====== 4. krok – Splátkový kalendár ======

Nová konsolidovaná zmluva bude mať nový vypočítaný splátkový kalendár, ktorého výška splátky a úročiteľ ostáva rovnaký ako na pôvodnej zmluve. Variabilný bude počet splátok. Nový splátkový kalendár bude anuitný bez vstupných poplatkov a posledná splátka bude dopočítavaná => nemusí byť rovnaká.

Prvá splátka bude v najbližšom 22. dni mesiaca od dátumu, kedy bola spúšťaná realizácia. Zákazník bude uhrádzať splátky podľa pôvodného VS.

''Príklad''

''Ak bude realizácia bude do 21.6. prvá splátka novej zmluvy bude 22.6 (aktuálny mesiac), ak bude realizácia napr. 22.6. a neskôr prvá splátka novej zmluvy bude 22.7(nasledujúci mesiac).''

====== 5.krok – finančné plnenie ======

Rovnaký princíp ako pri konsolidácii. Pre finančné plnenie novej zmluvy bude vygenerovaná nová faktúra, ktorá bude ponížená finančným saldom v hodnote zostatku pôvodnej zmluvy. A bude vyplatená suma navýšenia z importu.

====== 6.krok – Investori ======

Bez úprav.

====== 7.krok – Provízia ======

Bez úprav. Provízie budú fungovať rovnako ako pri aktuálnej konsolidácii – z navýšenej sumy.

====== ======

=== Variabilný symbol 2 ===

Variabilný symbol zmluvy je jedinečný a nie je možné ho duplikovať/opakovať, Súčasťou úlohy bude zavedenie nového Variabilného symbolu 2(VS2) na zmluve, ktorý nebude jedinečný. Pri akcii realizácia vo Virtuálnej karte budú generované nové zmluvy s novým VS. Zákazník bude, ale vždy posielať úhrady VS z pôvodnej zmluvy. VS pôvodnej zmluvy bude zapísaný v stĺpci Variabilný symbol 2 a tým sa zabezpečí párovanie úhrad na pôvodný VS.

==== Logika vyplnenia VS2 ====

Ak pri vytváraní novej konsolidovanej zmluvy (WEBID = 2) a vo Virtuálnej karte nebude mať pôvodná zmluva vyplnený VS2 nová konsolidovaná zmluva bude mať nový VS a VS2 bude VS prebratý z pôvodnej zmluvy.

Ak pri vytváraní novej konsolidovanej zmluvy (WEBID = 3) a vo Virtuálnej karte bude mať pôvodná zmluva vyplnený VS2 nová konsolidovaná zmluva bude mať nový VS a VS2 bude VS2 prebratý z pôvodnej zmluvy.

{| border="1"
|WEBID
|VS
|[mailto:VS@ VS2]
|-

|1
|999
|
|-

|2
|801
|999
|-

|3
|802
|999
|}
==== Spracovanie úhrad ====

Pri párovaní úhrad bude zapracovaná nová logika párovania úhrady cez variabilný symbol 2, ktorý bude mat vyššiu prioritu párovania. Systém pri párovaní bude najprv vyhľadávať uvedený VS v zmluvách s vyplneným VS2. Ak sa zmluva s takým VS2 nájde úhrada bude párovaná na najnovšiu zmluvu (ak ich bude viac), ak systém zmluvu s VS2 nenájde bude ju párovať cez variabilný symbol zmluvy ako v súčasnosti.

Zákazník bude uhrádzať splátky s pôvodným VS, ktorý bude zapísaný vo VS2 novej zmluvy a úhrada bude prednostne párovaná na novú zmluvu.

==== Úprava okien ====

V oknách modulu P2P, v ktorých sa nachádza stĺpec variabilný symbol bude pridaný nový stĺpec ''Variabilný symbol 2''. Pôvodný stĺpec variabilný symbol bude zobrazovať hodnotu nasledovne:

1) Ak zmluva nemá VS2 zobrazuje sa VS
1) Ak zmluva má vyplnený VS2 zobrazuje sa VS2

==== Parametre SMS a Email ====

V parametroch pre SMS a Emaily bude zapracovaná úprava pre Variabilný symbol 2

1) Ak zmluva nemá VS2 posiela sa VS
1) Ak zmluva má vyplnený VS2 posiela sa VS2

=== Tlačové výstupy ===

==== Úprava zostáv pôžičky pri párovaní ====

V zostavách pôžičky pri párovaní bude zapracovaná úprava pre Variabilný symbol 2

1) Ak zmluva nemá VS2 tlači sa VS
1) Ak zmluva má vyplnený VS2 tlači sa VS2
=== Prístupové práva ===

Zapracovaním tejto požiadavky nevzniknú požiadavky na prístupové práva.

=== VIEW ===

==== View dávky ====

V DB vznikne nové VIEW, ktoré bude zobrazovať všetky položky dávky so stĺpcami

1) ID dávky = Id ponuky
1) ID položky dávky
1) Platnosť do dávky
1) WEBID – z importu
1) VS - zobrazenie zo zmluvy podľa WEBID
1) VS2 - zobrazenie zo zmluvy WEBID
1) Dátum - Dátum konsolidácie zmluvy = sysdate importu
1) Suma navýšenia – z importu
1) Stav - Nový/Realizovaný/Schválený
1) Výsledok spracovania – popis spracovania/chyby
1) WEBID novej zmluvy – vyplnené po realizácii
1) VS2 novej zmluvy - pre novú zmluvu vyplnené pôvodné VS
1) Počet splátok novej zmluvy – informatívny stĺpec vypočítaný k dňu importu pre novú zmluvu
1) Zmluvná cena novej zmluvy – informatívny stĺpec vypočítaný k dňu importu pre novú zmluvu
1) Istina novej zmluvy – informatívny stĺpec vypočítaný k dňu importu pre novú zmluvu

== Proces realizácie ==

V procese realizácia bola zapracovaná nová funkčnosť, kde pri vytváraní novej zmluvy, bude vo WEB_ID použitá hodnota WEB_ID z CRM.

== WEBAPI ==

=== POST /virtual_card ===
Služba v sebe obsahuje kroky:
1. Schválenie
2. Realizácia
3. Aktualizácia dát zmluvy
Bola upravená štruktúra existujúcej služby POST /ptp/virtual_card
Model služby obsahuje:
• virtual_card_id – povinný údaj, identifikátor pre realizáciu zmluvy v dávke
• celý endpoint POST /loan – povinnosť údajov podľa endpointu
o WEB_ID, VS, Produkt bude preberaný z POST /loan, z dôvodu duplicity došlo k odstráneniu oproti pôvodnej štruktúre

{{Príklad| Príklad: virtula_card.json

[[https://jira.assecosol.eu/secure/attachment/374114/374114_KTFINANCE-1609+-+virtual_card.json]]
}}

*obsah LOAN sa môže líšiť od aktuálne platnej štruktúry služby POST /loan

Súčasťou realizácie bola zapracovaná nová funkčnosť aktualizácie dát zmluvy, ktoré sú na vstupe služby. Systém pri aktualizácií dát nebude kontrolovať správnosť prijatých dáta voči pôvodnej konsolidovanej zmluve. Za správnosť dát na novej zmluve bude zodpovedať systém, ktorý dáta poslal (CRM). Dáta v časti loan{} je potrebné posielať vždy ako pri volaní POST /loan.

Služby POST /virtual_card a POST /loan sú na seba naviazané a ak dôjde k zmene modelu, zmena sa prejaví v oboch službách.

Virtualna karta

2024-04-10T11:46:49Z

Roman.adamjak: /* */

Add Your Content Here

[[category:PTP (person to person)]]

= Virtuálna karta =

=== Virtuálna karta ===

''[''''Menu] P2P -> Zmluvy -> ''''[''''šípka] Virtuálna karta''

V module P2P vznikne nové okno ''„Virtuálna karta“'' kde budú importované dávky z csv súboru v dohodnutej štruktúre.

Okno bude mať 2 karty:

1) 1.karta ''„Dávka“ ''bude obsahovať stĺpce
1) Dávka – poradové číslo importovanej dávky, generované systémom
1) Dátum a čas importu
1) Používateľ – používateľ, ktorý dávku importoval
1) Platnosť do – určuje platnosť ponuky
1) 2.karta „''Zmluvy''“ stĺpce
1) WEBID – z importu
1) VS - zobrazenie zo zmluvy podľa WEBID
1) VS2 - zobrazenie zo zmluvy WEBID
1) Dátum - Dátum konsolidácie zmluvy = sysdate importu
1) Suma navýšenia – z importu
1) Stav - Nový/Realizovaný
1) Výsledok spracovania – popis spracovania/chyby
1) WEBID novej zmluvy – vyplnené po realizácie
1) '''VS novej zmluvy''' - pre novú zmluvu vyplnené cez služby v CRM – pri importe bude prázdne
1) '''Počet splátok novej zmluvy''' – informatívny stĺpec vypočítaný k dňu importu pre novú zmluvu
1) '''Zmluvná cena''''''novej zmluvy''' – informatívny stĺpec vypočítaný k dňu importu pre novú zmluvu
1) '''Istina novej zmluvy '''– informatívny stĺpec vypočítaný k dňu importu pre novú zmluvu

==== Akcia Import súboru ====

V okne ''Virtuálna karta'' bude nová akcia ''Import súboru'' spustením akcie sa otvorí okno kde bude možnosť prehľadávať cestu k súboru v PC a nastaviť platnosť do(povinný údaj) pre dávku. Stlačení OK sa csv súbor naimportuje ako dávka do okna s definovanou platnosťou do . Naimportovaním súboru vznikne nový záznam dávky s priradenými zmluvami v záložke zmluvy. Pri zmluvách budú vypočítané údaje informatívneho charakteru k dátumu importu - '''Počet splátok novej zmluvy, Zmluvná cena''''''novej zmluvy'''''', ''''''Istina novej zmluvy''''''.'''

Súbor csv s oddeľovačom bodkočiarka v štruktúre súboru:

1) WEBID – WEBID zmluvy, ktorá bude predčasne splatená
1) Suma navýšenia – suma o koľko bude navýšená nová zmluva - Suma navýšenia je hodnota finančného plnenia novej zmluvy.
Príklad

111111;200,50

===== Spracovanie súboru =====
V prípade, chybného WEBID v súbore, podľa ktorého nebude možné zmluvu identifikovať, súbor nebude naimportovaný a používateľ bude o chybe v súbore informovaný. Súbor opraví a spustí import znova.

===== View =====
Pre účely vytvárania ponúk bude vytvorené nove View. Štruktúra popísaná v kapitole View dávky

==== Akcia Zmena stavu ====

V okne ''Virtuálna karta'' bude nová akcia ''Realizácia. ''Akcia bude spúšťaná v záložke zmluvy nad označenými zmluvami z dávky. Akcia bude meniť stav zmlúv z dávky.

Pri spustení akcie používateľ si bude môcť vybrať zo stavov:

1) Nová
1) Zamietnutá

==== Akcia Realizácia ====

V okne ''Virtuálna karta'' bude nová akcia ''Realizácia. ''Akcia bude spúšťaná v záložke zmluvy nad označenými zmluvami z dávky. Akcia spustí realizáciu len nad zmluvami, ktoré majú stav ''„Schválená“ ''a Platnosť dávky do >= sysdate.Spracovaním záznamu sa zmení stav zmluvy v okne na ''„Realizovaný“. ''Akciu nebude možné spúšťať opakovane nad záznamom, ak bol spracovaný. V prípade chyby bude v stĺpci ''Výsledok spracovania'' zapísaná chyba spracovania. Akcia nebude mať spätný chod.

Akcia bude nad označenými zmluvami z dávky vytvárať nové konsolidované zmluvy (pôžičky) s novým číslom a VS. Pôvodná zmluva bude vyrovnaná na 0 s dátumom d-1 z aktuálneho dátumu. Prepojenie Pôvodnej zmluvy a novej konsolidovanej zmluvy bude pomocou nového stĺpca ''Variabilný symbol 2 ''(viď kapitola Variabilný symbol 2). Zákazník bude uhrádzať splátky podľa pôvodného VS. Proces realizácie bude opakovaný v slede zmlúv niekoľkokrát (odhad 3x) záver sa vytvorí konsolidácia cez CRM.

===== Kroky Realizácie =====
Realizáciu bude možné spúšťať ručne pomocou akcie ''Realizácia'' alebo Automaticky ( kroky 1 a 2 ) súčasťou volania webapi schvaľovania.

====== 1. krok - Spustenie ======

Spustením akcie spracovanie na označených zmluvách z dávky sa otvorí okno s vyberačom na produkt (nepovinný údaj).

1) Ak pri spustení bude produkt vyplnený v novej zmluve bude požitý vybraný produkt
1) Ak pri spustení nebude produkt vyplnený na novej zmluve sa použije produkt z pôvodnej zmluvy
====== 2. krok – Vytvorenie novej zmluvy ======

Výberom produktu vzniká nová konsolidovaná zmluva s väzbami na pôvodnú zmluvu. Číslo novej konsolidovanej zmluvy bude pridelené číslo podľa VS, ktoré poslalo CRM cez služby '''. '''Nová zmluva bude mať dátum evidencie = dátum z dávky a nový variabilný symbol z CRM (VS = WEBID) ( v rámci modulu P2P je VS jedinečný). A VS pôvodnej zmluvy sa zapíše do nového stĺpca ''Variabilný symbol 2''(viď kapitola Variabilný symbol 2).

Pôvodná zmluva bude vyrovnaná na 0 a nová zmluva bude mať istinu ako suma zostatku istiny + alikvotný úrok + suma navýšenia. Suma navýšenia(z importu) bude z pravidla hodnota uhradených splátok klientom.

{| border="1"
|VS
|VS2
|Mesiac splátka
|Istina
|Úrok
|-

|999
|
|1
|20
|50
|-

|999
|
|2
|30
|40
|-

|999
|
|3
|40
|30
|-

|999
|
|4
|410
|4
|-

| Nova zmluva
|
|

|
|
|-

|801
|999
|1
|624
|
|}

Istina 624€ na novej zmluve vznikol súčtom 410 + 4 + 210.

Počet splátok novej zmluvy – pri tvorbe novej zmluvy sa bude vypočítavať počet splátok. Poznáme istinu, úročiteľa a výšku splátky. Hľadá sa počet splátok, aby posledná splátka bola nižšia ako hodnota splátky. Príklad výpočtu v súbore.

'''Riešenie je postavene len pre výpočet kalendára anuitný štandard.'''

Prípadné preplatky na pôvodnej zmluve budú vyriešené cez funkčnosť preplatkov a prevedenia preplatku na konsolidovanú zmluvu. Výsledok o realizácii a WEBID novej zmluvy bude zapísaný v stĺpci ''Výsledok spracovania, ''kde bude vyplnený text ''„OK. Vytvorená nová konsolidovaná zmluva“. ''V stĺpci nové WEBID bude zobrazená hodnota novej zmluvy.

====== 3. krok – Párovanie ======

Konsolidovaná zmluva sa spáruje s investíciami. Vznikne finančné plnenie v hodnote navýšenia.

====== 4. krok – Splátkový kalendár ======

Nová konsolidovaná zmluva bude mať nový vypočítaný splátkový kalendár, ktorého výška splátky a úročiteľ ostáva rovnaký ako na pôvodnej zmluve. Variabilný bude počet splátok. Nový splátkový kalendár bude anuitný bez vstupných poplatkov a posledná splátka bude dopočítavaná => nemusí byť rovnaká.

Prvá splátka bude v najbližšom 22. dni mesiaca od dátumu, kedy bola spúšťaná realizácia. Zákazník bude uhrádzať splátky podľa pôvodného VS.

''Príklad''

''Ak bude realizácia bude do 21.6. prvá splátka novej zmluvy bude 22.6 (aktuálny mesiac), ak bude realizácia napr. 22.6. a neskôr prvá splátka novej zmluvy bude 22.7(nasledujúci mesiac).''

====== 5.krok – finančné plnenie ======

Rovnaký princíp ako pri konsolidácii. Pre finančné plnenie novej zmluvy bude vygenerovaná nová faktúra, ktorá bude ponížená finančným saldom v hodnote zostatku pôvodnej zmluvy. A bude vyplatená suma navýšenia z importu.

====== 6.krok – Investori ======

Bez úprav.

====== 7.krok – Provízia ======

Bez úprav. Provízie budú fungovať rovnako ako pri aktuálnej konsolidácii – z navýšenej sumy.

====== ======

=== Variabilný symbol 2 ===

Variabilný symbol zmluvy je jedinečný a nie je možné ho duplikovať/opakovať, Súčasťou úlohy bude zavedenie nového Variabilného symbolu 2(VS2) na zmluve, ktorý nebude jedinečný. Pri akcii realizácia vo Virtuálnej karte budú generované nové zmluvy s novým VS. Zákazník bude, ale vždy posielať úhrady VS z pôvodnej zmluvy. VS pôvodnej zmluvy bude zapísaný v stĺpci Variabilný symbol 2 a tým sa zabezpečí párovanie úhrad na pôvodný VS.

==== Logika vyplnenia VS2 ====

Ak pri vytváraní novej konsolidovanej zmluvy (WEBID = 2) a vo Virtuálnej karte nebude mať pôvodná zmluva vyplnený VS2 nová konsolidovaná zmluva bude mať nový VS a VS2 bude VS prebratý z pôvodnej zmluvy.

Ak pri vytváraní novej konsolidovanej zmluvy (WEBID = 3) a vo Virtuálnej karte bude mať pôvodná zmluva vyplnený VS2 nová konsolidovaná zmluva bude mať nový VS a VS2 bude VS2 prebratý z pôvodnej zmluvy.

{| border="1"
|WEBID
|VS
|[mailto:VS@ VS2]
|-

|1
|999
|
|-

|2
|801
|999
|-

|3
|802
|999
|}
==== Spracovanie úhrad ====

Pri párovaní úhrad bude zapracovaná nová logika párovania úhrady cez variabilný symbol 2, ktorý bude mat vyššiu prioritu párovania. Systém pri párovaní bude najprv vyhľadávať uvedený VS v zmluvách s vyplneným VS2. Ak sa zmluva s takým VS2 nájde úhrada bude párovaná na najnovšiu zmluvu (ak ich bude viac), ak systém zmluvu s VS2 nenájde bude ju párovať cez variabilný symbol zmluvy ako v súčasnosti.

Zákazník bude uhrádzať splátky s pôvodným VS, ktorý bude zapísaný vo VS2 novej zmluvy a úhrada bude prednostne párovaná na novú zmluvu.

==== Úprava okien ====

V oknách modulu P2P, v ktorých sa nachádza stĺpec variabilný symbol bude pridaný nový stĺpec ''Variabilný symbol 2''. Pôvodný stĺpec variabilný symbol bude zobrazovať hodnotu nasledovne:

1) Ak zmluva nemá VS2 zobrazuje sa VS
1) Ak zmluva má vyplnený VS2 zobrazuje sa VS2

==== Parametre SMS a Email ====

V parametroch pre SMS a Emaily bude zapracovaná úprava pre Variabilný symbol 2

1) Ak zmluva nemá VS2 posiela sa VS
1) Ak zmluva má vyplnený VS2 posiela sa VS2

=== WEBAPI ===

==== Schválenie položky dávky ====

Vznikne nová služba, ktorá bude schvaľovať položku dávky. Zmena stavu z ''Nová'' >> ''Schválená. ''Súčasťou služby bude aj vstup, kde bude CRM posielať VS pre novú zmluvu, ktorá vzniká pri realizácii

'''Vstup služby'''

1) ID položky dávky – povinný údaj
1) VS pre novú zmluvu – povinný údaj
1) WEB_ID produktu – nepovinný údaj

'''Podmienka správneho zápisu'''

1) ID položky dávky musí existovať
1) Platnosť do dávky >= sysdate
1) Položka dávky má stav = Nová
1) VS pre novú zmluvu – nesmie existovať na inej zmluve

'''Výsledok spracovania služby'''

1) Položke dávky sa zmení stav na ''Schválená''
1) Do stĺpca '''''VS novej zmluvy '''''sa zapíše hodnota VS
1) Spustí sa automatická realizácia pre danú zmluvu – produkt sa preberá z pôvodnej zmluvy alebo zo vstupu služby

'''Výstup služby'''

1) 200 OK
1) Zmluva schválená a realizácia dokončená – výstup, ak prebehla realizácia.
1) 500 chyba – popis chyby – bude zahŕňať aj chybu realizácie

=== Tlačové výstupy ===

==== Úprava zostáv pôžičky pri párovaní ====

V zostavách pôžičky pri párovaní bude zapracovaná úprava pre Variabilný symbol 2

1) Ak zmluva nemá VS2 tlači sa VS
1) Ak zmluva má vyplnený VS2 tlači sa VS2
=== Prístupové práva ===

Zapracovaním tejto požiadavky nevzniknú požiadavky na prístupové práva.

=== VIEW ===

==== View dávky ====

V DB vznikne nové VIEW, ktoré bude zobrazovať všetky položky dávky so stĺpcami

1) ID dávky = Id ponuky
1) ID položky dávky
1) Platnosť do dávky
1) WEBID – z importu
1) VS - zobrazenie zo zmluvy podľa WEBID
1) VS2 - zobrazenie zo zmluvy WEBID
1) Dátum - Dátum konsolidácie zmluvy = sysdate importu
1) Suma navýšenia – z importu
1) Stav - Nový/Realizovaný/Schválený
1) Výsledok spracovania – popis spracovania/chyby
1) WEBID novej zmluvy – vyplnené po realizácii
1) VS2 novej zmluvy - pre novú zmluvu vyplnené pôvodné VS
1) Počet splátok novej zmluvy – informatívny stĺpec vypočítaný k dňu importu pre novú zmluvu
1) Zmluvná cena novej zmluvy – informatívny stĺpec vypočítaný k dňu importu pre novú zmluvu
1) Istina novej zmluvy – informatívny stĺpec vypočítaný k dňu importu pre novú zmluvu

== Proces realizácie ==

V procese realizácia bola zapracovaná nová funkčnosť, kde pri vytváraní novej zmluvy, bude vo WEB_ID použitá hodnota WEB_ID z CRM.

== WEBAPI ==

=== POST /virtual_card ===
Služba v sebe obsahuje kroky:
1. Schválenie
2. Realizácia
3. Aktualizácia dát zmluvy
Bola upravená štruktúra existujúcej služby POST /ptp/virtual_card
Model služby obsahuje:
• virtual_card_id – povinný údaj, identifikátor pre realizáciu zmluvy v dávke
• celý endpoint POST /loan – povinnosť údajov podľa endpointu
o WEB_ID, VS, Produkt bude preberaný z POST /loan, z dôvodu duplicity došlo k odstráneniu oproti pôvodnej štruktúre

{{Príklad| Príklad: virtula_card.json

[[https://jira.assecosol.eu/secure/attachment/374114/374114_KTFINANCE-1609+-+virtual_card.json]]
}}

*obsah LOAN sa môže líšiť od aktuálne platnej štruktúry služby POST /loan

Súčasťou realizácie bola zapracovaná nová funkčnosť aktualizácie dát zmluvy, ktoré sú na vstupe služby. Systém pri aktualizácií dát nebude kontrolovať správnosť prijatých dáta voči pôvodnej konsolidovanej zmluve. Za správnosť dát na novej zmluve bude zodpovedať systém, ktorý dáta poslal (CRM). Dáta v časti loan{} je potrebné posielať vždy ako pri volaní POST /loan.

Služby POST /virtual_card a POST /loan sú na seba naviazané a ak dôjde k zmene modelu, zmena sa prejaví v oboch službách.

Virtualna karta

2024-04-10T11:46:38Z

Roman.adamjak: /* */

Add Your Content Here

[[category:PTP (person to person)]]

= Virtuálna karta =

=== Virtuálna karta ===

''[''''Menu] P2P -> Zmluvy -> ''''[''''šípka] Virtuálna karta''

V module P2P vznikne nové okno ''„Virtuálna karta“'' kde budú importované dávky z csv súboru v dohodnutej štruktúre.

Okno bude mať 2 karty:

1) 1.karta ''„Dávka“ ''bude obsahovať stĺpce
1) Dávka – poradové číslo importovanej dávky, generované systémom
1) Dátum a čas importu
1) Používateľ – používateľ, ktorý dávku importoval
1) Platnosť do – určuje platnosť ponuky
1) 2.karta „''Zmluvy''“ stĺpce
1) WEBID – z importu
1) VS - zobrazenie zo zmluvy podľa WEBID
1) VS2 - zobrazenie zo zmluvy WEBID
1) Dátum - Dátum konsolidácie zmluvy = sysdate importu
1) Suma navýšenia – z importu
1) Stav - Nový/Realizovaný
1) Výsledok spracovania – popis spracovania/chyby
1) WEBID novej zmluvy – vyplnené po realizácie
1) '''VS novej zmluvy''' - pre novú zmluvu vyplnené cez služby v CRM – pri importe bude prázdne
1) '''Počet splátok novej zmluvy''' – informatívny stĺpec vypočítaný k dňu importu pre novú zmluvu
1) '''Zmluvná cena''''''novej zmluvy''' – informatívny stĺpec vypočítaný k dňu importu pre novú zmluvu
1) '''Istina novej zmluvy '''– informatívny stĺpec vypočítaný k dňu importu pre novú zmluvu

==== Akcia Import súboru ====

V okne ''Virtuálna karta'' bude nová akcia ''Import súboru'' spustením akcie sa otvorí okno kde bude možnosť prehľadávať cestu k súboru v PC a nastaviť platnosť do(povinný údaj) pre dávku. Stlačení OK sa csv súbor naimportuje ako dávka do okna s definovanou platnosťou do . Naimportovaním súboru vznikne nový záznam dávky s priradenými zmluvami v záložke zmluvy. Pri zmluvách budú vypočítané údaje informatívneho charakteru k dátumu importu - '''Počet splátok novej zmluvy, Zmluvná cena''''''novej zmluvy'''''', ''''''Istina novej zmluvy''''''.'''

Súbor csv s oddeľovačom bodkočiarka v štruktúre súboru:

1) WEBID – WEBID zmluvy, ktorá bude predčasne splatená
1) Suma navýšenia – suma o koľko bude navýšená nová zmluva - Suma navýšenia je hodnota finančného plnenia novej zmluvy.
Príklad

111111;200,50

===== Spracovanie súboru =====
V prípade, chybného WEBID v súbore, podľa ktorého nebude možné zmluvu identifikovať, súbor nebude naimportovaný a používateľ bude o chybe v súbore informovaný. Súbor opraví a spustí import znova.

===== View =====
Pre účely vytvárania ponúk bude vytvorené nove View. Štruktúra popísaná v kapitole View dávky

==== Akcia Zmena stavu ====

V okne ''Virtuálna karta'' bude nová akcia ''Realizácia. ''Akcia bude spúšťaná v záložke zmluvy nad označenými zmluvami z dávky. Akcia bude meniť stav zmlúv z dávky.

Pri spustení akcie používateľ si bude môcť vybrať zo stavov:

1) Nová
1) Zamietnutá

==== Akcia Realizácia ====

V okne ''Virtuálna karta'' bude nová akcia ''Realizácia. ''Akcia bude spúšťaná v záložke zmluvy nad označenými zmluvami z dávky. Akcia spustí realizáciu len nad zmluvami, ktoré majú stav ''„Schválená“ ''a Platnosť dávky do >= sysdate.Spracovaním záznamu sa zmení stav zmluvy v okne na ''„Realizovaný“. ''Akciu nebude možné spúšťať opakovane nad záznamom, ak bol spracovaný. V prípade chyby bude v stĺpci ''Výsledok spracovania'' zapísaná chyba spracovania. Akcia nebude mať spätný chod.

Akcia bude nad označenými zmluvami z dávky vytvárať nové konsolidované zmluvy (pôžičky) s novým číslom a VS. Pôvodná zmluva bude vyrovnaná na 0 s dátumom d-1 z aktuálneho dátumu. Prepojenie Pôvodnej zmluvy a novej konsolidovanej zmluvy bude pomocou nového stĺpca ''Variabilný symbol 2 ''(viď kapitola Variabilný symbol 2). Zákazník bude uhrádzať splátky podľa pôvodného VS. Proces realizácie bude opakovaný v slede zmlúv niekoľkokrát (odhad 3x) záver sa vytvorí konsolidácia cez CRM.

===== Kroky Realizácie =====
Realizáciu bude možné spúšťať ručne pomocou akcie ''Realizácia'' alebo Automaticky ( kroky 1 a 2 ) súčasťou volania webapi schvaľovania.

====== 1. krok - Spustenie ======

Spustením akcie spracovanie na označených zmluvách z dávky sa otvorí okno s vyberačom na produkt (nepovinný údaj).

1) Ak pri spustení bude produkt vyplnený v novej zmluve bude požitý vybraný produkt
1) Ak pri spustení nebude produkt vyplnený na novej zmluve sa použije produkt z pôvodnej zmluvy
====== 2. krok – Vytvorenie novej zmluvy ======

Výberom produktu vzniká nová konsolidovaná zmluva s väzbami na pôvodnú zmluvu. Číslo novej konsolidovanej zmluvy bude pridelené číslo podľa VS, ktoré poslalo CRM cez služby '''. '''Nová zmluva bude mať dátum evidencie = dátum z dávky a nový variabilný symbol z CRM (VS = WEBID) ( v rámci modulu P2P je VS jedinečný). A VS pôvodnej zmluvy sa zapíše do nového stĺpca ''Variabilný symbol 2''(viď kapitola Variabilný symbol 2).

Pôvodná zmluva bude vyrovnaná na 0 a nová zmluva bude mať istinu ako suma zostatku istiny + alikvotný úrok + suma navýšenia. Suma navýšenia(z importu) bude z pravidla hodnota uhradených splátok klientom.

{| border="1"
|VS
|VS2
|Mesiac splátka
|Istina
|Úrok
|-

|999
|
|1
|20
|50
|-

|999
|
|2
|30
|40
|-

|999
|
|3
|40
|30
|-

|999
|
|4
|410
|4
|-

| Nova zmluva
|
|

|
|
|-

|801
|999
|1
|624
|
|}

Istina 624€ na novej zmluve vznikol súčtom 410 + 4 + 210.

Počet splátok novej zmluvy – pri tvorbe novej zmluvy sa bude vypočítavať počet splátok. Poznáme istinu, úročiteľa a výšku splátky. Hľadá sa počet splátok, aby posledná splátka bola nižšia ako hodnota splátky. Príklad výpočtu v súbore.

'''Riešenie je postavene len pre výpočet kalendára anuitný štandard.'''

Prípadné preplatky na pôvodnej zmluve budú vyriešené cez funkčnosť preplatkov a prevedenia preplatku na konsolidovanú zmluvu. Výsledok o realizácii a WEBID novej zmluvy bude zapísaný v stĺpci ''Výsledok spracovania, ''kde bude vyplnený text ''„OK. Vytvorená nová konsolidovaná zmluva“. ''V stĺpci nové WEBID bude zobrazená hodnota novej zmluvy.

====== 3. krok – Párovanie ======

Konsolidovaná zmluva sa spáruje s investíciami. Vznikne finančné plnenie v hodnote navýšenia.

====== 4. krok – Splátkový kalendár ======

Nová konsolidovaná zmluva bude mať nový vypočítaný splátkový kalendár, ktorého výška splátky a úročiteľ ostáva rovnaký ako na pôvodnej zmluve. Variabilný bude počet splátok. Nový splátkový kalendár bude anuitný bez vstupných poplatkov a posledná splátka bude dopočítavaná => nemusí byť rovnaká.

Prvá splátka bude v najbližšom 22. dni mesiaca od dátumu, kedy bola spúšťaná realizácia. Zákazník bude uhrádzať splátky podľa pôvodného VS.

''Príklad''

''Ak bude realizácia bude do 21.6. prvá splátka novej zmluvy bude 22.6 (aktuálny mesiac), ak bude realizácia napr. 22.6. a neskôr prvá splátka novej zmluvy bude 22.7(nasledujúci mesiac).''

====== 5.krok – finančné plnenie ======

Rovnaký princíp ako pri konsolidácii. Pre finančné plnenie novej zmluvy bude vygenerovaná nová faktúra, ktorá bude ponížená finančným saldom v hodnote zostatku pôvodnej zmluvy. A bude vyplatená suma navýšenia z importu.

====== 6.krok – Investori ======

Bez úprav.

====== 7.krok – Provízia ======

Bez úprav. Provízie budú fungovať rovnako ako pri aktuálnej konsolidácii – z navýšenej sumy.

====== ======

=== Variabilný symbol 2 ===

Variabilný symbol zmluvy je jedinečný a nie je možné ho duplikovať/opakovať, Súčasťou úlohy bude zavedenie nového Variabilného symbolu 2(VS2) na zmluve, ktorý nebude jedinečný. Pri akcii realizácia vo Virtuálnej karte budú generované nové zmluvy s novým VS. Zákazník bude, ale vždy posielať úhrady VS z pôvodnej zmluvy. VS pôvodnej zmluvy bude zapísaný v stĺpci Variabilný symbol 2 a tým sa zabezpečí párovanie úhrad na pôvodný VS.

==== Logika vyplnenia VS2 ====

Ak pri vytváraní novej konsolidovanej zmluvy (WEBID = 2) a vo Virtuálnej karte nebude mať pôvodná zmluva vyplnený VS2 nová konsolidovaná zmluva bude mať nový VS a VS2 bude VS prebratý z pôvodnej zmluvy.

Ak pri vytváraní novej konsolidovanej zmluvy (WEBID = 3) a vo Virtuálnej karte bude mať pôvodná zmluva vyplnený VS2 nová konsolidovaná zmluva bude mať nový VS a VS2 bude VS2 prebratý z pôvodnej zmluvy.

{| border="1"
|WEBID
|VS
|[mailto:VS@ VS2]
|-

|1
|999
|
|-

|2
|801
|999
|-

|3
|802
|999
|}
==== ====

==== Spracovanie úhrad ====

Pri párovaní úhrad bude zapracovaná nová logika párovania úhrady cez variabilný symbol 2, ktorý bude mat vyššiu prioritu párovania. Systém pri párovaní bude najprv vyhľadávať uvedený VS v zmluvách s vyplneným VS2. Ak sa zmluva s takým VS2 nájde úhrada bude párovaná na najnovšiu zmluvu (ak ich bude viac), ak systém zmluvu s VS2 nenájde bude ju párovať cez variabilný symbol zmluvy ako v súčasnosti.

Zákazník bude uhrádzať splátky s pôvodným VS, ktorý bude zapísaný vo VS2 novej zmluvy a úhrada bude prednostne párovaná na novú zmluvu.

==== Úprava okien ====

V oknách modulu P2P, v ktorých sa nachádza stĺpec variabilný symbol bude pridaný nový stĺpec ''Variabilný symbol 2''. Pôvodný stĺpec variabilný symbol bude zobrazovať hodnotu nasledovne:

1) Ak zmluva nemá VS2 zobrazuje sa VS
1) Ak zmluva má vyplnený VS2 zobrazuje sa VS2

==== Parametre SMS a Email ====

V parametroch pre SMS a Emaily bude zapracovaná úprava pre Variabilný symbol 2

1) Ak zmluva nemá VS2 posiela sa VS
1) Ak zmluva má vyplnený VS2 posiela sa VS2

=== WEBAPI ===

==== Schválenie položky dávky ====

Vznikne nová služba, ktorá bude schvaľovať položku dávky. Zmena stavu z ''Nová'' >> ''Schválená. ''Súčasťou služby bude aj vstup, kde bude CRM posielať VS pre novú zmluvu, ktorá vzniká pri realizácii

'''Vstup služby'''

1) ID položky dávky – povinný údaj
1) VS pre novú zmluvu – povinný údaj
1) WEB_ID produktu – nepovinný údaj

'''Podmienka správneho zápisu'''

1) ID položky dávky musí existovať
1) Platnosť do dávky >= sysdate
1) Položka dávky má stav = Nová
1) VS pre novú zmluvu – nesmie existovať na inej zmluve

'''Výsledok spracovania služby'''

1) Položke dávky sa zmení stav na ''Schválená''
1) Do stĺpca '''''VS novej zmluvy '''''sa zapíše hodnota VS
1) Spustí sa automatická realizácia pre danú zmluvu – produkt sa preberá z pôvodnej zmluvy alebo zo vstupu služby

'''Výstup služby'''

1) 200 OK
1) Zmluva schválená a realizácia dokončená – výstup, ak prebehla realizácia.
1) 500 chyba – popis chyby – bude zahŕňať aj chybu realizácie

=== Tlačové výstupy ===

==== Úprava zostáv pôžičky pri párovaní ====

V zostavách pôžičky pri párovaní bude zapracovaná úprava pre Variabilný symbol 2

1) Ak zmluva nemá VS2 tlači sa VS
1) Ak zmluva má vyplnený VS2 tlači sa VS2
=== Prístupové práva ===

Zapracovaním tejto požiadavky nevzniknú požiadavky na prístupové práva.

=== VIEW ===

==== View dávky ====

V DB vznikne nové VIEW, ktoré bude zobrazovať všetky položky dávky so stĺpcami

1) ID dávky = Id ponuky
1) ID položky dávky
1) Platnosť do dávky
1) WEBID – z importu
1) VS - zobrazenie zo zmluvy podľa WEBID
1) VS2 - zobrazenie zo zmluvy WEBID
1) Dátum - Dátum konsolidácie zmluvy = sysdate importu
1) Suma navýšenia – z importu
1) Stav - Nový/Realizovaný/Schválený
1) Výsledok spracovania – popis spracovania/chyby
1) WEBID novej zmluvy – vyplnené po realizácii
1) VS2 novej zmluvy - pre novú zmluvu vyplnené pôvodné VS
1) Počet splátok novej zmluvy – informatívny stĺpec vypočítaný k dňu importu pre novú zmluvu
1) Zmluvná cena novej zmluvy – informatívny stĺpec vypočítaný k dňu importu pre novú zmluvu
1) Istina novej zmluvy – informatívny stĺpec vypočítaný k dňu importu pre novú zmluvu

== Proces realizácie ==

V procese realizácia bola zapracovaná nová funkčnosť, kde pri vytváraní novej zmluvy, bude vo WEB_ID použitá hodnota WEB_ID z CRM.

== WEBAPI ==

=== POST /virtual_card ===
Služba v sebe obsahuje kroky:
1. Schválenie
2. Realizácia
3. Aktualizácia dát zmluvy
Bola upravená štruktúra existujúcej služby POST /ptp/virtual_card
Model služby obsahuje:
• virtual_card_id – povinný údaj, identifikátor pre realizáciu zmluvy v dávke
• celý endpoint POST /loan – povinnosť údajov podľa endpointu
o WEB_ID, VS, Produkt bude preberaný z POST /loan, z dôvodu duplicity došlo k odstráneniu oproti pôvodnej štruktúre

{{Príklad| Príklad: virtula_card.json

[[https://jira.assecosol.eu/secure/attachment/374114/374114_KTFINANCE-1609+-+virtual_card.json]]
}}

*obsah LOAN sa môže líšiť od aktuálne platnej štruktúry služby POST /loan

Súčasťou realizácie bola zapracovaná nová funkčnosť aktualizácie dát zmluvy, ktoré sú na vstupe služby. Systém pri aktualizácií dát nebude kontrolovať správnosť prijatých dáta voči pôvodnej konsolidovanej zmluve. Za správnosť dát na novej zmluve bude zodpovedať systém, ktorý dáta poslal (CRM). Dáta v časti loan{} je potrebné posielať vždy ako pri volaní POST /loan.

Služby POST /virtual_card a POST /loan sú na seba naviazané a ak dôjde k zmene modelu, zmena sa prejaví v oboch službách.

Virtualna karta

2024-04-10T11:45:55Z

Roman.adamjak:

Add Your Content Here

[[category:PTP (person to person)]]

= Virtuálna karta =

=== Virtuálna karta ===

''[''''Menu] P2P -> Zmluvy -> ''''[''''šípka] Virtuálna karta''

V module P2P vznikne nové okno ''„Virtuálna karta“'' kde budú importované dávky z csv súboru v dohodnutej štruktúre.

Okno bude mať 2 karty:

1) 1.karta ''„Dávka“ ''bude obsahovať stĺpce
1) Dávka – poradové číslo importovanej dávky, generované systémom
1) Dátum a čas importu
1) Používateľ – používateľ, ktorý dávku importoval
1) Platnosť do – určuje platnosť ponuky
1) 2.karta „''Zmluvy''“ stĺpce
1) WEBID – z importu
1) VS - zobrazenie zo zmluvy podľa WEBID
1) VS2 - zobrazenie zo zmluvy WEBID
1) Dátum - Dátum konsolidácie zmluvy = sysdate importu
1) Suma navýšenia – z importu
1) Stav - Nový/Realizovaný
1) Výsledok spracovania – popis spracovania/chyby
1) WEBID novej zmluvy – vyplnené po realizácie
1) '''VS novej zmluvy''' - pre novú zmluvu vyplnené cez služby v CRM – pri importe bude prázdne
1) '''Počet splátok novej zmluvy''' – informatívny stĺpec vypočítaný k dňu importu pre novú zmluvu
1) '''Zmluvná cena''''''novej zmluvy''' – informatívny stĺpec vypočítaný k dňu importu pre novú zmluvu
1) '''Istina novej zmluvy '''– informatívny stĺpec vypočítaný k dňu importu pre novú zmluvu

==== Akcia Import súboru ====

V okne ''Virtuálna karta'' bude nová akcia ''Import súboru'' spustením akcie sa otvorí okno kde bude možnosť prehľadávať cestu k súboru v PC a nastaviť platnosť do(povinný údaj) pre dávku. Stlačení OK sa csv súbor naimportuje ako dávka do okna s definovanou platnosťou do . Naimportovaním súboru vznikne nový záznam dávky s priradenými zmluvami v záložke zmluvy. Pri zmluvách budú vypočítané údaje informatívneho charakteru k dátumu importu - '''Počet splátok novej zmluvy, Zmluvná cena''''''novej zmluvy'''''', ''''''Istina novej zmluvy''''''.'''

Súbor csv s oddeľovačom bodkočiarka v štruktúre súboru:

1) WEBID – WEBID zmluvy, ktorá bude predčasne splatená
1) Suma navýšenia – suma o koľko bude navýšená nová zmluva - Suma navýšenia je hodnota finančného plnenia novej zmluvy.
Príklad

111111;200,50

===== Spracovanie súboru =====
V prípade, chybného WEBID v súbore, podľa ktorého nebude možné zmluvu identifikovať, súbor nebude naimportovaný a používateľ bude o chybe v súbore informovaný. Súbor opraví a spustí import znova.

===== View =====
Pre účely vytvárania ponúk bude vytvorené nove View. Štruktúra popísaná v kapitole View dávky

==== Akcia Zmena stavu ====

V okne ''Virtuálna karta'' bude nová akcia ''Realizácia. ''Akcia bude spúšťaná v záložke zmluvy nad označenými zmluvami z dávky. Akcia bude meniť stav zmlúv z dávky.

Pri spustení akcie používateľ si bude môcť vybrať zo stavov:

1) Nová
1) Zamietnutá

==== Akcia Realizácia ====

V okne ''Virtuálna karta'' bude nová akcia ''Realizácia. ''Akcia bude spúšťaná v záložke zmluvy nad označenými zmluvami z dávky. Akcia spustí realizáciu len nad zmluvami, ktoré majú stav ''„Schválená“ ''a Platnosť dávky do >= sysdate.Spracovaním záznamu sa zmení stav zmluvy v okne na ''„Realizovaný“. ''Akciu nebude možné spúšťať opakovane nad záznamom, ak bol spracovaný. V prípade chyby bude v stĺpci ''Výsledok spracovania'' zapísaná chyba spracovania. Akcia nebude mať spätný chod.

Akcia bude nad označenými zmluvami z dávky vytvárať nové konsolidované zmluvy (pôžičky) s novým číslom a VS. Pôvodná zmluva bude vyrovnaná na 0 s dátumom d-1 z aktuálneho dátumu. Prepojenie Pôvodnej zmluvy a novej konsolidovanej zmluvy bude pomocou nového stĺpca ''Variabilný symbol 2 ''(viď kapitola Variabilný symbol 2). Zákazník bude uhrádzať splátky podľa pôvodného VS. Proces realizácie bude opakovaný v slede zmlúv niekoľkokrát (odhad 3x) záver sa vytvorí konsolidácia cez CRM.

===== Kroky Realizácie =====
Realizáciu bude možné spúšťať ručne pomocou akcie ''Realizácia'' alebo Automaticky ( kroky 1 a 2 ) súčasťou volania webapi schvaľovania.

====== 1. krok - Spustenie ======

Spustením akcie spracovanie na označených zmluvách z dávky sa otvorí okno s vyberačom na produkt (nepovinný údaj).

1) Ak pri spustení bude produkt vyplnený v novej zmluve bude požitý vybraný produkt
1) Ak pri spustení nebude produkt vyplnený na novej zmluve sa použije produkt z pôvodnej zmluvy
====== 2. krok – Vytvorenie novej zmluvy ======

Výberom produktu vzniká nová konsolidovaná zmluva s väzbami na pôvodnú zmluvu. Číslo novej konsolidovanej zmluvy bude pridelené číslo podľa VS, ktoré poslalo CRM cez služby '''. '''Nová zmluva bude mať dátum evidencie = dátum z dávky a nový variabilný symbol z CRM (VS = WEBID) ( v rámci modulu P2P je VS jedinečný). A VS pôvodnej zmluvy sa zapíše do nového stĺpca ''Variabilný symbol 2''(viď kapitola Variabilný symbol 2).

Pôvodná zmluva bude vyrovnaná na 0 a nová zmluva bude mať istinu ako suma zostatku istiny + alikvotný úrok + suma navýšenia. Suma navýšenia(z importu) bude z pravidla hodnota uhradených splátok klientom.

{| border="1"
|VS
|VS2
|Mesiac splátka
|Istina
|Úrok
|-

|999
|
|1
|20
|50
|-

|999
|
|2
|30
|40
|-

|999
|
|3
|40
|30
|-

|999
|
|4
|410
|4
|-

| Nova zmluva
|
|

|
|
|-

|801
|999
|1
|624
|
|}

Istina 624€ na novej zmluve vznikol súčtom 410 + 4 + 210.

Počet splátok novej zmluvy – pri tvorbe novej zmluvy sa bude vypočítavať počet splátok. Poznáme istinu, úročiteľa a výšku splátky. Hľadá sa počet splátok, aby posledná splátka bola nižšia ako hodnota splátky. Príklad výpočtu v súbore.

'''Riešenie je postavene len pre výpočet kalendára anuitný štandard.'''

Prípadné preplatky na pôvodnej zmluve budú vyriešené cez funkčnosť preplatkov a prevedenia preplatku na konsolidovanú zmluvu. Výsledok o realizácii a WEBID novej zmluvy bude zapísaný v stĺpci ''Výsledok spracovania, ''kde bude vyplnený text ''„OK. Vytvorená nová konsolidovaná zmluva“. ''V stĺpci nové WEBID bude zobrazená hodnota novej zmluvy.

====== 3. krok – Párovanie ======

Konsolidovaná zmluva sa spáruje s investíciami. Vznikne finančné plnenie v hodnote navýšenia.

====== 4. krok – Splátkový kalendár ======

Nová konsolidovaná zmluva bude mať nový vypočítaný splátkový kalendár, ktorého výška splátky a úročiteľ ostáva rovnaký ako na pôvodnej zmluve. Variabilný bude počet splátok. Nový splátkový kalendár bude anuitný bez vstupných poplatkov a posledná splátka bude dopočítavaná => nemusí byť rovnaká.

Prvá splátka bude v najbližšom 22. dni mesiaca od dátumu, kedy bola spúšťaná realizácia. Zákazník bude uhrádzať splátky podľa pôvodného VS.

''Príklad''

''Ak bude realizácia bude do 21.6. prvá splátka novej zmluvy bude 22.6 (aktuálny mesiac), ak bude realizácia napr. 22.6. a neskôr prvá splátka novej zmluvy bude 22.7(nasledujúci mesiac).''

====== 5.krok – finančné plnenie ======

Rovnaký princíp ako pri konsolidácii. Pre finančné plnenie novej zmluvy bude vygenerovaná nová faktúra, ktorá bude ponížená finančným saldom v hodnote zostatku pôvodnej zmluvy. A bude vyplatená suma navýšenia z importu.

====== 6.krok – Investori ======

Bez úprav.

====== 7.krok – Provízia ======

Bez úprav. Provízie budú fungovať rovnako ako pri aktuálnej konsolidácii – z navýšenej sumy.

====== ======

=== Variabilný symbol 2 ===

Variabilný symbol zmluvy je jedinečný a nie je možné ho duplikovať/opakovať, Súčasťou úlohy bude zavedenie nového Variabilného symbolu 2(VS2) na zmluve, ktorý nebude jedinečný. Pri akcii realizácia vo Virtuálnej karte budú generované nové zmluvy s novým VS. Zákazník bude, ale vždy posielať úhrady VS z pôvodnej zmluvy. VS pôvodnej zmluvy bude zapísaný v stĺpci Variabilný symbol 2 a tým sa zabezpečí párovanie úhrad na pôvodný VS.

==== Logika vyplnenia VS2 ====

Ak pri vytváraní novej konsolidovanej zmluvy (WEBID = 2) a vo Virtuálnej karte nebude mať pôvodná zmluva vyplnený VS2 nová konsolidovaná zmluva bude mať nový VS a VS2 bude VS prebratý z pôvodnej zmluvy.

Ak pri vytváraní novej konsolidovanej zmluvy (WEBID = 3) a vo Virtuálnej karte bude mať pôvodná zmluva vyplnený VS2 nová konsolidovaná zmluva bude mať nový VS a VS2 bude VS2 prebratý z pôvodnej zmluvy.

{| border="1"
|WEBID
|VS
|[mailto:VS@ VS2]
|-

|1
|999
|
|-

|2
|801
|999
|-

|3
|802
|999
|}
==== ====

==== Spracovanie úhrad ====

Pri párovaní úhrad bude zapracovaná nová logika párovania úhrady cez variabilný symbol 2, ktorý bude mat vyššiu prioritu párovania. Systém pri párovaní bude najprv vyhľadávať uvedený VS v zmluvách s vyplneným VS2. Ak sa zmluva s takým VS2 nájde úhrada bude párovaná na najnovšiu zmluvu (ak ich bude viac), ak systém zmluvu s VS2 nenájde bude ju párovať cez variabilný symbol zmluvy ako v súčasnosti.

Zákazník bude uhrádzať splátky s pôvodným VS, ktorý bude zapísaný vo VS2 novej zmluvy a úhrada bude prednostne párovaná na novú zmluvu.

==== ====

==== Úprava okien ====

V oknách modulu P2P, v ktorých sa nachádza stĺpec variabilný symbol bude pridaný nový stĺpec ''Variabilný symbol 2''. Pôvodný stĺpec variabilný symbol bude zobrazovať hodnotu nasledovne:

1) Ak zmluva nemá VS2 zobrazuje sa VS
1) Ak zmluva má vyplnený VS2 zobrazuje sa VS2

==== Parametre SMS a Email ====

V parametroch pre SMS a Emaily bude zapracovaná úprava pre Variabilný symbol 2

1) Ak zmluva nemá VS2 posiela sa VS
1) Ak zmluva má vyplnený VS2 posiela sa VS2

=== WEBAPI ===

==== Schválenie položky dávky ====

Vznikne nová služba, ktorá bude schvaľovať položku dávky. Zmena stavu z ''Nová'' >> ''Schválená. ''Súčasťou služby bude aj vstup, kde bude CRM posielať VS pre novú zmluvu, ktorá vzniká pri realizácii

'''Vstup služby'''

1) ID položky dávky – povinný údaj
1) VS pre novú zmluvu – povinný údaj
1) WEB_ID produktu – nepovinný údaj

'''Podmienka správneho zápisu'''

1) ID položky dávky musí existovať
1) Platnosť do dávky >= sysdate
1) Položka dávky má stav = Nová
1) VS pre novú zmluvu – nesmie existovať na inej zmluve

'''Výsledok spracovania služby'''

1) Položke dávky sa zmení stav na ''Schválená''
1) Do stĺpca '''''VS novej zmluvy '''''sa zapíše hodnota VS
1) Spustí sa automatická realizácia pre danú zmluvu – produkt sa preberá z pôvodnej zmluvy alebo zo vstupu služby

'''Výstup služby'''

1) 200 OK
1) Zmluva schválená a realizácia dokončená – výstup, ak prebehla realizácia.
1) 500 chyba – popis chyby – bude zahŕňať aj chybu realizácie

=== Tlačové výstupy ===

==== Úprava zostáv pôžičky pri párovaní ====

V zostavách pôžičky pri párovaní bude zapracovaná úprava pre Variabilný symbol 2

1) Ak zmluva nemá VS2 tlači sa VS
1) Ak zmluva má vyplnený VS2 tlači sa VS2
=== Prístupové práva ===

Zapracovaním tejto požiadavky nevzniknú požiadavky na prístupové práva.

=== VIEW ===

==== View dávky ====

V DB vznikne nové VIEW, ktoré bude zobrazovať všetky položky dávky so stĺpcami

1) ID dávky = Id ponuky
1) ID položky dávky
1) Platnosť do dávky
1) WEBID – z importu
1) VS - zobrazenie zo zmluvy podľa WEBID
1) VS2 - zobrazenie zo zmluvy WEBID
1) Dátum - Dátum konsolidácie zmluvy = sysdate importu
1) Suma navýšenia – z importu
1) Stav - Nový/Realizovaný/Schválený
1) Výsledok spracovania – popis spracovania/chyby
1) WEBID novej zmluvy – vyplnené po realizácii
1) VS2 novej zmluvy - pre novú zmluvu vyplnené pôvodné VS
1) Počet splátok novej zmluvy – informatívny stĺpec vypočítaný k dňu importu pre novú zmluvu
1) Zmluvná cena novej zmluvy – informatívny stĺpec vypočítaný k dňu importu pre novú zmluvu
1) Istina novej zmluvy – informatívny stĺpec vypočítaný k dňu importu pre novú zmluvu

== Proces realizácie ==

V procese realizácia bola zapracovaná nová funkčnosť, kde pri vytváraní novej zmluvy, bude vo WEB_ID použitá hodnota WEB_ID z CRM.

== WEBAPI ==

=== POST /virtual_card ===
Služba v sebe obsahuje kroky:
1. Schválenie
2. Realizácia
3. Aktualizácia dát zmluvy
Bola upravená štruktúra existujúcej služby POST /ptp/virtual_card
Model služby obsahuje:
• virtual_card_id – povinný údaj, identifikátor pre realizáciu zmluvy v dávke
• celý endpoint POST /loan – povinnosť údajov podľa endpointu
o WEB_ID, VS, Produkt bude preberaný z POST /loan, z dôvodu duplicity došlo k odstráneniu oproti pôvodnej štruktúre

{{Príklad| Príklad: virtula_card.json

[[https://jira.assecosol.eu/secure/attachment/374114/374114_KTFINANCE-1609+-+virtual_card.json]]
}}

*obsah LOAN sa môže líšiť od aktuálne platnej štruktúry služby POST /loan

Súčasťou realizácie bola zapracovaná nová funkčnosť aktualizácie dát zmluvy, ktoré sú na vstupe služby. Systém pri aktualizácií dát nebude kontrolovať správnosť prijatých dáta voči pôvodnej konsolidovanej zmluve. Za správnosť dát na novej zmluve bude zodpovedať systém, ktorý dáta poslal (CRM). Dáta v časti loan{} je potrebné posielať vždy ako pri volaní POST /loan.

Služby POST /virtual_card a POST /loan sú na seba naviazané a ak dôjde k zmene modelu, zmena sa prejaví v oboch službách.

Faktoring

2024-04-04T08:14:26Z

Roman.adamjak:

KTFINANCE-1489
== Návrh riešenia ==

Požiadavka je na automatizáciu faktoringu.

1) Zápis nakúpených faktúr od dĺžníkov xxx firmy. Firma od ktorej budú faktúry kupované bude zákazník v existujúcom module.
1) Generovanie finančných plnení pre predávajúcu firmu
1) Generovanie splátkových kalendárov
1) Výpočet výnosov pre fond
1) Generovanie výnosových a nákladových faktúr
1) Výpočet pokút pre fond pri neplatičoch
1) Tvorba faktúry za pokutu
1) Dorovnanie pôžičky interným dokladom
Investícia pre túto činnosť sa nahrá pod novým produktom. Následne sa budú importovať dĺžne faktúry v okne faktroring. Pre tieto faktúry sa vygenerujú pôžičky, ktoré sa následne spárujú s investíciami. 2. splátka čaká až na splatenie faktúry do hodnoty celkovej sumy faktúry, ktorá je viditeľná len v okne faktoring. Po úhradení celkovej sumy alebo sumy nad hodnotu istiny sa vypočíta výnos pre fond, ktorý celú transakciu platil – sadzby sú odlišné pre platiča a neplatiča. Posiela sa druhý podiel pre predávajúcu firmu ponížený o interný výnos a výnos fondu. Ak fond nebude v importe – všetko bude interný výnos. Pri existencii fondu sa naimportuje aj hodnota pokuty, vypočíta sa po presiahnutí dátumu splatnosti. Následne sa pôžička dorovná interným dokladom.

=== Okno Faktoring ===

''P2P – Úhrady – šípka – okno Faktoring''

'''Karty: Faktoring, Nastavenia, Sadzby'''

===== Karta Faktoring =====
Zoznam zmlúv, ktoré sa naimportujú akciou import 2.2.1.1.. Zapíšu sa do novej tabulky ptp_faktoring.

Stĺpce:

{| border="1"
|Web_id_klient
|Importom
|-

|Klient
|Zobrazenie z firmy
|-

|Web_id_pôžička
|Vytvorenie pôžičky
|-

|VS_faktura
|Importom
|-

|Suma faktúra
|Importom
|-

|1. splátka %
|Importom
|-

|Istina
|suma faktúry*1.splátka %
|-

|Suma úhrad
|súčet úhrad pôžičky
|-

|Dátum poslednej úhrady
|Zo splátkového kalendára pôžičky
|-

|Rozdiel k faktúre
|Suma faktúry-suma úhrad
|-

|Dátum splatnosti
|Importom
|-

|Odberateľ
|Názov firmy
|-

|1.Splatka
|suma faktúry*1.splatka %
|-

|2. Splatka
|suma faktúry*sadzba
|-

|Výnos fond
|'''sadzba den platič*(posledný deň úhrady-deň úhrady) ak platič''''''ak neplatič sadzba den platič*(posledný deň úhrady-deň splatnosti)+sadzba deň neplatič (dátum úhrady-dátum splatnosť)'''
|-

|Výnos_interny
|Suma úhrady-1.splátka-2.splátka-výnos
|-

|Dátum importu
|sysdate
|-

|Dátum párovania
|z pôžičky
|-

|Faktura 1
|finančné plnenie 1 splatka
|-

|Dátum úhrady
|Dátum úhrady faktúry
|-

|Faktura 2
|finančné plnenie 2. splatka
|-

|Dátum úhrady
|Dátum úhrady faktúry
|-

|Dobropis
|ak akcia vrátenie
|-

|Nákladová faktúra
|číslo faktúry
|-

|Výnosová faktúra
|číslo faktúry
|-

|ček vybanie
|A/N
|-

|Fond
|Importom
|-

|Sadzba odmena fond
|Importom
|-

|Sadzba odmena neplatič
|Importom
|-

|Sadzba overboard
|Importom
|-

|Sadzba deň platič
|(sadzba odmena fond+sadzba overboard)/360*istina
|-

|Sadzba den neplatič
|Sadzba den platič*Sadzba odmena neplatič
|-

|Počet dní omeškania
|Výpočet od dátumu splatnosti po sysdate
|-

|% Pokuta
|Importom
|-

|Faktura pokuta
|číslo faktúry
|-

|Interný doklad
|číslo interného dokladu
|-

|Pôvodný dátum splatnosti
|Importom
|}

===== Karta Nastavenia =====
{| border="1"
| colspan="2" | '''Vyšlá faktúra fond'''
|-

|Druh dokladu
|Vyberač druhov dokladov
|-

|Účtovný druh
|Vyberač účtovných druhov
|-

|Sadzba DPH
|Vyberač typov DPH prijaté
|-

|

|

|-

|'''Vyšlá faktúra'''
|
|-

|Druh dokladu
|Vyberač druhov dokladov
|-

|Účtovný druh
|Vyberač účtovných druhov
|-

|Sadzba DPH
|Vyberač typov DPH prijaté
|-

|

|

|-

|'''Došlá faktúra'''
|

|-

|Druh dokladu
|Vyberač druhov dokladov
|-

|Účtovný druh
|Vyberač účtovných druhov
|-

|Sadzba DPH
|Vyberač typov DPH prijaté
|}

{| border="1"
| colspan="2" | '''Došlá faktúra pokuta'''
|-

|Druh dokladu
|Vyberač druhov dokladov
|-

|Účtovný druh
|Vyberač účtovných druhov
|-

|Sadzba DPH
|Vyberač typov DPH prijaté
|}

{| border="1"
| colspan="3" | '''Interný doklad dorovnanie'''
|-

|Druh dokladu
| colspan="2" | Vyberač druhov dokladov
|-

|Účet MD
| colspan="2" | Vyberač účtu
|-

|Účet D
| colspan="2" | Vyberač účtu
|-

|

| colspan="2" |

|-

| colspan="3" | '''Interný doklad začiatok'''
|-

| colspan="2" | pre fond
|

|-

| colspan="2" | Účet MD
|Vyberač účtu
|-

| colspan="2" | Účet MD
|Vyberač účtu
|-

| colspan="2" | Účet D
|Vyberač účtu
|-

| colspan="2" | Účet D
|Vyberač účtu
|-

| colspan="2" | bez fond
|

|-

| colspan="2" | Účet MD
|Vyberač účtu
|-

| colspan="2" | Účet D
|Vyberač účtu
|}

===== Karta Sadzby =====
{| border="1"
|Názov
|Hodnota
|-

|Firma
|vyberač podľa ICO firiem
|-

|Dni omeskania do
|number
|-

|% 2splatka
|number
|}

V prehľade sa zobrazí:

{| border="1"
|'''ICO'''
|'''Názov firmy'''
|'''Dni omeskania do'''
|'''%2splatka'''
|-

|111
|Lunys
|0
|4
|-

|111
|Lunys
|5
|5
|-

|111
|Lunys
|9999
|7
|-

|222
|CTM
|0
|4
|-

|222
|CTM
|12
|5
|-

|222
|CTM
|9999
|6
|}

=== Akcie v okne Faktoring ===

===== Akcia import =====
Naimportuje položky pre okno faktoring, použije sa csv súbor s bodkočiarkov medzi položkami. Akcia si vyžiada cestu k súboru. Klient bude založený cez CRM.

Potrebné polia:

{| border="1"
|'''Názov'''
|'''Príklad'''
|'''Poznámka'''
|-

|web_id_klient
|12564
|Volksgoup - koho pohľadávky sa kúpia
|-

|VS faktúry
|202301
|číslo faktúry - párovací symbol
|-

|Dátum splatnosti
|15.3.2023
|Dátum splatnosti faktúry
|-

|Suma faktúry
|1000
|Celková suma faktúry
|-

|%istina
|80
|1. podiel = v systéme istina
|-

|ICO dlžníka
|34567897
|pôvodný dĺžnik napr. Lunys
|-

|ICO fond
|22222222
|fond, ktorý požičal peniaze - nie investor
|-

|%odmena fond
|4
|ročná sadzba odmeny pre fond
|-

|%odmenaneplatič
|1,25
|navýšenie sadzby pre neplatiča
|-

|%overboard
|2
|%ktoré sa pripočíta k dennej sadzbe
|-

|Pôvodný dátum splatnosti
|28.2.2023
|Pôvodný dátum splatnosti faktúry
|-

|Počet dni vyhodnotenia
|150
|Dátum, kedy sa stane nevymožiteľnou pre zink
|-

|Percento pokuty
|5
|Pokuta pre fond
|}

===== Akcia generovanie pôžičky =====
Vstupný argument – produkt s výpočtom sk faktoring. Akcia vygeneruje pôžičku pre všetky naimportované záznamy, ktoré nemajú web_id pôžičky. Vytvorí vlastné číslo web_id rok a číslo – 10miestne. Napr. 2023000001. VS bude web_id, vznikne nový VS2, ktorý bude VS faktúry (terajšie VS je jedinečné a VS faktúry sa môže opakovať)

===== Akcia Vrátenie =====
Po stlačení akcie sa kalendár ukončí – urobia sa záporné predpisy a aktuálnym dátumom. Vygeneruje sa dobropis došlej faktúry.

Podmienka pre Vrátenie je

===== Akcia Výpočet a generovanie faktúr =====
'''Akcia kontroluje: '''

1) Celkovú úhradu
1) Úhradu nad istinu + dátum nad splatnosť
1) Dosiahnutie dátumu na vyhodnotenie – dátum splatnosti + počet dní pre vyhodnotenie
Akcia generuje doklady popísané v bode 2.7.

[[Súbor:Fak1.png]]

Príklad výpočtu súm:

[[Súbor:Fak2.png]]

=== Produkt ===

Nastavenie produktu bude nasledovné. Pre splátkový kalendár Faktoring bude možné zadať len s Typom Pôžička, Dodávateľ na DF bude povinne Klient.

Vstupný poplatok bude prednastavený žiadny, rovnako nebude možné čeknúť --Vyžadovaný OZ,-- Povinnosť poplatku... .

OZ bude možné zadať. Doplnené na stretnutí.

[[Súbor:Fak3.png]]

=== Párovanie ===

Pre faktoring bude vytvorená nová skupina produktov.

[[Súbor:Fak4.png]]

Pri párovaní sa vytvorí pre výpočet SK typu Faktoring. Každá faktúra 1 splátka. Dátum splatnosti splátky = dátum splatnosti faktúry.

=== Výpočet SK ===

Pridať nový typ výpočtu SK Faktoring.

[[Súbor:Fak5.png]]

Pri zápise službou sa pripravia jednotlivé výpočty nasledovne:

Istina = Istina

UROK = 0

UROK D = 0

1SPLATKA = v hodnote istiny

SPLATNOSŤ = z importu

Príklad:

Faktúra v hodnote 1000,--

Istina v hodnote 800,--

Splatnosť 15.3.2023

Vygeneruje sa pôžička s jendou splátkou v hodnote 800,-- , Splatnosť 15.3.2023

=== Generovanie finančného plnenia ===

K jednej pôžičke budú generované 2x finančné plnenia.

Prvé finančné plnenie v hodnote 1SPLATKA v čase párovania.

Druhé finančné plnenie akciou Výpočet a generovanie faktúr, ak budú splnené podmienky.

Dobropis – zrušením zmluvy.

Hlavička – ako pri pôžičke:

Firma: klient

Dátumy: sysdate

Dátum splatnosti – splatnosť pri spárovaní sysdate

Bankový účet – klientsky bankový účet s poznámkou #FA

Položky:

Suma – pri prvej faktúre hodnota z 1SPLATKA, pri druhej hodnota z 2SPLATKA, ak bude DPH nastavené pri výnosovej faktúre, tak od 2SPLATKA odpočítať DPH

Položka na zníženie salda sa nebude napĺňať.

Pre dobropis platí ako pri zrušení. Väzba na poslednú faktúru.

=== Generovanie výnosových, nákladových faktúr a interných dokladov ===

===== Interný doklad začiatok =====
Generuje sa s finančným plnením 2.6. pre každý faktoring. Účty sa rozlišujú podľa toho či bude vo faktoringu Fond.

Druh dokladu z nastavenia 2.1.1.2

Dátum účtovania – sysdate

Suma – celková suma faktúry

Pre fond sa vyplnia 4 účty (2xMD a 2x D)

Ak nieje fond použijú sa účty bez fondu (1xMD a 1xD)

===== Výnosová faktúra (odberateľská faktúra) =====
Druh dokladu – z nastavenia 2.1.1.2 podľa toho či je fond alebo nieje. --Generuje sa len ak je fond--. Druhá podmienka je úhrada nad výšku istinya dátum splatnosti menší ako sysdate

Firma – zákazník

Dátum – sysdate

Dátum splatnosti – sysdate

Suma – hodnota interného výnosu+fondu(20)

Účtovný druh

Saldo? nie

===== Nákladová faktúra (dodávateľská faktúra) =====
Systém vygeneruje došlú faktúru. Generuje sa len ak existuje na faktoringu fond. Druhá podmienka je úhrada nad výšku istinya dátum splatnosti menší ako sysdate

Druh dokladu – z nastavenia 2.1.1.2

Firma – fond dodaný importom

Dátum – sysdate

Dátum splatnosti – sysdate

Bankový účet – fondový bankový účet s poznámkou #FA

Účtovný druh

Suma – výnos fondu, len ak je zostatok istiny 0.

Saldo? Áno

===== Faktúra za pokutu (dodávateľská faktúra) =====
Systém vygeneruje došlú faktúru. Pokuta sa generuje, ak úhrada neexistuje alebo je menšia v čase vyhodnotenia ako istina. Nastáva až v čase dátumu vyhodnotenia (dátum splatnosti+počet dní pre vyhodnotenie)

Druh dokladu – z nastavenia 2.1.1.2

Firma – fond dodaný importom

Dátum – sysdate

Dátum splatnosti – sysdate

Bankový účet – fondový bankový účet s poznámkou #FA

Suma – suma pokuty (%pokuty*istina) maximum do výšky zostatku pokuty

Účtovný druh

Saldo? Áno

===== Interný doklad na konci =====
Generuje sa, ak úhrada neexistuje alebo je menšia v čase vyhodnotenia ako istina. Nastáva až v čase dátumu vyhodnotenia (dátum splatnosti+počet dní pre vyhodnotenie)

Systém vygeneruje interný doklad

Druh dokladu – z nastavenia 2.1.1.2

Účet 1xMD a 1x D podľa nastavenia 2.1.1.2.

Dátum účtovania– sysdate

Suma - suma faktúry

===== Sumarizácia podmienok generovania dokladov =====
[[Súbor:Fak6.png]]

=== Neplatiči ===

Pre prepočet neplatičov produkt s výpočtom Faktoring nebude vchádzať. Nedá sa vypočítať počet splátok a ani jednotlivé joby.

Vytvorí sa nová záložka Faktoring.

Zobrazia sa všetky neuhradené splátky faktoringu položkovite. Do neplatičov vstupuje zmluva, ktorá nemá uhradenú sumu faktúry a k sysdate je po splatnosti.

Stĺpce:

WEB_ID – web_id zmluvy

Meno klienta – spoločnosť, ktorá pohľadávku predala

Meno pôvodného klienta vo firme

Adresa pôvodného klienta vo firme

Mail pôvodného klienta vo firme

Telefón pôvodného klienta vo firme

Suma splátky

Splatnosť splátky

Suma úhrady

Počet dní po splatnosti

=== Spracovanie úhrady ===

Upraviť spracovanie úhrady, ak existuje VS2 páruje sa prioritne na VS2.

=== ZZP ===

Bude možná len akcia vrátenie popísaná v bode 2.2.1.3

=== Provízie ===

Na daný produkt sa nebudú vyplácať provízie.

=== Dátový model ===

{| border="1"
|'''PTP_FAKTORING'''
|

|

|

|-

|Názov
|Typ
|Povinné
|Popis
|-

|ID
|NUMBER
|Y
|Id faktoring
|-

|WEB_ID_KLIENT
|NUMBER
|N
|id klienta
|-

|WEB_ID_ZMLUVA
|NUMBER
|N
|Id_zmluva po generovaní
|-

|CISLO_FA
|NUMBER
|Y
|číslo faktoringovej faktúry
|-

|SUMA_FA
|NUMBER
|Y
|suma faktoringovej faktúry
|-

|DATUM_SPLATNOST
|DATE
|Y
|dátum splatnosti faktúry
|-

|DATUM_SPLATNOST_POVOD
|DATE
|Y
|pôvodný dátum splatnosti faktúry
|-

|DATUM_IMPORT
|DATE
|Y
|sysdate dátum importu
|-

|DNI_VYHODNOTENIA
|DATE
|Y
|počet dní pre vyhodnotenie, ak neplatič
|-

|PERCENTO_1SPLATKA
|NUMBER
|Y
|% prvej splátky
|-

|PERCENTO_2SPLATKA
|NUMBER
|N
|% druhej splátky podľa sadzieb
|-

|PERCENTO_POKUTA
|NUMBER
|N
|%pokuty pre fond pri nezaplatení
|-

|FIRMA_ID_DLZNIK
|NUMBER
|Y
|Id firmy dlžníka z importu
|-

|FIRMA_ID_FOND
|NUMBER
|Y
|id firmy fondu
|-

|SUMA_1SPLATKA
|NUMBER
|Y
|suma prvej splátky
|-

|SUMA_2SPLATKA
|NUMBER
|Y
|suma druhej splátky
|-

|SADZBA_DEN_PLATIC
|NUMBER
|N
|denná sadzba výnosu fondu platič
|-

|SADZBA_DEN_PLATIC
|NUMBER
|N
|denná sadzba výnosu fondu neplatič
|-

|VYNOS_FOND
|NUMBER
|N
|výnos pre fond
|-

|VYNOS_INTERNY
|NUMBER
|N
|výnos interny
|-

|1SPLATKA
|NUMBER
|Y
|1. splátka
|-

|2SPLATKA
|NUMBER
|N
|2. splátka
|-

|EP_ID_FA1
|NUMBER
|N
|ep_id faktúry 1
|-

|EP_ID_FA2
|NUMBER
|N
|ep_id faktúry 2
|-

|EP_ID_FA_vynos
|NUMBER
|N
|ep_id faktúry 2
|-

|EP_ID_FA_naklad
|NUMBER
|N
|ep_id faktúry 2
|-

|EP_ID_FA_dobropis
|NUMBER
|N
|ep_id faktúry dobropisu
|}

[[category:PTP (person to person)]]

Súbor:Fak6.png

2024-04-04T08:11:35Z

Roman.adamjak:

Súbor:Fak5.png

2024-04-04T08:11:17Z

Roman.adamjak:

Súbor:Fak4.png

2024-04-04T08:10:59Z

Roman.adamjak:

Súbor:Fak3.png

2024-04-04T08:10:45Z

Roman.adamjak:

Súbor:Fak2.png

2024-04-04T08:10:12Z

Roman.adamjak:

Súbor:Fak1.png

2024-04-04T08:09:48Z

Roman.adamjak:

Faktoring

2024-04-04T08:05:38Z

Roman.adamjak: Vytvorená stránka „KTFINANCE-1489 == Návrh riešenia == Požiadavka je na automatizáciu faktoringu. 1) Zápis nakúpených faktúr od dĺžníkov xxx firmy. Firma od ktorej budú fa…“

KTFINANCE-1489
== Návrh riešenia ==

Požiadavka je na automatizáciu faktoringu.

1) Zápis nakúpených faktúr od dĺžníkov xxx firmy. Firma od ktorej budú faktúry kupované bude zákazník v existujúcom module.
1) Generovanie finančných plnení pre predávajúcu firmu
1) Generovanie splátkových kalendárov
1) Výpočet výnosov pre fond
1) Generovanie výnosových a nákladových faktúr
1) Výpočet pokút pre fond pri neplatičoch
1) Tvorba faktúry za pokutu
1) Dorovnanie pôžičky interným dokladom
Investícia pre túto činnosť sa nahrá pod novým produktom. Následne sa budú importovať dĺžne faktúry v okne faktroring. Pre tieto faktúry sa vygenerujú pôžičky, ktoré sa následne spárujú s investíciami. 2. splátka čaká až na splatenie faktúry do hodnoty celkovej sumy faktúry, ktorá je viditeľná len v okne faktoring. Po úhradení celkovej sumy alebo sumy nad hodnotu istiny sa vypočíta výnos pre fond, ktorý celú transakciu platil – sadzby sú odlišné pre platiča a neplatiča. Posiela sa druhý podiel pre predávajúcu firmu ponížený o interný výnos a výnos fondu. Ak fond nebude v importe – všetko bude interný výnos. Pri existencii fondu sa naimportuje aj hodnota pokuty, vypočíta sa po presiahnutí dátumu splatnosti. Následne sa pôžička dorovná interným dokladom.

=== Okno Faktoring ===

''P2P – Úhrady – šípka – okno Faktoring''

'''Karty: Faktoring, Nastavenia, Sadzby'''

===== Karta Faktoring =====
Zoznam zmlúv, ktoré sa naimportujú akciou import 2.2.1.1.. Zapíšu sa do novej tabulky ptp_faktoring.

Stĺpce:

{| border="1"
|Web_id_klient
|Importom
|-

|Klient
|Zobrazenie z firmy
|-

|Web_id_pôžička
|Vytvorenie pôžičky
|-

|VS_faktura
|Importom
|-

|Suma faktúra
|Importom
|-

|1. splátka %
|Importom
|-

|Istina
|suma faktúry*1.splátka %
|-

|Suma úhrad
|súčet úhrad pôžičky
|-

|Dátum poslednej úhrady
|Zo splátkového kalendára pôžičky
|-

|Rozdiel k faktúre
|Suma faktúry-suma úhrad
|-

|Dátum splatnosti
|Importom
|-

|Odberateľ
|Názov firmy
|-

|1.Splatka
|suma faktúry*1.splatka %
|-

|2. Splatka
|suma faktúry*sadzba
|-

|Výnos fond
|'''sadzba den platič*(posledný deň úhrady-deň úhrady) ak platič''''''ak neplatič sadzba den platič*(posledný deň úhrady-deň splatnosti)+sadzba deň neplatič (dátum úhrady-dátum splatnosť)'''
|-

|Výnos_interny
|Suma úhrady-1.splátka-2.splátka-výnos
|-

|Dátum importu
|sysdate
|-

|Dátum párovania
|z pôžičky
|-

|Faktura 1
|finančné plnenie 1 splatka
|-

|Dátum úhrady
|Dátum úhrady faktúry
|-

|Faktura 2
|finančné plnenie 2. splatka
|-

|Dátum úhrady
|Dátum úhrady faktúry
|-

|Dobropis
|ak akcia vrátenie
|-

|Nákladová faktúra
|číslo faktúry
|-

|Výnosová faktúra
|číslo faktúry
|-

|ček vybanie
|A/N
|-

|Fond
|Importom
|-

|Sadzba odmena fond
|Importom
|-

|Sadzba odmena neplatič
|Importom
|-

|Sadzba overboard
|Importom
|-

|Sadzba deň platič
|(sadzba odmena fond+sadzba overboard)/360*istina
|-

|Sadzba den neplatič
|Sadzba den platič*Sadzba odmena neplatič
|-

|Počet dní omeškania
|Výpočet od dátumu splatnosti po sysdate
|-

|% Pokuta
|Importom
|-

|Faktura pokuta
|číslo faktúry
|-

|Interný doklad
|číslo interného dokladu
|-

|Pôvodný dátum splatnosti
|Importom
|}

===== Karta Nastavenia =====
{| border="1"
| colspan="2" | '''Vyšlá faktúra fond'''
|-

|Druh dokladu
|Vyberač druhov dokladov
|-

|Účtovný druh
|Vyberač účtovných druhov
|-

|Sadzba DPH
|Vyberač typov DPH prijaté
|-

|

|

|-

|'''Vyšlá faktúra'''
|
|-

|Druh dokladu
|Vyberač druhov dokladov
|-

|Účtovný druh
|Vyberač účtovných druhov
|-

|Sadzba DPH
|Vyberač typov DPH prijaté
|-

|

|

|-

|'''Došlá faktúra'''
|

|-

|Druh dokladu
|Vyberač druhov dokladov
|-

|Účtovný druh
|Vyberač účtovných druhov
|-

|Sadzba DPH
|Vyberač typov DPH prijaté
|}

{| border="1"
| colspan="2" | '''Došlá faktúra pokuta'''
|-

|Druh dokladu
|Vyberač druhov dokladov
|-

|Účtovný druh
|Vyberač účtovných druhov
|-

|Sadzba DPH
|Vyberač typov DPH prijaté
|}

{| border="1"
| colspan="3" | '''Interný doklad dorovnanie'''
|-

|Druh dokladu
| colspan="2" | Vyberač druhov dokladov
|-

|Účet MD
| colspan="2" | Vyberač účtu
|-

|Účet D
| colspan="2" | Vyberač účtu
|-

|

| colspan="2" |

|-

| colspan="3" | '''Interný doklad začiatok'''
|-

| colspan="2" | pre fond
|

|-

| colspan="2" | Účet MD
|Vyberač účtu
|-

| colspan="2" | Účet MD
|Vyberač účtu
|-

| colspan="2" | Účet D
|Vyberač účtu
|-

| colspan="2" | Účet D
|Vyberač účtu
|-

| colspan="2" | bez fond
|

|-

| colspan="2" | Účet MD
|Vyberač účtu
|-

| colspan="2" | Účet D
|Vyberač účtu
|}

===== Karta Sadzby =====
{| border="1"
|Názov
|Hodnota
|-

|Firma
|vyberač podľa ICO firiem
|-

|Dni omeskania do
|number
|-

|% 2splatka
|number
|}

V prehľade sa zobrazí:

{| border="1"
|'''ICO'''
|'''Názov firmy'''
|'''Dni omeskania do'''
|'''%2splatka'''
|-

|111
|Lunys
|0
|4
|-

|111
|Lunys
|5
|5
|-

|111
|Lunys
|9999
|7
|-

|222
|CTM
|0
|4
|-

|222
|CTM
|12
|5
|-

|222
|CTM
|9999
|6
|}

=== Akcie v okne Faktoring ===

===== Akcia import =====
Naimportuje položky pre okno faktoring, použije sa csv súbor s bodkočiarkov medzi položkami. Akcia si vyžiada cestu k súboru. Klient bude založený cez CRM.

Potrebné polia:

{| border="1"
|'''Názov'''
|'''Príklad'''
|'''Poznámka'''
|-

|web_id_klient
|12564
|Volksgoup - koho pohľadávky sa kúpia
|-

|VS faktúry
|202301
|číslo faktúry - párovací symbol
|-

|Dátum splatnosti
|15.3.2023
|Dátum splatnosti faktúry
|-

|Suma faktúry
|1000
|Celková suma faktúry
|-

|%istina
|80
|1. podiel = v systéme istina
|-

|ICO dlžníka
|34567897
|pôvodný dĺžnik napr. Lunys
|-

|ICO fond
|22222222
|fond, ktorý požičal peniaze - nie investor
|-

|%odmena fond
|4
|ročná sadzba odmeny pre fond
|-

|%odmenaneplatič
|1,25
|navýšenie sadzby pre neplatiča
|-

|%overboard
|2
|%ktoré sa pripočíta k dennej sadzbe
|-

|Pôvodný dátum splatnosti
|28.2.2023
|Pôvodný dátum splatnosti faktúry
|-

|Počet dni vyhodnotenia
|150
|Dátum, kedy sa stane nevymožiteľnou pre zink
|-

|Percento pokuty
|5
|Pokuta pre fond
|}

===== Akcia generovanie pôžičky =====
Vstupný argument – produkt s výpočtom sk faktoring. Akcia vygeneruje pôžičku pre všetky naimportované záznamy, ktoré nemajú web_id pôžičky. Vytvorí vlastné číslo web_id rok a číslo – 10miestne. Napr. 2023000001. VS bude web_id, vznikne nový VS2, ktorý bude VS faktúry (terajšie VS je jedinečné a VS faktúry sa môže opakovať)

===== Akcia Vrátenie =====
Po stlačení akcie sa kalendár ukončí – urobia sa záporné predpisy a aktuálnym dátumom. Vygeneruje sa dobropis došlej faktúry.

Podmienka pre Vrátenie je

===== Akcia Výpočet a generovanie faktúr =====
'''Akcia kontroluje: '''

1) Celkovú úhradu
1) Úhradu nad istinu + dátum nad splatnosť
1) Dosiahnutie dátumu na vyhodnotenie – dátum splatnosti + počet dní pre vyhodnotenie
Akcia generuje doklady popísané v bode 2.7.

[[Image:]]

Príklad výpočtu súm:

[[Image:]]

=== Produkt ===

Nastavenie produktu bude nasledovné. Pre splátkový kalendár Faktoring bude možné zadať len s Typom Pôžička, Dodávateľ na DF bude povinne Klient.

Vstupný poplatok bude prednastavený žiadny, rovnako nebude možné čeknúť --Vyžadovaný OZ,-- Povinnosť poplatku... .

OZ bude možné zadať. Doplnené na stretnutí.

[[Image:]]

=== Párovanie ===

Pre faktoring bude vytvorená nová skupina produktov.

[[Image:]]

Pri párovaní sa vytvorí pre výpočet SK typu Faktoring. Každá faktúra 1 splátka. Dátum splatnosti splátky = dátum splatnosti faktúry.

=== Výpočet SK ===

Pridať nový typ výpočtu SK Faktoring.

[[Image:]]

Pri zápise službou sa pripravia jednotlivé výpočty nasledovne:

Istina = Istina

UROK = 0

UROK D = 0

1SPLATKA = v hodnote istiny

SPLATNOSŤ = z importu

Príklad:

Faktúra v hodnote 1000,--

Istina v hodnote 800,--

Splatnosť 15.3.2023

Vygeneruje sa pôžička s jendou splátkou v hodnote 800,-- , Splatnosť 15.3.2023

=== Generovanie finančného plnenia ===

K jednej pôžičke budú generované 2x finančné plnenia.

Prvé finančné plnenie v hodnote 1SPLATKA v čase párovania.

Druhé finančné plnenie akciou Výpočet a generovanie faktúr, ak budú splnené podmienky.

Dobropis – zrušením zmluvy.

Hlavička – ako pri pôžičke:

Firma: klient

Dátumy: sysdate

Dátum splatnosti – splatnosť pri spárovaní sysdate

Bankový účet – klientsky bankový účet s poznámkou #FA

Položky:

Suma – pri prvej faktúre hodnota z 1SPLATKA, pri druhej hodnota z 2SPLATKA, ak bude DPH nastavené pri výnosovej faktúre, tak od 2SPLATKA odpočítať DPH

Položka na zníženie salda sa nebude napĺňať.

Pre dobropis platí ako pri zrušení. Väzba na poslednú faktúru.

=== Generovanie výnosových, nákladových faktúr a interných dokladov ===

===== Interný doklad začiatok =====
Generuje sa s finančným plnením 2.6. pre každý faktoring. Účty sa rozlišujú podľa toho či bude vo faktoringu Fond.

Druh dokladu z nastavenia 2.1.1.2

Dátum účtovania – sysdate

Suma – celková suma faktúry

Pre fond sa vyplnia 4 účty (2xMD a 2x D)

Ak nieje fond použijú sa účty bez fondu (1xMD a 1xD)

===== Výnosová faktúra (odberateľská faktúra) =====
Druh dokladu – z nastavenia 2.1.1.2 podľa toho či je fond alebo nieje. --Generuje sa len ak je fond--. Druhá podmienka je úhrada nad výšku istinya dátum splatnosti menší ako sysdate

Firma – zákazník

Dátum – sysdate

Dátum splatnosti – sysdate

Suma – hodnota interného výnosu+fondu(20)

Účtovný druh

Saldo? nie

===== Nákladová faktúra (dodávateľská faktúra) =====
Systém vygeneruje došlú faktúru. Generuje sa len ak existuje na faktoringu fond. Druhá podmienka je úhrada nad výšku istinya dátum splatnosti menší ako sysdate

Druh dokladu – z nastavenia 2.1.1.2

Firma – fond dodaný importom

Dátum – sysdate

Dátum splatnosti – sysdate

Bankový účet – fondový bankový účet s poznámkou #FA

Účtovný druh

Suma – výnos fondu, len ak je zostatok istiny 0.

Saldo? Áno

===== Faktúra za pokutu (dodávateľská faktúra) =====
Systém vygeneruje došlú faktúru. Pokuta sa generuje, ak úhrada neexistuje alebo je menšia v čase vyhodnotenia ako istina. Nastáva až v čase dátumu vyhodnotenia (dátum splatnosti+počet dní pre vyhodnotenie)

Druh dokladu – z nastavenia 2.1.1.2

Firma – fond dodaný importom

Dátum – sysdate

Dátum splatnosti – sysdate

Bankový účet – fondový bankový účet s poznámkou #FA

Suma – suma pokuty (%pokuty*istina) maximum do výšky zostatku pokuty

Účtovný druh

Saldo? Áno

===== Interný doklad na konci =====
Generuje sa, ak úhrada neexistuje alebo je menšia v čase vyhodnotenia ako istina. Nastáva až v čase dátumu vyhodnotenia (dátum splatnosti+počet dní pre vyhodnotenie)

Systém vygeneruje interný doklad

Druh dokladu – z nastavenia 2.1.1.2

Účet 1xMD a 1x D podľa nastavenia 2.1.1.2.

Dátum účtovania– sysdate

Suma - suma faktúry

===== Sumarizácia podmienok generovania dokladov =====
[[Image:]]

=== Neplatiči ===

Pre prepočet neplatičov produkt s výpočtom Faktoring nebude vchádzať. Nedá sa vypočítať počet splátok a ani jednotlivé joby.

Vytvorí sa nová záložka Faktoring.

Zobrazia sa všetky neuhradené splátky faktoringu položkovite. Do neplatičov vstupuje zmluva, ktorá nemá uhradenú sumu faktúry a k sysdate je po splatnosti.

Stĺpce:

WEB_ID – web_id zmluvy

Meno klienta – spoločnosť, ktorá pohľadávku predala

Meno pôvodného klienta vo firme

Adresa pôvodného klienta vo firme

Mail pôvodného klienta vo firme

Telefón pôvodného klienta vo firme

Suma splátky

Splatnosť splátky

Suma úhrady

Počet dní po splatnosti

=== Spracovanie úhrady ===

Upraviť spracovanie úhrady, ak existuje VS2 páruje sa prioritne na VS2.

=== ZZP ===

Bude možná len akcia vrátenie popísaná v bode 2.2.1.3

=== Provízie ===

Na daný produkt sa nebudú vyplácať provízie.

=== Dátový model ===

{| border="1"
|'''PTP_FAKTORING'''
|

|

|

|-

|Názov
|Typ
|Povinné
|Popis
|-

|ID
|NUMBER
|Y
|Id faktoring
|-

|WEB_ID_KLIENT
|NUMBER
|N
|id klienta
|-

|WEB_ID_ZMLUVA
|NUMBER
|N
|Id_zmluva po generovaní
|-

|CISLO_FA
|NUMBER
|Y
|číslo faktoringovej faktúry
|-

|SUMA_FA
|NUMBER
|Y
|suma faktoringovej faktúry
|-

|DATUM_SPLATNOST
|DATE
|Y
|dátum splatnosti faktúry
|-

|DATUM_SPLATNOST_POVOD
|DATE
|Y
|pôvodný dátum splatnosti faktúry
|-

|DATUM_IMPORT
|DATE
|Y
|sysdate dátum importu
|-

|DNI_VYHODNOTENIA
|DATE
|Y
|počet dní pre vyhodnotenie, ak neplatič
|-

|PERCENTO_1SPLATKA
|NUMBER
|Y
|% prvej splátky
|-

|PERCENTO_2SPLATKA
|NUMBER
|N
|% druhej splátky podľa sadzieb
|-

|PERCENTO_POKUTA
|NUMBER
|N
|%pokuty pre fond pri nezaplatení
|-

|FIRMA_ID_DLZNIK
|NUMBER
|Y
|Id firmy dlžníka z importu
|-

|FIRMA_ID_FOND
|NUMBER
|Y
|id firmy fondu
|-

|SUMA_1SPLATKA
|NUMBER
|Y
|suma prvej splátky
|-

|SUMA_2SPLATKA
|NUMBER
|Y
|suma druhej splátky
|-

|SADZBA_DEN_PLATIC
|NUMBER
|N
|denná sadzba výnosu fondu platič
|-

|SADZBA_DEN_PLATIC
|NUMBER
|N
|denná sadzba výnosu fondu neplatič
|-

|VYNOS_FOND
|NUMBER
|N
|výnos pre fond
|-

|VYNOS_INTERNY
|NUMBER
|N
|výnos interny
|-

|1SPLATKA
|NUMBER
|Y
|1. splátka
|-

|2SPLATKA
|NUMBER
|N
|2. splátka
|-

|EP_ID_FA1
|NUMBER
|N
|ep_id faktúry 1
|-

|EP_ID_FA2
|NUMBER
|N
|ep_id faktúry 2
|-

|EP_ID_FA_vynos
|NUMBER
|N
|ep_id faktúry 2
|-

|EP_ID_FA_naklad
|NUMBER
|N
|ep_id faktúry 2
|-

|EP_ID_FA_dobropis
|NUMBER
|N
|ep_id faktúry dobropisu
|}

[[category:PTP (person to person)]]