.Pirátská strana » Technické oddělení

ad 5) U smazaných účtů a vůbec u účtů chceme hisoricky uchovávat výpisy transakcí, které už neposkytuje (nezobrazuje) banka (starší dvou let, zrušené)
Asi by bylo fajn mít uložená i dispoziční práva (což je něco trošku jiného než propláceč)
Jinak leda jestli Aleš Krupa něco chce.

ad 3) já to smažu, nechám odkaz.

ad 5) jakákoliv transakce, která se stáhne z banky, už zůstává v databázi piroplacení, takže toto je otázka obecně záloh databáze, čili zde ok
dispoziční práva tam jsou, viz např: https://piroplaceni.pirati.cz/banka/ucet/22/ ; je to jen volný text bez vazby na propláceče a jeho historie se nearchivuje; stačí to takto?

Historické znamená třeba z roku 2016 hluboko před Piroplácením.
Nevím, jestli nějaké takové máme, ale pokud ano, bylo by záhodno je tam přidat.
Musí vědět Aleš.

Ok vidím že propláceči a dispoziční práva jsou odděleni, takže za mě ok.
Možná, mohli by jsme tam mít i IBAN, nebo nějaké další systémové údaje?

Vojtech Pikal napsal:

Ok vidím že propláceči a dispoziční práva jsou odděleni, takže za mě ok.
Možná, mohli by jsme tam mít i IBAN, nebo nějaké další systémové údaje?

Údaje možno doplnit libovolně .. .jaké konkrétně potřebujeme ? (Jde jen o evidenci nebo to má mít i nějaké návaznosti v systému ?)

přimlouvám se za minimalistický přístup, čili do informací kolem účtu bych dával jen to, pro co máme v současnosti reálné využití, ať nespravujeme balastní zátěž...

Ahoj,

souhlasím s Jarmilem, osobně taky dávám přednost minimalistickému přístupu.

Jen je potřeba vyřešit pár věcí:

• ve wiki byl seznam účtů, kde se u aktivních účtů odkazovalo na Fio banku a u neaktivních (zrušených) účtů jsem do odkazu začal nahrávat pdf výpisy za rok 2018. Jelikož už ve wiki účty nejsou, bylo by z hlediska transparentnosti u zrušených účtů potřeba změnit odkaz na online výpis tak, aby odkazoval na ty pdf výpisy
• za mě by bylo ideální odlišit aktivní účty (prvních osm), od účtů "zmražených" (to jsou účty ze senátních voleb, se kterými se nesmí disponovat po určitou dobu, nebo účty rezervní připravené na použití ve volbách) a od účtů zrušených - to je ten zbytek. Třeba odlišnou barvou čísla účtu??
• hlavně bych byl rád, kdyby se při zadávání žádostí, záměrů a rozpočtových položek nabízely jen ty účty, ze kterých se reálně smí platit, tzn. v současnosti prvních 5. 3lo by nastavit nějakým parametrem, např. existuje-li propláceč, nabízet? U těch neaktivních bych smazal všechny propláceče...

To je zatím jen pár námětů k bankovním účtům :-)

Mějte se,

Aleš

V tom případě potřebujem sledovat "stav" účtu, přičemž existuje několik stavů, řekl bych:
1) Aktivní - účet, který existuje a může se s ním nakládat
2) Zmražený - účet, který existuje, ale nesmí se s ním nakládat
3) Neaktivní - účet, který excistuje, může se s ním nakládat, ale nemá aktuálně daný účel a nenakládá se s ním
4) Zrušený - účet, který již neexistuje ale je třeba k němu uchovat údaje a historii

Stav ovlivňuje jak a kdo může s účtem nakládat ve smyslu z něj proplácet apod.
(Nejsem si jist, jestli potřebujeme rozlišovat 2 a 3, asi to lze řešit poznámkou/názvem, ale osobně bych preferoval nějaký nastavený softwarový časový zámek u takového zmraženého účtu.)

Taky potřebujem tedy účty propojit s nějakým úložištěm jejich výkazů. Buď se to nechá na wiki, nebo na to budem používat mrak.

část hotova: udělal jsem export seznamu bankovních účtů jako CSV, kód zde:
https://gitlab.com/photonStar/piroplaceni/tree/rm18014
nasazení prosím řešit s Martinem :)

Ahoj,

za mě je sloučení 2 a 3 na "neaktivní" vyhovující, stejně tak odkaz na výpisy v textu - místo odkaz do fio bude jen odkaz na výpisy v nějakém úložišti.
Ano,"aktivní" účet znamená, že se z něho dá platit v Piroplácení, tzn. nabízí se v seznamu účtů.
Naproti tomu "neaktivní" účty jsou - účty zmrazené - ty, se kterými se ze zákona nesmí nějakou dobu nakládat, a neaktivní, tzn. ty, ze kterých se nesmí platit (alespoň v rámci Piroplácení), což je třeba účet darů, členských příspěvků, spořící účet apod. a nebo rezervní účty, které se budou časem využívat např.jako volební. Tzn. "neaktivní" znamená neaktivní v Piroplácení, ve skutečnosti se ale může využívat např. pro převody mezi našimi účty.

