Omnibus i WooCommerce: førpris og laveste pris siste 30 dager

Siden 1. oktober 2023 må en norsk nettbutikk som markedsfører en vare med nedsatt pris, også oppgi varens førpris: den laveste prisen butikken har brukt i minst 30 dager før markedsføringen startet. Kravet står i § 9a i prisopplysningsforskriften og gjennomfører artikkel 6a i direktiv 98/6/EF slik Omnibus-direktivet endret den. WooCommerce lagrer ingen prishistorikk, så tallet må beregnes av en utvidelse eller egen kode. Her går vi gjennom hva forskriften sier, hvordan prishistorikken i WooCommerce bør fungere, hvilke feller en vanlig løsning går i, og hvordan du på en time sjekker at butikken din viser riktig tall.

Artikkelen beskriver regelverket og programvaren slik de er på publiseringsdagen. Den er ikke individuell juridisk rådgivning for din nettbutikk.

#Hva krever Omnibus-direktivet ved prisnedsettelser

Direktiv (EU) 2019/2161, kjent som Omnibus-direktivet (EUR-Lex), føyde en ny artikkel 6a til direktiv 98/6/EF om prisopplysning (EUR-Lex, konsolidert tekst). Artikkelen har fem ledd:

1. Enhver kunngjøring av en prisnedsettelse skal oppgi den tidligere prisen den næringsdrivende brukte i en bestemt periode før nedsettelsen.
2. Den tidligere prisen er den laveste prisen den næringsdrivende har brukt i en periode på minst 30 dager før nedsettelsen.
3. Statene kan ha egne regler for varer som raskt forringes eller går ut på dato.
4. For produkter som har vært på markedet i under 30 dager, kan statene fastsette en kortere periode.
5. Statene kan bestemme at førprisen ved en gradvis økende nedsettelse er prisen uten nedsettelse før første gang den ble brukt.

Norge er bundet gjennom EØS-avtalen. Innledningen til prisopplysningsforskriften viser til EØS-avtalen vedlegg XIX nr. 1a, direktiv 98/6/EF endret ved direktiv (EU) 2019/2161, og forskriften er gitt med hjemmel i markedsføringsloven § 10. Regelen om førpris kom inn som ny § 9a ved forskrift 20. juni 2023 nr. 979, i kraft 1. oktober 2023, og paragrafen ble senere endret ved forskrift 16. oktober 2024 nr. 2491, i kraft 1. januar 2025. Slik lyder den i dag:

Der prisen på varer markedsføres som nedsatt, skal den næringsdrivende gi informasjon om varens førpris. Førprisen er den laveste prisen som den næringsdrivende har anvendt i minimum 30 dager før markedsføringen startet. Med laveste pris menes prisen som har blitt anvendt for varen overfor allmennheten, eller andre større grupper av forbrukere som tilhører ulike lojalitetsprogrammer eller kundeklubber. Der prisnedsettelsen øker gradvis, er førprisen den laveste prisen før første prisnedsettelse. For varer som kan forringes eller foreldes raskt er førprisen den laveste prisen som den næringsdrivende har anvendt umiddelbart før markedsføringen startet.

Kilde: forskrift 14. november 2012 nr. 1066 om prisopplysninger mv. for varer og tjenester (prisopplysningsforskriften) § 9a (Lovdata).

Fra denne teksten kommer fem tekniske krav til nettbutikken.

Overalt der nedsettelsen markedsføres. Plikten utløses når prisen «markedsføres som nedsatt». Det dekker produktsiden, produktlister, bannere på forsiden og nyhetsbrev med kampanjepris. Der kunden ser en overstrøket pris eller et prosentavslag, skal førprisen også stå.

Vinduet regnes bakover fra markedsføringsstart. Forskriften bruker «før markedsføringen startet». I de fleste butikker er det samme dag som salget starter i WooCommerce. Annonserer du et salg i et nyhetsbrev før det trer i kraft, er det markedsføringen som starter først, og vinduet slutter da allerede den dagen.

Prisen som er anvendt. Det teller bare priser kunden faktisk kunne kjøpe for. En salgspris du har lagt inn i panelet for neste måned, er ennå ikke anvendt.

