Release note 3.34

Ændret den Wed, 24 Jun kl. 3:55 PM

INDHOLDSFORTEGNELSE

Ny indstilling: Hent shippinglabel automatisk efter pluk
Retur: Sprogoversættelser på produkter og returportal
Lageropsætning: Vælg flere lokationer og reoler på én gang
Stregkodescanning med GS1-koder virker nu ens i alle værktøjer
Manuel pak under pluk: Ny "Parkér"-mulighed ved manglende varer
Genopfyldning: Færre duplikerede opgaver og mulighed for at samle pluk
Cross-docking: Vælg antal labels og angiv forsendelsesmål
Modtagelse: Import af serienumre via filupload
AutoStore
OpenAPI
Performance opdateringer
Øvrige opdateringer
Bugfixes

Forventet release dato: 24 juni 2026

Ny indstilling: Hent shippinglabel automatisk efter pluk

Der er kommet en ny valgmulighed for, hvornår forsendelseslabels hentes fra fragtmanden: "Ordre plukket".

Med denne indstilling hentes labelen automatisk i baggrunden, lige så snart en ordre er færdigplukket. Det betyder, at labelen i de fleste tilfælde allerede er klar, når pakkemedarbejderen scanner ordren ved pakkestationen – og pakkeren slipper for at vente på, at labelen bliver hentet.

Hvordan virker det i praksis?

Plukkeren mærker ingen forskel – plukket afsluttes som normalt, og labelen hentes i baggrunden uden forsinkelse.
Pakkemedarbejderen scanner ordren ved pakkestationen. Hvis labelen er klar, fortsætter pakningen med det samme. Hvis labelen stadig er ved at blive hentet, vises en besked om at scanne igen om et øjeblik.
Hvis noget går galt med den automatiske hentning, henter systemet selv labelen som en reserve – så pakningen aldrig går i stå.

Hvornår er denne indstilling relevant?
Indstillingen er velegnet til fragtprodukter, hvor der ikke skal vejes eller måles ved pakningen. Bruger I fragtprodukter, der kræver vægt eller mål ved pakning, f.eks. fragtmetoder, der bruges til lande, hvor told er påkrævet, bør I fortsat bruge indstillingen for labelhentning i "Pak".

Indstillingen aktiveres af en administrator under fragtmetodens opsætning.

Retur: Sprogoversættelser på produkter og returportal

Hvis I sender varer til kunder i andre lande, har I måske oplevet, at produktbeskrivelser og tekster i returportalen kun blev vist på det sprog, produktet oprindeligt er oprettet med. En tysk slutkunde, der åbnede returportalen, kunne f.eks. se alle produktnavne på dansk.

Nu kan I oprette sprogoversættelser pr. land for produkter samt tilpasse alle tekster i returportalen til det relevante sprog.

Produktoversættelser
I kan oprette oversættelser af produktfelter (varenummer, beskrivelse, mærke, størrelse og farve) pr. landekode. Oversættelserne kan vedligeholdes på tre måder:

I PeakWMS – via en ny oversættelsesdialog direkte på produktet (Produktovesættelser).
Via Excel-import – upload af en fil med oversættelser, som matcher på varenummer og landekode. Eksisterende oversættelser opdateres, nye oprettes.
Via OpenAPI – et nyt OpenAPI-endpoint til oprettelse og hentning af oversættelser, så det kan integreres med jeres ERP eller PIM-system.

Når en oversættelse findes for det relevante land, bruges den automatisk:

På følgesedlen – produktbeskrivelser vises på modtagerlandets sprog.
I returportalen – slutkunden ser produktnavne og beskrivelser på det korrekte sprog.

Hvis der ikke er oprettet en oversættelse for det pågældende land, vises de originale værdier som hidtil.

Returportal-tekster
Alle UI-tekster i returportalen (knapper, overskrifter, info-tekster m.m.) kan nu oversættes pr. returportal. En administrator finder den nye sektion "Oversættelser" under returportalens indstillinger, hvor de originale tekster vises sammen med et felt til oversættelsen. Tomme felter beholder standardteksten.

Derudover er billedvisningen i returportalen forbedret, så alle produktbilleder nu vises i en ensartet, firkantet størrelse – for et pænere og mere konsistent udseende.

Lageropsætning: Vælg flere lokationer og reoler på én gang

I lageropsætningen (Warehouse editor) har det hidtil kun været muligt at arbejde med én lokation eller én reol ad gangen. Hvis I f.eks. ville flytte en hel række reoler til et andet sted i lageropbygningen, skulle hver enkelt reol markeres, flyttes og placeres individuelt – hvilket var tidskrævende ved større ændringer i lageropsætningen.

Hvad er nyt?
Nu kan I vælge flere lokationer og/eller reoler samtidig og derefter flytte eller kopiere dem samlet:

Multivælg – marker flere lokationer eller reoler i lageropsætningen på én gang.
Flyt – flyt hele den valgte gruppe til en ny placering i området.
Kopiér – kopiér de valgte lokationer/reoler, f.eks. for hurtigt at oprette en identisk sektion et andet sted på lageret.

Det gør det væsentligt hurtigere at opbygge og tilpasse lagerstrukturen – især ved større ombygninger, udvidelser eller ved opsætning af nye lagre.

Stregkodescanning med GS1-koder virker nu ens i alle værktøjer

Hvis I bruger GS1-stregkoder (f.eks. GS1-128 eller GS1 DataMatrix) på jeres varer, kunne der tidligere opstå en fejl, hvor systemet afviste stregkoden ved pakning, indlagring eller lagerflyt – selvom den samme stregkode fungerede fint ved pluk.

Det skyldtes, at systemet i nogle arbejdsgange sammenlignede den scannede kode direkte med den gemte stregkode, uden først at "oversætte" GS1-formatet korrekt. Det er nu rettet, så GS1-stregkoder behandles ens i alle arbejdsgange: pluk, pak, indlagring, lagerflyt og genopfyldning.

Almindelige stregkoder (uden GS1-format) fungerer præcis som før.

Manuel pak under pluk: Ny "Parkér"-mulighed ved manglende varer

Når en lagermedarbejder plukker en ordre manuelt med plukkeprocessen "Manuel pak under pluk" og opdager, at en eller flere varer mangler på lageret, har der hidtil kun været to muligheder: enten at sende det, der blev plukket, eller at lægge det hele tilbage.

Nu er der kommet en tredje mulighed: Parkér ordren. Det betyder, at de allerede plukkede varer sættes til side på en parkeringsplads på lageret med en printet parkeringslabel, mens systemet automatisk opretter en ny plukkeopgave for de manglende varer. Når de manglende varer senere er tilgængelige og plukket, bliver medarbejderen automatisk bedt om at samle de to dele, så ordren kan pakkes og sendes som én samlet forsendelse.

Kort sagt: I behøver ikke længere vælge mellem at sende en ufuldstændig ordre eller starte helt forfra – ordren kan nu parkeres og færdiggøres, når varerne er klar.

OBS! Funktionen her er kun relevant for plukkegrupper, der benytter "manuel pak under pluk", hvor pluk og pak foretages i samme proces.

Genopfyldning: Færre duplikerede opgaver og mulighed for at samle pluk

Genopfyldningsberegningen er blevet forbedret på tre områder:

1. Højere prioritet går først
Hvis en vigtig genopfyldningskonfiguration har brug for varer, som allerede er reserveret til en mindre vigtig opgave, kan systemet nu automatisk flytte reservationen til den vigtigste opgave. Tidligere kunne vigtige opgaver stå uopfyldte, selvom varerne faktisk var på lager – de var bare reserveret til en opgave med lavere prioritet.

2. Færre dobbeltopgaver
Når systemet genberegner genopfyldningsbehov og finder, at en eksisterende – endnu ikke påbegyndt – opgave allerede dækker det samme behov, øges den eksisterende opgaves antal i stedet for at oprette en ny opgave. Det giver et mere retvisende billede på dashboardet over det reelle antal genopfyldningsopgaver.

3. Nyt ikon ved pluk: Se og overtag andre genopfyldningsopgaver
Når en lagermedarbejder plukker en genopfyldningsopgave, vises nu et ikon, hvis der er andre ubesatte genopfyldningsopgaver for den samme beholdning på lageret. Medarbejderen kan klikke på ikonet for at se en liste over disse opgaver og vælge at overtage dem – så de kan plukkes i samme ombæring. Systemet sikrer, at to medarbejdere ikke kan overtage den samme opgave samtidig.

Cross-docking: Vælg antal labels og angiv forsendelsesmål

Når en vare cross-dockes, har det hidtil kun været muligt at oprette enten én label for hele mængden – eller én label pr. styk (ved pick-alone-varer). I har ikke haft indflydelse på, hvor mange labels (og dermed plukkeordrer) der blev oprettet, og det har ikke været muligt at angive forsendelsesmål (bredde, længde, højde og vægt) allerede ved cross-docking.

Hvad er nyt?

Cross-docking-flowet har nu et nyt felt "Antal labels", hvor lagermedarbejderen kan angive, hvor mange labels, der ønskes for ordrelinjen. PeakWMS fordeler mængden så jævnt som muligt på tværs af de valgte labels.

Eksempel: 7 styk fordelt på 3 labels giver fordelingen 3, 2, 2.

For hver label kan der desuden angives forsendelsesmål (bredde, længde, højde og vægt). Hvis målene ikke udfyldes, beregnes de automatisk ved labelprintning – præcis som hidtil.

I praksis:

Medarbejderen scanner en indgående varelinje, der kvalificerer til cross-docking.
Cross-docking-dialogen viser et felt til antal labels (standard: 1).
Ændres antallet, vises én række pr. label med den fordelte mængde og valgfrie mål-felter.
Ved bekræftelse oprettes én plukordre pr. label med den korrekte mængde og eventuelle forsendelsesmål.

Pick-alone-varer: Antal labels er låst til den samlede mængde (én label pr. styk) og kan ikke ændres – præcis som hidtil.

OBS! Flowet fungerer så snart cross docking er slået til under Indstillinger > Varemodtagelse/Indlagring.

Modtagelse: Import af serienumre via filupload

Ved modtagelse af varer med serienummerregistrering har lagermedarbejderen hidtil skullet scanne hvert serienummer individuelt – ét ad gangen. Ved store leverancer med 100+ enheder er det en tidskrævende proces, der nemt kan tage lang tid og øger risikoen for scanningsfejl.

Hvad er nyt?
Serienumre kan nu importeres via en tekstfil direkte i worker-appens varemodtagelsesflow. En ny importknap i headeren åbner en filvælger, hvor medarbejderen kan vælge en .txt- eller .csv-fil med ét serienummer pr. linje.

Sådan fungerer det:

Medarbejderen er på serienummer-skærmen under modtagelse og trykker på import-knappen.
En filvælger åbner – medarbejderen vælger en tekstfil med serienumrene.
Systemet tjekker, at antallet af serienumre i filen matcher det resterende antal (dvs. det totale antal minus allerede scannede). Passer det ikke, vises en fejlbesked.
Serienumrene valideres i backend: format (regex), om de allerede er på lager, og om der er dubletter i filen.
Alt-eller-intet: Enten accepteres hele filen, eller den afvises med en fejlbesked, der viser op til 20 ugyldige serienumre med årsagskode.
Ved succes opdateres tælleren (f.eks. 100/100), og medarbejderen kan trykke "Registrér".

Detaljer:

Reimport: Har medarbejderen allerede importeret en fil, kan en ny fil importeres – den erstatter de tidligere importerede serienumre. Manuelt scannede serienumre bevares.
Kombination: Medarbejderen kan scanne nogle serienumre manuelt og importere resten via fil. Fil-importen behøver kun at indeholde det resterende antal.
Performance: Importerede serienumre vises ikke enkeltvis i listen – kun det samlede antal opdateres. Det sikrer, at appen forbliver hurtig, selv ved store filer.
Filformat: Ren tekst (UTF-8), én linje pr. serienummer. Tomme linjer og whitespace ignoreres automatisk.
Kun modtagelse: Importknappen er kun tilgængelig under modtagelse – ikke ved returnering.

AutoStore

Alle stregkoder sendes nu med ved produktimport

Hvis en vare har flere stregkoder (EAN-numre) registreret i PeakWMS – f.eks. fordi varen findes i forskellige pakningsstørrelser – bliver alle stregkoder nu automatisk sendt med til Autostore-systemet.

Tidligere blev kun én stregkode overført, hvilket kunne betyde, at Autostore ikke genkendte varen ved scanning af en anden stregkode. Med denne rettelse sikrer vi, at alle registrerede stregkoder følger med, så varen altid kan identificeres korrekt i Autostore – uanset hvilken stregkode der scannes.