Pokud jde o časový zámek, tak nevidím momentálně jeho nutnost. Například u těch účtů ze senátních voleb platí termín do poloviny dubna, pak z nich buď převedu zůstatky na spořící účet, nebo u těch, kde má dojít k vypořádání s koaličními partnery změním stav z neaktivní na aktivní a přes Piroplácení vyplatíme podíly.

Mějte se fajn a díky!

Aleš

Ahojte,

díky za diskusi, ale slučování stavů opravdu není dobrý nápad. Již jenom během dvou příspěvků je vidět, že je potřeba dovysvětlení toho, co znamená neaktivní. Ten systém musí informace obsahovat pokud možno kompletní, a nikoliv komprimované a závislé na předávaném know-how :-)

Stavy, jak je navrhuje Vojta, jsou vzájemně ortogonální, tj. lze je zavést bez problému. Naopak by mě ještě zajímal ten stav účtu, kdy účet nepoužívám v Piroplácení, ale jinak "vedle" můžu ... ? To přece vůbec neodpovídá cíli aplikace, tj. poskytovat transparentní a úplné informace nejen veřejnosti, ale i členům !

Ohledně časové blokace - je velice vhodné tam mít napsáno, do kdy jsou ty účty blokovány, a že takový stav mohou některé účty mít - někteří totiž ani neví, že zákon nějakou takovou situaci vyžaduje.

Zdraví
Martin

Ahoj,

mě je jedno, jestli jsou tři nebo čtyři stavy účtů.
Účty aktivní platební - Provozní - výdaje, Dlouhodobí dodavatelé, Mzdy, Volební EP, Volební doplňovací senát.
Účty, které se nepoužívají v Piroplácení, ale jsou aktivní: Spořící, Dary a státní příspěvky, Členské příspěvky.
Časová blokace - klidně jí tam dejte.

Díky,

Aleš Krupa

Martine, imho nejde o slučování stavů, ale o rozšíření funkčnosti Piroplacení vůči tomu, co tam je teď (tj. jeden stav). V minimální variantě by úplně stačilo aspoň toto:
1) aktivní účet (tento stav mají nyní všechny účty v pp)
2) neaktivní účet (nový stav, kdy jsou zakázány aktivní operace (tj nenabízí se k proplácení, nedělá se export příkazů do banky, ale stahují se transakce, zobrazuje se jinou barvou, jsou vidět transakce)

Časový zámek a další informace (jakým způsobem je účet blokován a dokdy) se u neaktivního účtu mohou napsat do poznámky.
pokud to takto neporušuje zákon (a v čem by porušovalo?) a nezpůsobí to budoucí problém v databázi (nedovedu si představit jaký), tak bych to takto implementoval a další rozšíření přidával až podle potřeby.
lepší dobré řešení teď než geniální "někdy časem".

Vidíš-li to jinak, tak prosím specifikuj jak má být výsledný stav: soupis stavů, kdo je může přepínat, jaké operace pp povoluje v jednotlivých stavech.
Rovněž časový zámek, má-li být implementován, by si zasloužil trochu podrobnější specifikaci.

OK, čekám tedy na Martinovu specifikaci k diskuzi.

Zatím bych poprosil Vojtu o vrácení původní podstránky s účty a výpisy pod odkaz Ostatní účty . staré, volební, zrušené.

Aleš

Co se týče převodů, které nejsou v Piroplácení, tak se může jednat o převody prostředků mezi účty pro naplnění (typicky z provozního na volební) - fyzický převod (virtuálních) peněz pro doplnění účtu - to se v minulosti dělalo a dělá bez žádosti, bo k tomu není ani hospodář, na tož záměr.
(Obdobně stažení prostředků z volebního účtu po rozmražení.)

Dalším takovým převodem bývaly automatické převody úroků ze spořícího na provozní účet, což se nastavý někde v bankovnictví a pak to jede samo.

Vojtech Pikal napsal:

Co se týče převodů, které nejsou v Piroplácení, tak se může jednat o převody prostředků mezi účty pro naplnění (typicky z provozního na volební) - fyzický převod (virtuálních) peněz pro doplnění účtu - to se v minulosti dělalo a dělá bez žádosti, bo k tomu není ani hospodář, na tož záměr.
(Obdobně stažení prostředků z volebního účtu po rozmražení.)

Dalším takovým převodem bývaly automatické převody úroků ze spořícího na provozní účet, což se nastavý někde v bankovnictví a pak to jede samo.

+1, děkuji :-)