Kundeklubbpriser teller. Laveste pris omfatter også priser brukt overfor større grupper av forbrukere i lojalitetsprogrammer eller kundeklubber. Dette har konsekvenser for nettbutikker med medlemspriser, og vi kommer tilbake til det nedenfor.

Varer, ikke tjenester. § 9a står i kapittel 2, som gjelder prisopplysning for varer. Tjenester har egne regler i kapittel 3. Forskriften gjelder etter § 1 for næringsdrivende som er etablert i Norge og selger varer og tjenester til forbruker.

To andre bestemmelser i samme forskrift påvirker implementeringen. § 3 sier at «alle priser det opplyses om skal inkludere merverdiavgift og offentlige avgifter», så førprisen må vises med mva. akkurat som salgsprisen. § 5 krever at salgspris og enhetspris oppgis like tydelig på eller i umiddelbar nærhet av varen, så for varer som skal ha enhetspris, viser en produktside med kampanjepris i praksis tre tall: salgsprisen, enhetsprisen og førprisen.

Forbrukertilsynet fører tilsyn med markedsføringen overfor forbrukere i Norge, også med prisopplysninger.

#Når regnes 30 dager annerledes

Hovedregelen i § 9a dekker det vanlige tilfellet. Tre situasjoner endrer hvordan førprisen beregnes, eller krever at butikken tar et valg.

#Varen har vært til salgs i under 30 dager

Direktivet lar statene fastsette en kortere periode for produkter som har vært på markedet i under 30 dager (artikkel 6a nr. 4). Den norske § 9a har ingen slik regel. Teksten sier «minimum 30 dager» og nevner ikke nye varer. Hvordan en vare med kortere salgshistorikk skal behandles, sier forskriften altså ikke noe om, og det spørsmålet bør du avklare før du setter ned prisen på en nyhet.

Samme felle rammer butikker som akkurat har installert en utvidelse for prishistorikk. En vare som har vært solgt i to år, har i den nye utvidelsen en historikk som starter i dag. Utvidelsen vet ikke at varen er gammel og har ingen rad fra før installasjonen. En fornuftig utvidelse har derfor en egen innstilling for varer uten historikk, og du må bevisst bestemme hva butikken viser de første 30 dagene. Tryggest er å vente med nye prisnedsettelser til historikken dekker hele vinduet, eller å importere historikken fra den forrige utvidelsen hvis det fantes en.

#Varer som raskt forringes

For varer som kan forringes eller foreldes raskt, er førprisen den laveste prisen butikken har brukt umiddelbart før markedsføringen startet. Her er det ikke noe 30-dagersvindu, bare prisen rett før kampanjen. Direktivet lar statene velge sine egne regler for slike varer, så det er den norske ordlyden som gjelder for en butikk etablert i Norge.

En butikk som selger mat, blomster eller varer med kort holdbarhet, trenger derfor to beregningsmåter: det vanlige 30-dagersvinduet og «laveste pris umiddelbart før markedsføringen». Utvidelsen bør la deg merke slike varer, for eksempel med en kategori eller et felt på produktet.

#Rabatten økes trinnvis

Her har Norge valgt å bruke direktivets artikkel 6a nr. 5. § 9a sier: «Der prisnedsettelsen øker gradvis, er førprisen den laveste prisen før første prisnedsettelse.»

Et tenkt eksempel: en vare koster 100, på mandag går den ned til 90, og en uke senere til 80. Ved det andre trinnet er førprisen fortsatt 100, fordi det er den laveste prisen før første nedsettelse. Uten denne regelen ville 90 blitt førprisen ved trinn to, og kampanjen ville sett mindre ut enn den er.

For prishistorikken betyr det at utvidelsen må vite at trinn to hører til samme nedsettelse som trinn én. Det kan den ikke lese ut av prisene alene. En gradvis kampanje må enten merkes som én kampanje, eller så må butikken låse førprisen fra første trinn. Ordlyden sier «øker gradvis», så etter vår lesning passer et opphold der varen går tilbake til full pris mellom trinnene, dårlig inn under regelen.

#Kundeklubbpriser og medlemspriser

Denne presiseringen står i § 9a, ikke i direktivteksten, og den har direkte følger for WooCommerce. Laveste pris er prisen som er brukt overfor allmennheten, eller overfor andre større grupper av forbrukere i lojalitetsprogrammer eller kundeklubber.

I WooCommerce lages slike priser ofte med en utvidelse for rollebaserte priser, en medlemsplugin eller egne regler for innloggede kunder. Hvis prishistorikken bare lagrer den offentlige prisen, får du feil førpris. Et tenkt eksempel: varen koster 100 for alle og 85 for klubbmedlemmer. Nå markedsfører du 80 for alle. Etter ordlyden er førprisen 85, ikke 100, fordi klubbprisen er brukt overfor en større gruppe forbrukere i perioden.

En individuell rabattkode til én kunde faller etter vår lesning av ordlyden utenfor, fordi forskriften snakker om større grupper. Hvor grensen går mellom en liten og en stor gruppe, sier teksten ikke.

#Har WooCommerce innebygd laveste pris siste 30 dager

Nei. Vi sjekket koden i hovedgrenen av WooCommerce-repositoriet på GitHub 27. oktober 2026: søk etter «omnibus» og «lowest price» gir ingen treff, og kjernen har verken tabell eller felt for prishistorikk.

Et produkt i WooCommerce lagrer bare nåtilstanden:

Når du endrer prisen, forsvinner den gamle verdien. Et planlagt salg slås på av en bakgrunnsjobb (woocommerce_scheduled_sales) som bytter aktiv pris når salget starter. Når salget er over, går prisen tilbake til ordinærpris, og butikken lagrer ingenting om at salget har funnet sted.

Konsekvensen er enkel: førprisen kan verken beregnes fra WooCommerce-data eller gjenskapes i ettertid. Du trenger en egen historikk som føres fra installasjonsdagen, enten med en utvidelse eller med egen kode. Bestiller du dette fra en utvikler, må spesifikasjonen beskrive både hvordan historikken lagres og hvordan minimum beregnes. Selve etiketten tar en halvtime å legge til, mens en korrekt historikk er en egen modul med tester. Trenger du en slik modul eller en gjennomgang av den du har, beskriver vi det på siden WooCommerce-utvikler.

#Hvordan fungerer en riktig prishistorikk

Prishistorikken er en tabell med rader: produkt (eller variant), pris, valuta, kundegruppe og tidspunktet prisen gjelder fra. Fra den beregnes minimum i vinduet. Det høres enkelt ut, men hver regel under kommer fra en feil noen allerede har gjort.

#Raden lagres når prisen trer i kraft

Du legger til en rad når den aktive prisen endres, altså prisen kunden kan kjøpe for. Å lagre produktet i panelet er ikke nok som utløser, fordi du i samme lagring kan sette opp et salg som starter neste måned. Lagrer utvidelsen salgsprisen da, havner den i historikken før noen kunne kjøpe for den, og når salget starter, blir den «laveste pris siste 30 dager». Ved et planlagt salg skal raden lages i det øyeblikket WooCommerce starter salget.

Den andre regelen gjelder endringer i løpet av én dag. Setter du ned prisen om morgenen og tilbake om ettermiddagen, kunne kundene kjøpe billigere i noen timer. En historikk som bare lagrer én pris per døgn, mister den endringen, selv om prisen ble anvendt.

#Vinduet regnes fra start av nedsettelsen

30-dagersvinduet slutter når nedsettelsen markedsføres første gang, og det flytter seg ikke med dagens dato. Et tenkt eksempel: kampanjen startet 1. november og varer i tre uker. Den 15. november er førprisen fortsatt minimum fra perioden 2. til 31. oktober. Regner utvidelsen «siste 30 dager fra i dag», kommer kampanjeprisen selv inn i vinduet etter noen dager, og butikken viser «laveste pris siste 30 dager: 80» ved siden av prisen 80. Det sier kunden ingenting og er i strid med forskriften.

#Prisen som gjaldt da vinduet åpnet

Her snubler de fleste enkle løsninger. Rader lages bare når prisen endres. Et tenkt eksempel: varen har kostet 100 i 40 dager, og i dag settes den ned til 80. Den siste raden med 100 er 40 dager gammel, så det finnes ingen rad i 30-dagersvinduet. En spørring på «minimum av radene fra de siste 30 dagene» gir tomt resultat eller bare 80.

