VERSIE: 6.0.2024Oscar

Doorontwikkeling van het activatiebewijs van cadeaukaarten en werkstationinformatie

Met deze wijziging is de template voor het activatiebewijs van cadeaukaarten instelbaar gemaakt. De volgende verbeteringen zijn doorgevoerd:

• Weergave Transactienummer en Werkstationnaam: Het transactienummer en de naam van het werkstation worden nu weergegeven op de bon in de POS/SCO.

• Transactiebeheer: De naam van het werkstation waarop de transactie is afgerond wordt voortaan weergegeven in transactiebeheer.

Deze aanpassing zorgt voor een verbeterde traceerbaarheid en duidelijkheid bij het activeren en beheren van cadeaukaarten.

CN 48257

Toevoeging in usp_CustomerOrder_Distribute

• Wijziging in OrderDistributionMode: Wanneer OrderDistributionMode is ingesteld op '2', wordt er voortaan geen rekening gehouden met de eigen voorraad; alle orders worden altijd volledig verdeeld, ongeacht de voorraadstatus.

• Verwijderen van controle op negatieve orderregels: De controle op de aanwezigheid van negatieve regels in een order is verwijderd. Negatieve orderregels worden niet meer verwerkt, terwijl positieve regels wel blijven worden verwerkt.

CN 50075

Verbetering van POS/SCO bontemplate

Er is een aanpassing doorgevoerd in de POS/SCO bon template die nu ondersteuning biedt voor het tonen van extra informatie:

• Werkstationnummer: Het werkstationnummer wordt weergegeven op de bon.

• Ladenaam: De naam van de lade wordt weergegeven.

• Ladenummer: Het ladenummer wordt weergegeven.

Let op:

• Wanneer deze tags worden gebruikt in de Self-Checkout (SCO) template, worden de ladenaam en het ladenummer verborgen.

CN 50461

Uitbreidingen en optimalisaties in de koppeling met Vusion

De koppeling met Vusion is verder uitgebreid om de terugverdientijd te versnellen en de functionaliteit te verbeteren. Hieronder staan de belangrijkste uitbreidingen en optimalisaties.

Belangrijkste Uitbreidingen:

• Schedules voor label verversing: We sturen nu schedules mee in de verzoeken naar Vusion. Dit maakt het mogelijk om aan te geven dat een label op een specifiek tijdstip in de toekomst moet verversen. We sturen de einddatum/tijd mee zodat het label direct na afloop van een actie wordt bijgewerkt.

• Happy Hour acties met ESL labels: 'Happy hour' acties kunnen nu automatisch worden verwerkt met de ESL labels van Vusion. Als een actie over 2 uur ingaat, zal het label automatisch worden ververst met de nieuwe gegevens na deze periode. We controleren regelmatig op nieuwe acties die zojuist zijn ingegaan.

• LED lampjes van ESL: Er is een nieuwe API-call geïntroduceerd: api/product-esls/flash. Hiermee kunnen LED-lampjes op basis van de barcode van een product laten knipperen. De beschikbare kleuren zijn: RED, GREEN, BLUE, CYAN, MAGENTA, YELLOW, WHITE. Er zal nog een wijziging worden doorgevoerd in de PDA om deze functionaliteit te ondersteunen.

Optimalisaties:

• Voorkomen van dubbele verzoeken: Als een koppeling tussen een label en een product al bestaat, wordt deze niet opnieuw verstuurd.

• Label bijwerking: Het label in ASPOS wordt bijgewerkt op het moment dat de data correct is verstuurd naar Vusion. Het label komt dan op 'verwerkt' te staan.

• Controle van vestiging instellingen: We sturen geen producten meer naar Vusion als de instelling 'EslStoreCode' in de vestiging niet is ingevuld.

• Webshop Kenmerk voor Acties: Het webshop kenmerk van een actie wordt nu ook meegestuurd, zodat op basis daarvan bepaalde acties optioneel wel of niet worden getoond op het label.

CN 51038

Verbeterde bonlay-out voor de POS en SCO

Om de duidelijkheid en leesbaarheid van bonnen te verbeteren, zijn er verschillende wijzigingen doorgevoerd voor transacties die set-producten, kits en kortingen omvatten. Het nieuwe bonformaat zorgt ervoor dat klanten hun aankopen, de toegepaste kortingen en het totaalbedrag eenvoudig kunnen begrijpen.

Belangrijkste wijzigingen in de bonlay-out:

1. Inspringing voor geneste Kit-items:

   • Kit-items die deel uitmaken van een set-product worden nu ingesprongen weergegeven onder het hoofditem op de bon. Deze visuele hiërarchie toont duidelijk welke items deel uitmaken van een hoofdset-product, waardoor het voor klanten gemakkelijker is om hun aankopen te begrijpen.

