Ero sivun ”Lataamon ohjeet” versioiden välillä

Helsinki Hacklabin wikistä
Siirry navigaatioon Siirry hakuun
Rivi 49: Rivi 49:
  
 
Tapahtumalla tarkoitetaan maksutapahtumaa, joka voi olla joko:
 
Tapahtumalla tarkoitetaan maksutapahtumaa, joka voi olla joko:
* sisääntuleva plusmerkkinen (jäsen maksaa jotain)
+
* sisääntuleva plusmerkkinen (jäsen maksaa jotain) '''DEBIT'''
* odotettavissa oleva tulo miinusmerkkinen (odotetaan saavamme jäseneltä jokin maksusuoritteen).
+
* odotettavissa oleva tulo miinusmerkkinen (odotetaan saavamme jäseneltä jokin maksusuoritteen) '''CREDIT'''
 
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 tapahtumat ovat käytännössä aina miinusmerkkisiä.
 
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 tapahtumat ovat käytännössä aina miinusmerkkisiä.
  
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, lopetetaa 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ä.
 +
 
 +
Tapahtumiin toisinaan tarvitaan muokkauksia erilaisten poikkeustilanteiden selvittelemiseksi. Tässä tulee '''pyrkiä noudataamaan seuraavia periaatteita''', mikäli mahdollista
 +
* rekisteri kuvaa varsinkin sisääntulevien (plus) 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ä tilanteissa voi olla paras ratkaisu esimerkiksi merkitä tapahtuma nollaksi euroksi, jos odotettu maksu on joskus ollut, mutta ei enää (esim. jäsen vapautetaan maksusta jonkin perusteen vuoksi)
 +
* jokaista sisääntulevaa (+ debit) maksua kohden on sitä vastaava odotettu maksusuorite (- credit)
 +
* 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
  
  

Versio 28. maaliskuuta 2022 kello 08.04

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
  • Tapahtumat
  • 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 ja toistuva tapahtuma

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. Toistuva tapahtumat ovat käytännössä aina miinusmerkkisiä.

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 (plus) 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ä tilanteissa voi olla paras ratkaisu esimerkiksi merkitä tapahtuma nollaksi euroksi, jos odotettu maksu on joskus ollut, mutta ei enää (esim. jäsen vapautetaan maksusta jonkin perusteen vuoksi)
  • jokaista sisääntulevaa (+ debit) maksua kohden on sitä vastaava odotettu maksusuorite (- credit)
  • 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


Muokkaa jäsen

Jäsenen maksutietojen lukuohje:


Lataamo ohje 1.png