Interne jobber — masterordre¶

Masterordre-modulens åtte batch-motorer kjører som planlagte interne jobber i Konti Connect, i den egne kategorien «Interne jobber». En intern jobb er en vanlig Konti Connect-integrasjon — med cron-schedule, manuell kjøring, kjøringshistorikk, kjørelås og overvåkning — men den kobler seg ikke mot et eksternt system med egne påloggingsdetaljer: den kjører ePortals egne motorer på tenantens data. (NXT-synk-jobben bruker tenantens eksisterende Visma Business NXT-oppsett for selve NXT-lesingen.)

Type: Interne planlagte jobber (ingen egen autentisering) Modul i ePortal: Konfigureres i Konti Connect; virker på Masterordre-modulen (moduleID 50) Karakteristisk: Jobbene er idempotente og deler kjørelås med de manuelle handlingene i masterordre-bildene — samme motor kjører aldri dobbelt

De åtte jobbene¶

Jobb (navn i Konti Connect)	TypeCode	Hva den gjør
Masterordre: NXT-synk	`MasterOrderNxtSync`	Importerer nye/endrede masterordrer og leveringsobservasjoner fra Visma Business NXT inn i den lokale abonnementsprojeksjonen. Kjører i deltamodus med to sjekkpunkter (ordrer og observasjoner) og et arbeidsbudsjett per kjøring.
Masterordre: Datomotor	`MasterOrderDateEngine`	Kjører datomotoren (Live) over de lokale leveringsobservasjonene, skriver det forklarbare sporet, og skriver deretter automatisk nye planlagte datoer for hver masterordre med minst én endret linje — uten bekreftelse (MO-151).
Masterordre: Ordreforslag	`MasterOrderProposals`	Genererer ordreforslag for masterordrer som har nådd planlagt dato. Idempotent — maks ett åpent forslag per ordre; utsatte forslag som er forfalt gjenåpnes.
Masterordre: Auto-ordreforslag	`MasterOrderOfferAutoSend`	Konverterer forfalte ordreforslag i auto-modus til tilbud/ordreforslag og sender dem (auto-konverter + auto-utsend).
Masterordre: Påminnelser	`MasterOrderOfferReminders`	Sender purringer på ubesvarte tilbud (med karenstid og maks antall), utløper forfalte tilbud og rydder utløpte aksept-tokens.
Visma Business NXT: serienummer	`VismaBusinessNXT_SerialNumbers`	Leser serienummerrader fra Visma Business NXT inn i korrelasjonstabellen (`wv_ExtCache_NxtSerialUnit`) og binder dem til instrumenter i instrumentregisteret (MO-143 S4a/S4b). Bakfyller først tilbudslinje-kartet fra uavklarte fullførte tilbudsoverføringer (roterer rettferdig via en varig markør, avgrenset til halvparten av arbeidsbudsjettet; ferdig kartlagte ordrer leses aldri på nytt), slik at også tilbudsfødte ordrer bindes. Deltamodus med eget vannmerke per selskap og en periodisk full avstemming mot kilden.
Masterordre: malavvik-cache	`MasterOrderTemplateDeviationCache`	Regner ut malavviket for hver levende masterordre og lagrer ett sammendrag per ordre, slik at masterordrelista kan filtrere og sortere på malavvik. Kaller den samme kontrollen som fanen på den enkelte ordren — regelen finnes bare ett sted. Fanen på ordren regner fortsatt live og leser aldri sammendraget; porteføljesammendraget er derfor inntil ett døgn gammelt av design, og beregningstidspunktet vises sammen med tilstanden. En ordre jobben ennå ikke har rukket å regne på står som «Ikke beregnet» — aldri som «i orden». Skriver ingenting på ordrene selv.
Masterordre: NXT-overføring (kø)	`MasterOrderNxtTransferDrain`	Drenerer køen av tilbud→NXT-salgsordreoverføringer (eldste først, avgrenset av `MaxBatch`). Køede rader kommer fra aksept-bryteren og manuelle handlinger. Idempotent via overførings-ledgeren, og styrt av funksjonsbryteren `Subscription.OfferNxtTransfer.Enabled` (av som standard — avslått bryter gir advarsel i kjøringsloggen, aldri feil).

