WooCommerce Utvikler i Stavanger

En WooCommerce-butikk som selger til norske kunder må håndtere tre ting som ikke står i standarddokumentasjonen til Woo: Vipps i kassen, MVA på 25 prosent regnet riktig, og frakt via Posten/Bring eller PostNord med sporing kunden faktisk forventer. I Stavanger kommer ofte et fjerde lag: B2B-flyt for energileverandører, reservedeler og kystnære tjenester. Vi bygger og rydder opp i WooCommerce for bedrifter i Stavanger med utgangspunkt i nettopp disse kravene, ikke en generisk mal som siden lokaliseres med bynavn.

Vipps MobilePay brukes av rundt tre av fire nordmenn. En kasse uten Vipps taper konverteringer på norsk mobiltrafikk, uansett hvor pen resten av butikken er. Det er det praktiske utgangspunktet for arbeidet vårt, også når butikken sitter på Forus og selger til innkjøpere i olje- og gassverdikjeden.

#WooCommerce-utvikling i Stavanger

Stavanger-markedet er praktisk og kravtungt. Norske netthandlere er vant til kjappe kasser, Vipps-knapp øverst, fri retur innen angrefristen og tydelig pris med MVA inkludert. For B2B-butikker i energikjeden kommer i tillegg organisasjonsnummer, fakturabetaling, rollebasert tilgang og dokumentasjon som innkjøpere forventer før de legger inn ordre. Arbeidet vårt handler om å få WooCommerce til å oppføre seg slik en norsk kunde - og en norsk innkjøper - forventer, og å gjøre det på en måte som overlever oppdateringer av Woo, temaet og betalingstilleggene.

#Hva vi faktisk bygger

• Vipps MobilePay i kassen: hurtigkasse-knapp på produkt- og handlekurvside, login med Vipps der det gir mening, gjentakende betaling for abonnement, og test av webhooks for autorisasjon, belastning, refusjon og delvis refusjon mot testmiljø
• Klarna og kort (via Nets/Nexi eller Stripe) ved siden av Vipps, med riktig rekkefølge i kassen for norsk trafikk og testkort-matrise per gateway
• MVA-oppsett for norsk handel: 25 prosent standardsats, redusert sats på næringsmidler, fritak der det gjelder, og priser vist inkludert MVA slik norske forbrukere forventer
• VOEC-håndtering for butikker som selger fra utlandet inn til Norge: MVA krevd inn ved salg på varer under 3 000 kroner, riktig merking mot tollbehandling, og logikk rundt terskelen på 50 000 kroner i årlig omsetning
• Frakt med Posten/Bring og PostNord: fraktsoner, prisregler basert på vekt og volum, hentested/pakkeboks som leveringsvalg, og fraktsedler/sporing koblet mot ordrebehandlingen
• Angrerett bygget inn i flyten: retur- og angreskjema, riktig informasjon i ordrebekreftelse og e-post, slik at den lovpålagte 14-dagersfristen ikke blir en manuell jobb for kundeservice
• B2B-flater for energileverandører og maritime tjenester: felt for organisasjonsnummer, fakturaflyt, kataloger med bedriftspris, og EHF der offentlig eller større virksomhetskunde krever det
• Utvidelser av WooCommerce REST API for hodeløs storefront, mobilapp eller POS, med autentisering og idempotente betalingsstier

#Hvorfor norske betalings- og fraktvalg styrer arkitekturen

I de fleste WooCommerce-prosjekter for Stavanger er det ikke produktkatalogen som er vanskelig, det er kassen og integrasjonene rundt den. Vipps oppfører seg ikke som et vanlig kortgateway: redirect-flyten, app-switchen på mobil og webhook-bekreftelsen krever at ordrestatus ikke settes til betalt før Vipps faktisk har bekreftet. Vi har sett butikker der ordrer ble markert fullført på redirect tilbake, ikke på webhook, slik at avbrutte Vipps-betalinger ga ordrer uten penger. Den typen feil fanges bare med ende-til-ende-QA på selve betalingsstien.