Riktig logikk tar minimum fra to kilder: radene inne i vinduet og den siste raden før vinduet åpnet, fordi den prisen fortsatt gjaldt da vinduet startet. I eksempelet blir svaret 100. Det samme gjelder opprydding: en jobb som sletter rader eldre enn 30 dager, må aldri slette den siste raden før vinduet, for den er det eneste beviset på prisen 100.

#Valuta på hver rad

En butikk som har byttet hovedvaluta, eller som bruker en flervalutautvidelse, har priser i ulike valutaer i historikken. Hver rad må ha valuta, og spørringen må filtrere på valutaen kunden ser produktet i. Ellers står en laveste pris i euro ved siden av en salgspris i kroner, eller minimum beregnes av tall som ikke kan sammenlignes.

#Mva. på samme måte som prisen ved siden av

§ 3 krever at alle priser inkluderer merverdiavgift. WooCommerce lar deg legge inn priser med eller uten mva. og velge separat hvordan de vises i butikken og i handlekurven. Førprisen må gå gjennom de samme visningsinnstillingene som prisen ved siden av, for eksempel via wc_get_price_to_display(). Legger butikken inn priser eks. mva. og viser dem inkl. mva., vil et rått tall fra historikken mangle mva. og villede kunden.

#Variable produkter per variant

Et variabelt produkt i WooCommerce har ingen egen pris. Variantene har priser, og produktsiden viser et intervall. Historikken må føres for hver variant, og førprisen bør vises når kunden velger varianten, sammen med prisen for den. I produktlister der intervallet vises, trenger butikken en gjennomtenkt regel, for eksempel å vise førprisen for varianten som setter den nedre grensen.

#Oppryddingen beholder raden før vinduet

Historikken vokser med hver prisendring, så utvidelsen rydder. Oppryddingsjobben sletter gamle rader, men beholder den siste raden før vinduet for hvert produkt. Jobben må også fortsette å kjøre etter en oppdatering av utvidelsen, uten ny aktivering.

#Hvordan beregne førprisen for et planlagt salg

Planlagte salg er den vanligste kilden til feil tall, fordi salgsprisen finnes i WooCommerce-panelet før den gjelder. Et tenkt eksempel steg for steg:

1. Varen har kostet 100 lenge. Historikken har én rad: 100, fra 60 dager siden.
2. 20. oktober legger du inn salgspris 80 med startdato 1. november og lagrer produktet.
3. Fram til 31. oktober betaler kunden 100. Historikken skal ikke ha en rad med 80, for den prisen er ikke anvendt.
4. 1. november starter WooCommerce salget. Først nå får historikken raden 80.
5. Vinduet er 2. til 31. oktober. Det finnes ingen rader inne i vinduet, så raden fra før vinduet teller: 100.
6. Butikken viser 80, overstrøket 100 og «førpris (laveste pris siste 30 dager): 100».
7. Den 15. november er resultatet det samme, fordi vinduet er festet til 1. november.

Lagrer utvidelsen 80 i historikken allerede i steg 2, viser den 80 som førpris i steg 6. Ignorerer den raden før vinduet i steg 5, viser den ingenting eller 80. Regner den vinduet fra dagens dato i steg 7, viser den 80. Det er tre ulike feil som ser helt like ut i butikken.

Sender du et nyhetsbrev om kampanjen 25. oktober, starter markedsføringen den dagen. Prisen har vært 100 hele tiden, så resultatet blir det samme i dette eksempelet, men vinduet er formelt 25. september til 24. oktober.

#Hva går galt i praksis med førprisen

Alle løsninger for prishistorikk, ferdige utvidelser og skreddersydd kode, kan gå i de samme fellene. Under beskriver vi hver av dem: hvor feilen kommer fra, hvordan du finner den i egen butikk, og hva en riktig løsning gjør.

#Planlagt salg lagret før start

Årsak. Løsningen lagrer historikk når produktet lagres i panelet. Setter du opp et salg for neste uke i samme lagring, havner salgsprisen i historikken før den gjelder og kan bli laveste pris siste 30 dager.