Jobbene opprettes per tenant av administrator i Konti Connect → Integrasjoner («Ny integrasjon» → velg type under «Interne jobber») — de opprettes ikke automatisk ved oppgradering.

Avhengighet og anbefalt kjøreplan¶

De fire nattlige jobbene bygger på hverandre og bør kjøres i rekkefølge:

flowchart LR
    A["NXT-synk<br/>(nattlig, f.eks. 03:00)"] --> B["Datomotor<br/>(nattlig, f.eks. 04:00)"]
    B --> C["Ordreforslag<br/>(nattlig, f.eks. 04:30)"]
    C --> G["Malavvik-cache<br/>(nattlig, f.eks. 05:00)"]
    C -.-> D["Auto-ordreforslag<br/>(faste dager i måneden)"]
    E["Påminnelser<br/>(daglig)"]
    F["NXT-overføring (kø)<br/>(hvert 15.–30. min i arbeidstiden)"]

Jobb	Anbefalt kadens	Kommentar
NXT-synk	Nattlig, f.eks. kl. 03:00	Først — datomotoren leser observasjonene den skriver
Datomotor	Nattlig, f.eks. kl. 04:00	Etter NXT-synk
Ordreforslag	Nattlig, f.eks. kl. 04:30	Etter datomotoren; kan i tillegg kjøres oftere på dagtid
Auto-ordreforslag	Faste dager i måneden via cron	F.eks. den 1. og 15. kl. 06:00: `0 0 6 1,15 * ?`
Påminnelser	Daglig	Purring/utløp/opprydding
NXT-overføring (kø)	Hyppig, f.eks. hvert 15.–30. min i arbeidstiden	Kø-drenering — uavhengig av natt-kjeden; korte, avgrensede kjøringer så aksepterte tilbud raskt blir NXT-ordrer
Serienummer-synk	F.eks. hvert 30.–60. min i arbeidstiden	Uavhengig av natt-kjeden; binder serienumre til instrumenter etter hvert som NXT leverer
Malavvik-cache	Nattlig, f.eks. kl. 05:00	Sist i natt-kjeden. Den leser malpakkene og ordrelinjene slik de står etter at de øvrige jobbene er ferdige, så et avvik som skyldes en linje datomotoren eller ordreforslag-jobben nettopp endret, kommer med samme natt

Rekkefølgen håndheves ikke hardt: datomotor- og ordreforslag-jobben har en ferskhetsvakt (UpstreamFreshnessHours, standard 26 timer) som legger en advarsel i kjøringsloggen når forrige vellykkede oppstrøms-kjøring (henholdsvis NXT-synk og datomotor) er eldre enn terskelen — kjøringen stoppes aldri av vakten.

Konfigurasjonsnøkler¶

Konfigurasjonsmalen fylles ut automatisk når du velger jobbtypen i integrasjonseditoren — også for serienummer-jobben, som fram til august 2026 var den eneste masterordre-jobben uten mal og derfor svarte «Ingen forhåndsdefinert skjemamal funnet. Bruk JSON-modus.». Malen fyller bare inn felt som mangler; verdier du allerede har satt beholdes. Nøklene per jobb:

Masterordre: NXT-synk¶

Nøkkel	Standard	Hva den betyr
`SyncOrders`	`true`	Go-live-bryteren. `true` = importer/oppdater masterordrer fra NXT (test-/migreringsfasen). `false` = kun leveringsobservasjoner (etter go-live, når ePortal er master for ordrene). Se runbook-steget under.
`SyncObservations`	`true`	Synk leveringsobservasjoner
`RunEnrich`	`true`	Etterfyll blanke hodefelter/linjepriser på importerte ordrer
`MaxOrders`	`25`	Øvre grense for antall ordrer i en avgrenset (første) kjøring
`MaxPagesPerRun`	`40`	Arbeidsbudsjett: maks antall NXT-sider per kjøring
`MaxRuntimeSeconds`	`120`	Arbeidsbudsjett: maks kjøretid per kjøring
`ObservationBackfillMonths`	`0`	`0` = delta (normal drift). `> 0` = engangs tilbakefylling så mange måneder bakover — tung, kjøres manuelt
`RunAsUserId`	`0`	Systemaktør-id i endringsloggen (0 = system)
`DebugLogging`	`false`	Detaljert logging, kun for feilsøking

