VERSIE: 6.0.2026Geneva

De integratie met SendCloud is uitgebreid en verbeterd

Servicepunten & ShippingID
Het is nu mogelijk om een shippingId mee te geven aan een order voor levering bij een servicepunt. Wanneer dit ID aanwezig is, wordt de order automatisch als zodanig aangemeld en zijn de opties voor Transporteur en Servicelevel in de aanmeld-popup vergrendeld om fouten te voorkomen.

Bulkverwerking
Het proces voor het gelijktijdig aanmelden van meerdere orders is geoptimaliseerd. Er kan gekozen worden voor een uniforme verwerking (instelling uit popup) of verwerking per order. Bij de laatste optie wordt gekeken naar de instellingen op het tabblad 'Bezorgen' of het shippingId. Indien een gekozen ServiceLevel niet wordt ondersteund, valt het systeem terug op de standaardwaarde.

API Aanpassing
De validatie op het veld packageServiceLevelTimeCode is verwijderd uit de REST API. Validatie van deze data vindt voortaan plaats aan de zijde van SendCloud.

CN 70780

SendCloud: Onderdrukken saldomelding bij AD orders

Er is een aanpassing gedaan in de verwerking van AD-orders via de SendCloud-integratie. Bij het omzetten van deze orders wordt de melding omtrent het klantordersaldo niet langer getoond.

CN 72659

Verbeterde afhandeling van sessie-timeouts

We hebben de sessie-afhandeling verbeterd om te voorkomen dat je onverwachts wordt uitgelogd na een korte periode van inactiviteit.

Je blijft nu ingelogd, zelfs wanneer je langer dan 15 minuten niet actief bent geweest. Dit werkt ook perfect wanneer je tegelijkertijd in meerdere browsertabbladen aan het werk bent.

CN 77234

Nieuw POS Berichtensysteem (POS Messages)

Er is een volledig nieuw berichtensysteem geïntroduceerd voor NEXT, de Backoffice en de POS. Dit systeem vervangt de oude 'Kassaberichten' functionaliteit en biedt verbeterde communicatiemogelijkheden tussen het hoofdkantoor en de winkels.

Let op: Deze functionaliteit is enkel beschikbaar in combinatie met de Nieuwe Backoffice; verdere informatie hierover volgt op een later moment.

Configuratie: Om het nieuwe systeem te activeren zijn er twee nieuwe geavanceerde instellingen:

• POSMessagesEnabled: Zet deze op True om het nieuwe systeem te gebruiken. (Bij False blijft de oude werking actief).

• POSMessagesPollingTime: Bepaalt hoe vaak (in seconden) de kassa controleert op nieuwe berichten (standaard: 30 seconden).

POS: Bij activatie verandert de knop 'E-mails' in 'Berichten'.

• Notificaties: Nieuwe berichten worden direct zichtbaar door een badge en een gekleurd kader om de knop.

• Inbox: Een vernieuwde interface toont de berichtenlijst. Berichten kunnen direct in het scherm gelezen worden.

• Beheer: Via een filter kan gewisseld worden tussen 'Alle' en 'Ongelezen' berichten. Reeds gelezen berichten kunnen handmatig weer op 'Ongelezen' worden gezet via de knop "Maak ongelezen".

Backoffice (Nieuw): In de nieuwe backoffice is een beheeromgeving toegevoegd voor het aanmaken en beheren van berichten.

• Overzicht: Inzicht in actieve berichten, looptijden en wijzigingen.

• Targeting: Selecteer eenvoudig specifieke winkels of groepen via de winkelboom-structuur.

• Validatie: Het systeem valideert verplichte velden bij het aanmaken.

• Bulkacties: Mogelijkheid om meerdere berichten tegelijk te verwijderen.

CN 70886

Herstel weergave regelkorting

Er is een correctie doorgevoerd in de weergave van kortingen op de kassa. Regelkortingen worden hierdoor weer op de juiste manier getoond in het transactieoverzicht.

CN 72219

Adyen EcoCheque - Validatie op Productgroepen

De integratie voor EcoCheques via Adyen is verbeterd met een striktere filtering op productgroepen.

• Validatie: Alleen producten die behoren tot geconfigureerde EcoCheque-productgroepen kunnen met deze kaart worden afgerekend.

• Gesplitste betaling: Bij een transactie met gemengde artikelen (Eco en niet-Eco) is een gesplitste betaling vereist.

• Foutafhandeling: Indien geprobeerd wordt een niet-toegestaan artikel met een EcoCheque te betalen, toont de kassa een duidelijke melding.

Configuratie & Weergave: Om deze functionaliteit te gebruiken, dient de betaalwijze geconfigureerd te zijn met specifieke (voorkeurs)productgroepen. Hoewel de transactie op de kassa nog steeds als 'PIN – Adyen Mastercard' wordt getoond, worden de EcoCheque-regels op de achtergrond correct toegepast. Reguliere pinbetalingen blijven ongewijzigd.

CN 72422

Optimalisaties stabiliteit en gebruikerservaring

Er is een reeks verbeteringen doorgevoerd in de Self-Checkout (SCO) om het proces voor zowel klant als medewerker te stroomlijnen.

Belangrijkste wijzigingen:

• Controles (Full Check): De afhandeling van een volledige controle na een steekproef is verbeterd (specifiek bij ForceAcceptFullCheck = false). Alleen daadwerkelijk gescande producten worden afgerekend en de totaalbedragen worden correct berekend.

• Communicatie: Meldingen tijdens controles zijn verduidelijkt, bijvoorbeeld bij het scannen van niet-aangemelde producten of de vraag of alles gescand is.

• Ondersteuning: De help-knop is nu beter beschikbaar tijdens het betaalproces en notificaties naar medewerkers worden consistenter verstuurd.

• Meertaligheid: Productmeldingen vallen nu correct terug op de originele taal indien een vertaling ontbreekt.

• Redencodes: De lijst met redenen (bijv. voor korting) is opgeschoond; alleen actieve en zichtbare opties worden getoond aan de gebruiker.

CN 69287

Configureerbare zichtbaarheid 'Help'-knop

De zichtbaarheid van de 'Help'-knop op de Zelfscankassa (SCO) is nu configureerbaar. Via een nieuwe setting in de werkstationconfiguratie kan bepaald worden of deze knop wordt getoond of verborgen.

Gebruik onderstaande instelling om de knop te verbergen: <Setting Key="HelpButtonEnabled" Value="False" />

Indien deze setting ontbreekt, blijft de 'Help'-knop standaard zichtbaar. De huidige werking blijft hiermee ongewijzigd, tenzij expliciet anders geconfigureerd.

CN 69825

Rapportages

Generieke versie Afgiftebewijs

Er is een generieke variant van het rapport 'Afgiftebewijs' beschikbaar gesteld. Deze kan worden geactiveerd door de instelling ReportProofOfDelivery de waarde ReportRepairDeliveryOrder_General te geven.

Daarnaast is het mogelijk om een voettekst aan dit rapport toe te voegen. Dit kan worden geconfigureerd via de vestigingsteksten door gebruik te maken van de code ProofofDeliveryFooter1.

CN 69828

Performanceverbetering en PDF-fix

Er zijn optimalisaties doorgevoerd om de performance van diverse rapporten binnen ASPOS te verbeteren. Daarnaast is een probleem verholpen waarbij het kopiëren van tekstselecties uit gegenereerde PDF-rapportages niet correct functioneerde.

CN 70395

Producten

Validatie bij verdeelde filiaalorders

Er is een extra controle toegevoegd aan het proces voor goederenontvangst. In de specifieke configuratie waarbij OrderDistributionMode op 3 staat en ReceivingCustOrderReq op False, wordt bij het binnenboeken nu expliciet gevalideerd of de ontvangst voortkomt uit een reeds verdeelde filiaalorder.

CN 71417

Tabblad Kleuren voor Matrix-producten

Er is een nieuw tabblad 'Kleuren' geïntroduceerd, specifiek zichtbaar bij Matrix-producten in ASPOS. Dit scherm faciliteert het centraal beheren van kleurtoewijzingen. Gebruikers kunnen actieve kleuren eenvoudig toevoegen, verwijderen en sorteren via een hiërarchische selector. Ingebouwde validatie voorkomt hierbij dubbele invoer.

CN 71444

Herstel zichtbaarheid leveranciersknop

Er is een correctie doorgevoerd in de weergave van het tabblad 'Leveranciers' binnen de module Productbeheer. De leveranciersknop is hierdoor weer correct zichtbaar en operationeel.

CN 72006

Extra controle bij het binnenboeken van verdeelde filiaalorders

Wat is er veranderd?

Bij het binnenboeken van ontvangsten (goederen) voert het systeem vanaf nu een extra, automatische controle uit, afhankelijk van je instellingen. Wanneer de configuratie zo staat ingesteld dat OrderDistributionMode de waarde 3 heeft én ReceivingCustOrderReq op False staat, checkt het systeem expliciet of de binnenkomende ontvangst gekoppeld is aan een filiaalorder die al verdeeld is.

Wat levert dit op?

Deze specifieke validatie zorgt ervoor dat goederenstromen en verdeelde filiaalorders onder deze instellingen altijd correct aan elkaar gekoppeld blijven. Je hoeft hier zelf geen extra handelingen voor te verrichten; het systeem doet dit volledig automatisch op de achtergrond tijdens het reguliere binnenboeken.

CN 74028

Klanten

Optimalisatie validatie kits bij orderwijzigingen

Het validatieproces van het endpoint PATCH /customer-order-lines/{id} is aangepast. Bij het wijzigen van een bestaande klantorderregel vindt er geen hernieuwde validatie van de kit-samenstelling plaats op basis van de actuele productconfiguratie. Kits gekoppeld aan een moederartikel worden hierdoor altijd geaccepteerd. Dit voorkomt onnodige blokkades bij het doorvoeren van eenvoudige mutaties, zoals een prijsaanpassing.

CN 65538

Ondersteuning automatische annulering restorder

De REST services ondersteunen nu de POSCancelCustOrdBackord instelling, conform de bestaande POS-functionaliteit. Wanneer deze instelling actief is, worden bij het afronden van een transactie via het POST /api/transactions/Commit endpoint alle niet-verwerkte orderregels automatisch geannuleerd.

CN 65541

Achtergrondtaak voor Cyclustellingen

Voor de operationele werking van de nieuwe cyclustellingen is de inrichting van een specifieke achtergrondtaak vereist. Deze taak zorgt voor de periodieke generatie van tellingen. De configuratie dient eenmalig via de API te geschieden door een taak van het type CycleCount aan te maken op hoofdkantoorniveau.

Gebruik onderstaande JSON-payload via POST api/background-task-configurations om de taak in te stellen (voorbeeld: controle elke 5 minuten):

{

  "name": "Create StockCounts based on CycleCounts",

  "backgroundTaskType": "CycleCount",

  "cronExpression": "0 0/5 * * * ?",

  "enabled": true,

  "storeId": 1 // Let op: Dit moet het ID van het Hoofdkantoor zijn

}

CN 67280

Ondersteuning Wasteless Pricing Scancodes

Het endpoint POST /api/scancodes/Load is uitgebreid met ondersteuning voor 'Wasteless pricing' scancodes. Dit maakt het mogelijk om via een samengestelde string direct kortingen toe te passen.

Het vereiste formaat is: [scancodeartikel]|[handelingnr]|[hoeveelheid korting]|[redencode korting]

Voorbeelden:

• Percentage korting: 119|I0|10K|OTHERDISCOUNT

• Bedrag korting: 119|I0|1.50B|OTHERDISCOUNT

CN 70839

Fallback naar standaardtaal bij Product Memos

Bij de product GET-endpoints is een uitbreiding gedaan op de expand=memos functionaliteit. Door de parameter $includeDefaultLanguage=true mee te geven, wordt nu de memo in de standaardtaal (zoals ingesteld in appSettings) opgehaald indien de memo in de opgevraagde taal niet bestaat.

CN 69287

Reparatieorders: Verwerking verwachte betalingen via Next

De verwerking van verwachte betalingen bij reparatieorders is gemoderniseerd. Deze transacties worden nu afgehandeld via Next in plaats van de verouderde backoffice-omgeving. Hiermee is de werkwijze consistent gemaakt met de logica van het Klantorder-scherm.

CN 70857

Introductie Internal POS messaging system

Er is een nieuwe set API-endpoints geïntroduceerd ter ondersteuning van een intern berichtensysteem voor de kassa. Hiermee kunnen berichten centraal worden aangemaakt en gericht worden verstuurd naar specifieke winkels of werkstations.

Let op: Dit betreft de technische API-implementatie; de visuele integratie in de POS- en Backoffice-interface volgt in een latere fase.

Beschikbare endpoints:

Berichtenbeheer (/api/pos-messages)

• GET – Haalt een lijst op van actieve berichten. Ondersteunt filtering op WorkstationId en OnlyUnread. Resultaten worden automatisch gefilterd op geldigheid (datum/tijd).

• GET /{id} – Haalt details en leesbevestigingen op van een specifiek bericht.

• POST – Maakt een nieuw bericht aan (inclusief parameters voor inhoud, geldigheidsperiode, doelwinkel en prioriteit).

• PATCH /{id} – Wijzigt een bestaand bericht (m.u.v. de winkel-ID).

• DELETE /{id} – Verwijdert een bericht.

Leesbevestigingen (/api/pos-message-acknowledgements)

• POST – Markeert een bericht als gelezen voor een specifiek werkstation en gebruiker.

• DELETE /{id} – Maakt een leesbevestiging ongedaan (zet status terug op 'ongelezen').

CN 70885

Beheer van productkleuren

De REST API is uitgebreid met functionaliteit voor het volledig beheren van productkleuren. Deze toevoeging ondersteunt het nieuwe tabblad 'Kleuren' op de productkaart in de backoffice.

De volgende endpoints zijn beschikbaar gesteld voor het aanmaken, inzien, wijzigen en verwijderen van kleuren:

• GET & POST /api/product-colors

• GET, PATCH & DELETE /api/product-colors/{id}

CN 71443

Omzetten inkooporder naar pre-order

Er is nieuwe functionaliteit toegevoegd aan de REST services om een inkooporder te converteren naar een pre-order. Via het nieuwe endpoint POST /api/purchase-orders/{id}/ConvertToPreOrder kan een inkooporder met de status 'Te Bestellen' direct worden omgezet naar de status 'Pre-order aanmelding'.

CN 71954

Optimalisatie transaction archiving endpoints

Alle GET-endpoints binnen de Transaction Archiving API zijn geconverteerd naar POST-requests. Hierbij worden de parameters verplaatst van de URL naar de request body. Deze wijziging voorkomt limietoverschrijdingen van de URL-lengte. De structuur van de responses blijft ongewijzigd. Zowel AsposNext als de nieuwe Backoffice zijn aangepast om deze nieuwe werkwijze te ondersteunen.

CN 71961

Validatie betalingen bij Hibernate-transacties

Er is een extra validatie toegevoegd aan het POST /api/transactions/Hibernate endpoint. Het is niet langer toegestaan om een betaling mee te sturen bij het parkeren (hibernaten) van een transactie. Requests die toch betalingsinformatie bevatten, worden voortaan geweigerd.

CN 71976

Wijziging standaardsortering klantfacturen

De standaard sorteringsvolgorde van het GET /api/customer-invoices endpoint is aangepast. De resultaten worden nu standaard gesorteerd op ID aflopend (Id DESC) in plaats van op factuurdatum (InvoiceDate DESC).

CN 71982

Nieuw veld 'isValidated' voor werkstations

De endpoints voor werkstations (workstations) zijn uitgebreid met het veld isValidated. Dit veld wordt ondersteund binnen de GET, POST en PATCH methoden. De standaardwaarde is ingesteld op false en de status wordt gesynchroniseerd met de backoffice.

CN 71995

Genereren Inkooporder-rapportages

De endpoints api/reports/Generate en api/reports/GenerateUrl zijn uitgebreid met ondersteuning voor het genereren van inkooporder-rapportages. Het systeem valideert hierbij of de opgegeven selectionIds verwijzen naar geldige ID's in de purchaseorders-tabel.

De ondersteuning omvat de volgende varianten (zoals gedocumenteerd in de API):

• Intern

• Extern

• Advies

• Backorder

• E-mailbijlage

CN 72060

Uitbreiding filters en statuswijziging secties

Het endpoint GET /api/stock-count-sections is uitgebreid met de filters states en stockCountIds om gerichter data op te kunnen vragen. Daarnaast is een terminologiewijziging doorgevoerd in de statusvermelding: de status Pending wordt voortaan aangeduid als Open.

CN 72046

POS Berichten - Uitgebreide filtering en validatie

Er zijn uitbreidingen en verbeteringen doorgevoerd in de endpoints voor POS-berichten (/api/pos-messages).

Nieuwe functionaliteit:

• Store Filtering: Het GET-endpoint ondersteunt nu de parameter StoreIds. Hiermee kunnen berichten voor meerdere winkels tegelijk worden opgehaald, waarbij rekening wordt gehouden met de hiërarchische structuur (parent/child relaties).

Verbeterde validatie (PATCH):

• Content: De velden Subject en Message mogen niet leeg worden gelaten.

• Datums: Er is een strikte controle toegevoegd die voorkomt dat StartTime ná EndTime valt. Deze validatie werkt ook bij het wijzigen van slechts één van beide velden, door de nieuwe invoer te toetsen aan de bestaande database-waarde.

CN 72332

Bugfix aanmaken pickregels bij sortering op leverancier

Er is een correctie doorgevoerd in het endpoint POST /api/customer-orders/{id}/CreatePickingLines. Voorheen kon hier een 500-foutmelding optreden wanneer de picklijstsortering was ingesteld op leverancierscode (PickSortOrder = 4) en een orderregel een artikel zonder voorkeursleverancier bevatte. Dit scenario wordt nu correct afgehandeld.

CN 72384

• 05/02/2026: Verdelen korting werkt niet zoals verwacht

Wijziging doorgevoerd zodat wanneer de setting POSDivideDiscounts op True staat de korting op de POS over de regels wordt verdeeld op het moment dat er een regel (welke bij een mixmatch hoort) wordt besteld op de POS.

TN 1412851

• 10/02/2026: Bevinding deelbetaling met dezelfde betaalsoorten

De afhandeling van artikelgroepen die gekoppeld zijn aan een betaalmethode is gecorrigeerd. Voorheen kreeg u bij een deelbetaling met bijvoorbeeld een maaltijd- of ecocheque onterecht de foutmelding dat er geen toegestane artikelen op de bon stonden. Dit probleem is verholpen. Vanaf nu kunt u kassaregels probleemloos deels afrekenen met deze specifieke betaalmethoden.

TN 1412851

• 17/02/2026: Factuurcontrole onjuist

Aanpassing doorgevoerd in de factuurcontrole zodat artikelen niet meer geaggregeerd worden. Dit zodat afzonderlijke regels met korting juist verwerkt kunnen worden.

TN 1415450

• 19/02/2026: Aanmelden klantorder bij TransSmart gebruikt factuuradres

Wijziging doorgevoerd zodat bij het aanmelden van labels bij TransSmart het bezorgadres van het tablad bezorgen weer gebruikt word.

TN 1421060

• 27/02/2026: Batch picking werkt niet meer zoals verwacht

Aanpassing doorgevoerd waarbij de PDA weer bij het 1e artikel in de pickbatch begint.

TN 1421161

• 27/02/2026: Interfiliaalorder op PDA werkt niet

Wijziging doorgevoerd waardoor er weer correct gebruik gemaakt kan worden van de functie Interfiliaalorder maken.

TN 1411355

• 05/03/2026: Sortering kitgroupregels behouden bij omzetten offerte naar order

Er traden validatiefouten op in CartCalc tijdens het omzetten van een offerte naar een verkooporder. Dit is verholpen door een aanpassing in de verwerking: de originele sortering van de kitgroupregels uit de offerte blijft vanaf nu exact behouden in de resulterende order. Hiermee worden de eerdere validatiefouten succesvol voorkomen.

TN 1423508

• 06/03/2026: Versiemismatch op webservers verholpen

Op enkele webservers ontstond een versiemismatch als gevolg van incorrecte browser caching. Er is een wijziging doorgevoerd in de reportserver om de afhandeling van deze caching aan te passen. Hierdoor worden de actuele bestanden weer consistent geladen en is de fout succesvol verholpen.

TN 1424278

• 16/03/2026: Gebruiksvriendelijkheid van Productmeldingen verbeterd

In de ASPOS Next Backoffice zijn diverse verbeteringen doorgevoerd op de Productmeldingen pagina. Volledige opmerkingen zijn nu direct in te zien via een hover-tooltip zonder de melding eerst te hoeven openen. Daarnaast keert de gebruiker na het sluiten van een voorraad pop-up (na het zoeken op barcode) weer correct terug naar de Productmeldingen in plaats van doorverwezen te worden naar Productbeheer. Tot slot is de contrastfout bij verwerkte wijzigingen verholpen, waardoor de tekst altijd duidelijk leesbaar blijft.

TN 1421993

• 18/03/2026: Producten uit klantorders bij voldoende voorraad uit besteladvies geweerd

Artikelen die deel uitmaken van een klantorder werden onterecht meegenomen in de berekening van het besteladvies, zelfs als de actuele winkelvoorraad toereikend was. De berekening is aangepast, waardoor deze producten niet langer op het advies verschijnen zolang er lokaal genoeg voorraad beschikbaar is.

TN 1426746

• 19/03/2026: Validatie op winkelcodes bij 2-fase productimport

Er is een extra controle op winkelcodes toegevoegd aan de 2-fase productimport. Deze validatie voorkomt dat een importbestand behorend tot een andere vestiging per ongeluk wordt ingelezen en verwerkt.

TN 1425047

• 25/03/2026: Meerdere e-mailadressen opgeven voor leveranciersbestellingen weer mogelijk

In de instellingen voor leveranciers is het veld 'Bestel e-mailadres' vernieuwd, waardoor het weer volledig wordt ondersteund om meerdere e-mailadressen in te vullen. Door de gewenste adressen simpelweg te scheiden met een puntkomma (;) kunnen bestellingen direct naar meerdere ontvangers tegelijk worden verstuurd. Hiermee is de situatie verholpen waarbij het systeem tijdelijk slechts één e-mailadres accepteerde.

TN 1422268

• 31/03/2026: Onterechte validatiemelding bij legacy kit-producten in REST-services verholpen

In de REST-services is een fout hersteld rondom de berekening van transacties (cartCalculate). Voorheen ontstond er onterecht een validatiemelding bij verouderde (legacy) kit-producten wanneer een regel gekoppeld was aan een customerOrderLineId, maar het hoofdproduct (parentProduct) ontbrak in het verzoek. Deze situatie is aangepast. Zodra er nu een customerOrderLineId wordt meegegeven, vinden er geen validaties meer plaats op ontbrekende kit-artikelen of -groepen. Hierdoor worden deze aanvragen weer succesvol en zonder foutmeldingen verwerkt.

TN 1430676

• 31/03/2026: Vastlopen SCO na pinbetaling en onvolledige logging verholpen

Er is een fout hersteld waarbij de Self-Checkout (SCO) kon blijven hangen na het voltooien van een elektronische betaling (EFT/pin). In de afhandeling bleek bovendien de situatie voor te komen dat de logging aan de client-zijde van de SCO niet altijd correct en volledig werd opgeslagen. Deze bug in de dataregistratie is opgelost, waardoor betalingen weer vlot worden afgerond en de loggegevens betrouwbaar worden vastgelegd.

TN 1429533

• 03/04/2026: Verwerking van te lange scancodes op de SCO en via REST-services gecorrigeerd

Er is een aanpassing doorgevoerd in Next en de achterliggende REST-services rondom het verwerken van scancodes. Voorheen ontstond er een fout op de Self-Checkout (SCO) wanneer deze scancodes van meer dan 30 karakters probeerde te verwerken.

Om dit te verhelpen, worden opgegeven scancodes die langer zijn dan 30 tekens bij de REST-endpoints POST /api/transactions/Commit en POST /api/customer-orders vanaf nu automatisch afgekapt en opgeslagen tot maximaal 30 karakters. Hiermee worden storingen bij het verwerken en opslaan van transacties en klantorders voorkomen.

TN 1431016

• 07/04/2026: Onjuiste weergave en kortingsberekening wichtproducten bij offline kassa hersteld

In de offline modus van de kassa (POS) ontstond er een fout bij het scannen van wichtproducten met een prijsbarcode. Het product werd niet correct getoond, wat ertoe leidde dat promoties en kortingen eveneens onjuist werden berekend. Deze situatie is gecorrigeerd, waardoor gewichtsartikelen ook zonder actieve netwerkverbinding weer foutloos worden gescand en de bijbehorende acties correct worden toegepast.

TN 1422854

• 07/04/2026: Onbruikbare matrix-rapportages en rechten verwijderd uit overzicht

Er is een opschoning doorgevoerd in het rapportage-overzicht. Onbruikbare rapporten die tot foutmeldingen leidden (zoals "Resale Figures Matrix Layout") en nooit in gebruik zijn geweest, zijn samen met de bijbehorende rechten definitief verwijderd uit het systeem.

Het betreft de volgende rapportages:

• ReportTurnoverNumbersMatrixLayout_General

• ReportResaleNumbersMatrixLayout_General

TN 1426035

• 07/04/2026: Terugkeren naar transactie na scannen retourbon en drukken op 'Totaal' hersteld

Er is een aanpassing doorgevoerd in de kassa (POS) waardoor het weer mogelijk is om na het scannen van een retourbon en het drukken op 'Totaal' terug te keren naar de geopende transactie. Dit geldt voor situaties waarin er na de totaaltoets nog geen betalingen zijn verricht die direct worden verwerkt. Hierdoor kunnen transacties voorafgaand aan de definitieve betaling indien nodig alsnog worden aangepast.

TN 1426306

• 13/04/2026: Verwerking useFreeStock bij aanmaken pickregels in REST-services gecorrigeerd

In de REST-services is een aanpassing doorgevoerd bij het endpoint POST /api/customer-orders/{id}/CreatePickingLines. Wanneer bij het aanroepen van dit endpoint de parameter useFreeStock = true wordt meegegeven en er voor geen van de orderregels vrije voorraad aanwezig is, worden er vanaf nu geen pickregels of picklijsten meer aangemaakt. Hierdoor sluit de afhandeling van pickopdrachten weer exact aan op de verwachte logica omtrent vrije voorraad.

TN 1430832

• 13/04/2026: Dubbele transacties bij PayAndGo verholpen

Er zijn een aantal aanpassingen doorgevoerd binnen PayAndGo om de verwerking van betalingen aan te scherpen. Met deze wijzigingen wordt voorkomen dat er onbedoeld dubbele transacties in het systeem ontstaan. Hierdoor verlopen betalingen via PayAndGo voortaan altijd betrouwbaar en wordt een meervoudige verwerking van een en dezelfde betaling uitgesloten.

CN 75007

• 14/04/2026: Timeouts bij openen van menu 'Pickbatches' op PDA verholpen

Er is een performance-optimalisatie doorgevoerd in de PDA voor het menupunt 'Pickbatches'. Voorheen kon de situatie ontstaan dat het scherm bij het openen te lang bleef laden en tegen een timeout aanliep. Met deze aanpassing opent het overzicht weer snel en zonder storingen, zodat medewerkers direct en zonder onderbrekingen toegang hebben tot de pickbatches.

TN 1432831

• 15/04/2026: Foutmelding bij orderverwerking met verzend- of handelingskosten verholpen

Er is een aanpassing doorgevoerd in de procedure voor het verwerken van orders. Voorheen kon er een foutmelding optreden wanneer er verzendkosten of handelingskosten aan een klantorder waren toegevoegd. Dit is gecorrigeerd, waardoor orders met dit soort aanvullende kosten vanaf nu weer zonder problemen en foutloos worden verwerkt.

TN 1432845

• 17/04/2026: Validatie POSMaximumQuantity in kassa uitgebreid naar negatieve aantallen

Er is een aanpassing doorgevoerd in de kassa (POS) voor het valideren van ingevoerde aantallen. De instelling POSMaximumQuantity valideert vanaf nu ook op negatieve hoeveelheden, wat voorkomt dat er bij bijvoorbeeld retouren onbeperkte aantallen worden ingevoerd.

Als de instelling staat ingesteld op een waarde van 999, mogen er geen aantallen meer worden ingevoerd die hoger zijn dan 999 of lager dan -999. Wanneer een gebruiker deze limiet overschrijdt, toont de POS hier direct een melding van.

TN 1430395

• 17/04/2026: Onterechte status 'open' bij volledig verwerkte klantorders verholpen

Er is een wijziging doorgevoerd in de statusafhandeling van klantorders. In specifieke gevallen kon het voorkomen dat een order onterecht de status 'open' behield of kreeg, hoewel alle afzonderlijke orderregels al volledig waren verwerkt. Deze situatie is gecorrigeerd, waardoor de status van een klantorder voortaan altijd correct wordt bijgewerkt zodra alle regels zijn afgerond.

TN 1433238

• 17/04/2026: Weergave huisnummertoevoeging op pakbon rapportage hersteld

Er is een aanpassing doorgevoerd in de pakbon rapportage. Voorheen werd de huisnummertoevoeging niet getoond wanneer het afleveradres niet direct in de header van de order stond, maar wel aanwezig was in de adressenlijst. Dit is gecorrigeerd, waardoor het afleveradres inclusief eventuele toevoeging in alle situaties weer volledig en correct op de pakbon verschijnt.

TN 1431896

• 22/04/2026: Aantallen gekoppelde kitproducten bij klantorders op kassa hersteld

Er is een wijziging doorgevoerd in de kassa (POS) bij het verwerken van klantorders. Bij het ophalen van een openstaande klantorder(regel) worden vanaf nu altijd de juiste aantallen van het gekoppelde kitproduct geladen.

Daarnaast worden de aantallen van de onderliggende kitregels voortaan automatisch en correct mee aangepast wanneer het aantal op de hoofdregel op de kassa wordt gewijzigd.

TN 1431950

• 22/04/2026: Verwijderen van klantdocumenten hersteld via unieke ID-generatie

Er is een aanpassing doorgevoerd bij het beheren van documenten die aan een klant zijn gekoppeld. Voorheen kon het verwijderen van een document soms mislukken, omdat het systeem keek naar de combinatie van omschrijving en type in plaats van een unieke sleutel.

Vanaf nu genereert het systeem bij het toevoegen van een document direct een uniek ID. Hierdoor kunnen klantdocumenten voortaan altijd eenduidig worden geïdentificeerd en probleemloos worden verwijderd.

TN 1435120

• 23/04/2026: Verwijderen van productrelaties bij verwijderen van product hersteld

Er is een aanpassing doorgevoerd bij het verwijderen van producten. Wanneer een product wordt verwijderd, worden voortaan ook de gekoppelde productrelaties (product connections) automatisch uit het systeem verwijderd.

Daarnaast is de zoekfunctionaliteit aangepast: producten die op een ander tabblad reeds zijn verwijderd, kunnen niet langer worden gevonden bij het selecteren van artikelen om nieuwe productrelaties mee aan te maken.

TN 1429928

• 23/04/2026: Onterechte aanmaak van inkooporderregels bij WebOrderCollect verholpen

Er is een wijziging doorgevoerd in de procedure die wordt gebruikt binnen de WebOrderCollect-taak. Voorheen kon het voorkomen dat er onterecht een inkooporderregel werd aangemaakt bij het verzamelen van orders voor producten met een vrije voorraad van 0 of minder (<= 0). Deze logica is hersteld, waardoor inkooporderregels in deze situatie niet langer onbedoeld worden gegenereerd.

TN 1429075

• 24/04/2026: EVL-bonuspunten bij retouren gelijkgesteld aan verkoop

Er is een wijziging doorgevoerd in de verwerking van bonuspunten (EVL) bij retouren. Voorheen kon in bepaalde situaties het aantal afgetrokken bonuspunten op de transactieregel van een retour afwijken van het aantal punten dat bij de oorspronkelijke verkoop was toegekend.

Dit is hersteld, waardoor het aantal bonuspunten op de transactieregel bij een retour voortaan altijd exact overeenkomt met het aantal op de oorspronkelijke verkooptransactie.

TN 1424081

• 29/04/2026: Volgorde klantsaldomutaties in backoffice gecorrigeerd

Er is een wijziging doorgevoerd in de weergave van klantsaldomutaties in de backoffice. Voorheen konden mutaties in een onjuiste volgorde worden getoond doordat het overzicht werd gesorteerd op datum.

Vanaf nu worden de klantsaldomutaties gesorteerd op basis van OID in plaats van datum. Hierdoor worden alle mutaties voortaan altijd in de juiste, exacte volgorde weergegeven.

TN 1427202

• 29/04/2026: Dubbele prijswijzigingen bij bulk-update van leverancier verholpen

Er is een wijziging doorgevoerd voor het in bulk aanpassen van leveranciers. Voorheen kon de ongewenste situatie ontstaan dat er bij producten met een SGP dubbele prijswijzigingen werden aangemaakt.

Dit is gecorrigeerd, waardoor er bij het in bulk wijzigen van de leverancier voor deze artikelen geen dubbele prijswijzigingen meer worden gegenereerd.

TN 1431411

• 29/04/2026: Leverancierskorting bij ontvangstcontrole op PDA en backoffice hersteld

Er is een wijziging doorgevoerd in de verwerking van ontvangsten via een ontvangstcontrole op de PDA of in de backoffice. Voorheen kon de situatie ontstaan dat de eventuele leverancierskorting niet werd toegepast op producten die tijdens deze controle aan de ontvangst werden toegevoegd.

Dit is gecorrigeerd, waardoor artikelen die via een ontvangstcontrole worden toegevoegd vanaf nu altijd met de juiste leverancierskorting in de ontvangst worden opgenomen.

TN 1429936

• 13/05/2026: Nulbedragen voor verzend- en handelingskosten niet meer opgenomen in klantorder

Er is een wijziging doorgevoerd in de verwerking van verzend- en handelingskosten. Wanneer deze kosten na controle uitkomen op € 0,00, blijven ze wel zichtbaar op de bon, maar worden ze niet meer toegevoegd aan de klantorder.

Hiermee wordt voorkomen dat er regels met een waarde van € 0,00 onnodig in de klantorder worden opgenomen.

TN 1429936

• 18/05/2026: Automatisch toewijzen van standaardland via REST API hersteld

Er is een wijziging doorgevoerd bij het aanmaken van een klant via de REST API. Wanneer er bij het toevoegen van een nieuwe klant geen DefaultAddress wordt meegegeven in het POST-verzoek, kijkt het systeem vanaf nu automatisch naar de instelling DefaultCountry om het standaardland te bepalen.

Hierdoor wordt het land bij het aanmaken van klanten via de REST API voortaan wel automatisch gevuld, gelijk aan de werking in de backoffice.

TN 1436602

• 20/05/2026: Lengte van retourbarcode consistent gemaakt op rapporten, database en REST API

Er is een wijziging doorgevoerd in de weergave van retourbarcodes. Voorheen kon er een inconsistentie of afwijking in de lengte van de retourbarcode bestaan tussen de weergave op diverse rapporten, de database en de gegevens via de REST API.

Dit is gecorrigeerd, waardoor de retourbarcode op alle rapporten voortaan volledig consistent is met wat er in de database staat en via de REST API wordt teruggegeven.

TN 1431854

• 20/05/2026: Data-ophaling medewerker prestatierapport geoptimaliseerd

Er is een wijziging doorgevoerd in de onderliggende query die wordt gebruikt voor het ophalen van gegevens voor het medewerker prestatierapport.

Hierdoor worden de relevante prestatiecijfers en transactiegegevens voortaan weer correct en efficiënt in het rapport geladen en weergegeven.

TN 1435347

• 20/05/2026: Aanmaken van storejoblines uit orderregels hersteld

Er is een wijziging doorgevoerd in het aanmaken van storejoblines (winkeltaakregels) vanuit orderregels. Voorheen kon de situatie ontstaan dat de oorspronkelijke werkwijze voor het genereren van deze regels niet meer juist functioneerde.

Dit is hersteld, waardoor het aanmaken van storejoblines op basis van orderregels weer volledig volgens de vertrouwde en oude methodiek werkt.

TN 1442743

• 21/05/2026: Foutmelding bij verplaatsen van klantenkaart via REST API verholpen

Er is een foutsituatie opgelost in de REST-services bij het verplaatsen van een klantenkaart via het endpoint POST /api/customer-cards/{customerCardId}/Move. Voorheen kon hierbij in specifieke gevallen een database-foutmelding optreden (gerelateerd aan een ScanCodes constraint).

Dit is hersteld, waardoor het verplaatsen van klantenkaarten via het API-endpoint voortaan weer probleemloos en zonder foutmeldingen verloopt.

TN 1436986

• 22/05/2026: Tonen van pakboncorrecties in klanthistorie op kassa hersteld

Er is een wijziging doorgevoerd waardoor transacties van het type 'pakbon correctie' weer worden getoond in de historie van een klant op de kassa (POS). Hierdoor is het weer mogelijk om direct sales orders direct retour te nemen op basis van de transactiehistorie van de klant.

Deze transacties zijn zichtbaar wanneer de instellingen POSReturnMode = 1 en Turnoverondelivery = 1 actief zijn en de transactie een waarde hoger dan 0 heeft. Hierdoor worden negatieve correctietransacties automatisch uitgesloten.

TN 1435260

• 02/06/2026: Onjuiste inkoopaantallen bij aanmaken van besteladvies via PDA hersteld

Er is een aanpassing doorgevoerd bij het aanmaken van een besteladvies via de PDA. Voorheen kon het voorkomen dat de PDA bij het opstellen van een besteladvies niet de juiste inkoopaantallen overnam van de eigen voorkeursleverancier.

Dit is gecorrigeerd, waardoor de PDA bij het maken van een besteladvies vanaf nu altijd de juiste inkoopaantallen en -eenheden van de voorkeursleverancier hanteert.

TN 1436999

• 17/06/2026: Ontbrekende SCO-transacties in ASPOS hersteld

Er is een wijziging doorgevoerd in de verwerking van SCO-transacties (Self-Checkout) op versie Geneva. Voorheen kon het voorkomen dat sommige SCO-transacties na een succesvolle betaling niet werden geregistreerd in ASPOS.

Dit werd veroorzaakt doordat transactieregels soms ongeldige aantallen bevatten (nul of negatieve waarden), waardoor ASPOS de gehele transactie tijdens de validatie afkeurde. De SCO slaat vanaf nu automatisch regels met niet-positieve aantallen over voordat de transactie naar ASPOS wordt verzonden. Dit geldt voor reguliere artikelen, kitartikelen en geneste kitartikelen, waardoor SCO-transacties weer altijd correct worden vastgelegd. Tevens is er extra testdekking toegevoegd om het opnieuw optreden van deze situatie te voorkomen.

TN 1447488

• 18/06/2026: Openen van pakbonrapportage na omzetten van klantorder hersteld

Er is een wijziging doorgevoerd bij het openen van de pakbonrapportage na het omzetten van een klantorder naar een pakbon. Voorheen kon het voorkomen dat de rapportage op langzamere systemen niet werd geopend wanneer er snel dubbel werd geklikt op de betreffende link.

Dit is gecorrigeerd, waardoor de pakbonrapportage vanaf nu ook op langzamere systemen altijd betrouwbaar opent bij het (snel dubbel)klikken op de link.

TN 1427233

• 29/06/2026: Prestaties van webservices bij hoge belasting geoptimaliseerd

Er is een algemene prestatieverbetering doorgevoerd binnen de webservices. Hierdoor kunnen verzoeken tijdens periodes van hoge belasting (high load) sneller en efficiënter worden afgehandeld, wat resulteert in een hoger aantal verwerkte verzoeken per seconde. Dit zorgt voor meer capaciteit, betere responstijden en een stabielere verwerking tijdens piekmomenten.

CN 77097

• 07/007/2026: Gedrag van transactiedatumfilter in nieuwe Backoffice gelijkgetrokken met oude Backoffice

Er is een wijziging doorgevoerd in de Backoffice om de werking van het transactiedatumfilter weer volledig overeen te laten komen met het oude Transactiebeheer. Voorheen week het gedrag af, waardoor gebruikers het recht "Transactiedatum van/tot" ook nodig hadden voor het opvragen van transacties op één enkele dag.

Dit is aangepast. Gebruikers kunnen vanaf nu transacties voor elke afzonderlijke dag in het verleden selecteren zonder dat daarvoor het recht "Transactiedatum van/tot" vereist is. Dit recht is voortaan alleen nog nodig wanneer er een datumbereik van meer dan één dag wordt geselecteerd.

TN 1451361