Slik finner du den. Sett opp et salg som starter i morgen, og se på produktsiden etter start. Er førprisen lik salgsprisen, ble salget lagret for tidlig.

Riktig løsning. Lagrer bare et salg som pågår, i det øyeblikket WooCommerce starter det.

#Salgsprisen vist som laveste pris

Årsak. 30-dagersvinduet regnes fra dagens dato. Etter noen dager med salg kommer salgsprisen inn i vinduet og blir minimum. En historikk som lagrer én pris per døgn og mister endringer i løpet av dagen, gir samme effekt.

Slik finner du den. Sammenlign salgsprisen med førprisen på en vare på salg. Er de like, og varen kostet mer før salget, er beregningen feil.

Riktig løsning. Avslutter vinduet ved start av nedsettelsen og lagrer hver endring av aktiv pris, også flere endringer samme dag.

#Ingen rad i vinduet for en vare med fast pris

Årsak. Rader lages bare ved prisendring, så en vare med uendret pris i over 30 dager har ingen rad i vinduet. En spørring som bare ser på rader inne i vinduet, finner ingenting. En opprydding som sletter alt eldre enn 30 dager, fjerner det eneste beviset på prisen før nedsettelsen.

Slik finner du den. Ta en vare som har hatt samme pris i over en måned, og sett ned prisen. Førprisen må vise den gamle prisen.

Riktig løsning. Beregner minimum fra radene i vinduet pluss den siste raden før vinduet, og oppryddingen beholder alltid den raden.

#Førpris i feil valuta

Årsak. Historikken lagrer beløp uten valuta, eller den lagrer valuta, men spørringen bruker den ikke. En butikk som har byttet hovedvaluta, eller som har en flervalutautvidelse som bytter valuta per forespørsel, viser da førprisen i én valuta ved siden av salgsprisen i en annen.

Slik finner du den. Bytt valuta i butikken og se på en vare på salg. Førprisen skal stå i samme valuta som salgsprisen.

Riktig løsning. Lagrer valuta på hver rad og filtrerer minimum på valutaen i den aktuelle forespørselen.

#Kundeklubbprisen mangler i historikken

Årsak. Medlemspriser og rollebaserte priser settes ofte av en annen utvidelse enn den som fører prishistorikk. Historikken ser bare den offentlige prisen.

Slik finner du den. Logg inn som klubbmedlem, noter prisen, og sett deretter ned prisen for alle. Ligger klubbprisen under den offentlige prisen, skal førprisen ikke være høyere enn klubbprisen.

Riktig løsning. Lagrer prisen per kundegruppe som er en større gruppe forbrukere, og tar dem med i minimum.

#Innstillinger som gir et resultat i strid med regelen

Årsak. Utvidelser har gjerne innstillinger for vinduets lengde og oppførsel i grensetilfeller. Noen av dem gir et resultat i strid med regelverket: et vindu kortere enn 30 dager, valget «i dag» som kilde for laveste pris, eller å vise gjeldende pris som laveste pris.

Slik finner du den. Gå gjennom innstillingene i Omnibus-utvidelsen i butikken din: vinduets lengde og hva som skjer uten historikk.

Riktig løsning. Har standardinnstillinger i tråd med regelen og advarer når noen endrer dem til noe som ikke er det.

#Ingen førpris i produktrutenett i blokktema

Årsak. I blokktemaer bygges produktlister av blokken Product Collection. WooCommerce kjører de klassiske løkke-hookene bare i butikkrutenettet, så en løsning basert på disse hookene viser ikke førprisen på forsiden, i relaterte produkter eller i mersalg i handlekurven. Med to visningskilder kan samme informasjon også dukke opp to ganger.

Slik finner du den. Legg en Product Collection-blokk med en vare på salg inn på forsiden, og sjekk at førprisen står ved den overstrøkne prisen, og bare én gang.

Riktig løsning. Legger til førprisen i hvert rutenett som viser en overstrøket pris, uavhengig av blokk eller mal.

#Ingen førpris på produktside fra Elementor Pro