Masterordre: Datomotor¶

Nøkkel	Standard	Hva den betyr
`UpstreamFreshnessHours`	`26`	Ferskhetsvakt: advarsel i kjøringsloggen når forrige vellykkede NXT-synk er eldre enn dette (blokkerer aldri)
`RunAsUserId`	`0`	Systemaktør-id i endringsloggen (0 = system)
`DebugLogging`	`false`	Detaljert logging

Masterordre: Ordreforslag¶

Nøkkel	Standard	Hva den betyr
`UpstreamFreshnessHours`	`26`	Ferskhetsvakt: advarsel når forrige vellykkede datomotor-kjøring er eldre enn dette (blokkerer aldri)
`DebugLogging`	`false`	Detaljert logging

Masterordre: Auto-ordreforslag og Masterordre: Påminnelser¶

Nøkkel	Standard	Hva den betyr
`RunAsUserId`	`0`	Systemaktør-id i endringsloggen
`DebugLogging`	`false`	Detaljert logging

Selve brev-oppførselen (karenstid, maks purringer, avsender, maler) styres av pipeline-konfigurasjonen, ikke av jobb-konfigurasjonen.

Visma Business NXT: serienummer¶

Nøkkel	Standard	Hva den betyr
`CompanyNo`	(påkrevd)	NXT-selskapsnummeret serienumrene leses for. Vannmerket er partisjonert per selskap. Jobben bruker tenantens aktive Visma Business NXT-integrasjon for selve påloggingen — ingen egen ClientId.
`MaxPagesPerRun`	`40`	Arbeidsbudsjett: maks antall NXT-sider per kjøring. Bakfyllet av tilbudslinje-kartet får halvparten (heltallsdelt), håndhevet per ordre: en ordre slippes bare til når minst én side gjenstår av bakfyllets halvdel, og tilbakelesingen dens er hardt begrenset til det som gjenstår — trenger ordren mer, feiler den lukket og prøves igjen senere. Sidene bakfyllet bruker trekkes fra kjøringens felles budsjett, så serienummer-fasene beholder alltid minst den andre halvdelen. Med `MaxPagesPerRun` satt til `1` blir bakfyllets andel 0 sider — det slipper ingen ordrer til, og serienummer-fasene beholder hele budsjettet
`MaxRuntimeSeconds`	`120`	Arbeidsbudsjett: kjøretidsgrensen sjekkes ved trygge grenser (mellom ordrer i bakfyllet, før avstemmingen og mellom ordrelinjer i bindingen) - en pågående lesing eller linje avbrytes aldri midt i. Bakfyllet får maks halvparten av tiden. Resten fortsetter ved neste kjøring
`ReconcileEveryNRuns`	`10`	Hvor mange fullførte delta-kjøringer det går mellom hver fulle avstemming mot kilden
`DebugLogging`	`false`	Detaljert logging, kun for feilsøking