Pokud má Piroplácení naplnit původní cíl, tj. aby to byla samostatná aplikace bez nutnosti mít účetní firmu (pro malé uživatele), tak je potřeba sledovat i tyto věci minimálně na úrovni transakcí, abychom dokázali dát dohromady skutečný stav bankovních účtů.

Následně totiž můžeme dělat audit bankovního zůstatku dle banky a porovnávat s Piroplácením - což může např. upozornit na to, že někdo dělá s bankovními účty něco, co by neměl.

Martin Rejman napsal:

Bude 5 stavů:
1) Aktivní - účet, který existuje a může se s ním nakládat
2) Zmražený dočasně - důvod se napíš do poznámky, datum odmražení se napíše do k tomu určeného datového pole - pokud se překročí datum odmražení, účty se probarví v seznamu účtů
3) Zmražený - účet, který existuje, ale nesmí se s ním nakládat (důvod zmražení se napíše do poznámky)
4) Neaktivní - účet, který excistuje, může se s ním nakládat, ale nemá aktuálně daný účel a nenakládá se s ním
5) Zrušený - účet, který již neexistuje ale je třeba k němu uchovat údaje a historii

prosím ještě dospecifikovat:
ad 2: znamená to tedy že po překročení data odmražení se účet automaticky přepne do stavu 1 ? Nebo do jiného?
ad 4: účet, se kterým se může nakládat ... ale nenakládá se s ním: to zní dost mysticky :) :) co to přesně znamená z hlediska logiky aplikace: chápu to tak že se nemá nabízet tam, kde se vybírá, za jakého účtu proplatit žádost, a jinak se chová jako aktivní (stav 1). Nebo ještě něco jiného?

ad 2 a 3: jde pouze o zákonnou povinnost pro politické strany nebo to zmražení musí mít ještě někdo další? ptám se kvůli běžícímu rozšiřování pp pro další subjekty (svj, města...)

ad všecko: kdo všechno se k tomu musí ještě vyjádřit/odsouhlasit, aby to bylo možno brát za "ready to implement"?

Jarmile,

ad2 - dočasně zmražený je volební účet, se kterým se ze zákona nesmí 180 dní nakládat. To je pro politické strany, jestli může existovat obdoba i u obcí netuším.
ad3 - nesmí se s ním nakládat v Piroplácení, tedy nenabízí se ??

Aleš

Jarmil Halamíček napsal:

Martin Rejman napsal:

Bude 5 stavů:
1) Aktivní - účet, který existuje a může se s ním nakládat
2) Zmražený dočasně - důvod se napíš do poznámky, datum odmražení se napíše do k tomu určeného datového pole - pokud se překročí datum odmražení, účty se probarví v seznamu účtů
3) Zmražený - účet, který existuje, ale nesmí se s ním nakládat (důvod zmražení se napíše do poznámky)
4) Neaktivní - účet, který excistuje, může se s ním nakládat, ale nemá aktuálně daný účel a nenakládá se s ním
5) Zrušený - účet, který již neexistuje ale je třeba k němu uchovat údaje a historii

prosím ještě dospecifikovat:
ad 2: znamená to tedy že po překročení data odmražení se účet automaticky přepne do stavu 1 ? Nebo do jiného?
ad 4: účet, se kterým se může nakládat ... ale nenakládá se s ním: to zní dost mysticky :) :) co to přesně znamená z hlediska logiky aplikace: chápu to tak že se nemá nabízet tam, kde se vybírá, za jakého účtu proplatit žádost, a jinak se chová jako aktivní (stav 1). Nebo ještě něco jiného?

ad 2 a 3: jde pouze o zákonnou povinnost pro politické strany nebo to zmražení musí mít ještě někdo další? ptám se kvůli běžícímu rozšiřování pp pro další subjekty (svj, města...)

ad všecko: kdo všechno se k tomu musí ještě vyjádřit/odsouhlasit, aby to bylo možno brát za "ready to implement"?

Ahoj, k bodům výše:
2) samo se to nikdy nikam nepřepíná. Jak píšu, pouze se to probarví jinou barvou.
3) (a případně i ostatní) ... ve výběrech se pro kohokoliv kromě FINMANa zobrazují pouze aktivní účty.

2 a 3) ... i když to máme jako politická strana, může to využít i někdo jiný. Obecně nebudeme chtít dělat výjimky v programovém kódu, zejména nikoliv v datovém modelu :-) Jestli se uživatelům schová nějaká kolonka při vyplňování, to přípustné je ...

Myslím, že takto už je specifikace kompletní, ohledně implementace je pak potřeba udržet stejnou štábní kulturu např. pro vytváření "výčtových" polí (je tam na to udělátko).

Snad stačí takto, zdraví
Martin

Martin Rejman napsal:

2) samo se to nikdy nikam nepřepíná. Jak píšu, pouze se to probarví jinou barvou.

Tedy z pohledu uživatele půjde po překročení data odmražení vlastně o šestý stav
6) Zmrazen, ale měl by se už odmrazit.

Stavy 2) 3) a 6) se budou lišit pouze barvou zobrazení, a vypsáním data, kdy zmrazení vypršelo/vyprší. Jiné funkční rozlišení tam není, je to tak?

V programu budou vlastně 3) a 6) pouze jakési podstavy stavu 2), které se liší obsahem položky "zmrazení vyprší dne" (2=nulová, 3=datum dnešní nebo v buducnosti, 6=datum v minulosti).

Interně bych tedy stavy 2), 3) a 6) sloučil do jednoho a rozlišoval je jen jak výše uvedeno, už kvůli tomu že nemůže vzniknout inkonzistence v databázi typu: "účet je ve stavu 3, ale datum zmrazení nebylo nastaveno".
Sorry že se na tom točím, ale ten účet se bude chovat jako stavový stroj a ty je třeba specifikovat přesně (a žádoucí je držet počet stavů na minimum, kvůli počtu hran).

2 a 3) ... i když to máme jako politická strana, může to využít i někdo jiný...

spiš ne, uživatel nebude chápat rozdíl mezi stavy 2, 3 a 4, všechno jsou to účty, se kterými nemůže manipulovat.

3) (a případně i ostatní) ... ve výběrech se pro kohokoliv kromě FINMANa zobrazují pouze aktivní účty

Nerozumím tomuto: FINMAN tedy může proplatit žádost i z účtu (dočasně) zmraženého nebo neaktivního? Nebo jaký je jiný důvod k tomu, aby se mu to zobrazovalo?

Jarmil Halamíček napsal:

Martin Rejman napsal:

2) samo se to nikdy nikam nepřepíná. Jak píšu, pouze se to probarví jinou barvou.

Tedy z pohledu uživatele půjde po překročení data odmražení vlastně o šestý stav
6) Zmrazen, ale měl by se už odmrazit.

Jenže ty nevíš, jestli se to má odmrazit, a někdo to musí udělat. Samotná aplikace prostě měnit data automaticky nesmí.

Stavy 2) 3) a 6) se budou lišit pouze barvou zobrazení, a vypsáním data, kdy zmrazení vypršelo/vyprší. Jiné funkční rozlišení tam není, je to tak?

Stavy jsou různé proto, že uživatel, když bude vybírat, tak má možnost určit, která data se pak musí povinně vyplnit (datum odmražení).

V programu budou vlastně 3) a 6) pouze jakési podstavy stavu 2), které se liší obsahem položky "zmrazení vyprší dne" (2=nulová, 3=datum dnešní nebo v buducnosti, 6=datum v minulosti).

Nikoliv, významově mohou být ty stavy jiné. To je již na uživateli, jak to bude používat.

Interně bych tedy stavy 2), 3) a 6) sloučil do jednoho a rozlišoval je jen jak výše uvedeno, už kvůli tomu že nemůže vzniknout inkonzistence v databázi typu: "účet je ve stavu 3, ale datum zmrazení nebylo nastaveno".

Konzistenci musí hlídat aplikace kvůli tomu, že uživatel musí dostat upozornění, že dělá něco špatně, a právě proto máme redundantní stavy, abychom to uměli ohlídat.

Sorry že se na tom točím, ale ten účet se bude chovat jako stavový stroj a ty je třeba specifikovat přesně (a žádoucí je držet počet stavů na minimum, kvůli počtu hran).

Optimalizovat kód je kontraproduktivní vzhledem k budoucím požadavkům rozvoje.

2 a 3) ... i když to máme jako politická strana, může to využít i někdo jiný...
spiš ne, uživatel nebude chápat rozdíl mezi stavy 2, 3 a 4, všechno jsou to účty, se kterými nemůže manipulovat.

OK, klidně to tam dělat nemusíš, já to tedy pak předělám, a začlením tak, aby to souhlasilo s ostatním programem. Pak ale začleňování změn může trvat déle.

3) (a případně i ostatní) ... ve výběrech se pro kohokoliv kromě FINMANa zobrazují pouze aktivní účty
Nerozumím tomuto: FINMAN tedy může proplatit žádost i z účtu (dočasně) zmraženého nebo neaktivního? Nebo jaký je jiný důvod k tomu, aby se mu to zobrazovalo?

FINMAN nic neproplácí, je to správce systému, který občas potřebuje něco upravit, a nastavovat mu hard limity tohoto typu se neosvědčilo. Pokud to někdo nezvládá, tak tu roli mít prostě nemůže.

so?

já již neřeším, přebral si to Martin.

Určitě, IMHO na úrovni nice-to-have.

Prosím o update. Díky!