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:
De extensie wordt voortaan gevuld op de correcte order
De extensie wordt voortaan aangemaakt als customer order property in plaats van een store property
Het vinkje 'bezorgen' wordt voortaan aangezet in de klantorder als er wordt gekozen voor de optie 'Ophalen in andere winkel'
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:
1317 Specified account does not exist
9001 Userdata not Found
9002 User Disabled
9010 User Expired
9013 No Valid Purses
9014 Not Enough Balance
9020 User Group not Allowed
9078 Card Disabled
9083 NetpayUser Not Valid Yet
990 Message not supported
993 Unallowed TRX amount
994 Missing Data Field
995 Duplicate Transaction ID
998 Terminal Type Mismatch
999 Terminal Unknown
1105 Log Command failed
1106 Log Response failed
1107 Monitor Message failed
1108 Send Message failed
1111 general Read exception
1112 general Write exception
1121 Update Terminal failed
1123 Main function execution failed
1124 Send Error message function failed
1317 Specified account does not exist
9001 Userdata not Found
9002 User Disabled
9003 Fraude Detected
9010 User Expired
9013 No Valid Purses
9014 Not Enough Balance
9020 User Group not Allowed
9021 DeviceDataNotFound
9022 Unknown Device
9023 Unable to Load Session Key
9024 Invalid Session Key
9025 Invalid Encryption
9026 User Not Active
9039 CardID Already Exists
9042 User Already Exists
9044 User Already Exists But Has Expired
9045 No User Groups Available
9057 Loyalty Data Not Found
9058 Loyalty Expired
9059 Loyalty Not Yet Available
9066 Terminal OrganizationID Not Allowed
9068 Loyalty Item Not Paid
9070 Loyalty Not Enough Balance
9072 Share Parent User Not Found
9073 Share Parent Not Available
9074 Share Child User Not Found
9075 Share Child Not Available
9076 Share User Has Child Users
9077 Share User Not Found
9078 Card Disabled
9079 Invalid SecretKey
9083 NetpayUser Not Valid Yet
9091 Coupon Already Exists
9092 Coupon Data Not Found
9100 Too many cards
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:
"POSUseGCServiceBovertis". Zet deze waarde op true om de Bovertis koppeling aan te zetten
"BovertisGCConfigID". Vul deze instelling met de aangeleverde config ID
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.
PAYNL_APIClient_Url
PAYNL_APIClient_ApiUrl
PAYNL_APIClient_At
PAYNL_APIClient_Token
PAYNL_APIClient_Sl
PAYNL_APIClient_ReturnUr
PAYNL_APIClient_TestMode
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:
De setting ShowTranslationsInBO gevuld is met FR, EN, ES of DE.
De taal van de backoffice hetzelfde is als de waarde in "ShowTranslationsInBO".
Het icoontje wordt op alle pagina's waar het vraagteken staat ook getoond, behalve op de loginpagina.
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:
Real-time, op afstand, meekijken met elke transactie
Het afhandelen van Hulp-vragen
Tonen van uitzonderingen/meldingen die vanuit de SCO worden verstuurd en het uitvoeren uitvoeren van controles waarop een actie vereist is
Nix18 controle bij aankoop alcohol/tabak/kansspelen etc.
Verplichte productcontroles met o.a. legitimatieplicht/vereiste documenten
Meldingen als er producten zonder prijs worden gescand
Meldingen als er producten met een onbekende barcode worden gescand
Meldingen als er problemen optreden tijdens o.a. het printen van kassabonnen, het activeren van cadeaukaarten en e-vouchers of tijdens het betalen met PIN
Het uitvoeren en forceren van steekproeven die gegenereerd worden op basis van een tiental, per winkel instelbare, parameters
Het buiten gebruik zetten en beschikbaar maken van een Selfcheckout
Meerdere SCO’s vanuit meerdere vestigingen in één overzicht
Ondersteuning in 4 talen: Nederlands, Engels, Duits en Frans
Om de applicatie i.c.m. de SCO te laten werken zijn de volgende onderdelen noodzakelijk:
Ingerichte Werkstations van type=Zelfscankassa
Ingerichte Redencodes van type=EventMessage
Ingerichte Eventtypes
De winkelinstelling SCOAppEnabled=True
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.
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:
Omschrijving (meertalig): hoe het event wordt weergegeven in het overzicht, in de eventberichten tabel en in de Monitor App.
Prioriteit: de prioriteit van het eventberichttype (deze wordt momenteel niet gebruikt)
Tonen: of het eventbericht getoond moet worden in de Monitor App of niet. Een eventbericht dat niet wordt getoond, wordt wel aangemaakt en verstuurd. Sommige eventberichten zijn bedoeld voor interne doeleinden en worden niet in de App getoond.
Event code: de code van het event. Deze kan niet gewijzigd worden.
TimeOut (seconden): dit is een instelbare tijd in seconden. Als het event na het aanmaken niet binnen de ingestelde tijd wordt opgepakt, dan wordt deze automatisch gesloten met een redencode time-out.
Actie vereist?: hiermee kan worden afgedwongen dat het event verplicht moet worden afgehandeld voordat er afgerekend kan worden aan de SCO. Als het event nog niet is afgehandeld vóór het betalen, dan wordt aan de SCO een controlescherm getoond. Pas na het verwerken van actie vereist events, wordt een eventuele steekproef aangemaakt.
Afbeelding: hier kan een afbeelding worden opgeslagen (deze wordt momenteel niet gebruikt)
Pop-up weergeven: geeft aan of er een pop-up moet worden weergegeven (deze wordt momenteel niet gebruik)
Settings: hier wordt, in JSON structuur, o.a. de configuratie vastgelegd van:
diverse parameters voor de steekproef
de te gebruiken redencodes. Deze redencodes komen uit de redencode tabel en kunnen voorzien worden van een actionType;
started: dit actietype wordt gebruikt voor events waar een actie vereist is. De redencode waarvan het actionType=started wordt opgestuurd wanneer een event met actie vereist wordt geopend. Op dat moment wordt er een event opgestart met status=in behandeling (pending) en wordt het tijdstip vastgelegd.
accept: dit actietype wordt gebruikt voor events die getoond moeten worden en waar een actie vereist is. De redencode waarvan het actionType=accept wordt in de Monitor App in het eventbericht weergegeven met een groene V . Op het moment dat het event wordt afgehandeld in de Monitor App wordt het event gesloten/geaccepteerd met deze redencode.
decline: dit actietype wordt gebruikt voor events die getoond moeten worden en waar een actie vereist is. De redencode waarvan het actionType=decline wordt in de Monitor App in het event bericht weergegeven met een rood kruis.
de gebruikte iconen in de Monitor App. Deze kunnen worden gekozen uit de beschikbare iconen uit de volgende library: https://oblador.github.io/react-native-vector-icons/. het eerste deel is de naam van de library van het icoon, gevolgd door -icon-- en de naam van het icoon.
en de kleurstelling van de gebruikte iconen in de Monitor App. Deze dienen in HEX te worden gedefinieerd. Hier kan bijv. deze website voor gebruikt worden: https://www.color-hex.com/color/
Score: dit is de score van een event. Deze wordt gebruikt in het steekproefmechanisme. Wanneer de combinatie van scores van events boven een ingestelde drempelwaarde komt, vindt er een steekproef plaats
Memo (Meertalig): dit is de tekst/beschrijving voor de medewerker die getoond wordt in de Monitor App bij het openen/afhandelen van events.
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.
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:
Een medewerker heeft in de Monitor App d.m.v. de [Forceer controle] knop aangegeven dat de klant gecontroleerd moet worden
Door het random controle percentage, welke in de instellingen van de steekproef is opgenomen.
Door het bereiken van de drempelwaarde voor een steekproef als gevolg van de gecombineerde score van diverse events die door de SCO zijn verstuurd. Deze wordt eveneens ingesteld in de instellingen van de steekproef.
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:
AmountOfProductsToCheck: het minimaal aantal te controleren producten tijdens een steekproef. Dit kan eventueel minder zijn als de inhoud van de winkelwagen minder is.
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.
PercentageOfProductsToCheck: uit dit percentage wordt het aantal te controleren producten tijdens de steekproef berekend. Deze wordt naar beneden afgerond en opgeteld bij AmountOfProductsToCheck. De combinatie van deze twee instellingen zorgt in het Steekproef event voor
RandomCheckPercentage: het percentage van de transacties wat resulteert in een steekproef. Hier wordt naar gekeken als de steekproef niet wordt aangemaakt door het bepalen van de drempelwaarde of door een geforceerde controle.
MaxOpenBaskets: het maximaal tegelijkertijd openstaande Steekproef en Volledige Controle events. Als er meer events openstaan dan hier ingesteld en er zou volgens de instellingen een Steekproef moeten komen, dan wordt deze wel aangemaakt, maar direct gesloten met de reden ‘Steekproef gesloten - te veel controles’
ThresHoldScore: hier kan de drempelwaarde voor de steekproef worden ingesteld. Een transactie resulteert in een steekproef als de gecombineerde score van alle events die met dezelfde winkelwagen te maken hebben, op of boven deze drempelwaarde komt.
MinimumProductPrice: dit is de minimale aannemelijke stuksprijs voor een product. Wanneer een gescand product op of onder deze ingestelde drempelwaarde uitkomt, wordt er een event met een ingestelde score verstuurd.
minimumTransactionValue: dit is de minimale aannemelijke transactiewaarde van een winkelwagen. Wanneer het transactietotaal op of onder deze ingestelde drempelwaarde uitkomt, wordt er een event met een ingestelde score verstuurd.
highQuantityThreshold: dit is het maximum aantal aannemelijke stuks van product in een winkelwagen. Wanneer het aantal op of boven deze ingestelde drempelwaarde uitkomt, wordt er een event met een ingestelde score verstuurd.
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:
Steekproef gesloten - te veel controles: de steekproef wordt gesloten met deze reden als er al te veel steekproeven en volledige controles open staan
Steekproef gesloten - geen tijd: de steekproef wordt gesloten met deze reden als de medewerker in de Monitor App aangeeft geen tijd te hebben
Steekproef gesloten - time-out: de steekproef wordt gesloten met deze reden als de ingestelde time-out verlopen is.
Steekproef afgewezen: de steekproef wordt gesloten met deze reden als de steekproef is mislukt. Er wordt dan ook direct een volledige controle aangemaakt
Steekproef afgerond: de steekproef wordt gesloten met deze reden als de steekproef succesvol is en geen verschillen heeft opgeleverd.
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:
Wanneer de werkstationinstelling ForceAcceptFullCheck de waarde ‘True’ heeft of ontbreekt, dan mag er direct op de [Akkoord]-knop gedrukt worden en wordt de inhoud van de winkelwagen zoals gescand door de klant afgerekend. De volledige controle wordt dan afgerond met de redencode ‘Volledige controle - handmatig’
Wanneer de werkstationinstelling ForceAcceptFullCheck de waarde ‘False’ heeft, dan dienen aan de SCO alle producten uit de winkelwagen op dit moment gescand te worden en wordt uiteindelijk alleen het deel afgerekend wat door de medewerker tijdens de controle is gescand. Wanneer gewerkt wordt met de Monitor App is het aanbevolen om de instelling op ‘False’ te zetten. Hieronder wordt de werking uitgelegd met de waarde op ‘False’
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:
Wanneer het juiste aantal is gescand, wordt het product groen.
Wanneer nog niet het juiste aantal is gescand of als er meer is gescand dan origineel aanwezig, dan wordt het product in het rood weergegeven.
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:
Aanmaakdatum: de aanmaakdatum en tijd van het event .
Type: het type event wat verstuurd is.
Actie vereist: of er een actie van een medewerker vereist was.
Message ID: het unieke id van het eventbericht.
Transactie: het transactienummer waaraan de event(s) zijn gekoppeld. Als een transactie wordt afgerond, dan krijgen alle events die met die transactie te maken hebben hetzelfde transactienummer. Events gerelateerd uit geannuleerde transacties of het buiten dienst zetten van een SCO krijgen nooit een transactienummer.
Gebruiker: de gebruiker die een event heeft aangemaakt en/of afgehandeld heeft.
Werkstation: de naam van het werkstation van type=Zelfscankassa waar de events vandaan zijn gekomen.
WinkelCode: de winkelnaam van het event.
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:
Timeout moment: het moment dat het event afgerond zou worden met een timeout indien het event niet binnen de ingestelde timeout (seconden) van de aanmaakdatum is opgepakt en afgerond.
Score: de score zoals ingesteld in het eventberichttype. Als de gecombineerde score van de events de drempelwaarde bereikt, wordt er een steekproef aangemaakt.
Reden code: de reden waarmee het event is aangemaakt
Redencode verwerkt: de reden waarmee het event is afgerond.
Inbehandeldatum: het moment waarop een medewerker het eventbericht in de Monitor App heeft geopend.
Verwerkingsdatum: het moment waarop een medewerker het eventbericht in de Monitor App heeft afgehandeld.
Inhoud: hier wordt specifieke informatie opgeslagen. Dit is per eventberichttype andere informatie. Voorbeelden zijn:
een scancode bij een Onbekende scancode event
een productid bij een Verplichte productcontrole, Hoog risicoproduct, Product verwijderd, Aantal gewijzigd event
het aantal te controleren producten bij een Steekproef event
de originele inhoud van de winkelwagen bij een Volledige controle event
Memo: hier wordt specifiek informatie opgeslagen. Dit is per eventberichttype andere informatie. Voorbeelden zijn:
het productid waardoor tijdens de Steekproef de Volledige controle is aangemaakt.
de gescande inhoud door de medewerker tijdens de Volledige controle
de inhoud van de winkelwagen in een Transactie event als de transactie wordt geannuleerd of als de timeout in de SCO bereikt wordt.
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.
Wanneer de werkstationinstelling ForceAcceptFullCheck de waarde ‘True’ heeft of ontbreekt, dan mag er direct op de [Akkoord]-knop gedrukt worden en wordt de inhoud van de winkelwagen zoals gescand door de klant afgerekend. De volledige controle wordt dan afgerond met de redencode ‘Volledige controle - handmatig’. Dit is de standaard werking van de Selfcheckout, zonder gebruikt van de Monitor App.
Wanneer de werkstationinstelling ForceAcceptFullCheck de waarde ‘False’ heeft, dan dienen aan de SCO alle producten uit de winkelwagen op dit moment gescand te worden en wordt uiteindelijk alleen het deel afgerekend wat door de medewerker tijdens de controle is gescand. Wanneer gewerkt wordt met de Monitor App is het aanbevolen om de instelling op ‘False’ te zetten. Hieronder wordt de werking uitgelegd met de waarde op ‘False’
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:
Wanneer het juiste aantal is gescand, wordt het product groen.
Wanneer nog niet het juiste aantal is gescand of als er meer is gescand dan origineel aanwezig, dan wordt het product in het rood weergegeven.
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:
Bij het endpoint POST /api/carts/Calculate is bij de expand op "Lines" de expand optie "AvailableToPromise" toegevoegd. Per regel wordt dan de leverbelofte getoond.
Bij het endpoint POST /api/carts/Calculate is de expand optie "AvailableToPromise" toegevoegd. In de header wordt de langst durende leverbelofte over alle regels getoond.
Bij de verschillende GET /api/product endpoints is de expand optie "AvailableToPromise" toegevoegd.
In ASPOS in het menupunt [Generieke instellingen] is het configuratie type "AvailableToPromise" toegevoegd. Hier moet de configuratie voor de ATP berekeningen worden toegevoegd.
ATP berekening:
Er wordt gekeken of de "Default" store kan leveren. De leverbelofte van "StockDefaultStore" wordt gebruikt.
Dit is de store die als default is ingesteld in de configuratie.
Anders wordt er gekeken of een extra store het kan leveren. De leverbelofte "StockExtraStore" wordt gebruikt.
Dit zijn de ingestelde extra stores in de configuratie.
Anders wordt er gekeken of een combinatie van winkels kan leveren. De leverbelofte "StockMultipleStores" wordt gebruikt.
De order kan uitgeleverd worden door een combinatie van winkels (default store plus één of meer extra stores of alleen door de extra stores).
Er is geen of niet voldoende voorraad. De leverbelofte "NoStock" wordt gebruikt.
Wanneer de locale parameter wordt gebruikt wordt de leverbelofte boodschap (DeliveryMessage) van de opgegeven taal gebruikt,
Berekening is op basis van vrije voorraad
PercentageOfStock betekent hoeveel % van de vrije voorraad gebruikt kan worden. Als deze bijvoorbeeld op 90% staat en de default store heeft een vrije voorraad van 10 stuks, dan kan deze 9 stuks gebruiken voor de berekening. (90% / 100% * Vrije voorraad 10 = 9 stuks).
Er wordt naar beneden afgerond.
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
02/02/2024: Aanpassing bij doorscannen POS
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
02/02/2024: Validatie op karakters bij huisnummers in REST
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
08/02/2024: Extra logging bij pick aantalen
Temporal table toegevoegd in de database voor de wijzigingen in de customerOrderLines.
TN 1175113
08/02/2024: Weergave open prijswijzigingen
Wijziging doorgevoerd zodat de openstaande prijswijzigingen weer getoond worden in de taken pop-up.
TN 1202640
08/02/2024: Aanpassing ALT + T in de POS
Wijziging doorgevoerd zodat de [ALT]+T functie in de POS de bonuspunten melding weer juist reset.
TN 1198563
09/02/2024: Extra logging bij transacties met betrekking tot EVL punten
Extra logging toegevoegd aan transacties via de POS die betrekking hebben op EVL punten.
TN 1198893
12/02/2024: Aanpassing bij twee keer pinnen in één transactie
Wijziging doorgevoerd in de payment service, zodat bij aanvang van een transactie eerst de status opgevraagd wordt van eventuele errors.
TN 1199777
21/02/2024: Zichtbaarheid betaalvouchers bij betalingen
Wijziging doorgevoerd zodat betaalvouchers weer zichtbaar zijn in bij de betaling.
TN 1204141
22/02/2024: Dubbele winkeltaak in PDA
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
28/02/2024: Na verwerken pakbon besteld aantal aangepast
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
01/03/2024: Artikel export naar Excel
Wijziging doorgevoerd zodat de product export naar Excel weer correct werkt in omgevingen waar de multilingual setting uit staat.
TN 1207514
01/03/2024: Verwerking prijswijziging naar onderliggende winkels
Wijziging doorgevoerd zodat een prijswijziging die voortkomt uit het wijzigen van een voorkeursleverancier wordt door verwerkt naar de onderliggende winkels.
TN 1201677
05/03/2024: Offline bon gekoppeld aan verkeerde gebruiker
Wijziging doorgevoerd waardoor (offline) refund transacties nu de juiste gebruiker weergeven in het transactiebeheer.
TN 1201607
05/03/2024: Sortering inkoopregels JDS t.o.v. ASPOS
Aanpassing doorgevoerd zodat de sortering van inkoopregels in de JDS export gelijk is aan die van de inkoopordermodule in de Backoffice.
TN 1203555
05/03/2024: Wijziging bij pakbonrapportage
Wijziging doorgevoerd zodat op de pakbonrapportage "TelerikCustomerOrderDeliveryNoteExtended_General" het bezorgadres gebruikt wordt i.p.v. het adres van de klant.
TN 1201589
05/03/2024: Melding bij inventarisatie bij openstaande telregels
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
08/03/2024: Aantal bij barcode in SCO
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
08/03/2024: Wijziging bij verwerken van klantsaldo
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
11/03/2024: Wijziging in klantorder memo
Wijziging doorgevoerd zodat het klantordermemo weer correct toont op de rapportage TelerikReportCustomerOrders_General
TN 1207257
18/03/2024: Klantcode op kassabon
Wijziging doorgevoerd zodat wanneer de setting POSShortCustomerInfo op True staat op de kassabon weer enkel de klantcode wordt getoond op de kassabon.
TN 1209979
29/03/2024: Bonkorting op statiegeld
Wijziging doorgevoerd zodat kitregels niet meer meelopen in acties.
TN 1208295
17/04/2024: Betaling kwam niet door in de SCO
Wijziging doorgevoerd in de SCO m.b.t. de afhandeling van kitproducten.
TN 1216677
19/04/2024: Ongeldig teken in xml Intres
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
19/04/2024: Regel in retour klantorder toevoegen zorgde niet voor groen bolletje
Wijziging doorgevoerd die in sommige scenario's extra clicks die een postback in de weg zitten worden geblokkeerd.
TN 1215651
30/04/2024: Call op customerOrderLines gaf verkeerde orders terug
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