Hver kjøring starter med et bakfyll av tilbudslinje-kartet (wv_Subscription_OfferLineNxtLine): uavklarte fullførte tilbud→NXT-overføringer — ordrer som fortsatt har ukoblede linjer eller en åpen tvetydig sak — leses tilbake fra NXT og entydige produktlinjer kobles automatisk til tilbudslinjene sine, slik at også tilbudsfødte ordrelinjer kan bindes til instrumenter i samme kjøring. Ferdig kartlagte ordrer leses aldri på nytt. Bakfyllet er avgrenset: det får maks halvparten av side- og kjøretidsbudsjettet (MaxPagesPerRun/MaxRuntimeSeconds), håndhevet per ordre — hver ordres tilbakelesing er hardt begrenset til det som gjenstår av halvdelen — og sidene det bruker trekkes fra kjøringens felles sidebudsjett. Rekker det ikke over hele restanselisten, stopper det ved en trygg ordregrense — serienummer-fasene kjører uansett videre med resten av budsjettet. Neste kjøring fortsetter fra en varig markør (sjekkpunktet OfferLineBackfillCursor, ordre-ID-en til den sist forsøkte overføringen): restanselisten leses i avgrensede sider etter markøren, og når enden er nådd starter rotasjonen forfra (maks én runde per kjøring). Dermed prøves alle uavklarte ordrer på nytt over tid, samtidig som en varig åpen tvetydig sak tidlig i listen aldri kan sluke budsjettet og sperre senere ukoblede ordrer. Steget er feilisolert — feiler bakfyllet, logges en advarsel og serienummer-synken fortsetter som normalt; kartet repareres ved neste kjøring. Et tidsavbrudd mot NXT behandles som en vanlig ordrefeil: sidene som ble brukt telles mot budsjettet og markøren flyttes forbi ordren, slik at gjentatte tidsavbrudd aldri leser de samme ordrene om igjen. Ordrer med tvetydige produktlinjer (samme produkt flere ganger) kobles aldri automatisk: de registreres som varige tvetydige saker (AmbiguousOrder) og avklares manuelt med handlingen Koble linjer på NXT-serienummer-siden (se instrumentregisteret).

Jobben husker fremdriften i tre sjekkpunkter: vannmerket LastSerialSyncTimestamp (rå NXT-tidsstempel med 5 minutters replay-vindu), telleren RunsSinceReconcile og bakfyll-markøren OfferLineBackfillCursor. Første kjøring (og avstemmingen) leser serienumrene ordre-for-ordre for et samlet lokalt ordresett: de importfødte masterordrene som har instrumenter, ordrene fra fullførte tilbudsoverføringer og ordrene som allerede finnes i tilbudslinje-kartet; deretter tar delta-lesingen over. Avstemmingen markerer rader som er borte fra kilden (MissingAtSourceSince); en rad som er borte to avstemminger på rad settes til RemovedAtSource — men en rad som er bundet til et instrument mistes aldri automatisk: den beholder bindingen og varsles i kjøringsloggen.

Uavklarte rader i portalen: siden NXT-serienummer under Abonnement (modul 50) viser alle uavklarte rader - og bundne rader som er borte fra kilden. Tabellen er skrivebeskyttet, med ett unntak: rader med årsak AmbiguousOrder har handlingen Koble linjer, som åpner den manuelle koblingsvisningen (tilbudslinjer mot NXT-ordrelinjer, én kobling om gangen, skrevet under samme lås som synkjobben og logget i endringsloggen på tilbudet). Siden ligger ikke i noen standardmeny: en administrator aktiverer den per kunde via Menyadministrasjon (velg ruten «NXT-serienummer» under Abonnement (modul 50)). Se instrumentregisteret.

Operatorspørring (Systemadministrasjon → SQL-editor, mot klientdomenet) er den dokumenterte reserven for den samme mengden:

SELECT NxtCompanyNo, NxtOrderNo, NxtLineNo, NxtSequenceNo, SerialNo, ProductNo,
       BindState, UnbindReason, ServiceObjectId, FirstSeenAt, LastSeenAt, MissingAtSourceSince
FROM   dbo.wv_ExtCache_NxtSerialUnit
WHERE  BindState <> 'Bound' OR MissingAtSourceSince IS NOT NULL
ORDER  BY NxtOrderNo, NxtLineNo, NxtSequenceNo;

Et serienummer et menneske har skrevet inn manuelt overskrives aldri av jobben: en uenighet blir stående som en varig konflikt (ManualValueDisagrees) til en operatør avgjør den — rett verdien i NXT, rediger instrumentets serienummer, eller tøm det manuelle serienummeret for å gi eierskapet tilbake til synken.

Masterordre: malavvik-cache¶

