Lataamon ohjeet

Helsinki Hacklabin wikistä
Siirry navigaatioon Siirry hakuun

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

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

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

Muokkaa jäsen

Jäsenen maksutietojen lukuohje:


Lataamo ohje 1.png