God pilot. Flere steg før lansering.

Hovedkonklusjon

Dagens backend er en enkeltbutikkpilot med reell serverkontroll, krypterte betalingsprofiler og låste økonomiske dokumenter. Den nye demoen viser hvordan flere butikker, Studio T-administrasjon og nettbutikktillegg kan fungere. Demoen gjør ikke backend klar for flere butikker, og simulerte tilkoblinger er ikke ekte leverandørintegrasjoner.

Utseendet kan beholdes. Det viktigste arbeidet ligger i datamodell, tilgang, avstemming og drift. Vanlig kundeinnlogging bør være på plass før Brukt’n inviterer ekte kunder.

Ny økonomiversjon

Varig databasejournal for arbeidsområde og fakturabok, manuelle utbetalingsregistreringer med motposter, utskrivbare måneds- og årsoppgjør, og arkiverte rapportversjoner med kilderevisjoner. Journalen lagres atomisk med endringen. Eldre data får startpunkt i journalen ved første endring; tidligere brukerhistorikk kan ikke rekonstrueres.

Vernet gjelder applikasjons- og databaseoperasjoner, ikke en fullmektig databaseadministrator. Sikkerhetskopi, gjenoppretting, oppbevaringssted og full drifts-/tilgangslogging er fortsatt åpne punkter.

Funnet: Butikkpakken kan slås av/på i demo. Leietaker velger egen sending eller butikkpakking. Ordre beholder avtalt ansvar, gebyr og frist. Butikkens plukking, pakking, sporing, henting og gebyrgrunnlag er demonstrert.

Tiltak: Flytt til varige, butikkavgrensede serverdata. Bygg varsling, refusjon og gebyrmotposter, leverandørkoblinger og avtaleflyt. Pris for butikkpakken er ikke fastsatt. Hold separat fra leietakertillegg og pakkegebyr.

Funnet: Refusjon setter varen til returkontroll. Salg og etiketter er sperret til butikkadmin bekrefter kontroll. Ny tilgjengelig vare får ny etikettversjon.

Tiltak: Test fysisk rutine. Tidligere refunderte varer må gjennomgås særskilt; gamle hendelser er ikke omskrevet. Delreturer og nettrefusjoner gjenstår.

Funnet: memberships.user_id er global primærnøkkel. applications.user_id er globalt unik. shop() krever én utviklerbutikk.

Tiltak: Innfør butikker, personer, butikkmedlemskap og leieavtaler som separate tabeller. Samme kunde skal kunne ha hylle i flere butikker. Butikk-ID må valideres på serveren i alle lesinger og endringer.

Funnet: Utviklerrollen er i dag knyttet til én butikk. Den har ikke global oversikt og kan ikke lese private betalingsprofiler.

Tiltak: Egen plattformrolle for studiot med tofaktor, butikkoversikt, funksjonsstyring og begrunnet supporttilgang. Logg alle innsyn og endringer. Selv superadmin må korrigere regnskap med sporbare motposter.

Funnet: Identitet kommer fra Sites-headere. Vanlig passordinnlogging, e-postverifisering, passordreset og MFA er ikke implementert.

Tiltak: Velg produksjonsdrift og en etablert identitetsleverandør. Bruk e-post som verifisert kontakt og eventuelt selvvalgt brukernavn. Ingen delte ansattepassord. Krev MFA for butikkadmin og Studio T. Ikke flytt tilliten til Sites-headere uendret til egen server.

Funnet: Adapteren henter og inspiserer kjøp, men er ikke tilkoblet. Det finnes ingen ferdig OAuth-, produkt-, lager- eller webhook-flyt.

Tiltak: Partnerintegrasjon med godkjenning fra hver butikk. Kartlegg produkt/variant/strekkode, hent salg og returer idempotent, håndter rabatter og delreturer, og kjør avstemming. Varesynk og betalingsdata er ulike flyter.

Funnet: Dagens varemodell har available/sold/return_review/withdrawn. Intern revisjonskontroll stopper ikke et eksternt Zettle-salg.

Tiltak: Atomisk reservasjon med utløp, betalingsbekreftelse fra signert webhook og konfliktkø. Ikke lov at Zettle hindrer en skanning eller et offline-salg. Unike varer må ha en praktisk rutine for reservasjon også i butikken.

Funnet: Nå finnes append-only databasejournal, manuelle utbetalingsposter med bankreferanse og motposter, måneds-/årsrapport og uforanderlige rapportversjoner. Ingen bankkobling eller kontrollert betalingsbatch er implementert.

Tiltak: Samlet reskontro for salg, leie, tillegg, returer, motregning og utbetaling. Utbetalingsbatch trenger stabil ID, godkjenning, bankreferanse og sperre mot dobbeltbetaling. Kontroller oppgjør med regnskapsfører før piloten bruker penger.

Funnet: Full kreditering støttes. Delkreditering, erstatningsfaktura, netto returer, overbetaling og leiedokument når salget dekker leien mangler.