Frakt er den andre fellen. En norsk kunde forventer å velge hentested hos Posten eller en Bring-pakkeboks i kassen, ikke bare «standard frakt». Når dette mangler, faller konverteringen på mobil. For reservedeler og industrielt utstyr til virksomheter langs Rogalandskysten kan frakten i tillegg være styrt av vekt, dimensjon og avtalt leveringssted - da må fraktreglene speile det, ikke et forbrukermalverk. Vi setter opp fraktsonene og leveringsvalgene som hører til det norske markedet, og kobler dem mot sporing kunden ser i e-posten.

#Markedet og miljøet i Stavanger

Stavanger er Norges energihovedstad og et tett knutepunkt for olje- og gassleverandører, maritime tjenester og teknologimiljøer knyttet til energitransisjon. Næringsparken på Forus binder sammen kontorer, leverandører og tjenesteselskaper mellom Stavanger og Sandnes. Universitetet i Stavanger (UiS) tilfører kompetanse innen energi, teknologi og samfunnsfag, og kandidater og forskningsmiljøer preger hvordan lokale virksomheter snakker om digitalisering.

For en nettbutikk betyr det ofte en annen profil enn typisk forbrukerhandel. Mange virksomheter i regionen selger reservedeler, verneutstyr, verkstedmateriell, inspeksjonsutstyr eller profesjonelle tjenester inn i energikjeden. Kjøperen er ikke nødvendigvis en privatperson med Vipps i lomma - det kan være en innkjøper som trenger organisasjonsnummer på ordren, faktura med betalingsfrist, og en katalog som speiler avtalepriser. Samtidig forventer norske forbrukerkunder fortsatt Vipps, MVA inkludert i prisen og Bring/Posten med hentested. En WooCommerce-butikk i Stavanger må ofte betjene begge sporene uten at de blander ordreformer eller MVA-logikk.

Kystnær B2B langs Rogalandskysten - maritime tjenester, logistikk, inspeksjon, turisme og profesjonelle rådgivningstjenester - har ofte sesongvariasjoner og behov for å vise kapasitet, sertifiseringer og referanseprosjekter ved siden av selve kjøpsflyten. Her er tydelige produktgrupper, dokumentfelter og gjenbrukbare blokker mer verdifulle enn en engangsdesign. Vi prioriterer redaksjonell autonomi og ytelse på mobil, fordi mange lesere treffer butikken fra felt, kai eller reise.

Mange av disse butikkene har vokst organisk over flere år: et tema fra en kjøpt mal, et halvt dusin tillegg som overlapper, og en kasse som er lappet sammen i takt med at nye krav dukket opp. Det fungerer helt til trafikken øker, et betalingstillegg slutter å bli vedlikeholdt, eller MVA-reglene endrer seg. Da er det ikke en ny plugin som trengs, men en opprydding i arkitekturen: skille ut egen kode i en egen plugin, fjerne tillegg som dupliserer hverandre, og gjøre kassen forutsigbar igjen. Vi tar denne typen refaktorering uten å bygge alt på nytt, så lenge WooCommerce er riktig plattform for det butikken skal gjøre. Er det ikke det, sier vi det skriftlig.

#Slik jobber vi gjennom et prosjekt

1. Kasse- og katalogrevisjon. Vi går gjennom dagens WooCommerce-butikk: produkttaksonomi, kasseflyt, aktive betalingstillegg (Vipps, Klarna, Nets, Stripe), fraktsoner mot Posten/Bring, MVA-regler, B2B-felter og Lighthouse-måling på de mest besøkte produkt- og kategorisidene.
2. Plan for betaling, frakt og integrasjon. Vi dokumenterer gateway-valg og rekkefølge i kassen, fraktsoner og hentestedslogikk, MVA- og VOEC-håndtering, og koblinger mot regnskap, lager eller fulfilment. For energileverandører kartlegges også fakturaflyt og eventuelt EHF. Grensen mellom Woo-kjerne, egen plugin og temakode settes her.
3. Bygging i feature-brancher. Vi følger kodestandardene til WordPress og WooCommerce, utvider Woo via action- og filter-hooks i stedet for å endre kjernen, og tester betalings- og ordrestier underveis.
4. QA på ordrestien. Handlekurv, kasse, betaling med testkort og test-Vipps på hver gateway, refusjon og delvis refusjon, retur etter angrerett, kunde-e-post og admin-redigering, kjørt i et testmiljø som speiler produksjon. B2B-flyt testes med organisasjonsnummer og faktura der det er i omfang.
5. Utrulling og overlevering. Vi deployer via en dokumentert release-prosess med testet tilbakeføring, og leverer runbook for hver gateway og hver integrasjon sammen med dokumentasjon for butikkstyrere og redaktører.

#Typiske oppdrag fra Stavanger-butikker

• Vipps mangler eller er feilkoblet. En butikk markerte ordrer betalt på redirect i stedet for på webhook. Vi flyttet bekreftelsen til webhooken, la inn idempotens slik at dobbel webhook ikke ga dobbel ordre, og satte opp full testmatrise for autorisasjon, belastning og refusjon.
• Treg kasse på mobil. En butikk med tungt tema og mange aktive tillegg hadde flere sekunders forsinkelse før Vipps-knappen var klikkbar. Vi startet med Lighthouse, WP-CLI-profil og Query Monitor på kassesiden, fant cart-fragment-kallene og autoloadede options som var skyld i mesteparten, og fjernet flaskehalsene én etter én i stedet for å installere enda et caching-tillegg.
• MVA og VOEC regnet feil. En butikk som solgte både innenlands og inn til Norge fra utlandet blandet sammen vanlig norsk MVA og VOEC-reglene. Vi skilte de to flytene, satte riktig sats per produktgruppe og fikk varer under 3 000 kroner merket riktig mot tollbehandling.
• B2B uten skikkelig ordreflyt. En leverandør i energikjeden solgte reservedeler via en forbrukerkasse uten organisasjonsnummer, med manuell fakturering etterpå. Vi skilte forbruker- og bedriftsflyt, la inn validering av organisasjonsnummer der det kreves, og koblet salg mot regnskapssystemet slik at dobbeltbokføring unngås.

#Tekniske standarder

Vi kjører WooCommerce på PHP 8.2 eller nyere, med object caching (Redis) der trafikken forsvarer det, og CDN foran statiske ressurser. Betaling går via Vipps MobilePay, Klarna og kort (Nets/Nexi eller Stripe) avhengig av hva butikken trenger, alltid med 3D Secure på kort. Tunge jobber, som synkronisering mot lager eller regnskap, kjøres via Action Scheduler i bakgrunnen slik at de ikke blokkerer kassen.

#Hva du kan forvente etter lansering

Vi lover ikke faste prosenttall, fordi resultatet avhenger av utgangspunktet. Det vi leverer er en kasse som tar Vipps på alvor og bekrefter ordrer på webhook, ikke på redirect, fraktvalg som matcher det norske kunder forventer fra Posten og Bring, MVA og angrerett håndtert i selve flyten i stedet for manuelt, og en målbar forbedring i Core Web Vitals på de sidene som faktisk konverterer. For B2B-butikker på Forus og langs kysten leverer vi i tillegg en ordreflyt som tåler organisasjonsnummer, faktura og eventuelle godkjenninger uten at forbrukerkassen ødelegges. Måltallene settes mot dagens nivå i revisjonen, ikke mot oppdiktede bransjegjennomsnitt.

#Sikkerhet og personvern

Hvert prosjekt får en sikkerhetsgrunnlinje: HTTPS med HSTS, Content Security Policy mot XSS, sårbarhetsskanning av avhengigheter i CI, tofaktor for administratorkontoer og testede sikkerhetskopier. Butikker som håndterer personopplysninger får GDPR-tilpasset samtykkehåndtering, databehandleravtale og personvern bygget inn i arkitekturen. For norske nettbutikker betyr det i praksis også at kundedata fra Vipps- og kortbetalinger, samt navn og adresse for frakt, behandles og lagres slik regelverket krever. For energileverandører som mottar tilbudshenvendelser eller dokumenter fra innkjøpere, gjelder samme disiplin på opplastinger og tilgangskontroll.

#Ytelse, målt der det teller

Core Web Vitals påvirker både rangering og konvertering, og på en nettbutikk er det kasse-, produkt- og kategorisidene som betyr noe. Vi jobber mot lav LCP gjennom optimalisert kritisk renderingsvei og forhåndsinnlasting av hero-bilder i moderne format (WebP/AVIF), lav INP gjennom minimal JavaScript og utsatt innlasting av tredjepartsskript (inkludert betalingsskript), og stabil layout (lav CLS) gjennom faste bildedimensjoner og reservert plass for dynamisk innhold som Vipps-knappen. Store PDF-er og bildegallerier fra felt - vanlig i energikjeden - skilles fra forside- og kategoriløpet slik at tung dokumentasjon ikke ødelegger LCP. Vi måler kontinuerlig med Lighthouse i utrullingsløpet, slik at en regresjon blokkerer distribusjon i stedet for å nå produksjon.

#Spørsmål Stavanger-butikker stiller oss

Setter dere opp Vipps MobilePay i kassen? Ja. Vi integrerer hurtigkasse-knapp, login og gjentakende betaling der det passer, og tester autorisasjon, belastning, refusjon og delvis refusjon mot testmiljø før lansering. Bekreftelse av betaling skjer på webhook, ikke på redirect tilbake til butikken.

Kan dere håndtere MVA og VOEC riktig? Ja. Vi setter 25 prosent standardsats og reduserte satser der de gjelder, viser priser inkludert MVA slik norske forbrukere forventer, og skiller VOEC-flyten for varer under 3 000 kroner solgt fra utlandet inn til Norge fra ordinær innenlands MVA.

Hvilke fraktløsninger støtter dere? Posten/Bring og PostNord, med fraktsoner, prisregler etter vekt og volum, hentested og pakkeboks som leveringsvalg, og fraktsedler og sporing koblet mot ordrebehandlingen. For tungt eller industrielt gods dokumenteres egne regler når standard pakkeløsning ikke holder.

Endrer dere WooCommerce-kjernen? Nei. Tilpasninger går via dokumenterte action- og filter-hooks, med en klar deling mellom egen plugin og tema, slik at butikken overlever Woo-oppdateringer.

Jobber dere med butikker utenfor Stavanger? Ja. Vi har tyngdepunktet i Stavanger-regionen og Forus, men leverer til netthandlere i hele Norge og til norske butikker drevet fra utlandet.

#Integrasjoner en norsk nettbutikk faktisk trenger

En norsk nettbutikk på WooCommerce ender som regel opp med de samme fire koblingene: betaling med Vipps MobilePay og kort, frakt med Posten/Bring eller PostNord inkludert hentesteder, regnskap i Fiken eller Tripletex, og en ordrestatus som settes av serveren til leverandøren, ikke av at kunden tilfeldigvis kommer tilbake til takkesiden. Rekkefølgen er ikke tilfeldig: hver kobling nedover i listen arver feilene fra den over hvis den første ikke er riktig bygget. For B2B i energikjeden kommer ofte en femte kobling: ERP eller lagerstyring som speiler reservedelslager og avtalepriser.

#Betaling: Vipps MobilePay ved siden av kort

Vipps er en app-switch, ikke et skjema. Integrasjonen bygges mot ePayment-API-et for engangskjøp og mot avtale-API-et for gjentakende trekk. Butikken oppretter en betaling, sender kunden til appen og venter. Alt som skjer etterpå er utenfor nettleserens kontroll. Derfor implementeres gatewayen som en vanlig WC_Payment_Gateway-klasse der process_payment returnerer en redirect og ingenting mer, mens fullføringen skjer i callback-håndtereren. Ordren får payment_complete først når leverandøren har bekreftet.

Reserver nå, trekk ved forsendelse. Norsk praksis for varesalg er å reservere beløpet ved kjøp og trekke det når varen sendes. Det betyr at integrasjonen må skille tydelig mellom autorisasjon, belastning, delvis belastning, annullering og refusjon, og at hver av disse må kunne utløses både fra Woo-admin og fra en bakgrunnsjobb. Delvis belastning er en vanlig kilde til avvik når en ordre sendes i to forsendelser - typisk når reservedeler går i ulike pakker eller fra ulike lagre.

Kort går ved siden av, ikke i stedet for. Nets/Nexi eller Stripe dekker kunder som ikke bruker Vipps, alltid med 3D Secure. To gatewayer betyr to sett med statuskoder, to refusjonsmodeller og to webhook-formater, så ordren må lagre i metadata hvilken gateway som eide betalingen og hvilken referanse den bruker. Uten dette blir refusjon fra admin et gjettespill.

HPOS må deklareres. På butikker med High-Performance Order Storage må egen plugin-kode melde kompatibilitet via FeaturesUtil::declare_compatibility på before_woocommerce_init, og all lesing og skriving av ordredata må gå gjennom wc_get_order og CRUD-metodene i stedet for direkte postmeta-kall. Gammel gateway-kode som skriver med update_post_meta slutter å virke uten å gi feilmelding.

#Frakt: Bring, Posten og PostNord med hentesteder

Fraktpriser hentes, de gjettes ikke. Bring Shipping Guide gir pris og leveringstid per produkt og postnummer, autentisert med API-nøkkel og kundenummer fra Mybring. Svaret kobles inn i kassen via woocommerce_package_rates, med volumvekt regnet ut fra pakkens dimensjoner der den overstiger faktisk vekt. Svarene mellomlagres i transienter per postnummer og vektklasse, fordi kassen ikke kan vente på et eksternt kall ved hver oppdatering av handlekurven.

Hentested er et eget datafelt. Kunden velger et konkret utleveringssted eller en pakkeboks i kassen, og valget må lagres på ordren som en identifikator fra leverandøren, ikke som fritekst. Fraktsedlene genereres senere mot den identifikatoren. Skrives den som en adresse i et notatfelt, må lageret slå den opp manuelt, og fordelen ved integrasjonen forsvinner.

Tidsavbrudd krever en reserveløsning. Når frakt-API-et ikke svarer, skal kassen falle tilbake til en definert standardsats i stedet for å vise en kasse uten fraktvalg. Feilen logges via wc_get_logger med egen kilde, slik at hyppige tidsavbrudd blir synlige i WooCommerce-loggen før kundeservice oppdager dem.

Sporing hører hjemme i e-posten. Sporingsnummeret lagres på ordren og skrives inn i forsendelsesvarselet, typisk via woocommerce_email_before_order_table. Det fjerner en av de vanligste henvendelsene til kundeservice.

Tungt gods og avtalt levering. Når butikken selger utstyr som ikke passer i en pakkeboks - vanlig for verkstedmateriell og industrielt utstyr til virksomheter i Rogaland - dokumenteres egne fraktalternativer: frakt etter avtale, henting på Forus, eller spesialtransport. Disse skal ikke forstyrre den vanlige forbrukerflyten med Bring og Posten.

#Regnskap: Fiken eller Tripletex

Salget bokføres én gang, med riktig MVA-kode. Både Fiken og Tripletex har REST-API med token-basert autentisering. Integrasjonen oppretter kunde og salgsdokument, og mapper hver produktgruppe til riktig MVA-kode i stedet for å sende en flat sats. Nummeret på det opprettede dokumentet skrives tilbake på ordren, og eksistensen av dette nummeret er det som hindrer dobbeltbokføring ved en ny kjøring.

Avstemming er mot utbetaling, ikke mot ordre. Betalingsleverandøren utbetaler samlet og trekker gebyr. Regnskapet stemmer først når integrasjonen bokfører utbetalingen som en egen post med gebyret skilt ut, ikke når hver ordre er bokført hver for seg.

B2B og offentlig sektor betyr EHF. Selger butikken til offentlige oppdragsgivere i Norge, eller til større virksomhetskunder i energikjeden som krever elektronisk faktura, skal fakturaen sendes som EHF over Peppol-nettverket, med organisasjonsnummer på mottakeren. Det er en egen flyt i kassen: felt for organisasjonsnummer, validering, og et annet dokumentløp enn forbrukersalget.

