VERSIE: 6.0.2026Kingston

Nieuwe KvK-koppeling: Sneller en foutloos zakelijke klanten aanmaken

Wat is er nieuw?
De integratie voor het ophalen van bedrijfsgegevens is flink vernieuwd. De bestaande CompanyInfo/Sizo-koppeling is vervangen door een directe integratie met de officiële KvK API. Hierdoor worden bedrijfsgegevens nu rechtstreeks, sneller en betrouwbaar vanuit de database van de Kamer van Koophandel opgehaald bij het aanmaken of zoeken van zakelijke klanten.

Hoe werkt het?

• Zoeken: Je zoekt eenvoudig op KvK-nummer of postcode + huisnummer.

• Selecteren: Staan er meerdere vestigingen op één adres? Dan kies je de juiste locatie via een pop-up.

• Automatisch invullen: Gegevens zoals bedrijfsnaam, adres, rechtsvorm en aantal medewerkers worden direct overgenomen in het klantformulier.

Belangrijk om te weten

• Eigen KvK-account nodig: Jouw organisatie moet zelf een account (API-sleutel) afnemen bij de KvK. Zonder dit account kan het systeem geen gegevens ophalen.

• Zoeken op bedrijfsnaam kan niet: De KvK ondersteunt het vrij zoeken op een bedrijfsnaam helaas niet via deze koppeling.

• Bestaande klanten: De gegevens van klanten die al in het systeem stonden, veranderen niet automatisch. Dit werkt alleen bij het aanmaken of handmatig opnieuw opzoeken van een klant.

Inrichting:

Vraag de API-toegang aan bij de KvK. Configureer daarna eenmalig de instellingen ASPOSCompanyInfoAPIkey en ASPOSCompanyInfoURL, en zet de CustomerCheckMethod op CompanyInfo. Zorg ook dat de stamgegevens voor het veld NumberOfEmployees (aantal medewerkers) zijn aangemaakt.

CN 74629

Gescheiden afhandeling voor PayByLink-refunds bij annuleringen

Wat is er nieuw?
Vanaf deze release is het mogelijk om refunds voor PayByLink-betalingen apart te administreren. Bij het (gedeeltelijk) annuleren van een klantorder die via PayByLink is afgerekend, wordt de refund vanaf nu geboekt op een specifiek PayByLink-refund-betaaltype. Voorheen verliep dit altijd via het standaard webshop refund-betaaltype. Deze wijziging vereenvoudigt de financiële afhandeling en administratie via Pay.nl aanzienlijk.

Hoe werkt de refund-splitsing?
Wanneer een order wordt geannuleerd, splitst het systeem het refundbedrag automatisch op:

• Via PayByLink: Het systeem boekt maximaal het bedrag dat oorspronkelijk via PayByLink is betaald, terug op het gekoppelde PBL-refund-betaaltype.

• Via Standaard Refund: Het eventuele restbedrag wordt via het standaard refund-betaaltype afgehandeld.

• Let op: Bij een gedeeltelijke annulering (bijvoorbeeld na een deellevering) wordt uiteraard alleen het niet-geleverde deel gerestitueerd, waarbij exact dezelfde logica geldt.

Rekenvoorbeeld:  Een klantorder van € 100,- is deels betaald via PayByLink (€ 60,-) en deels via PIN (€ 40,-). Bij een volledige annulering wordt € 60,- gerefund via het specifieke PBL-refund-betaaltype en € 40,- via het standaard refund-betaaltype.

Benodigde inrichting & Configuratie

Om gebruik te maken van deze nieuwe functionaliteit, is de volgende inrichting vereist op de betreffende stores. Doe je dit niet? Dan verandert er niets en blijft het huidige systeemgedrag intact (volledig backward compatible).

• Betaaltype aanmaken: Zorg dat het gewenste refund-betaaltype (bijv. PBLREF) bestaat en actief is op de store.

• Setting CustOrdCancelMakeTrans: Controleer of deze setting op Ja staat (dit was al een vereiste voor transactie-aanmaak bij annuleringen).

• Nieuwe setting configureren: Vul de nieuwe setting PaymentCodesRefundMethods in. Dit is de mapping van de originele betaaltype-code naar de refund-betaaltype-code.

