Datomotor og ordre til NXT¶

Foreløpig — til kundeavklaring

Åtte historiske testscenarier beskriver mulig forretningsintensjon, men kildekodeauditten viser motstridende vilkår, stille feil og klokkeavhengige datoendringer. De er derfor ikke en ferdig spesifikasjon. Opprettelse av salgsordre i NXT er planlagt, men kontrakten er ikke verifisert ennå — det løpet tegnes stiplet.

Formål og avgrensning¶

Datomotoren beregner neste leveringsdato per masterordrelinje. Den er forklarbar: hver kjøring skriver en logg som viser hvilken regel som traff og hvorfor.

Levert i dag vs. målbilde

Levert i dag: motoren kjører et fast, testet regelsett og skriver forklaringsloggen (datoendringer-visningen nedenfor). Under arbeid (målbilde): at reglene kan redigeres, versjoneres og simuleres av administrator uten kodeendring, og at forklaringen vises direkte på masterordrelinjen. Det bygges config-drevet i arbeidsdelen MO-017 (fase 2 + fase 9). Inntil det er levert, endres regelsettet i kode.

Datoene eies av ePortal og skrives aldri til NXT. Motoren har to typer input:

Leveranser — importert fra NXT (ferdigmeldt dato, antall, serienummer).
Tilbudsutfall i ePortal — aksepterte, avslåtte og utløpte tilbud. Hvis kunden ikke kjøper, flyttes datoen likevel videre i henhold til frekvens.

Reglene i hverdagsspråk¶

Dette er målbildet og de åpne policyvalgene etter legacy-auditten:

Status	Regel
Avklart prinsipp	Faktisk levering: en ny, klassifisert leveranseobservasjon kan gi ny dato basert på leveringsdato og frekvens
Må avklares	Dobbel frekvens: hva betyr «én periode ute av takt» — forsinket levering, tidlig levering over årsskifte eller en faktisk hoppet syklus?
Må avklares	Gruppesynkronisering: hvilke linjer påvirker gruppen, hva betyr gruppe 0, og hvor stor datotoleranse gjelder? Hele beslutningssettet lagres alltid samlet
Må avklares	Rental: om fast planlagt dato skal beholdes uten leveringsjustering
Avklart datakrav	Ikke levert: må bygge på eksplisitt ordre- og leveransegrunnlag, ikke fravær eller søskenlinjer alene
Avklart projeksjon	Ikke fulgt anbefaling: vises når bestilt innhold avviker fra anbefalingen, med kildefakta i forklaringsloggen
Avklart prinsipp	Avslått eller utløpt tilbud fryser ikke linjen; det eksplisitte utfallet kan flytte datoen etter frekvens
Absolutt stopp	Manuell overstyring — absolutt stopp
Må avklares	Aktivt tilbud: hvor lenge det skal blokkere, og om bare et eksplisitt utfall skal oppheve blokkeringen
Datakvalitet	Manglende, tvetydige eller ugyldige fakta gir «Trenger gjennomgang» med egen årsak; de skal aldri passere eller stoppe stille

Beslutningspunkt — datomotorens policy

Før første regelsett publiseres må kunden avklare:

den presise betydningen av dobbel frekvens,
hvor lenge et aktivt tilbud blokkerer,
om gruppe 0 betyr en virkelig gruppe eller «ingen gruppe»,
om en manuelt låst linje kan påvirke søskenlinjer,
om datoer ved månedsslutt skal beholde månedssluttforankringen.

Tid som går alene er ikke en gyldig årsak til ny dato. En endring må knyttes til en ny leveranseobservasjon eller et eksplisitt tilbudsutfall.

Fra fakta til ny dato — alt skjer i ePortal¶

