Hopp til innhold
← Nyttig
3. november 20266 min lesetid
Nyheter

Unngå prisavvik i WooCommerce: Fra produktpris til regnskap

Prisavvik oppstår ofte i møtet mellom produktdata, rabattregler, mva, frakt, betaling og økonomisystem. Slik etablerer dere en kontrollert prisflyt gjennom hele nettbutikken.

Kategori: WooCommerce

En kunde ser én pris på produktsiden, en annen i handlekurven og et tredje beløp på fakturaen. Det trenger ikke være store forskjeller før det skaper problemer. Noen få kroner i avvik kan utløse kundeservice, manuell korrigering, feil i regnskapet og usikkerhet om hvilke tall som faktisk er riktige.

I en profesjonell WooCommerce-butikk er ikke pris bare et felt på produktet. Sluttbeløpet formes av produktvarianter, kundetype, rabattregler, mva, frakt, avrunding, betalingsløsning og integrasjoner. Derfor bør pris behandles som en sammenhengende prosess fra produktkatalog til bokføring og refusjon.

Prisene må stemme fra nettbutikk til regnskap.
Prisene må stemme fra nettbutikk til regnskap.

Start med å definere hvilke systemer som bestemmer

Det første spørsmålet er ikke hvilken pris som skal vises, men hvilket system som har myndighet til å fastsette den. I en enkel butikk kan WooCommerce være hovedkilden for produktpriser. I en mer sammensatt virksomhet kan prisene komme fra et ERP-system, et produktinformasjonssystem eller en kundespesifikk prisliste.

Problemer oppstår når flere systemer får lov til å endre samme verdi. En integrasjon importerer ordinær pris om natten, mens en redaktør legger inn kampanjepris direkte i WooCommerce. Neste synkronisering overskriver kampanjen, eller sender den lokale endringen tilbake til økonomisystemet.

Lag derfor en enkel oversikt over ansvaret:

  • Hvilket system eier ordinær produktpris?
  • Hvor opprettes kampanjepriser og rabatter?
  • Hvilket system bestemmer mva-kode?
  • Hvor vedlikeholdes kundespesifikke priser?
  • Hvem bestemmer fraktpris og eventuelle gebyrer?
  • Hvilke beløp skal overføres til betaling, lager og regnskap?

For hvert felt bør det finnes én tydelig hovedkilde. Andre systemer kan lese og bruke verdien, men bør ikke overskrive den uten en definert regel.

Skill mellom produktpris og beregnet ordrebeløp

Produktprisen er bare utgangspunktet. Ordrebeløpet beregnes ut fra den konkrete handlekurven og kundens situasjon. Det kan blant annet påvirkes av antall, variant, kundekonto, rabattkode, leveringsadresse og valgt fraktmetode.

Tydelige varianter og varenummer reduserer feil i ordrebehandlingen.
Tydelige varianter og varenummer reduserer feil i ordrebehandlingen.

Denne forskjellen er viktig når dere planlegger integrasjoner. Et eksternt system bør ikke uten videre forsøke å gjenskape ordren ved å hente dagens produktpris. Prisen kan ha blitt endret etter at kunden bestilte. Ordren må behandles som et historisk dokument med de prisene, rabattene og avgiftene som faktisk gjaldt ved kjøpet.

Integrasjonen bør derfor overføre ordrelinjenes faktiske beløp, ikke bare produktnummer og antall. Den må også håndtere rabatt, frakt, mva og eventuelle gebyrer på en måte mottakersystemet forstår.

Gjør variantene tydelige før dere lager prisregler

Variable produkter er en vanlig kilde til prisfeil. Størrelse, materiale, pakningsantall eller abonnementstype kan påvirke både pris, vekt, lagerstatus og avgift. Hvis variantene er ufullstendige eller brukes inkonsekvent, blir det vanskelig å kontrollere sluttbeløpet.

Unngå å bruke fritekstfelt eller tilleggsløsninger til egenskaper som egentlig definerer et eget salgbart produkt. Dersom en valgmulighet har egen pris, lagerbeholdning eller varenummer, bør den normalt kunne identifiseres som en tydelig variant eller ordrelinje.

Kontroller spesielt at:

Reelle kjøpssituasjoner bør testes før prisregler settes i drift.
Reelle kjøpssituasjoner bør testes før prisregler settes i drift.
  • hver salgbar variant har korrekt varenummer
  • prisene er satt på riktig nivå
  • standardvalg ikke skjuler dyrere alternativer
  • prisvisningen forklarer om den viser fra-pris eller valgt variant
  • integrasjonen gjenkjenner variantens varenummer

En ryddig produktstruktur gjør både checkout, plukk, kundeservice og rapportering mer pålitelig.

Bestem rekkefølgen for rabatter, mva og frakt

Mange avvik skyldes ikke feil tall, men ulike beregningsregler. To systemer kan bruke samme priser og likevel komme frem til forskjellige totaler dersom de beregner rabatt, mva eller avrunding i ulik rekkefølge.

