GOLF

VERSIE: 6.0.2024Golf

LET OP! Vanaf deze versie worden PC's die met een .NET versie draaien lager dan 4.7.2 NIET meer ondersteund! Uw kassa start niet meer op. Vanuit onze support/sales afdeling zal er contact op worden genomen indien uw systeem niet meer up-to-date is, of niet meer voldoet aan de standaard en vervangen dient te worden.

INHOUDSOPGAVE

KLANTEN

Aanpassing omzetten van klantorder naar soort "Maatwerk"

Wijziging doorgevoerd zodat bij het omzetten of kopiëren van een klantorder naar het soort Maatwerk wordt gekeken naar de setting "CONoMessageForKindCustom". Als deze setting op true staat wordt het meldingstype op geen bericht gezet.

CN 43891

ASPOS KASSA

Aanpassing klant referentie

Aanpassing doorgevoerd in de POS zodat in het geval dat het klantveld 'ReferenceRequired' actief is en de store setting "POSDeliveryNoteNoMemo" op false staat er bij pakbon transacties nog steeds een referentie kan worden ingevoerd.

CN 44031

"Kas uit" boeking op afronding in plaats van contant

Aanpassing doorgevoerd in de POS/Backoffice zodat kas uit transacties voortaan op de betaalsoort 'contant' in plaats van 'wisselgeld' worden geboekt. Tevens is er extra logging toegevoegd zodat deze transacties beter zijn te volgen.

Weergave in transactiebeheer:

Weergave in de POS:

CN 44030

Wijzigingen bij DirectSale orders

Met deze wijziging is er een aantal aanpassingen doorgevoerd voor DirectSale orders:

CN 44023

Wijziging pakbon lay-out vanuit de POS

Wijziging doorgevoerd in een klantspecifieke pakbon lay-out, zodat deze ook via de POS correct werkt.

CN 44041

"POSUseTimeoutHook" niet gebruiken bij Airside functionaliteit

Wijziging doorgevoerd voor de airside feature in ASPOS zodat de POS in combinatie met de setting "POSUseTimeoutHook" naar verwachting start.

CN 44168

Aanpassing Xafax foutcodes in de POS en SCO

Aanpassing doorgevoerd in de POS/SCO zodat foutcodes die vanuit Xafax worden aangeleverd voortaan 1 op 1 worden getoond in de pop-ups. Hieronder volgt de lijst met Xafax foutcodes.

Mogelijke foutcodes die door kunnen komen vanuit Xafax:


CN 41154

Voucher koppeling 5.8 van Intersolve

Met deze wijziging is er ondersteuning ingebouwd voor het tonen van (Aztec) QR codes afkomstig vanuit Intersolve op de kassabon voor Epson bonprinters. Om gebruik te maken van deze functionaliteit dient de standaard Intersolve koppeling geconfigureerd te zijn in ASPOS op basis van de winkel- en leveranciersinstellingen.

CN 43895

Aanpassingen ten behoeve van Bovertis giftcards via de Giftcard service

Met deze wijziging is er ondersteuning ingebouwd voor de Bovertis giftcard koppeling vanuit Schiphol. Om gebruik te maken van deze functionaliteit in de POS dient een aantal instellingen gevuld te worden:

Maak vervolgens een nieuwe betaalsoort aan voor de Bovertis giftcard en vul deze met de onderstaande gegevens en configuratie:

Bovertis giftcard configuratie:

<GenericSettingsHolder xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

  <GenericSettings>

    <GenericSettingHolder>

      <SettingObject xsi:type="BovertisServiceSettings">

        <Version>3</Version>

        <PortNumber>5003</PortNumber>

        <OpenTimeOut>20000</OpenTimeOut>

        <InactiveTimeOut>20000</InactiveTimeOut>

        <Namespace>http://namespace</Namespace>

        <ServiceUrl>https://acc2.luntronics.com/webservices/okintegration.asp</ServiceUrl>

        <SupportsCancel>1</SupportsCancel>

        <ExtensiveLogging>1</ExtensiveLogging>

        <LogCardInfo>0</LogCardInfo>

        <RetryCancels>1</RetryCancels>

      </SettingObject>

      <SettingTypeName>BovertisServiceSettings</SettingTypeName>

    </GenericSettingHolder>

  </GenericSettings>

</GenericSettingsHolder>

CN 43468/42955

ASPOS BACKOFFICE

Kitgroepen meertalig gemaakt

Wijziging doorgevoerd zodat de omschrijving van kitgroepen meertalig ingegeven kan worden in APSOS. Als de setting "Multilanguage" op True staat, wordt bij het invoeren van de omschrijving van een kitgroep de Multilanguage pop-up geopend.

CN 41213

Wijziging binnenboeken kitregels via een ontvangst

Wijziging doorgevoerd zodat kitregels (indien besteld bij een leverancier) ook via een ontvangst kunnen worden binnen geboekt op een klantorder.

CN 43212

Nieuwe storesettings ten behoeve van integratie Pay.nl

Eerste wijzigingen doorgevoerd voor de Pay.nl koppeling, hiervoor zijn in ASPOS de volgende storesettings toegevoegd.

LET OP!

De verdere functionaliteit in ASPOS wordt opgepakt in een ander item.

CN 41610