Ordrer sendes nu korrekt til automationsystemet ved genberegning af plukgrupper

Når plukgrupper genberegnes – enten manuelt eller automatisk – kan ordrer, der endnu ikke er begyndt at blive plukket, flytte fra én plukgruppe til en anden. Hvis en ordre på den måde blev flyttet til en automationsplukgruppe (f.eks. Autostore), blev automationsystemet tidligere ikke informeret om ordren. Det betød, at ordren blev "strandet" – den lå og ventede i automationsplukgruppen, men automationsystemet vidste ikke, den var der, og den blev derfor aldrig plukket.

Nu sørger systemet automatisk for at sende ordren til automationsystemet, når den flyttes til en automationsplukgruppe ved genberegning – præcis som det allerede sker, når en ordre frigives direkte til en automationsplukgruppe.

Ordrer, der allerede er i gang med at blive plukket eller pakket, berøres ikke af ændringen.

Plukkedato baseres nu på planlagt afsendelsesdato

Når ordrer sendes til Autostore til pluk, blev plukkedatoen tidligere sat ud fra ordrens bestillingsdato. Det betød, at Autostore ikke nødvendigvis plukkede ordrerne i den rækkefølge, de rent faktisk skulle afsendes.

Nu bruges i stedet ordrens planlagte afsendelsesdato som plukkedato. Det sikrer, at Autostore prioriterer ordrerne ud fra, hvornår de faktisk skal sendes – og ikke hvornår de blev bestilt.

Ordrer med samme afsendelsesdato plukkes stadig i den rækkefølge, de er bestilt, så den ældste ordre altid plukkes først inden for samme dag.

Hvis en ordre ikke har en planlagt afsendelsesdato, efterlades plukdatoen tom, og Autostore håndterer den efter sine egne standardregler.

Varemodtagelse: Fejlbesked ved scanning af automationslastbærer vises nu på dansk

Når en lagermedarbejder ved varemodtagelse scanner en lastbærer, der allerede indeholder varer og står på en lokation, som bruges af et automationsystem (f.eks. AutoStore), blokerer systemet korrekt for handlingen. Fejlbeskeden blev dog altid vist på engelsk – uanset hvilket sprog medarbejderen bruger i appen. Det kunne skabe forvirring, især i opstartsfasen, hvor medarbejdere endnu ikke har lært, hvilke lastbærere der tilhører automationsområdet.

Nu vises fejlbeskeden på medarbejderens valgte sprog – herunder dansk og norsk – og den nævner konkret, hvilken lastbærer og lokation det drejer sig om. F.eks.:

"Lastbærer LC-1234 står på lokation A-01-02, som bruges til automation-integration og kan ikke bruges til varemodtagelse."

Det gør det lettere for medarbejderen hurtigt at forstå situationen og scanne en korrekt lastbærer i stedet.

Ordredato og -tidspunkt sendes nu med til AutoStore

Når en udgående ordre sendes til AutoStore som en plukliste (picklist), har plukkedato- og plukketidspunkt-felterne (ExtPickDate og ExtPickTime) hidtil været tomme. AutoStore havde dermed ingen dato/tidsreference for den pågældende plukkeliste – hvilket begrænsede mulighederne for at prioritere ordrer korrekt i eManager og AutoStore-systemet.

Hvad er nyt?
Plukkelisten, der sendes til AutoStore, indeholder nu ordrens dato og tidspunkt – hentet fra den udgående ordres ordredato (OrderDateTime).

Sådan fungerer det:

Ordren har en ordredato: Plukkedato (ExtPickDate) og plukketidspunkt (ExtPickTime) udfyldes automatisk ud fra ordrens dato og tid. Derudover vises ordredatoen i et læsevenligt format i AutoStore-interfacet (Info2-feltet), så operatøren kan se ordrens dato og klokkeslæt under pluk.
Ordren har ingen ordredato: Plukkedato, plukketidspunkt og Info2 forbliver tomme – præcis som hidtil.

Ændringen giver AutoStore og eManager mulighed for at bruge ordredatoen til at prioritere ordrer – f.eks. så ældre ordrer plukkes først – og giver operatøren bedre synlighed over, hvilken ordre der arbejdes på.

OpenAPI

OpenAPI: Produktopdatering (Patch) via OpenAPI: Nyt endpoint til delvise ændringer

Hvis I bruger PeakWMS' OpenAPI til at opdatere produkter, er der kommet et nyt endpoint, som gør det muligt kun at sende de felter, I ønsker at ændre – uden at skulle medsende alle øvrige produktoplysninger.

Tidligere krævede opdateringsendpointet, at alle produktfelter blev sendt med, også dem der ikke skulle ændres. Med det nye endpoint kan I f.eks. nøjes med at sende en ny pris eller en ny beskrivelse, og resten af produktets oplysninger forbliver uændrede.

Hvad betyder det i praksis?

Integrationer, der opdaterer produkter, bliver enklere og mere sikre – der er mindre risiko for ved et uheld at overskrive felter, man ikke ønskede at ændre.
Det gamle endpoint virker stadig, men er markeret som forældet og vil på sigt blive udfaset

Denne ændring er kun relevant, hvis I har en integration, der opdaterer produkter via PeakWMS' OpenAPI. Den daglige brug af PeakWMS er ikke påvirket.

OpenAPI: Hurtigere oprettelse og opdatering af indkøbsordrer via OpenAPI

Når en indkøbsordre (purchase order) med mange linjer sendes ind til PeakWMS via en integration, kunne det tidligere tage unødigt lang tid. Systemet slog hver enkelt varelinje op én ad gangen – så en indkøbsordre med f.eks. 80 linjer krævede op til 100 individuelle opslag i databasen.

Nu samles alle varesøgninger og udføres i én samlet forespørgsel pr. type (varenummer, stregkode osv.), uanset hvor mange linjer ordren indeholder. Det giver en markant hurtigere behandling af indkøbsordrer – især for kunder med store ordrer med mange varelinjer.

Ændringen sker under motorhjelmen og påvirker ikke den måde, integrationen bruges på. Alt fungerer som før, bare hurtigere.

OpenAPI: Hurtigere håndtering af indkøbsordrelinjer via API

Når en indkøbsordre med mange linjer opdateres via en integration, kunne systemet tidligere være langsomt, fordi hver enkelt linje blev slået op i databasen én ad gangen. Ved en indkøbsordre med f.eks. 50 linjer betød det lige så mange individuelle databaseopslag.

Nu håndteres alle linjer samlet i hukommelsen i stedet for at slå dem op enkeltvis. Det giver en markant hurtigere behandling – især ved større indkøbsordrer med mange varelinjer.

Ændringen sker under motorhjelmen og påvirker ikke den måde, integrationen bruges på. Alt fungerer som før, bare hurtigere.

Denne forbedring gælder kun for indkøbsordrer modtaget via OpenAPI-integrationen. Andre integrationer (f.eks. Business Central, Stocky og Uniconta) er ikke berørt.

OpenAPI: Planlagt afsendelsesdato kan nu opdateres og ryddes på eksisterende ordrer

Når en ordre med en planlagt afsendelsesdato (planned shipping date) blev oprettet via OpenAPI-integrationen, kunne datoen ikke efterfølgende ændres eller fjernes:

Ved en fuld opdatering (PUT) blev den planlagte afsendelsesdato ignoreret – ordren beholdt den oprindelige dato, uanset om opdateringen indeholdt en ny dato eller slet ingen dato.
Ved en delvis opdatering (PATCH) kunne datoen ændres til en ny dato, men den kunne ikke ryddes – sendte man en tom værdi, forblev den gamle dato.

Det var problematisk for kunder, der bruger den planlagte afsendelsesdato til at prioritere ordrer – f.eks. i AutoStore-integrationer, hvor datoen styrer rækkefølgen af ordrer, der endnu ikke er en del af en plukbølge. Integrationen havde simpelthen ikke mulighed for at ændre eller fjerne datoen efter oprettelse.

Hvad er rettet?

Fuld opdatering (PUT): Den planlagte afsendelsesdato i opdateringen gemmes nu altid på ordren. Indeholder opdateringen ingen dato, ryddes den – i overensstemmelse med den erstatningslogik, der allerede bruges for andre felter (f.eks. følgeseddelkommentarer).
Delvis opdatering (PATCH): Datoen kan nu både ændres til en ny værdi og ryddes ved at sætte den til null.

Ændringen gælder kun for ordrer opdateret via OpenAPI-integrationen. Andre integrationer (webshop, ERP m.fl.) er ikke berørt – opdateringer, der ikke indeholder feltet, rydder det heller ikke.

OpenAPI: Følgeseddelkommentar kan nu sættes via salgsordrer

Lagre, der integrerer med PeakWMS via OpenAPI-salgsordrer, har hidtil ikke kunne sætte følgeseddelkommentaren (delivery note comment) på en udgående ordre. Følgeseddelkommentaren er den fritekstbesked, der printes på følgesedlen – f.eks. information til chaufføren under levering ("Ring til kundens mobil ved ankomst", "Levér ved bagindgangen" o.l.). Kommentaren kunne kun skrives manuelt inde i PeakWMS, selvom følgesedlen allerede understøttede og viste den.

Hvad er nyt?
Salgsordre-endpointet (OpenAPI) har nu et nyt felt: DeliveryNoteComment – en valgfri fritekststreng (maks. 2.000 tegn), der gemmes på den udgående ordre og printes på følgesedlen præcis som en manuelt indtastet kommentar.

Sådan fungerer det:

Oprettelse (POST): Angiv en følgeseddelkommentar ved oprettelse af en salgsordre – kommentaren gemmes på den udgående ordre og vises på følgesedlen.
Fuld opdatering (PUT): Kommentaren erstattes med den leverede værdi. Udelades feltet, ryddes kommentaren – i overensstemmelse med øvrige kommentarfelters adfærd ved fuld opdatering.
Delvis opdatering (PATCH): Kun følgeseddelkommentaren opdateres – øvrige felter forbliver uændrede. En tom værdi rydder kommentaren, og udelades feltet, bevares den eksisterende kommentar.
Læsning (GET): Følgeseddelkommentaren returneres ved læsning af salgsordrer – både på enkeltordre- og listeendpointet – så hostsystemet kan verificere den gemte værdi.
Validering: Kommentarer over 2.000 tegn afvises med en valideringsfejl og gemmes ikke.

Feltet er valgfrit – ordrer uden en følgeseddelkommentar fungerer præcis som hidtil.

OpenAPI: Lange svartider ved oprettelse og opdatering af indkøbsordrer er elimineret

Kunder med mange indkøbsordrelinjer – eller ordrer med forventede leveringsdatoer og pre-order-linjer på hold – oplevede ekstremt lange svartider ved oprettelse og opdatering af indkøbsordrer (Purchase Orders) via OpenAPI. Svartider på over 100 sekunder var ikke ualmindelige, og i værste fald kunne selv en ordre med blot 28 linjer tage op til 167 sekunder at behandle.

Problemet ramte endpoints POST /api/integration/v1/purchaseOrder og PUT /api/integration/v1/purchaseOrder/{id} – mens andre API-endpoints fungerede med normal hastighed.

Hvad skete der?
Opdateringen af indkøbsordrer gennemførte unødvendigt tunge operationer pr. linje – herunder gentagne databaseopslag og beregninger, der skalerede dårligt med antallet af linjer. Ordrer med mange linjer, forventede leveringsdatoer og pre-order-status forstærkede problemet yderligere, da hver linje udløste ekstra valideringer og statusberegninger.

Hvad er rettet?
Oprettelses- og opdateringsprocessen for indkøbsordrer er optimeret, så svartiderne er markant reduceret – også for ordrer med flere hundrede linjer. De tunge operationer er strømlinet, så behandlingstiden ikke længere vokser uforholdsmæssigt med antallet af linjer.

Rettelsen gælder både POST (oprettelse) og PUT (opdatering) af indkøbsordrer via OpenAPI.

OpenAPI: Plukket serienummer, holdbarhedsdato og lotnummer er nu tilgængelige på plukordrelinjer

Integrationspartnere, der henter plukordrer via OpenAPI-endpointet GET /api/integration/v1/salesOrder/{hostId}/pickOrder, har hidtil ikke kunnet se, hvilket serienummer, hvilken holdbarhedsdato (BBD) eller hvilket lotnummer der faktisk blev plukket for den enkelte pluklinje. Dataen blev registreret internt i PeakWMS ved pluk, men var ikke eksponeret i API-responset.