Avklar blant annet om rabatt skal beregnes før eller etter mva, om frakt skal få rabatt, og hvordan faste rabattbeløp fordeles mellom ordrelinjene. Det samme gjelder mva på frakt og gebyrer. Reglene må passe virksomhetens salg og være konsistente i nettbutikk, betaling og økonomisystem.

Avrunding må også testes. Ett system kan runde hver ordrelinje, mens et annet runder totalsummen. Forskjellen blir særlig synlig ved mange ordrelinjer, lave enhetspriser eller fordeling av en fast rabatt.

Ikke prøv å skjule slike differanser ved å legge inn tilfeldige korrigeringslinjer. Dokumenter heller beregningsmetoden og sørg for at integrasjonen sender tilstrekkelig detaljerte beløp.

La checkout vise hele regnestykket

Checkout skal ikke være stedet der kunden for første gang oppdager mva, frakt eller et gebyr. Prisvisningen gjennom kjøpsreisen bør være konsekvent og forklare hva som inngår.

Test overgangen mellom produktside, handlekurv og checkout. Kunden bør kunne forstå:

  • enhetspris og antall
  • hvilken variant som er valgt
  • hvilken rabatt som er brukt
  • om prisene vises med eller uten mva
  • fraktkostnad og eventuelle vilkår for gratis frakt
  • endelig beløp før bestillingen sendes

For bedriftskunder kan det være behov for å vise priser uten mva, mens privatkunder forventer totalpriser. Hvis butikken betjener begge grupper, må kundetype og visningsregler testes nøye. Det holder ikke at totalsummen til slutt er riktig dersom presentasjonen underveis er misvisende.

Kontroller beløpet mot betalingsløsningen

Når kunden går til betaling, sender WooCommerce et beløp til betalingsløsningen. Etter betalingen mottar butikken en bekreftelse. Disse beløpene må samsvare med ordren.

Endringer som skjer for sent i prosessen kan skape avvik. Det gjelder for eksempel prisregler som aktiveres etter at betalingsøkten er opprettet, eller integrasjoner som endrer ordrelinjer uten å oppdatere betalingen.

Driftsrutinen bør fange opp situasjoner der:

  • ordren er opprettet uten bekreftet betaling
  • betalingen er gjennomført uten korrekt ordrestatus
  • betalt beløp avviker fra ordrebeløpet
  • kunden har forsøkt flere betalinger på samme ordre
  • en endring eller refusjon bare er registrert i ett system

Slike hendelser bør havne i en tydelig avvikskø. De bør ikke være avhengige av at en medarbeider tilfeldigvis oppdager dem.

Behandle refusjon som en del av prisflyten

Prisarbeidet slutter ikke når ordren er betalt. Returer, kanselleringer og delrefusjoner må kunne spores tilbake til riktige ordrelinjer, avgifter og betalingshendelser.

En delrefusjon er mer krevende enn å trekke et beløp fra ordretotalen. Virksomheten må vite hvilket produkt som er returnert, hvor mye mva som skal tilbakeføres, om frakten skal refunderes, og om lagerbeholdningen skal økes.

Definer hvor refusjonen skal startes. Dersom ansatte kan opprette refusjon både i WooCommerce, betalingsportalen og økonomisystemet, øker risikoen for dobbeltarbeid og sprikende status. Velg én normal arbeidsflyt, og beskriv unntakene.

Bygg en testmatrise med reelle prissituasjoner

En testordre med ett standardprodukt er ikke tilstrekkelig. Lag en fast testmatrise som dekker kombinasjonene virksomheten faktisk selger med.

Den kan for eksempel inneholde:

  1. ordinært produkt uten rabatt
  2. variant med annen pris enn standardvalget
  3. kampanjepris kombinert med rabattkode
  4. ordre over og under grensen for gratis frakt
  5. privatkunde og bedriftskunde
  6. ulike mva-klasser i samme handlekurv
  7. delvis refusjon av én ordrelinje
  8. ordre med mange enheter og mulig avrundingsforskjell

For hver test bør dere sammenligne produktside, handlekurv, checkout, ordre, betalingsløsning og økonomisystem. Noter forventet resultat på forhånd. Da tester dere mot en regel, ikke bare mot det systemet tilfeldigvis viser.

Følg prisavvik som et driftsansvar

Prisflyten må overvåkes også etter lansering. Produktendringer, nye rabattutvidelser, justerte fraktregler og oppdaterte integrasjoner kan endre beregningen uten at feilen er synlig med en gang.

Etabler noen få, konkrete kontroller: ordre med negativ totalsum, uvanlig høy rabatt, manglende mva, forskjell mellom betalt beløp og ordrebeløp, og integrasjoner som avviser ordrelinjer. Fordel ansvaret for hvem som undersøker, korrigerer og dokumenterer avvikene.

Den viktigste kontrollen er likevel organisatorisk: Prisregler skal ikke endres som isolerte innstillinger. Hver endring må vurderes gjennom hele kjeden fra produkt og checkout til betaling, ordrebehandling, refusjon og regnskap. Da blir prisen ikke bare riktig på skjermen, men gjennom hele handelen.