Mogelijkheid om "Rapportage" knop uit te kunnen schakelen bij facturen

Wijziging doorgevoerd zodat het recht om een factuur te tonen en/of te printen (in het menupunt facturen) gesplitst is. Hiervoor is er een nieuw gebruikersrecht toegevoegd: "Print facturen". Dit recht is standaard toegevoegd voor alle gebruikers die het recht "Facturen" actief hebben. Met dit nieuwe recht kan bepaald worden of de knop printen beschikbaar is in het menupunt facturen. Met het recht "Facturen" wordt enkel de knop rapportage in het menupunt facturen beïnvloed. 

CN 43718

Wijziging events icoontje in reparatie module

Wijziging doorgevoerd zodat, bij het drukken op het events icoontje in de reparatie module het juiste tabblad, namelijk events, wordt geopend.

CN 44253

Vertalingspagina in de backoffice

Links naast het vraagteken in de Backoffice wordt een nieuw icoontje getoond als:

Drukken op dit icoontje opent een tijdelijke vertalingspagina.

CN 43776

RefundTransactionCorrect transacties geen transactienummer toekennen

Wijziging doorgevoerd zodat wanneer de setting "FiscalCertificationType" op de waarde FR staat een refund transactie geen transactienummer toegekend krijgt.

CN 44395

Eventtypes meertalig kunnen gebruiken

In het menupunt Eventmessage types onder Instellingen kunnen nu zowel de Omschrijving als het Memo (instructie voor de medewerker die de Monitor App gebruikt) van het eventtype meertalig worden ingevuld. Dit werkt alleen als in de ASPOS omgeving ook met meerdere talen wordt gewerkt. 

In het overzicht van Eventmessage types wordt de omschrijving in de taal van de ingelogde gebruiker getoond.

In het overzicht van Eventberichten is de omschrijving van het gekoppelde eventtype nu ook de omschrijving van het eventbericht en wordt deze eveneens in de taal van de ingelogde gebruiker getoond.

Daarnaast zijn de kolommen nu vertaald en zijn de kolommen Omschrijving en prioriteit nu vervangen door de kolommen Transactie en Gebruiker, zodat je snel eventberichten terug kan zoeken.

CN 44166

ASPOS SELFCHECKOUT

SCO/Monitor app uitbreiding en optimalisatie

De integratie tussen de Selfcheckout en de Monitor App is uitgebreid en ondersteunt nu de volgende functies:

Om de applicatie i.c.m. de SCO te laten werken zijn de volgende onderdelen noodzakelijk:

De verdere inrichting wordt hieronder toegelicht:

Redencodes

De Monitor App en de SCO gebruiken redencodes om events op een logische en duidelijke manier af te handelen. Deze redencodes worden weggeschreven bij het aanmaken en afhandelen van events en kunnen in het (nog onder handen) SCO Dashboard gebruikt worden om op te filteren. 

Deze redencodes zijn te vinden onder het menu Instellingen → Redencodes, zijn van type=EventMessage en kunnen meertalig worden opgeslagen. In de eventberichttypen kunnen redencodes gekoppeld worden aan eventberichten. 

Onderstaande redencodes zijn standaard aanwezig in een ASPOS omgeving en standaard gekoppeld aan de diverse event berichttypes.

Redencodes monitor app

Eventberichttypes

In de eventberichttypes wordt de inrichting gedaan voor de zogenoemde events. Events zijn berichten die, bij bepaalde gebeurtenissen/handelingen in de SCO of in de Monitor App, door de applicatie worden verstuurd. De ene applicatie verstuurt een event en de andere applicatie ontvangt het event en kan hier vervolgens een melding van tonen of een actie op laten ondernemen. 

In het menupunt Instellingen → Eventtypeberichten worden deze eventberichttypen geconfigureerd. Afhankelijk van de configuratie en het type event, worden berichten alleen getoond, is er een actie vereist of zijn deze nodig om o.a. het steekproefmechanisme te activeren.

De configuratie van een eventberichttype bestaat uit de volgende velden:

Voorbeeld configuratie eventberichttype en weergave in de Monitor App:

Onderstaande eventbericht types worden nu standaard ondersteund in de SCO en de  Monitor App als de inrichting juist is. Deze worden automatisch toegevoegd aan elke ASPOS omgeving. Hieronder worden deze per type toegelicht.

Eventbericht types

Aantal gewijzigd

Een aantal gewijzigd event wordt door de SCO verstuurd als handmatig het aantal in de winkelmand wordt aangepast. Iedere keer dat handmatig een aantal wordt gewijzigd, wordt een nieuw event gestuurd. Je kunt hier een score aan koppelen die meeweegt in het behalen van de drempelwaarde voor de steekproef.  

Standaard staat het ‘tonen’ van dit type uit, omdat je hier doorgaans geen melding van wilt krijgen in de Monitor App. 

Activatie Cadeaukaart mislukt

Een activatie cadeaukaart mislukt event wordt door de SCO verstuurd als de activatie van een cadeaukaart of e-voucher mislukt. Er wordt een melding aan de SCO getoond en de Monitor App ontvangt het event om door een medewerker af te laten handelen. Bij het afhandelen stuurt de App een nieuw event met de gebruikte redencode en wordt het event in ASPOS gesloten.

