Potřebovala bych udělat webovou aplikaci na zobrazení platebních údajů k obecním poplatkům na základě RČ (GDPR mám pořešeno, nebojte).
Z hlediska FE k tomu jsem schopná dodat zadání včetně chybových stavů, texty mám, obrázek mám (v canvě).
Potřebuju vytvořit volání do agendového systému a nastavit pár podmínek (pokud občan nemá zaplaceno, zobrazí se podklady k platbě a qr kód, pokud tam je nějaká nesrovnalost z minula, zobrazí upozornění, ať člověk nakluše na úřad, pokud je vše OK, zobrazí se, že je vše OK).
Mám k tomu komunikační protokol a popis rozhraní. SOAP web service, Microsoft.NET Framework.
To vypadá jako hezký malý projekt! Řešíte nějak autentizaci toho člověka? Čili je kromě rodného čísla potřeba ještě nějak prokázat, že jsem to já? A nechceš sem pro představu a inspiraci hodit i ten obrázek? Držím palce!
Líbí se mi, že Brno to má v rámci aplikace BrnoID. A rovnou se to tam dá i zaplatit kartou.
Petře, nějak tak to má ten portál středočeského kraje? Že tam má člověk svůj účet?
K Brnu…ještě víc by se mi teda líbilo, kdyby využívalo potenciál té aplikace naplno, například na zaplaceného poplatku za odpady je navázaná dotace na roční šalinkartu. I když si oboje pořizuju přes BrnoID, není tam automatický check - máš zaplacené poplatky, dostáváš rovnou slevu. Musíš podat žádost o dotaci, ta se ze systému odešle, ale pak čekáš, až ji někde někdo schválí a pošle ti peníze na účet. Příklad pro optimalizaci.
To myslím že nemá. Co jsem namátkou koukal, tak jsou tam různé typy formulářů pro různé typy poplatků a pravděpodobně i pro různé typy procesů (kdy každá obec to může mít trochu jinak).
Ahoj, klidne mi napis na Slacku a rad se na to podivam. Docela me zajima to navazani na RC, nezda se mi, ze by verejne pristupne API agendoveho systemu vydavalo personalizovane info na rodne cislo (spis tam to RC nebude hrat roli).
Stačí zjistit, že za ně dlužíš, což samo o sobě není ideální. Musíš vědět rodné číslo, ale když budu vědět datum narození, tak už zbývá jen čtyřčíslí na konci, takže 10 tisíc možností pro kontrolu hrubou silou. Asi by aspoň stálo za to zjistit, jestli to volané API má nějaký rate limiting, který by to vyřešil.
Zní to jako věc, která by šla udělat čistě na klientovi (HTML + JavaScript), což by bylo super, protože by to mělo naprosto minimální nároky na hosting (jde snadno zařídit zdarma). Záleží na detailech toho volaného agendového API, zejména na tom, jestli je autentizované. A taky záleží na tom, jestli má Zu nějakou existující infrastrukturu, do které by se jim to hodilo nasadit.
@mwenisch, dejte vědět, jestli jste si plácli – a pokud ne, hoď sem technické detaily, ať se toho případně pak může ujmout někdo jiný? Díky!
Neřeší. Portál není propojený s agendovým systémem. Umožňuje poplatek zaplatit, člověk musí znát platební údaje včetně VS – a to je právě u nás ten problém, protože máme VS neodvoditelný z dalších údajů a pro lidi je poměrně náročné platební údaje uchovávat.
Cestou je samozřejmě i změnit způsob přidělování VS, ale to není tak jednoduchá změna.
Jsem si vědoma toho, že zjištění nesrovnalosti (ne nutně nedoplatku) citlivý vstup je, ošetření API na počet volání je dobrý point. Co se týče samotného zobrazení takto citlivých údajů na základě RČ, balanční test k tomu mám a je to OK.
OT: Platební portál SčK toto zatím neumí, ale právě jsme dokončili přihlášení přes NIA, dalším krokem bych rád nahrávání předpisů plateb. Portál už využívá Vysočina: https://www.platbyvysocina.cz/ a nově se připojuje Plzeň, tak věřím, že se rozvoj zrychlí.
U nás taky na to narazil portál Středočeského kraje nemožnost vlastního vs symbolu. Takže je pro města nepoužitelný nebo tedy přesněji řečeno nezautomatizovatelny. = víc práce než užitku
Plátce ten VS propisuje do formuláře u platby, toto pole se pak propíše do údajů bankovního převodu, platba přijde na účet obce a zde ji spáruje obecní ERP (Triada, Helios…)
