Aplikace pro AO a PO (evidence členů)

[Lukas.Novy]

Houby, předpisy neříkají nic o tom, jakým způsobem mají odbory efektivně vést svoji agendu, naopak jim v tom ponechávají jistou volnost a co se technických prostředků týče, určují jen něco málo.

Urcite dulezite zabrany tam jsou:

StAO píše:
§1 Působnost administrativního odboru
(2) Administrativní odbor výlučně

a) vede seznam členů (§14 JdŘ) a seznam funkcí,
c) spravuje členské příspěvky (§5 PrP).

Seznam členů se vede na internetovém fóru a sestává ze všech lidí zahrnutých do skupiny Celostátní fórum (§7(4)a StTO).
§2 Seznam členů

(1) Administrativní odbor může vedle seznamu členů vést další podpůrnou evidenci (§3(3)c StTO).

StTO:
§7 Internetové fórum

(1) Fórum je autoritativní systém pro vedení seznamu členů, seznamu funkcí, správu přístupových oprávnění a hesel pro systémy strany.

Z tohoto ustanoveni PO nesmi vest seznam clenu ani funkci a nesmi spravovat clenske prispevky. Musi ji vest AO a musi ji vest prostrednictvim fora a dalsi system si muze zridit na spravu kontaktu na cleny, ale muze to udelat i ve foru.

[Martin.Kucera]

Z tohoto ustanoveni PO nesmi vest seznam clenu ani funkci a nesmi spravovat clenske prispevky.

Však taky PO ten seznam nepovede (tj. nebude mít oprávnění k úpravě příslušných položek).

Musi ji vest AO a musi ji vest prostrednictvim fora

To, že se seznam členů a funkcí bude z fóra přenášet do další podpůrné aplikace, nijak předpisy neporušuje.

[Lukas.Novy]

To, že se seznam členů a funkcí bude z fóra přenášet do další podpůrné aplikace, nijak předpisy neporušuje.

Vzhledem k tomu, ze je ty informace mozne ziskavat online, neni pro to zadny duvod, staci kdyz se to bude v rozhrani zobrazovat.

[Martin.Kucera]

Z ERD tedy pujde pryc (nesmi tam byt): cely User, Group, Function, Area, Membership a Payment. Tez je nevhodne tam mit PeopleGroup (to se ma resit triggerem v phpbb).

Z ERD půjde pryč jen to, co tam nesmí být dle předpisů.
Payment tam rozhodně zůstane, stejně tak People Group, stejně tak Membership (nic z toho fórum neumí dostatečně pro naše potřeby a bastlit ve spreadsheetu se to nebude).

[Lukas.Novy]

Payment je v ucetnictvi, online pristupne. PeopleGroup (historie clenstvi ve skupine) klidne dobastlim je to za 10 minut hotovo a bude to stejne jako Membership opet pristupne online.

Kdyz tam budete mit kopie, tak musite delat synchronizaci pravidelnou, coz neni nikdy trivialni task.

[Martin.Kucera]

Payment je v ucetnictvi, online pristupne.

Je mi jedno odkud se to bude do té aplikace načítat, pokud se to bude zobrazovat správně (a co přesně znamená "v účetnictví, onlině dostupné"? link, pls)

PeopleGroup (historie clenstvi ve skupine) klidne dobastlim je to za 10 minut hotovo a bude to stejne jako Membership opet pristupne online.

A bude možné tam zpětně doplnit celou již proběhlou historii?
Membership (všechny údaje v ERD, tedy i datum podání přihlášky, datum hlasování o přijetí, jména hlasujících) je přístupné online? Kde?

[Stanislav.Stipl]

Payment je v ucetnictvi, online pristupne. PeopleGroup (historie clenstvi ve skupine) klidne dobastlim je to za 10 minut hotovo a bude to stejne jako Membership opet pristupne online.

Payment je v ucetnictvi/na transparentnim uctu, ale chybi tam naparovani na clena. Paruje se to rucne. Hruza.
PeopleGroup neni jen o historii clenstvi ve skupine, ale take o terminech pro svolavani, ktere se v soucasne dobe vedou rucne na wiki https://www.pirati.cz/ao/terminy
Membership je treba aktualizovat na zaklade Payment.

Kdyz tam budete mit kopie, tak musite delat synchronizaci pravidelnou, coz neni nikdy trivialni task.