De SCO kan weer worden vrijgegeven door de pincode van de medewerker in te geven of de medewerkerspas te scannen. 

Standaard staat het ‘tonen’ van dit type aan, omdat je hier doorgaans een melding van wilt krijgen in de Monitor App. 

Afdrukken mislukt

Een afdrukken mislukt event wordt door de SCO verstuurd als het printen van een kassabon, e-voucher of evl-voucher mislukt. In veel gevallen is dan het bonpapier van de bonprinter op. 

Er wordt een melding aan de SCO getoond en de Monitor App ontvangt het event om door een medewerker af te laten handelen. Bij het afhandelen stuurt de App een nieuw event met de gebruikte redencode en wordt het event in ASPOS gesloten. 

De SCO kan weer worden vrijgegeven door de pincode van de medewerker in te geven of de medewerkerspas te scannen.

Standaard staat het ‘tonen’ van dit type aan, omdat je hier doorgaans een melding van wilt krijgen in de Monitor App. 

Betaling

Een Betaling event wordt door de SCO verstuurd als de klant op [Betalen] drukt. De SCO verstuurd opnieuw een event als de betaling wordt afgerond (redencode ‘Betaling afgerond’) óf de klant de terug knop gebruikt (redencode ‘Betaling onderbroken’) om bijvoorbeeld extra producten bij te scannen. 

Het Betaling event heeft als doel om bij te houden hoe lang het duurt om een betaling uit te voeren en af te ronden. Daarnaast weten we door het aanmaken van het Betaling event precies hoe lang het scannen van de producten heeft geduurd en kunnen we deze informatie in het SCO Dashboard gebruiken.   

Standaard staat het ‘tonen’ van dit type uit, omdat je hier doorgaans geen melding van wilt krijgen in de Monitor App. 

Foutmelding

Een Foutmelding event wordt door de SCO verstuurd als er een foutmelding optreedt die niet één van de andere events betreft.

Standaard staat het ‘tonen’ van dit type aan, omdat je hier doorgaans een melding van wilt krijgen in de Monitor App. 

Gratis product

Een Gratis product event wordt door de SCO verstuurd als er een product is gescand met een prijs van 0,00 vóór actiekorting en prijstype <> nul. Producten van type=Giftcard, E-voucher en EVL-voucher worden hiervan uitgesloten. In de inhoud van het event wordt het Gratis product meegestuurd, zodat het voor een medewerker inzichtelijk is om welk product in de winkelwagen het gaat. 

De Monitor App ontvangt het event om door een medewerker af te laten handelen. Bij het afhandelen stuurt de App een nieuw event met de gebruikte redencode en wordt het event in ASPOS gesloten.

Dit event wordt verstuurd om de ingelogde medewerker in de Monitor App de mogelijkheid te geven om te controleren of het product voor niets ‘verkocht’ wordt. Meestal gaat het hier om gratis promotieproducten, maar soms kan het ook foutieve inrichting van het product in ASPOS zijn.

Als een medewerker de Gratis product controle afwijst, dan dient het product fysiek verwijderd te worden uit de winkelwagen van de klant en uit de transactie aan de SCO.

Standaard staat het ‘tonen’ van dit type aan, omdat je hier doorgaans een melding van wilt krijgen in de Monitor App. 

Standaard staat ook ‘actie vereist’ op dit type aan. Dit zorgt ervoor dat deze melding eerst moet worden afgerond voordat de klant kan betalen. Hierna kan eventueel nog een steekproef worden aangemaakt. 

Handmatige controle

Een Handmatige controle event wordt door een medewerker vanuit de Monitor App verstuurd als de medewerker, bijvoorbeeld vanwege verdachte handelingen van de klant aan de SCO, een steekproef/controle wil forceren. De medewerker gebruikt hiervoor de knop [Forceer controle] tijdens het meekijken met een transactie in de Monitor App. 

Dit event zorgt altijd voor een steekproef, ongeacht de inhoud van de winkelwagen. De steekproef wordt in dit geval aangemaakt met de redencode ‘Steekproef voor geforceerde controle’.

Hoog aantal

Een Hoog aantal event wordt door de SCO verstuurd als het aantal stuks van een product in de winkelwagen boven een ingestelde drempelwaarde uitkomt. Ieder product met een veelvoud van deze ingestelde drempelwaarde in de winkelwagen zorgt voor een event. 

De drempelwaarde wordt ingesteld in de settings van het Steekproef event met de parameter “highQuantityThreshold”.

In het Hoog aantal event zelf kan je hier een score aan koppelen die meeweegt in het behalen van de drempelwaarde voor de steekproef.  

Standaard staat het ‘tonen’ van dit type uit, omdat je hier doorgaans geen melding van wilt krijgen in de Monitor App. Wanneer de gecombineerde score van deze en andere events boven de drempelwaarde van de steekproef komt, wordt er een steekproef aangemaakt.

Hoog risico product

Een Hoog risico product event wordt door de SCO verstuurd als er een product is gescand met een verhoogd risico. Dit kan bijvoorbeeld een product zijn met een hoge waarde of een diefstalgevoelig product. 

Een product met een verhoogd risico wordt ingesteld via het productveld ‘Increased risk product score’. In dit productveld kan een score worden ingevuld. Deze score weegt net als andere scores mee in het behalen van de drempelwaarde voor de steekproef. Ieder product met een verhoogd risico levert een event op, evenals een veelvoud van hetzelfde product met een verhoogd risico. 

De Monitor App ontvangt het event om door een medewerker af te laten handelen. Bij het afhandelen stuurt de App een nieuw event met de gebruikte redencode en wordt het event in ASPOS gesloten.

Een product met een verhoogd risico wordt ook apart, in het rood, weergegeven tijdens een steekproef (en in het steekproef eventbericht in ASPOS) en moet verplicht gescand worden om de steekproef af te kunnen ronden.

Standaard staat het ‘tonen’ van dit type uit, omdat je hier doorgaans geen melding van wilt krijgen in de Monitor App. Wanneer de gecombineerde score van deze en andere events boven de drempelwaarde van de steekproef komt, wordt er een steekproef aangemaakt.

Hulp gevraagd

Een Hulp gevraagd event wordt door de SCO verstuurd als een klant op [Hulp] heeft gedrukt. Er wordt een melding aan de SCO getoond en de Monitor App ontvangt het event om door een medewerker af te laten handelen. 

Bij het afhandelen in de Monitor App stuurt de App een nieuw event met de gebruikte redencode en worden de melding aan de SCO en het event in ASPOS gesloten.

Bij het sluiten van de melding in de SCO worden ook de melding in de Monitor App en het event in ASPOS gesloten.

Standaard staat het ‘tonen’ van dit type aan, omdat je hier doorgaans een melding van wilt krijgen in de Monitor App. 

Minimale productwaarde

Een Minimale productwaarde event wordt door de SCO verstuurd als de verkoopprijs van één stuk van een product in de winkelwagen onder een ingestelde drempelwaarde uitkomt. Ieder product met een veelvoud van deze ingestelde drempelwaarde in de winkelwagen zorgt voor een event. 

De drempelwaarde wordt ingesteld in de settings van het Steekproef event met de parameter “MinimumProductPrice”.

In het Minimale productwaarde event zelf kan je hier een score aan koppelen die meeweegt in het behalen van de drempelwaarde voor de steekproef.  

Standaard staat het ‘tonen’ van dit type uit, omdat je hier doorgaans geen melding van wilt krijgen in de Monitor App. Wanneer de gecombineerde score van deze en andere events boven de drempelwaarde van de steekproef komt, wordt er een steekproef aangemaakt.

Minimale transactiewaarde

Een Minimale transactiewaarde event wordt door de SCO verstuurd als de totale prijs van de producten in de winkelwagen onder een ingestelde drempelwaarde uitkomt. 

De drempelwaarde wordt ingesteld in de settings van het Steekproef event met de parameter “minimumTransactionValue”.

In het Minimale transactiewaarde event zelf kan je hier een score aan koppelen die meeweegt in het behalen van de drempelwaarde voor de steekproef.  

Standaard staat het ‘tonen’ van dit type uit, omdat je hier doorgaans geen melding van wilt krijgen in de Monitor App. Wanneer de gecombineerde score van deze en andere events boven de drempelwaarde van de steekproef komt, wordt er een steekproef aangemaakt.

Nieuwe winkelmand

Een Nieuwe winkelmand event wordt door de SCO verstuurd als een transactie is afgerond of de SCO weer in het beginscherm wordt gezet. De Monitor App ontvangt dit event en weet vervolgens dat de SCO weer op [Beschikbaar] kan worden gezet in de App. 

Standaard staat het ‘tonen’ van dit type uit, omdat je hier doorgaans geen melding van wilt krijgen in de Monitor App

Nix 18

Een Nix 18 event wordt door de SCO verstuurd als er een product gescand is waar een leeftijdscontrole op plaats moet vinden, zoals op alcohol, tabak en kansspelen.

Een product met een Nix 18 controle wordt ingesteld via het productveld ‘AgeCheck’. Als dit productveld de waarde ‘Ja’ heeft, dan wordt er een event verstuurd.

De Monitor App ontvangt het event om door een medewerker af te laten handelen. De Nix 18 controle kan worden goedgekeurd met of zonder identificatie óf worden afgekeurd. 

Bij het afhandelen stuurt de App een nieuw event met de gebruikte redencode en wordt het event in ASPOS gesloten.

Als een medewerker de Nix 18 controle afwijst, dan dienen alle producten waar deze controle voor geldt fysiek verwijderd te worden uit de winkelwagen van de klant en uit de transactie aan de SCO.

In het memoveld van het eventberichttype kan de tag [DATE:-18Y] worden opgegeven. Dit bepaalt de datum die in het event wordt weergegeven tijdens de Nix 18 controle, in dit geval vandaag -18 jaar. 

Standaard staat het ‘tonen’ van dit type aan, omdat je hier een melding van moet krijgen in de Monitor App. 

Standaard staat ook ‘actie vereist’ op dit type aan, omdat dit een wettelijke verplichting betreft. Dit zorgt ervoor dat deze melding eerst moet worden afgerond voordat de klant kan betalen. Hierna kan eventueel nog een steekproef worden aangemaakt. 

Onbekende barcode

Een Onbekende barcode event wordt door de SCO verstuurd als er een product is gescand met een onbekende barcode. In de inhoud van het event wordt de onbekende scancode meegestuurd, zodat de medewerker het product in een winkelwagen kan identificeren. 

De Monitor App ontvangt het event om door een medewerker af te laten handelen. Bij het afhandelen stuurt de App een nieuw event met de gebruikte redencode en wordt het event in ASPOS gesloten.

Dit event wordt verstuurd om de ingelogde medewerker in de Monitor App de mogelijkheid te geven om te controleren of het product niet voor niets ‘verkocht’ wordt.

Als er onterecht een product met een onbekende barcode fysiek in de winkelwagen van de klant is gekomen, dan dient het product door de medewerker ook fysiek verwijderd te worden uit de winkelwagen van de klant.

Standaard staat het ‘tonen’ van dit type aan, omdat je hier doorgaans een melding van wilt krijgen in de Monitor App. 

Standaard staat ook ‘actie vereist’ op dit type aan. Dit zorgt ervoor dat deze melding eerst moet worden afgerond voordat de klant kan betalen. Hierna kan eventueel nog een steekproef worden aangemaakt.

Onderhoudsmodus

Een Onderhoudsmodus event wordt door de Monitor App verstuurd als vanuit het transactiescherm één van de knoppen [Zet buiten gebruik] of [Maak beschikbaar] gebruikt worden. Hiermee kan de SCO vanuit de Monitor App buiten gebruik worden gezet of juist weer beschikbaar.

Pinnen mislukt

Een Pinnen mislukt event wordt door de SCO verstuurd als er, om welke reden dan ook, niet gepind kan worden. 

De Monitor App ontvangt het event om door een medewerker af te laten handelen. Bij het afhandelen stuurt de App een nieuw event met de gebruikte redencode en wordt het event in ASPOS gesloten.

Product verwijderd

Een Product verwijderd event wordt door de SCO verstuurd als handmatig een product wat reeds is gescand uit de winkelwagen wordt verwijderd. Iedere keer dat handmatig een product wordt verwijderd, wordt een nieuw event gestuurd. Je kunt hier een score aan koppelen die meeweegt in het behalen van de drempelwaarde voor de steekproef.  

Standaard staat het ‘tonen’ van dit type uit, omdat je hier doorgaans geen melding van wilt krijgen in de Monitor App. 

Steekproef

Een Steekproef event wordt door de SCO verstuurd als het controlemechanisme vindt dat er een steekproef plaats moet vinden. Dit kan 3 verschillende redenen hebben:

Deze redenen worden opgeslagen in het eventbericht in ASPOS.

De steekproef wordt pas aangemaakt als alle events met ‘actie vereist’ zijn afgehandeld. Als de klant eerder op [Betalen] drukt, dan dat de ‘actie vereist’ events zijn afgehandeld, dan wordt er een controle scherm getoond. Het kan zijn dat na het afronden van alle ‘actie vereist’ events, er alsnog een steekproef komt. Dit is bewust om de steekproef zuiver te houden. 

In de settings van de steekproef kunnen, naast de redencodes en icooninformatie, de volgende parameters worden opgenomen:

vb. Als hier de waarde 2 is ingesteld, maar er zit maar één product in de winkelwagen, dan hoeft er maar 1 product gecontroleerd te worden.

Voorbeeld van de steekproef settings

{   "AmountOfProductsToCheck": 1,


"PercentageOfProductsToCheck": 25,  "RandomCheckPercentage": 25,  "MaxOpenBaskets": 5,  "ThresHoldScore": 100, "MinimumProductPrice": 0.1,   "minimumTransactionValue": 1, "highQuantityThreshold": 10, 


"reasons": [


    {


      "reasonCode": "SampleCheckStarted",


      "actionType": "started"


    },


    {


      "reasonCode": "SampleCheckFinished",


      "actionType": "accept"


    },


        {


      "reasonCode": "SampleCheckClosedNoTime",


      "actionType": "decline"


    }


  ],


  "icon": "fontawesome5-icon--shopping-basket",


  "iconColor": "#e25e5e" }

Naast het vastleggen van redenen voor het aanmaken van een steekproef, zijn er ook een aantal redenen voor het afronden van een steekproef:

Bij het uitvoeren van een steekproef in de Monitor App wordt rekening gehouden met de producten met een verhoogd risico (in rood weergegeven) en het aantal te controleren producten. De producten met een verhoogd risico moeten altijd gecontroleerd worden.

Daarnaast wordt vanaf het openen van de steekproef, tot het moment van afronden, de gebruikte tijd bijgehouden en weggeschreven in het steekproef event in ASPOS.

Het uitvoeren van de steekproef met de Monitor App kan d.m.v. het scannen van de producten (elke barcode bij het product werkt) en het gebruik van de [+]-knop. 

De knop [Steekproef afgerond] kan worden gebruikt als het minimaal aantal te scannen producten is bereikt.

De knop [Sluiten] kan gebruikt worden om de steekproef opnieuw uit te voeren, mocht de medewerker zelf een fout maken. 

Wanneer er tijdens het uitvoeren van de steekproef een product wordt gescand die niet aanwezig is in de winkelwagen óf er wordt een hoger aantal van een product gescand, dan wordt er een melding gegeven dat er een verschil is ontstaan en dat er een volledige controle wordt aangemaakt. Het product dat voor het verschil heeft gezorgd, wordt vastgelegd in het steekproef event in ASPOS.

