Synk med Business NXT

Foreløpig — til kundeavklaring

Lesekontrakten er verifisert mot et reelt NXT-selskap med representative data (3 391 masterordrer, 2 373 produkter, 33 244 serienummerrader og 332 189 leveransetransaksjoner tilgjengelig for lesing).

Formål og avgrensning

ePortal eier masterordre-registeret; NXT eier produkter, priser, ekspedering og leveransedata. Synken har derfor to helt ulike deler:

1. Løpende synk — polling, daglig og ved behov.
2. Engangsmigrering — de eksisterende masterordrene flyttes inn i ePortal én gang og arkiveres deretter i NXT.

Løpende synk

Datatype	Retning	Brukes til
Produkter med klassifisering og strukturer	NXT → ePortal	Produktvalg, instrumentklassifisering (type 1, 2 og 10)
Priser	NXT → ePortal (live-oppslag ved behov)	Alltid fersk pris i tilbud og ordre
Kunder / skip / management	Begge veier	En ny kunde kan opprettes i ePortal og få tilbud; overføres til NXT senest ved første kjøp
Salgsordrer ved akseptert tilbud	ePortal → NXT	NXT ekspederer og fakturerer — se Datomotor og ordre til NXT
Leveransetransaksjoner	NXT → ePortal	Grunnlaget for datomotoren — se klassifisering
Serienumre	NXT → ePortal	Ett instrument per serienummerrad

flowchart LR
    A["Planlagt kjøring<br/>(daglig + ved behov)"] --> B["Les endringer fra NXT<br/>(vannmerke: endringstidspunkt)"]
    B --> C["Lagre rådata som<br/>uforanderlig historikk"]
    C --> D["Klassifiser transaksjoner"]
    D --> E["Oppdater leveransebildet<br/>per masterordre"]
    E --> F{"Avvik mot lokalt<br/>akseptert tilstand?"}
    F -- "Nei" --> G["Ferdig"]
    F -- "Ja" --> H["Trenger gjennomgang<br/>(aldri stille overskriving)"]

Beslutningspunkt — kundesynk i konflikt

Kundedata kan endres i begge systemer mellom synkene. Hvem vinner — per feltgruppe eller per system? Og hvilke utfyllende kundefelter må legges til i NXT når en ePortal-først-kunde overføres? Dette må avklares.

Engangsmigreringen av masterordrer

• Alle aktive masterordrer (ordretype 6, unntatt ordrer med Gr7 = 9) i Business leses inn og blir ePortal-masterordrer med tilstand «Importert». Gr7 = 9-ordrer holdes bevisst utenfor importen (filtreres bort på Business-siden ved henting).
• Tilknyttet historikk (tilbud, salgsordrer, leveranser, serienumre) følger med som uforanderlige observasjoner — det er slik datomotoren kan forklare datoer fra dag én.
• Etter migreringen arkiveres masterordrene i NXT. Ingen aktive masterordrer vedlikeholdes i NXT etterpå.
• Migreringen kan kjøres på nytt uten duplikater: hver rad har en stabil identitet (f.eks. selskap + journalnummer + transaksjonsnummer for leveranser). Importen overskriver aldri eksisterende rader — en ny kjøring legger kun til nye ordrer, nye linjer og nye observasjoner.

Importere kun ordrer og linjer (uten observasjoner)

Observasjons-hentingen (leveringstransaksjonene som mater datomotoren) skanner et bredt datovindu og kan mot en full prod-kopi overskride tidsgrensen. Du kan importere kun ordrene og linjene — som allerede har sine egne datoer fra NXT — ved å sende includeObservations: false:

POST api/SubscriptionImport/run-nxt
{ "maxOrders": 100, "includeObservations": false }

Da hoppes leveringstransaksjons-skanningen over. Ordrene og linjene kommer inn med riktige datoer; observasjonene (og datomotorens historiske forklaring fra leveranser) tas ikke med. Standard er includeObservations: true (full import).

Hva importen setter på ordre og linjer

• Kundenavn på ordren — hentes fra aktørregisteret (wv_Actor.actName via kundenummeret); finnes ingen lokal aktør, brukes navnet fra NXT-associaten. Navnet driver masterordre-listens kundenavn-kolonne.
• Linjepris og rabatt — NXT-ordrelinjens priceInCurrency (enhetspris) og discountPercent1 (rabatt %). Beløp per linje beregnes i visningen som antall × pris × (1 − rabatt %/100).
• Produkt-snapshot per linje — instrumentgruppene (Gruppe 1–6) samt beskrivelse og enhet hentes fra produktet i NXT (samme snapshot som når en linje opprettes manuelt). Feiler produktoppslaget, importeres linjen uten snapshot — importen stopper ikke.

Etterfylle allerede importerte ordrer (enrich-nxt)

Ordrer som ble importert før feltene over ble en del av importen kan etterfylles uten re-import:

POST api/SubscriptionImport/enrich-nxt
{ "maxOrders": 2100 }            // eller { "masterOrderNos": [ ... ] }

Endepunktet leser samme utvalg fra NXT og fyller kun blanke verdier på eksisterende rader:

• Kundenavn — kun når feltet er blankt på ordren.
• Linjepris/rabatt — kun når linjens enhetspris er tom eller 0.
• Instrumentgrupper (+ beskrivelse/enhet) — kun når alle seks gruppene er tomme/0 på linjen.

Manuelt redigerte verdier røres aldri, og endepunktet oppretter aldri nye ordrer eller linjer (ordrer som ikke finnes lokalt telles bare i svaret). Kjøringen er idempotent og kan gjentas. Tilgang styres av samme datatilgang som importen (Masterordre-import, opprette).

Spilleregler som beskytter dataene

• Lesing endrer aldri noe i NXT. Skriving skjer kun som salgsordre ved akseptert tilbud, kundeoverføring og selve arkiveringen ved migrering.
• Historikk er uforanderlig. En tidligere levert ordrelinje eller en gammel transaksjon skrives aldri om.
• Avvik gir gjennomgang, ikke overskriving. Hvis NXT-data ikke stemmer med det ePortal allerede har akseptert, flagges saken for manuell gjennomgang.
• Endringstidspunkt brukes kun som vannmerke for å hente nytt — aldri som identitet.

Avvik og feil

Situasjon	Håndtering
NXT utilgjengelig	Kjøringen prøves igjen; neste kjøring tar igjen etterslepet via vannmerket
Rad med endret innhold for kjent identitet	Registreres som kildeavvik og flagges — den lagrede historikken endres ikke
Ufullstendig kobling (f.eks. transaksjon uten gjenkjennbar ordrelinje)	Lagres som uavklart faktum; ingen videre effekt før den er avklart

Relaterte sider

• Prosessflyt — oversikt
• Leveranser og klassifisering