flowchart TD
    A["Leveranser fra NXT"] --> C["Regelmotor<br/>(versjonert regelsett)"]
    B["Tilbudsutfall i ePortal<br/>(akseptert / avslått / utløpt)"] --> C
    C --> D["Forklaringslogg skrives<br/>(alltid, også uendret)"]
    D --> E{"Stoppregel?"}
    E -- "Ja" --> S["Ingen endring —<br/>årsak logges"]
    E -- "Nei" --> F["Ny dato gjelder umiddelbart<br/>— i én samlet operasjon<br/>for hele gruppen"]

    style S fill:#ffd6d6,stroke:#cc0000,color:#000
    style F fill:#d4f7d4,stroke:#006600,color:#000

Datoendringen er en lokal, samlet operasjon: gruppesynkroniserte linjer oppdateres alle i samme transaksjon, og det finnes ingen ventetilstand mot NXT — fordi ingenting skal skrives dit.

Ordre til NXT ved akseptert tilbud¶

Det eneste som sendes til NXT i denne flyten, er salgsordren når kunden aksepterer et tilbud:

flowchart LR
    A["Tilbud akseptert<br/>i ePortal"] --> B{"Finnes kunden<br/>i NXT?"}
    B -- "Nei" --> C["Overfør kunde<br/>til NXT først"]
    B -- "Ja" --> D
    C -.-> D["Opprett salgsordre type 1<br/>med masterordre- og linjereferanse<br/>(planlagt, ikke verifisert)"]
    D -.-> E["NXT ekspederer<br/>og fakturerer"]
    E -.-> F["Leveransedata kommer<br/>tilbake via importen"]

    style D fill:#fff3cd,stroke:#b8860b,color:#000

Ordren og hver ordrelinje opprettes med stabile ePortal-referanser, slik at leveransedata (ferdigmeldt dato, antall, serienummer) kobles riktig tilbake til masterordren og riktig linje. De eksakte NXT-feltene er ikke verifisert ennå. Feiler opprettelsen, prøves den igjen automatisk; en ordre opprettes aldri dobbelt, og uløselige feil havner i gjennomgangskøen.

Forklarbarhet¶

For hver linje, hver kjøring lagres: hvilke fakta som gjaldt, hvilke regler som ble vurdert, hvilken som traff (eller hvilken stoppregel som blokkerte), forrige og ny dato, og regelsett-versjonen.

Brukeren ser nå «hvorfor endret datoen seg?» direkte på masterordrelinjen: på Linjer-fanen har hver linje en info-knapp («Hvorfor endret datoen seg?») som åpner en tidslinje av kuraterte forklaringer for linja — for hver kjøring vises hvilken regel som traff, utfallet, dato-bevegelsen (forrige → foreslått), faktaene beslutningen bygde på, og begrunnelsen. Visningen er skrivebeskyttet; ingenting beregnes på nytt i nettleseren. Knappen vises kun for brukere med datatilgangen «Datoendringslogg» (Subscription.DateChangeTrace); lenken videre til regelsett-versjonen vises kun med «Regeladministrasjon (datomotor)» (Subscription.RuleAdmin). Den samme kuraterte forklaringen vises også per linje i simuleringsresultatet (utvid en berørt linje).

Administrator kan simulere et regelutkast mot den publiserte versjonen og se konsekvensen (endrede datoer, nye avvik, stoppede linjer) før publisering, uten å røre noen linje (se under). Den fulle batch-loggen vises fortsatt i den provisoriske datoendringer-visningen nederst.

Regeladministrasjon (Innstillinger → Masterordre → Datomotor – regler)¶

Siden Innstillinger → Masterordre → Datomotor – regler (/settings/portal-setting/masterorder-rules) viser regelsettene datomotoren bygger på: én publisert versjon som er låst, eventuelle utkast, og arkiverte versjoner. Hver regel vises som en lesbar «Når … Så …»-setning med regeltype, prioritet og aktiv/inaktiv-status — ingen rå JSON.

Tilgang: siden krever datatilgangen «Regeladministrasjon (datomotor)» (Subscription.RuleAdmin), som er fail-closed — ingen har den som standard. Uten tilgang vises verken menypunktet eller siden. Tilgangen gis under Innstillinger → Datatilgang. API-et håndhever den samme tilgangen uavhengig av grensesnittet.

Slik gjør du:

Åpne Innstillinger → Masterordre → Datomotor – regler. Siden er delt i to: venstre kolonne har versjonsvelgeren øverst og Regelsett-panelet under, mens høyre panel brukes til å redigere en regel eller se et simuleringsresultat.
Velg en versjon i versjonsvelgeren øverst i venstre kolonne. Regelsett-panelet for den valgte versjonen vises rett under, med scope, status og versjon i toppen (og «endret» når utkastet har ulagrede endringer). Den publiserte versjonen er låst.
Trykk Lag utkast for å lage en redigerbar kopi av den publiserte versjonen.
I regellisten kan du nå administrere reglene i utkastet. Hver rad har en av/på-bryter, et kompakt trinn-merke (f.eks. S1/R1), regelnavnet, et type-merke («systemregel», «rediger» eller «ny») og en «…»-meny.
- Av/på-bryteren i raden slår regelen av eller på i utkastet — også for systemregler (se avsnittet om systemregler under). Å slå av en regel gjør utkastet «endret» og krever ny simulering før publisering, som alle andre endringer.
- Ny regel / Fra mal (nederst i listen) oppretter en egendefinert regel fra en trygg mal — «stopp for gjennomgang» eller «marker avvik» — og åpner betingelsesbyggeren. En egendefinert «marker avvik»-regel har eget vurderingsvalg og kan redigeres og slettes fritt; datomotorens innebygde avviksregler (R5/R6) forblir låst. Datoflyttende handlinger eies av datomotoren og kan ikke opprettes som ny regel.
- «…»-menyen på raden samler handlingene: Rediger, Dupliser (lager en redigerbar kopi av en egendefinert regel), Flytt opp/ned (endrer regelens prioritet innenfor samme trinn — rekkefølgen mellom trinnene er fast) og Slett (egendefinerte regler og systemregler; innebygde regler kan ikke slettes, og valget er da skjult).
Klikk en regel i listen (eller blyantikonet) for å åpne redigeringen inline i høyre panel ved siden av regellisten — den valgte regelen markeres i listen. Her bygger du regelens betingelser i en veiledet bygger (felt → operator → verdi): verdifeltet får automatisk riktig type (dato, tall, ja/nei, valg, frekvens), og du grupperer betingelser som ALLE av (OG) eller ENHVER av (ELLER) og kan neste grupper. For felt som kan mangle verdi (f.eks. bekreftet leveringsdato, anbefalt dato, siste ordreforslag, tilbudsutfall) finnes operatoren «har en verdi» — den tar ingen verdi og er sann når feltet er satt (brukes f.eks. i N1-vilkåret «det finnes en bekreftet leveringsdato»). Handlingen velges fra et sett trygge, testede regelhandlinger. Hva du får endre styres av regelens type:
- Systemregler (N1/S1/S4/S5/R3 — f.eks. «Manuell overstyring stopper linjen») er nå fullt redigerbare på lik linje med egendefinerte regler: betingelser, parametere, av/på-bryter, rekkefølge, sletting og valg av handling fra det godkjente settet med regelhandlinger. Reglene har et «systemregel»-merke og redigereren viser en tydelig (lukkbar) advarsel: dette er strukturell sikkerhet (MO-009), og endringer kan påvirke datoberegninger for hele porteføljen og fjerner golden-parity-beskyttelsen — simulér nøye før du publiserer. Alle fem systemreglene (S1/S4/N1/S5/R3) leser nå motoren av/på-bryteren og vilkåret — men for flere av dem eies selve effekten (dato-matematikken, normaliseringen eller gruppe-aggregeringen) fortsatt av motoren; vilkåret kan da bare avgrense hvilke linjer/medlemmer regelen gjelder, ikke endre hvordan datoen regnes ut. Motor-styrt i dag: gruppesynk-vinduet (R3), S1 (manuell overstyring) — slår du S1 av, beregnes manuelt overstyrte linjer på vanlig måte igjen, og et vilkår på S1 (f.eks. bare utleielinjer) avgrenser hvilke overstyrte linjer som ekskluderes — og S4 (ingen kausal årsak). For S4 er det kun forklaringen (regelkoden/teksten i datoendringsloggen) som er regel-styrt: slår du S4 av eller avgrenser den bort, får en årsaksløs linje en nøytral sportekst, men datoen står fortsatt uendret. Regelen «ingen kausal årsak ⇒ ingen fremrykking» er et ufravikelig sikkerhetsgulv eid av motoren (MO-009 LD-013) — det kan aldri slås av, og det er derfor ikke lov å bytte S4 til en dato-flyttende regelhandling (avvises ved lagring/publisering). S1 og S4 kan derimot konservativt byttes til «stopp for gjennomgang» (ReviewStop) — en gjennomgangsstopp uten dato-effekt: velger du det, stoppes de aktuelle linjene for manuell gjennomgang i stedet for at motoren avgjør dem videre. Dette er det eneste tillatte byttet for S1/S4; alle dato-flyttende regelhandlinger (og «marker avvik») avvises fortsatt. Regelhandlings-nedtrekket i regel-editoren viser derfor bare den lovlige listen per regel: for S1/S4 dens egen handling + «stopp for gjennomgang», for N1/S5/R3 kun dens egen. N1 (normaliser tapt tilbud) — slår du N1 av, normaliseres ikke lenger et «tapt tilbud uten oppfølging» selv om det finnes en reell levering, og linjen blir stående uendret på tapt-tilbud-stien (ingen fremrykking); et vilkår på N1 avgrenser hvilke linjer som normaliseres. Selve normaliserings-effekten (å åpne for datofremrykking) eies fortsatt av motoren — N1 er et forhåndsflagg, ikke en egen datohandling, og kan ikke byttes til en annen regelhandling. S5 (gjennomgangs-gap) — slår du S5 av, flagges ikke lenger en linje der planlagt dato ligger foran den beregnede planen uten at noe forklarer det; linjen blir stående uendret i stedet for å stoppes for gjennomgang, og datoen flyttes fortsatt aldri bakover. Et vilkår på S5 avgrenser hvilke slike linjer som flagges. Selve utløseren (at datoen ligger foran den beregnede planen) og «flytt aldri bakover»-matematikken eies fortsatt av motoren — S5 er vevd sammen med R1-beregningen og kan ikke skilles ut som egen regel eller byttes til en annen regelhandling; du kan bare slå den av eller avgrense den på tilgjengelige felt. R3 (gruppesynk) — slår du R3 av, hoppes hele gruppesynk-steget over og hver linje beholder sin egen dato (ingen samordning). Et vilkår på R3 vurderes per medlem og avgjør om linjen deltar i gruppesynken: et medlem som ikke matcher verken driver gruppedatoen (regnes ikke med når den høyeste datoen i gruppen finnes) eller trekkes med som årsaksløst søsken — det beholder sin egen linjedato. Selve gruppe-aggregeringen (høyeste/laveste dato) og synk-vinduet eies fortsatt av motoren; vilkåret kan bare avgrense hvilke medlemmer som er med, og R3-regelhandlingen kan ikke byttes ut — kun slås av eller avgrenses. Simulér alltid for å se den faktiske effekten.
- Innebygde regler kan bare avgrenses: betingelsene du legger til kombineres (OG) med regelens innebygde vilkår og kan aldri utvide den. Regelhandlingen er låst.
- Egendefinerte regler (trygge, ikke-datoflyttende handlinger som «marker avvik» / «stopp for gjennomgang») kan bygges fritt med egne betingelser og slås av/på. Forhåndsvisningen «Når … Så …» oppdateres mens du redigerer. Nederst i redigeringspanelet ligger Avbryt, Simulér endring og OK — «Simulér endring» lagrer endringen og kjører simuleringen i ett steg, mens OK bare tar vare på endringen i utkastet.
Trykk OK (eller Lagre over regellisten). Serveren validerer regelsettet; feil vises per regel.
Trykk Simulér (over regellisten) eller Simulér endring (i redigeringen) for å kjøre utkastet mot den publiserte versjonen. Resultatet vises i høyre panel som et kompakt sammendrag («… linjer vil endres …») med status (venter på godkjenning / godkjent). Trykk Se full diff for å utvide hele oversikten: hvor mange linjer som får endret dato, nye avvik, stoppes eller er uendret, og de berørte linjene (publisert vs. utkast). Ingen linje endres av en simulering.
Trykk Godkjenn på et simuleringsresultat du er fornøyd med. Endrer du utkastet etterpå (lagrer, redigerer en regel, bytter versjon) faller godkjenningen bort automatisk — du må simulere og godkjenne på nytt.
Trykk Publisér. Knappen er kun aktiv når du har en godkjent simulering av utkastet slik det står nå. Serveren håndhever det samme kravet uavhengig av knappen, arkiverer forrige publiserte versjon og gjør utkastet til ny publisert, låst versjon.
Angre en publisering: velg den publiserte versjonen og trykk Trekk tilbake. Den publiserte versjonen arkiveres, og den forrige publiserte versjonen blir aktiv (Publisert) igjen. Handlingen vises kun når det finnes en tidligere publisert versjon å gjenopprette, og en bekreftelsesdialog forklarer konsekvensen først. Dette er en rask angre-vei etter en publisering du vil reversere — du slipper å lage og publisere et nytt utkast for å komme tilbake til forrige versjon. Krever samme tilgang som publisering.