De Monitor App sluit vervolgens het steekproef event en maakt een Volledige controle event aan, welke aan de SCO moet worden afgehandeld.

Voorbeeld Steekproef event in ASPOS:

Standaard staat het ‘tonen’ van dit type aan, omdat je hier altijd een melding van wilt krijgen in de Monitor App. 

Standaard staat ‘actie vereist’ op dit type aan.

Standaard staat er een time-out op dit event ingesteld, zodat de klant niet te lang moet wachten om af te kunnen rekenen als er, om welke reden dan ook, geen tijd/ruimte is om de steekproef uit te voeren. 

Transactie

Een Transactie event wordt door de SCO verstuurd als de klant begint met het scannen van producten. De SCO verstuurt opnieuw een event als de transactie wordt afgerond (redencode ‘Transactie afgerond’), als de transactie niet op tijd wordt afgerond (redencode ‘Transactie time-out’) óf als de SCO weer in het beginscherm wordt gezet (redencode ‘Transactie handmatig verwijderd’). 

Het Transactie event heeft als doel om bij te houden hoe lang de SCO, van kop tot staart, bezet is en op deze manier o.a. de gemiddelde tijd van een transactie te achterhalen en hier analyses op los te laten in het SCO Dashboard.

Standaard staat het ‘tonen’ van dit type uit, omdat je hier doorgaans geen melding van wilt krijgen in de Monitor App. 

Verplichte productcontrole

Een Verplicht productcontrole event is vergelijkbaar met een Nix 18 event en wordt door de SCO verstuurd als er een product gescand is waar een verplichte productcontrole op plaats moet vinden, zoals bijv. op vergif wat alleen verkocht mag worden als de klant de juiste documenten heeft. Een product met een verplichte productcontrole wordt ingesteld via het productveld ‘CheckRequiredSCO’. Als dit productveld aanwezig is, dan wordt er een event verstuurd.

In de inhoud van het event wordt het Verplichte productcontrole product meegestuurd, zodat het voor een medewerker inzichtelijk is om welk product in de winkelwagen het gaat. 

De Monitor App ontvangt het event om door een medewerker af te laten handelen. Bij het afhandelen stuurt de App een nieuw event met de gebruikte redencode en wordt het event in ASPOS gesloten.

Als een medewerker de Verplichte productcontrole afwijst, dan dient het product fysiek verwijderd te worden uit de winkelwagen van de klant en uit de transactie aan de SCO.

Standaard staat het ‘tonen’ van dit type aan, omdat je hier een melding van moet krijgen in de Monitor App. 

Standaard staat ook ‘actie vereist’ op dit type aan, omdat dit een wettelijke verplichting betreft. Dit zorgt ervoor dat deze melding eerst moet worden afgerond voordat de klant kan betalen. Hierna kan eventueel nog een steekproef worden aangemaakt. 

Volledige controle

Een Volledige controle event wordt door de Monitor App verstuurd als de voorafgaande steekproef verschillen heeft opgeleverd en dus is gefaald. 

De volledige controle dient uitgevoerd te worden aan de SCO. Het controlescherm dat tijdens de steekproef in beeld stond wordt vervangen door een scherm voor de volledige controle:

Het totaalbedrag van de originele inhoud van de winkelwagen, zoals gescand door de klant, wordt weergegeven in het volledige controlescherm. 

In de [Akkoord]-knop begint het bedrag tijdens het scannen van producten opnieuw op te lopen vanaf €0,00.

Wanneer een product wordt gescand in het volledige controlescherm wordt het bedrag in de [Akkoord]-knop opgehoogd met de waarde van het gescande product: 

Als alle producten uit de winkelwagen/winkelmand zijn gescand en er geen verschil is geconstateerd, dan komt het bedrag in de [Akkoord]-knop overeen met het totaalbedrag van de winkelwagen. De volledige controle wordt dan afgerond met de redencode ‘Volledige controle - geen verschillen’

Als er wel een verschil is geconstateerd, dan verschijnt onderstaande melding. Als er voor ‘Nee’ wordt gekozen, dan heeft de medewerker nog de mogelijkheid om verder te scannen. 

Als er voor ‘Ja’ wordt gekozen, dan wordt het betaalscherm getoond en kan de klant het totaalbedrag afrekenen van de producten, zoals gecontroleerd door de medewerker. Het totaalbedrag en het bedrag in de [Akkoord]-knop wijken dan van elkaar af. De volledige controle wordt dan afgerond met de redencode ‘Volledige controle - verschillen’.

Het Volledige controle event wordt automatisch gekoppeld aan de medewerker die tijdens de steekproef het verschil heeft geconstateerd. 

Standaard staat het ‘tonen’ van dit type uit, omdat de Monitor App hier zelf niet opnieuw een melding van hoeft te ontvangen. 

Eventberichten

In het menupunt ‘Eventberichten’ onder het menupunt ‘Instellingen’ worden de verstuurde events opgeslagen en getoond. 

Hier kan onder andere het verloop van een volledige transactie worden nagelopen. 

Deze begint altijd met een Nieuwe winkelmand event (het oudste message id) en wordt afgerond met een Betaling event. Eventuele events die nog kunnen optreden ná betaling, zoals een fout met de bonprinter of het activeren van cadeaukaarten wordt hierna nog getoond. 

