Billig::Settlement

Støtte for kasseoppgjør ble kodet inn i Billig til UKA-07, da de under UKA-05 måtte skrive alle disse for hånd, da eksportene fra Billettservice var udugelige(tm). Dette tok unødvendig mye tid og krefter fra både billettgjengen og øko.

Denne noden er ment for å forklare litt om hvordan oppgjørene henger sammen, og forhåpentligvis øke bussfaktoren på denne delen av Billig litt :-)

MERK: Denne teksten er litt forut for sin tid. Det meste stemmer, men noen av databaseendringer vi har sett vi trenger fra UKA-09 er ikke i produksjon enda. Men de kommer Real Soon Now(tm).

Databasen

Lagringen av kasseoppgjør gjøre etter skjemaet som finnes i sql/settlement.sql i kode-treet.

Et kasseoppgjør har et starttidspunkt og et slutttidspunkt som viser når kasseoppgjøret ble åpnet og eventuelt lukket. Kasseoppgjøret har en eier som er brukeren som åpnet kassen. Tidligere hadde billig et konsept om hvilken kasse og bankterminal ble benyttet, men dette ble fjernet da dette er overflødig da kassekontoret (under UKA i alle fall) har denne informasjonen. Denne informasjonen knyttes opp via feltet cash_king_id. Dette er et løpetall fra kassekontoret sin side for hver transaksjon de har i cash_king. (I vårt tilfelle er det kasse ut med veksel).

Et kasseoppgjør får for hver billett som blir berørt av selgeren så lenge kasseoppgjøret er åpent, en ny transaksjon tilknyttet seg. Dvs om selgeren selger et syv billetter til en kunde registreres dette som syv salgstransaksjoner. Dette er for å gjøre rapporteringlogikken mindre kompleks da det samme kjøpet kan bli berørt av andre kasseoppgjør innenfor den samme perioden. En transaksjon kan oppre i to typer, salg og refundering. Dvs om noen gjør om en billett fra medlem til ikke-medlem (f.eks) blir det registrert som en refundering og ett salg. En transaksjon har også et konsept om betalingsmiddel, vi støtter i dag to stykk, kontanter og kreditt (bankterminal).

Databasen har også to hjelpe-views. settlement_report og settlement_tickets.

settlement_report returnerer feltene i settlement-tabellen (starttid osv) samt en summering av hvor mye pengestrømmen var (i følge det som ble rapportert inn om kasseoppgjøret er avsluttet, og hvor mye billig mener det skulle ha vært.

settlement_tickets gir en liste over billetter som i følge kasseoppgjøret er gyldige, altså billetter som ble solgt og ikke refundert innenfor det samme kasseoppgjøret. Merk at billettene kan ha blitt refundert i et annet kasseoppgjør. Dette viewet hjelper oss å lage økonomiske rapporter for hvert kasseoppgjør.

Bruk - fra en selgers synspunkt

Når en vanlig bruker prøver å selge billetter og ikke har et aktivt kasseoppgjør blir han spurt om han vil åpne et nytt kasseoppgjør. Om han har et tidligere kasseoppgjør som ikke er avsluttet vil han også få valget om å fortsette på det eksisterende kasseoppgjøret. Her må han samtidig taste inn hvor han selger fra og hvilken billettprinter han evt bruker.

Selgeren selger så billetter som vanlig.

Når selgeren er ferdig for dagen, går han inn på kasseoppgjøret sitt (link finnes i hovedmenyen). Her blir han spurt om å taste inn hvor mye penger han har i kassen og hvor mye han har fått inn på bankterminalen sin. Hadde han veksel med seg ut, må dette trekkes fra summen før han taster den inn. Om kasseoppgjøret stemmer overrens med det billig mener han burde ha fått inn, avsluttes oppgjøret og brukeren sendes til startsiden. Om det er en differanse på over en gitt grense ($settlement_diff_limit i config.pm) får han opp en advarsel om at det er for stor differanse for å avslutte kasseoppgjøret direkte. Meningen er da at selgeren skal telle over kassen sin på nytt. Om det fortsatt er for stor differanse kan selgeren krysse av for å avslutte kasseoppgjøret med differanse og har da også en mulighet for å legge ved et notis om hvorfor han har differanse. Når dette kasseoppgjøret avsluttes sendes det en mail til en gitt adresse med beskjed om at det er levert inn et kasseoppgjør med høy differanse.

Selgeren er nå ferdig for dagen.

Bruk - fra en administrators synspunkt

Administratorer har tilgang til å se alle detaljer om et kasseoppgjør via rapport-siden. Her kan han også søke opp gamle kasseoppgjør på selger og/eller dato. Inne på detaljersiden kan han se alle detaljer billig har om kasseoppgjøret. I fremtiden er det meningen at han skal kunne legge inn justeringstransaksjoner, og evt endre på detaljene på kasseoppgjøret (men ikke endre på noen av transaksjonene).

Disse rapportene har et printstyle som gjør de egnet for å printe ut og levere til økonomi som skal ha papirutgaver av alle rapportene.

Automatiske rapporter

Under UKA-09 ble det skrevet et script for å gi CSV-rapporter pr oppgjør som var egnet for import til visma. Dette skriptet finnes i bin/report.pl på cirkus i /var/www/samfundet.no/billig. Dette scriptet lager en csv-fil pr oppgjør med en linje for hvert UKE-prosjektnummer (knyttet mot arrangementer) eksl. billettavgift, og en linje for hvert prosjekt med kun billettavgiften (da de skal inn på forskjellige kontoer).

Disse rapportene ble dog aldri eksportert automatisk under UKA da det ofte måtte gjøres korreksjoner av ITK på oppgjørene, og dette er litt problematisk å rette på i Visma om rapporten allerede er lagt inn.

Scriptet ble kjørt som brukeren billig-web, da billig-web hadde skrivetilgang på et fellesområde som økonomi hadde for rapporter av denne typen.

Formatet på denne eksporten er som føler:

Oppgjørsdato;Bilagsart;Tekst;Debet;Debet A.K;Kredit;Kredit A.K;Beløp;Oppgjørsid;Gjeng;Prosjekt;Motref;Ekstratekst

Merk at vi bruker semicolon som seperator, da excel takler dette sømløst, og gjør ting litt lettere for de som bruker eksporten.

Feltene i CSV-eksporten

Feltnavn	Beskrivelse
Oppgjørsdato	Datoen oppgjøret ble startet
Bilagsart	Regnskapsteknisk kode, 70 under UKA-09
Tekst	Beskrivende tittel for hva man rapporterer for. (Billetter, Billettavgift..)
Debet	Regnskapsteknisk konto - avhenger av prosjekt id
Debet A.K.	Regnskapsteknisk konto - avhenger av prosjekt id
Kredit	Regnskapsteknisk konto - avhenger av prosjekt id
Kredit A.K.	Regnskapsteknisk konto - avhenger av prosjekt id
Beløp	Summen pengeflyten
Oppgjørsid	Unik ID i regnskapets system. Under UKA er dette cash_king_id fra databasen
Gjeng	Gjengnummeret i databasen, under UKA-09 var Billett gjeng nummer 72
Prosjekt	Regnskapsprosjektet linjen omhandler. Hentes fra uka_project under UKA
Motref	Regnskapsteknisk felt vi lar stå tomt
Ekstratekst	Tomt felt for Visakompatibilitet.

Håndtering av moms i rapporten

Under UKA-09 hadde vi to arrangementer med moms, Supperevy og Romantisk Aften. Det eneste som skiller disse arrangmentene (eller deres tilknyttede prosjekt ider), er at de fikk en annen Kredit- og Kredit A.K.-konto.

Kravspec

Et kasseoppgjør skal være knyttet mot en ansvarlig selger.
Et kasseoppgjør skal inneholde alle økonomiske transaksjoner som er blitt gjor av selgeren innenfor kasseoppgjøret.
Kasseoppgjør er obligatorisk for vanlige selgere, med unntak for Samfundets (org.nr 1)
Et kasseoppgjør skal kunne regne ut kassedifferanse og lagre dette for fremtidig bruk ved avslutting av et kasseoppgjør.
Et kasseoppgjør skal kunne knyttes opp mot en fysisk kasse (skaffes fra CashKing).
En transaksjon skal ha informasjon om retning på pengene, tidspunkt, brukeren som gjennomførte transaksjonen og transaksjonssummen.
Det skal kunne genereres automatiske rapporter fra kasseoppgjørene i CSV-format.

Lenker: Start, billig