2. Duidelijke weergave van kortingen op kit-regels:

   • Kortingen, of deze nu handmatig of automatisch worden toegepast, worden nu duidelijk weergegeven op de bon naast elk toepasselijk kit-item en set-product.

   • Zowel de oorspronkelijke prijs als het kortingsbedrag worden voor transparantie weergegeven.

3. Berekening van het totale bedrag:

   • Het totale bedrag onderaan de bon weerspiegelt nu nauwkeurig alle toegepaste kortingen op zowel set-producten als hun geneste kit-items. Dit helpt klanten te zien hoe het uiteindelijke totaalbedrag is berekend.

Overzicht van set-producten en kits:

3. • Set-producten: Producten die als "Set" zijn gemarkeerd (bijv. 'Mijn Menu Klein') kunnen meerdere kitgroepen bevatten.

     • Bijvoorbeeld, 'Mijn Menu Klein' heeft kitgroepen zoals 'Frites menu', die hun eigen kitopties kunnen hebben.

   • Kitopties: Kitgroepen kunnen verschillende kitopties bevatten. Zo is 'Frites menu' een kitgroep onder 'Mijn Menu Klein' en heeft het zijn eigen selecteerbare opties.

   • Geneste Kits: Sommige kitopties kunnen ook hun eigen subkits hebben, waardoor er meerdere niveaus van kits ontstaan. De bonlay-out houdt rekening met deze geneste items door middel van duidelijke inspringing.

Voorbeelden van bonlay-outs:

1. Handmatige kortingen:

3. • Wanneer een korting handmatig wordt toegepast op een set-product, toont de bon:

     • De oorspronkelijke prijs en de kortingsprijs voor het set-product.

     • Voor kit-items de oorspronkelijke prijs, het kortingsbedrag en de reden voor de korting (bijv. "Reden: Actie").

   • Zowel in POS als SCO zal deze duidelijke opsomming zichtbaar zijn.

2. Automatische kortingen:

3. • Voor automatische kortingen (bijv. 10% korting op een set) verschijnt de geconfigureerde kortingsnaam naast elk kortingsbaar kit-item.

   • Automatische kortingen kunnen worden ingesteld in de Backoffice onder het gedeelte "Acties", waar kortingen kunnen worden toegepast op een productgroep (bijv. "Menu Set Voedsel 10%").

   • Als de korting wordt toegepast op een specifiek product in plaats van een groep, ontvangt alleen het hoofdset-product de korting.

Voorbeeld bon voor automatische korting:

3. • Wanneer een automatische korting wordt toegepast, toont de bon:

     • De kortingsnaam naast de in aanmerking komende kit-items.

     • Het totaalbedrag dat de korting voor de gehele set weerspiegelt.

Verbeterde Berekening van het Totale Bedrag:

3. • Het totale bedrag onderaan de bon omvat alle toegepaste kortingen, zowel voor het set-product als voor de kit-items. Dit zorgt voor volledige transparantie voor de klant over hoe het eindbedrag is bepaald.

CN 51350

Memo-toevoeging bij uitbetaling van krasloten met gratis loten

Er is een aanpassing doorgevoerd zodat bij het uitbetalen van een kraslot waarbij een gratis lot wordt gewonnen, een extra memo wordt toegevoegd aan de kassabon. Dit gebeurt alleen wanneer het aantal gratis loten 1 of meer is (aangegeven met "nrOfFreeTickets": "1"). Deze memo vermeldt de informatie over het gewonnen gratis lot, ter verduidelijking op de kassabon.

CN 50590

Doorontwikkeling in OV Chip Koppeling op POS

Nieuwe instelling: POSOVChipPopupMode bepaalt nu hoe de OV Chip pop-up op de POS wordt geopend:

• Waarde 0: Pop-up verschijnt alleen na klikken op de backoffice-knop op de POS.

• Waarde 1: Pop-up opent automatisch bij het plaatsen van een OV-chipkaart op de USB reader, mits er een gebruiker is ingelogd en er geen andere pop-up open staat.

Deze wijziging biedt flexibiliteit in het gebruik van de OV Chip functionaliteit op de POS. 

CN 51522

Retourproces: Verplichte Veelvoud

Bij het retourneren van producten is een wijziging doorgevoerd om te voorkomen dat het verplichte veelvoud kan worden omzeild. Vanaf nu wordt er gecontroleerd of retouren voldoen aan de ingestelde verplichte veelvoud, zodat alle retouren correct en conform de regels worden verwerkt.

CN 52542

Verbetering in de OV koppeling op de POS: Directe Retourverwerking

