Kildenotater fra gjennomgangen av Miro-tavla (arbeidsnotater, september 2026)

Råe notater per ramme, skrevet under lesingen. Brukes for sporbarhet. De redigerte sidene ligger i systemarkitektur/.

Seksjonsoverskrifter på tavla (løse tekster) og hva som ligger under

“Produktvarianter” (x -53555): Docs-rammen “Produkter”.
“GoLive Utlevering i butikk” (x -49499): kun ett stort skjermbilde (ikke lesbart, ikke i PDF). ÅPENT.
“Jobber” (x -39462): Cron-jobber Azure og Omnium.
Fastly-/stackbeskrivelse (x -35789) og doc Kunnskapsoverføring (x -35551).
“Produktopprettelse” (x -26533): Product creation and update BC.
“Kundeopprettelse” (x -20289): Customer club AS-IS, TO-BE, Vipps (forkastet).
“Klikk&Hent + retur (POS)” (x -10243): Click & Reserve-rammene og Returns in store.
“Utlevering i butikk” (x -6269): Click & Collect.
“Byttegull”: Docs, Matrix, Catalogs, Ordreprosess, TOGAF-faser, Kommunikasjonsflyt, Ordrestatus og epostløp.
“Brudekjoler - En gang til” (x 15534).
NoA - Arkitektur (x 32902): opprinnelig arkitektur fra NoA.
Salg og returer / 26.01.26 / 27.01.26: PowerBI-butikkrapport.
Helt til høyre (x 60089+): Datamodel PowerBi, BC, Omnium, XAL orders. Språkbruk: overskriftene tyder på Klikk & Hent = Click & Reserve (betal i butikk) og Utlevering i butikk = Click & Collect (betalt på nett, sendt fra lager). Men PowerBI-notatet skriver ‘Klikk&Hent “Utlevering i butikk”’, så begrepene brukes ikke konsekvent. ÅPENT: bekreft navnene som brukes ut mot butikk og kunde.

Kilde: Doc “Kunnskapsoverføring - Gullfunn.no” (løst på tavla, id 3458764677133676649) = PDF s. 1-8

Dato 8. april 2025. Deltakere: Espen Rosenberg Hansen, Tormod Ulsberg, Torbjørn Holtmon.

Ansvarstabell (beskrivelser avkuttet i kilden)

1 BS-integrasjoner (BC, Sylvsmi[dja]…) - Dragos - Integrasjoner mot eksterne fo[rhandlere?]… 2 Synkronisering mellom BS og … - Dragos - Sørger for at data fra Busines[s Central?]… 3 Synkronisering til Elevate - Torbjørn - Overfører produkt- og katego[ridata]… 4 Synkronisering til Sanity - Torbjørn / Ragnar - Overfører data til Sanity, som… 5 Synkronisering til Channable - Torbjørn - Sender produktdata til Chann[able]… 6 Pris-, lager- og transaksjonssy[nk] - Tormod / Torbjørn - Sikrer at priser, lagerbeholdni[ng]… 7 Ordreflyt (NShift, Klarna, Vipp[s]…) - Torbjørn / Tormod - Håndterer ordreprosessen fra… 8 Kindly - Tormod - Chat- og kundeserviceplattfor[m] 9 Kundeopprettelse (Azure og …) - Tormod / Torbjørn - Håndterer opprettelse og syn[kronisering]… ÅPENT: “BS” = BlueStone? (Docs-rammen nevner “BLUESTONE” og “BS/Omnium”). Hvem er Dragos/Ragnar (NoA? Adapt?).

Stack gullfunn.no

TypeScript overalt (frontend og backend).
Astro frontend: valgt for god integrasjon med Cloudflare Pages, høy ytelse, lite JS til klient, fleksibel caching/deploy.
Svelte for interaktive komponenter. Tailwind CSS for styling, vanlig CSS der Tailwind ikke passer.
GraphQL-lag mellom frontend og Omnium: hente akkurat de feltene som trengs, nye funksjoner uten nye Omnium-integrasjoner, gjenbruk av spørringer, fleksibelt for f.eks. huskelister. Eksempel: produkt + varianter + kategorier i én forespørsel.
Status GraphQL: nyere Adapt-prosjekter har gått bort fra GraphQL (kompleksitet, læringskurve, vedlikehold). Ingen planer om å fjerne det på Gullfunn. Sannsynlig strategi: nye funksjoner uten GraphQL, gammelt beholdes, gradvis migrering.
Implisitt: Adapt er utviklingsbyrået (egen ramme “Adapt”).

Infrastruktur

Cloudflare Pages: alle deployer. Rollback til tidligere versjoner umiddelbart. Branch deployments ved behov, koster ingenting når ubrukt, nyttig for test/QA.
Caching i flere lag:
- Fastly CDN foran applikasjonen: cache-intervall + stale-while-revalidate (bruker får cachet innhold straks, oppdatering i bakgrunnen). Purge ved deployment ved behov.
- Intern cache i Cloudflare for header, footer, kampanjer, kategorier, brands. Mål: færre kall til Sanity m.fl.
- Løs tekst på tavla: “Fastly → CDN/cache optimalisering, Cloudflare → app-plattform (front…), Astro → siden, Svelte → UI-komponenter, TypeScript → språk, Tailwind → styling”.

Synkroniseringer

Sanity oppdateres via cron-jobber. Begrenset innsikt i kjøringene. Logging primært i Azure Functions. Forbedringsforslag: dashboards, manuelle kjøringer, mer detaljert logging.
Elevate mottar produktdata via planlagte synker. Elevate-logger gir lite innsikt; feilsøking krever Azure-logger og intern synklogikk.

Feilsøking og observabilitet

Utfordringer: få logger i Omnium, lite info om hva som feiler, krever ofte bistand fra NoA (ÅPENT: hvem er NoA? Omnium-leverandøren?).
Forslag: egen database for loggdata + eget grensesnitt i Sanity med synk-status, feilede produkter, feilårsaker, manuelle kjøringer. Gevinst: egenfeilsøking, mindre NoA-kontakt, raskere å skille engangsfeil fra systematiske feil.
Oppsummering nevner: “aktuelt å etablere bedre innsikt og styring via Sanity fremfor Omnium”.

Typiske produktfeil (synk til Elevate)

Duplikate produkter: samme variant-ID på flere produkter. Voyado/Elevate tillater ikke det. Ett synkes, det andre hoppes over.
Manglende størrelsesattributter: produkter uten påkrevd variantinfo utelates.

Azure Storage Queue

Mellomlager for flere integrasjoner: Business Central, Logic, ordreeksport, diverse. Flyt: data i kø → Azure Function plukker opp → sendes til sluttsystem.

Postman

Omnium API: opprette API-klient, bearer-token, miljøvariabler, autorisering, GET/PATCH/POST. Anbefalinger: egen API-klient for personlige tester, PATCH fremfor PUT for enkeltfelt, forsiktig mot prod. Bruk: kontrollere rådata i Omnium, feilsøke ordre/produkter, validere integrasjoner.

Systemoversikt (ordrett innhold, kortet)

Omnium: sentral e-handelsplattform: produkter, priser, lagerstatus, kunder, ordre, kampanjer. Nav for de fleste integrasjoner. (Andre rammer: Omnium = OMS)
Sanity: headless CMS: kampanjesider, kategoritekster, artikler, menyer, header, footer.
Voyado Elevate: søk og anbefalinger, filtrering, merchandising.
Channable: produktdata til Google Shopping, Meta, Prisjakt m.fl.
Business Central (BC): MS Dynamics 365 ERP: økonomi, produktinfo, lager, innkjøp.
Sylvsmidja: ekstern leverandør og produktkilde med egne integrasjoner.
Logic: eksternt forretningssystem for utveksling av produkter, lagerdata eller ordreinfo.
Vision Point: butikkdatasystem (POS) i fysiske butikker: produktopprettelse, salg, lager, transaksjoner, synket med Omnium. (Andre rammer skiller VisionPoint = produktdatabase/webportal og VisionPos = POS)
Azure Functions: serverløse integrasjoner, synker, bakgrunnsjobber.
Azure Storage Queue: meldingskø mellom systemer.
Cloudflare Pages: hosting/deploy frontend.
Fastly: CDN.
NShift: frakt: sendinger, transportører, etiketter, sporing.
Klarna: faktura, delbetaling, kort.
Vipps: betaling i Vipps-appen.
iGive: donasjoner/støtteordninger knyttet til kjøp eller kampanjer.
Kindly: kundeservice- og chatbot.
Postman: API-testing.
GraphQL: API-lag frontend↔Omnium.

Kilde: PDF s. 9 “SCOPE” (Byttegull-prosjektet)

In scope: kundeprosess for innlevering av gull (butikk + hjemmefra); nytt skjema og live gullpriser i Sanity; integrasjon mot Verified (BankID); ny ordretype i Omnium OMS; integrasjon mot BC for utbetalinger; nShift for frakt; automatiserte e-poster fra Omnium; prisvurdering gjennom NC; informasjonsflyt ved angrerett; politirapportering hver 14. dag (delvis manuell/automatisert); overordnet arkitekturdesign. Out of scope: CRM-endringer, endringer i butikk-POS, ingen endringer i PIM, dyp BC-optimalisering utover Byttegull, andre varetyper (sølv osv.). ÅPENT: hva er NC? (Home delivery-flyten har “NC BC” og “Gullfunn BC” som to BC-selskaper. NC = sentrallager/selskap?)

Ramme: Simplified architecture (3458764596718000905)

Forklaring (legend): VisionPoint = Product database and WEB portal; Omnium = OMS; Elevate = Find and discover engine; Bluestone = PIM; Sanity = CMS; Nshift = Shipping management and booking; Logic = Product information database; Kustom = Checkout and payment; JFS Services = Logistics and finance. Bokser: “Online store” (www.gullfunn.no) inneholder Sanity (CMS), Elevate (Søkemotor), Omnium (OMS), nShift, Kustom, Bluestone (PIM). “Produktregister, service og kasseløsning” inneholder VisionPoint. Utenfor: Logic (Produktdatabase), Lager Kristiansand. Piler:

Logic → Produktregister/kasse (VisionPoint): Produktinformasjon
Produktregister/kasse → Bluestone: Produktinformasjon
Bluestone → Omnium: Produkter
Produktregister/kasse → Omnium: Lagerbeholdning
Lager Kristiansand → Omnium: Lagerbeholdning
Omnium → Elevate → Sanity (uten tekst)
Sanity ↔ Omnium: Produkt- og ordreinformasjon Observasjoner: Kustom som checkout (Klarna-avleggeren Kustom). Ingen BC her; JFS Services står i forklaringen men ikke i diagrammet. Sannsynligvis tidligere/forenklet bilde. ÅPENT: er Lager Kristiansand = NC? Er Kustom fortsatt checkout, eller Klarna/Vipps direkte?

Ramme: Detailed Overview (3458764670381148372): mest komplette systemkart

Legend: VisionPoint = Product database; VisionPos = POS; Omnium = OMS; Voyado Engage = CRM; Voyado Elevate = Find and discover engine; Bluestone = PIM; Sanity = CMS; BC = ERP; Sylvsmidja = Supplier; Logic = Product information database; Kindly = Chatbot; Channable = Product Feeds; PowerBi = Business intelligence; Kustom = Checkout and payment; Nshift = Shipping management; Bring = Freight provider.

Grupper:

“Data sources, ERP and Warehouse”: BC, Warehouse, Sylvsmidja, Excel import, Logic.
“Online store” (www.gullfunn.no): Sanity, Elevate, Bluestone, Omnium, Kustom, Nshift. Aktører: Customer, PIM manager (ved Bluestone).
“Store data system”: VisionPoint, VisionPos. Aktør: Category manager.
“Other third party vendors”: Bring, PowerBi (aktør Solution Architect), Engage (SMS/EMAIL til Customer), Kindly (Customer), Channable → Advertising (Ads til Customer).
“Other external vendors” (aktører Vendor, Gullfunn, Customer) → Logic.

Piler:

Logic → VisionPoint: Product info
VisionPoint → Bluestone: Product info
Excel import → Bluestone: Product info
BC → Bluestone: Product info and images
Sylvsmidja → Bluestone: Product info
Logic → Bluestone: Images
BC → Logic: NC product update/creation
Sylvsmidja → Logic: Sylvsmidja product update/creation
Other external vendors → Logic
Bluestone → Omnium: Produktinfo
Omnium → Elevate: Product info
Elevate → Sanity: Product info
Sanity → Elevate: Event’s and content
Omnium → Sanity: Product, Order and Customer info
Omnium → Engage: Product, Order and Customer Info
Omnium → Kindly
Omnium → Channable: Product info; Channable → Advertising: Product info
Omnium → PowerBi: Data
Omnium → BC: Order data
BC → Bring: Freight booking Tolkning: Produktdata har to innganger til Bluestone (PIM): via Logic → VisionPoint → Bluestone, og direkte fra BC/Sylvsmidja/Excel. Logic ser ut til å være masterregister for produkter fra NC (via BC), Sylvsmidja og andre leverandører, og leverer bilder til Bluestone. Omnium er navet ut mot kanalene. Ordre går Omnium → BC, og BC booker frakt hos Bring. ÅPENT: Hva er forholdet NC / BC / Warehouse? Er Kustom i bruk (dokumentet 8. april 2025 nevner Klarna og Vipps, ikke Kustom)?

Ramme: BC (3458764601856815562)

Tekst: «New Order» in the webshop will be sent to GullFunn AS in BC. Bilde (image004.png, blått blokkdiagram) ikke lesbart: r.miro.com blokkert av egress. ÅPENT: bruk PDF-side eller få r.miro.com på allowlist.

Ramme: Omnium (3458764617431399022)

Lenke: https://docs.omnium.no/#/api/carts?id=cart-data-flow . Bilde: sekvensdiagram “Carts” (Omniums dokumentasjon av handlevognflyt). Ikke lest.

Ramme: Home delivery order flow BC (3458764622358470660)

NB på tavla: “Ship from store not active”. Legend: VisionPoint (Product database and WEB portal), VisionPos (POS), Omnium (OMS), Voyado Engage (CRM), Sanity (CMS), JFS Services (Logistics and finance), Nshift (Shipping management and booking), Bring (Shipping). Bokser: Online store (Sanity, Omnium); Store data system (VisionPoint, VisionPos); Other third party vendors (Engage, Nshift, Bring); en boks med Gullfunn BC, NC BC, EWMS, Nshift; Guldbolaget utenfor. Fargekoder på piler: blå = Option 1 ship from warehouse; lilla = Option 2 ship from store.

Felles: (1) Kunde legger ordre i Sanity (nettsiden) → Omnium (2 & 10.1) Omnium → kunde: SMS/EMAIL 10.2 Omnium → Engage: transaksjon registreres på kunden

Option 1, ship from warehouse (aktiv): (3) Omnium → Gullfunn BC: Request for items (4) Gullfunn BC ↔ NC BC: overfør ordre til NC ordreimport (ordreimport → Ordrer) (5.1) NC BC ↔ EWMS: Create picking; (6.1) Confirmed picking (5.2) NC BC ↔ Guldbolaget: order ex products; (6.2) receive ex. products (7) NC BC ↔ Nshift: delivery note / return shipping label (8) NC BC → Gullfunn BC: confirmed shipping info (9) Gullfunn BC → Omnium: items confirmed (11) NC BC → Omnium: get shipping number; Bring ↔ Nshift: get tracking number (12) Nshift → NC BC: tracking number (13) EWMS ↔ Bring: retrieve product(s) (14) Bring → kunde: send product(s)

Option 2, ship from store (ikke aktiv): (3) Omnium → Store data system: Picking (4) Store → Omnium: items confirmation (5) Omnium → Nshift: book shipment; Nshift → Bring (6) Bring → Omnium: confirm shipment (7) Omnium → Store: order confirmed and booking URL created

Tolkning: Gullfunn AS har egen BC-instans (Gullfunn BC). NC har egen BC (NC BC) med lagersystem EWMS. Varer NC ikke har på lager hentes fra Guldbolaget (“ex products” = eksterne produkter?). ÅPENT: Hva står NC for (leverandør/grossist/søsterselskap?). Guldbolaget = svensk leverandør? Hva er “ex products”?

Ramme: Home delivery detailed flow with shipFromStore BC (3458764622358320910)

NB: “Ship from store not active”. Legend: VisionPoint, VisionPos, Omnium, “JFP Services” (skrivefeil for JFS?), Voyado Engage, Bring, Nshift. Fargekode på bokser: svart = Omnium-steg, lys gul = VisionPoint/butikk-steg, oransje/gul = VisionPos, grå = fysisk.

Checkout: “KUSTOM CHECKOUT” med Shipping options (Nshift) og Payment options (Credit card, Vipps, Klarna, Electronic gift card) → “Home delivery order is placed” (Order Status: Ny). → “Orderline(s) is allocated to store(s) and BC”. Grønn pil: Whole order amount is reserved (Online order: Credit card/Vipps/Klarna/Electronic gift card). Unntak: gavekort har ingen reservasjon; beløpet trekkes når ordren legges.

Orderflow-regler i Omnium (tagging):

Omnium: bunadsølv → tagg bunadsølv; giftering → tagg giftering; gebyrBrudekjole → tagg gebyrBrudekjole.
Noa: helt/delvis betalt med gavekort → tagg Giftcard; kjøpt av medlem → tagg “medlem”, ellers “ikke medlem”; produkt med diamanter → legg til asset diamantsertifikat. Sticky: eget e-postmal for bunadsølv og giftering (ved Ny). Ved Sendt: egne maler for bunadsølv, giftering og gebyrBrudekjole; diamantsertifikat vedlagt og tilgjengelig på MinSide.