Nøkkel	Standard	Hva den betyr
`BatchSize`	`200`	Hvor mange masterordrer jobben henter om gangen. Den går gjennom hele porteføljen uansett — nøkkelen styrer bare hvor store bitene er. Hver bit regnes ut i én felles operasjon, ikke én per ordre, så en større bit betyr færre databaseoppslag totalt. Blir en ordre slettet mens jobben går, hopper den aldri over de neste — porteføljen leses med en nøkkelbasert markør (`MasterOrderId > @AfterMasterOrderId`), ikke `OFFSET`
`DebugLogging`	`false`	Detaljert logging, kun for feilsøking

Jobben går gjennom alle masterordrer som ikke er slettet — også avsluttede og de som venter på gjennomgang, siden et malavvik kan være verdt å se også der. For hver ordre kaller den den samme kontrollen som fanen «Avvik fra mal», og lagrer ett sammendrag: tilstanden, antall avvik per type, hvor mange instrumenter som faktisk kunne kontrolleres, og når beregningen ble gjort.

Fire tilstander, og «Ikke beregnet» er en av dem. Sammendraget sier Avvik når kontrollen fant minst ett, Ufullstendig dekning når den ikke fant noen, men minst ett instrument ikke kunne sammenlignes i det hele tatt (mangler produktnummer, treffende malpakke eller instrumentgruppe), og Kontrollert først når alt ble kontrollert og ingenting avvek. En ordre jobben ennå ikke har rukket å regne på står som Ikke beregnet. Den fjerde tilstanden slås aldri sammen med Kontrollert — «ingen svar» er ikke det samme som «i orden», og lista skiller dem alltid.

En feilet ordre beholder sitt forrige sammendrag. Feiler beregningen for én ordre, logges den som feilet i kjøringsloggen og kjøringen går videre til neste; det gamle sammendraget står urørt til neste vellykkede kjøring. Jobben erstatter aldri et gyldig sammendrag med tomrommet etter et mislykket forsøk. Til slutt i hver kjøring ryddes sammendrag for ordrer som er slettet.

Jobben skriver ingenting på masterordrene, tilbudene eller malpakkene — kun sitt eget sammendrag, som ingen annen flyt enn masterordrelista leser.

Masterordre: NXT-overføring (kø)¶

Nøkkel	Standard	Hva den betyr
`MaxBatch`	`25`	Øvre grense for antall køede overføringer per kjøring (må være > 0). Resten blir stående i køen til neste kjøring
`DebugLogging`	`false`	Detaljert logging, kun for feilsøking

Jobben drenerer køen av tilbud→NXT-salgsordreoverføringer. Køede rader oppstår når et tilbud aksepteres (aksept-bryteren legger overføringen i kø i stedet for å kalle NXT i selve forespørselen) eller via manuelle handlinger. Overføringen er idempotent via overførings-ledgeren — en ny kjøring skaper aldri en ny NXT-ordre for et allerede overført tilbud. Hele funksjonen styres av funksjonsbryteren Subscription.OfferNxtTransfer.Enabled (av som standard): er den av, logger jobben en advarsel («Funksjonen er avslått …») og hopper over radene — kjøringen regnes fortsatt som vellykket.

Bryteren settes ikke i jobbens konfigurasjon, men på Innstillinger → Masterordre → Pipeline-konfigurasjon, i seksjonen «Overføring til Visma Business NXT». Den gjelder per klient. Fram til august 2026 fantes den bare som en rad i wv_SystemConfiguration og måtte settes direkte i databasen.

Delta og sjekkpunkter (NXT-synk)¶

NXT-synk-jobben husker hvor den kom i forrige kjøring via to sjekkpunkter: ett for ordre-importen (LastOrderSyncTimestamp) og ett for observasjons-synken (LastObservationSyncTimestamp).

Normal kjøring: kun ordrer/observasjoner endret etter sjekkpunktet hentes fra NXT — nattkjøringen er derfor rask uansett datamengde.
Budsjettstopp: treffer kjøringen arbeidsbudsjettet (MaxPagesPerRun/MaxRuntimeSeconds), stopper den kontrollert, lagrer fremdriften den har fått skrevet, og fortsetter fra sjekkpunktet ved neste kjøring. Kjøringen regnes fortsatt som vellykket — kjøringsloggen viser en advarsel om at den fortsetter neste gang.
Ingen duplikater: observasjoner settes inn «kun én gang» (nøkkel per NXT-transaksjon), så en overlappende eller gjentatt kjøring skaper aldri doble observasjoner.
Første kjøring (uten sjekkpunkter) er avgrenset av MaxOrders; historikk lenger tilbake hentes ved behov med ObservationBackfillMonths som en manuell engangskjøring.