Det betød, at integrationspartnere – f.eks. ERP-systemer eller sporbarhedsløsninger – ikke kunne modtage de faktisk plukkede værdier automatisk, men var afhængige af manuelle opslag eller alternative kanaler for at opnå fuld sporbarhed.

Hvad er nyt?

Plukordrelinjer (SalesOrderPickOrderLine) i API-responset indeholder nu tre nye felter:

PickedSerialNumber – det serienummer, der blev registreret ved pluk af den pågældende linje.
PickedBestBeforeDate – holdbarhedsdatoen på den plukkede beholdning.
PickedLotNumber – lotnummeret på den plukkede beholdning.

Detaljer:

Nullable felter: Alle tre felter er valgfrie og returnerer null for varer, der ikke er serienummer-, BBD- eller lot-styrede – præcis som forventet.
Arkiverede plukordrer: Felterne er også tilgængelige på arkiverede plukordrelinjer – så historiske ordrer returnerer de korrekte plukkede værdier.
Bagudkompatibelt: De nye felter er additive og nullable – eksisterende integrationer, der ikke bruger felterne, påvirkes ikke.
Ingen konfiguration nødvendig: Felterne vises automatisk i API-responset og er dokumenteret i Swagger.

Performance opdateringer

Ordrer: Hurtigere generering af følgesedler og ordredokumenter

Hvis en webshops logo var i meget høj opløsning, kunne det tage lang tid at generere ordredokumenter som f.eks. følgesedler. I nogle tilfælde kunne det tage op til 5 sekunder pr. dokument.

Vi har nu optimeret håndteringen af billeder, så selv store logoer behandles hurtigt. Det betyder en mærkbart hurtigere dokumentgenerering i det daglige arbejde.

Beholdning: Hurtigere produktsøgning

Søgning efter produkter i beholdning – f.eks. via stregkode, varenummer eller beskrivelse – er nu markant hurtigere. Vi har optimeret den måde, systemet henter søgeresultater på, så svartiden er reduceret betydeligt.

I praksis betyder det, at når I søger efter et produkt i PeakWMS, vil resultatet komme frem næsten øjeblikkeligt i stedet for at I skal vente i op til flere sekunder.

Indkøbsbehov: Beregning er nu hurtigere og mere stabil

Når indkøbsbehov blev genberegnet for en kunde med mange varer, kunne systemet fryse eller fejle – især hvis kunden havde et stort antal eksisterende indkøbslinjer. Fremskridtsbjælken viste 100%, men systemet arbejdede stadig i baggrunden med at slette de gamle beregninger, hvilket kunne tage meget lang tid eller helt time ud.

Dette er nu løst ved en ny tilgang: I stedet for at slette alle gamle indkøbsbehov før en ny beregning, oprettes de nye resultater med det samme, og oprydningen af gamle data sker automatisk i baggrunden. Det betyder:

Beregningen føles hurtigere, fordi I ikke længere venter på, at gamle data bliver slettet først.
Færre fejl og timeouts, selv for kunder med meget store varesortimenter.
Oprydning sker automatisk – I behøver ikke gøre noget.

Lageværdirapport: Hurtigere beregning af lagerbalancen

Beregningen af den økonomiske lagerbalance pr. dato er nu blevet optimeret, så rapporten genereres markant hurtigere end tidligere. Især ved lagre med mange varer og lagerbevægelser vil I opleve en kortere ventetid, når I trækker lagerværdirapporten.

StockAdjust: Forbedret ydeevne ved lagerjusteringer af bundle-produkter

Når en ordre med bundle-produkter blev oprettet eller opdateret, skulle systemet afstemme beholdningen for alle tilknyttede produkter. Tidligere blev hvert enkelt produkt hentet fra databasen ét ad gangen. Ved kunder med mange bundle-produkter kunne det resultere i hundredvis af individuelle databasekald – hvilket gjorde processen unødigt langsom og ressourcetung.

Nu hentes alle relaterede podukter samlet i én forespørgsel, og de efterfølgende lagerjusteringer sendes ligeledes som én samlet handling i stedet for enkeltvis. Det giver en markant hurtigere behandling – især for kunder med mange bundle-produkter i sortimentet.

Ændringen sker under motorhjelmen og påvirker ikke funktionaliteten. Beholdninger opdateres præcis som før, bare væsentligt hurtigere.

Øvrige opdateringer

Tabelindstillinger: "Vis alle" og "Skjul alle" kolonner med ét klik

Mange tabeller i PeakWMS' admin-dialoger giver mulighed for at vælge, hvilke kolonner der skal vises og skjules. Hidtil har det krævet, at administratoren klikkede på hver enkelt kolonne individuelt for at flytte den mellem "Synlige kolonner" og "Skjulte kolonner". Ved tabeller med mange kolonner var det en tidskrævende proces – især hvis man ønskede at starte fra bunden og kun vise et par udvalgte kolonner.

Hvad er nyt?
Kolonnevælgeren i tabelindstillingerne har nu to nye knapper:

Vis alle – flytter alle skjulte kolonner til listen over synlige kolonner med ét klik.
Skjul alle – flytter alle synlige kolonner til listen over skjulte kolonner med ét klik.

Eksempel på brug:

En administrator ønsker kun at se 3 ud af 40 kolonner i en tabel. I stedet for at klikke 37 kolonner fra én ad gangen, trykker administratoren på "Skjul alle" og tilføjer derefter de 3 ønskede kolonner – færdig på få sekunder.

Knapperne er tilgængelige i alle admin-dialoger, der benytter kolonnevælgeren. Brug søgefeltet i tabelindstillingerne til at finde de enkelte kolonner du ønsker vist i dialogerne.

Bundles: Søgefeltet ryddes nu automatisk efter valg af underprodukt

Når man opretter en bundle og tilføjer underprodukter via søgefunktionen, kunne det tidligere ske, at søgefeltet ikke blev ryddet efter man havde valgt et produkt. Det betød, at den forrige søgetekst stadig stod i feltet, når man skulle tilføje det næste produkt – hvilket kunne skabe forvirring.

Nu ryddes søgefeltet automatisk, så snart et underprodukt er valgt, så man altid har et tomt felt klar til næste søgning.

Varemodtagelse: Nu kan alle emballagetyper vælges – også styks-enheder

Når I modtager varer eller håndterer returvarer, har det tidligere kun været muligt at vælge forpakningsniveau (f.eks. colli eller palle) under modtagelsen. Hvis et produkt kun var oprettet med en styks-enhed (f.eks. STK), blev der slet ikke vist nogen valgmulighed – og varen blev i stedet registreret med en generisk enhed.

Med denne opdatering introduceres en ny indstilling på forpakningsniveauer: "Lagerrelevant". Som administrator kan I nu markere præcis hvilke forpakningsniveuaer, der skal kunne vælges ved modtagelse, uafhængigt af om de er opsat som colli eller palle.

Systemet opfører sig herefter sådan:

Ingen lagerrelevante enheder: Samme adfærd som i dag – ingen valg vises.
Én lagerrelevant enhed: Enheden vælges automatisk, så lagermedarbejderen ikke skal gøre noget ekstra.
Flere lagerrelevante enheder: Lagermedarbejderen bliver bedt om at vælge den korrekte enhed.

Dette gælder for varemodtagelse, returvarer, lagertælling og lagerflytning.

Eksisterende forpakningsniveauer, der allerede er markeret som colli eller palle, bliver automatisk markeret som lagerrelevante ved opdateringen – så I behøver ikke ændre noget for at bevare den nuværende adfærd.

Homerunner: Udvidet opsætning og automatisk afsendelse for farligt gods

Tidligere kunne I kun registrere to oplysninger på en vare, der er klassificeret som farligt gods: en fareklasse og et UN-nummer.

Nu kan I oprette en fuld farligt gods-registrering på hver vare med alle de nødvendige transportoplysninger, bl.a.:

UN-nummer og fareklasse
Korrekt forsendelsesnavn
Emballagegruppering
Tunnelrestriktionskode
Emballagebeskrivelse og mængder
Om varen er miljøfarlig eller kan sendes som begrænset mængde

Sådan fungerer det:
En administrator opretter og vedligeholder farligt gods-oplysningerne i et nyt opsætningsflow i PeakWMS, hvor hver registrering kobles til den relevante vare. En vare kan have flere farligt gods-registreringer, hvis det er nødvendigt.

Når en ordre med farligt gods sendes via Homerunner, medsendes alle de registrerede oplysninger automatisk – så fragtmanden får de korrekte transportdata uden manuelt arbejde.

Ordrer med varer uden farligt gods-registreringer påvirkes ikke og fungerer som hidtil.

Lotstyring: Delvist pluk nu muligt, når lot ikke er fastlåst

Hvis I arbejder med lotstyrede varer, har det hidtil kun været muligt enten at plukke den fulde mængde eller at registrere et "short pick" – altså melde, at varen ikke var tilgængelig. Der var ingen mulighed for at plukke det, der var på lagerplaceringen, og lade systemet finde resten fra et andet lot.

Nu er der tilføjet en "Delvist pluk"-mulighed for lotstyrede varer, når ordren ikke kræver et bestemt lotnummer. I praksis betyder det:

Lagermedarbejderen plukker det antal, der er tilgængeligt på placeringen.
Systemet opretter automatisk en ny plukopgave for den resterende mængde og reserverer den fra et andet lot.
Arbejdet kan fortsætte uden ophold.

Hvornår gælder det ikke?
Hvis ordren kræver et bestemt lotnummer (f.eks. fordi kunden har bestilt en specifik batch), er delvist pluk fortsat blokeret – her skal hele mængden stadig komme fra det samme lot. I den situation fungerer det som hidtil med kun "short pick" som mulighed.

Ændringen gælder for alle pluktyper: pallepluk, plukkevogn, manuelt pluk, enkeltstyk pluk og bulkpluk.

Ordrer: Send det, der er på lager, ved første frigivelse

Normalt frigives en udgående ordre kun, når alle ordrelinjer kan dækkes fuldt af lagerbeholdningen. Hvis bare én linje mangler varer, holdes hele ordren tilbage, indtil alt er på lager.

Med den nye indstilling "Send hvad der er på lager ved første frigivelse" kan I nu vælge, at en ordre skal frigives med det, der er tilgængeligt – i stedet for at vente på fuld dækning.

Sådan fungerer det:

Når indstillingen er aktiveret, og ordren frigives for første gang (dvs. der endnu ikke er oprettet nogen plukkeordrer), frigives ordren som en delvis frigivelse: de linjer, der har beholdning, plukkes og sendes med det samme.
Hvis der slet ikke er beholdning på nogen linjer ved første frigivelse, holdes ordren tilbage som normalt – og kan frigives igen, når varer kommer på lager.
Ved alle efterfølgende frigivelser (når der allerede eksisterer mindst én plukordre) har indstillingen ingen effekt – her gælder de normale frigivelsesregler, så de resterende linjer frigives samlet, når de alle kan dækkes.

Indstillingen er slået fra som standard, så eksisterende ordrer og nuværende adfærd er helt upåvirket. Indstillingen sættes pr. ordre – f.eks. via en integration. Indstillingen skal sættes på udgående ordre direkte fra din webshop.

Webshipper: Opsætning af fragtprodukter via Host ID

Når I opsætter fragtprodukter til en Webshipper-integration, har det hidtil kun været muligt at vælge produktet fra en liste – hvorefter systemet automatisk udfyldte det tilhørende Host ID. For 3PL-kunder, der administrerer mange vareejere, er det samme produktnavn (f.eks. "GLS") ofte oprettet mange gange i listen, hvilket gør det svært at finde det rigtige. Host ID'et er derimod unikt og let at identificere.

Hvad er nyt?
Nu kan I gå den modsatte vej: Indtast Host ID'et direkte, og systemet finder og vælger automatisk det fragtprodukt, der matcher – inkl. produktkode, beskrivelse og alle tilknyttede felter (f.eks. servicekoder og aftalenumre).

I praksis:

Indtaster I et Host ID og forlader feltet, slår systemet det op mod de tilgængelige fragtprodukter. Findes et match, udfyldes produktet automatisk.
Vælger I et produkt fra listen, udfyldes Host ID'et stadig automatisk som hidtil.
Host ID og produkt holdes altid i sync – uanset hvilken af de to I udfylder først.
Indtastes et Host ID, der ikke matcher noget produkt, ryddes produktfeltet, og opsætningen kan ikke gemmes, før et gyldigt Host ID eller produkt er valgt.

Funktionen gælder kun for Webshipper-integrationer. Andre fragtintegrationer er ikke berørt.

Homerunner: Fragtpris sendes nu med i forsendelsesdata til toldbrug

Ved internationale forsendelser via Homerunner har fragtprisen ikke været inkluderet i de data, der sendes til Homerunner ved oprettelse af en forsendelse. Det betød, at Homerunner ikke automatisk kunne bruge fragtprisen i toldberegninger – hvilket kunne kræve manuel håndtering eller give unøjagtige toldangivelser.

Hvad er nyt?
Når PeakWMS opretter en forsendelse via Homerunner, inkluderes nu fragtprisen automatisk i forsendelsesdata. Fragtprisen sendes som en værdi med tilhørende valuta (f.eks. 49,95 DKK) og beregnes ud fra ordrens fragtomkostninger inkl. moms og rabat.

Sådan fungerer det:

Ordren har en fragtpris: Fragtprisen beregnes og sendes med i den valuta, der er sat på ordren.
Fragtprisen er 0 eller negativ (f.eks. gratis fragt): Værdien sendes som 0 – Homerunner modtager stadig feltet, så toldberegningen har et komplet datasæt.
Ingen valuta på ordren: Fragtprisfeltet udelades helt, da en pris uden valuta ikke giver mening.
Returlabels: Fragtpris sendes ikke med ved oprettelse af returlabels.

Fragtprisen beregnes pr. forsendelse – ikke samlet på tværs af eventuelle samsendingsordrer – da den fysiske fragtomkostning knytter sig til den enkelte forsendelse.

Retur: Separat leveringsadresse for ombytningsforsendelser

Når en kunde returnerer en vare og får en ombytning sendt retur, har det hidtil ikke været muligt at sende ombytningen til en anden adresse end den originale ordres adresse. Systemet brugte enten returadressen (som er afsenderadressen på returlabelen) eller den originale ordres leveringsadresse – og ingen af dem kunne ændres uafhængigt til brug for ombytningen.

Det var et problem f.eks. når:

Kunden er flyttet siden den originale ordre.
Kunden ønsker ombytningen sendt til en pakkeshop i stedet for hjemmeadressen.
Kunden vil have ombytningen leveret til en alternativ adresse (arbejdsplads, familiemedlem m.m.).

Hvad er nyt?
Returordrer har nu en selvstændig ombytningsadresse og et tilhørende pakkeshop-id, som udelukkende bruges til at bestemme, hvor ombytningsforsendelsen sendes hen.

Sådan fungerer det:

Via OpenAPI : Der kan angives en eksplicit ombytningsadresse og evt. pakkeshop-id ved oprettelse af returordren. Ombytningen sendes til den angivne adresse.
Ingen eksplicit adresse angivet: Angives der ikke en ombytningsadresse, kopieres returadressen automatisk ind som ombytningsadresse. Adfærden svarer dermed til den nuværende – men adressen kan nu ændres efterfølgende.
Via returportalen: Slutkundens afsenderadresse kopieres automatisk ind som ombytningsadresse. Returportalen understøtter ikke eksplicit valg af ombytningsadresse – auto-kopieringen dækker standardbehovet.
Manuel ændring: Ombytningsadressen kan redigeres i PeakWMS – både i webklienten og via et nyt API-endpoint – så længe returordren har mindst én ombytningslinje.

Ved pakning og labelprintning bruger alle fragtintegrationer (Webshipper, GLS, PostNord, Bring, Shipmondo, DAO m.fl.) nu ombytningsadressen som modtageradresse. For Webshipper bruges det nye pakkeshop-id til levering til pakkeshop.

Bagudkompatibilitet: Returordrer uden ombytningslinjer berøres ikke – her forbliver ombytningsadressen tom, og systemet bruger den originale ordres leveringsadresse præcis som hidtil.

Flyt lastbærer: Vælg specifikke lastbærere fra en lokation

Når en lagermedarbejder bruger "Flyt lastbærer"-funktionen i workeren og scanner en kildelokation med flere lastbærere, er alle lastbærere hidtil blevet medtaget automatisk – uden mulighed for at fravælge nogle af dem. Ville man kun flytte f.eks. 3 ud af 7 lastbærere, skulle det gøres som tre separate flytninger.

Hvad er nyt?
Når en lokation scannes og der findes flere lastbærere, vises nu en liste, hvor medarbejderen kan vælge præcis hvilke lastbærere, der skal flyttes:

Ingen markeret – alle lastbærere flyttes samlet til destinationslokationen (samme adfærd som hidtil).
Én eller flere markeret – kun de valgte lastbærere flyttes. Resten forbliver på kildelokationen.

Dialogen viser desuden tydeligt, hvor mange lastbærere der er valgt til flytning (f.eks. "Flytter 3 lastbærere"), så medarbejderen altid har overblik inden den endelige scanning af destinationslokationen.

Funktionen er særligt nyttig ved delvis tømning af et område – f.eks. når kun nogle paller skal flyttes til et nyt reolareal, mens resten skal blive stående.

Pallepluk: Print følgeseddel og ordrelabel på én gang ved palleafslutning

Når en palle afsluttes under pallepluk, har lagermedarbejderen hidtil skullet vælge mellem enten at printe en ordrelabel eller en følgeseddel – aldrig begge dele. Det betød, at kunder, der har brug for begge dokumenter pr. palle, måtte håndtere det ene dokument i et separat trin eller via en workaround.

Hvad er nyt?
Der er tilføjet en ny palleafslutningstilstand: "Følgeseddel og ordrelabel". Når denne er valgt på plukkegruppen, printer systemet både følgesedlen og ordrelabelen i ét samlet trin, når pallen afsluttes.

Sådan fungerer det:

Medarbejderen afslutter pluk af alle linjer på pallen.
På afslutningsskærmen vælger medarbejderen pallevægt, lastbærertype og printer til følgesedlen.
Ved tryk på "Afslut palle" vælger medarbejderen ordrelabel-skabelon og printer – enten automatisk fra gemte præferencer eller via den velkendte labeldialog.
Systemet printer følgesedlen og ordrelabelen i ét trin. Hvis ordren går til et land uden for EU, genereres tolddokumenter automatisk.
Hvis palleplaceringen er aktiveret på plukkegruppen, scanner medarbejderen en lokation som vanligt.

Detaljer:

Sidste palle: Tilstanden skelner ikke mellem sidste og ikke-sidste palle – der printes altid følgeseddel + ordrelabel. Flowet ruter ikke videre til forsendelseslabel, uanset om det er den sidste palle.
Printfejl: Hvis følgesedlen printes korrekt, men ordrelabel-printet fejler, forbliver pallen i "Afslut palle"-status, og medarbejderen kan prøve igen. Følgesedlen genskabes ikke ved genforsøg, da den allerede er gemt.
Bagudkompatibilitet: Indstillingen er en ny valgmulighed på plukgruppen. Eksisterende plukkegrupper beholder deres nuværende tilstand og er helt upåvirkede.

Ordrer: "Planlagt afsendingsdato" omdøbt til "Planlagt frigivelsesdato" + nyt felt "Planlagt afsendelsesdato"

I B2B-lageroperationer er der forskel på, hvornår en ordre frigives til pluk, og hvornår den rent faktisk afsendes. Hidtil har ordren kun haft ét datofelt – "Planned Pick Date" – der styrer, hvornår ordren frigives til pluk. Den danske oversættelse "Planlagt afsendingsdato" har været misvisende, fordi feltet netop ikke handler om afsendelse, men om hvornår plukprocessen igangsættes.

Omdøbning af eksisterende felt
Feltet hedder nu "Planned Release Date" / "Planlagt frigivelsesdato" på alle sprog. Det afspejler feltets faktiske funktion: det styrer, hvornår ordren frigives til pluk. Al beregningslogik (f.eks. automatisk beregning ud fra ønsket leveringsdato minus 1 hverdag) er uændret – kun navnet er opdateret.

Nyt felt: Planlagt afsendelsesdato
Ordren har nu et nyt felt: "Planned Shipping Date" / "Planlagt afsendelsesdato". Feltet er rent informationelt – det påvirker ikke ordrefrigivelse, plukordrer eller nogen automatiseret proces. Det giver jer mulighed for at registrere, hvornår ordren forventes afsendt, f.eks. til intern planlægning eller rapportering.

Sådan sættes den planlagte afsendelsesdato:

I ordreoversigten: Vælg én eller flere ordrer og brug den nye handling "Sæt planlagt afsendelsesdato". Datoen kan også ryddes igen via samme dialog.
Via OpenAPI: Feltet PlannedShippingDate kan sættes ved oprettelse og opdatering af ordrer.

Bagudkompatibilitet (OpenAPI):

Det gamle feltnavn PlannedPickDate virker stadig i API'et – det fungerer som et alias for det nye PlannedReleaseDate. Begge navne accepteres ved input og returneres i output. PlannedPickDate er markeret som forældet (deprecated) og vil blive fjernet i en fremtidig version. Vi anbefaler, at I opdaterer jeres integrationer til at bruge PlannedReleaseDate ved lejlighed.

Pallepluk: Vis kommende add-on-top-linjer på konsolideringsskærmen

Når en palleplukker afslutter pluk og systemet viser konsolideringsskærmen, har medarbejderen hidtil kun kunnet se basale ordreoplysninger – kildelastbærer, forsendelseslager, ordrenummer og kundenavn. Der har ikke været nogen synlighed over, om der er yderligere plukkeordrelinjer til den samme udgående ordre, der endnu ikke er plukket – og som potentielt kan lægges ovenpå (add-on-top) af en anden plukker.

Det betød, at medarbejderen skulle tage konsolideringsbeslutningen "i blinde" – uden at vide, om det ville give mening at vente med konsolideringen, til en anden plukker har tilføjet de resterende linjer.

Hvad er nyt?
Konsolideringsskærmen viser nu en informationsliste over tilgængelige add-on-top-linjer – dvs. plukkeordrelinjer fra andre plukkeordrer til den samme udgående ordre, der stadig afventer pluk.

Sådan fungerer det:

Add-on-top-linjer tilgængelige: En udvidbar sektion vises på konsolideringsskærmen med en læsbar liste over ventende linjer. Hver linje viser varenummer, varebeskrivelse, antal, plukkegruppenavn og områdenavn (hvis tilgængeligt). Listen er sorteret efter plukkegruppe, område og varenummer.
Ingen add-on-top-linjer: Hvis alle øvrige plukkeordrer allerede er plukket eller pakket, vises sektionen slet ikke – skærmen ser ud præcis som hidtil.
AllowAddOnTop ikke aktiveret: Hvis plukgruppen ikke har "Allow add-on-top" slået til, vises sektionen ikke – adfærden er identisk med den nuværende.

Informationen er rent visuel og skrivebeskyttet – den ændrer ikke konsolideringsflowet og tilføjer ingen nye trin eller knapper. Medarbejderen kan bruge informationen til at vurdere, om det giver mening at konsolidere nu, eller om det er bedre at skippe lastbæreren (hvis tilladt) og lade en anden plukker tilføje de resterende linjer først.

Funktionen gælder for alle tre konsolideringstilstande: konsolidér med eksisterende, konsolidér uden eksisterende og konsolidér til andet forsendelseslager.

Pallepluk: Kundenavn vises nu på ordreinfoskærmen

Når en lagermedarbejder starter et pallepluk, vises en ordreinfoskærm med oplysninger om ordren – antal linjer, vægt, volumen og transportørprodukt. Hidtil har kundenavnet ikke været vist på denne skærm, hvilket gjorde det svært hurtigt at identificere, hvem ordren tilhørte – især når flere ordrer behandles i træk.

Hvad er nyt?
Ordreinfoskærmen ved pallepluk viser nu kundenavnet fra forsendelsesadressen som en fremtrædende linje med et person-ikon – konsistent med den måde kundenavnet allerede vises på pakkeskærmene.

Detaljer:

Kundenavn tilgængeligt: Navnet vises som den første linje i ordreinfo-sektionen (over linjer, vægt og volumen), så medarbejderen ser det med det samme.
Ingen forsendelsesadresse: Hvis ordren ikke har en forsendelsesadresse, vises linjen ikke – skærmen ser ud præcis som hidtil.
Bagudkompatibelt: Ændringen er et nyt valgfrit felt – eksisterende integrationer og klienter er ikke påvirket.

Rapport over tomme lokationer: Varenumre fra faste plukkepladser vises nu

Rapporten "Tomme lokationer" viser alle lokationer på lageret, der aktuelt ikke indeholder nogen beholdning. Hidtil har rapporten ikke vist, om en tom lokation var konfigureret som fast plukkeplads (MaterialLocation) for specifikke varer – og i givet fald, hvilke varenumre der var tilknyttet. Det betød, at lagercheferne manuelt skulle slå op på hver enkelt lokation for at vurdere, om en tom plukkeplads stadig var relevant, eller om den kunne omallokeres.

Hvad er nyt?
Rapporten har nu en ny kolonne: "Varenumre" (MaterialItemNumbers), der viser de varenumre, som er konfigureret som faste plukkepladser på den pågældende lokation.

Sådan fungerer det:

Lokation med faste plukkepladser: Kolonnen viser de tilknyttede varenumre kommasepareret – f.eks. "ITEM-001, ITEM-002". Kun aktive MaterialLocations medtages.
Lokation uden faste plukkepladser: Kolonnen er tom.
Søg og filtrér: Varenummerkolonnen er tilføjet til rapportens hurtigsøgning, så det er muligt at søge direkte på et varenummer og hurtigt finde tomme plukkepladser for et bestemt produkt.

Eksempel på brug:

En lagerchef ønsker at finde tomme plukkepladser for vare ITEM-001. Chefen åbner rapporten "Tomme lokationer", søger på ITEM-001 og får en liste over alle tomme lokationer, der er konfigureret som fast plukkeplads for den vare – og kan derefter vurdere, om lokationerne skal genopfyldes eller omallokeres.

Ændringen er rent additiv – eksisterende kolonner og funktionalitet i rapporten er uændret.

Rapport over afsendte enheder: Lotnummer og holdbarhedsdato er nu tilgængelige

Rapporten "Shipped Units" viser detaljerede oplysninger om alle afsendte enheder – varenummer, antal, ordreoplysninger m.m. Hidtil har rapporten ikke vist, hvilket lotnummer eller hvilken holdbarhedsdato, der faktisk blev plukket for den enkelte enhed – selvom disse oplysninger registreres automatisk ved pluk og gemmes på plukkeordrelinjen.

Det betød, at kunder med lot- og holdbarhedsstyring (f.eks. fødevarer, kosmetik, farmaceutiske produkter) ikke kunne bruge rapporten til sporbarhed eller til at verificere, at den korrekte batch blev afsendt.

Hvad er nyt?
Rapporten har nu to nye kolonner:

Plukket lotnummer (PickedLotNumber) – det lotnummer, der blev registreret ved pluk af den pågældende linje.
Plukket holdbarhedsdato (PickedBestBeforeDate) – den holdbarhedsdato, der var tilknyttet den plukkede beholdning.

Detaljer:

Eksisterende data: Kolonnerne viser data fra både aktive og arkiverede plukkeordrer – så historiske forsendelser, der allerede er afsluttet og arkiveret, får også lot- og holdbarhedsdata vist korrekt.
Ingen konfiguration nødvendig: Kolonnerne vises automatisk i rapporten og er tilgængelige i søgning og filtrering som alle øvrige kolonner.
Ingen performance-påvirkning: Data hentes fra felter, der allerede eksisterer på plukkeordrelinjen – der tilføjes ingen nye tabeller eller beregninger.
Varer uden lot/holdbarhed: Kolonnerne er tomme for linjer, hvor lot- eller holdbarhedsregistrering ikke er aktiveret – rapporten ser ud som hidtil for disse varer.

Serienumre på lager: Nye felter "Leverandørkommentar" og "Tilhørsforhold"

Serienumre på lager har hidtil kun indeholdt de grundlæggende registreringsdata – selve serienummeret, varenummeret og lagerstatus. Der har ikke været mulighed for at tilføje supplerende oplysninger fra leverandøren eller angive en kontekstuel gruppering – f.eks. hvilket lager, land eller område serienummeret er tilknyttet.

Det betød, at vigtige oplysninger – som at en leverandør har rengjort eller serviceret en enhed – måtte registreres uden for PeakWMS eller slet ikke blev registreret.

Hvad er nyt?
Serienumre på lager har nu to nye valgfrie fritekstfelter:

Leverandørkommentar (SupplierComment, maks. 512 tegn) – til registrering af information fra leverandøren, f.eks. at et serienummer er blevet rengjort, repareret eller inspiceret.
Tilhørsforhold (Affiliation, maks. 256 tegn) – til kontekstuel gruppering, f.eks. et bestemt lager, land eller område, som serienummeret er tilknyttet.

Begge felter er rent informationelle – de påvirker ingen forretningslogik, plukprocesser eller lagerbevægelser.

Admin-dialog:

Begge felter vises som kolonner i serienummeroversigten og kan redigeres direkte via redigeringsdialogen.
Felterne kan sættes, ændres og ryddes frit til enhver tid.

OpenAPI:

Nyt endpoint: PUT api/integration/v1/serialNumberInStock/{serialNumber} – accepterer et JSON-body med supplierComment og affiliation.
Endpointet udfører en fuld erstatning: begge felter overskrives ved hvert kald. Udeladte felter, null-værdier, tomme strenge og whitespace-only-strenge rydder det pågældende felt.
Standardiserede fejlkoder: 200 ved succes, 400 ved ugyldigt input eller overskredet maks. længde, 404 hvis serienummeret eller varenummeret ikke findes.

Pallemodtagelse: "Print label"-knappen hedder nu "Print beholdningslabel"

Under pallemodtagelse har knappen til at printe labels hidtil heddet blot "Print label" – uden at specificere, hvilken type label der printes. Det var utydeligt for lagermedarbejderen, hvad knappen faktisk gjorde, og selv under onboarding af nye kunder var det svært at forklare knappens funktion baseret på teksten alene.

Hvad er ændret?
Knapteksten er omdøbt for at gøre det tydeligt, at der printes en beholdningslabel:

Dansk: "Print beholdningslabel"
Engelsk: "Print Stock Item label"

Ændringen er rent kosmetisk – funktionaliteten bag knappen er uændret. Knappen printer præcis det samme som hidtil, men teksten afspejler nu klart, hvad der printes.

Returordrelinjer: Alle felter er nu tilgængelige i linjeoversigten

Oversigten over returordrelinjer (View_ReturnOrderLineOverview) har hidtil ikke indeholdt alle de felter, der faktisk var tilgængelige på selve returordrelinjen. Det betød, at administratorer ikke kunne se – eller søge og filtrere på – visse felter direkte i linjeoversigten, men i stedet måtte åbne hver enkelt returordrelinje for at se de manglende informationer.

Hvad er ændret?

Returordrelinjeoversigten er opdateret, så den nu indeholder alle felter fra returordrelinjen. Alle kolonner er tilgængelige i tabelindstillinger og kan vises, skjules, søges og filtreres på – præcis som de øvrige felter i oversigten.

Ændringen giver et komplet overblik over returordrelinjer direkte i oversigten – uden at skulle åbne de enkelte linjer.

Produktimport: ExternalLocation kan nu importeres via Excel

Feltet ExternalLocation (ekstern lokation) – som bruges under pluk til at vise en alternativ lokationsreference – har hidtil kun kunnet sættes manuelt pr. produkt via admin-dialogen. Det har ikke været muligt at importere værdien via Excel-produktimport i Produkter.

Det betød, at lagre, der ønskede at konfigurere ekstern lokation på mange produkter på én gang, var nødt til enten at gøre det manuelt produkt for produkt.

Hvad er nyt?

Feltet ExternalLocation er nu tilføjet som kolonnemulighed i produktimport via Excel i Produkter-dialogen. Administratorer kan dermed masseimportere eller masseopdatere ekstern lokation for alle produkter i ét Excel-ark – hurtigt, sikkert og uden behov for manuelle databaseændringer.

Bugfixes

Ordrefrigivelse: Fejl rettet ved ordrer med samme varenummer på flere linjer

Hvis en ordre indeholdt det samme varenummer på flere ordrelinjer – f.eks. fordelt på forskellige leveringsgrupper – kunne systemet fejlagtigt sætte ordren på hold med besked om, at lagerbeholdningen var reserveret til ældre ordrer.

Fejlen skyldtes, at reservationen for ældre ordrer blev talt med flere gange – én gang pr. ordrelinje med det pågældende varenummer – i stedet for kun at blive talt med én gang samlet for hele ordren. Det betød, at systemet troede, der var mindre på lager end der reelt var, og derfor afviste at frigive ordren.

Dette er nu rettet, så reservationen kun tælles med én gang, uanset hvor mange linjer i ordren der indeholder det samme varenummer. Ordrer, der tidligere fejlagtigt blev sat på hold, vil nu blive frigivet korrekt.

Delvist pluk: Ny forsendelseslabel genereres nu korrekt ved split af ordre

Når en lagermedarbejder kun plukker en del af en ordre (delvist pluk), og ordren dermed splittes i to, blev den oprindelige forsendelseslabel tidligere beholdt på den første delforsendelse. Det betød, at oplysninger som vægt og indhold på labelen ikke matchede det, der reelt lå i pakken.

Nu genereres der automatisk en ny forsendelseslabel, når en ordre splittes ved delvist pluk. Labelen afspejler dermed det faktiske indhold i pakken, så fragten beregnes korrekt, og forsendelsen får de rigtige oplysninger med.

Returhåndtering: Fejl rettet ved returnering af bundleprodukter

Når en kunde returnerede en vare, der var en del af et bundleprodukt (en bundle med underprodukter), og der allerede eksisterede en returordre på den pågældende ordre, fejlede systemet med en intern fejl (HTTP 500). Det betød, at det ikke var muligt at registrere returen – hverken med eller uden refundering.

Fejlen opstod i den tekniske håndtering af returlinjer for bundleprodukter, hvor systemet forsøgte at ændre en intern nøgle på en allerede registreret returlinje, hvilket ikke er tilladt.

Dette er nu rettet, så returnering af varer fra bundleprodukter fungerer korrekt – også når der allerede eksisterer en returordre på den pågældende ordre. Oplysninger som returårsag og returhandling overføres stadig korrekt fra hovedproduktet til de enkelte underprodukter.

Pluk: Alternativ plukkelokation og nulpluk bruger nu den korrekte frigivelsesregel ved sammenlægning af regler

Når en ordre frigives via en frigivelsesregel, der er sat op til at flette ind i en anden regel, mistede systemet tidligere sporet af, hvilken regel ordrelinjen oprindeligt matchede. Det betød, at:

Alternativ plukkelokation kun viste beholdning baseret på den sammenlagte regels lagerkriterier – som kan være mere restriktive end den oprindelige regels. Gyldige alternative lokationer blev derfor skjult for plukkeren.
Nulpluk søgte efter erstatningsbeholdning med den forkerte regels kriterier. Hvis der ikke var beholdning under den sammenlagte regel – men der var under den oprindelige regel – blev linjen fejlagtigt markeret som "short pick" i stedet for at blive reserveret fra den korrekte beholdning.

Hvad er ændret?
Systemet husker nu, hvilken frigivelsesregel hver enkelt plukkeordrelinje oprindeligt matchede. Når der søges efter beholdning – enten ved alternativ plukkelokation eller ved nulpluk – gennemgår systemet hele kæden af sammenhængende regler:

Alternativ plukkelokation viser nu beholdning fra alle regler i kæden, så plukkeren ser det bredest mulige udvalg af lokationer.
Nulpluk forsøger først at reservere fra den oprindelige regel. Hvis der ikke er beholdning, søger systemet videre op i kæden, indtil det finder tilgængelig beholdning.

For eksisterende plukkeordrer, der er oprettet før opdateringen, bevares den nuværende adfærd – ændringen gælder kun for nyoprettede plukkeordrelinjer.

Dialoger: Datofiltre viser nu korrekte resultater i alle tidszoner

Når I brugte relative datofiltre i en dialog – f.eks. "ordrer inden for den sidste time" eller "i dag" – kunne resultatet i dialogen afvige fra det antal, dashboardet viste. Dialogen viste typisk for mange eller for få resultater.

Fejlen skyldtes, at dialogen beregnede tidspunktet ud fra UTC-tid i stedet for lokal tid. Da alle datoer i systemet gemmes i lokal tid, betød det f.eks. i dansk tidszone (UTC+2), at filteret "ordrer den sidste time" reelt hentede ordrer fra de sidste 3 timer i dialogen – mens dashboardet korrekt viste ordrer fra den sidste time.

Hvad er rettet?
Alle relative datoberegninger i dialoger bruger nu lokal tid – præcis som dashboardet allerede gør. Det gælder filtrene:

Timer/dage fra nu (OFFSET_HOURS / OFFSET_DAYS)
I dag, i går, i morgen
Denne uge, næste uge, denne måned

Dashboard og dialog viser nu altid det samme resultat for de samme filtre.