Årsak. En produktsidemal i Elementor Pro erstatter hooken woocommerce_single_product_summary. En løsning som bare henger førprisen på denne hooken, viser ingenting på en slik side.

Slik finner du den. Åpne en vare på salg på en produktside bygget i Elementor, og sjekk at førprisen står ved prisen.

Riktig løsning. Støtter sidebyggerens maler eller legger til informasjonen der selve prisen vises.

#Import som teller et salg som bare var planlagt

Årsak. Importen fra den gamle utvidelsen leser det rå salgsprisfeltet. Det feltet inneholder også salg som bare var planlagt, så en pris ingen har kjøpt for, havner i historikken som anvendt pris.

Slik finner du den. Etter importen sammenligner du førprisen for en vare som hadde et planlagt, men aldri startet salg, med prisen den faktisk ble solgt for.

Riktig løsning. Flytter bare priser som er anvendt, med datoer og valuta.

#Strukturerte data overskrevet med tallet fra historikken

Årsak. Løsningen setter førprisen inn i produktets JSON-LD i stedet for salgsprisen eller listeprisen fra WooCommerce. Søkemotoren ser da en annen pris enn den kunden betaler.

Slik finner du den. Åpne kildekoden til en produktside med salg og finn blokken application/ld+json. Feltet price i tilbudet skal være lik prisen kunden betaler.

Riktig løsning. Legger førprisen til ved siden av salgsprisen og listeprisen, som ikke endres.

#Teknisk prefiks i handlekurven

Årsak. WooCommerce viser data for linjer i handlekurven som «etikett: verdi». Sendes førprisen dit med en teknisk nøkkel, ser kunden for eksempel prefikset «Omnibus:».

Slik finner du den. Legg en vare på salg i handlekurven og les det som står under varenavnet.

Riktig løsning. Viser en setning kunden forstår uten å kjenne utvidelsen.

#Opprydding som slutter å kjøre etter en oppdatering

Årsak. Den daglige jobben som rydder i historikken, planlegges bare når utvidelsen aktiveres. En oppdatering uten ny aktivering lar den bli liggende uplanlagt.

Slik finner du den. Gå til WooCommerce > Status > Planlagte handlinger (eller listen over WP-Cron-jobber) og sjekk at jobben til Omnibus-utvidelsen er planlagt.

Riktig løsning. Sjekker tidsplanen etter hver oppdatering og planlegger jobben på nytt hvis den mangler.

#Oversikt

#Slik gjør våre utvidelser det

Vi utvikler to WooCommerce-utvidelser med støtte for Omnibus: Shoplex, som er laget for etterlevelse av EU-regler i nettbutikker, og Polski for WooCommerce, som er laget for polske butikker. Begge lagrer et planlagt salg først når WooCommerce starter det, og begge advarer hvis du setter vinduet til under 30 dager. Valgene «i dag» og «vis gjeldende pris som laveste pris» er merket som ikke i samsvar med artikkel 6a nr. 2 i direktiv 98/6/EF.

Produktside i en testbutikk med Shoplex (grensesnitt på engelsk). Laveste pris siste 30 dager (16,00 EUR) står under salgsprisen, i samme valuta og sammen med enhetsprisen. Eksempelet viser også en regel fra denne artikkelen: laveste pris i vinduet trenger ikke være lik den overstrøkne prisen.

Polski for WooCommerce lagrer i tillegg valuta på hver rad i historikken og beregner minimum i valutaen kunden ser produktet i. Den tar med prisen som gjaldt da vinduet åpnet, og prisendringer i løpet av én dag. Den viser førprisen etter mva.-innstillingene i WooCommerce, ved varianter av variable produkter, i Product Collection-rutenett i blokktemaer og på produktsider fra Elementor Pro-maler. I strukturerte data legges laveste pris til ved siden av salgsprisen og listeprisen. Utvidelsen har en egen innstilling for varer uten historikk og kan importere prishistorikken som Omnibus-utvidelsen fra iworks har lagret.

#Hvor ellers viser nettbutikken en nedsatt pris

§ 9a gjelder der prisen markedsføres som nedsatt, uansett hvor. I WooCommerce dukker den overstrøkne prisen opp mange steder, og hvert sted rendres av ulik kode.