Oppbevaringsplikt og SAF-T. Bokføringspliktig dokumentasjon skal oppbevares i fem år etter regnskapsårets slutt, og regnskapssystemet må kunne levere SAF-T Regnskap på forespørsel fra Skatteetaten. I praksis betyr det at butikken ikke er regnskapssystemet: WooCommerce er kilden, Fiken eller Tripletex er arkivet, og integrasjonen må overføre nok informasjon til at arkivet er komplett uten oppslag i databasen til nettbutikken.

Synkronisering kjøres i kø. All overføring til regnskap legges på Action Scheduler med gjentatte forsøk ved feil, aldri synkront i kasseforespørselen. En regnskapstjeneste som er nede, skal forsinke bokføringen, ikke blokkere et kjøp.

#B2B for energikjeden og kystnær handel

Organisasjonsnummer før betaling. For bedriftskjøp valideres organisasjonsnummer i kassen, og lagres på ordren slik at faktura og regnskap får samme identifikator. Uten dette blir avstemming manuell.

Katalog og pris per bedrift. Når leverandører i olje- og gassverdikjeden har avtalepriser, bygges dette som egne kundegrupper, katalogregler eller egne plugins - ikke som hardkodede rabatter i temaet. Da kan salgsteamet på Forus oppdatere priser uten å røre temakode.

Rollebasert tilgang. Innkjøpere, godkjenner og butikkansvarlig trenger ulike rettigheter. Vi skiller kundekontoer og adminroller tydelig, og dokumenterer hvem som kan se lagerstatus, hvem som kan godkjenne ordre, og hvem som kan utløse refusjon.

Dokumentasjon uten å drepe ytelsen. Sertifikater, datablad og HSE-dokumenter er vanlige i energileveranser. De lagres som egne felt eller dokumentbibliotek, med lazy-loading og caching som hindrer at store PDF-er bremser produkt- og kategorisider.

#Hvorfor ordrestatus må settes server-til-server

Takkesiden er et løfte, ikke et bevis. Kunden kan miste dekning på ferja til Tau, lukke appen på vei gjennom Forus, bytte til en annen app mens betalingen fullføres, eller ha nettleseren i bakgrunnen når batteriet sparer strøm. Redirect tilbake til butikken er dermed en hendelse som kanskje skjer. Betalingsbekreftelsen fra leverandørens server er en hendelse som skjer uansett, og det er den ordrestatusen skal henge på.

Verifiser først, kvitter raskt, jobb etterpå. Callback-endepunktet skal først verifisere signaturen på varselet mot delt hemmelighet, deretter svare med en rask kvittering, og først etterpå gjøre det tunge arbeidet i en bakgrunnsjobb. Leverandører prøver på nytt når svaret drøyer, og et tregt endepunkt utløser dermed flere kopier av det samme varselet.

Idempotens lagres, den antas ikke. Hvert varsel har en identifikator. Den lagres når hendelsen er behandlet, og et varsel med en allerede lagret identifikator forkastes. Uten dette gir gjentatte forsøk dobbel belastning, dobbel bokføring i regnskapet og dobbelt kunde-e-post. Hendelser kan også komme i feil rekkefølge, så håndtereren må tåle en belastningsmelding som kommer før autorisasjonsmeldingen.

Endepunktet må være åpent for maskiner. Callback-URL-en skal holdes utenfor sidecache, ikke stå bak passordbeskyttelse eller IP-sperre, og ikke ligge på et testmiljø som krever innlogging. Dette er en vanlig årsak til at en integrasjon virker i testmiljø og ikke i produksjon.

Avstemmingsjobben er sikkerhetsnettet. En planlagt jobb henter status fra leverandøren for ordrer som har blitt stående som ventende lenger enn et definert vindu, og retter opp der varselet aldri kom fram. Jobben kjøres via ekte systemcron mot wp cron event run --due-now med DISABLE_WP_CRON satt, fordi WordPress’ egen pseudo-cron avhenger av trafikk og dermed er upålitelig akkurat når butikken er stille om natten.