Gren “BC” (aktiv, sentrallager): (1) Gullfunn BC ↔ NC BC: overfør ordre til NC ordreimport (ordreimport → Ordrer); (5) confirmed shipping info tilbake (2.1) NC BC ↔ EWMS: create picking; (3.1) confirmed picking (2.2) NC BC ↔ Guldbolaget: order ex products; (3.2) receive ex products (4) NC BC ↔ Nshift: delivery note / return shipping label; (8) shipping label 6. Gullfunn BC → “Orderline status updated” (items confirmed) 9. NC BC → Orderline status updated: get shipping number Orderline(s) Status: Sendt. Hvis alle linjer i én sending → “Order status updated” (Order Status: Sendt, e-post/SMS-mal https://oms.omnium.no/administration/notifications/34173a83-7ed3-4df6-9f1c-40627f1d56b4) → Voyado Engage: Added orders. Ved delvis levering: produktbeløp trekkes per sending (grønn pil).

Gren “Store” (ship from store, ikke aktiv): Notification is shown in store(s) → Print out picking list → Set all products as picked

False → Delete order → Order is deleted (Order Status: “Ordre kansellert av butikken”, e-post/SMS-mal) ; Nightly rutine: Go through deleted orders → Stock adjustment
True → Orderline status updated (Sendt) → Booking shipment (Bring) → Freight label is produced → URL for freight label is received (sticky: refresh site after 1 min) → Print out freight label → Pack the product(s) and complete the sale → Package forwarded to shipping provider. Pack/complete sale → The transaction → BC finance settlement: match transaksjonen i POS mot Ecom / Gullfunn AS bankkonto. Grønn pil fra Online order: “Settlement: Amount that is shipped from store”. Products amount is withdrawn når orderline status oppdateres. Nshift/Bring: “Bulk update every day 16:00”, (7) get tracking number.

ÅPENT: “Noa” står som ansvarlig for noen taggeregler: er Noa Omnium-partneren (samme som NoA i kunnskapsoverføringen)?

Ramme: Click and Reserve order flow (3458764563450667669)

Systemer: Online store (Sanity → Omnium), Store data system (VisionPoint, VisionPos), Other third party vendors (Engage). (1) Sanity → Omnium: order is placed (2) Omnium → Store: picking (3.1) Store → Omnium: items confirmation; (3.2) Not found → Cancelled → Order Status: OrderCalceledByStore (4.1) VisionPos → Omnium: items PickedUp → Order Status: PickedUpAndPaid → (5) transaksjon registreres på kunden i Engage (4.2) Omnium: Cancelled → OrderCanceled (4.3) Omnium: Not Collected → NotCollected Merk: statusnavnene her er engelske systemnavn; den detaljerte flyten bruker norske visningsnavn.

Ramme: Click & Reserve detailed flow (3458764583224600452)

Legend: VisionPoint, VisionPos, Omnium, Payment, Voyado Engage.

Click & Reserve order is placed (Omnium) → Order Status: Ny (e-post/SMS-mal 149e98f6-113f-40e4-b40e-33eb76b14f14)
Notification is shown (VisionPos) → Print out picking list → Set product as picked (VisionPoint) 3a. False (ikke funnet) → Delete order → Order is deleted → Order Status: “Ordren kansellert av butikk” (mal a6c95eac-d35a-4172-a7ff-346be5082822; lenketeksten peker på f8cbe41c-…, avvik i Miro). Kveldsrutine i butikk: Go through deleted orders → Stock adjustment. 3b. True → Order status updated → Order Status: “Klar for henting” (mal 5cf6f7a9-9043-43fc-87d8-cb85878b8c96) Valgfritt (stiplet): butikken kansellerer manuelt → Order is cancelled → Order status updated → “Ordren kansellert” (mal 49385a5d-986d-4903-9dcb-2092ff742070)
Customer comes to shop to pick up product False (48 timer har gått) → Order is cancelled → Order Status: “Ikke hentet i tide” → Cancellation email to customer and store (mal 2df7b4b8-f325-4106-9aa1-fa34165e82b1) → Delete order (VisionPos) → Product is placed back in store True → Find and select order (VisionPos) → Optional: cross sale products added → Select payment method (Cash, Credit card, Gift card) → Omnium: payment info, nye ordrelinjer med kommentar “Extra” (valgfritt) og ny status → Order Status: “Hentet og betalt” → Voyado Engage: Added orders Poeng: Click & Reserve betales i butikk, ikke på nett. Mal-URL-er: https://oms.omnium.no/administration/notifications/

Ramme: Click&Collect order flow (3458764643226907673)

Varen sendes fra sentrallager til butikk; kunden betaler på nett (til forskjell fra Click & Reserve).

Sanity → Omnium: order is placed
Omnium → Warehouse: order is transferred 3.1 Warehouse → Omnium: order status sent (Order Status: Sent); 3.2 Warehouse → Store (VisionPoint): product(s) sent
Omnium → Engage: transaksjon registreres på kunden
Store → Omnium: confirm received (ReadyForPickup)
Store → Omnium: customer picks up (PickedUp)

Ramme: Click&Collect detailed flow (3458764643226907674)

Legend: VisionPos, Omnium, Voyado Engage, JFS Services. Viktig merknad på tavla: I motsetning til Click & Reserve er ordrene skjult i VisionPos. All ordrehåndtering skjer i VisionPoint, og ordrene er utelatt fra POS-salgsdataene. Flyt:

Click & Collect order is placed (Order Status: Ny; e-postmaler som bilder)
Order → VisionPoint: “Order is in Sales Order”
Order is placed → Warehouse → Order status sent → “Order is sent” (Status: Sent) → Voyado Engage: Added orders
Order is sent / Sales Order → “Product is received and set as ReadyForPickup” (VisionPoint) → Order status updated (ReadyForPickup, e-postmal)
Customer comes to shop: YES: vis ID og hentebekreftelse → “Set product as pickedUp and order av invoiced” → Order status updated (PickedUp) NO: 3 uker har gått → Delete order → Order status updated (NotCollected) → “Kredit product(s)”; Employee send product back → Ship product back to warehouse → Return products → Order status updated (Returned) Merk: Engage får ordren allerede ved “Sent”, ikke ved henting. Hentefrist 3 uker (Click & Reserve: 48 timer).

Ramme: Returns in store (3458764583224600764)

Legend: VisionPos, Omnium, Payment, Voyado Engage. Prosesstekst (oversatt/kortet): Kunden tar med vare og kvittering til en Gullfunn-butikk. Ansatt søker opp kvitteringen i Omnium med funksjonen HENT KVITTERING / ORDRE i VisionPos, velger salgslinjene som returneres og fjerner resten.

Opprinnelig HJEMLEVERING a. Mottakende butikk er en Gullfunn AS-butikk (franchisebutikk sender direkte til lager uten å gå via POS). Butikken legger signert papir i returen til lageret og gir kunden en bekreftelseslapp. i. Kunden vil bare ha pengene tilbake: årsak “Returner vare”, betalingsmåte NETTRETUR. ii. Kunden vil returnere og kjøpe noe nytt: håndter returen først (1.a.i), start så nytt salg. Kunden kan betale med Klarna i butikk hvis debetkort/kontanter ikke dekker.
Opprinnelig kjøpt i FYSISK BUTIKK i. Bare pengene tilbake: “Returner vare”, betalingsmåte etter original kvittering. ii. Bytte der ny pris ≤ returnert sum: “Returner vare”, betalingsmåte etter original kvittering. Differansen krediteres original betalingsmåte (eks. A 100 kr → B 80 kr, 20 kr tilbake). Er summen 0, velg kontant. Nytt kjøp opprettes som byttordre (exchange order) i Omnium. iii. Retur/bytte + nytt kjøp der ny pris > returnert sum: differansen tas med kort, kontant, Klarna (butikk) eller Vipps (butikk). Eks. A 100 kr, B 250 kr → 150 kr. Byttordre i Omnium. Regler: Alle Klarna-kjøp må returneres før nytt salg, med unntak av størrelsesbytte med samme beløp. Returneres en byttordre, krediteres hele beløpet til ny ordre eller ny betalingsmåte, selv om den arvet betaling; original betaling endres ikke.

Flytdiagram: Customer comes to shop → “Search for order or receipt number. Hit?”

NO → Manual process (sticky: retur ikke knyttet til ordre/kvittering)
Yes → Orderdata (Products, Customer) → Edit the order to only contain applicable lines → Select reason for return (sticky: IF Reason = Reclamation → lagerjustering) → Select payback method
- Physical (fysiske og BOPIS-ordre): Cash opptil 10 000 NOK, Credit card, Gift card Scenario 1.a.ii/iii: Original order status Returnert / Delvis returnert; Return order created and set to completed (Fullført); New POS order for up- and cross-sale (sticky: brukt beløp fra original ordre flyttes til ny ordre) → Engage: update orders, add returns. E-post/SMS-mal bcd74566-7481-43f1-8ec6-6df70cf175c8.
- Nettretur (Online order): Credit card, Vipps, Klarna, Electronic gift card. Sticky: betalingsløsningene tilbakebetaler automatisk via riktig metode for nettordre. Scenario 1.a.i: Original order status Returnert / Delvis returnert; return order created, Fullført → Engage: update orders, add returns. Samme mal. Begrep: BOPIS = buy online, pick up in store (Click & Reserve / Click & Collect).

Ramme: Returns from WEB BC (3458764622387086478)

Scenario: Kunden velger ordre og produkter som skal returneres på “Mine Sider”, og booker frakt via skjemaet Gullfunn tilbyr. Når lageret har mottatt og verifisert varene, krediteres pengene via betalingsmåten fra kjøpet. Legend: VisionPos, Omnium, Payment, Voyado Engage, Warehouse. Flyt: Customer create return from MyPages → Orderdata (products, customer) → Return order is created (Return Order Status: Ny; e-post/SMS-mal bcd74566-7481-43f1-8ec6-6df70cf175c8, bilde av e-post) Lager: pakken kommer i posten til “JFP Services” → The returned product has been received → (sticky: matching order and product) → Return is approved → Find order → Set return order status Complete (Fullført) → Engage: update orders, add returns Original order status: Returnert eller Delvis returnert (ordrehode), ordrelinjer merket “Returnert” (skjermbilder). Kreditering (NETTRETUR: kort, Vipps, Klarna, elektronisk gavekort): produkt(er) krediteres minus 59 NOK fraktgebyr. Returneres hele ordren, krediteres også opprinnelig frakt.

Ramme: Returns from manual form BC (3458764622387086479)

Scenario: Kunden fyller ut Angrerettskjema (https://cdn.sanity.io/files/l3008jy7/production/a970f9906a36cfd8aec887d1cbc08c5cdbd52446.pdf). Anbefalt å booke frakt via Bring-returskjemaet https://retur.bring.no/?q=GullfunnRetur med ordrenummer i referansefeltet. Kreditering etter verifisering på lager, via original betalingsmåte. Flyt: Customer create return from manual form → pakken kommer til JFP Services → The returned product has been received (matching order and product) → Return is approved → Find order (Omnium) → Mark products and select return → Set new return order to complete (Fullført) → Engage: update orders, add returns. Original order status Returnert / Delvis returnert. Samme kreditering: minus 59 NOK frakt, hele ordren → frakt krediteres. Forskjell fra web: returordren opprettes manuelt av lageret/kundeservice i Omnium etter mottak, ikke av kunden på forhånd. ÅPENT: “JFP Services” vs “JFS Services” i legend. Hvem er det (3PL for logistikk og økonomi)? Er dette samme aktør som “Warehouse” og NC/EWMS?

Ramme: Settlement between Gullfunn AS and franchise stores (3458764583224600765)

Legend: VisionPoint, VisionPos, Omnium, Payment. Utgangspunkt: kunden har levert en vare og signert returkvittering (i en annen butikk enn der kjøpet skjedde). Flyt: Add the original store the sale took place → Search for order or receipt number through VisionPos. Hit?

NO → Manual process in VisionPos (sticky: ingen måte å vite original salgspris)
Yes → Orderdata (products, customer) → Edit the order to only contain applicable lines → Use specific payment method for credit / collection → “Receiver is Gullfunn AS?”
- True → Invoice is sent faktura@jfpservices
- False → Invoice and product is sent to the original store where the sale took place (sticky: ordre for nettsalg sendes til Gullfunn Byporten) → Receiving store creates a sales order towards the sender Tolkning: Gullfunn AS eier egne butikker; franchisebutikker er egne selskaper. Returer på tvers utlignes med faktura mellom selskapene. JFP Services mottar fakturaer for Gullfunn AS (regnskapsfører/økonomitjeneste?). Nettsalg eies regnskapsmessig av Gullfunn Byporten. ÅPENT: stemmer det at Byporten er “nettbutikkens butikk”? Er JFP Services regnskap/økonomi og lager, eller to ting?

Ramme: Kommunikasjonsflyt Omnium (3458764669845428895): Byttegull / “Selg gull”

Legend: Sanity (CMS, rød), Omnium (OMS, svart). Rød boks = hendelse fra Sanity/kunde, svart = status i Omnium. Ikonene (stencils) er trolig e-postutsendinger. Start: “Ny Selg gull ordre” med etikett LeverIButikk (lever i butikk) eller SendtFraHjemme (sendt hjemmefra).

LeverIButikk → Bekrefte mottak (Sanity/kunde, e-post) → Under behandling (e-post) → Åpnet og editert av Gullsmed → Order Status: Fullført
SendtFraHjemme → Åpnet og editert av Gullsmed → Fullført Fullført: etikett selgerMedlem eller selgerIkkeMedlem (ulike e-poster) → Kunde angrer (Sanity) → Order Status: Angre (e-post) → Tilbakeføring mottatt → Order Status: Angre Fullført (e-post) Kobles til Byttegull-scope: angrerett, e-poster fra Omnium, ny ordretype.

Ramme: Byttegull: Ordrestatus og epostløp (3458764664316845617)

To spor: “Skjema - sende hjemmefra” og “Skjema - levere i butikk” (skjema i Sanity). Omnium-status med systemnavn i parentes. E-poster i midten. Sende hjemmefra:

Ordre opprettes → Status: Ny (new) → EPOST: Ordrebekreftelse til kunde
→ Status: Utbetalt, fullførtdato settes → EPOST: Betalingsbekreftelse
14 dagers vindu → Status: angre (cancelled) → EPOST: Tilbakebetalingsinfo → Status: angre fullført (returned) → EPOST: Bekrefte tilbakebetaling mottatt Levere i butikk:
Ordre opprettes → Status: Ny → EPOST: Ordrebekreftelse
Butikk bekrefter mottak → Status: Under behandling (inProgress) → EPOST: Bekrefte mottak
Gullsmed ferdigstiller ordren og økonomi gjennomfører betalingen → Status: Fullført, fullførtdato settes → EPOST: Betalingsbekreftelse
14 dagers vindu → angre (cancelled) → Tilbakebetalingsinfo → angre fullført (returned) → Bekrefte tilbakebetaling mottatt Merk inkonsistens: hjemmefra-sporet går rett til “Utbetalt”, butikksporet til “Fullført”. Kommunikasjonsflyt Omnium-rammen bruker Fullført for begge. ÅPENT: hvilken status er riktig i dag?

Status og beskrivelse på gullfunn.no (kundevendt):

Opprettet: “Vi venter på å motta gullet i [butikknavn]” / “Du vil motta en konvolutt som du sender tilbake til oss med gullet ditt”
Mottatt: “[butikknavn] har mottatt gullet og sender det videre til gullsmed for vurdering”
Vurdert: “Gullsmed har vurdert gullet og ordren overføres til BC. Beløpet blir utbetalt til din konto. Angrerett på 14 dager gjelder fra denne datoen”
Utbetalt: “Angreretten er utløpt” (etter “Angrerett utløper”)
Returneres / Returnert: Lorem ipsum (ikke skrevet ferdig) Opprettet kan gå rett til Vurdert (hjemmefra).

Ramme: Customer club user creation AS-IS (3458764567803893092)

Legend: VisionPoint, VisionPos, Omnium, Voyado Engage, Sanity. Online store: Sanity, skjema, Azure AD, Omnium. Store data system: VisionPoint, VisionPos. Engage i “Other third party vendors”. Option 1, direkte registrering på web: (1) Sanity → registreringsskjema “SMS or Vipps”: navn*, e-post*, telefon*, kjønn, fødselsdato*, samtykker (nyhetsbrev, SMS, annonser), medlemsvilkår. *forhåndsutfylt med Vipps. (2) Azure AD → Omnium: create user (3) Omnium → Engage: create customer Option 2, registrering fra POS: Butikkrutine: søk opp kunde på telefonnummer (reserverte numre: skriv inn navn manuelt), velg “ja” hvis kunden vil bli medlem. (1.1) Store → kunde: SMS med lenke https://www.gullfunn.no/sider/bli-medlem (1.2) Engage ↔ Store: create incomplete user (return coupons) (2) Kunden registrerer seg på Sanity-skjemaet → (3) Azure AD → Omnium: create user (4) POS-transaksjon registreres på telefonnummer og kunde med registreringsbutikk (profil ikke komplett) 5. Merging user data in Omnium (6) Omnium → Engage: update existing customer card Kunnskapsoverføringen: “Kundeopprettelse (Azure og …)” eies av Tormod/Torbjørn. Azure AD = trolig Azure AD B2C for kundeinnlogging.

Ramme: Customer club user creation TO-BE VIPPS / VOYADO (3458764674385232491)

Samme oppsett som AS-IS (skjema kun “SMS”, ikke Vipps), pluss VIPPS som tredjepart: (1) Store → Engage: create customer and start onboarding automation (2) Engage → Vipps: app push for å fylle inn kontaktinfo og samtykke (3) Vipps → Engage: sync data back (4) Engage: create contact Resten som AS-IS (1.1 SMS, 1.2 incomplete user, registrering, Azure AD, 4 POS-transaksjon, 5 merge, 6 update).

Ramme: VIPPS - VURDERT -> FORKASTET (rosa, hoppet over)

ÅPENT: Er TO-BE VIPPS/VOYADO fortsatt aktuell, eller er det den som ble forkastet (den rosa rammen ligger rett under)?

Ramme: Adapt (3458764674887942232): request-flyt for gullfunn.no

Request www.gullfunn.no → Fastly: “Cache?”

Yes → response fra Fastly
NO → Cloudflare Pages (Astro + Svelte; HTML, TypeScript, Tailwind) → Query for data → Cloudflare Workers (GraphQL) → Response → Pages → Fastly → bruker Merk: GraphQL-laget kjører på Cloudflare Workers.

Ramme: Cron-jobber Azure (3458764675040399496)

Innholdet er et bilde (ikke lesbart via Miro), men lesbart i PDF s. 53:

omniumCampaignsDelta: synker Omnium-kampanjer inn i Sanity
omniumCategories: synker Omnium-kategorier inn i Sanity (sletter ikke; enkelte unntak krever en manuell, tyngre synk kjørt av Adapt)
omniumGoldPriceSync: gullpris inn i Omnium
omniumProductsDelta: synker Omnium-produkter inn i Sanity
omniumStoresDelta: synker Omnium-butikker inn i Sanity
product-feed: lager produktfeed til Channable (blant annet Voyado Engage)
voyadoImport: synker produkter og innhold inn i Voyado Elevate Kjøretidspunkter står ikke. “Oss” i teksten = Adapt (rammen ligger ved siden av Adapt-rammen).

Ramme: Cron-jobber Omnium (3458764675044029389)

Ramme: Product creation and update BC (3458764622509362730): produktdataflyt (gjeldende)

Legend: som Detailed Overview + JFS Services (Logistics and finance), PowerBi. Aktører: Vendor, Gullfunn, Customer (Other external vendors), PIM manager (Bluestone), Category manager (VisionPoint/VisionPos), Customer, Solution Architect (PowerBi). Piler med frekvens:

BC → Bluestone: Product data, API (lenke “Attributes”)
BC → Bluestone: Image/Video (grønn = media)
BC → Logic: NC product update/creation
Sylvsmidja → Logic: Sylvsmidja product update/creation
Sylvsmidja → Bluestone: Product data, runs daily 09:00 (Attributes)
Sylvsmidja → Bluestone: Images (grønn)
Other external vendors → Logic
Logic → VisionPoint: Daily product changes (Attributes)
Logic → Bluestone: Image, runs daily 09:00 (grønn)
Excel import → Bluestone: Product data, manual import
VisionPoint → Bluestone: Product data, instant update (Attributes)
VisionPoint/VisionPos → Omnium (grønn): product prices synced every 5 min, product inventory every 15 min, transactions every 5 min (“See VisionPoint options”)
Bluestone → Omnium: Published products (“See Bluestone options”, Attributes)
Omnium → Elevate: products available for PLP, SERP and REC, runs every 15 min
Elevate → Sanity: presentation front-end
Omnium → Sanity: PDP and Carousel, instant update
Omnium → Engage: products every day 03:00 (Attributes)
Omnium → PowerBi: products and inventory every day 02:00
Omnium → Kindly
Omnium → Channable: daily 01:00 → Advertising (Pinterest, Google, Snapchat, Facebook, Instagram, TikTok ifølge PDF-ikoner) Tolkning: Bluestone (PIM) er stedet produkter berikes og publiseres. VisionPoint er fortsatt kilde for pris og lager. Elevate brukes til PLP (kategorisider), SERP (søk) og REC (anbefalinger); PDP og karuseller henter fra Omnium direkte. Avvik mot Cron-jobber Omnium: tavla sier inventory hvert 15. min og pris/transaksjoner hvert 5. min; cron-listen har VisionPointProduct hvert 5. min, VisionPosInventory hvert 15. min 09-21 og VisionPosSalesReceipt hvert minutt. VoyadoProductDataExport 03:00 samsvarer med “Omnium → Engage 03:00” (altså Engage, ikke Elevate). Mangler: attributtabellene (grids: Logic → VisionPoint, VisionPoint → Bluestone, BC → Bluestone, Sylvsmidja → Bluestone, Bluestone → Omnium, Omnium → Engage (order data), Bluestone Options, VisionPoint Options) kan ikke leses via Miro-koblingen og er uleselige i PDF-en.

Ramme: Diagrams: Ordreprosess (3458764659466013027): Byttegull (kunde selger gull til Gullfunn)

Legend: Sanity = CMS; Verified = brukerautentisering (BankID); Omnium = OMS; Azure = integrasjonsplattform; nShift = frakt; PowerBI = rapportering; BC = ERP; JFS = Økonomi; NC = produkthåndtering; gul kant = nye tekniske løsninger (Sanity-skjema med live gullpriser, Verified, nShift, PowerBI-synk). Viktig oppklaring: JFS/JFP = økonomifunksjonen (blå boks rundt BC merket “JFP”). NC = produkthåndtering, der gullsmeden sitter (oransje boks “NC” rundt Gullsmed og Konvolutt-sammensetning). Skjemafelt: navn*, e-post*, telefon*, adresse*, sendt fra butikk*, bankkonto*, bilde*, steiner, produktbeskrivelse*, vekt, karat. Priser (notat): bedriftspakke 159 NOK, brevadresse 38 NOK, Verified 8 NOK per stk, 2 000 NOK per år for API-er, gullpriser 2 565 USD per år. Politirapport (“Data Politiet”): selgers navn, adresse, nummer på tingene, dato for innlevering, mengde, vekt, verdi, kontroll av ID. Sendes hver 14. dag som passordbeskyttet Excel-fil for ordre over 25 000 NOK. Første gang ringer politiet for å opprette passord.

A. Direkte fra kunde (selger): forsikret konvolutt 300K

Kunden går til skjemaet på gullfunn.no (Sanity med live gullpriser og estimater), autentiseres med Verified
Ordre plasseres i Omnium 3.1 Omnium trigger e-postbekreftelse; 3.2 Omnium booker brev + bedriftspakke i nShift; 3.3 ordren synkes til PowerBI
NC (konvoluttsammensetning) sender konvolutt + skriv til kunden
Kunden sender produktet i mottatt konvolutt til gullsmed (NC) (Omnium → Politiet hver 14. dag)
[gullsmed oppdaterer tilbud, jf. B] 7.1 Omnium → Azure → BC: opprett ordre; 7.2 e-post til kunde; 7.3 synk PowerBI
BC (JFP) → kunde: betaling minus steingebyr
Alternativt: gullsmed returnerer steiner til kunden

B. Via butikkmedarbeider: forsikret konvolutt 100K

Kunden kommer i fysisk butikk; POS: vekt og estimat
Butikkmedarbeider går til skjemaet (Sanity + Verified)
Ordre plassert i Omnium; 4.2 synk PowerBI
Butikken signerer (POS → Omnium)
Butikken sender produktet til NC/gullsmed
Gullsmed oppdaterer tilbudet i Omnium (pris, vekt) 8.1 Azure → BC: opprett ordre; 8.3 synk PowerBI
BC (JFP) → kunde: betaling minus steingebyr
Alternativt: gullsmed returnerer steiner (til butikken)

C. Retur (angrerett)

Kunden avslår tilbudet (knapp i e-post eller på MinSide i Sanity) 2.1 Omnium → BC: e-post til økonomi; 2.2 → gullsmed: e-post om avslått tilbud; 2.3 → kunde: e-post med betalingsinfo; 2.4 og 6 synk PowerBI
Kunden tilbakebetaler + gebyr 179 NOK til BC/økonomi
Økonomi sender e-postbekreftelse til gullsmed 5.1 Gullsmed returnerer produktet når tilbakebetaling er mottatt; 5.2 gullsmed setter status “Angre fullført” i Omnium Kobling til andre rammer: Byttegull-status (Ny → Under behandling → Fullført/Utbetalt → angre → angre fullført), Kommunikasjonsflyt Omnium, Scope-side.

Ramme: XAL orders (3458764583243748496): ligger utenfor den rosa flaten, men gjelder XAL (ERP før BC)

Tre soner: Omnium | FTP (FTP-server, API og funksjon som synker XML-filer; gullfunnsftp.blob.core.windows.net, dvs. Azure Blob) | XAL.

Produkt: Når et XAL-produkt aktiveres i Omnium, kaller en webhook FTP-API-et som lager en “New Product XML”. XAL leser filen og merker produktene som aktive.
Lager: XAL lager en XML-fil for aktiverte produkter med beholdning. XML-API-et leser filen og oppdaterer lager i Omnium (/api/Inventory/AddMany; testpayload sku/warehouseCode/inventory). Lager heter “XAL Warehouse” i Omnium.
Ordre: Ny nettordre i Omnium → webhook → “New order XML File” → XAL oppretter ordren (New order → Processing order; frakt bookes ut fra fraktinfo fra Omnium → Completed order) → “Complete order XML File” med sporingsnummer → FTP-API oppdaterer ordren i Omnium til Completed og legger på sporingsnummer (/api/Orders/{orderId}/UpdateStatus). Omnium capturer betalingen og varsler kunden.
Retur: Returnert nettordre i Omnium → webhook → “Returned order XML File” → XAL oppdaterer ordren.
Lenker: Omnium API-dok https://api.omnium.no/documentation/index.html, Omnium-dok https://docs.omnium.no/, test-API https://apitest.omnium.no SIKKERHET: Rammen har test-ClientId og test-Secret for Omnium i klartekst (klient-ID med prefiks “noa-”). Ikke kopiert hit. Bør fjernes fra tavla og nøkkelen roteres. Tolkning: Prefikset “noa-” tyder på at NoA er integrasjonspartneren som har satt opp Omnium-klientene. ÅPENT: Er XAL-ordreflyten helt avviklet (erstattet av BC-flyten)? Brukes Azure Blob-“FTP”-mønsteret fortsatt mot BC?

Ramme: Docs (3458764655982162850): doc “Produkter” (testoppsett og produktattributter)

NC = NC CHRISTOPHERSEN AS (BC-lenken peker på company=NC CHRISTOPHERSEN AS i Business Central, tenant 37d8000a-…). BS = Bluestone. NB: Alle testprodukter i BS/Omnium må også finnes i test-BC. Bluestone:

Produkttyper: Single, Variant, Group.
Attributter som påvirker front-end (med testprodukter på test.gullfunn.no): Angrerett gjelder ikke; Angrerett-tekst; Bokstav (valg på PDP); Bunadsdistrikt (egen kategorisering); Diamond options (valg på PDP); Gravering modus (Avansert / Enkel); Kan ikke selges på egenhånd (f.eks. Barnekreftforeningen i utsjekk); Nettlager styres i Omnium; PDP disclaimer; standardLocation; Varianter styres i Omnium; Video URL; Custom str S/M/L/XL; Relaterte grupper; legge til klokker; rette opp kategorisering for enklere kampanjeregler.
Relasjoner som påvirker front-end: Gaveinnpakning; Tilbehør; Breddegruppe (MANGLER); Karatgruppe. Omnium:
Kampanjetyper: kategori-/merkerabatt, flerkjøp / Mix & Match, ordretotalrabatt. Custom labels i Sanity: Editorial, Campaign.
Kategorier brukt til ordreallokering: produkter som ikke kan reserveres i butikk; produkter som ikke kan sendes fra butikk. Upsale i handlevognen.
Produktinnstillinger: Aktivert, Er virtuell.
Må samsvare med produktregisteret i BC. Testmiljøer: demovpoint.gullfunn.no (VisionPoint), app.test.bluestonepim.com, test.omnium.no, test.gullfunn.no. Arkivering (stikkord): fjerne hake i VisionPoint på “eksportvare” → merkes i BS → går over til arkivert → synkroniserer → går over til draft → borte fra Omnium? (uavklart)

Ramme: Docs (3458764644934031414): Byttegull, TOGAF-lignende arkitekturarbeid

Doc: Nye kostnader, Angrerett og KPI

Faste kostnader: live gullpriser fra KA Rasmussen (https://karasmussen.com/metallpriser/), som henter fra London Metal Exchange daglig (XML next-day feed), 2 565 USD/år. Verified: API ca. 2 000 NOK/måned (ordreprosess-rammen sier 2 000 NOK/år, avvik!), ca. 8 NOK per signering. Angrerett: kunden kan avslå tilbudet innen 14 dager fra beløpet er mottatt (håndteres i UX på gullfunn.no). Produktet kan ikke smeltes før Økonomi har bekreftet at refusjon er mottatt. Ordre med status returnert/angret må følges opp hvis beløpet aldri krediteres. KPI-er: gjennomsnittlig behandlingstid (ordre opprettet → penger overført); antall angretilfeller (% av ordre); gjennomsnittlig avvik i avstemming (estimat NOK vs reell utbetaling NOK).

Doc: Target Business Architecture

Kapabiliteter: innsending og KYC (CMS-registrering + BankID via Verified); innkjøp fra privat som ny ordrekategori i OMS (type Byttegull); ekspertvurdering av gullsmed (vekt, karat, tilstand, pris i OMS); angrerett 14 dager med betalingsreversal og fysisk retur; automatisk utbetaling fra ERP når ordren er “Godkjent”; materialhåndtering (smelting, gull som råvare, batch/sporbarhet); veiledning i butikk. Målprosess: kunde (direkte eller via butikk) velger Byttegull → personalia + bankkonto → BankID → OMS “Verifisert” → smykke mottas → “Under vurdering” → gullsmed setter pris, 14-dagers angrerett starter → kunden varsles → passiv aksept etter 14 dager → ERP utbetaler, status “Utbetalt” → smelting, registrert som råvare/batch i ERP. Ved angring: ERP krever tilbakebetaling, fysisk retur, OMS “Angret”. Rapportering: KYC, utbetalinger, angrestatistikk. Informasjonsobjekter: Byttegull-ordre (KYC-status, prisvurdering, angrerett start/slutt, utbetalingsstatus); KYC/BankID (Verified transaksjons-ID, tid, identitetsnivå); bankkonto (kryptert, tilgangsstyrt); vurderingsdata (vekt, renhet, bilder, notater); materiale (batch-ID, vekt, renhet etter smelting, lokasjon); angrerett (frist, status, reverseringstransaksjon); utbetaling (beløp, dato, referanse, status). Roller: kunde, gullsmed, kundeservice, finans/regnskap, compliance/personvern, IT/integrasjonsansvarlig (Verified ↔ CMS/OMS, OMS ↔ ERP, datamodell). Policy: BankID obligatorisk før Byttegull-ordre (KYC/AML); dataminimering og kryptering av bankinfo; 4-øyne-godkjenning av utbetalinger over terskel; avstemming mot bank; full chain-of-custody. Merk avvik: målbildet sier passiv aksept og utbetaling etter 14 dager, mens statusflyten og kundetekstene sier at beløpet utbetales ved “Vurdert” og at angreretten løper fra da. ÅPENT: hvilken rekkefølge gjelder i dag?

Doc: Gap Analysis Report

Prosessgap: ny innkjøpsprosess (workflow, statuser, SLA, varsling); KYC/BankID mangler (blokkerende steg); angrerett for innkjøp med reversal; smelting/batching. Kapabilitetsgap: B2C-utbetaling fra ERP (bankintegrasjon); ny ordrekategori i OMS; KYC og bankkonto i CMS; compliance/AML for edelmetaller. Informasjonsgap: datamodell, sikker lagring av bankkonto (vault), batch-/materialdata i ERP. Teknologigap: Verified-integrasjon (API, callback, token); OMS-ERP-utvidelser (ordretype, statuskart, hendelsesbuss, triggere for utbetaling); Byttegull-modul i CMS. Organisasjon: opplæring av gullsmed, kundeservice, finans, butikk. Risikoer (sannsynlighet/konsekvens 1-5): R1 personvern bankdata 2/5; R2 angrerett kompleks tilbakeføring 4/4; R3 dupliserte hendelser/utbetalinger 2/5 (idempotens, logger, alarmer); R4 smelting før angrefrist 1/4 (sperre til dag 15); R5 ufullstendige ordredata 3/3; R6 feil utbetaling ved mismatch BankID-navn og kontoeier 2/4 (automatisk blokkering); R7 kapasitet hos gullsmed 2/3; R8 dårlig veiledning i butikk 3/4.

Doc: Prinsipper

API-first over punkt-til-punkt; security & privacy by design; automatiser der det gir verdi (utbetaling, logistikk, e-post); OMS er SSOT for ordre og kundestatus; Reuse > Buy > Build; hendelsesdrevet statusoppdatering; observability som grunnlag for drift.

Doc: SCOPE (tom tittel; innholdet er bildet fra PDF s. 9)

Ramme: Catalogs (3458764653861316205): Byttegull

Ramme: Matrix (3458764653865821968)

Stakeholder-Concern Matrix (Security / GDPR / Ease of use / Transparency / Cost control): Kunde H/H/H/M/L; Gullsmed M/M/M/H/L; Kundeservice M/H/H/H/L; IT-integrasjon H/H/L/M/M; ERP-team H/H/L/M/H; Compliance H/H/L/M/L; Produktansvarlig M/H/M/M/H; Butikkmedarbeider M/M/H/M/L. RACI - oppgaver (Arkitekt / Tech Lead / ERP-spesialist / CMS-OMS-utvikler / Gullsmed / Juridisk-personvern / BI-analytiker / Drift / Styringsgruppe):

OMS-ordretype: R/A/C/R/C/C/I/I/A
CMS-skjema: C/R/I/R/I/A/I/I/A
ERP-utbetaling/angrerett: C/C/R/I/I/A/I/I/A
Integrasjoner: R/A/C/R/I/C/I/I/A
BI/KPI: C/C/I/I/I/I/R/I/A
Sikkerhet/logging: R/A/C/C/I/R/I/I/A
Opplæring: C/C/I/I/R/C/I/R/A (Flere A per rad: RACI-en er ikke konsistent.) RACI - PRELIMINARY: kolonner Leder digital handel, Løsningsarkitekt, Gullfunn CEO, JFP CEO, NC CEO, NC Gullsmed, NoA, Knowit (ERP), Finance. Nøkkelfunn om aktører: JFP har egen CEO (eget selskap, logistikk og økonomi). NC har egen CEO og gullsmed (NC Christophersen AS). NoA = partner (integrasjon/Omnium). Knowit = ERP-partner (BC). Aktiviteter (R = Løsningsarkitekt på alle): bekrefte mandat (A Leder digital handel); scope og rammer; interessenter og styringsmodell; arkitekturprinsipper (A Gullfunn CEO); prosess og kapabiliteter; data- og applikasjonskart; foreløpig integrasjonsstrategi (C NoA, Knowit, Finance); sikkerhet og personvern (DPIA-light, logging, Key Vault); kostmodeller Verified/nShift/LME (A Finance); business case; 4 mnd leveranseplan; forankring av partnerroller; risiko og avhengigheter.

Ramme: PRELIMINARY - Rammer (3458764659866890844)

Doc (doc_format, ikke lesbart via koblingen) + samme Stakeholder-Concern Matrix og RACI - PRELIMINARY som over.

Byttegull-arkitekturen følger TOGAF ADM: Preliminary, A, B, C, (D mangler), E, F, G, H.

Ramme: Fase A - Sette retning (3458764659867878233)

Visjonsnotat (Byttegull, Gullfunn AS med NC, JFP Services, NoA, Knowit, Verified, nShift; februar 2026, v1.0, utarbeidet av løsningsarkitekt)

Visjon: Norges mest brukervennlige, trygge og transparente tjeneste for innlevering og verdiomvandling av gull, i butikk og hjemmefra. Løfte modenhet fra “Under utvikling” til “Definert/Styrt”. Kjerneverdier: tillit, sikkerhet, transparens, effektivitet. Mål: én kundereise med ett skjema, én ID-kontroll med BankID og helautomatisk flyt Sanity → Omnium → BC → nShift → varsling/e-post. Politirapportering over 25 000 NOK. MVP innen 4 måneder med 1 FTE utviklingskapasitet fra NoA (fordelt). KPI-forslag: behandlingstid (dager), andel vellykkede automatiske utbetalinger, angretilfeller (% av ordre), andel hjemmefra vs butikk, fortjeneste.

Høynivåkrav (18 stk)

Forretning: 1 sømløs innlevering (butikk og post); 2 trygg ID-kontroll; 3 full transparens; 4 minimere manuelle steg; 5 lovpålagt politirapportering > 25 000 NOK. Funksjonelt: 6 digitalt skjema (PII, kontakt, bankkonto, kanal, butikkvalg, steiner); 7 automatisk ordreopprettelse; 8 automatisk frakt begge veier; 9 gullsmed registrerer prisvurdering som trigger utbetaling; 10 automatisk utbetaling. Sikkerhet/kvalitet: 11 GDPR, dataminimering; 12 sporbarhet og logging; 13 høy tilgjengelighet i åpningstid; 14 robust mot feil i BankID, frakt, økonomi (feilmeldinger, fallback). Drift: 15 enkle rutiner i butikk og hos gullsmed (utskrift, etiketter, oppslag, status); 16 angrerettprosess. Fremtid: 17 utvidbar til sølv, klokker; 18 gjenbrukbare integrasjonsmønstre CMS/OMS/ERP/BankID/logistikk.

Scope (samme som PDF s. 9) og Risikoer R1-R8 (samme som Gap Analysis)

Ramme: Fase B - Forretningsprosesser (3458764659869845155)

Legend: Omnium (OMS), Azure (integrasjonsplattform), nShift (frakt), JFS (økonomi), BC (ERP), NC (produkthåndtering), forsikret konvolutt 300K. Grupper: Gullfunn (Omnium, Azure, nShift, [Sanity, Butikk]), JFP Services (BC, PrintNode routing), NC (Gullsmed, Konvolutt-sammensetning), Kunde, Politiet. Direktesending: (1) Kunden legger en ordre → Omnium (2) Omnium booker frakt i nShift (3) nShift sender fraktetiketter → PrintNode routing (hos JFP) → konvoluttsammensetning (NC) (4) NC sender konvolutter til kunden (5) Kunden sender produkt(er) til gullsmed (7) Azure sender ordren til BC (8) Omnium sender info om utbetalinger til Politiet (9) Gullsmed returnerer stein(er) til kunden Angring (rødt): (9) kunden angrer → Omnium; (10) tilbakebetaling → BC; (11) BC bekrefter tilbakebetaling → gullsmed; (12.1) gullsmed oppdaterer ordrestatus; (12.2) gullsmed returnerer produktet Sending fra butikk: (1) Kunden legger en ordre / (2) leverer produkt(er) i butikk; (3) butikken henter opp ordren (Sanity); (4) Sanity/Omnium bekrefter mottak og brukerverifisering; (5) butikken sender produkt(er) til gullsmed; (7) Azure → BC; (8) info til Politiet; (9) returnere steiner; angring som over. Nytt funn: PrintNode (utskriftsruting) brukes for fraktetiketter hos JFP. GAP-liste (AS-IS → TO-BE → gap → effekt):

nShift i Omnium → automatisk booking → konfigurere automatisk booking av brevadresse + bedriftspakke per byttegullordre → mindre manuelt arbeid og færre feil
Ingen konvoluttsammensetning → dedikert ressurs som setter sammen og sender konvolutter → kunden får forsikret konvolutt med adresse
Gullsmed vurderer for butikk → også for sluttkunde → må ta imot sendinger direkte → høyere volum
Gullsmed vurderer direkte → pris i ordreinformasjonen → brukervennlig UI i OMS → ordre sendes til ERP for utbetaling
Kun hjemleveringsordre → ny ordreprosessering for byttegull → integrasjonen må ta imot ny ordretype → automatisk til ERP
Ingen eksport av ordredata → ordreeksport → OMS-ordreeksport som politirapport
Ingen returprosess for byttegull → registrere anger → enkel innmelding for kunden

Ramme: Fase C - Applikasjon og dataprosesser (3458764659893356919): Byttegull, systemnivå

Direktesending: (1) Sanity (live gullpriser og skjema) ↔ Verified: verifisere bruker (2) Sanity → Omnium: plassere ordre (3) og (7) Omnium → PowerBI: synkroniserer ordredata (4) Omnium → nShift: booker frakt (5) nShift → PrintNode routing (JFP): sender etiketter (6) Azure → BC (JFP): sender ordre (8) Omnium → Politiet: sender rapport Sending fra butikk: (1) Sanity ↔ Verified; (2) Sanity → Omnium: plassere ordre; (3) og (8) Omnium → PowerBI; (4) butikken søker opp ordren (Sanity); (5) Omnium → Sanity: henter ordredata; (6) Sanity → Omnium: signerer mottak; (7) Azure → BC; (9) Omnium → Politiet Data Entity Catalog som i Catalogs, men Smykke har attributtene type, vekt, karat. Merk: butikksporet bruker Sanity (ikke VisionPos) som grensesnitt for butikkmedarbeideren. Ordreprosess-rammen nevner “POS: vekt og estimat”, og scope sier ingen endringer i POS.

Ramme: Fase E - Muligheter og løsninger (3458764659898985866)

Work packages, 4 mnd MVP: WP1 skjema + Verified BankID + Sanity-modellering; WP2 OMS-orkestrering (ordre/status/e-post); WP3 nShift-integrasjoner + etiketter + retry; WP4 ERP/BC-utbetaling + bekreftelsesløp; WP5 politirapport (Excel + passord) + prosedyre; WP6 angrerett (MinSide + e-post); WP7 LME XML-feed ingest + validering + cache; WP8 observability og sikkerhet. Transition: mnd 1 WP1+WP7; mnd 2 WP2+WP6; mnd 3 WP3+WP4+WP8; mnd 4 WP5 + E2E-test + go-live readiness. Løsningskomponenter (område / komponent / type / valg):

Kundeopplevelse: web-skjema + Verified / Config / Sanity
Saksbehandling: admin-UI for gullsmed / Config / Omnium
Meldinger: e-post og maler / Config / Omnium
Integrasjoner: ERP-integrasjon (ordre/faktura) / Config / API via APIM
Lagring: dokument- og bildeopplasting / Config / Omnium eller Azure Blob Storage (ev. virusskann)
Data: transaksjons- og forespørselsdata / Config / Omnium
Sikkerhet: identitet og roller / Buy-Config / Entra ID (RBAC internt, BankID eksternt)
Observability: logging/monitorering / Buy-Config / App Insights, Azure Monitor
Integrasjonsstyring: API-gateway / Buy-Config / Azure API Management Gevinster: G1 raskere saksbehandling (tid per sak, etter mnd 3); G2 mindre manuelt arbeid (etter WP4); G3 færre feil (etter WP3-4); G4 sporbarhet/compliance (etter WP8); G5 kundeopplevelse (NPS/CSAT, etter WP1-3). Påvirkning: prosess (ny prosessbeskrivelse, opplæring); personell (nytt admin-UI, hurtigguide); system (miljøer, testdata); data (validering, GDPR); sikkerhet (RBAC); drift (dashboards, varsling, hypercare); kunde (e-postløp, opt-in/opt-out).

Ramme: Fase F - Migreringsplan (3458764659902840944)

Roadmap med leveransemål per måned: M1: skjema, BankID, Sanity-innholdsmodell, LME-prisfeed med cache. M2: full OMS-flyt med status og e-post, angrerettløp, MinSide-visning. M3: nShift med etiketter og retry, automatisert BC-utbetaling, bekreftelses-e-poster, observability-dashboard og alarmer, sikkerhetsmodell (RBAC, logging, API-nøkler). M4: politirapport (Excel + passord) og prosedyre, full E2E (skjema → BankID → OMS → ERP → nShift → angrerett → rapportering), go-live-kontrollpunkter, hypercare. Avhengigheter: WP2 krever WP1; WP3, WP4 og WP6 krever WP2; WP8 og WP5 krever WP1-4; E2E krever WP1-7; go-live krever grønn E2E. Et bilde (trolig tidslinje/Gantt, jf. PDF s. 42) ikke lest.

Ramme: Fase G - Governance (3458764659902841894)

Sjekkliste for arkitekturcompliance: 1 prinsipper og retning; 2 scope og krav (sporbarhet plan → design → implementasjon); 3 prosess (TO-BE, brukerreise); 4 applikasjon og integrasjoner (API-standarder, system of record, ingen skyggeintegrasjoner); 5 data (dataminimering, masterdata-eierskap); 6 teknologi, sikkerhet og drift (godkjent plattform Azure/ERP/API-gateway, RBAC, least privilege, TLS, secrets, private endpoints, alarmer, GDPR); 7 kvalitet (testdekning, retry, ytelse); 8 dokumentasjon og driftsoverlevering (runbook, go-live-sjekkliste, signert overlevering). Endringslogg (beslutninger underveis):

Butikk skal kunne editere en ordre ved innlevering: hente opp, justere detaljer for gullsmed, lukke og bekrefte mottak, sende videre.
Bankkontonummer krypteres og lagres i Omnium (alternativet var egen lagring i Azure).
“Byttegull” heter “Selg gull” ut mot kunden og ligger i footeren.
Butikk må registrere ansattnummer ved mottak.
Nytt angregebyr lagt inn som produkt i Omnium, legges til i arbeidsflytsteget.
Nytt gebyr på 179 NOK for innsendinger med under 5 gram gull. (Ordreprosess-rammen kaller 179 NOK et angregebyr. ÅPENT: hvilket gjelder, eller begge?)
Levering i butikk er stengt ved oppstart på grunn av manglende opplæring; åpnes én måned etter lansering.

Ramme: Fase H - Endringer (3458764659903072547)

Tomme dokumenter: Backlogg, Risiko, Eierskap for videre forvaltning.

Ramme: Fase B - Forretningsprosesser (alt2 diagram) (3458764660196019302): sekvensdiagram

Pilene er ikke tilgjengelige via Miro-koblingen; lest fra PDF s. 45 i lav oppløsning. Nummer og tekst er delvis usikre (markert ?). Lifelines direktesending: Kunde | Gullfunn (Sanity, Omnium, Azure, nShift) | JFP Services (BC, PrintNode routing) | NC (Gullsmed, Konvolutt-sammensetning) | Politiet. (1) Kunde → Sanity: legger ordre; (2) Sanity → Omnium: oppretter ordre; (3) Omnium → nShift: booker frakt; (4) nShift → PrintNode: sender fraktetiketter; (5) PrintNode → konvoluttsammensetning: sender fraktetiketter; (6) konvoluttsammensetning → kunde: sender konvolutt; (6?) kunde → gullsmed: sender produkt(er); (7) gullsmed → Omnium: oppdaterer prisforslag; (8) Omnium → Azure: ordredata; (9) Azure → BC: ordredata sendes; (10) Omnium → kunde: bekrefter utbetaling; (11) gullsmed → kunde: returnerer steiner. Angring (rødt, mellom grønne streker): (12) kunde → Omnium: angrer; (13) kunde → BC: tilbakebetaling; (14) BC → gullsmed: bekrefter tilbakebetaling; (14.1) gullsmed → Omnium: oppdaterer status; (14.2) gullsmed → kunde: returnerer produkt. Etter: (15) Omnium ← gullsmed?: “henter ordre fra siste 14 dager”; (16) → Politiet: sender rapport (hver 14. dag). Sending fra butikk: (1) legger ordre; (2) oppretter ordre; (3) kunde leverer produkt(er) i butikk; (4) butikk → Sanity: signerer mottak; (5) butikk → gullsmed: sender produkt(er); (6) oppdaterer prisforslag; (7)-(8) ordredata via Azure til BC; (9) bekrefter utbetaling; (10) returnerer steiner; angring (11)-(14.2); (15) henter ordre siste 14 dager; (16) rapport til Politiet. Butikksporet har ingen nShift/PrintNode.

Ramme: Fase C - Applikasjon og dataprosesser (alt2 diagram) (3458764660196019674): systemsekvens (PDF s. 46)

Lifelines: Sanity, Verified, Omnium, Azure, nShift, PowerBI | JFP: PrintNode routing, BC. Direktesending: (1) Sanity → Verified: verifisere bruker; (2) Sanity → Omnium: oppretter ordre; (3) Omnium → nShift: booker frakt; (4) nShift → PrintNode: sender etiketter; (5) Omnium → Azure: sender ordredata; (6) Azure → BC: mapper felter og oppretter ordre; (7) Omnium → PowerBI: synkroniserer ordredata; (8) BC → Omnium: oppdaterer status ved angring. Butikk: (1) verifisere bruker; (2) oppretter ordre; (3) butikk henter opp ordren i Sanity; (4) Sanity → Omnium: signerer mottak; (5) Omnium → Azure; (6) Azure → BC: mapper felter og oppretter ordre; (7) synk PowerBI; (8) BC → Omnium: status ved angring. Poeng: Azure-integrasjonen gjør feltmapping Omnium → BC. Angrestatus går tilbake fra BC til Omnium.

Ramme: ShipFromStore med Porterbuddy (3458764677030027035): konsept/krav

Krav:

Fraktbegrensning på kundens leveringsadresse via integrasjon mellom Porterbuddy og nShift.
Fraktbegrensning på produkt basert på beholdning i butikk med shipfromstore-rolle: a) innenfor Porterbuddys dekningsområde, b) Porterbuddy kan plukke fra butikken.
Allokering etter fraktvalg: butikk trumfer lager hvis kunden velger Porterbuddy. Regel: kundens leveringsadresse OK + shipfromstore-adresse OK + shipfromstore-plukk OK = Porterbuddy vises i utsjekk. Eksempel: Produkt 1 og 2 (1 stk Byporten, 1 stk lager) og Produkt 3 (1 stk Alta, 0 lager).

Handlevogn 1 (produkt 1+2): Ja, Porterbuddy med shipfromstore trumfer allokering til lager.
Handlevogn 2 (produkt 1+2+3): Nei, Alta er utenfor dekningsområdet og har ingen Porterbuddy-plukk. Merk: ship from store er ikke aktivt i dag (jf. home delivery-rammene). ÅPENT: status på Porterbuddy-initiativet?

Ramme: Brudekjoler - En gang til (3458764677030027815): kommisjonssalg av brukte brudekjoler

Notater (utkast):

Skjema fra Gjenbruk, integrert mot Zendesk.
Forespørselen behandles. Godkjennes den, sendes selger til gebyrproduktet på gullfunn.no. nShift hoppes over ved at produktet er markert som digitalt i checkout (ny produktattributt “digitalt”).
Etter betaling har vi selgerinfo (å opprette selger som leverandør var tungvint; alternativ: kunde med negativ post / leverandørkost).
Åpent i notatet: sender selger oss kjolen? Hvordan skille kjolene med de to konseptene? Enkleste måte å skjule produktet fra Elevate?
Nytt felt i VisionPoint for kunde-ID/telefonnummer til selger, så vi vet hvem som skal ha oppgjøret.
Enkel PowerBI-rapport for salget. Ved salg krediteres selger, og varen lagerjusteres. Prosess (steg med skjermbilder):

Banner/hero på https://www.gullfunn.no/kategorier/bryllup-og-forlovelse/brudekjoler---en-gang-til
Registreringsskjema på https://www.gullfunn.no/sider/selg-din-brudekjole-via-oss
Egen visning i Zendesk gruppert på type “bryllupskjole”.
Når kjolen er godkjent: oppgi adresse og be selger betale gebyr via produktsiden https://www.gullfunn.no/produkter/63442/gebyregts (gebyrEGTS). Gebyret må ha attributtet “Digital produkt” = true i Bluestone for å slippe frakt i utsjekk.
Opprett produktet for kjolen. Legg selgerens telefonnummer i attributtet “KundeID EGT” (fra skjema eller gebyrbetaling). Kostpris 0 NOK.
Følg salget i PowerBI.
Når kjolen er solgt: opprett kreditt mot selger for salgssummen og lagerjuster så varen ikke er tilgjengelig. Kobling: gebyrBrudekjole-taggen og egen e-postmal i home delivery-flyten. EGT = “En gang til”.

Ramme: Salg og returer (3458764677250935261): KPI-definisjoner for butikkrapport (PowerBI)

Tema: hvordan returer og bytter påvirker KPI-er i VisionPoint vs Omnium/PowerBI. Eksempel: én dag hos Byporten. Del 1, VisionPoint vs Omnium/PowerBI (scenario per rad, kunde → POS):

Ett kjøp 200 kr: begge viser 1 salg, AOV 200, omsetning 200.
Kjøp 200 + retur -200 (retur av ordre fra annen dato): VisionPoint teller 2 salg, AOV 0, omsetning 0. Omnium teller 1 salg (retur registreres som status “returnert” på originalordren med annen dato), AOV 200, omsetning 200.
Med byttordre (exchange order laget av nye varer; returen i transaksjon 3 utligner ordre fra annen dato): VisionPoint 3 salg, AOV -66,66, omsetning -200. Omnium 2 salg, AOV 200, omsetning 400.
Flere retur-scenarier: VisionPoint går negativt (-400, -800), Omnium viser oppdatert originaltransaksjon = 0 og 200 kr omsetning. Noen transaksjoner “kommer ikke med i tallene”.
NB: PowerBI kan filtrere på ordrestatus (Fullført, Sendt osv.).
Gavekort påvirker ikke omsetningen i VisionPoint; derfor blir en transaksjon -400 og ikke 0. Del 2, “KPIer for én dag hos Byporten” (VisionPoint sales-tall):
Nye målepunkter: brutto omsetning, netto omsetning, returer i kroner, retur i vare, gavekort, varer per salgskunde.
Fire definisjoner vurdert: Netto AOV (etter returer, “økonomisk realitet”); Bytte-justert netto AOV (anbefalt ved fysisk bytte); netto (rå) varer per salgskunde; bytte-justert varer per salgskunde. Eksempel: (200-200-400-300)/(1+1+0+0) = -350 netto AOV; bytte-justert (400-200-700)/2 = -250.
Nevneren teller kun salgskunder (rene returer teller 0). “Per kunde betjent (alle 4, inkl. rene returer)” gjelder også medlemsandel.
Skjermbilder fra VisionPoint 24.10.25 og en skisse av dashboardet: Brutto 400 kr, 2 salg, transaksjoner, Klikk&Reserver avvist %, returer i kroner -500, retur i vare -200, gavekort 400.
Krav i gule lapper: NETTRETUR må ekskluderes fra hele rapporten (gjelder kun egeneide butikker). Klikk&Hent “Utlevering i butikk” må ekskluderes ved å utelate nettbutikkens betalingsmetoder. Forslag: skjule de nederste KPI-ene bak klikk/hover.

Rammer: 26.01.26 (3458764677250935419) og 27.01.26 (3458764677250935469): testing av PowerBI-butikkdashboard

26.01.26: testtransaksjoner hos Byporten i VisionPoint (1000, -1 199 900 (!), 32 990 ×3, 20 kr) med skjermbilder av dashboardet. Korrigert regnestykke ved siden av: 1000 / -119 990 / 3299 ×3 / 200 (gavekort) → 4 salg, AOV (1000+3299+3299+3299)/4 = 2 724,25, omsetning 10 897, varer per kunde 1, gavekort 200. Endringsnotat for dashboardet (engelsk, trolig fra leverandør):

Tidsintervall (fra/til-dato) via “Salgsoversikt”.
Ny KPI “Negative Sales (excl. NETTRETUR)”.
Ny KPI “Gift Cards Sold” (kun dagens gavekortsalg).
“Revenue incl. VAT” ekskluderer alle returlinjer.
Transaksjoner med betalingstype NETTRETUR ekskluderes fra alle KPI-er.
Totaler konsistente med ny logikk. 27.01.26: scenarier med medlem / ikke medlem (2299, 1000, 200, -2299, -3249) og tilhørende dashboard-skjermbilder. Brukes til å verifisere medlemsandel og AOV.

Ramme: Datamodel PowerBi (3458764645995480379)

Kun et skjermbilde av PowerBI-datamodellen (tabeller som Stores, PriceList, Order, OrderLine osv. ifølge PDF s. 32). Uleselig i PDF og ikke nedlastbart. ÅPENT.

Løst område “NoA - Arkitektur” (x 32902..45014, y -11348..-7098): NoAs opprinnelige løsningsarkitektur (engelsk, XAL-æra)

Bekrefter: NoA er implementasjonspartneren som designet og bygget gullfunn.no-plattformen. (Test-klient-ID og test-secret for Omnium står også her i klartekst. Ikke kopiert.)

Voyado Engage and Elevate integration

Ordre i nettbutikk synkes til VisionPoint, og ordre i VisionPoint synkes til Omnium. Omnium får dermed alle ordre.
Alle ordre fra Omnium synkes til Voyado (register purchase); alle returer synkes (register return).
Registrert kunde i Omnium → kontakt i Voyado. Kontakt opprettet i Voyado → synkes til Omnium med discoveryKey som externalId.
Kuponger laget i Voyado → Omnium (uavklart om Omnium støtter det).
Eksisterende POS-integrasjon mot Voyado (må verifiseres).
Kunde registrert i POS får registrerings-SMS med lenke til skjema i frontend; innsending lager kontakt i Voyado.
Samtykker håndteres på Min side og synkes til Voyado.
Ordrehistorikk (nett, Click & Collect, Click & Reserve, butikk) hentes fra Omnium via Retailor API (uavklart om Omnium har butikkjøp).
Retailor API lager produktfeed til Engage og produkt-, ordre- og innholdsfeed til Elevate (innhold fra Sanity). Merk: “Retailor API” er trolig NoAs lag (GraphQL på Cloudflare Workers).

Cart, Checkout and Orders

Storefront: produkt → handlevogn (rabattkode eller kupong) → valg Click & Reserve eller nettordre. C&R: velg butikk med varen på lager. Nettordre → Klarna Checkout: mottaker (annen adresse for gave), fraktmetode via nShift (hjemlevering, hentested, hente i butikk; fraktmetode kun for nettordre; ordre over 1 500 kr skal ikke tillates for hjemlevering, “to be specified”), betalingsmetode (Klarna-alternativer, Vipps, iGive; “kan Omnium støtte iGive?”). Omnium ordretyper: Click & Reserve = ClickAndCollect; Click & Collect = Bopis; nettordre = Online. Nettordre/Bopis-flyt: New → Processing → kunde varslet → alloker til XAL (hvis på lager, ellers første butikk med varen) → send til XAL → motta ferdig ordre fra XAL → capture i Klarna/Vipps → kunde varslet med sporingsnummer → oppdater lager → synk ordre (VisionPoint, “trolig ikke for XAL-ordre”; Voyado) → kunde varslet → fullført. Butikkgren: alloker til butikk → nShift booker → Bring/DHL → capture. C&R-flyt: New → Processing → varslet → alloker til butikk → synk til VisionPoint → hentet og betalt → synk til Omnium → oppdater lager → synk til Voyado → varslet → fullført. Lagerrisiko: lager synkes fra VisionPoint hvert 5. minutt. Kjøper noen samme vare i butikk samtidig, kan nettordren måtte kanselleres. C&R/hent i butikk kanselleres; vanlig nettordre kanselleres av butikken og Omnium prøver å allokere til en annen butikk.

Order Return

Nett: kunden logger inn på Min side, velger ordre (hel ordre eller enkeltlinjer; gifteringer og graverte produkter kan ikke returneres). Frakt bookes med myBring (mottakerbestilt retur), fraktkost trekkes fra refusjonen. Storefront registrerer retur i Omnium med riktig beløp. XAL varsles og melder tilbake når returen er ferdig; uten XAL håndteres returen i Omnium. Omnium refunderer via riktig betalingsleverandør (Klarna/Vipps). Butikk: VisionPoint henter ordren fra Omnium; finnes den, trigges returflyten i Omnium; VisionPoint oppdaterer lager i Omnium (legger varen til butikkens lager).

Application overview

Bruker → Fastly (caching) → Cloudflare (gullfunn.no, Svelte & Astro) → Pages og frontend-API → Cloudflare Workers (backend-API), Datadog (logging), Google Analytics, Azure AD B2C (autentisering), Channable. Workers ↔ Omnium (e-handelsbackend); Workers ← Sanity; Workers → Klarna/Vipps/nShift ↔ Omnium. Omnium → Sanity, Bluestone, VisionPoint (POS), XAL, Voyado Engage, Voyado Elevate, Kindly, Business Central. Sanity → Elevate → frontend. Kindly → frontend. Bluestone (PIM) ← XAL, VisionPoint, Sylvsmidja/andre leverandører, BC. BC ↔ VisionPoint. Nye fakta: logging i Datadog; innlogging via Azure AD B2C; Google Analytics.