Met de recente wijziging in de OV koppeling van de POS is de mogelijkheid geïntroduceerd om bij het activeren van een restitutiebon het verkochte product direct op de kassabon retour te laten nemen. Hiervoor is de nieuwe instelling POSOvChipReturnMode geïntroduceerd.
De instelling heeft twee waarden:

• 0 (Standaardwaarde): De situatie blijft ongewijzigd. Er wordt gekeken naar het retourproduct dat is ingesteld in de geavanceerde instelling POSOvChipLoadProdID.

• 1: Het zojuist verkochte product dat niet kan worden weggeschreven naar de kaart, wordt direct retour op de bon geplaatst. Dit product kan vervolgens worden afgehandeld.

CN 52630

Verbeteringen in Self-Checkout (SCO) ten behoeve van food-orders

Het scherm voor voedselbestellingen is verder verfijnd om het selectieproces voor kitproducten bij de SCO-toepassing te verbeteren. Deze verbetering vereenvoudigt het proces van het kiezen van opties binnen een samengesteld product, waardoor het intuïtiever wordt voor klanten. Hieronder vindt u een overzicht van de wijzigingen:

• Scrolbaar Food-Order scherm voor opties

• Extra stap voor geneste Kit-groepen

• Inspringen voor geneste opties in winkelwagen

• Visuele aanwijzing voor Kit-productopties in Bedieningsscherm

CN 50255

Verbeteringen in de Self-Checkout (SCO) betalingsflexibiliteit

De Self-Checkout (SCO) is verder geoptimaliseerd om een soepelere afhandeling van transacties te garanderen, zelfs bij problemen zoals defecte PIN-machines. De nieuwe functionaliteiten bieden alternatieve betaalmethoden en extra hulpmiddelen voor medewerkers om wachttijden te verkorten en de klanttevredenheid te verhogen.

Belangrijkste Kenmerken:

1. Alternatieve betaalmethode bij PIN-fouten:

• Inschakelen: Medewerkers kunnen nu de standaard Electronic Funds Transfer (EFT) en Mealcheque betaalmethoden uitschakelen bij defecten van de vaste PIN-machines.

• Instelling: Stel de instelling [SCODisablePinMethod] in op True in de Backoffice. Hierdoor verschijnt de nieuwe werkstationinstelling [SCOAltPinMethod] voor alternatieve betaalmethoden.

  • Configuratie in backoffice:

    • Ga naar de werkstationslijst en selecteer het SCO-werkstation.

    • Voeg de instelling <Setting Key="SCOAltPinMethod" Value="MOBIELEPIN" /> toe. De waarde moet de betaaltypecode zijn (bijv. MOBIELEPIN).

• Gebruik: Bij ingeschakelde instelling [SCODisablePinMethod] kunnen standaard kaartbetalingen (EFT) en Mealcheque-opties worden uitgeschakeld op het SCO tijdens het betalingsscherm.

• Alternatieve betaling: Bij invoer van een medewerkercode kan de normale EFT-betaling worden uitgeschakeld en een alternatieve betaalmethode zoals 'MobielePin' worden gekozen.

2. Afhandeling van onvolledige transacties:

• Speciale betaalmethode: Medewerkers kunnen nu een speciale betaalmethode gebruiken om transacties af te ronden die al gedeeltelijk zijn betaald (bijv. met cadeaubonnen of vouchers), zelfs als er problemen zijn met de betaling.

• Instelling: Zet de instelling SCOPaymeentMethodEmployee in de Backoffice om de speciale medewerker-betalingsmethode beschikbaar te maken bij gedeeltelijke betalingen.

Voorbeeld: Als een klant een cadeaubon heeft gebruikt maar niet het resterende bedrag kan betalen door een bankkaartprobleem, kan de medewerker de betaling afhandelen met de speciale medewerker-betalingsmethode.

Opmerking: De betaalmethode voor correcties moet automatisch contant tellen en een grootboekrekening voor administratie hebben.

3. Event logging voor verantwoordelijkheid:

   • Transactie logging: Wanneer medewerkers speciale betaalmethoden gebruiken, registreert het systeem automatisch het evenement en de medewerker die de transactie heeft uitgevoerd.

   • Transparantie en veiligheid: Dit voorkomt fraude en zorgt voor volledige verantwoordelijkheid en transparantie.

Voorbeeld: Bij gebruik van 'Afgerond Medewerker' om een transactie te voltooien, wordt de actie van de medewerker gelogd voor toekomstig gebruik.

Waar te vinden: Deze logboekitems kunnen worden bekeken in de Backoffice onder Hoofdmenu > Instellingen > evenementberichten.

CN 51169

Uitbreiding Foodservice in de SCO voor SUP-heffing en BTW-tarieven:

De Foodservice in de SCO is verder uitgebreid om wetgeving te ondersteunen omtrent SUP heffing (plastictoeslag) voor het niet ter plekke nuttigen van maaltijden en het toepassen van de juiste BTW tarieven voor het nuttigen van maaltijden ter plekke in België. 

In Nederland is het verplicht om een plastictoeslag toe te kennen als producten in plastic worden verpakt om meegenomen of bezorgd te worden. 

In België geldt een ander (hoger) BTW tarief voor het ter plaatse nuttigen van bepaalde producten ten opzichte van het meenemen (het instellen van andere BTW tarieven op producten is onderdeel van een andere releasenote in Release November 'Ondersteuning voor verschillende BTW-tarieven per product in de REST services'). 

Op basis van de keuze 'Hier opeten' of 'Meenemen' worden automatisch SUP heffingen toegevoegd of de juiste BTW tarieven toegekend. 

Daarnaast is het nu mogelijk om de Selfcheckout in te stellen voor alleen 'Hier opeten', alleen 'Meenemen' of een combinatie van beiden. 

De toepassing van beide Nederlandse en Belgische wetgeving op een transparante manier heeft geresulteerd in het verplaatsen van de vraag voor het 'Hier opeten' of 'Meenemen' van de maaltijd naar het begin van de Foodservice-flow, naar het Welkomstscherm (in plaats van na het drukken op 'Betalen').

Wijziging flow

Wanneer de Selfcheckout is ingesteld voor Foodservice (werkstation setting SCOtype bevat 'Foodservice') wordt na het drukken op 'Bestellen' in het Welkomstscherm óf na het drukken/scannen van het eerste Food-product direct de keuze getoond voor het 'Hier opeten' of 'Meenemen' van maaltijden. 

CN 51583

Instelbare gebruiker voor transacties

• Nieuwe instelling: EmployeeFinishTransaction toegevoegd aan de werkstationconfiguratie om in de Self-Checkout (SCO) expliciet een gebruiker (GroupUserID) toe te wijzen voor het afronden van transacties.

• Gedrag: Bij een ongeldige of ontbrekende waarde wordt de transactie afgerond op de standaardgebruiker (AsposRESTAPIUser).

• Voorbeeld XML:
  <Setting Key="EmployeeFinishTransaction" Value="6061" />

Deze wijziging biedt meer controle over de afronding van transacties.

CN 52355

Aanpassing voor de self-checkout

Er is een fout opgelost in de self-checkout waarbij in sommige gevallen een verkeerd bedrag op het pin scherm werd weergegeven bij het gebruik van kit-items. Deze wijziging zorgt ervoor dat het juiste bedrag nu correct wordt weergegeven, waardoor de betaling correct kan worden afgerond.

CN 52509

Weergave versienummer en werkstationinformatie

Het versienummer van de Selfcheckout (SCO) en het ingelogde werkstation worden nu subtiel rechtsonderin weergegeven op de Welkomstpagina van de SCO, specifiek voor Belgische werkstations met een gekoppelde Blackbox.

Details:

• Bij een Belgisch werkstation met gekoppelde Blackbox wordt het serienummer van het werkstation voor de Blackbox gebruikt (prefix "BVAL002" gevolgd door 7 karakters van het werkstation-ID).

• Deze informatie is ook toegevoegd aan de inlogpagina van de SCO, ongeacht het type werkstation.

• Op de inlogpagina wordt het laatst gebruikte werkstation getoond voordat er wordt ingelogd, wat handig is voor gebruikers om snel te identificeren op welk werkstation ze werken.

CN 52967

Nieuwe functionaliteit in medewerkersmenu selfcheckout

Er is een nieuwe functie toegevoegd aan het medewerkersmenu van de Selfcheckout:

• Uitloggen mogelijk:

  • Het is nu mogelijk om uit te loggen in het medewerkersmenu van de Selfcheckout. Dit maakt het mogelijk om met een ander werkstation in te loggen zonder het geheugen van de browser te legen.

• Beperkingen:

  • De uitlogknop is niet beschikbaar als het medewerkersmenu wordt geopend vanuit het betaalscherm. Dit voorkomt dat deels betaalde transacties per ongeluk worden geannuleerd.

CN 53055

Producten

Wijziging in Intres-integratie

Het veld DrempelDioDud toont nu de waarde "Wonka" wanneer een waarde anders dan "Null" wordt meegegeven door Intres.

Weergave van aangepaste leverdatum op inkooporderregels

Bij het wijzigen van de leverdatum op een inkooporderregel wordt de aangepaste leverdatum nu ook getoond op alle relevante plekken waar dit artikel als "in bestelling" staat. Dit omvat:

• De productinformatie pop-up in het menu Productbeheer

• Het Besteladvies

CN 51927

Financeel

Aanpassing in de backoffice voor DirectSale/Kioskorder annuleringen:

Bij het annuleren van een DirectSale of kioskorder (wanneer de instelling KioskOrderAsSale op true staat), wordt voortaan ook de omzet van de oorspronkelijke transactie tegengeboekt. Tijdens het annuleren worden een refundtransactie en een pakbontransactie aangemaakt. De koppeling met de originele klantorder is terug te vinden in de transactie-extensies.

Let op:

• Deze functionaliteit werkt niet in combinatie met de instelling CustOrdCancelMakeTrans. Zorg ervoor dat deze instelling op false staat om de annulering naar verwachting te laten verlopen.

Overzicht van geannuleerde DirectSale Order in transactiebeheer:

• Het transactiebeheer toont een duidelijk overzicht van de geannuleerde DirectSale order, inclusief de bijbehorende refund- en pakbontransacties.

CN 48867

Klanten

Aanpassing verdeelorder verwerking bij gedeeltelijke afhandeling in de POS

Met deze wijziging is de logica aangepast voor het verwerken van verdeelorders wanneer gebruik wordt gemaakt van de setting OrderDistributionMode (2). Dit zorgt ervoor dat als een verdeelorder in de POS tussentijds gedeeltelijk wordt afgehandeld, de bijbehorende verdeelorder correct wordt bijgewerkt.

Details:

• Bij het gedeeltelijk ophalen van een klantorder in de POS wordt het opgehaalde artikel voortaan geannuleerd in de gekoppelde verdeelorder en inkooporder.

• Dit betekent dat de statussen van de bronorder, verdeelorder, en inkooporder worden geüpdatet om de gedeeltelijke afhandeling correct weer te geven.

Hierdoor ontstaat een weergave van de orderstatussen en blijft de voorraadadministratie consistent bij gedeeltelijke leveringen.

CN 51374

CN 51374

Nieuwe Instelling voor aanbetalingen in de Backoffice

Wijziging: Een nieuwe instelling genaamd BODownPaymentPaymentType maakt het mogelijk om aanbetalingen in de klantorderpagina van de Backoffice te boeken op een andere betaalsoort dan 'Bank'.

Gebruik:

• Vul de instelling in met de gewenste betaalsoortcode (te vinden in het Backoffice menu 'Betaalsoorten').

Let op:

• Bij een onjuiste of lege invoer wordt standaard teruggevallen op de betaalsoort 'Bank'.

• De instelling is overerfbaar en vereist de juiste rechten voor configuratie als systeemveld.

CN 51517

Orderannulering aangepast

Wanneer de setting OrderDistributionMode is ingesteld op '2', worden orders niet langer automatisch geannuleerd, zelfs als ze volledig worden uitgeleverd via de POS. Deze aanpassing zorgt ervoor dat orders behouden blijven in het systeem.

CN 52258

Uitbreiding van de filters voor Klantevents

In de Backoffice zijn twee nieuwe filters toegevoegd aan het menu [Klantevents beheer]:

Actie Vereist:

• Dit filter maakt het mogelijk om evenementen te filteren op basis van het vinkje [Actie nodig] (ja/nee) in het evenement.

• Standaard staat dit filter op [Ja].

Actie Type:

• Dit filter maakt het mogelijk om evenementen te filteren op basis van het [Actie type] in het evenement.

• Opties: Bellen, Geen, Mailen, Offerte, en Picken.

• Standaard zijn alle opties aangevinkt, behalve de optie "Geen".

In de Rest service is een aanvullende wijziging doorgevoerd welke terug te vinden zijn onder Services in de release notes van Oscar.

CN 52331

ASPOS Tasks aanpassing: geen betaallink bij creditfacturen

Wanneer een creditfactuur wordt verzonden via ASPOS Tasks, zal deze voortaan geen betaallink meer bevatten. Dit om te voorkomen dat klanten onterecht een betaallink ontvangen bij creditfacturen, waar geen betaling vereist is.

CN 52961

Aanpassingen in het Backoffice menu 'Klantevents Beheer'

De volgende wijzigingen zijn doorgevoerd in het menu 'Klantevents Beheer' in het Backoffice:

1. Nieuwe Filterknop:

• Een nieuwe filterknop genaamd 'Geen uitvoerdatum' is toegevoegd. Deze knop sorteert de events zonder uitvoerdatum van oud naar nieuw.

2. Standaard Filterinstelling:

• Het veld 'Uitvoerdatum' is standaard ingesteld op een periode van 90 dagen voor meer duidelijkheid bij het toepassen van filters.

CN 52485

Verbeteringen aan de functie 'THT wijzigen'

We hebben een aantal handige aanpassingen doorgevoerd aan de functie 'THT wijzigen' om jouw gebruikerservaring te verbeteren:

• Standaardwaarde voor lege THT: Wanneer je een THT-veld leeg laat en probeert te wijzigen, wordt er nu automatisch de huidige datum ingevuld. Dit bespaart je tijd en voorkomt fouten.

• Vastgezet scherm tijdens wijziging: Het scherm zal tijdens het wijzigen van de THT niet meer meeschuiven. Dit zorgt voor een stabielere en focusserdere ervaring.

• Snellere verwerking van THT-data: Het ophalen van de ingevulde THT-datum is geoptimaliseerd, waardoor je wijzigingen sneller doorgevoerd ziet.

CN 52255

Aansturen LED-verlichting labels via Vusion

In deze release is het mogelijk om de LED-verlichting van labels direct aan te sturen via Vusion, in combinatie met de PDA. Hiermee kun je de kleur van de verlichting aanpassen om bijvoorbeeld prioriteiten aan te geven of specifieke locaties te markeren.

Hoe werkt het:

• Activering: De functie is actief wanneer de instelling "ProductESLUseLED" op "true" staat.

• Beschikbare taken: De functie is beschikbaar in de volgende taken:

  • Telopdrachten

  • Pick klantorder

  • Pick batch

  • Wegzetlijst

• Aanpassen kleur: Onderin het scherm verschijnt een pallet-icoontje waarmee je eenvoudig de kleur van de verlichting kunt aanpassen naar jouw voorkeur.

CN 52407

Verwerkingsgeschiedenis van ontvangsten

Om de traceerbaarheid te verhogen, wordt er nu bij elke verwerkte ontvangst de naam van de betreffende gebruiker opgeslagen. Dit zorgt voor een helder overzicht van alle uitgevoerde handelingen.

CN 52499

Efficiënter batch picken:

We hebben het batch pick proces verder geoptimaliseerd:

• Overzichtelijke batchnamen: Voor interfiliaal orders zie je nu direct het eerste filiaal in de batchnaam.

• Snel scannen: Scans worden automatisch geregistreerd, waardoor je tijd bespaart.

• Meer flexibiliteit: Je kunt nu ook zonder container picken, wat handig is bij eenvoudige batches.

CN 53070

Correctie datumreeks in Slim Beheer

In een eerdere versie van Slim Beheer werd bij het uitvoeren van voorraadmutaties de datumreeks met één dag verschoven. Dit probleem is nu opgelost.

CN 53088

Verbeterde gebruikerservaring: Kortere pop-ups

We hebben gehoord dat de pop-up meldingen soms te lang in beeld bleven, waardoor je werk onderbroken werd. Daarom hebben we de weergavetijd van deze meldingen aanzienlijk verkort.

CN 53089

Verbeterde duidelijkheid in productinformatie

Om je werk nog efficiënter te maken, hebben we de headers in de productinformatie schermen aangepast. Deze headers geven nu een duidelijke indicatie van de specifieke functie waar je mee bezig bent. Hierdoor kun je beter begrijpen welke informatie relevant is en waar je andere functies kunt vinden.

CN 53094

Real-time synchronisatie van picklijsten

De picklijsten op je PDA worden nu real-time gesynchroniseerd met de centrale database. Hierdoor wordt gegarandeerd dat je altijd de meest recente informatie tot je beschikking hebt.

CN 53140

Geautomatiseerde ontvangstcreatie bij interfiliaal orders

Vanaf nu kun je bepalen of er automatisch een ontvangst wordt aangemaakt wanneer je een interfiliaal pick order afrondt. Deze handeling wordt gestuurd door de instelling 'InterstoreCreateReceiving'.

CN 53213

Flexibeler annuleren van interfiliaal orders

We hebben een nieuwe instelling toegevoegd die je meer controle geeft over het annuleren van interfiliaal orders.

Wat is er veranderd?

• Optioneel annuleren: Je kunt nu zelf bepalen of een interfiliaal order automatisch geannuleerd wordt als er niets is gepickt. Deze instelling vind je onder de naam 'WifiCancelMxxxOrder'.

• Standaardinstelling: De standaardinstelling is 'true', wat betekent dat de huidige werkwijze behouden blijft. Als je de automatische annulering wilt uitschakelen, stel je deze waarde in op 'false'.

CN 53223

Uitbreiding van de Aanbetalingsfunctionaliteit voor Klantorders in de REST Services

De functionaliteit voor het aanbetalen van klantorders is uitgebreid, zodat het nu ook mogelijk is om een klantorder van een andere winkel aan te betalen. Deze verbetering is ook beschikbaar in de POS-omgeving. Hieronder volgen de details van deze uitbreiding:

Instellingen en Functionaliteit:

1. Instellingen:

   • [PrePayCustOrdOtherStores]: Wanneer deze instelling op "Ja" staat, kan een klantorder van een andere winkel worden aangebetaald.

   • [ShowCustOrdersFromNode]: Deze instelling bepaalt tot welk niveau klantorders van andere winkels kunnen worden aanbetaald. De waarde moet de storeCode van de winkel bevatten.

2. Endpoint voor Aanbetaling:

   • POST /api/transactions/Commit: Bij het aanroepen van dit endpoint moet het storeId worden opgegeven van de winkel die de aanbetaling op de klantorder uitvoert.

Voorbeeld request:

Wanneer een klantorder door een andere winkel wordt aangebetaald, ziet het request er als volgt uit:

{

    "transaction": {

        "storeId": 1,  // Winkel die de aanbetaling op de order van een andere winkel doet.

        "customerId": 31,

        "payments": [

            {

                "amount": 25.00,

                "paymentMethodId": 1

            }

        ]

    },

    "downpayments": [

        {

            "customerOrderId": 123,  // Klantorder aangemaakt op StoreID = 5.

            "amount": 25.00

        }

    ]

}

Belangrijkste Punten:

2. • De storeId in de transactie specificeert de winkel die de betaling uitvoert.

   • Het customerOrderId in de aanbetalingssectie verwijst naar de klantorder van een andere winkel.

   • Deze uitbreiding maakt het mogelijk om flexibel klantorders te beheren en aanbetalingen te verwerken, zelfs wanneer de klantorder afkomstig is van een andere vestiging.

CN 48640

Ondersteuning voor meerdere Filiaalorders/Inkooporders en Afhaalorders in REST Endpoint

Met deze wijziging is het nu mogelijk om een klantorder te verwerken naar meerdere filiaalorders of inkooporders via het bestaande endpoint POST /api/customer-orders/{id}/Process. Voorheen was dit beperkt tot bezorgorders. Deze aanpassing biedt meer flexibiliteit in het orderbeheer en verwerking van klantorders naar verschillende winkels.

Belangrijkste aanpassingen:

1. Meerdere Filiaalorders/Inkooporders per Klantorderregel:

   • Per orderregel kan nu worden aangegeven welke winkel de levering gaat verzorgen.

   • In de body van het request kunnen verschillende deliveryStores worden opgegeven met bijbehorende customerOrderLineIds.
     POST /api/customer-orders/{id}/Process

{

    "deliveryStores": [

        {

            "deliveryStoreId": 5,

            "customerOrderLineIds": [1, 2],

            "expirationDate": "2050-08-27T12:09:46.191Z",

            "expirationMemo": "Dit is de memo voor de vervaldatum 1."

        },

        {

            "deliveryStoreId": 6,

            "customerOrderLineIds": [3],

            "expirationDate": "2050-01-27T12:09:46.191Z",

            "expirationMemo": "Dit is de memo voor de vervaldatum 2."

        }

    ]

}

2. Opslag van vervaldatum en memo per winkel:

   • De velden expirationDate en expirationMemo kunnen per winkel worden meegegeven.

   • Deze gegevens worden opgeslagen op de orderregel van de originele klantorder en in de klantorder-extensie van de filiaalorder(s) met de benamingen ExpirationDate en ExpirationMemo.

3. Geen aanmaak van filiaalorder/inkooporder voor originele winkel:

   • Als de deliveryStore in het request overeenkomt met de winkel van de originele order, wordt er geen nieuwe filiaalorder of inkooporder aangemaakt.

   • De velden expirationDate en expirationMemo worden wel opgeslagen op de orderregel.

4. Verwerking van afhaalorders:

• Het is nu ook mogelijk om afhaalorders te verwerken via dit endpoint. Dit was voorheen alleen mogelijk voor bezorgorders.

• Afhaalorders kunnen alleen worden verwerkt als de deliveryStores in de body van het request worden opgegeven.

CN 52157

Nieuwe functionaliteit in REST services: expand optie voor kind-/filiaalorders

In de REST services is een nieuwe expand-optie toegevoegd aan de verschillende GET /api/customer-orders endpoints.

Details:

• Expand Optie: relationLogs

  • Met deze nieuwe optie is het mogelijk om de kind- of filiaalorders van de ouder- of bronorder op te halen.

  • Dit stelt gebruikers in staat om een uitgebreidere weergave te krijgen van alle gerelateerde orders die verbonden zijn met de opgegeven ouderorder.

Deze uitbreiding vergemakkelijkt het beheren en volgen van de volledige orderstructuur door alle gerelateerde orders te tonen in één verzoek.

CN 52160

Update in GET /api/transactions Endpoints

• Nieuw veld toegevoegd: Alle GET /api/transactions endpoints bevatten nu een nieuw veld genaamd returnBarcode. Dit veld toont de gegenereerde retourbarcode voor een transactie.

