Ero sivun ”Lataamon ohjeet” versioiden välillä
Rivi 64: | Rivi 64: | ||
* 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ä 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 | * 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) | + | * jokaista sisääntulevaa (+ debit) maksua kohden on sitä vastaava odotettu maksusuorite (- credit) - 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ä tiedostolatauksissa |
* 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 |
Versio 28. maaliskuuta 2022 kello 09.00
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
- jokaista sisääntulevaa (+ debit) maksua kohden on sitä vastaava odotettu maksusuorite (- credit) - 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ä tiedostolatauksissa
- 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ä
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: