Pakkesys

Pakkesys' formål

Pakkesys har som formål å hente inn bestillinger på selskap og revy under UKEhelgene. Systemet skal ikke være et fullstendig verktøy for planlegging, men en frontend for standardiserte bestillinger. Det betyr at kundens møte med pakketilbud er via Pakkesys, men at håndtering av spesialtilfeller skjer via epost og i Selskaps regneark.

Hva som skal gjøres av Pakkesys

Hente inn informasjon fra brukere:

Kontaktinformasjon
Antall personer
Ønsket dato
Spesielle arrangementsbehov (fritekst)
Menyvalg
Allergier

Gi informasjon til brukere:

Webskjema for forespørsel om dato
Epost med godkjent tidspunkt og dato
Epost med lenke til skjema for mat-/revybestilling
Webskjema for mat-/revybestilling

Hva som ikke skal gjøres av Pakkesys, men manuelt av Selskap

Pakkesys skal hente inn bestillinger, men skal ikke være et verktøy for å behandle bestillinger i etterkant. Etter at matbestillinger er mottatt er fortsatt Pakkesys kilden til sannhet over informasjonen systemet allerede lagrer, og ordreendringer må legges inn i Pakkesys av administrator, men Pakkesys behandler ikke denne dataen på noe vis. Årsaken til dette er at behandling av forespørslene fort kan bli komplekst, og det er viktigere at Pakkesys gjør noe enn å forsøke å gjøre alt og deretter feile. Kanskje man senere kan automatisere deler av prosessen, men det gjør vi ikke i første omgang.

Spesielt skal Pakkesys ikke:

Håndtere spesielle forespørsler
Fordele personer på de ulike revysittegruppene
Sende ut billetter

Hvordan Pakkesys fungerer

Faser

Pakkesys har et konsept om flere faser gjennom året. UKA er ikke nødvendigvis klar til å hente inn all informasjonen om en pakkebestilling samtidig som gamle mennesker ønsker å gi beskjed om at de skal på festival. Pakkesys har i nåværende versjon et konsept om 4.5 faser.

Fase 0.0: Pakkesys er stengt.

Fase 1.0: Pakkesys tar imot bestillinger som fordeles etter poengsum/jubileum.

Fase 1.5: Pakkesys stenger midlertidig for at UKA skal kunne behandle forespørslene som har kommet.

Fase 2.0: Pakkesys tar imot bestillinger som fordeles etter første-mann-til-mølla.

Fase 3.0: Pakkesys tar ikke imot bestillinger, men UKA er tilgjengelige på epost.

Tekstinnhold

For å unngå at Selskap må sende epost til ITK de vil endre tekstinnhold et sted i Pakkesys, kan de selv endre dette under Tekstinnhold på admin-siden. I utgangspunktet tolkes tekstinnhold som markdown, men et flagg kan sette tekstinnholdet som plaintext. Dette gjør man f.eks. i eposter.

Menyer

Modellering av matbestilling til selskap ganske vanskelig, og vi har endt opp med en modell som tilfredsstiller behovene til UKA-19. Det er sterkt anbefalt å holde seg til denne modellen.

Avhengig av datoen man har valgt for sitt selskap vil man ha en eller flere ulike matretter man kan velge mellom. Til hver av disse matrettene kan man bestille ulike drikkepakker. Det er viktig at man bestiller akkurat like mange drikkepakker tilhørende en matrett som antall man bestiller av den matretten. Det betyr at dersom 10 personer skal ha Meny 1 og 5 skal ha Vegetarmeny, må man bestille 10 drikkepakker under Meny 1 og 5 drikkepakker under Vegetarmeny. Hvis noen ikke ønsker drikke setter man dem på Ingen drikkepakke slik at regnskapet går opp.

Videre er vi interessert i hvilke allergier selskapene har. For lettere å kunne tilrettelegge for allergenfri mat ønsker vi å vite hvilke allergier vi skal ta hensyn til per matrett. Det betyr at hvis to personer i selskapet er allergiske mot gluten, men den ene skal ha Meny 1 og den andre skal ha Vegetarmeny, skriver man "En glutenallergiker" under allergifeltet for Meny 1 og "En glutenallergiker" under allergifeltet for Vegetarmeny.

Dette modelleres i databasen ved at flere MenuCombinationOrder opprettes tilknyttet en Order. Dette representerer en bestilling av count stk av en MenuCombination, som er en kombinasjon av en matrett og en drikkepakke. Det går ikke an å bestille en matrett eller drikkepakke separat fra hverandre.

Revyer og eksport for Regnskap

Før UKA-21 ble det lagt inn støtte for revyer og revybilletter i pakkesys. Dette ble gjort slik at Regnskap kan eksportere alle dataene som trengs for å opprette fakturaer direkte fra pakkesys. På grunn av eksporten til Regnskap er det ekstra viktig at prisene er korrekte. Moms-satsene er satt som environment variabler i base.py og ITK og Regnskap må sjekke at disse stemmer før man starter eksporteringen.

Det er ingen integrasjon mot billig og det er derfor viktig å dobbeltsjekke at dataene i pakkesys stemmer overens med dataene som finnes i billig. Her er det lett å gjøre feil, og det har skjedd tidligere. Det kan for eksempel føre til at man selger flere billetter gjennom pakkesys enn det man har kapasitet til i billig. Dersom det gjøres feil her blir de fort vanskelige å løse og fører ofte til misfornøyde kunder.

Revyer og revybilletter må opprettes av itk og de kan låses på samme måte som menyene.

Persondata tilknyttet pakketilbud eksisterer både i Pakkesys og i Selskaps regneark. Pakketilbudsansvarlig er ansvarlig for at alle data slettes etter at UKA er over, og noterer dette i fremdriftsplanen sin. Tømming av Pakkesys gjøres av ITK, mens tømming av regneark gjøres av Selskap. Merk at ITK kan bruke verktøyet python manage.py pakkesys_export for å eksportere en anonymisert versjon av databasen. Deretter kan hele databasen tømmes.

Databasen kan tømmes med verktøyet python manage.py delete_pakkesys_data. Dette verktøyet vil slette all informasjon i pakkesys-databasen med unntak av tekstinnhold (Merk: meny_pdf-er blir ikke lastet opp i databasen og vil fortsatt eksistere i uploads-mappen). NB! Tenk deg om to ganger før du sletter all dataen i databasen.

Hvem som har tilgang til Pakkesys administreres av ITK. Regnearkene adgangsbegrenses ved at man må inviteres for å få både lese- og skrivetilgang. I alle disse arkene skrives det tydelig at man må innom pakketilbudsansvarlig for å få tilgang, og hun gir det bare hvis det sammenfaller med det brukerne har samtykket til i bestillingsskjema, nemlig å være nødvendig for å arrangere pakketilbud. Hvem som har tilgang til regnearkene kan administratorer over regnearket se. Ingen regneark med persondata skal være lesbare for noen som ikke eksplisitt har blitt invitert til å få tilgang.

Brukerhistorier

Bruker

Byggkullet fra 1957 vil på selskap og revy. Kim Larsen får i oppdrag å bestille revy. Han besøker uka.no og trykker seg inn på "Pakketilbud". Der spesifiserer han at de er 26 personer som ønsker både middag og revy lørdag under H-helg. Han kommenterer at en av dem bruker rullestol. Videre har de totalt 108 UKEpoeng, så han skriver inn dette sammen med en forklaring.

Når bestillingen er sendt inn får han en forespørselsbekreftelse. Han forstår at han ikke har fått godkjent forespørselen, men at dette kommer senere. Han kan gå inn på en lenke for å se ordredetaljene.

En måned senere mottar han en epost om at de ikke hadde nok UKEpoeng, så de får ikke datoen de ønsker seg. De kan derimot få fredagen samme helg. Han svarer at dette er greit.

En uke senere mottar han en epost med informasjon om at de nå har booket fredagen under H-helg. Han går på linken som fulgte med og sjekker at ordren er som den skal. Videre besøker han skjemaet for matbestilling som også er lenket til. Etter å ha snakket med resten av kullet sitt skriver han inn at de skal ha 19 supermenyer og 7 vegetarianermenyer. I tillegg er 5 av dem allergiske mot egg. De skal ha 26 vinpakker. Han sender inn skjemaet og får en bekreftelse på at bestillingen er mottatt.

I etterkant finner han ut at 3 av personene ikke kan komme likevel, og det noe er visst allergiske mot fisk. Han sender epost til pakketilbud@uka.no, og de svarer at det ordner seg.

Selskap

I midten av mars åpner fase 1, og Selskap ser på at bestillingene renner inn. Det kommer forespørsler fra alle retninger til pakketilbud@uka.no, og Selskap besvarer disse.

Etter to uker går man over i fase 1.5, og det kommer ikke nye ordre. Selskap eksporterer dataen til et regneark og bruker regnearket til å finne ut hvilke ordre som har prioritet basert på UKEpoeng. Deretter fordeler de datoer, og de setter tidspunkt og sted. Enkelte bestillinger får ikke datoen de ønsker seg, så da kontakter Selskap dem via epost og finner en annen dato. De endrer deretter datoen som er satt i Pakkesys. Etter hvert som bestillingene behandles oppdateres de i Pakkesys. De godkjennes, og administrator velger "Send epost". Da sendes det ut bekreftelser på dato, tid og sted, samt mat-/revybestillingsskjema. Etter hvert begynner matbestillingene å gjennomføres, noe som vises i ordreoversikten.

Når eksisterende ordre er behandlet går man over i fase 2. Da åpnes det for bestillinger igjen, men denne gangen fordeles de etter første-mann-til-mølla. Ellers er prosessen som beskrevet i avsnittet over.

Etter hvert som ordrene blir bekreftet av kundene fordeler Selskap revybilletter i billig og pakkesys. Det er ingen integrasjon mellom disse systemene, så Selskap må føre inn dette i begge systemene. Når revybillettene er fordelt kan Selskap markere alle ordrene som er klare for å eksporteres til Regnskap. Når dette er gjort må ikke ordren endres noe mer ettersom faktura kan allerede ha blitt sendt ut. Dersom man oppdager at det er feil i en ordre som er markert klar for eksport må Selskap og Regnskap kommunisere om hvordan man skal fikse dette.

Når Regnskap har sendt ut faktura og den er blitt betalt sender Selskap ut revybillettene. Dette gjøres manuelt gjennom billig og epost.

I slutten av sommerferien er kapasiteten til Selskap full, og man går over i fase 3. Da kommer det ikke flere forespørsler via Pakkesys, men eksisterende ordre behandles videre. Det viser seg plutselig at statsministeren gjerne vil komme. Da oppretter adminsitrator en ordre for henne via admin-grensesnittet, og prosessen går som vanlig.

Regnskap

Regnskap har et eget admingrensesnitt der med en knapp som eksporterer dataene de trenger til et regneark i Google sheets. Hit eksporteres kun ordre som Selskap har markert klar for eksport. Når det er på tide å sende ut fakturaer logger Regnskap seg inn i pakkesys, eksporterer dataene og overfører disse manuelt til Visma for å sende ut fakturaer.

Pakkesys, HOWTO

Det er en del som må skje på bestemte tidspunkter for å at pakkesys skal gå glatt. Her er et forslag basert på hva som skjedde i UKA-19. Tidspunktene er omtrentelige, men rekkefølgen er viktig.