Testing gjøres på feilstiene. Testmatrisen dekker ikke bare vellykket betaling, men avbrutt betaling i appen, varsel som kommer to ganger, varsel som kommer i feil rekkefølge, forsinket varsel, frakt-API som svarer for sent, og regnskaps-API som avviser dokumentet. Hver av disse skal ende i en ordre med riktig status og en linje i loggen. Reaksjonstider ved feil i drift avtales skriftlig i vedlikeholdsavtalen.

#WooCommerce for energileverandører på Forus

Mange Stavanger-virksomheter lever av å levere utstyr, tjenester eller kompetanse inn i olje- og gassverdikjeden, eller i tilstøtende områder som havvind, karbonfangst og energiinfrastruktur. Det digitale ansiktet utad - og nettbutikken bak - er ofte det første inntrykket en innkjøper eller partner får. En WooCommerce-butikk i denne konteksten må typisk håndtere:

• Produktkataloger med SKU-er som speiler reservedeler og forbruksvarer, ikke bare forbrukervarianter
• Flerspråklig oppsett når målgruppen inkluderer både norsk og engelsk B2B-kommunikasjon
• Tydelige kontaktflater og leveringsvalg for virksomheter med adresse på Forus, i Stavanger sentrum eller langs kysten
• Integrasjon mot lager eller ERP slik at synlig lagerstatus ikke lyver til innkjøperen

Jeg bygger dette som egne plugins og felter, ikke som hardkodede maler i functions.php. Da kan butikkstyrere i Stavanger oppdatere katalog og priser når markedet skifter, uten at hvert skifte blir et utviklingsoppdrag.

#Forus som operasjonelt tyngdepunkt

Forus er regionens tyngste næringspark og samlingspunkt for mange selskaper i energikjeden og tilknyttede tjenester. En nettbutikk som skal støtte salg og fulfilment derfra, trenger ofte:

• Klare leveringsadresser og hentemuligheter knyttet til lager eller kontor
• Landingssider som speiler konkrete produkt- eller tjenestespor uten å duplisere hele temastrukturen
• Rollebasert tilgang for salg, lager og økonomi, slik at ikke alle har samme rettigheter i Woo-admin

Universitetet i Stavanger bidrar til et miljø der forskningsformidling, studentrettet informasjon og samarbeid med næringslivet møtes. For WooCommerce er det sjelden UiS som er kunden - men kompetansemiljøet påvirker forventningene til dokumentasjon, flerspråklighet og profesjonell presentasjon av katalog og tjenester.

#Kystnær B2B-ehandel

Kystnær handel i Rogaland blander ofte fysisk vare, tjeneste og dokumentasjon. En butikk kan selge reservedeler én uke og booke inspeksjonskapasitet neste. WooCommerce egner seg når kjernen er produktkatalog, ordre og betaling; når hovedjobben er booking eller prosjektstyring, sier vi det skriftlig og foreslår riktigere verktøy. Der WooCommerce er riktig, prioriterer vi:

• Mobilvennlig kasse for kjøpere som bestiller fra felt eller kai
• Frakt- og henteregler som speiler faktiske lagerpunkter i regionen
• E-postflyt med sporingsnummer og tydelig ordrestatus, fordi kundeservice ellers blir flaskehalsen

#Andre norske byer

Trenger du WooCommerce-hjelp i en annen norsk by, gjelder de samme norske kravene til Vipps, MVA og frakt, men med lokal logistikk og kundemønster. Se også WooCommerce-utvikler i Bergen og WooCommerce-utvikler i Trondheim for hvordan oppsettet tilpasses der.

#Start et WooCommerce-prosjekt i Stavanger

Trenger butikken din i Stavanger, på Forus eller langs kysten en kasse som tar Vipps på alvor, regner MVA riktig og lar deg styre frakten selv - og eventuelt betjene B2B-kjøp i energikjeden uten å ødelegge forbrukerflyten - ta kontakt for en uforpliktende gjennomgang. Vi ser på dagens oppsett, peker på den faktiske flaskehalsen og gir en ærlig vurdering av hva som bør gjøres først. Prisen settes individuelt etter omfang, og du får oversikten skriftlig før arbeidet starter.