Tiltak: Utvid bilags- og kundejournalen, med uforanderlige originaler. Skill MVA-registrering fra avgiftskategori, avklar bruktvaresalg/formidling og ansvar. Ny versjon beholder betalings-ID ved retry og lagrer fakturahistorikk atomisk med fakturaboken. Full reskontro og avgiftskontroll gjenstår.

Funnet: Ingen varig bildeopplasting eller objektlagring er koblet til; hostingmanifestet har r2:null.

Tiltak: Eier- og butikkavgrenset objektlagring. Valider faktisk filinnhold, størrelse og pikselantall; dekod og fjern metadata som GPS. Lag miniatyrer og sletterutiner. Godkjenn varetekst, bilder og pakkemål før publisering.

Funnet: Ingen Stripe- eller Profrakt-nøkkel, webhook, checkout eller fraktbooking er aktivert. Demoen bruker faste eksempelpriser.

Tiltak: Egen Stripe Connect-konto og Profrakt-avtale per butikk. Skilj varesalg, frakt, betalingsgebyrer, kundens nettbutikktillegg og Studio T-abonnement. Nettbutikktillegg må ha avtale, betalingsperiode, oppsigelse og serverstyrt rettighet.

Funnet: OBA list_printservere viste Pi Skien online 23.10.2026. Modell og driver ble ikke returnert. HylleutleieNO har én global enhetsnøkkel og hardkodet butikktekst.

Tiltak: Bekreft eksakt Brother-modell, rull og dagens OBA-agent med Pål. Opprett eget enhetsregister, kø og tilbakekallbar nøkkel for hver butikk. Kalibrer og skann fysisk. Fraktetiketter kan kreve annet format eller egen skriver.

Funnet: En kansellert jobb kunne avvise en sen kvittering permanent og blokkere alle etterfølgende jobber i Pi-agenten.

Tiltak: Gi et eksplisitt terminalt svar for manuelt avsluttet jobb. Håndter kvitteringsfeil per jobb uten automatisk ny fysisk utskrift. Test strømbrudd, tom rull og manuell lukking.

Funnet: Aktive hyller frigjøres ikke ved utløp. Forlengelse, hyllebytte, flere hyller, restvarer og gjenåpnet søknad mangler.

Tiltak: Egen leieavtale per hylle med start, slutt, prisversjon og avslutning. Frigi først etter varekontroll og sluttoppgjør. Tillat ny søknad/reaktivering med historikk. Prisendring på vare må utløse ny etikettversjon.

Funnet: API og database blokkerer sletting av workspaces/fakturabøker. Historikk og rapportarkiv er append-only. Lokal nettleserdemo kan fortsatt nullstilles.

Tiltak: Etabler dokumentert arkiv- og sletterutine per datakategori. Separat testmiljø må ha styrt levetid. Ikke omgå journalvernet for å nullstille en butikk.

Funnet: Globale pilot/live-flagg og JSON-snapshots på 2,5/3 MB. Økonomijournalen er nå varig, men tar kopi av hele revisjoner og må skaleres om. Backup, restore, nøkkelrotasjon og reell flerbrukertest er ikke gjennomført.

Tiltak: Butikkvise miljøgrenser, normaliserte tabeller, append-only logg, overvåking, ratebegrensning og testet gjenoppretting. Avklar avtalepart, behandlingsansvar, databehandlere, lagringstid og netthandelsvilkår.

Hva vi trenger for virkelige tilkoblinger

• Bekreftet Brother-modell og etikettformat, samt OBA-agentens oppsett fra Pål. OBA MCP viste bare Pi Skien og online-status. Ingen utskrift er sendt.
• Zettle-utviklerapp og butikkens autorisasjon. Flere butikker krever butikkvis OAuth og tokenhåndtering.
• Stripe Connect-oppsett for Studio T-plattformen og tilkoblet konto for pilotbutikken.
• Profrakt sandbox/API-tilgang og butikkens fraktavtale. Ikke bruk OBA-avtalen automatisk for andre butikker.
• Valgt drifts- og innloggingsleverandør, verifisert e-post til Studio T og sikker kontooppretting. Brukernavnet studiot vises bare i innloggingsdemoen. Ingen passord er lagret og ingen ny konto er opprettet.

Kilder og kontrollgrunnlag

Kildekode ved start: 2096aebaf365857663da48d765214a788d50e916. Offisiell dokumentasjon kontrollert 23.10.2026. OBA skriverstatus lest via obaverk9800. Det er ikke gjort endringer hos OBA, Zettle, Stripe eller Profrakt.

• Zettle: integrasjoner og OAuth
• Zettle: API-oversikt
• Stripe Connect: direkte betalinger
• Stripe: betalingsbekreftelse og webhooks
• Profrakt: utviklergrensesnitt og sandbox
• Profrakt: API-dokumentasjon
• Brother: QL-serien
• Skatteetaten: oppbevaring og sikkerhetskopi
• Altinn: faktura og dokumentasjonskrav