Trekk tilbake vs. lag nytt utkast

Trekk tilbake gjør den forrige publiserte versjonen aktiv igjen — den er ment for å reversere en nettopp publisert versjon. Vil du i stedet endre reglene fremover, lag et utkast fra den publiserte versjonen, rediger, simulér, godkjenn og publisér som normalt.

Hva som faktisk påvirker beregningen i denne versjonen

Datomotoren har regelrekkefølgen og betingelsene innebygd og testet. Fra regeladministrasjonen er det i dag bare tre parametere som endrer beregningen:

Parameter	Regel	Standard
Blokkering ved aktivt tilbud	Stopp – aktivt tilbud	12 måneder
Grense for gammelt ordreforslag	Stopp – fremtidig dato med gammelt ordreforslag	6 måneder
Vindu for gruppesynkronisering	Synkroniser datoer i gruppen	3 måneder

Betingelsene du bygger avgrenser når en innebygd regel gjelder — de kombineres (OG) med regelens innebygde vilkår og kan aldri utvide eller erstatte den. Selve dato-matematikken og regelrekkefølgen er fast og eng-eid; du velger hvilken betingelse som utløser hvilken trygg, testet handling, aldri hvordan datoen regnes ut. Alle fem systemreglene er nå motor-styrte: R3-vinduet, S1 (av/på + vilkår), S4 (kun forklaringen — «ingen kausal årsak ⇒ ingen fremrykking» er et ufravikelig motor-eid gulv), N1 (av/på + vilkår på normaliserings-forhåndsflagget), S5 (av/på + vilkår som avgjør om et gjennomgangs-gap flagges — «flytt aldri bakover»-matematikken forblir motor-eid) og R3 (av/på + vilkår per medlem som avgjør hvilke linjer som deltar i gruppesynken — gruppe-aggregeringen og synk-vinduet forblir motor-eid).

