Lataamon ohjeet

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.