Format voor PaymentCodesRefundMethods:

Gebruik het format PaymentCode^RefundCode (bijvoorbeeld: PBL^PBLREF). Wil je meerdere mappings instellen? Scheid deze dan met een sluisteken (|), bijvoorbeeld: PBL^PBLREF|IDEAL^IDEALREF.

Belangrijk om te weten (Out of Scope)

• Geen automatische Pay.nl verwerking: Deze update regelt puur de correcte administratieve boeking in de software. De daadwerkelijke financiële terugbetaling richting de klant via Pay.nl moet nog steeds separaat worden afgehandeld.

• CCV PayByLink: De splitsingsfunctionaliteit is momenteel uitsluitend getest voor Pay.nl, niet voor CCV PayByLink.

CN 74629

Directe pop-up melding op de kassa bij Pay&Go-betalingen

Wat is er nieuw?

Wanneer een klant een Pay&Go-betaling succesvol afrondt, genereert het systeem vanaf nu direct een urgent POS-bericht. Dit bericht verschijnt automatisch als een pop-up (toast-notificatie) op het kassascherm, zodat de kassamedewerker direct kan zien wat er is afgerekend.

Hoe werkt het?

• Duidelijk overzicht: De pop-up toont de gekochte artikelen in het verbeterde formaat: [aantal] x [artikelnaam] [verkoopprijs].

• Slimme synchronisatie: Zodra de melding op één kassa is weergegeven, wordt deze direct voor alle werkstations binnen de winkel als gelezen gemarkeerd (ReadOnSingleDevice = true). Hierdoor krijgen collega's op andere kassa's niet onnodig dezelfde pop-up te zien.

• Nacontrole: Het bericht verdwijnt van het scherm, maar blijft voor eventuele controle altijd beschikbaar in het POS-berichtenoverzicht (via de knop "Berichten").

Belangrijk om te weten:

• De pop-up maakt gebruik van het standaard POS-ontwerp; de stijl of weergaveduur is niet aanpasbaar.

• Deze urgente status wordt uitsluitend automatisch toegekend via de Pay&Go-applicatie en kan niet handmatig worden meegegeven aan berichten uit de Backoffice.

Vereiste inrichting:

Om deze functionaliteit te activeren, moeten de volgende instellingen per winkel worden geconfigureerd (gevolgd door een herstart van de POS):

1. Zet POSMessagesEnabled op True (om kassaberichten in te schakelen).

2. Zet de nieuwe instelling PayandGoUrgent op True (om de automatische pop-up te activeren).

3. Optioneel: Verlaag de poll-interval bij POSMessagesPolling (standaard 30 seconden) naar bijvoorbeeld 10 seconden voor een snellere weergave op het scherm.

De bestaande voorwaarde dat de betaalmethode PAYNLPAYANDGO actief moet zijn op de winkel blijft ongewijzigd van kracht.

CN 72866

Actuele voorraad nu ook zichtbaar bij externe wachtstandbonnen op de kassa

Wat is er veranderd?

Wanneer je op de kassa (POS) een wachtstandbon ophaalt die afkomstig is uit een externe applicatie (zoals POS Next of de Pay & Go oplossing), kan de POS nu direct de actuele voorraad van de gescande artikelen tonen.

Wanneer is dit zichtbaar?

Deze voorraadweergave wordt automatisch geactiveerd wanneer de geavanceerde instelling POSAllowSwitchWarehouse op True staat. Zodra de geparkeerde transactie wordt ingeladen, zie je direct de actuele voorraadstanden op het scherm, zoals weergegeven in het bijbehorende screenshot.

Technische achtergrond (API)

Om dit mogelijk te maken, is de communicatie tussen de POS en de REST API geoptimaliseerd. De aanpassing zit in de manier waarop de POS deze transacties ophaalt, specifiek via het /api/transactions/Hibernate endpoint.

Wanneer er een POST verzoek wordt gedaan, zoals in het onderstaande voorbeeld, vertaalt de POS dit naar een correcte weergave inclusief voorraadinformatie:

{

    "transaction": {

        "storeId": 434,

        "records": [

            {

                "scanCode": 9990000001,

                "productQuantity": 1,

                "priceInclTax": 30.16

            }

        ]

    }

}

CN 74727

Betaalknop "Online Refund" op POS alleen beschikbaar voor online orders

Wat is er nieuw?

Er is een wijziging doorgevoerd in het betaalscherm van de POS bij het verwerken van retouren. De betaalknop "Online Refund" is vanaf nu uitsluitend beschikbaar wanneer het een retour betreft van een online bestelling die volledig vooraf is betaald met een online betaalmethode (zoals iDEAL, creditcard of Klarna). In alle andere gevallen is de knop automatisch uitgeschakeld (disabled).

Inrichting en werking

Om deze functionaliteit te gebruiken, moet de betaalmethode met de exacte code REFUNDONLINE en de online betaalmethoden aan de winkel gekoppeld zijn, en moet de knop zijn toegevoegd aan de menu-knoppen van de POS.

Wanneer dit is ingericht, wordt de knop tijdens een retour automatisch geactiveerd onder de volgende voorwaarden:

• Er staat minimaal één retourorderregel op de bon.

• De oorspronkelijke order is volledig vooraf online betaald.

• Het restitutiebedrag is beperkt tot het totaal van de in aanmerking komende retourregels.

De knop blijft uitgeschakeld bij reguliere kassatransacties, bij orders die niet volledig vooraf zijn betaald, of orders die (deels) met PIN of contant in de winkel zijn afgerekend.

Belangrijk om te weten:

• Geen automatische terugbetaling: De knop registreert de restitutie correct in ASPOS voor de administratie. De daadwerkelijke terugbetaling naar de klant moet handmatig via het dashboard van de payment provider (PSP) worden afgehandeld.

• Gedeeltelijke online restitutie per orderregel is niet mogelijk; het bedrag betreft altijd het volledige regelbedrag.

CN 74728

Variantkeuze en 'Alles gescand'-controle

Deze update introduceert twee belangrijke nieuwe functies voor de Self-Checkout (SCO) applicatie. Beide toevoegingen zijn ontworpen om de voorraadnauwkeurigheid te vergroten, fouten in prijsberekeningen te voorkomen en derving (krimp) tegen te gaan.

1. Slimme variantkeuze (Multi-Format Prompting)
Om te garanderen dat klanten de juiste verpakkingsgrootte afrekenen bij producten die in meervoud worden verkocht (zoals blikjes drinken per stuk, als 6-pack of als krat), hebben we een slim keuzescherm (modal) geïmplementeerd.

Hoe werkt het?
Wanneer de barcode van een "Hoofdproduct" (Parent) wordt gescand, pauzeert het systeem het toevoegen aan het winkelmandje. De klant krijgt een pop-up te zien waarin gevraagd wordt om de juiste variant te kiezen.

• Slimme detectie: Dit keuzescherm verschijnt alléén als het gescande productid overeenkomt met het parentproductid. Scant de klant direct de specifieke barcode van bijvoorbeeld het 6-pack (het "Child" product)? Dan snapt het systeem dit en wordt het artikel direct, zonder pop-up, aan de bestelling toegevoegd.

• Wat ziet de klant? Het keuzescherm toont de productomschrijving, de inhoud (bijv. 300ml of 1800ml), de prijs en eventuele verplichte gekoppelde producten (zoals statiegeld).

• Annuleren: Met de annuleer-knop kan de klant veilig terugkeren naar het hoofdscherm zonder een artikel toe te voegen.

Vereiste inrichting en logica

• Geavanceerde instellingen: Zet de nieuwe instelling SCOVariantPopUp op True om dit te activeren.

• API Validatie: Het systeem gebruikt de productConnections API om te checken of er producttypes zijn gedefinieerd als Variant.

2. Bevestigingsscherm "Alles gescand"

Om te voorkomen dat klanten per ongeluk (of expres) artikelen vergeten af te rekenen, is er een extra, verplichte bevestigingsstap toegevoegd vlak voor het betalen. 