Fase	Når	Hva	Hvem	Kommentar
0.0	Januar	Definere datoer for faser	Selskap, ITK
0.0	Januar	Definere tidsfrister for eventuell utvikling	Selskap, ITK
0.0	Sen februar	Gå gjennom alle tekstinnholdsobjekter	Selskap, ITK
0.0	Sen februar	Opprette regneark og koble det til pakkesys	Selskap, ITK	Se GDPR og Google sheets-eksport
0.0	Tidlig mars	Bytte til fase 1.0	ITK	`get_current_festival().phase`
1.0	Sen mars	Bytte til fase 1.5	ITK
1.5	Sen mars	Behandle forespørsler	Selskap	Importer ordre til gdocs med Google-synkronisering, behandle dem der og oppdater dem i pakkesys via Datofordeling og kommentarer.
1.5	Sen mars	Lage invitasjons-PDF	Selskap, Grafikken	Sendes til ITK
1.5	Sen mars	Definere meny	Selskap, KSG	Må finne ut av navn/pris/allergener for både matretter og drikkepakker. Liste sendes til ITK
1.5	Tidlig april	Lage meny-PDFer	Selskap, Grafikken	Lastes opp under Menyer, én PDF per helgedag
1.5	Tidlig april	Legge invitasjons-PDF på rett sted	ITK	Skal ligge i `uno/uploads/Invitasjon_pakketilbud.pdf`. Den legges ved hver epost, så sørg for at den er liten! Gjør f.eks. en `gs -sDEVICE=pdfwrite -dNOPAUSE -dBATCH -dPDFSETTINGS=/ebook -sOutputFile=small.pdf "Invitasjon_pakketilbud.pdf"`
1.5	Tidlig april	Opprette menyer	ITK	Opprett først WeekDays, deretter Foods og så MenuCombinations
1.5	Tidlig april	Låse menyer	ITK	Fordi man ikke kan endre pris etter at noen har kjøpt noe. `get_current_festival().menus_locked`
1.5	Tidlig april	Legge inn revyer og revybilletter	ITK	Opprett først Revue, så RevueTicketGroup
1.5	Tidlig april	Låse revyer	ITK	Fordi man ikke kan endre pris etter at noen har kjøpt noe.
1.5	Medio april	Sende ut eposter	Selskap	Bruk grensesnittet Epostutsending
1.5	Medio april	Bytte til fase 2.0	ITK
1.5	April-Juni	Fordele revybilletter så fort ordren er akseptert av kunden	Selskap	Gjøres både i billig og pakkesys
2.0	Medio juli	Bytte til fase 3.0	ITK
2.0	Juli-September	Eksportere data og send ut fakturaer	Regnskap	Bruk grensesnittet Google-eksportering
3.0	November	Eksportere anonymisert data og tømme database	ITK	`python manage.py pakkesys_export`
3.0	November	Tømme regneark	Selskap	Se GDPR

Teknisk

Opprette ny festival

Pakkesys er enn django-app som bor i uno_apps. For å opprette en ny festival må man per nå bruke et python-skall og instansiere et nytt Festival-objekt. Merk at det ikke kan eksistere to Festival-objekter samtidig, så du må eventuelt først slette eksisterende festival. NB: Tenk deg om før du gjør dét.

Fra venv-et ditt:

python manage.py shell
from uno.app.pakkesys.models import Festival
f = Festival(year=<ditt_år_i_heltall>)
f.save()

Google Sheets-eksport

Via biblioteket gspread eksporterer pakkesys all data til et Google-regneark. For å sette opp dette må du hente en oauth-json-fil fra Google Developer Console logget inn som eieren av det aktuelle regnearket. Du må også skru på APIet for Drive og Sheets, og oauth-brukeren må få redigeringstilgang til regnearket.

Ønsker for pakkesys

Sammenkoble billig og pakkesys på noe vis slik at man kan fordele revybilletter i pakkesys. Eventuelt knyte sammen billigdatabasen med pakkesysdatabasen for å hente ut infomrasjon om revyer og revybilletter
Bedre filtrering av ordrer. Blant annet ønsker man å kunne filtrere etter helg, samt at datofeltet sorteres etter dato i stedet for ukedag.
Gjøre noe smart med allergier. Selskap trenger en liste med hvor mange og hvilke retter som skal tilpasses en allergi for hver dag.
Gjøre det mulig å opprette menyer, (dager?), drikkepakker, revyer og revybilletter i admingrensesnittet.
Legge til et felt i ordreskjemaet der kundene fyller inn antall medlemmer/ikke-medlemmer. Dette gjelder for både selskapsgjester og revygjester, men skal begrenses til enkelte helger. Se #166641 for mer info

Bugs og feature-requests fra Selskap salgansvarlig i UKA-21

Bugs

Forhåndsvisningen av tekstinnhold som ikke er markdown vises likevel med markdown-formatering.
Hvis kunden ikke legger inn allergier når de bekrefter bestillingen, er det ikke mulig for oss å legge inn allergier på bestillingen i ettertid, f.eks. hvis de melder inn en allergi senere. Dersom de har lagt inn allergier på bare én av menyene (f.eks. Tempora) kan vi ikke legge inn allergier på den andre (Paradoks).

