Skip to content

Salgsprisen på en vare bliver ved med at blive sat til 0,00

Nogle varer mister deres salgspris igen og igen. En medarbejder skriver prisen ind, og kort efter står varen igen til 0,00. I systemloggen (feltrettelser på varen) ser det typisk sådan ud:

Felt Dato Kl. Bruger Før Efter
Salgspris 11.09.2026 08:16 Scheduler 1167,00 0,00
Salgspris 01.09.2026 11:26 APT 0,00 1167,00
Salgspris 31.08.2026 14:15 Scheduler 1167,00 0,00

Det ser ud som om "Scheduler" nulstiller prisen med ujævne mellemrum — men det er ikke et prisjob der gør det.

Årsag

Varen har feltet "S.pris fra Styk" (salgspris beregnes fra stykliste) sat, men varen har ingen styklistelinjer.

Salgsprisen er i så fald et beregnet felt: den er summen af styklistens linjer. Er der ingen linjer, er summen 0 — og salgsprisen bliver regnet til 0,00 hver gang varekortet bliver skrevet. Det sker ikke kun når man selv redigerer varen, men også automatisk, fx når varen indkøbsfaktureres, hvor systemet opdaterer sidste købspris og købsdato på varekortet.

Derfor følger nulstillingerne indkøbsfakturaerne og ikke et fast tidspunkt, og derfor står der "Scheduler" på dem: det er den automatiske bogføring af leverandørfakturaer (bilagsskanningens autoflow) der udløser dem.

Symptomet rammer kun varer hvor fluebenet er sat uden at der findes en stykliste. Varer med en rigtig stykliste opfører sig korrekt.

Løsning

  1. Åbn varekortet og fjern fluebenet "S.pris fra Styk" — eller opret den stykliste, prisen skulle komme fra.
  2. Skriv salgsprisen ind igen. Nu bliver den stående.

Sådan finder du alle varer med problemet: søg i varelisten efter varer hvor "S.pris fra Styk" er sat og "Stykliste" ikke er sat. De varer får nulstillet prisen næste gang varekortet bliver opdateret — også selvom de lige nu har en korrekt pris.

Rettet fra 2609

Fra version 2609 beregnes salgsprisen kun fra styklisten når varen rent faktisk har en stykliste. En vare med fluebenet sat, men uden styklistelinjer, får ikke længere nulstillet sin salgspris.

Bemærk: opdateringen retter ikke priser der allerede er blevet nulstillet — de skal skrives ind igen. Og fluebenet bør stadig fjernes på de varer hvor det er sat ved en fejl, så opsætningen afspejler virkeligheden.

Internt

FILE Vare, feltet Salgspris, Init():

if Firma.BrugLevListPris then return Vare.LevListPris * (Vare.AvancePctVare + 100) / 100;
if Vare.SPrisFraStykl & Vare.HarStykListe then return Vare.StykListeSalgspris;   // & Vare.HarStykListe tilføjet i 2609
if Vare.AvanceModel == "Salg=Kost+Av" then return Vare.SidsteNettoKøbspris * (Vare.AvancePctVare + 100) / 100;

StykListeSalgspris er sumofrange(StykListe.IaltSalg;StykListe.Varenr;[Vare.VNummer]) — 0 uden linjer.

Skrivningen af varekortet kommer fra TRIGGERVarepost (Kilde == "Købsfaktura"), der åbner Vare i Update og sætter DatoSidsteKøb, SidsteKøbsprisValuta m.fl. Selve nulstillingen er altså ikke en tildeling i et task, men en gen-afledning af Init() når posten skrives. Hos kunder med BS autoflow (BS_AF_AutoFlowBS_AF_IFakturerIFAKTURERORDRE) sker det på jobbets kadence, hvilket forklarer "Scheduler" som bruger og de skæve klokkeslæt.

Til diagnose hos en kunde: grupper varekartoteket på Vare:SPrisFraStykl og Vare:HarStykListe — kombinationen true / false er de ramte varer.