Hoe werkt het?
Zodra de klant op de 'Betalen'-knop drukt, wordt het proces heel even onderbroken door een pop-up met de vraag: "Heb je alle artikelen gescand?". Pas nadat de klant dit bevestigt, gaat de applicatie verder naar de reguliere betaalflow.

Vereiste inrichting

• Geavanceerde instelling: Zet de nieuwe instelling SCOScannedConfirmation op True om deze extra controle in te schakelen.

CN 75760

Verbeterde afhandeling SCO van AddOn-barcodes

AddOn-barcodes worden nu altijd correct opgeslagen, zelfs wanneer de specifieke AddOn-barcode nog niet bestaat in ASPOS.

Let op: De basis-barcode (base barcode) moet wél in ASPOS bestaan om het product te kunnen ophalen.

CN 76077

Rapportages

Vertaling Kasstaat rapport

Het rapport "Kasstaat" is vertaald naar de standaard ASPOS talen (Nederlands, Engels, Frans, Duits en Spaans).

LET OP. De vertaling van grootboekrekeningen wordt in een later item opgepakt.

CN 72531

Vertaling Uitzonderingen overzicht rapport

Het rapport "Uitzonderingen overzicht" is vertaald naar de standaard ASPOS talen (Nederlands, Engels, Frans, Duits en Spaans).

CN 72533

Vertaling Handmatige Korting rapport

Het rapport "Handmatige Korting" is vertaald naar de standaard ASPOS talen (Nederlands, Engels, Frans, Duits en Spaans).

CN 72534

Wijziging schaplabel

Aanpassingen doorgevoerd op klantspecifieke layout volgens wensen van de klant.

CN 75404

Klanten

Percentage kortingveld geblokkeerd bij deellevering

Bij een deels geleverde klantorder is het invoerveld voor het kortingspercentage vanaf nu vergrendeld en niet meer aanpasbaar.

CN 76059

Uitgebreide logging voor Wasteless Pricing via PDA

De logging voor Wasteless Pricing is uitgebreid om acties rondom het afprijzen van producten beter controleerbaar te maken. Wanneer er via de PDA een afprijssticker wordt geprint, legt het systeem vanaf nu extra detailinformatie vast in de Security Log onder de actie WASTELESSPRICING. Hierdoor is direct inzichtelijk welke gebruiker op welk moment een afprijsactie heeft uitgevoerd.

De memo van de logging bevat voortaan de volgende specifieke gegevens:

• Product

• Aantal

• Afprijsreden

• Prijs vóór korting

• Prijs na korting

• Type korting en de waarde

Deze uitbreiding zorgt voor een betere controleerbaarheid (auditability) en vermindert de fraudegevoeligheid van het handmatige afprijsproces.

CN 76059

Nieuw API-endpoint voor productstatistieken

We hebben het nieuwe endpoint POST stock-mutation-records/GetStatistics toegevoegd aan de API. Hiermee kun je eenvoudig specifieke statistieken opvragen over de verkopen en ontvangsten van een individueel product, zodat je direct en gericht inzicht krijgt in de voorraadstromen per artikel.

CN 73534

Receivings REST services overgezet naar nieuwe base repository 

Alle logica en endpoints met betrekking tot 'receivings' (ontvangsten) binnen de REST services zijn succesvol gemigreerd naar de nieuwe base repository.

CN 73534

Nieuw API-endpoint voor voorraadmutaties

Aan onze API is het nieuwe endpoint GET /stock-mutation-records toegevoegd. Hiermee vraag je direct de historie en details van voorraadmutaties op.

CN 73535

Nieuw API-endpoint voor uitgebreid zoeken naar producten

Wat is er nieuw?
Er is een nieuw endpoint toegevoegd aan de REST services: POST /api/products/LegacySearch. Dit endpoint maakt gebruik van exact dezelfde logica en levert dezelfde resultaten op als het vertrouwde product-zoekscherm binnen de backoffice.

Mogelijkheden en parameters

Met dit endpoint kun je zeer gericht zoeken, filteren en sorteren:

• Filteren: Je kunt de resultaten verfijnen via de volgende parameters: productGroupIds, productSubGroupIds, segmentIds, brandIds, states, seasonCodes, modelCodes, supplierIds en supplierStates.