• Opbouw van de retourbarcode: De retourbarcode wordt samengesteld uit de volgende componenten:

  • Prefix: Afkomstig van de storesetting ReturnPrefix.

  • StoreId of BranchNumber: Afhankelijk van de storesetting ReturnUseStoreOIDForEan, die bepaalt of het storeId of branchNumber wordt gebruikt.

  • Laatste 6 cijfers van het transactionNumber

  • Controlegetal

De uiteindelijke barcode heeft de volgende opbouw: Prefix + StoreId/BranchNumber + Laatste 6 cijfers van transactionNumber + Controlegetal.

Voorbeeld van een API-response:

GET /api/transactions/19858

{

    "id": 19858,

    "number": 1313,

    "returnBarcode": "9900050013139",

    "date": "2020-01-13T12:51:17.437Z",

    "storeId": 5,

    "customerId": 31,

    "amountInclTax": 10002.54,

    "taxAmount": 825.77,

    "amountExclTax": 9176.77,

    "discountAmount": 0.00,

    "payableAmount": 10002.54,

    "receivedAmount": 10002.54,

    "bonusPoints": 0,

    "sessionIdCreated": 3265,

    "groupUserId": 109,

    "type": "Invoice",

    "typeDescription": "Faktuur",

    "state": "commited",

    "cashDrawerId": 36,

    "notes": "Notitie Transactie",

    "documentID": "4",

    "invoiceId": 98

}

Deze update zorgt ervoor dat retourbarcodes direct beschikbaar zijn bij het opvragen van transactiegegevens via de API.

CN 52161

Uitbreiding van de filters voor Klantevents

In de REST services is bij het endpoint GET /api/customer-events een nieuw filter toegevoegd: [actionTypes]. Dit filter maakt het mogelijk om evenementen te filteren op het actie-type van het evenement.

In de backoffice zijn aanvullende wijzigingen doorgevoerd welke terug te vinden zijn onder Backoffice - Klanten in de release notes van Oscar.

CN 52331

Wijziging in Transactie Extensies:

In de transactie-extensies is een aanpassing doorgevoerd waarbij voortaan in de response vanuit Bovertis het veld "cardName" wordt meegegeven in plaats van "brandName".

CN 52715

Aanpassing bij POST /api/customer-orders/{id}/CreateStoreJobsFromPickingLines in REST Services

Er zijn diverse wijzigingen doorgevoerd in het POST /api/customer-orders/{id}/CreateStoreJobsFromPickingLines endpoint om de verwerking van StoreJobs te verbeteren:

Controle op StoreJob Statussen:

• Aanroepen van CreateStoreJobsFromPickingLines terwijl er een StoreJob met de status pending bestaat, is nog steeds niet toegestaan.

• Het aanroepen van CreateStoreJobsFromPickingLines terwijl er een StoreJob met de status finished bestaat, is nu wel toegestaan. Als er nog openstaande pickinglines zijn, worden er nieuwe StoreJobs aangemaakt.

• Het aanroepen van CreateStoreJobsFromPickingLines terwijl er een StoreJob met de status open bestaat, is nu ook toegestaan. Als er geen pickinglines meer zijn, worden de bestaande StoreJobs verwijderd. Dit resulteert in een status 200, maar er worden geen nieuwe StoreJobs aangemaakt.

Verwerking van Pickinglines:

• Als de pickinglines zijn gewijzigd, worden de bestaande StoreJobs verwijderd en worden er nieuwe StoreJobs aangemaakt.

• Als de pickinglines resulteren in exact dezelfde StoreJobs (gebaseerd op aantallen en de storesetting WifiStoreJobSplitLoc), worden er geen nieuwe StoreJobs aangemaakt. In plaats daarvan worden de bestaande StoreJob IDs teruggegeven.

CN 52774

Nieuwe filteroptie in REST services: LabelType filtering

In de REST services is een nieuw filter toegevoegd aan het endpoint GET /api/label-layouts.

Details:

• Filter: labelTypeIds

  • Met dit nieuwe filter kunt u de label-layouts filteren op basis van het labelType.

  • Dit maakt het mogelijk om specifiek te zoeken naar layouts die zijn gekoppeld aan bepaalde labeltypes, waardoor het beheer en de organisatie van labellayouts efficiënter worden.

Deze toevoeging helpt gebruikers om gerichter te zoeken naar de benodigde label-layouts, gebaseerd op het type label dat ze willen gebruiken.

CN 52879

Uitbreiding van het endpoint voor leveringsbonnen

Het endpoint POST /api/customer-orders/{id}/ConvertToDeliveryNote is uitgebreid. Het ondersteunt nu ook het omzetten van orders naar een leveringsbon, zelfs wanneer de orderregels alleen negatieve toDeliveryQuantity waarden bevatten.

CN 53460