Bemærk: Gemte søgninger med relative datofiltre kan vise et andet antal resultater end før. Det er den korrekte adfærd – resultaterne matcher nu det, filteret faktisk beskriver.

Homerunner returlabels: Rettet fejl ved kundeadresser med to adresselinjer

Når en returlabel blev oprettet via Homerunner, blev kundens to adresselinjer (adresselinje 1 og adresselinje 2) sammensat til én enkelt linje og sendt til fragtmanden. Hvis den samlede linje oversteg 35 tegn – hvilket er grænsen hos flere fragtmænd – blev returlabelen afvist. Det betød, at returlabels ikke kunne oprettes for kunder i bl.a. Østrig og Frankrig, hvor adresserne typisk bruger begge adresselinjer.

Nu sendes kundens adresselinjer som to separate felter til Homerunner – præcis som det allerede sker for modtageradressen ved udgående forsendelser. Dermed overholder hver linje for sig fragtmandens tegngrænse, og returlabels oprettes korrekt.

Ændringen påvirker kun returlabels. Udgående forsendelser via Homerunner fungerer som hidtil.

Lagerjustering: Plukkeordre med allerede plukkede linjer slettes ikke længere

Hvis en lagermedarbejder redigerede en lagerbeholdning (f.eks. nedsatte mængden til 0 via en lagerjustering), og beholdningen var reserveret til en plukkeordre, slettede systemet tidligere hele plukkeordren – også selvom andre linjer på plukkeordren allerede var plukket.

Det betød, at allerede plukkede varer mistede deres tilknytning til ordren. Varerne "hang" på lageret uden reference til nogen ordre, og den udgående ordre blev sat tilbage til status "Oprettet", som om intet var plukket. Det gav risiko for dobbeltpluk og tab af sporbarhed.

Hvad er rettet?
Systemet tjekker nu, om der er linjer på plukkeordren, der allerede er plukket, før det forsøger at slette ordren:

Hvis mindst én linje er plukket: Plukkeordren bevares. Kun den reservation, der ikke længere kan opfyldes (fordi beholdningen er reduceret), fjernes – resten af ordren forbliver intakt.
Hvis ingen linjer er plukket: Plukkeordren slettes som hidtil, og ordren kan frigives igen, når ny beholdning er tilgængelig.

Ændringen sikrer, at allerede udført plukkearbejde aldrig går tabt ved en lagerjustering.

Samsending: Annullering af hovedordre efter pluk blokerer ikke længere underordrer

Hvis I bruger samsending, og hovedordren blev annulleret fra webshoppen, efter at varerne allerede var plukket, endte systemet i en fastlåst tilstand:

Hovedordrens egne linjer blev annulleret, men plukordren forblev i status "Plukket".
Underordrerne (child orders) sad fast i status "Send med anden ordre" og kunne ikke behandles – hverken sammen med hovedordren eller selvstændigt.
På pakkebordet så lagermedarbejderen en plukkeordre uden aktive linjer og kunne ikke komme videre uden manuel indgriben i databasen.

Hvad er rettet?
Når en lagermedarbejder scanner lastbæreren på pakkebordet, opdager systemet nu automatisk, at hovedordren reelt er annulleret (alle egne linjer er annulleret eller fjernet), og udfører følgende:

Plukordren annulleres og lagerbeholdningen tilbageføres.
Underordrerne frigøres – de sættes tilbage til status "Oprettet", så de kan frigives og plukkes selvstændigt.
Medarbejderen ser den velkendte "ordrer annulleret"-dialog og bekræfter, at varerne lægges tilbage på lager.

Hele flowet sker automatisk ved scanning – der kræves ingen manuelle rettelser i databasen. Hvis hovedordren stadig har aktive egne linjer (f.eks. kun delvist annulleret), træder den nye logik ikke i kraft, og den eksisterende adfærd bevares.

Webshipper: Kundenavn vises ikke længere dobbelt på forsendelseslabels til privatadresser

Når en forsendelse via Webshipper blev sendt til en privatadresse uden firmanavn, viste forsendelseslabelen kundens navn to gange – én gang som firmanavn og én gang som kontaktperson.

Fejlen skyldtes, at PeakWMS brugte kundens personnavn som fallback i feltet "Company name", når firmanavnet var tomt. Samtidig blev det samme personnavn sat i feltet "Att. contact". Fragtmanden modtog dermed det samme navn i begge felter og printede det dobbelt på labelen.

Hvad er rettet?
Feltet "Company name" fyldes nu kun ud, hvis der faktisk er et firmanavn på forsendelsesadressen. Hvis firmanavnet er tomt, sendes feltet tomt til Webshipper – og kundens personnavn vises kun én gang på labelen, som kontaktperson.

Rettelsen gælder kun forsendelser til privatadresser uden firmanavn. Forsendelser til virksomhedsadresser, hvor firmanavnet er udfyldt, fungerer som hidtil.

Bemærk: En tilsvarende fejl i Shipmondo-integrationen er rettet separat.

Pakkebord: "Send igen"-ordrer blokerer ikke længere pakkebordet

Når en ordre blev sendt igen via "Send igen"-funktionen (f.eks. fordi kunden havde brug for en ny forsendelse), og den nye plukkeordre blev pakket og fik bekræftet forsendelseslabelen, blev pakkebordet ikke frigivet korrekt. Lastbæreren forblev registreret på pakkebordet, og bordets status blev ikke nulstillet til "Ikke aktiv".

Det betød, at pakkebordet var blokeret for den næste ordre – og der var behov for manuel indgriben (via admin-værktøjer eller direkte i databasen) for at frigøre bordet igen.

Hvad var årsagen?
Systemet forvekslede "Send igen"-plukkeordrer med splittede ordrer. Når forsendelseslabelen blev bekræftet, ledte systemet efter en eventuel splitordre – og fordi "Send igen"-ordren teknisk set havde en reference til den oprindelige plukkeordre, troede systemet, at der var en splitordre, der ventede. Derfor sprang det oprydningen over og lod lastbæreren blive på bordet.

Hvad er rettet?

Systemet skelner nu korrekt mellem splittede ordrer og "Send igen"-ordrer. Når en "Send igen"-plukkeordre pakkes og labelen bekræftes, fjernes lastbæreren fra pakkebordet, og bordets status sættes til "Ikke aktiv" – præcis som ved enhver anden plukkeordre. Pakkebordet er dermed straks klar til næste ordre.

Konsolidering: Annullerede pluklinjer blokerer ikke længere pakning efter sammenlægning

Hvis I bruger konsolidering (sammenlægning af plukordrer) på tværs af lagre, kunne en ordre i visse tilfælde blive permanent blokeret på pakkebordet.

Fejlen opstod i dette scenarie:

En ordrelinje frigives til lager 1, men varen er ikke tilgængelig – lagermedarbejderen laver et nulpluk, og linjen annulleres.
Ordrelinjen frigives igen til lager 2, hvor varen plukkes korrekt.
De to plukkeordrer konsolideres (lægges sammen).

Ved sammenlægningen blev den annullerede linje fra lager 1 fejlagtigt medtaget. Det kunne enten oppuste mængden på den plukkede linje (så den fremstod som "delvist plukket") eller tilføje en død linje med mængde 0. I begge tilfælde kunne plukordren aldrig nå status "Plukket" – og ordren sad fast og kunne ikke pakkes uden manuel indgriben.

Hvad er rettet?
Sammenlægningslogikken filtrerer nu annullerede linjer fra – præcis som den allerede gør for short-pick-linjer. Annullerede linjer har ingen beholdning og ingen mængde, og de medtages derfor ikke længere ved konsolidering.

Rettelsen sikrer, at plukkeordren efter sammenlægning får den korrekte status og kan pakkes som forventet.

Pallepluk: Nuloptælling udløses ikke længere, når der stadig er varer på lokationen

Ved pallepluk – når en lagermedarbejder tømte en lastbærer på en pluklokation – bad systemet om en nuloptælling (zero-quantity verification) for at bekræfte, at lokationen var tom. Men systemet kiggede kun på den ene lastbærer, der netop var plukket tom – og ignorerede, om der stod andre lastbærere med samme vare på den samme lokation.

Det betød, at medarbejderen blev bedt om at bekræfte, at varen var udgået på lokationen, selvom der tydeligt stod en anden palle med den samme vare lige ved siden af. Det var forvirrende og forsinkede plukprocessen unødigt.

Hvad er rettet?
Systemet kigger nu på al tilgængelig beholdning af den pågældende vare på hele lokationen – på tværs af alle lastbærere og eventuel løs beholdning – før det beslutter, om en nuloptælling er nødvendig:

Hvis der stadig er tilgængelig beholdning af samme vare på lokationen (uanset lotnummer, holdbarhedsdato eller pakkeenhed), udløses ingen nuloptælling.
Hvis der ikke er mere tilgængelig beholdning af varen på lokationen, udløses nuloptællingen som hidtil.

Kun beholdning med status "Tilgængelig" tæller med – blokeret eller reserveret beholdning undertrykker ikke nuloptællingen.

Rettelsen gælder for alle pluktyper: pallepluk, manuelt pluk, plukvogn, enkellinjes pluk, bulkpluk og automationspluk.

Business Central: Lagerjusteringer blokeres ikke længere af fejlede posteringer

Kunder, der bruger kontinuerlig lagerrapportering med automatisk bogføring mod Business Central, kunne opleve, at alle lagerjusteringer gik i stå – uden at nogen alarm blev vist i PeakWMS.

Hvad skete der?
Når en lagerjustering blev sendt til Business Central og posteringen af PEAK-ADJ-journalen fejlede (f.eks. pga. negativ lagerbeholdning i BC), blev de indsatte journallinjer liggende i Business Central. Ved næste lagerjustering indsatte systemet nye linjer – men med et nyt dokumentnummer fra nummerserierne. Business Central kræver, at alle linjer i en journal har samme dokumentnummer, og afviste derfor posteringen med en fejl om dokumentnummer-mismatch.

Fejlen gentog sig ved alle efterfølgende lagerjusteringer – én fejlet postering blokerede dermed alle fremtidige justeringer permanent. Samtidig blev der ikke oprettet nogen alarm i PeakWMS, da alarmfunktionen utilsigtet var deaktiveret for alle ERP-integrationer. Fejlen blev derfor først opdaget, når kunden manuelt tjekkede i Business Central.

Hvad er rettet?

Oprydning af gamle journallinjer: Før nye lagerjusteringer indsættes og bogføres, rydder systemet nu alle eksisterende linjer i PEAK-ADJ-journalen. Det sikrer, at restlinjer fra tidligere fejlede posteringer ikke blokerer nye justeringer. Oprydningen sker kun, når automatisk bogføring er aktiveret – ved manuel bogføring (DONT_BOOK_AUTOMATICALLY) bevares den eksisterende adfærd, hvor linjerne akkumuleres til manuel postering i BC.
Alarmer ved ERP-integrationsfejl: Når en besked til en ERP-integration (Business Central, Uniconta, e-conomic, Navision eller Rackbeat) fejler endeligt efter alle genforsøg, oprettes der nu en alarm i PeakWMS. Det giver operatører synlighed over integrationsfejl, der tidligere gik ubemærket hen.

Bemærk: PEAK-ADJ-journalen antages at være ejet af PeakWMS. Eventuelle manuelt tilføjede linjer i denne journal vil blive slettet ved næste automatiske bogføring.

3PL: Sletning af vareejer: Fejl med fragt-referencer blokerer ikke længere sletningen

Når en 3PL-administrator forsøgte at slette en vareejer (Goods Owner), der ikke længere var i brug, kunne sletningen fejle med en databasefejl – uden at vareejeren blev fjernet.

Hvad skete der?
Hver vareejer kan have egne fragtopsætninger. Når en vareejer slettes, forsøger systemet også at slette de tilknyttede fragtopsætninger. Men hvis en fragtopsætning var refereret af en anden vareejer – f.eks. via en klientopsætning eller via et fragtprodukt på en historisk udgående ordre – blokerede databasens integritetsbeskyttelse sletningen. Systemet forsøgte op til 5 gange og fejlede derefter med en teknisk fejlbesked.

Hvad er rettet?
Sletteprocessen håndterer nu disse krydsreferencer korrekt, inden selve fragtopsætningen slettes:

Klientopsætninger der refererer til fragtopsætningen, men tilhører en anden vareejer, får deres fragtreference ryddet – så de ikke blokerer sletningen.
Udgående ordrer der refererer til et fragtprodukt fra den slettede vareejer, får deres fragtproduktreference ryddet – da fragtproduktet alligevel ikke længere er gyldigt.