• Sorteren: De resultaten kunnen oplopend of aflopend worden gesorteerd via orderBy en orderByDirection. Er worden 20 velden ondersteund, waaronder omschrijvingen, prijzen, voorraad, scancodes, merk, leveranciersgegevens en status.

• Specifieke opties:

  • • onlyInProductDescription: true - Zorgt ervoor dat er uitsluitend in de productomschrijving wordt gezocht.

    • onlyPreferredSupplier: true - Filtert uitsluitend op de voorkeursleverancier (alleen geldig in combinatie met de parameter supplierIds).

Belangrijke regels voor het gebruik van dit endpoint:

• Paginering: De waarde van de offset moet altijd een veelvoud zijn van de limit.

• Zoekterm: De searchTerm moet uit minimaal 3 karakters bestaan.

• Meerdere waarden: Bij de filters productGroupIds en segmentIds kun je een array met meerdere waarden opgeven.

• Uitsluiting: Wanneer je meerdere productGroupIds meestuurt in het request, is het niet toegestaan om ook productSubGroupIds op te geven.

Opties request:

{

  "fields": "string",

  "expand": "string",

  "offset": 0,

  "limit": 0,

  "locale": "string",

  "searchTerm": "string",

  "productGroupIds": [0],

  "productSubGroupIds": [0],

  "segmentIds": [0],

  "brandIds": [0],

  "states": ["string"],

  "seasonCodes": ["string"],

  "modelCodes": ["string"],

  "supplierIds": [0],

  "supplierStates": ["string"],

  "onlyPreferredSupplier": true,

  "onlyInProductDescription": true,

  "orderBy": "string",

  "orderByDirection": "string",

  "storeId": 0

}

CN 74074

Productverwijdering geblokkeerd bij openstaande ontvangsten via API opgelost

Er is een fout hersteld waardoor producten per ongeluk konden worden verwijderd wanneer er nog een onverwerkte ontvangst openstond die via de REST API was aangemaakt. Voortaan wordt bij het aanmaken van een ontvangst via de API de waarde receivingspendingquantity weer direct bijgewerkt, waardoor het systeem de openstaande goederenstroom herkent en het product correct beschermt tegen voortijdige verwijdering.

CN 73535

• 06/05/2026: Kassacrash bij scancode met aantal 0 verholpen

Er is een wijziging doorgevoerd in de kassa (POS) bij het verwerken van scancodes. Het is vanaf nu niet meer mogelijk om een aantal van 0 in te voeren bij een scancode.

Mochten er in het systeem nog producten bestaan met een ingesteld aantal van 0, dan leiden deze voortaan niet langer tot een foutmelding of een crash van de kassa. Deze artikelen worden nu op een stabiele manier afgehandeld.

TN 1435090

• 27/05/2026: Transactieverwerking PayAndGo-betaalflow geoptimaliseerd via webhooks

Er is een verbetering doorgevoerd in de PayAndGo-betaalflow. Transacties worden vanaf nu afgerond via veilige backend-webhooks in plaats van afhankelijk te zijn van de active browsersessie van de gebruiker.

Hiermee verloopt het verwerken en afronden van betalingen een stuk betrouwbaarder, ook wanneer een gebruiker het afrekenproces voortijdig verlaat of de browsersessie wordt onderbroken.

TN 1437867

• 09/06/2026: NullReferenceException bij verwerken klantorderregels in REST-services hersteld

Er is een aantal verbeteringen doorgevoerd rondom null-checks binnen de REST-services (onder meer bij UpdateChildOrderLinesAsync). Voorheen kon er onterecht een foutmelding (NullReferenceException) optreden wanneer een veldwaarde leeg (null) was.

Dit is gecorrigeerd voor de velden LastModifiedByGroupUserId, Quantity, IsCancelled en sDeleted bij de klantorderregels (customer-order-lines). Hierdoor worden verzoeken met lege of ontbrekende waarden in deze velden vanaf nu weer foutloos verwerkt.

CN 75633

• 09/06/2026: Verwerken van grote voorraadtellingen in ASPOS NEXT geoptimaliseerd