Utkast tas ikke i bruk før de publiseres

Et utkast kan redigeres og lagres uten å påvirke noen beregning. Det tas først i bruk når det publiseres, og publisering krever en godkjent simulering av utkastet slik det står. Endrer du utkastet etter godkjenningen, må du simulere og godkjenne på nytt før du kan publisere.

Avklart: redigering skjer i ePortal

Masterordrer, datoer og manuell overstyring redigeres i ePortal. NXT brukes til ekspedering og fakturering av salgsordrene. Kundedata kan redigeres begge steder og synkroniseres — konfliktregelen er et åpent punkt (se modulforsiden).

Automatisk anvendelse (nattlig jobb)¶

Den nattlige datomotor-jobben (Innstillinger → KontiConnect → «Interne jobber», MasterOrderDateEngine) evaluerer alle masterordrelinjer og skriver automatisk nye datoer for hver masterordre som fikk minst én endret linje — ingen bekreftelse kreves. Jobben kjører samme, sikkerhetsgjennomgåtte skrivevei som operatørhandlingen under (fersk evaluering, rad-versjon- og overstyringsvakter, ledger-idempotens), bare uten et menneske i loopen. En forbigående kollisjon (f.eks. en samtidig manuell «Bruk beregnede datoer») logges og forsøkes automatisk på nytt neste natt — linjen evaluerer fortsatt som endret helt til den faktisk skrives. En linje som er manuelt overstyrt er derimot ekskludert fra evalueringen (S1-regelen) og forblir uendret til overstyringen fjernes — den «prøves» ikke på nytt av seg selv. Se Interne jobber for jobboppsett.

