Ero sivun ”Lataamon ohjeet” versioiden välillä
(22 välissä olevaa versiota samalta käyttäjältä ei näytetä) | |||
Rivi 17: | Rivi 17: | ||
** Fyysinen avain joudutaan pyytämään kuitenkin takaisin | ** Fyysinen avain joudutaan pyytämään kuitenkin takaisin | ||
* '''Ulkopuoliselle annetut poletit''' | * '''Ulkopuoliselle annetut poletit''' | ||
− | ** Esim. huollolle tai siivoukselle annettu avain menee tänne | + | ** Esim. huollolle tai siivoukselle annettu avain menee tänne - polettiin ei liity tällöin jäsentietoa |
AUTENTIKAATIOTUNNISTE | AUTENTIKAATIOTUNNISTE | ||
Rivi 24: | Rivi 24: | ||
CREDITOR | CREDITOR | ||
* '''Tapahtuman tägit''' | * '''Tapahtuman tägit''' | ||
+ | ** Tapahtumien tyyppien hallinta: avainmaksu, jäsenmaksu jne. | ||
* '''Tapahtumat''' | * '''Tapahtumat''' | ||
+ | ** Lista kaikista taphtumista, joita on joko saapnut (debit) tai joita odotetaan saavamme (credit) | ||
+ | ** Päivämäärä on hetki siitä, kun tieto on rekisteriöity kantaan | ||
* '''Toistuvat tapahtumat''' | * '''Toistuvat tapahtumat''' | ||
Rivi 46: | Rivi 49: | ||
− | == Tapahtuma | + | == Tapahtuma, toistuva tapahtuma ja saldo == |
+ | |||
+ | ''Termit debit ja credit eivät esiinny Lataamossa suoraan näillä nimillä, tämä on kirjanpidollisesta käytännöstä tulevaa termistöä.'' | ||
Tapahtumalla tarkoitetaan maksutapahtumaa, joka voi olla joko: | Tapahtumalla tarkoitetaan maksutapahtumaa, joka voi olla joko: | ||
Rivi 53: | Rivi 58: | ||
Etumerkki määrää täysin, kummasta on kyse. | Etumerkki määrää täysin, kummasta on kyse. | ||
− | Toistuva tapahtuma on jäsenkohtainen ajastettava uusia tapahtumia luova käsky, joka aktivoituu sille asetetun toistuvuusvälin mukaan. Tapahtumia voi myös tehdä itse manuaalisesti tarvittaessa, mutta pääosin lähes kaikki tapahtumat luodaan toistuvien tapahtumien kautta. Toistuvalla tapahtumalla on aikaväli, joka määrää, onko toistuvuus voimassa. | + | Toistuva tapahtuma on jäsenkohtainen ajastettava uusia tapahtumia luova käsky, joka aktivoituu sille asetetun toistuvuusvälin mukaan. Tapahtumia voi myös tehdä itse manuaalisesti tarvittaessa, mutta pääosin lähes kaikki tapahtumat luodaan toistuvien tapahtumien kautta. Toistuvalla tapahtumalla on aikaväli, joka määrää, onko toistuvuus voimassa. '''Toistuvat tapahtumat ovat käytännössä aina miinusmerkkisiä, plusmerkkinen on varmastikin virhekirjaus.''' |
Toistuva tapahtuman muokkaus ei vaikuta aiempien tuotettujen tapahtumien historiaan. Muutos maksun määrään vaikuttaa vain siitä hetkestä alkaen, kun muutos on tehty. Yleensä on fiksumpaa toimia siten, että maksun määrän muokkaamisen sijaan, lopetetaan vanha toistuva tapahtuma voimassaoloajalla ja tehdään uusi toistuva tapahtuma uudella aloitushetkellä. Tämä pitää historian ymmärrettävämpänä. | Toistuva tapahtuman muokkaus ei vaikuta aiempien tuotettujen tapahtumien historiaan. Muutos maksun määrään vaikuttaa vain siitä hetkestä alkaen, kun muutos on tehty. Yleensä on fiksumpaa toimia siten, että maksun määrän muokkaamisen sijaan, lopetetaan vanha toistuva tapahtuma voimassaoloajalla ja tehdään uusi toistuva tapahtuma uudella aloitushetkellä. Tämä pitää historian ymmärrettävämpänä. | ||
Rivi 60: | Rivi 65: | ||
* rekisteri kuvaa varsinkin sisääntulevien (+ debit) maksujen osalta vain sellaista tilaa, jossa rahaa on oikeasti liikkunut jäseneltä meidän tilille | * rekisteri kuvaa varsinkin sisääntulevien (+ debit) maksujen osalta vain sellaista tilaa, jossa rahaa on oikeasti liikkunut jäseneltä meidän tilille | ||
* vältetään tietueiden poistoa, ellei kyse ole virheen vuoksi syntyneestä tilanteesta | * vältetään tietueiden poistoa, ellei kyse ole virheen vuoksi syntyneestä tilanteesta | ||
− | * tietyissä | + | * tietyissä korjaustilanteissa voi olla paras ratkaisu esimerkiksi merkitä tapahtuma nollaksi euroksi, esim. jos credit on joskus ollut olemassa, mutta sille ei odoteta enää vastaavaa debittiä, koska jäsen vapautetaan maksusta jonkin perusteen vuoksi |
− | * jokaista sisääntulevaa (+ debit) maksua kohden on sitä vastaava odotettu maksusuorite (- credit) | + | * ihannetilanteessa jokaista sisääntulevaa (+ debit) maksua kohden on sitä vastaava odotettu maksusuorite (- credit) samalla viitteellä - jos plusmerkkisiä on jäsenellä enemmän kuin oletetaan, niin virhe on todennäköisesti meidän puolella, tai sitten jäsen maksaa tietämättään liikaa - miinusmerkkisiä sen sijaan on usein enemmän kuin debittejä, koska tieto tapahtumista siirtyy viiveellä uusia tiedostolatauksia odotellessa |
* rekisteristä ilmenee luotettavasti ja totuudemukaisesti jäsenmaksuliikenne sellaisena, kuin se näkyy myös tiliotteella, eikä sinne kuulu tämän ulkopuolisia tapahtumia | * rekisteristä ilmenee luotettavasti ja totuudemukaisesti jäsenmaksuliikenne sellaisena, kuin se näkyy myös tiliotteella, eikä sinne kuulu tämän ulkopuolisia tapahtumia | ||
* korjaussummat ym. ovat vältettävä ratkaisumalli, niitä ei oikeastaan saisi käyttää koskaan - jos debittejä ei oleteta saatavan, mieluummin nollataan niitä koskevat creditit | * korjaussummat ym. ovat vältettävä ratkaisumalli, niitä ei oikeastaan saisi käyttää koskaan - jos debittejä ei oleteta saatavan, mieluummin nollataan niitä koskevat creditit | ||
+ | * korjataan tapahtuman aikaansaanut toistuva tapahtuma, mikäli muutos toistuu tästä eteenpäin - jos muutos koskee vain mennyttä aikaa, eikä tulevia uusia tilanteita, niin toistuvan tapahtuman muokkausta ei tehdä | ||
+ | * joihinkin määrittelmättömiin erikoistilanteisiin saattaa olla tarpeen käyttää nollamääräistä toistuvaa tapahtumaa, tätä voi harkita joihinkin tilanteisiin | ||
+ | |||
+ | Saldo on jäsenen debit- ja credit-tapahtumien etumerkit huomioiva summa. Tämä luku kuvaa sitä, onko jäsenen saatavien ja saapuneiden maksujen balanssi negatiivinen, positiviinen tai usein myös nolla. Nollatulos on tavoiteltavin tilanne, se kertoo, että jäsnen maksutiedot vastaavat saapuneiden ja odotettujen maksujen osalta samaa euromäärää. Tyypillisesti luku on usein negatiivinen sen vuoksi, että toteutuneiden debit-maksutapahtumien lataaminen pankista kestää aikaa, ja tällä välin on ehtinyt ajastua uusi kierros toistuvia credit-tapahtumia. | ||
+ | |||
+ | Saldo on määritelty jäsenmallissa seuraavasti (huom. kuten näkyy, se ei huomioi viitenumeroiden vastaavuutta debitin ja creditin välillä, vaan tekee suoraviivaisen yhteenlaskun kaikista tapahtumista) | ||
− | == | + | @property |
+ | def credit(self): | ||
+ | ret = self.creditor_transactions.all().aggregate(models.Sum('amount'))['amount__sum'] | ||
+ | if ret == None: | ||
+ | return Decimal(0.0) | ||
+ | return ret | ||
+ | |||
+ | === Laskut ja muistutukset === | ||
+ | Järjestelmässä ei ole erillistä laskutuksen tietomallia ja sen vuoksi ei myöskään laskuihin liittyvää kuvailutietoa tai laskuhistoriaa. Tästä johtuen Lataamon lähettämissä emaileissa ns. "laskut" ovat käytännössä saldoilmoituksia, eivät laskuja, ja siksi niissä '''ei ole järjellistä eräpäivätietoa'''. Saldomuistutuksissa "eräpäivän" kohdalla käytetään credit-tapahtuman luontihetkeä, joka on usein jo ehtinyt olla menneisyydessä ennen kuin viestit päätyvät jäsenelle. Tämä on tiedostettu ongelma ja vaatisi kehittämistä. | ||
+ | |||
+ | Aliohjelma ''velkoja'' sisältää automaattisen maksumuistutusohjelma, joka käy läpi saldoja ja lähettää muistutuksia puuttuvista suoritteista jäsenelle merkittyyn emailiin. 2022 alkaen puuttuvien maksujen tiedoista koostetaan yksi email, joka sisältää listan puuttuvista maksuista. Tähän käytetään saldomäärää ja maksujen viitevastaavuuden päättelyä, mikä ei ehkä mene aina oikein, jos maksutiedoissa on paljon epäselvyyksiä. | ||
+ | |||
+ | Kts. lisää projektista: | ||
+ | project/velkoja/nordeachecker.py/NordeaOverdueInvoicesHandler | ||
+ | list_overdue() jne. | ||
+ | https://github.com/HelsinkiHacklab/asylum/blob/hhl_changes/project/velkoja/nordeachecker.py | ||
+ | |||
+ | === Viitenumerot === | ||
+ | |||
+ | Viitenumeroiden generoitumisesta jotain jne... | ||
+ | |||
+ | == Jäsenen muokkaus == | ||
+ | Jäsentyyppejä voi olla voimassa useita samanaikaisesti. Käytössä on pääasiassa vain tyypit jäsen ja avainjäsen. Tällä hetkellä '''järjestelmä ei edellytä tai pakota näitä tietoja oikein''', vaan henkilöllä voi olla avainjäsenmaksu, vaikka ei olisi merkitty avainjäseneksi jäsentyypissä. Määräämällä jäsenelle jäsentyypin tai tyypit, on helpompaa selata ja löytää listaukset tietyistä jäsentyypeistä. | ||
+ | |||
+ | Kommentit jäsenen tiedoissa on pyrittävä pitämään mahdollisimman minimaalisina ja '''vain jäsenyyden hoitamiseen liittyviin asioihin''', jotka auttavat tulkitsemaan muita jäsentietojen kirjauksia. Esimerkiksi sovitut poikkeukset maksujen osalta tai vaihtoehtoiset yhteystiedot. | ||
+ | |||
+ | Jäsenem muokkauksen kautta on mahdollista editoida poletteja ym. tietoja, mutta ne ovat löydettävissä myös omilta sivuiltaan pitkänä listauksena kaikilta jäseniltä yhteensä. | ||
+ | |||
+ | === Maksut === | ||
Jäsenen maksutietojen lukuohje: | Jäsenen maksutietojen lukuohje: | ||
+ | * nimiö-tiedon voi ohittaa, toistuvalla tapahtumalla ei käytännössä voii olla yksilöivää nimeä | ||
+ | * järjestelmä huolehtii viitenumeroista itse, ne luodaan vasta varsinaisen tapahtuman luomisen hetkellä | ||
+ | * sarake määrä on lähes ilman poikkeusta '''aina negatiivinen''' (credit) | ||
+ | * virhetilanne voi syntyä myös siitä, että maksutyypille annetaan väärä toistuvuus, esim. avainjäsenmaksu vain kerran vuodessa tai kuukausittain toistuva jäsenmaksu | ||
+ | '''Järjestelmä ei estä tekemästä virheellisiä merkintöjä, joten tässä pitää olla tarkkana!''' | ||
[[Tiedosto:Lataamo ohje 1.png]] | [[Tiedosto:Lataamo ohje 1.png]] | ||
+ | |||
+ | |||
+ | == Tavanomaisia tai vähemmän tavanomaisia toimenpiteitä == | ||
+ | |||
+ | === Uusien jäsenten hyväksyntä === | ||
+ | 1. Jäsenhakemuksia on saapunut hyväksyttäväksi, siirrytään valitsemaan kaikki hyväksyttävät jäsenet listalta jäsenhakemukset-hallinnasta (tässä kohdin voi olla hyvä katsoa, että jokaisella on oikean näköinen email) | ||
+ | |||
+ | 2. Valitaan uusi jäsentyyppi (valitaan vain pelkkä jäsen) pudotusvalikosta | ||
+ | |||
+ | 3. Hyväksytään valinta napilla, jäsen päätyy nyt prosessiin, jossa hänelle lähetetään maksutiedot hänen ilmoittamaansa email-osoitteeseen | ||
+ | |||
+ | === Jäsen haluaa erota yhdistyksestä === | ||
+ | |||
+ | Kannan tietomalli on rakennettu ''cascade delete''-tyyliin, joten suurimman osan tapahtumista tulisi toimeia siten, että jäsenen poistaminen poistaa myös häneen liittyvät tietueet muista malleista. | ||
+ | |||
+ | === Jäsen on hakenut vapautusta jäsenmaksusta === | ||
+ | |||
+ | Jos vapautus hyväksytään, voidaan tilanne ratkaista esimerkisi merkitsemällä vuotta koskeva credit-tapahtuma nollaksi ja merkitä kommentti jäsenen tietoihin asiasta. | ||
+ | |||
+ | === Avainjäsen hakee muutosta avainmaksuunsa === | ||
+ | |||
+ | Kaksi tapaa: 1) vaihdetaan voimassaolevan toistuvan tapahtuman maksumäärä uuteen '''TAI''' 2) päätetään vanhan toistuvan maksun toistuminen johonkin ajankohtaan ja lisätään uusi uudella määrällä (tämä on hyvä tapa varsinkin, jos maksua halutaan muuttaa alkaen jostain tietystä päivämäräästä). Toistuvan tapahtuman muutos ei vaikuta niihin vanhoihin tapahtumiin, jotka on muutosta aiemmin luotu vanhan toistuvan tapahtuman pohjalta. Toistuva tapahtuma on luonteeltaan malli, joka vain tuottaa uusia tapahtumaolioita ilman yhteyttä tähän toistuvan tapahtuman "isäntäprosessiin". | ||
+ | |||
+ | === Avainjäsen hukannut avaimensa === | ||
+ | |||
+ | Kadonneelle avaimelle on oma tapahtumatäginsä. Uusi tapahtuma on tehtävissä manuaalisesti tapahtumien hallinnan kautta. Jokainen tapahtumatägi vastaa numeroa, joka kulkee myös maksutapahtuman viitenumeron mukana, joten hukkuneen avaimen maksukin on omalla viitenumerollaan. |
Nykyinen versio 28. maaliskuuta 2022 kello 12.48
Päävalikko
ACCESS
- Poletin tyypit
- Poletti tarkoittaa tässä lähtökohtaisesti (mutta ei välttämättä) jotain avainta
- Voidaan käyttää myös tarvittessa muihin sellaisiin jäsenelle myönnettäviin oikeuksia ilmaiseviin tietueisiin, jotka vaativat seurantaa
- Pääsyoikeuden tyypit
- Tärkein pääsyoikeuden tyyppi on avainjäsenelle myönnettävä oikeus oven avaamiseen
- Muut oikedet voivat olla esim. koneiden ja laitteiden käyttöoikeuksia
- Pääsyoikeudet
- Pääsyoikeus = jäsen + hänelle myönnetty pääsyoikeuden tyyppi
- Tunnisteet
- Tunniste = jäsen + myönnetty poletti + poletin yksilöivä tieto
- Esimerkiksi avainjäsen, hänelle myönnetty avain ja avaimen yksilöivä id
- Tämä on tärkeä varsinkin avainjäsenten avainten hallinnalle: tämä listaus sisältää kaikki avaimet, joita on koskaan myönnetty
- Kun avainta ei enää käytetä, sille asetetaan ruksi kohtaan revoked - jos avain on sähköinen, se ei enää ole sen jälkeen voimassa
- Fyysinen avain joudutaan pyytämään kuitenkin takaisin
- Ulkopuoliselle annetut poletit
- Esim. huollolle tai siivoukselle annettu avain menee tänne - polettiin ei liity tällöin jäsentietoa
AUTENTIKAATIOTUNNISTE
- Tokens
CREDITOR
- Tapahtuman tägit
- Tapahtumien tyyppien hallinta: avainmaksu, jäsenmaksu jne.
- Tapahtumat
- Lista kaikista taphtumista, joita on joko saapnut (debit) tai joita odotetaan saavamme (credit)
- Päivämäärä on hetki siitä, kun tieto on rekisteriöity kantaan
- Toistuvat tapahtumat
KIRJAUTUMINEN JA OIKEUDET Tämä on järjestelmän (jäsenrekisteri) käyttäjien hallinnan hoitamiseen - se ei ehkä näy jokaiselle rekisterin käyttäjällekään oikeuksista riippuen
JÄSENET
- Jäsenhakemuksen tägit
- Jäsenhakemukset
- Jäsentyypit
- jäsen voi kuulua useisiin jäsentyyppeihin kerrallaan, jokaisen tulee olla tyyppiä jäsen
- Muistiinpanot
- vain välttämättömiin kommentteihin jäsentietojen hoitamisessa
SIVUSTOT
- Sivustot
EXTRA
- Transaction detail view
Tapahtuma, toistuva tapahtuma ja saldo
Termit debit ja credit eivät esiinny Lataamossa suoraan näillä nimillä, tämä on kirjanpidollisesta käytännöstä tulevaa termistöä.
Tapahtumalla tarkoitetaan maksutapahtumaa, joka voi olla joko:
- sisääntuleva plusmerkkinen (jäsen maksaa jotain) DEBIT
- odotettavissa oleva tulo miinusmerkkinen (odotetaan saavamme jäseneltä jokin maksusuoritteen) CREDIT
Etumerkki määrää täysin, kummasta on kyse.
Toistuva tapahtuma on jäsenkohtainen ajastettava uusia tapahtumia luova käsky, joka aktivoituu sille asetetun toistuvuusvälin mukaan. Tapahtumia voi myös tehdä itse manuaalisesti tarvittaessa, mutta pääosin lähes kaikki tapahtumat luodaan toistuvien tapahtumien kautta. Toistuvalla tapahtumalla on aikaväli, joka määrää, onko toistuvuus voimassa. Toistuvat tapahtumat ovat käytännössä aina miinusmerkkisiä, plusmerkkinen on varmastikin virhekirjaus.
Toistuva tapahtuman muokkaus ei vaikuta aiempien tuotettujen tapahtumien historiaan. Muutos maksun määrään vaikuttaa vain siitä hetkestä alkaen, kun muutos on tehty. Yleensä on fiksumpaa toimia siten, että maksun määrän muokkaamisen sijaan, lopetetaan vanha toistuva tapahtuma voimassaoloajalla ja tehdään uusi toistuva tapahtuma uudella aloitushetkellä. Tämä pitää historian ymmärrettävämpänä.
Tapahtumiin toisinaan tarvitaan muokkauksia erilaisten poikkeustilanteiden selvittelemiseksi. Tässä tulee pyrkiä noudataamaan seuraavia periaatteita, mikäli mahdollista
- rekisteri kuvaa varsinkin sisääntulevien (+ debit) maksujen osalta vain sellaista tilaa, jossa rahaa on oikeasti liikkunut jäseneltä meidän tilille
- vältetään tietueiden poistoa, ellei kyse ole virheen vuoksi syntyneestä tilanteesta
- tietyissä korjaustilanteissa voi olla paras ratkaisu esimerkiksi merkitä tapahtuma nollaksi euroksi, esim. jos credit on joskus ollut olemassa, mutta sille ei odoteta enää vastaavaa debittiä, koska jäsen vapautetaan maksusta jonkin perusteen vuoksi
- ihannetilanteessa jokaista sisääntulevaa (+ debit) maksua kohden on sitä vastaava odotettu maksusuorite (- credit) samalla viitteellä - jos plusmerkkisiä on jäsenellä enemmän kuin oletetaan, niin virhe on todennäköisesti meidän puolella, tai sitten jäsen maksaa tietämättään liikaa - miinusmerkkisiä sen sijaan on usein enemmän kuin debittejä, koska tieto tapahtumista siirtyy viiveellä uusia tiedostolatauksia odotellessa
- rekisteristä ilmenee luotettavasti ja totuudemukaisesti jäsenmaksuliikenne sellaisena, kuin se näkyy myös tiliotteella, eikä sinne kuulu tämän ulkopuolisia tapahtumia
- korjaussummat ym. ovat vältettävä ratkaisumalli, niitä ei oikeastaan saisi käyttää koskaan - jos debittejä ei oleteta saatavan, mieluummin nollataan niitä koskevat creditit
- korjataan tapahtuman aikaansaanut toistuva tapahtuma, mikäli muutos toistuu tästä eteenpäin - jos muutos koskee vain mennyttä aikaa, eikä tulevia uusia tilanteita, niin toistuvan tapahtuman muokkausta ei tehdä
- joihinkin määrittelmättömiin erikoistilanteisiin saattaa olla tarpeen käyttää nollamääräistä toistuvaa tapahtumaa, tätä voi harkita joihinkin tilanteisiin
Saldo on jäsenen debit- ja credit-tapahtumien etumerkit huomioiva summa. Tämä luku kuvaa sitä, onko jäsenen saatavien ja saapuneiden maksujen balanssi negatiivinen, positiviinen tai usein myös nolla. Nollatulos on tavoiteltavin tilanne, se kertoo, että jäsnen maksutiedot vastaavat saapuneiden ja odotettujen maksujen osalta samaa euromäärää. Tyypillisesti luku on usein negatiivinen sen vuoksi, että toteutuneiden debit-maksutapahtumien lataaminen pankista kestää aikaa, ja tällä välin on ehtinyt ajastua uusi kierros toistuvia credit-tapahtumia.
Saldo on määritelty jäsenmallissa seuraavasti (huom. kuten näkyy, se ei huomioi viitenumeroiden vastaavuutta debitin ja creditin välillä, vaan tekee suoraviivaisen yhteenlaskun kaikista tapahtumista)
@property def credit(self): ret = self.creditor_transactions.all().aggregate(models.Sum('amount'))['amount__sum'] if ret == None: return Decimal(0.0) return ret
Laskut ja muistutukset
Järjestelmässä ei ole erillistä laskutuksen tietomallia ja sen vuoksi ei myöskään laskuihin liittyvää kuvailutietoa tai laskuhistoriaa. Tästä johtuen Lataamon lähettämissä emaileissa ns. "laskut" ovat käytännössä saldoilmoituksia, eivät laskuja, ja siksi niissä ei ole järjellistä eräpäivätietoa. Saldomuistutuksissa "eräpäivän" kohdalla käytetään credit-tapahtuman luontihetkeä, joka on usein jo ehtinyt olla menneisyydessä ennen kuin viestit päätyvät jäsenelle. Tämä on tiedostettu ongelma ja vaatisi kehittämistä.
Aliohjelma velkoja sisältää automaattisen maksumuistutusohjelma, joka käy läpi saldoja ja lähettää muistutuksia puuttuvista suoritteista jäsenelle merkittyyn emailiin. 2022 alkaen puuttuvien maksujen tiedoista koostetaan yksi email, joka sisältää listan puuttuvista maksuista. Tähän käytetään saldomäärää ja maksujen viitevastaavuuden päättelyä, mikä ei ehkä mene aina oikein, jos maksutiedoissa on paljon epäselvyyksiä.
Kts. lisää projektista: project/velkoja/nordeachecker.py/NordeaOverdueInvoicesHandler list_overdue() jne. https://github.com/HelsinkiHacklab/asylum/blob/hhl_changes/project/velkoja/nordeachecker.py
Viitenumerot
Viitenumeroiden generoitumisesta jotain jne...
Jäsenen muokkaus
Jäsentyyppejä voi olla voimassa useita samanaikaisesti. Käytössä on pääasiassa vain tyypit jäsen ja avainjäsen. Tällä hetkellä järjestelmä ei edellytä tai pakota näitä tietoja oikein, vaan henkilöllä voi olla avainjäsenmaksu, vaikka ei olisi merkitty avainjäseneksi jäsentyypissä. Määräämällä jäsenelle jäsentyypin tai tyypit, on helpompaa selata ja löytää listaukset tietyistä jäsentyypeistä.
Kommentit jäsenen tiedoissa on pyrittävä pitämään mahdollisimman minimaalisina ja vain jäsenyyden hoitamiseen liittyviin asioihin, jotka auttavat tulkitsemaan muita jäsentietojen kirjauksia. Esimerkiksi sovitut poikkeukset maksujen osalta tai vaihtoehtoiset yhteystiedot.
Jäsenem muokkauksen kautta on mahdollista editoida poletteja ym. tietoja, mutta ne ovat löydettävissä myös omilta sivuiltaan pitkänä listauksena kaikilta jäseniltä yhteensä.
Maksut
Jäsenen maksutietojen lukuohje:
- nimiö-tiedon voi ohittaa, toistuvalla tapahtumalla ei käytännössä voii olla yksilöivää nimeä
- järjestelmä huolehtii viitenumeroista itse, ne luodaan vasta varsinaisen tapahtuman luomisen hetkellä
- sarake määrä on lähes ilman poikkeusta aina negatiivinen (credit)
- virhetilanne voi syntyä myös siitä, että maksutyypille annetaan väärä toistuvuus, esim. avainjäsenmaksu vain kerran vuodessa tai kuukausittain toistuva jäsenmaksu
Järjestelmä ei estä tekemästä virheellisiä merkintöjä, joten tässä pitää olla tarkkana!
Tavanomaisia tai vähemmän tavanomaisia toimenpiteitä
Uusien jäsenten hyväksyntä
1. Jäsenhakemuksia on saapunut hyväksyttäväksi, siirrytään valitsemaan kaikki hyväksyttävät jäsenet listalta jäsenhakemukset-hallinnasta (tässä kohdin voi olla hyvä katsoa, että jokaisella on oikean näköinen email)
2. Valitaan uusi jäsentyyppi (valitaan vain pelkkä jäsen) pudotusvalikosta
3. Hyväksytään valinta napilla, jäsen päätyy nyt prosessiin, jossa hänelle lähetetään maksutiedot hänen ilmoittamaansa email-osoitteeseen
Jäsen haluaa erota yhdistyksestä
Kannan tietomalli on rakennettu cascade delete-tyyliin, joten suurimman osan tapahtumista tulisi toimeia siten, että jäsenen poistaminen poistaa myös häneen liittyvät tietueet muista malleista.
Jäsen on hakenut vapautusta jäsenmaksusta
Jos vapautus hyväksytään, voidaan tilanne ratkaista esimerkisi merkitsemällä vuotta koskeva credit-tapahtuma nollaksi ja merkitä kommentti jäsenen tietoihin asiasta.
Avainjäsen hakee muutosta avainmaksuunsa
Kaksi tapaa: 1) vaihdetaan voimassaolevan toistuvan tapahtuman maksumäärä uuteen TAI 2) päätetään vanhan toistuvan maksun toistuminen johonkin ajankohtaan ja lisätään uusi uudella määrällä (tämä on hyvä tapa varsinkin, jos maksua halutaan muuttaa alkaen jostain tietystä päivämäräästä). Toistuvan tapahtuman muutos ei vaikuta niihin vanhoihin tapahtumiin, jotka on muutosta aiemmin luotu vanhan toistuvan tapahtuman pohjalta. Toistuva tapahtuma on luonteeltaan malli, joka vain tuottaa uusia tapahtumaolioita ilman yhteyttä tähän toistuvan tapahtuman "isäntäprosessiin".
Avainjäsen hukannut avaimensa
Kadonneelle avaimelle on oma tapahtumatäginsä. Uusi tapahtuma on tehtävissä manuaalisesti tapahtumien hallinnan kautta. Jokainen tapahtumatägi vastaa numeroa, joka kulkee myös maksutapahtuman viitenumeron mukana, joten hukkuneen avaimen maksukin on omalla viitenumerollaan.