Er is een prestatieverbetering doorgevoerd bij het verwerken van voorraadtellingen binnen ASPOS NEXT. Voorheen kon het verwerken van voorraadtellingen met een groot aantal getelde regels of omvangrijke datasets problemen opleveren of niet goed functioneren vanuit het overzichtsscherm Voorraadtellingen.

Het verwerkingsproces is geoptimaliseerd, waardoor voorraadtellingen met grote hoeveelheden getelde regels vanaf nu sneller, stabieler en betrouwbaarder kunnen worden afgehandeld vanuit het overzicht.

TN 1443735

• 17/06/2026: Dubbeltelling bij gewijzigde orderregels in medewerker prestatierapport hersteld

Er is een wijziging doorgevoerd in het medewerker prestatierapport. Voorheen kon het voorkomen dat het aanpassen van een orderregel op dezelfde dag leidde tot een dubbeltelling in de resultaten van het rapport.

Dit is gecorrigeerd, waardoor het wijzigen van een orderregel op dezelfde dag vanaf nu niet meer zorgt voor een dubbeltelling en het prestatierapport weer de juiste cijfers weergeeft.

TN 1446685

• 17/06/2026: Btw-berekening over statiegeld bij 0%-btw-klanten hersteld

Er is een wijziging doorgevoerd in de btw-berekening voor klanten met een 0%-btw-instelling (zoals zerotax- en airside-klanten). Voorheen kon het voorkomen dat er onterecht btw werd berekend over het statiegeldbedrag.

De berekeningsmethode is aangepast, waardoor de btw voor deze klanten vanaf nu direct opnieuw wordt berekend op zowel bestaande transactieregels als nieuw toegevoegde artikelen. Dit werkt nu ook correct bij kitartikelen met een btw-tarief hoger dan 0%, waardoor er bij 0%-btw-klanten geen btw meer berekend wordt over statiegeld.

TN 1447480

• 18/06/2026: Berekening van inkoopprijs bij verwerken van transacties hersteld

Er is een wijziging doorgevoerd bij het vastleggen (committen) van transacties in NEXT. Voorheen kon de inkoopprijs op transactieregels onjuist worden berekend doordat het systeem direct terugviel op de laatst bekende inkoopprijs (LastPurchasePrice).

Dit is gecorrigeerd. De inkoopprijs wordt vanaf nu berekend via de juiste fallback-keten (VVP → margeberekening → LastPurchasePrice → basis inkoopprijs). Voor niet-aangepaste (non-customized) producten bepaalt het systeem nu altijd zelf de correcte inkoopprijs, waardoor een handmatig meegegeven waarde in het veld purchasePrice bij deze producten voortaan wordt genegeerd.

TN 1444891

• 24/06/2026: Resetten van ontvangstgegevens bij opslaan van inkooporders hersteld

Er is een wijziging doorgevoerd bij het verwerken en opslaan van inkooporders. Voorheen kon het voorkomen dat wanneer een inkooporder al openstond vóórdat de bijbehorende ontvangstbon werd verwerkt, het alsnog opslaan van de inkooporder de net verwerkte ontvangstgegevens weer overschreef.

Dit is gecorrigeerd. Het opslaan van een inkooporder reset de velden ReceivedQuantity, ReceivedDate en IsReceived op de inkooporderregels niet langer naar de verouderde waarden, waardoor de verwerkte ontvangsten correct behouden blijven.

TN 1448785

• 29/06/2026: Btw-verschil tussen CashJournal-rapport en journaalexport hersteld

Er is een wijziging doorgevoerd in het CashJournal-rapport. Voorheen kon er een verschil in btw-bedragen ontstaan tussen het CashJournal-rapport en de journaalexport, doordat het rapport de opgetelde afgeronde btw-bedragen per transactie toonde.

Dit is gecorrigeerd. Het CashJournal-rapport herberekent het btw-bedrag vanaf nu op basis van het getotaliseerde nettobedrag, precies zoals de journaalexport dat doet. Hierdoor komen het rapport en de journaalexport weer volledig met elkaar overeen en worden afrondingsverschillen voorkomen. Tevens is er direct een prestatieverbetering doorgevoerd.

TN 1448968

• 15/07/2026: Hetzelfde product meerdere keren toevoegen aan ontvangst bij verschillende inkooporders

Er is een aanpassing doorgevoerd in de REST-services bij het endpoint POST /api/receivings. Voorheen was het niet mogelijk om twee dezelfde producten toe te voegen binnen één ontvangst.

Dit is geoptimaliseerd. Vanaf nu is het wel mogelijk om meerdere regelitems voor hetzelfde product op te nemen in een ontvangst, mits op regelniveau een verschillende purchaseOrderId wordt meegegeven. Hierdoor kunnen ontvangsten afkomstig uit meerdere inkooporders probleemloos gecombineerd verwerkt worden.

TN 1452335

• 16/07/2026: Herkenning en opwaarderen van cadeaukaarten bij Self-Checkout in alle talen hersteld

Er is een wijziging doorgevoerd bij de verwerking van cadeaukaarten op de Self-Checkout (SCO). Voorheen werden cadeaukaart-serienummers niet herkend en werkte het opwaarderen van een cadeaukaart alleen wanneer de interfacetaal op Nederlands stond ingesteld.

Dit is gecorrigeerd. Cadeaukaart-serienummers worden vanaf nu altijd correct herkend, ongeacht de gekozen interfacetaal. Hierdoor werkt zowel de herkenning als het opwaarderen van cadeaukaarten weer consistent in alle ondersteunde talen.

TN 1454485

• 17/07/2026: Automatisch afmelden via POSUsageTimeout hersteld op diverse kassaschermen

Er is een wijziging doorgevoerd met betrekking tot de POSUsageTimeout in de kassa (POS). Voorheen werd een gebruiker na de ingestelde time-out niet automatisch uitgelogd wanneer specifieke schermen geopend stonden, zoals "Kas in/uit", "Productinformatie" en "Openen".

Dit is gecorrigeerd. De POSUsageTimeout is nu ook actief op deze schermen. Hierdoor meldt de POS de gebruiker vanaf nu op elk scherm consistent af na de ingestelde periode van inactiviteit (net zoals dit al het geval was bij onder andere "Transacties" en "Klanten").

TN 1452653

• 17/07/2026: Betrouwbaarheid en registratie van betalingen op de Self-Checkout (SCO) geoptimaliseerd

Er is een reeks verbeteringen doorgevoerd in het betaalproces van de Self-Checkout (SCO). Voorheen kon het in zeldzame gevallen voorkomen dat een succesvol afgeronde betaling niet correct werd geregistreerd in ASPOS, waardoor de kassa vast bleef staan op het betaalscherm.

Dit is geoptimaliseerd om de stabiliteit en het herstelvermogen te vergroten. Er is betere foutafhandeling en validatie toegevoegd voor onverwachte betaalreacties en time-outs, zodat de kassa niet oneindig blijft wachten. Bij een onverwachte fout keert de SCO vanaf nu netjes terug naar het betaalselectiescherm in plaats van vast te lopen. Tot slot is de logging uitgebreid om eventuele communicatieproblemen in de toekomst sneller te kunnen analyseren.

Hierdoor worden (succesvolle) betalingen een stuk betrouwbaarder verwerkt en is de kans dat de SCO na een betaling blijft hangen sterk verminderd.

TN 1446822

• 22/07/2026: Weergave van aantal openstaande klantorders op het Dashboard gecorrigeerd

Er is een wijziging doorgevoerd op het Dashboard met betrekking tot de weergave van het aantal openstaande klantorders. Voorheen werden 'PreOrder WebShop'-orders meegenomen in de totale telling van openstaande klantorders.

Dit is gecorrigeerd. 'PreOrder WebShop'-orders worden vanaf nu standaard uitgesloten van deze telling, geheel conform de beoogde bedrijfsregels. Hierdoor biedt het Dashboard weer een accuraat en realistisch inzicht in het daadwerkelijke aantal openstaande klantorders.

TN 1451410

• 27/07/2026: Duizend-scheidingstekens toegevoegd aan totalen in dashboard-grafieken

Er is een verbetering doorgevoerd op het dashboard met betrekking tot de weergave van grote getallen in de grafieken voor Transactiebeheer. Voorheen werden deze getallen zonder scheidingstekens getoond, wat het lastig kon maken om grote bedragen of aantallen snel af te lezen.

Dit is geoptimaliseerd. Grote getallen worden vanaf nu standaard voorzien van duizend-scheidingstekens, passend bij de lokaal ingestelde getalnotatie. Hierdoor wordt een waarde als '1000' nu netjes weergegeven als '1.000'. Dit zorgt voor een veel overzichtelijker en beter leesbaar dashboard.

TN 1451079

• 27/07/2026: Onjuiste weergave van het ampersand-teken (&) in kassa-berichten hersteld

Er is een probleem verholpen met betrekking tot de weergave van tekstberichten op de kassa (POS). Voorheen kon het voorkomen dat het ampersand-teken (&) onjuist werd getoond als de bijbehorende HTML-code (&).

Dit is gecorrigeerd. Het systeem decodeert HTML-gecodeerde tekens nu op de juiste manier. Hierdoor worden alle kassa-berichten vanaf nu weer netjes getoond zoals ze bedoeld zijn, met een correcte weergave van het &-teken.

TN 1451113

• 28/07/2026: Correcte uitlezing van prijs- en gewichtsbarcodes met voorloopcontrolecijfer 0 in de kassa (POS)

Er is een wijziging doorgevoerd in de kassa (POS) bij het verwerken van prijs- en gewichtsbarcodes die een voorloopcontrolecijfer 0 bevatten. Voorheen konden deze barcodes verkeerd worden geïnterpreteerd, waardoor er bijvoorbeeld maar 4 cijfers voor de prijs werden uitgelezen en er een onjuist bedrag of gewicht werd aangeslagen.

Dit is gecorrigeerd. De kassa bepaalt vanaf nu het juiste barcode-template door direct te matchen met de PLUCODE van het gekoppelde artikel. Hierdoor wordt een foutieve uitlezing voorkomen.

Dit werkt in de praktijk als volgt:

• Prijsbarcodes: Bij een gescande barcode zoals 2308010123450 controleert de kassa de PLUCODE. Heeft het artikel een 7-cijferige PLUCODE (2308010), dan wordt het bijbehorende template (AAAAAAACPPPPC) gebruikt en leest de kassa een prijs van € 23,45. Heeft het artikel een 6-cijferige PLUCODE (230801), dan past het template (AAAAAACPPPPPC) en wordt de prijs € 123,45. De kassa kiest nu altijd de juiste interpretatie.

• Gewichtsbarcodes: Wanneer de kassa is ingesteld op weeg-logica (waarbij de instelling POSPriceByBarcode uit staat), selecteert het systeem nu correct de gewichtssjablonen (W-templates in plaats van P-templates). Hierdoor wordt een barcode consistent en foutloos volgens de gewichtslogica verwerkt.

TN 1452868

• 28/07/2026: Export van rapportage omzetoverzicht groep/leverancier/merk opent weer uitgeklapt

Er is een wijziging doorgevoerd in de rapportage 'Omzetoverzicht groep/leverancier/merk'. Voorheen zorgde een onjuiste productsortering en groepering in de export ervoor dat de geëxporteerde gegevens standaard 'ingeklapt' werden weergegeven in het bestand.

Dit is gecorrigeerd. De juiste groepering en sortering zijn hersteld voor het exporteren van deze rapportage. Hierdoor opent het geëxporteerde bestand vanaf nu direct weer netjes en volledig 'uitgeklapt', zodat alle data direct overzichtelijk en inzichtelijk is.

TN 1454600

• 30/07/2026: Ontbrekende ophaaltijd op het Picklijsten rapport hersteld

Er is een wijziging doorgevoerd in de weergave van het Picklijsten rapport. Voorheen ontbrak op dit rapport de specifieke ophaaltijd van een klantorder, waardoor uitsluitend de ophaaldatum zichtbaar was voor de medewerkers.

Dit is gecorrigeerd. Het Picklijsten rapport toont vanaf nu weer netjes zowel de ophaaldatum als de exacte ophaaltijd van de betreffende klantorder. Hierdoor is de afhaalinformatie op de picklijst weer volledig en direct inzichtelijk.

TN 1455245