Feature-request

Det er ikke mulig å godkjenne bare f.eks. revy på en ordre som har forespurt både selskap og revy. Så vidt jeg har forstått det er dette sånn det er ment å fungere, men dette er ikke helt optimalt. F.eks. når selskapene er fyllt opp er det ofte revybilletter igjen, og da vil vi gjerne tilby dem bare revybilletter. Slik det er nå må vi da fjerne selskapsforespørselen sånn at vi kan godkjenne bare revy – det hadde vært fint om det var mulig å bekrefte bare én av delene, og gjerne at kunden da fikk en beskjed på ordresiden om at det ikke var mer ledig på det de ikke fikk godkjent.

Hvis vi skal legge inn frister, f.eks. for å bekrefte pakketilbud, er det nå 3-4 ulike tekstinnhold som må oppdateres manuelt. Det hadde vært nice om denne fristen kunne legges inn som et eget tekstinnhold, så vi kan oppdatere bare denne ene.

Enda bedre hadde det vært om det automatisk kom opp på ordresiden at frist for å bekrefte var f.eks. 2 uker (eller at man kan velge antall dager i pakkesys et sted) etter at de hadde fikk mailen med tilbudet. Dette trenger ikke å være en hard frist, men når fristen har gått ut kan teksten endres til en advarsel som “Fristen for å bekrefte tilbudet har gått ut. Vennligst bekreft på linken under snarest!”.

Vet ikke om dette er mulig å endre på, men akkurat nå er tittelen på nettsiden (den som står på fanen i nettleseren liksom) alltid bare “UKA”. Dette blir litt kaotisk når man har mange ordre oppe på en gang i flere faner, så det hadde vært mye bedre om tittelen f.eks. var navnet på bestillingen, ev. ordrenummer.

I fanen “Gjør klar for eksport” er det ingen muligheter for å filtrere. Det hadde vært helt supert å ha de samme filtrene der som i “Datofordeling”.

Filteret på “Helg” i “Datofordeling” tar utgangspunkt i hvilken dag de har forespurt. Jeg skjønner at dette fort kan bli en slags sirkeldefinisjon, siden det er denne fanen man bruker til å fordele datoer, men denne filtreringen er litt upraktisk når man har fordelt datoer, da ikke alle får den datoen de har forespurt. Da ender man opp med at noen bestillinger som har fått plass på H1-1 ligger under filteret på H2, osv. Jeg tror den enkleste løsningen kanskje kan være å legge inn enda et filter, for “tildelt revyforestilling” – da kan man filtrere enten på forespurt dato eller på faktisk tildelt forestilling.

Det hadde vært utrolig praktisk om man kunne importere varekoder på menyer og revyer direkte fra et regneark/csv-fil eller lignende. Det tar lang tid å fylle inn alt manuelt, og det er lett å gjøre feil, så man må bruke en del tid på å dobbeltsjekke alt. (Og vi så jo i høst hva som kan skje hvis varekodene ikke stemmer.)

Vi vil gjerne også ha et (obligatorisk) “antall menyer med allergi”-felt (kun tall) for hver av menyene. Når folk får skrive inn allergiene som (kun) tekst kommer det ikke alltid helt klart frem hvor mange av hver allergi det er, så å ha et sikkert antall hjelper oss veldig. Tror også det kommer til å hjelpe med å gjøre kundene oppmerksomme på at de fyller inn riktig.

Når data eksporteres til Google Sheets er alle feltene i utgangspunktet formatert som tekst. Det hadde vært supert om det gikk an å gjøre disse til tall/datoer automatisk ved eksport, så vi slipper å gjøre dette manuelt hver gang vi eksporterer.

Enkelte av radene i det eksporterte regnearket (typ de med lange kommentarer) blir for lange til å se hele (sheets lar deg ikke scrolle halvveis gjennom cellene). Går det an å innføre en maks-”størrelse/lengde” på radene i eksportarket?

Lenker: Start, gdpr, historie, til nye itkere, uka-no