Pokud je jeden ze systemu Master a druhy Slave, je to celkem easy.

[Lukas.Novy]

Payment je v ucetnictvi/na transparentnim uctu, ale chybi tam naparovani na clena. Paruje se to rucne. Hruza.

Mno v ucetnictvi stejne k bankovnimu prevodu vytvorit vydanou fakturu, kterou to prevede na spravny vynosovy ucet. V te kdyz bude spravne uveden subjekt, ktery v uzivatelske vazbe spravne uvedeno user_id, tak mas po problemu. (resp. se to uctuje bud casovym rozlisenim nebo zalohovym danovym dokladem po zaplaceni a zapoctem faktury na konci).

PeopleGroup neni jen o historii clenstvi ve skupine ale take o terminech pro svolavani,

To je velice spatny napad. Datum svolani se vubec nesouvisi s lidmy, jeho dalsi nastaveni zavysi na datu volby do organu jakozto procesu nikoliv na clenstvi v nem.

Membership je treba aktualizovat na zaklade Payment.

Nelze, jednak to nezalezi jenom na payment (potrebujes jeste prijeti predsednictvem) a druhak ti membership nekonci promeskanim lhuty ale vzetim na vedomi.

Pokud je jeden ze systemu Master a druhy Slave, je to celkem easy.

Pokud je to master-slave, tak opravdu nema smysl si ty data tahat k sobe, kdyz z GraphAPI je ziskam vzdycky aktualni a pravdepodobne i rychleji.

[Stanislav.Stipl]

Payment je v ucetnictvi/na transparentnim uctu, ale chybi tam naparovani na clena. Paruje se to rucne. Hruza.

Mno v ucetnictvi stejne k bankovnimu prevodu vytvorit vydanou fakturu, kterou to prevede na spravny vynosovy ucet. V te kdyz bude spravne uveden subjekt, ktery v uzivatelske vazbe spravne uvedeno user_id, tak mas po problemu. (resp. se to uctuje bud casovym rozlisenim nebo zalohovym danovym dokladem po zaplaceni a zapoctem faktury na konci).

A kdo asi bude doplnovat do ucetnictvi user_id? Ted je rucni dohledavani plateb oser, tak vymyslime jeste vetsi oser. Kdo bude clena upozornovat, ze ma zalplatit? Jak se organ dozvi, ze ma vzit na vedomi ukonceni clenstvi?

PeopleGroup neni jen o historii clenstvi ve skupine ale take o terminech pro svolavani,

To je velice spatny napad. Datum svolani se vubec nesouvisi s lidmy, jeho dalsi nastaveni zavysi na datu volby do organu jakozto procesu nikoliv na clenstvi v nem.

No kazdemu volenemu funkcionari nekdy konci mandat. Nevidim zasadni problem vazat to na lidi. Ale ok, muzem to vazat na organy, proc ne. Kde to najdu v phpbb?

Membership je treba aktualizovat na zaklade Payment.

Nelze, jednak to nezalezi jenom na payment (potrebujes jeste prijeti predsednictvem) a druhak ti membership nekonci promeskanim lhuty ale vzetim na vedomi.

Podle payment se aktualizuje datum posledhiho zaplaceni clenskeho prispevku. Na zaklade toho bude AO/PKS/PMS vedet, do kdy ma clen zaplaceno a provest patricne kroky. Samozrejme aplikace sama nemuze ukoncit nekomu clenstvi.

Pokud je jeden ze systemu Master a druhy Slave, je to celkem easy.

Pokud je to master-slave, tak opravdu nema smysl si ty data tahat k sobe, kdyz z GraphAPI je ziskam vzdycky aktualni a pravdepodobne i rychleji.

Je to master-slave, ale muze se stat, ze se jednou role master a slave prohodi.

[Petr.Vileta]

Payment je v ucetnictvi/na transparentnim uctu, ale chybi tam naparovani na clena. Paruje se to rucne. Hruza.

Tak ono to někdy ani jinak nejde, fakt hrůza.

EDIT: ale z Flexibee to půjde přes API vysosat přes "zakázku", která bude přesně odpovídat číslu rozpočtové položky. Jen ta jména jsou stringy. Jestli bys měl nápad, jak to v účetnictví udělat jednoznačně navázané na jméno, tak se ozvi. Poptám se na možnosti v Alvariu.