Blokktemaer. Butikkarkivet, forsiden, relaterte produkter og mersalg i handlekurven er separate blokker i et blokktema. En utvidelse skrevet for klassiske hooks dekker arkivet, mens de andre rutenettene står uten førpris. Flytter du butikken til et blokktema, må du sjekke hvert av dem. Forskjellene mellom klassiske temaer og blokktemaer går vi gjennom i artikkelen om klassiske temaer og blokktemaer.

Sidebyggere. Elementor Pro og andre sidebyggere med egne produktsidemaler erstatter standardhookene i WooCommerce. Førprisen må kobles til stedet sidebyggeren bruker, eller til selve prisen.

Handlekurv og ordreoppsummering. Viser handlekurven en overstrøket pris, markedsfører den en nedsettelse. Teksten skal være lesbar for kunden, uten tekniske navn.

Strukturerte data. Produktdata i JSON-LD leses av søkemotorer, og de brukes i søkeresultater med pris. Feltet price i tilbudet skal fortsatt være salgsprisen kunden betaler. Førprisen erstatter verken salgsprisen eller listeprisen.

Trappepriser, kundeklubber og B2B-priser. En butikk med priser som avhenger av antall eller kunderolle, har flere priser samtidig for samme vare. Siden § 9a eksplisitt tar med priser i lojalitetsprogrammer og kundeklubber, må du før du velger Omnibus-utvidelse sjekke hvilken pris den regner som aktiv, og om en pris for en kundegruppe havner i historikken. Rene B2B-priser til bedriftskunder er ikke forbrukerpriser, men de ligger ofte i samme tabell og må skilles ut. Arkitekturen bak slike priser beskriver vi i artikkelen om trappepriser og enhetspriser i WooCommerce B2B.

Markedsføring med pris. Bannere og nyhetsbrev som viser en nedsatt pris, er markedsføring av nedsettelsen. Dette innholdet lager du utenfor produktsiden, så tallet fra historikken må flyttes dit manuelt eller via en integrasjon. Husk også at et nyhetsbrev som annonserer kampanjen før den starter, flytter starten på markedsføringen fram.

#Hvordan bytte Omnibus-utvidelse uten å miste prishistorikken

Prishistorikken er det eneste beviset på hvilken pris som gjaldt før nedsettelsen. Bytter du utvidelse uten import, nullstilles den, og butikken er tilbake i situasjonen «ingen historikk» i 30 dager.

Før byttet sjekker du tre ting:

1. Kan den nye utvidelsen importere historikken fra den gamle? Polski for WooCommerce importerer historikken fra Omnibus-utvidelsen fra iworks. For andre kombinasjoner må du sjekke dokumentasjonen eller be en utvikler om et migreringsskript.
2. Hva importeres egentlig? Importen skal flytte priser som er anvendt, med datoer og valuta. Det rå salgsprisfeltet er ikke nok, fordi det også inneholder salg som bare var planlagt.
3. Hva gjør den nye utvidelsen uten historikk? For varer importen ikke dekker, bruker utvidelsen innstillingen for manglende historikk. Sjekk hva den viser før du starter nye nedsettelser.

Tryggest rekkefølge: sikkerhetskopi av databasen, installer den nye utvidelsen ved siden av den gamle, importer, sammenlign førprisen på noen varer i begge utvidelsene, og slå av den gamle først etterpå. Gir de to historikkene ulike tall for samme vare, finner du årsaken før den gamle slås av, for etterpå har du ingenting å sammenligne med.

#Hvordan sjekke at nettbutikken viser riktig førpris

Testen under tar omtrent en time på en kopi av butikken (staging). Tallene er tenkte eksempler, og hvert steg sier hva som er riktig resultat.