Dermed kan vareejeren og alle tilhørende data slettes uden fejl.

Derudover er fragtopsætning (forwarder) nu gjort til et påkrævet felt ved opsætning af fragt for kunder med flere vareejere. Det forhindrer, at der oprettes fragtopsætninger uden tilknytning til en vareejer – hvilket var en af årsagerne til de problematiske krydsreferencer.

Plukkegrupper: Sletning af plukkegruppe fejler ikke længere pga. arkiverede plukkeordrer

Når en administrator forsøgte at slette en plukkegruppe via admin-opsætningen, kunne systemet fejle med en databasefejl – selvom plukkegruppen ikke havde nogen aktive plukordrer.

Hvad skete der?
Inden en plukkegruppe slettes, tjekker systemet, om der er aktive plukkeordrer (i status Picking, Picked eller Assigned), og flytter dem til en anden plukkegruppe. Derefter slettes gruppen. Men systemet tog ikke højde for arkiverede plukkeordrer – historiske plukkeordrer, der stadig havde en reference til den slettede plukkegruppe i arkivtabellen. Databasens integritetsbeskyttelse forhindrede sletningen, fordi arkiverede plukkeordrer stadig pegede på den gruppe, der var ved at blive fjernet.

Hvad er rettet?
Inden plukkegruppen slettes, nulstiller systemet nu referencen på alle arkiverede plukkeordrer, der peger på den pågældende gruppe. Referencen sættes til NULL – de arkiverede plukkeordrer bevares stadig i historikken, men uden tilknytning til den slettede gruppe.

Den eksisterende validering er uændret: plukkegrupper med aktive plukkeordrer i status Picking, Picked eller Assigned kan stadig ikke slettes. Rettelsen gælder udelukkende arkiverede plukkeordrer, der ikke længere er operationelt relevante.

Lager: Sletning af tom reol fejler ikke længere pga. optællingslinjer

Når en administrator forsøgte at slette en tom reol (uden lagerbeholdning), kunne sletningen fejle med fejlbeskeden: "Sletning af data mislykkedes, da der eksisterer en reference til Optællingslinjer".

Hvad skete der?
Reolen var tom – ingen varer på nogen af dens lokationer – men der eksisterede afventende optællingslinjer (StocktakingOrderLines), der refererede til reolens lokationer. PeakWMS havde allerede logik til at fjerne disse optællingslinjer inden sletning, men logikken blev aldrig udført, fordi de tilknyttede data ikke blev indlæst korrekt. Resultatet var, at databasens integritetsbeskyttelse blokerede sletningen, og reolen forblev i PeakWMS.

Hvad er rettet?
Optællingslinjer, der refererer til reolens lokationer, fjernes nu automatisk som en del af sletteprocessen – inden lokationerne og selve reolen slettes. Det sikrer, at en tom reol altid kan slettes, uanset om der eksisterer afventende optællingslinjer.

Den eksisterende beskyttelse er uændret: reoler med lagerbeholdning kan stadig ikke slettes.

Lager: Sletning af lokationer blokeres ikke længere af inaktive plukkearbejdsstationer

Når en administrator forsøgte at slette en lokation i rn reol, kunne sletningen fejle med fejlbeskeden: "Sletning af data mislykkedes, da der eksisterer en reference til Plukkearbejdsstationer" – selvom ingen plukkearbejdsstation var aktiv eller i brug.

Hvad skete der?
Under en plukketur gemmer plukkearbejdsstationen (f.eks. plukkevogn eller manuel station) en reference til den sidst besøgte lokation (LastPickLocationId) og startlokationen (StartPickLocationId). Når plukketuren afsluttedes og stationen blev sat til "Ikke aktiv", blev disse referencer ikke ryddet. De forblev i databasen som "forladte" foreign keys – og blokerede enhver efterfølgende sletning af de pågældende lokationer.

Problemet opstod uanset, hvordan stationen blev deaktiveret – via normal afslutning af plukketuren, via reset af workstationen eller via admin-værktøjer.

Hvad er rettet?
Når en lokation slettes, fjerner systemet nu automatisk referencerne fra alle inaktive plukkearbejdsstationer, der peger på den pågældende lokation. Stationerne bevarer deres øvrige data – kun de lokationsreferencer, der ville blokere sletningen, ryddes.

Aktive plukkearbejdsstationer (der er midt i en pluktur) berøres ikke – her er referencerne stadig operationelt relevante og bevares.

Shipmondo: Kundenavn vises ikke længere dobbelt på pakkeshop-labels

Når en forsendelse via Shipmondo blev sendt til en pakkeshop (f.eks. PostNord Service Point), og modtageradressen havde et udfyldt firmafelt (Company), blev kundenavnet printet to gange på forsendelseslabelen – én gang som modtagernavn og én gang som kontaktperson (Attention).

Fejlen skyldtes, at systemet automatisk mappede kundenavnet til Attention-feltet, når firmafeltet var udfyldt. Derefter overskrev koden modtagernavnet (Name) med kundenavnet – men uden at rydde Attention. Resultatet var, at Shipmondo modtog det samme kundenavn i begge felter, og fragtselskabet printede det dobbelt på labelen.

Problemet ramte alle PARCEL_SHOP-forsendelser via Shipmondo, hvor modtageradressen havde et udfyldt firmafelt – uanset fragtselskab (PostNord, GLS m.fl.) og uanset land.

Hvad er rettet?
Når modtagernavnet (Name) sættes til kundenavnet for pakkeshop-forsendelser, ryddes Attention-feltet nu automatisk, så kundenavnet kun vises én gang på labelen.

Bemærk: En tilsvarende fejl i Webshipper-integrationen er rettet separat.

POS-lagerjusteringer: Alarm ved forsøg på justering af varer i QA-status

Når et POS-system (f.eks. FrontSystems) sendte en negativ lagerjustering – typisk ved salg eller optælling i butikken – og den pågældende beholdning var i QA-status (kvalitetskontrol), blev justeringen ignoreret uden besked. Systemet ledte kun efter beholdning med status "Tilgængelig" (Available), og da der ingen fandtes, blev justeringen kasseret stille og roligt – uden fejl, uden alarm og uden logbesked.

Det betød, at POS-systemet troede justeringen var gennemført, mens lageret i PeakWMS forblev uændret. Uoverensstemmelsen mellem POS og WMS blev først opdaget ved en senere lageroptælling eller ved manuel kontrol.

Fejlen gjaldt alle POS-integrationer: FrontSystems, Shopify POS og OpenAPI (adjustStockInStore), da de alle bruger den samme underliggende metode.

Hvad er rettet?
Når systemet modtager en negativ lagerjustering og kun finder beholdning i QA-status (men ingen tilgængelig beholdning), oprettes nu en alarm i PeakWMS, der tydeligt angiver, at justeringen ikke kunne gennemføres, fordi beholdningen er i QA-status.

Selve QA-beholdningen justeres ikke automatisk – designvalget er bevidst, da QA-varer netop er spærret og ikke bør ændres uden eksplicit frigivelse. Alarmen sikrer, at lageroperatøren bliver opmærksom på problemet og kan håndtere det manuelt.

Varemodtagelse: "Luk indkøbslevering"-knappen er nu tilgængelig efter modtagelse af sidste linje på indkøbsordren

Når indkøbsleveringer (Inbound Deliveries) var aktiveret og pallemodtagelse var slået fra, blev lagermedarbejderen sendt direkte tilbage til ordreoversigten efter modtagelse af den sidste linje på en indkøbsordre. Men knappen "Luk indkøbslevering" findes kun på ordrens linjeoversigt – og da medarbejderen aldrig nåede at se den skærm, var der ingen mulighed for at lukke indkøbsleveringen fra worker-appen. En administrator måtte i stedet lukke leveringen manuelt via admin-dialogen.

Hvad er rettet?
Når den sidste linje modtages på en indkøbsordre med en tilknyttet indkøbslevering (og pallemodtagelse er slået fra), forbliver medarbejderen nu på linjeoversigten i stedet for at blive sendt tilbage til ordreoversigten. Her vises knappen "Luk indkøbslevering", og medarbejderen kan lukke leveringen direkte – uden at involvere en administrator.

Luk indkøbslevering: Medarbejderen kan lukke indkøbsleveringen med ét tryk og bliver derefter ført tilbage til ordreoversigten.
Spring over: Medarbejderen kan også vælge at gå tilbage til ordreoversigten uden at lukke indkøbsleveringen – leveringen forbliver åben og kan lukkes senere.
Ikke tilladt at lukke: Hvis medarbejderen ikke har rettighed til at lukke (allowedToClose = false), sendes medarbejderen direkte til ordreoversigten som hidtil.

Ikke berørt:

Ordrer uden indkøbslevering følger det eksisterende flow med luk-ordre-dialogen.
Ordrer med pallemodtagelse aktiveret er uændrede – her forbliver medarbejderen allerede på linjeoversigten.
Automatisk ordrevalg-tilstand er ikke berørt – her tildeles ingen indkøbslevering, og flowet er uændret.

Indkøb/Kreditnota: "Opret"-knappen er nu altid aktiv på indkøbsordrer oprettet via OpenAPI eller ERP

Når en indkøbsordre var oprettet via OpenAPI eller en ERP-integration uden at angive en forecast-metode, blev feltet forecastMethod gemt som null i systemet. Det forhindrede brugeren i at oprette en kreditnota fra indkøbsordre – "Opret"-knappen forblev inaktiv, og kreditnotaen kunne ikke oprettes.

Hvad skete der?
Kreditnota-dialogen kræver, at forecast-metoden er sat på indkøbsordren, for at "Opret"-knappen aktiveres. Når ordren blev oprettet manuelt i PeakWMS, blev forecast-metoden altid sat automatisk. Men ved oprettelse via OpenAPI eller ERP-integrationer var feltet valgfrit – og blev det ikke angivet, forblev det null. Det var ikke synligt for brugeren, og der blev ikke vist nogen fejlbesked – knappen var bare nedtonet uden forklaring.

Hvad er rettet?
Når en indkøbsordre oprettes eller opdateres via OpenAPI eller en ERP-integration, og der ikke er angivet en forecast-metode, sættes den nu automatisk til standardværdien "Empty". Det sikrer, at alle indkøbsordrer altid har en gyldig forecast-metode – og at kreditnotaer kan oprettes uden problemer.

Rettelsen gælder både nye indkøbsordrer og redigering af eksisterende ordrer via OpenAPI og ERP-integrationer.

Shopify: Integrationsfelter nulstilles ikke længere ved hentning af access token

Når en administrator hentede et nyt Shopify access token via OAuth-flowet, blev alle øvrige felter i integrationsopsætningen nulstillet til standardværdier – kun Client ID, Client Secret, Web URL og det nye access token blev bevaret. Gemte administratoren formularen i denne tilstand, blev den eksisterende integration overskrevet med tomme eller default-værdier.

Hvad skete der?
Shopify OAuth-flowet redirecter browseren til Shopify til godkendelse og tilbage til PeakWMS. Ved tilbagekomsten genopbyggede systemet formularen fra bunden som en blank formular og indsatte derefter kun de 4 OAuth-relaterede felter. Alle øvrige felter – integrationsnavn, lageropsætning (warehouse hosts), vareejer, plukketype, notifikationsindstillinger m.fl. – forblev på standardværdier, selvom de allerede var konfigureret og gemt.

Problemet ramte både redigering af eksisterende Shopify-integrationer og oprettelse af nye, hvor brugeren havde udfyldt felter inden OAuth-redirectet.

Hvad er rettet?

Efter OAuth-callback gendannes nu alle eksisterende feltværdier fra den gemte integration, inden de 4 OAuth-felter opdateres med de nye værdier. Formularen ser ud præcis som før redirectet – blot med et nyt access token. Ingen data går tabt.

Zonepluk: For tidlig kasse-scanning ved pluk af varer fra lastbærere (LoadUnits)

Når en lagermedarbejder plukkede varer i et zonepluk-flow, og en af varerne lå i en lastbærer (palle eller kasse på en lokation), kunne systemet fejlagtigt vise en kasse-scanning (target confirmation) mellem to pluk i samme zone – selvom der stadig var flere pluklinjer tilbage i zonen.

Hvad skete der?
Mellem hvert pluk tjekker systemet, om den netop afsluttede linje var den sidste i zonen. Hvis ja, beder systemet medarbejderen om at scanne mål-kassen, inden der skiftes til den næste zone. Tjekket ledte efter andre uplukede linjer i samme plukzone – men kun via to af fire mulige stier til plukzonen (Lokation → Reol → Plukzone og Lokation → Plukzone). De to stier, der går via lastbærer (Lastbærer → Lokation → Plukzone og Lastbærer → Lokation → Reol → Plukzone), blev ikke medtaget.