Tørrkjøring («dry-run») i integrasjonseditoren validerer konfigurasjonen og viser jobbens gjeldende sjekkpunkter uten å kjøre noe.

Manuell kjøring, kjørelås og kjøringshistorikk¶

Kjør nå: enhver av jobbene kan startes manuelt fra Konti Connect — se Kjøre manuelt.
Delt kjørelås: de manuelle handlingene i masterordre-bildene (kjør NXT-import, evaluer datomotor, generer ordreforslag, kjør tilbudspipeline) deler kjørelås med de planlagte jobbene. Starter du en manuell kjøring mens den planlagte kjører (eller omvendt), avvises den med en «kjører allerede»-melding — prøv igjen om litt.
Kjøringshistorikk: hver kjøring logges med status, antall behandlede/vellykkede rader, per-steg-logg (norsk løpende logg) og utløser (manuell / planlagt / API) — se Lese kjøringslogg.
Overvåkning: kjøringene inngår i Konti-admins integrasjonsmonitor på tvers av tenants (med varsling og kvittering/demping av alarmer). Se også Overvåkning og gjenoppretting.

Go-live-runbook: slå av ordre-import (`SyncOrders=false`)¶

Frem til go-live er Visma Business NXT master for masterordrene, og NXT-synk importerer/oppdaterer ordrer. Ved go-live overtar ePortal som master for ordrene — da skal ordre-importen slås av, mens observasjons-synken fortsetter:

Åpne Konti Connect → Integrasjoner → Masterordre: NXT-synk → Rediger.
Sett SyncOrders til false i konfigurasjonen. La SyncObservations stå på true.
Lagre. Neste kjøring henter kun leveringsobservasjoner (delta).
Verifiser i kjøringsloggen at neste kjøring er grønn og bare rapporterer observasjons-steget.

Dette er et bevisst manuelt runbook-steg — bryteren endres aldri automatisk.

Vanlige problemer¶

Problem	Årsak / løsning
«Kjører allerede»-melding ved manuell kjøring	Den planlagte jobben (eller en annen manuell kjøring) holder kjørelåsen. Vent til den er ferdig og prøv igjen.
Advarsel om gammel oppstrøms-kjøring i loggen	NXT-synk (eller datomotoren) har ikke kjørt vellykket innenfor `UpstreamFreshnessHours`. Sjekk oppstrøms-jobbens kjøringshistorikk; kjøringen er ikke stoppet.
Kjøringen stopper med «fortsetter neste kjøring»	Arbeidsbudsjettet (`MaxPagesPerRun`/`MaxRuntimeSeconds`) ble brukt opp. Normalt ved store endringsmengder — neste kjøring fortsetter fra sjekkpunktet. Øk budsjettet ved behov.
Jobben har aldri kjørt	Sjekk at integrasjonen er aktiv, at cron-uttrykket er gyldig, og at typen ble opprettet under kategorien «Interne jobber».
Ordrer oppdateres ikke lenger fra NXT	`SyncOrders` står på `false` (go-live-modus). Det er tilsiktet etter go-live — se runbook-steget over.
Advarsel i serienummer-synken om at en linje ble hoppet over pga. radlås	To skrivere traff samme ordrelinje samtidig (f.eks. planlagt kjøring og en manuell handling). Ingen endringer ble skrevet for linjen; neste kjøring tar den automatisk.
Advarselen «Funksjonen er avslått (Subscription.OfferNxtTransfer.Enabled)» i kø-dreneringens logg	Funksjonsbryteren for tilbud→NXT-overføring er av (standard). Slå den på under Innstillinger → Masterordre → Pipeline-konfigurasjon når overføringen skal aktiveres — kjøringen er ikke feilet, radene blir stående i køen.