Er kan hier gefilterd worden op een specifiek eventtype of gezocht worden op de inhoud van één van de getoonde kolommen, zoals bijv. het Transactienummer.

In dit overzicht worden de volgende velden getoond:

Indien er de behoefte is om meer detailinformatie van een event in te zien, kan het detailscherm van het event geopend worden. 

De belangrijkste informatie, die nog niet in het overzicht met eventberichten staat, wordt hieronder toegelicht:

CN 42118

Full Check Event aanpassingen

Er is een nieuwe werkstationinstelling ForceAcceptFullCheck voor de Selfcheckout geïntroduceerd, die de werking van het scannen van producten tijdens het medewerker controle scherm beïnvloedt.

Het totaalbedrag van de originele inhoud van de winkelwagen, zoals gescand door de klant, wordt weergegeven in het volledige controlescherm. 

In de [Akkoord]-knop begint het bedrag tijdens het scannen van producten opnieuw op te lopen vanaf €0,00.

Wanneer een product wordt gescand in het volledige controlescherm wordt het bedrag in de [Akkoord]-knop opgehoogd met de waarde van het gescande product: 

Als alle producten uit de winkelwagen/winkelmand zijn gescand en er geen verschil is geconstateerd, dan komt het bedrag in de [Akkoord]-knop overeen met het totaalbedrag van de winkelwagen. De volledige controle wordt dan afgerond met de redencode ‘Volledige controle - geen verschillen’

Als er wel een verschil is geconstateerd, dan verschijnt onderstaande melding. Als er voor ‘Nee’ wordt gekozen, dan heeft de medewerker nog de mogelijkheid om verder te scannen. 

Als er voor ‘Ja’ wordt gekozen, dan wordt het betaalscherm getoond en kan de klant het totaalbedrag afrekenen van de producten, zoals gecontroleerd door de medewerker. Het totaalbedrag en het bedrag in de [Akkoord]-knop wijken dan van elkaar af. De volledige controle wordt dan afgerond met de redencode ‘Volledige controle - verschillen’.

CN 42929

SERVICES

REST: Mogelijkheid om transacties te filteren op product

In de REST services bij het endpoint GET /api/transaction-records is het nieuwe filter "ProductIds" toegevoegd. Met deze parameter is het mogelijk om binnen transactieregels te filteren op een of meerdere producten.

CN 43225

Ondersteuning fiscal certification type "none"

Wijziging doorgevoerd zodat de logging niet te vaak errors weergeeft als "FiscalCertificationType" op None staat. Dit om ruis in de logging te voorkomen.

CN 44160

REST: Wijziging prijs bij wichtartikelen

In de REST services werd bij producten van het type "Wicht" waarbij een korting werd verleend niet de juiste priceInclTax / priceExclTax getoond in de CartCalculate / CustomerOrder en Transaction. De prijs na korting werd hier getoond terwijl dit de prijs voor korting moet zijn. Dit is nu aangepast.

CN 44006

REST: Introductie "Ratelimiting"

In de REST services is het nu mogelijk om het aantal verzoeken dat gebruikers in een bepaalde tijd kunnen doen te beperken. Dit vereist enige configuratie. Standaard zijn de limieten extreem hoog ingesteld, deze zijn te vinden in appsettings.json.

  "RateLimiter": {

    "RateLimit": "100000",

    "TimeSpan": "00:01:00"

  }

RateLimit is het aantal oproepen dat gebruikers mogen doen binnen de opgegeven tijd.

TimeSpan is het tijdsbestek waartoe de oproepen beperkt zijn. Het formaat is HH:MM:SS. Als we het aantal per uur willen beperken, dan moet er dus 01:00:00 worden ingesteld. Als we het aantal per minuut willen beperken, dan moet 00:01:00 worden ingesteld.

CN 44671

REST: Omzetten naar inkooporder

In de REST services is het nu mogelijk om een klantorder te verwerken naar inkooporder. Dit kan middels het nieuwe endpoint: POST /api/customer-orders/{id}/ConvertToPurchaseOrder. De inkooporder wordt aangemaakt met de status "Te bestellen". Deze wordt niet verwerkt.

CN 40476

REST: Uitbreiden services voor ATP berekening

In de REST services is het nu mogelijk om te werken met ATP berekeningen (Available-to-promise).

Hiervoor zijn de volgende wijzigen doorgevoerd:

ATP berekening:

Wanneer de locale parameter wordt gebruikt wordt de leverbelofte boodschap (DeliveryMessage) van de opgegeven taal gebruikt,

Berekening is op basis van vrije voorraad

Voorbeeld ATP configuratie:

<json>{

  "Stock": [

    {

      "Store": "M001",

      "type": "Default",

      "PercentageOfStock": 90

    },

    {

      "Store": "M201",

      "type": "Extra",

      "PercentageOfStock": 50

    },

    {

      "Store": "M202",

      "type": "Extra",

      "PercentageOfStock": 50

    }

  ],

  "DeliveryPromise": [

    {

      "type": "StockDefaultStore",

      "DeliveryinDays": 0,

      "DeliveryMessageNL": "Direct leverbaar, vandaag besteld morgen in huis",

      "DeliveryMessageEN": "Immediately available, ordered today, delivered tomorrow",

      "DeliveryMessageDE": "XXX",

      "DeliveryMessageFR": "XXX"

    },

    {

      "type": "StockExtraStore",

      "DeliveryinDays": 3,

      "DeliveryMessageNL": "Vandaag besteld, levering in 3 dagen",

      "DeliveryMessageEN": "Ordered today, delivery in 3 days",

      "DeliveryMessageDE": "XXX",

      "DeliveryMessageFR": "XXX"

    },

    {

      "type": "StockMultipleStores",

      "DeliveryinDays": 4,

      "DeliveryMessageNL": "Vandaag besteld, levering in 4 dagen",

      "DeliveryMessageEN": "Ordered today, delivery in 4 days",

      "DeliveryMessageDE": "XXX",

      "DeliveryMessageFR": "XXX"

    },

    {

      "type": "NoStock",

      "DeliveryinDays": null,

      "DeliveryMessageNL": "Product is niet op voorraad neem contact op met onze vestiging voor mogelijkheden",

      "DeliveryMessageEN": "Product is not in stock, please contact our branch for options",

      "DeliveryMessageDE": "XXX",

      "DeliveryMessageFR": "XXX"

    }

  ]

}</json>

CN 42201

PATCHES

Aanpassing doorgevoerd in de POS zodat in het geval dat er een puntendialoog wordt getriggerd het mogelijk blijft om scancodes op de bon te plaatsen.

TN 1198179

In de REST services is een aanpassing gedaan m.b.t. de toegestane karakters bij de huisnummer toevoeging van het klantadres.

Voorheen werd een spatie in de huisnummer toevoeging niet geaccepteerd. Nu is dit wel mogelijk.

TN 1202457

Temporal table toegevoegd in de database voor de wijzigingen in de customerOrderLines.

TN 1175113

Wijziging doorgevoerd zodat de openstaande prijswijzigingen weer getoond worden in de taken pop-up.

TN 1202640

Wijziging doorgevoerd zodat de [ALT]+T functie in de POS de bonuspunten melding weer juist reset.

TN 1198563

Extra logging toegevoegd aan transacties via de POS die betrekking hebben op EVL punten.

TN 1198893

Wijziging doorgevoerd in de payment service, zodat bij aanvang van een transactie eerst de status opgevraagd wordt van eventuele errors.

TN 1199777

Wijziging doorgevoerd zodat betaalvouchers weer zichtbaar zijn in bij de betaling.

TN 1204141

Wijziging doorgevoerd zodat via de REST service wordt afgevangen dat er 2 open winkeltaken van het type ontvangst zijn op 1 ontvangst bon. 

TN 1206026

Wijziging doorgevoerd zodat bij het aanpassen van een deels geleverde klantorderregel zodat het totale aantal geleverd is, de status van de regel wordt aangepast.

TN 1189522

Wijziging doorgevoerd zodat de product export naar Excel weer correct werkt in omgevingen waar de multilingual setting uit staat.

TN 1207514

Wijziging doorgevoerd zodat een prijswijziging die voortkomt uit het wijzigen van een voorkeursleverancier wordt door verwerkt naar de onderliggende winkels.

TN 1201677

Wijziging doorgevoerd waardoor (offline) refund transacties nu de juiste gebruiker weergeven in het transactiebeheer.

TN 1201607

Aanpassing doorgevoerd zodat de sortering van inkoopregels in de JDS export gelijk is aan die van de inkoopordermodule in de Backoffice.

TN 1203555

Wijziging doorgevoerd zodat op de pakbonrapportage "TelerikCustomerOrderDeliveryNoteExtended_General" het bezorgadres gebruikt wordt i.p.v. het adres van de klant.

TN 1201589

Wijziging doorgevoerd zodat er een melding wordt getoond op het moment dat er een telling wordt verwerkt waar nog openstaande telregels in staan.

TN 1200767

Wijziging doorgevoerd zodat de rest services (en daarmee dus ok de SCO) juist rekening houden met het aantal bij de barcode en statiegeld producten.

TN 1208429

Wijziging doorgevoerd zodat bij het verwerken van klantsaldo (met eventuele vraag hoe saldo terugbetaald moet worden o.b.v. de setting POSCustBalChangeChoice) er alsnog een call wordt gedaan naar auto commit transaction.

TN 1209030

Wijziging doorgevoerd zodat het klantordermemo weer correct toont op de rapportage TelerikReportCustomerOrders_General

TN 1207257

Wijziging doorgevoerd zodat wanneer de setting POSShortCustomerInfo op True staat op de kassabon weer enkel de klantcode wordt getoond op de kassabon.

TN 1209979

Wijziging doorgevoerd zodat kitregels niet meer meelopen in acties. 

TN 1208295

Wijziging doorgevoerd in de SCO m.b.t. de afhandeling van kitproducten.

TN 1216677

Aanpassing doorgevoerd zodat een extra set aan karakters naar verwachting worden getoond in het memoveld van het Intres/DB besteladvies in de Backoffice.

TN 1216463

Wijziging doorgevoerd die in sommige scenario's extra clicks die een postback in de weg zitten worden geblokkeerd. 

TN 1215651

In de REST services bij het endpoint GET /api/customer-order-lines kwamen voorheen de customer-order-lines van alle winkels terug. Nu komen alleen customer-order-lines terug van het eigen niveau.

TN 1209790