Bruk beregnede datoer på en masterordre (operatørhandling)¶

Handlingen «Bruk beregnede datoer» i masterordrens handlingsmeny (detaljpanelets Handlinger-nedtrekk) skriver datomotorens beregnede leveringsdatoer på ordren umiddelbart, uten å vente på neste nattlige jobbkjøring. Den kjører en fersk evaluering av den publiserte versjonen for dagens dato og lagrer resultatet under de vanlige samtidighets- og overstyringsvaktene. Datoen kan ikke velges av operatøren; den settes på serveren.

Tilgang: handlingen krever datatilgangen «Bruk beregnede datoer (datomotor)» (Subscription.ScheduleApply), som er fail-closed — ingen har den som standard, og den er atskilt fra «Regeladministrasjon (datomotor)» (å bruke datoene er ikke det samme som å redigere reglene). To nivåer:

Se-tilgang (CanView) viser handlingen og lar deg åpne forhåndsvisningen.
Opprett-tilgang (CanCreate) kreves for å faktisk bruke datoene (skrive).

Tilgangen gis per rolle under Innstillinger → Datatilgang → gruppen Abonnement. API-et håndhever begge nivåene uavhengig av grensesnittet.

Slik gjør du:

Åpne en masterordre, og velg Handlinger → «Bruk beregnede datoer».
Dialogen laster en forhåndsvisning (skrivebeskyttet): linjene som får ny dato, med fra → til og begrunnelse. Er det ingenting å endre, vises «Ingen datoer endres for denne ordren nå.» og bekreft-knappen forblir inaktiv.
Trykk «Bruk datoene» for å skrive. Du får en bekreftelse med antall linjer som fikk oppdatert dato, og linjene i ordren oppdateres.

Forhåndsvisningen er veiledende: selve skrivingen kjører fortsatt motorens sikkerhetsvakter (rad-versjon og manuell overstyring), så en linje kan avvises ved skriving selv om den var med i forhåndsvisningen. Utfall som «Ingenting å bruke», «Endret av noen andre», «Manuelt overstyrt line» eller «Ordren er avsluttet» vises som en tydelig melding — ingen delvis skriving skjer. Handlingen skriver ingenting til NXT.

Datoendringer-visningen (provisorisk logg)¶

Siden Abonnement → Datoendringer (/subscription/date-changes) viser den siste evalueringsbatchen fra datomotoren — én rad per linjevurdering med masterordrenr., linjenr., regelkode, utfall, forrige/foreslått dato, årsak og begrunnelse. En full batch kan være titusener av rader.

Server-paging: listen henter og viser 50 rader per side fra serveren (GET api/SubscriptionTrace/lines?skip=&pageSize=). Nettleseren holder aldri hele batchen i minnet samtidig — bla mellom sidene med pagineringen nederst.
Filter (server-side): filterknappen åpner et felt for masterordrenr., utfall (Changed / Stopped / Unchanged / Excluded) og regelkode. Filtrene sendes til serveren og begrenser hele batchen (ikke bare den viste siden), så du går rett til de aktuelle radene i stedet for å bla gjennom hele loggen. «Evaluer» kjører en ny batch og hopper tilbake til første side.