Resultatet var, at linjer fra lastbærere ikke blev talt med, og systemet troede, der kun var én linje tilbage i zonen. Medarbejderen blev bedt om en unødvendig kasse-scanning – og oplevede derefter, at der alligevel var flere pluk i samme zone.

Hvad er rettet?

Tjekket medtager nu alle fire stier til plukzonen – inkl. de to stier via lastbærer. Dermed tælles alle uplukede linjer korrekt med, og kasse-scanningen vises kun, når medarbejderen reelt er færdig med den sidste pluklinje i zonen.

Når en administrator højreklikkede på Indstillinger-knappen i sidebaren, blev browserens kontekstmenu – med muligheder som "Åbn i ny fane" og "Åbn i nyt vindue" – ikke vist. I stedet skete der enten ingenting, eller en forkert menu blev vist. Det betød, at det ikke var muligt at åbne indstillingssiden i en ny fane via højreklik – som det ellers er standard for alle andre links i en browser.

Hvad er rettet?

Indstillinger-knappen i sidebaren er nu implementeret som et korrekt link-element, så browserens standard-kontekstmenu vises ved højreklik. Administratoren kan dermed åbne indstillingssiden i en ny fane, kopiere linket eller bruge øvrige browserfunktioner – præcis som forventet.

HostedShop: "Test forbindelse" fejlede ved brug af andet sprog end "DK"

Når en administrator testede forbindelsen til en HostedShop-integration via "Test Connection"-knappen, og integrationen var konfigureret med et andet sprog end standardværdien "DK", fejlede testen med en misvisende fejlbesked: "The requested language: "DK" does not exist" – selvom de indtastede legitimationsoplysninger og sprogindstillinger var korrekte.

Hvad skete der?
"Test Connection"-funktionen opretter et midlertidigt forbindelsesobjekt med de indtastede værdier (URL, brugernavn, adgangskode) og bruger det til at kalde HostedShop's SOAP API. Da feltet LanguageIdentifier for nylig blev tilføjet til forbindelsesobjektet, blev det brugt af API-kaldet til at sætte sproget – men "Test Connection"-metoden kopierede ikke sprogindstillingen fra formularen. Det midlertidige objekt fik derfor altid standardværdien "DK", uanset hvad administratoren havde konfigureret.

På HostedShop-løsninger, der ikke har sproget "DK" konfigureret, fejlede forbindelsestesten med det samme – og fejlbeskeden pegede på "DK" i stedet for det sprog, administratoren faktisk havde indtastet. Det gav indtryk af, at der var et problem med legitimationsoplysningerne eller serveren, snarere end et sprogproblem.

Hvad er rettet?

"Test Connection"-metoden kopierer nu også LanguageIdentifier fra formularen til det midlertidige forbindelsesobjekt. Forbindelsestesten bruger dermed det sprog, administratoren har konfigureret – og fejlbeskeder afspejler den faktiske sprogindstilling, hvis den er ugyldig.

Flyt til eksternlager: Antal-displayet opdateres nu korrekt ved hurtige tryk på +/- knapperne

Når en lagermedarbejder brugte "Flyt til eksternlager"-flowet i worker-appen og trykkede hurtigt på + eller - knapperne for at justere antallet, blev det viste antal på skærmen ikke opdateret visuelt – selvom den faktiske værdi bag ved blev ændret korrekt. Medarbejderen kunne f.eks. trykke + to gange hurtigt og stadig se "1" (eller "0") på skærmen, mens den reelle værdi var "2".

Det betød, at medarbejderen ikke kunne stole på det viste antal og risikerede at bekræfte en flytning uden at vide, hvilket antal der faktisk blev sendt.

Hvad skete der?

Antal-feltet i worker-appens quantity-komponent var implementeret som et almindeligt klassefelt i stedet for et Angular signal. Kombineret med Angular's OnPush change detection-strategi på parent-komponenten betød det, at skærmen ikke blev gentegnet ved hurtige successive ændringer – Angular opdagede simpelthen ikke, at værdien var ændret.

Hvad er rettet?

Antal-feltet er konverteret til et Angular signal, så template-bindingen altid opdateres ved ændringer – uanset hvor hurtigt medarbejderen trykker på knapperne. Det viste antal matcher nu altid den faktiske værdi.

Rettelsen gælder alle flows i worker-appen, der bruger den pågældende quantity-komponent – ikke kun "Flyt til eksternlager".

Medarbejder Performance: "Inkl. alle medarbejdere"-funktionen er rettet

I Medarbejder Performance-oversigten har "Vælg alle"-knappen og det tilhørende flueben til at inkludere alle medarbejdere ikke fungeret korrekt. Flere fejl gjorde, at medarbejdervalget opførte sig uforudsigeligt og ikke matchede brugerens forventninger.

Hvad skete der?

Fravalg virkede ikke: Når alle medarbejdere var valgt via knappen, og man derefter fjernede markeringen, blev valget ikke nulstillet – alle medarbejdere forblev markeret.
Søgning virkede ikke: Søgefeltet i medarbejder-dropdown'en returnerede ikke korrekte resultater, hvilket gjorde det svært at finde specifikke medarbejdere.
Globale administratorer blev inkluderet: Når "Vælg alle" blev aktiveret, blev globale administratorer fejlagtigt medtaget i listen – selvom det kun var tiltænkt inaktive/slettede brugere.
"Inkl. alle" vistes i søgeresultater: Indstillingen "Include all" dukkede op som et element i søgeresultaterne, hvilket var forvirrende.
Valget forsvandt ved genindlæsning: Hvis brugeren bevidst ikke havde valgt nogen medarbejdere, blev dette ikke bevaret ved genindlæsning af siden – i stedet blev "alle brugere"-flaget (inkl. slettede brugere) aktiveret.

Hvad er rettet?

"Vælg alle"-knappen fungerer nu som en toggle: tryk én gang for at vælge alle, tryk igen for at fravælge alle.
Søgning i medarbejder-dropdown'en virker nu korrekt.
Globale administratorer inkluderes ikke længere ved "Vælg alle".
"Include all"-indstillingen vises ikke længere i søgeresultaterne.
Brugerens valg (inkl. intet valg) bevares korrekt ved genindlæsning af siden.

Release note 3.34

Ny indstilling: Hent shippinglabel automatisk efter pluk

Retur: Sprogoversættelser på produkter og returportal

Lageropsætning: Vælg flere lokationer og reoler på én gang

Stregkodescanning med GS1-koder virker nu ens i alle værktøjer

Manuel pak under pluk: Ny "Parkér"-mulighed ved manglende varer

Genopfyldning: Færre duplikerede opgaver og mulighed for at samle pluk

Cross-docking: Vælg antal labels og angiv forsendelsesmål

Modtagelse: Import af serienumre via filupload

AutoStore

Alle stregkoder sendes nu med ved produktimport

Ordrer sendes nu korrekt til automationsystemet ved genberegning af plukgrupper

Plukkedato baseres nu på planlagt afsendelsesdato

Varemodtagelse: Fejlbesked ved scanning af automationslastbærer vises nu på dansk

Ordredato og -tidspunkt sendes nu med til AutoStore

OpenAPI

OpenAPI: Produktopdatering (Patch) via OpenAPI: Nyt endpoint til delvise ændringer

OpenAPI: Hurtigere oprettelse og opdatering af indkøbsordrer via OpenAPI

OpenAPI: Hurtigere håndtering af indkøbsordrelinjer via API

OpenAPI: Planlagt afsendelsesdato kan nu opdateres og ryddes på eksisterende ordrer

OpenAPI: Følgeseddelkommentar kan nu sættes via salgsordrer

OpenAPI: Lange svartider ved oprettelse og opdatering af indkøbsordrer er elimineret

OpenAPI: Plukket serienummer, holdbarhedsdato og lotnummer er nu tilgængelige på plukordrelinjer

Performance opdateringer

Ordrer: Hurtigere generering af følgesedler og ordredokumenter

Beholdning: Hurtigere produktsøgning

Indkøbsbehov: Beregning er nu hurtigere og mere stabil

Lageværdirapport: Hurtigere beregning af lagerbalancen

StockAdjust: Forbedret ydeevne ved lagerjusteringer af bundle-produkter

Øvrige opdateringer

Tabelindstillinger: "Vis alle" og "Skjul alle" kolonner med ét klik

Bundles: Søgefeltet ryddes nu automatisk efter valg af underprodukt

Varemodtagelse: Nu kan alle emballagetyper vælges – også styks-enheder

Homerunner: Udvidet opsætning og automatisk afsendelse for farligt gods

Lotstyring: Delvist pluk nu muligt, når lot ikke er fastlåst

Ordrer: Send det, der er på lager, ved første frigivelse

Webshipper: Opsætning af fragtprodukter via Host ID

Homerunner: Fragtpris sendes nu med i forsendelsesdata til toldbrug

Retur: Separat leveringsadresse for ombytningsforsendelser

Flyt lastbærer: Vælg specifikke lastbærere fra en lokation

Pallepluk: Print følgeseddel og ordrelabel på én gang ved palleafslutning

Ordrer: "Planlagt afsendingsdato" omdøbt til "Planlagt frigivelsesdato" + nyt felt "Planlagt afsendelsesdato"

Pallepluk: Vis kommende add-on-top-linjer på konsolideringsskærmen

Pallepluk: Kundenavn vises nu på ordreinfoskærmen

Rapport over tomme lokationer: Varenumre fra faste plukkepladser vises nu

Rapport over afsendte enheder: Lotnummer og holdbarhedsdato er nu tilgængelige

Serienumre på lager: Nye felter "Leverandørkommentar" og "Tilhørsforhold"

Pallemodtagelse: "Print label"-knappen hedder nu "Print beholdningslabel"

Returordrelinjer: Alle felter er nu tilgængelige i linjeoversigten

Produktimport: ExternalLocation kan nu importeres via Excel

Bugfixes

Ordrefrigivelse: Fejl rettet ved ordrer med samme varenummer på flere linjer

Delvist pluk: Ny forsendelseslabel genereres nu korrekt ved split af ordre

Returhåndtering: Fejl rettet ved returnering af bundleprodukter

Pluk: Alternativ plukkelokation og nulpluk bruger nu den korrekte frigivelsesregel ved sammenlægning af regler

Dialoger: Datofiltre viser nu korrekte resultater i alle tidszoner

Homerunner returlabels: Rettet fejl ved kundeadresser med to adresselinjer

Lagerjustering: Plukkeordre med allerede plukkede linjer slettes ikke længere

Samsending: Annullering af hovedordre efter pluk blokerer ikke længere underordrer

Webshipper: Kundenavn vises ikke længere dobbelt på forsendelseslabels til privatadresser

Pakkebord: "Send igen"-ordrer blokerer ikke længere pakkebordet

Konsolidering: Annullerede pluklinjer blokerer ikke længere pakning efter sammenlægning

Pallepluk: Nuloptælling udløses ikke længere, når der stadig er varer på lokationen

Business Central: Lagerjusteringer blokeres ikke længere af fejlede posteringer

3PL: Sletning af vareejer: Fejl med fragt-referencer blokerer ikke længere sletningen

Plukkegrupper: Sletning af plukkegruppe fejler ikke længere pga. arkiverede plukkeordrer

Lager: Sletning af tom reol fejler ikke længere pga. optællingslinjer

Lager: Sletning af lokationer blokeres ikke længere af inaktive plukkearbejdsstationer

Shipmondo: Kundenavn vises ikke længere dobbelt på pakkeshop-labels

POS-lagerjusteringer: Alarm ved forsøg på justering af varer i QA-status

Varemodtagelse: "Luk indkøbslevering"-knappen er nu tilgængelig efter modtagelse af sidste linje på indkøbsordren

Indkøb/Kreditnota: "Opret"-knappen er nu altid aktiv på indkøbsordrer oprettet via OpenAPI eller ERP

Shopify: Integrationsfelter nulstilles ikke længere ved hentning af access token

Zonepluk: For tidlig kasse-scanning ved pluk af varer fra lastbærere (LoadUnits)

Menu: Højreklik på "Indstillinger"-knappen åbner nu browserens kontekstmenu

HostedShop: "Test forbindelse" fejlede ved brug af andet sprog end "DK"

Flyt til eksternlager: Antal-displayet opdateres nu korrekt ved hurtige tryk på +/- knapperne

Medarbejder Performance: "Inkl. alle medarbejdere"-funktionen er rettet