1. Planlagt salg. Velg en vare som koster 100 og ikke har endret pris på over 30 dager. Sett opp et salg til 80 som starter i morgen. I dag skal produktsiden verken vise 80 eller noen førpris. I morgen, etter at salget har startet, skal førprisen vise 100.
2. Vare med fast pris. Vil du ikke vente til i morgen, tar du en annen vare med fast pris i 40 dager og setter ned prisen med en gang. Førprisen er den gamle prisen. Salgsprisen eller ingen førpris på dette stedet er feil.
3. Vinduet er festet til start. Etter noen dager med salg går du tilbake til varen fra steg 1. Førprisen skal fortsatt være 100.
4. Endring i løpet av dagen. Sett ned prisen på en testvare i en time, og sett den tilbake. Start deretter en ny nedsettelse. Førprisen skal ta med den timelange nedsettelsen.
5. Variabelt produkt. Sett opp salg på én variant av et variabelt produkt. Når den varianten velges, skal førprisen vises sammen med variantens pris. Når en variant uten salg velges, skal den forsvinne.
6. Valuta. Bruker butikken en flervalutautvidelse, bytter du valuta på en vare på salg. Førprisen skal stå i samme valuta som salgsprisen.
7. Mva. Sammenlign førprisen med salgsprisen i et oppsett der butikken legger inn priser eks. mva. og viser dem inkl. mva. Begge tallene skal inkludere mva. på samme måte.
8. Forsiden og andre rutenett. Legg en vare på salg i en Product Collection-blokk på forsiden, og sjekk deretter relaterte produkter og mersalg i handlekurven. Ved hver overstrøkne pris skal det stå en førpris, og bare én.
9. Sidebyggermal. Kommer produktsiden fra Elementor Pro eller en annen sidebygger, sjekker du en vare på salg på den siden.
10. Handlekurv. Legg en vare på salg i handlekurven. Førprisen skal være en setning for kunden, uten tekniske prefikser.
11. Strukturerte data. Åpne kildekoden til en produktside med salg, eller Googles test for utvidede resultater. Prisen i tilbudet skal være lik salgsprisen.
12. Oppryddingsjobben. Gå til WooCommerce > Status > Planlagte handlinger og sjekk at jobben til Omnibus-utvidelsen er planlagt. Når den har kjørt, gjentar du steg 2: raden fra før vinduet skal fortsatt finnes.
13. Innstillinger. Sjekk at vinduet er 30 dager, og at ingen innstilling viser gjeldende pris som laveste pris.

Har butikken kundeklubb eller medlemspriser, tar du med ett steg til: logg inn som medlem, noter klubbprisen, sett ned prisen for alle, og sjekk at førprisen ikke er høyere enn klubbprisen.

Lagre resultatet med dato og skjermbilder. Bytter butikken tema, sidebygger eller prisutvidelse, gjentar du testen, fordi hver av disse endringene kan flytte prisen til et sted utvidelsen ikke dekker.

#Hva gjør du når testen viser en feil

Ligger feilen i innstillingene (vindu under 30 dager, valg som viser gjeldende pris), retter du den selv i panelet til utvidelsen. Gjelder den visningen (ingen førpris i et blokkrutenett, i en sidebyggermal eller i handlekurven), holder det som regel med en oppdatering av utvidelsen eller en liten endring i temaet. Gjelder den selve historikken (salg lagret før start, manglende pris fra før vinduet, valuta eller kundeklubbpriser som ikke er med), krever rettingen endringer i logikken som lagrer historikk, og ofte også opprydding i historikk som er samlet inn feil.

En feil historikk retter seg ikke selv etter en oppdatering av utvidelsen. Rader fra salg som ble lagret før start, blir liggende i databasen og trekker minimum ned til noen sletter dem eller de faller ut av vinduet. Etter hver retting av logikken bør du gå gjennom historikken for varer som har hatt planlagte salg de siste 30 dagene.

Vi bruker samme tilnærming til andre forbrukerkrav i nettbutikken, for eksempel angreknappen: regelverket beskriver resultatet, og butikken må bygge det av data WooCommerce ikke samler inn selv. En oversikt over andre utvidelser for nettbutikken finner du i gjennomgangen av WooCommerce-utvidelser.

Vil du at vi skal sjekke prishistorikken i din butikk, flytte den fra en annen utvidelse eller bygge Omnibus-støtte for et blokktema, en sidebygger eller kundeklubbpriser, kan du ta kontakt via siden WooCommerce-utvikler. Vi starter med testen fra denne artikkelen på en kopi av butikken din, og avtaler omfanget av arbeidet etter resultatet.

Sist oppdatert: 27. oktober 2026