Gå til innhold

Pipeline-konfigurasjon — masterordre

Siden Innstillinger → Masterordre → Pipeline-konfigurasjon samler innstillingene som styrer den automatiske ordreforslag- og brevutsendings-pipelinen (kjøres manuelt eller planlagt). Alle verdiene lagres per klient i wv_SystemConfiguration via SettingsService — de er ikke appsettings og ikke hardkodet. En uendret klient bruker standardverdiene under, og siden viser den gjeldende effektive verdien selv om ingen rad er lagret ennå.

Tilgang

Handling Datatilgang (Subscription.Configuration)
Se siden og lese verdiene Se
Lagre endringer Endre

Menypunktet og siden er fail-closed: uten Se vises verken menypunktet eller innholdet. Backenden (SubscriptionPipelineConfigController) håndhever den samme datatilgangen på hvert endepunkt — tilgangssjekken i grensesnittet er kun en bekvemmelighet.

Innstillinger

Innstilling Nøkkel (wv_SystemConfiguration) Standardverdi Effekt
Standard automatisering Subscription.DefaultProposalAutomation Manual Automatiseringsnivå for ordre uten eget valg: Manuell (ingen auto-produksjon), Auto-produser (produserer tilbud automatisk) eller Auto-produser og send (produserer og sender).
Planleggingshorisont (måneder) Subscription.DefaultPlanningHorizonMonths 3 Hvor mange måneder fram ordreforslag genereres når ordren ikke har egen horisont.
Maks ordreforslag per batch Subscription.MaxSupportLettersPerBatch 200 Tak på antall førstegangs tilbudsbrev som produseres/sendes per pipeline-kjøring.
Maks purringer per batch Subscription.MaxReminderLettersPerBatch 200 Tak på antall purrebrev som sendes per pipeline-kjøring.
Dager før purring Subscription.ReminderDaysAfterOffer 14 Antall dager etter første utsending før en purring blir aktuell.
BCC-arkivadresse Subscription.BccArchiveAddress (tom) Valgfri arkivadresse som legges som BCC på alle utsendte brev. Må være en gyldig e-postadresse når den er satt.
Testmodus Subscription.TestModeEnabled false Når på: alle brev omdirigeres til testadressen i stedet for de reelle mottakerne.
Testadresse Subscription.TestModeEmail (tom) Adressen som mottar alle brev mens testmodus er på. Påkrevd og gyldig når testmodus er på.
Aksept-lenke Subscription.AcceptLinkEnabled true Når på: førstegangsbrev får en selvbetjent aksept-lenke med token.
Gyldighet aksept-lenke (dager) Subscription.AcceptLinkExpiryDays 30 Gyldighetsvindu i dager for et nytt aksept-token / tilbudets utløp.
Offentlig base-URL Subscription.PublicBaseUrl (tom) Når satt (f.eks. https://dinbedrift.eportal.no): aksept-lenken i brev blir en absolutt lenke til den offentlige bekreftelsessiden (stien offer-accept/<token> på basen), der kunden ser tilbudssammendraget og bekrefter med ett klikk — uten innlogging. Tom = gammel relativ lenke (fungerer ikke i e-post). Må være absolutt http(s)-URL uten spørrestreng/fragment. Har en annen rolle også: dokumentmalenes serverside-PDF-generering bruker samme innstilling til å hente virksomhetens logo (se avsnittet «Dokumentmaler» i Brevmaler) — tom verdi betyr da «ingen logo i dokumenter», ikke en feil.
Legg ved tilbuds-PDF i brev Subscription.AttachOfferPdf false Når på: utsendte tilbuds- og purrebrev får den server-genererte tilbuds-PDF-en (dokumentmal-forside + dokumenter merket «ta med i PDF») som e-postvedlegg. Krever en aktiv dokumentmal. Feiler PDF-genereringen sendes brevet uten vedlegg (brevet blokkeres aldri), og årsaken logges.
Overfør aksepterte tilbud til Visma Business NXT Subscription.OfferNxtTransfer.Enabled false Skriver til kundens produksjonsmiljø. Når på: overføringsvalgene blir tilgjengelige, og et tilbud som noen aktivt velger å overføre legges i køen, der den interne jobben Masterordre: NXT-overføring (kø) oppretter salgsordren i Visma Business NXT. Bryteren køer altså ikke aksepterte tilbud av seg selv. Styres av datatilgangen «Go-live-brytere», se avsnittet under.

Overføring til Visma Business NXT

Bryteren Overfør aksepterte tilbud til Visma Business NXT står i sin egen seksjon nederst på siden, med en synlig advarsel. Den er den eneste innstillingen på siden som starter skriving mot et eksternt produksjonssystem, og derfor:

  • Standard er av. En tenant som aldri har lagret nøkkelen leser den som false — en manglende rad betyr «av», aldri «på».
  • Er den av, rapporterer hver overføring utfallet Disabled uten å kontakte NXT, og kø-jobben logger advarselen «Funksjonen er avslått (Subscription.OfferNxtTransfer.Enabled)» — kjøringen regnes fortsatt som vellykket.
  • Overføringen er idempotent via overførings-ledgeren: et tilbud som allerede er overført får aldri en ny NXT-ordre, uansett hvor mange ganger jobben kjører.
  • Slår du bryteren av igjen, blir allerede køede rader stående i køen til den slås på på nytt. Salgsordrer som alt er opprettet i NXT må ryddes manuelt der.
  • Å slå den på køer ingenting i seg selv. Aksepteringsdialogen nullstiller overføringsvalget, så et tilbud havner først i køen når noen krysser av for overføring. Bryteren styrer om det valget i det hele tatt er tilgjengelig.

Slå den på først når NXT-selskapsnummer, ordretype og kontoplan er verifisert mot kundens oppsett.

Hvem kan slå den på

Bryteren styres av datatilgangen «Go-live-brytere (produksjonsskriving)» (Subscription.GoLiveSwitch). Fra 2026-08-16 er den seedet med redigeringstilgang for alle brukernivåer, så en vanlig administrator kan slå bryteren på uten at noen først deler ut en egen rettighet. Tidligere krevde den en manuell tildeling; det gjør den ikke lenger.

Rettigheten er likevel et eget håndtak: du kan trekke den fra et brukernivå under Innstillinger → Datatilgang uten å ta bort redigeringstilgangen til resten av pipeline-innstillingene. Det er grunnen til at den er en egen objekttype — Subscription.Configuration er seedet for hvert eneste brukernivå og kan derfor ikke brukes til å styre denne bryteren separat.

Rettigheten er fortsatt fail-closed når selve raden eller hele tilgangstabellen wv_DataAccess mangler. For vanlige objekttyper gir en manglende tabell full tilgang, slik at en tenant ikke låses ute mens den settes opp; for de fail-closed typene — inkludert denne — nektes tilgangen i stedet. Seedingen endrer standardverdien, ikke hva som skjer når raden er borte.

Å slå bryteren AV krever ingen tilgang. Asymmetrien er tilsiktet og går i sikker retning: tilgangen finnes for å hindre at produksjonsskriving startes, og ingenting beskyttes av å gjøre det vanskeligere å stanse den. En tenant skal aldri bli stående med skriving mot produksjon fordi et tilgangsoppslag svarer nei eller er utilgjengelig. Bryteren er derfor operabel i av-retning selv uten tilgangen, og brukere uten tilgangen ser en forklaring under bryteren i stedet for en kontroll som bare feiler.

Bryteren lagres for seg selv, ikke sammen med resten av skjemaet, og du blir bedt om å bekrefte før den slås på. Bekreftelsen navngir både hvilken kunde endringen gjelder og hvilket NXT-selskap salgsordrene vil havne i, siden siden ser lik ut for alle tenanter. Er bare det ene kjent, navngis det: kan ikke selskapsnummeret slås opp akkurat da — for eksempel fordi NXT-integrasjonen ikke er satt opp — navngis kunden alene, og mangler kundenavnet navngis selskapsnummeret alene. At selskapsnummeret ikke kunne slås opp betyr ikke at noe selskap mangler. Er ingen av delene kjent, står bare konsekvensteksten. Har noen andre endret bryteren mens siden din var åpen, avvises endringen og verdien oppdateres til den som faktisk gjelder — slik at en gammel skjemalagring aldri kan slå den på igjen i det stille. Sammenlikningen gjøres av databasen i samme transaksjon som skrivingen, så to samtidige endringer kan ikke begge slippe gjennom og overskrive hverandre.

Bryteren kan bare settes fra denne siden. Det generiske systemkonfigurasjons-API-et avviser nøkkelen Subscription.OfferNxtTransfer.Enabled, slik at en administrator uten go-live-tilgangen ikke kan omgå bekreftelsen og tilgangskravet ved å skrive nøkkelen direkte.

Når bryteren slås av, får ingen overføring som ikke allerede er påbegynt lov til å skrive til NXT. Overføringsjobben leser bryteren direkte fra databasen — ikke fra en mellomlagret verdi — både når et forsøk starter og på nytt i samme databasetransaksjon som selve skrivestartet. Den siste lesingen er den bindende: den og av-skrivingen står i kø for hverandre i databasen, så en overføring som ennå ikke har passert skrivestartet blir stanset og blir liggende i kø til bryteren eventuelt slås på igjen.

Det som ikke loves, er at ingenting er underveis i det øyeblikket du får «lagret». En overføring som allerede har passert skrivestartet, fullfører sin NXT-skriving — den er da bare et kall unna. I praksis betyr det at ett enkelt forsøk per pågående overføring kan fullføres etter at bryteren er slått av. Ønsker du å bekrefte at alt har stanset, sjekk overføringslisten for rader som står som underveis.

Fram til august 2026 fantes bryteren bare som en rad i wv_SystemConfiguration og måtte settes direkte i databasen; nå settes den her.

Validering

Grensesnittet validerer inline og blokkerer lagring til alt er gyldig; backenden gjentar de samme sjekkene som et sikkerhetsnett:

  • Batch-tak, purredager, gyldighet og planleggingshorisont må være positive heltall innenfor fornuftige grenser.
  • BCC-arkivadressen må være en gyldig e-postadresse når den er utfylt.
  • Testadressen må være en gyldig e-postadresse, og er påkrevd når testmodus er på.
  • Automatiseringsnivået må være ett av Manual, AutoProduce, AutoProduceAndSend.
  • Offentlig base-URL må være en absolutt http(s)-URL uten spørrestreng/fragment når den er utfylt.

Når trer endringen i kraft

Lagring oppdaterer wv_SystemConfiguration og tømmer innstillings-cachen for hver nøkkel, slik at neste pipeline-kjøring leser de nye verdiene umiddelbart.

Vanlige problemer

Problem Årsak Løsning
Menypunktet «Pipeline-konfigurasjon» mangler Brukeren har ikke Se på Subscription.Configuration Gi datatilgang under Innstillinger → Datatilgang → Abonnement
«Lagre» er deaktivert Ett eller flere felt er ugyldige Rett de røde feltene; feilmeldingen står under feltet
Testadresse-feil ved lagring Testmodus er på uten en gyldig adresse Fyll inn en gyldig testadresse, eller slå av testmodus

Referanser i koden

  • Grensesnitt: ui/ePortal.ui/src/app/components/setting/portal-setting/masterorder-pipeline-config/
  • Backend: api/ePortal.API/ePortal.API/Controllers/SubscriptionPipelineConfigController.cs
  • Nøkler + validering: api/ePortal.API/ePortal.Base/Models/Subscription/SubscriptionPipelineConfigDto.cs