VERSIE: 6.0.2026NewYork

MAUI Narrowcasting v4: Klantscherm en weergavefouten

In MAUI Narrowcasting (versie 4) is de functionaliteit van het klantscherm (customer display) bij de POS-kassa bijgewerkt. De bestaande instelling voor aangepaste berichten wordt nu ondersteund en er zijn diverse verbeteringen doorgevoerd in de weergave van product- en kortingsregels.

Aangepaste tekst op het klantscherm (POS-NCCustPointMessage)

MAUI Narrowcasting (versie 4) volgt nu het gedrag van de oudere versie 3 wat betreft de parameter POS-NCCustPointMessage.

• Wanneer deze instelling is gevuld (bijvoorbeeld met de tekst 'Heeft u een klantpas?'), vervangt dit de standaardtekst 'Uw kassabon' rechtsboven op het klantscherm.

• De ruimte hiervoor is beperkt tot één regel. Als de ingevoerde tekst te lang is, wordt deze automatisch afgekapt zodat het op de regel past.

• Als de instelling leeg is, blijft de standaardtekst ('Uw kassabon') behouden.

Weergave van kortingen en kitproducten

• Wanneer er korting wordt gegeven op Kit(groep)producten, wordt dit nu als een aparte kortingsregel op het klantscherm getoond. Dit werkt nu op dezelfde manier als bij reguliere producten. 

Opgeloste weergavefouten

Daarnaast zijn de volgende visuele correcties doorgevoerd op het klantscherm:

• De verticale uitlijning van de aantallen bij kitregels is gecorrigeerd.

• Er werd onterecht een aantal (hoeveelheid) getoond bij kortingsregels; dit is verwijderd.

• De ontbrekende omschrijving op kortingsregels is toegevoegd.

• De kortingsregel wordt nu correct als laatste regel gepositioneerd, in plaats van willekeurig tussen de reguliere productregels.

Systeeminstellingen en vereiste configuratie

• Deze wijzigingen zijn uitsluitend van toepassing op kassa's waar de instelling POSCustomerDisplayVersion de waarde 4 heeft.

• Beheerders kunnen desgewenst de instelling POS-NCCustPointMessage controleren en vullen. Er zijn hiervoor geen nieuwe parameters of instellingen toegevoegd.

CN 77939

Homepage

Correctie weergave aantal openstaande klantorders op het dashboard

Er is een wijziging doorgevoerd in de weergave van data op het dashboard, specifiek voor het onderdeel dat de open klantorders toont.

Wat is er gewijzigd?

• Het dashboard toont vanaf nu het werkelijke, actuele aantal openstaande klantorders.

• De telling is gelijkgetrokken met de achterliggende overzichtspagina: het getoonde aantal op het dashboard komt nu exact overeen met de resultaten van de standaard filtering op de reguliere klantorderpagina.

• Dit lost een eerdere inconsistentie op, waardoor de getallen op beide schermen nu synchroon lopen en betrouwbaarder zijn.

Vereiste actie

Deze weergavecorrectie is op de achtergrond doorgevoerd en direct actief. Er is geen actie of configuratie vereist van beheerders of gebruikers.

CN 78668

Rapportages

Pakbon rapport

Klant specifiek pakbon rapport gemaakt naar wensen van de desbetreffende klant.

CN 77940

Producten

Introductie MatrixModel

MatrixModel is vanaf nu het primaire producttype voor het beheren van productvarianten (kleuren en maten) binnen één structuur.

Nieuwe functionaliteiten

• Structuur: Met het MatrixModel kunnen een set kleuren en een reeks maten worden gedefinieerd. (Let op: het veld 'Matrix' is verplicht).

• Generatie van varianten: Kleuren kunnen worden toegevoegd via het tabblad 'Color'. Bij het opslaan worden de maten geselecteerd. Het systeem creëert vervolgens automatisch een aparte Matrix voor elke kleur, inclusief de bijbehorende MatrixProducts (maat-varianten).

• Koppelingen: Het hoofd-MatrixModel is gekoppeld aan alle kleurvarianten, en alle kleurvarianten zijn ook onderling gekoppeld.

• Extra kleurdata: Ondersteuning is toegevoegd voor de velden Color Code, Supplier Color Code en Supplier Color Description. De leveranciersvelden zijn bewerkbaar via het kleur-tabblad.

• Leverancierscodes: De Supplier Product Code wordt nu opgebouwd uit de ingevoerde leverancierscode (uit het MatrixModel) gecombineerd met de Supplier Color Code. Als deze laatste ontbreekt, gebruikt het systeem de standaard Color Code.

Systeemlogica & Workflow

• Synchronisatie: Bij het opslaan of bewerken van data kan worden gekozen of de wijziging moet worden doorgezet naar de onderliggende webshops.

• Verwijderen van producten: Een product kan alleen worden verwijderd als het geen voorraad heeft (alle aantallen = 0), geen onderdeel is van een product-kit en geen actieve afhankelijkheden heeft. Voldoet het product hier niet aan, dan toont het systeem een waarschuwing.

Belangrijke wijziging 

• Overschrijven van data: Het updaten van een Matrix Model overschrijft de data van alle gerelateerde Matrix (moeder)producten en Matrix Products. Dit betekent dat eventuele wijzigingen die eerder direct op de individuele matrices of varianten zijn gedaan, verloren gaan bij een update van het hoofdmodel.

CN 72733

Nieuwe verkoopkolommen in het voorraadoverzicht

Het voorraadoverzicht in de backoffice (op te roepen via de sneltoets Alt+I op een product) is uitgebreid. Naast de bestaande informatie over voorraad, inkooporders en klantorders, kunnen er nu drie extra kolommen worden getoond die de verkoophistorie weergeven.

Werking en berekening

De nieuwe kolommen (4W / 12W / 52W) tonen de gerealiseerde verkoopaantallen van de afgelopen 4, 12 en 52 weken, inclusief de huidige dag. Hierbij gelden de volgende bedrijfsregels:

• Magazijnspecifiek: De waarden worden per magazijn berekend en getoond, niet als totaal van de gehele winkel.

• Realtime verwerking: Verkopen van vandaag tellen direct mee op basis van de openstaande statussen (SalesPendingQuantity en DeliveriesPendingQuantity).

• Ordertypes: DirectSales-orders tellen direct mee als verkoop. Reguliere klantorders worden pas meegeteld zodra de pakbon is aangemaakt.

• Retouren: Retourtransacties verlagen de geregistreerde verkoopaantallen.

Weergave en gebruik

• De kolommen zijn puur informatief (read-only) en niet klikbaar.

• Wanneer het voorraadoverzicht op een kleiner scherm wordt geopend, wordt er automatisch een scrollbalk toegevoegd om alle kolommen leesbaar te houden.

Systeeminstellingen en vereiste configuratie

Om deze functionaliteit te activeren, is een aanpassing in de instellingen vereist:

• ShowSalesInProdInfo: Deze store setting bepaalt of de nieuwe verkoopkolommen worden getoond in het voorraadoverzicht. De standaardwaarde is False. Zet deze op True voor de vestigingen waar dit gewenst is. Er is geen verdere inrichting (zoals templates of rapporten) nodig.

Buiten scope

• De kolommen kunnen niet worden gesorteerd of gefilterd.

• Er is geen export- of printfunctie voor deze specifieke verkoopkolommen in dit scherm.

• De getoonde verkoopgegevens worden direct in de pop-up gerenderd en zijn niet beschikbaar via de API.

CN 77417

Geoptimaliseerd proces voor DC Verdelen

Het handmatige proces voor het verdelen van voorraad vanuit een distributiecentrum (DC) is vervangen door een geoptimaliseerde workflow. Afhankelijk van de configuratie kan het systeem nu automatisch vervolgstappen uitvoeren, zoals het verwerken van inkooporders, het omzetten van FILW-orders naar pakbonnen en het verwerken van ontvangsten.

Locatie in de applicatie

• Scherm: Producten → Voorraadinformatie (Alt+I) → knop 'DC Verdelen'. Dit is benaderbaar vanuit elk scherm waar de voorraad-pop-up (Alt+I) beschikbaar is.

Werking en automatisering (StockTransferMode)

Na het invullen van de te verdelen hoeveelheden en het klikken op 'Verwerken', bepaalt de instelling StockTransferMode welke acties automatisch op de achtergrond worden uitgevoerd:

• Mode 0: Een inkooporder wordt aangemaakt en verwerkt. De FILW-order en de ontvangst moeten handmatig worden verwerkt.

• Mode 1: Een inkooporder wordt aangemaakt en verwerkt, en de FILW-order wordt automatisch omgezet naar een pakbon. De ontvangst moet handmatig worden verwerkt.

• Mode 2: Volledig geautomatiseerd proces. De inkooporder, de pakbon (via FILW) en de ontvangst worden allemaal automatisch verwerkt.

• Melding: Na afloop toont het systeem een overzicht van de succesvol uitgevoerde stappen.

Handmatig afwijken per verdeling

Op het 'DC Verdelen' scherm zijn twee checkboxen toegevoegd ('FILW' en 'Ontvangst'). De standaardstatus van deze vinkjes wordt bepaald door de actieve StockTransferMode. Gebruikers kunnen deze vinkjes handmatig aanpassen om per transactie af te wijken van het standaardgedrag.

Let op: de checkbox 'Ontvangst' is alleen beschikbaar (enabled) als de checkbox 'FILW' is aangevinkt.

Systeeminstellingen en vereiste configuratie

Om gebruik te maken van de automatisering moeten applicatiebeheerders de volgende instellingen nalopen:

• StockTransferMode: Dient op de gewenste waarde (0, 1 of 2) te worden ingesteld op zowel de HQ-vestiging als de ontvangende vestiging(en). De standaardwaarde is 0.

• InterstoreVersion: Ondersteunt versie 1 en 2. Bij versie 2 daalt de fysieke voorraad op HQ direct bij het aanmaken van de pakbon.

• InterstoreCreateReceiving: Bij het gebruik van de knop 'DC Verdelen' wordt er altijd een ontvangst aangemaakt, ongeacht of deze parameter op True of False staat.

Buiten scope

Bestaande verdeelsleutels (distribution keys) en overige reguliere interstore-processen zijn niet gewijzigd in deze update. Er is geen dataconversie vereist voor deze functionaliteit.

CN 77418

Nieuwe visuele actie-indicator in het Besteladvies

Het handmatige proces voor het verdelen van voorraad vanuit een distributiecentrum (DC) is vervangen door een geoptimaliseerde workflow. Afhankelijk van de configuratie kan het systeem nu automatisch vervolgstappen uitvoeren, zoals het verwerken van inkooporders, het omzetten van FILW-orders naar pakbonnen en het verwerken van ontvangsten.

Werking van de indicator

• Zichtbaarheid: Er wordt een actie-icoon getoond zodra een product in een lopende actie zit, óf in een actie die binnen nu en 4 weken start. Heeft het product geen kwalificerende actie, dan blijft de kolom leeg. Het termijn van 4 weken is vast ingesteld en niet handmatig aanpasbaar.

• Voorwaarde: Alleen acties die op de standaard prijslijst staan, worden meegenomen en triggeren het icoon. Acties op afwijkende prijslijsten worden niet getoond.

• Sorteren: De nieuwe kolom is sorteerbaar, waardoor het mogelijk is om alle actieproducten in het besteladvies bij elkaar te groeperen.

• Puur informatief: De berekening van het besteladvies zelf (zoals de geadviseerde aantallen, min/max en franco) is niet gewijzigd.

Actiedetails inzien

Het actie-icoon is klikbaar. Bij het aanklikken opent een pop-up met een overzicht van de geldende acties voor dat specifieke product, inclusief de kolommen: Code, Winkel, Van, Tot, Omschrijving, Prijslijst en Folderkenmerk.

• De status (Actief/Aankomend) is af te leiden uit de 'Van'- en 'Tot'-datums.

• De actieregels in deze pop-up zijn niet klikbaar om onbedoelde navigatie weg van het besteladvies te voorkomen. Na het sluiten van de pop-up blijft het oorspronkelijke besteladvies intact staan.

Systeeminstellingen en vereiste configuratie

Deze wijziging is standaard beschikbaar voor alle gebruikers met de benodigde rechten om het besteladvies te openen. Er hoeven geen nieuwe instellingen of toggles geactiveerd te worden. Voorwaarde is uiteraard wel dat de actiegegevens (bijvoorbeeld via de reguliere import) aanwezig zijn in het systeem.

CN 77435

Nieuwe voorraadkolom voor kitcomponenten in Productbeheer

Op het tabblad 'Kitproducten' bij een kitproduct in Productbeheer is een nieuwe kolom "Voorraad" toegevoegd. Hiermee is direct inzichtelijk wat de actuele beschikbare voorraad is van de afzonderlijke onderdelen (componenten) van de kit, zonder dat de artikelcode van elk onderdeel apart hoeft te worden opgezocht.

Weergave en berekening

• De nieuwe kolom "Voorraad" wordt op het tabblad gepositioneerd vóór de bestaande kolom "Aantal".

• De getoonde voorraadwaarden zijn puur informatief (alleen-lezen) en linken niet door naar een achterliggend voorraadscherm.

• De reikwijdte van de berekende voorraad is afhankelijk van de bestaande instelling ProductsShowStockTotal:

  • Uit (False): De getoonde waarde is de som van de voorraad van alle voorraadhoudende magazijnen van uitsluitend de eigen winkel.

  • Aan (True): De getoonde waarde is de som van de voorraad van alle voorraadhoudende magazijnen van alle zichtbare winkels.

Systeeminstellingen en vereiste configuratie

Om deze functionaliteit te activeren, is een nieuwe instelling geïntroduceerd:

• ShowStockForKitProds: Deze instelling bepaalt of de voorraadkolom op het tabblad wordt getoond. De standaardwaarde is False.

• Beheerders dienen deze instelling op True te zetten voor de winkels waar deze weergave gewenst is. Er is verder geen aanvullende inrichting, zoals templates of rapporten, vereist.

Buiten scope

Er zijn geen wijzigingen doorgevoerd in de berekeningslogica van de voorraad zelf; het systeem maakt volledig gebruik van de reeds bestaande logica achter de parameter ProductsShowStockTotal.

CN 77978

Gebruikers

Opsplitsing autorisatierechten voor merken en productgroepen (Backoffice Next)

De autorisatierechten (securitydoors) voor het beheren van merken en productgroepen in Backoffice Next zijn aangepast. Waar het toevoegen en wijzigen voorheen onder één gecombineerd recht vielen, zijn deze nu opgesplitst in afzonderlijke rechten

Wat is er gewijzigd?

• Gescheiden rechten: Beheerders kunnen nu de rechten voor het 'toevoegen' en het 'wijzigen' van een merk of productgroep onafhankelijk van elkaar toewijzen aan gebruikers(groepen).

• Oude benamingen aangepast: Om duidelijk onderscheid te maken tussen de oude en de nieuwe situatie, is aan de naam van de voormalige, gecombineerde rechten de tekst "(oud)" toegevoegd. Een bestaand recht heet in de lijst nu bijvoorbeeld: Productgroep toevoegen/wijzigen (oud).

• Toepassingsgebied: Deze wijziging in de securitydoors is uitsluitend van toepassing binnen Backoffice Next.

Vereiste actie

Voor beheerders is het nu mogelijk om de rechten rondom merken en productgroepen specifieker in te regelen via de nieuw toegevoegde, gesplitste securitydoors.

CN 77437

Klanten

Beperking op het kopiëren van orderregels bij klantorders

Er is een extra validatie toegevoegd aan het beheer van klantorders. Wanneer een klantorder de eigenschap AllowChange = False heeft (wat aangeeft dat de order geblokkeerd is voor bewerkingen), is het vanaf nu ook niet meer mogelijk om een bestaande orderregel te kopiëren.

Werking en impact

• Deze wijziging sluit een hiaat waarbij het kopiëren van een regel nog wel mogelijk was, terwijl de order feitelijk niet meer gewijzigd mocht worden.

• De blokkade helpt bij het borgen van de data-integriteit van klantorders die afgerond of vergrendeld zijn.

Vereiste actie

Deze functionele aanscherping is direct actief. Er zijn geen nieuwe instellingen of parameters toegevoegd en er is geen configuratie vereist vanuit beheerders.

CN 78824

Herstel voorraadbijwerking bij het verwijderen van een ontvangst via de API

Er is een correctie doorgevoerd in de REST API met betrekking tot het verwijderen van ontvangsten (receivings).

Wat is er opgelost?

• Voorheen werd bij het verwijderen van een ontvangst via de API de waarde receivingsPendingQuantity (de openstaande, te ontvangen hoeveelheid) niet altijd correct bijgewerkt in de voorraadadministratie.

• Deze fout is nu hersteld: wanneer een ontvangst via de API wordt verwijderd, wordt de verwachte ontvangsthoeveelheid weer direct en juist gecorrigeerd.

Vereiste actie

Deze bugfix is op de achtergrond verwerkt en direct actief. Er is geen actie of aanpassing in de configuratie vereist voor API-gebruikers of beheerders.

CN 76440

Uitbreiding ondersteuning ontvangstrapporten in REST API

Er is ondersteuning toegevoegd voor het genereren van diverse ontvangstrapporten (receiving reports) via de REST services.

Betrokken endpoints

De wijziging is van toepassing op de volgende bestaande endpoints:

• POST /api/reports/Generate

• POST /api/reports/GenerateUrl

Nieuwe ondersteunde rapporten

Via de bovengenoemde endpoints kunnen vanaf nu de volgende rapporten worden opgevraagd:

• ReceivingInternal

• ReceivingCountings

• ReceivingDifferences

• ReceivingVersusPurchaseOrder

• ReceivingPutAwayList

• ReceivingA4KLB

Deze update betreft uitsluitend een backend-uitbreiding voor API-gebruikers en vereist verder geen specifieke inrichting of systeeminstellingen.

CN 76453

Nieuw API-endpoint: Ontvangst aanmaken vanuit inkooporder

Er is een nieuw REST API-endpoint toegevoegd in de module Ontvangsten (POST /api/receivings/CreateFromPurchaseOrder). Hiermee kan nu via de API direct een ontvangst worden aangemaakt op basis van een bestaande inkooporder of een specifieke inkooporderzending. Deze functionaliteit was voorheen uitsluitend beschikbaar via de schermen in de oude backoffice.

Werking van het endpoint

Bij het aanroepen van het endpoint moet exact één van de twee parameters worden meegegeven: purchaseOrderId óf purchaseOrderShipmentId. Afhankelijk van de keuze gelden er specifieke regels:

1. Aanmaken op basis van een Inkooporder (purchaseOrderId)

• De inkooporder moet de status Ordered of Partially received hebben.

• Alleen inkooporderregels met een openstaande te ontvangen hoeveelheid worden overgenomen op de ontvangst.

• Prijzen, kortingen en bedragen worden naar rato van de resterende hoeveelheid berekend. Leveranciersartikelcodes en btw-gegevens worden direct van de orderregel gekopieerd.

• De aangemaakte ontvangst krijgt de status Pending, met als bron FromPurchaseOrder. De ontvangstcode wordt automatisch gegenereerd en begint met het inkoopordernummer.

• Bij een multistore-inkooporder wordt het ontvangsttype InterStore, in alle andere gevallen Default.

2. Aanmaken op basis van een Zending (purchaseOrderShipmentId)

• De gekoppelde zending moet de status Open hebben.

• In plaats van de orderhoeveelheden worden de daadwerkelijk verzonden hoeveelheden (ShippedQuantity / ShippedStockQuantity) overgenomen als ontvangstregels.

• Zendingsregels zonder bijbehorende inkooporderregel (bijv. een onvoorzien artikel dat via een barcode-import is toegevoegd aan de zending) worden ook geaccepteerd. Deze worden aan de ontvangst toegevoegd met de actuele inkoopprijs.

Voorraad en validaties

• Voorraadeffect: Bij het aanmaken van de ontvangst worden direct de indicatoren ReceivingsPending en TotalReceivingsQuantity bijgewerkt.

• Foutmeldingen: Het systeem retourneert een HTTP 400 error indien de verkeerde parameters worden meegestuurd, de order niet bestaat (of rechten ontbreken), de status onjuist is, of als de leverancier deze actie blokkeert.

Systeeminstellingen en vereiste configuratie

• Leverancier: De optie AllowReceivingFromPurchaseOrder moet op leveranciersniveau geactiveerd zijn. Is dit niet het geval, dan weigert de API het verzoek.

• Distributie: De winkelinstelling RecFromPOCopyDistribution kan op True worden gezet. Hierdoor worden eventuele distributieregels van de inkooporder gekopieerd naar de ontvangst.

• Rechten: De gebruiker of API-koppeling heeft slechts de reguliere rechten nodig voor het aanmaken van ontvangsten; er is geen nieuw recht geïntroduceerd.

Buiten scope

• Dit betreft uitsluitend een API-toevoeging; er is niets gewijzigd aan de backoffice-schermen of het UI-proces.

• Het is niet mogelijk om zelf een ontvangstcode mee te geven (deze is altijd automatisch).

• De gecreëerde ontvangst wordt niet automatisch doorgeboekt of verwerkt, maar wordt in status Pending klaargezet.

• Het is niet mogelijk om meerdere inkooporders samen te voegen tot één ontvangst.

CN 76854

Uitbreiding zoekfunctionaliteit: Bovenliggende matrixartikelen in API-resultaten

Het endpoint POST products/Search is aangepast bij het gebruik van trefwoordzoeken. Wanneer er matrixvarianten worden gevonden, retourneert de API nu ook direct het bovenliggende matrixartikel. Hierdoor kan bijvoorbeeld de kassa in de zoekresultaten het hoofd-matrixartikel tonen met een keuzevenster voor de maat, in plaats van een lange lijst met losse varianten.

Toepassingsgebied en werking

• Zoekstroom: Deze wijziging geldt specifiek voor de full-text zoekstroom (wanneer forceFullTextSearch: true is meegegeven, of wanneer Elastic search niet is geconfigureerd). De Elastic-zoekstroom is niet gewijzigd.

• Datastructuur: Het gevonden matrixartikel wordt als een apart artikelrecord in de products[] array teruggegeven, en dus niet als een genest object onder de variant.

• Relatie: Er wordt uitsluitend gekeken naar de directe relatie MatrixProduct → Matrix. Een eventueel bovenliggend MatrixModel wordt niet toegevoegd.

Werking van het productTypes-filter

Het meegeven van producttype-filters heeft invloed op wat er precies wordt geretourneerd. Een variant die door een filter wordt uitgesloten, wordt op de achtergrond nog wel gebruikt om het bovenliggende matrixartikel te vinden.

Belangrijke wijzigingen voor API-gebruikers (Paginering en sortering)

• Paginering en limieten: Een geretourneerde pagina kan nu meer records bevatten dan de opgegeven limit. Het matrixartikel wordt namelijk als extra record boven op de opgevraagde paginalimiet toegevoegd. Dit voorkomt dat een opgevraagde variant van zijn eigen pagina wordt verdrongen door het toevoegen van zijn matrixartikel.

• Count: De count is hierdoor pagina-afhankelijk en wordt verhoogd met het aantal matrixartikelen dat aan de specifieke pagina is toegevoegd.

• Meerdere pagina's: Eén matrixartikel kan op meerdere pagina's terugkomen, als de bijbehorende varianten over meerdere pagina's zijn verspreid.

• Sortering en deduplicatie: Full-text resultaten bevatten geen relevantiescore en zijn standaard gesorteerd op artikel-ID. Dubbele rijen (bijvoorbeeld door meerdere trefwoordrecords per groep) worden automatisch gefilterd tot één uniek record in de response.

• Statusfilter: Het filter productStates wordt ook toegepast op het matrixartikel. Voldoet het matrixartikel niet aan de gevraagde statussen, dan wordt deze niet teruggegeven.

Opgeloste fouten (Bugfixes)

In deze release zijn ook twee gerelateerde problemen opgelost:

1. Uitsluiten producttypes in Elastic (79006): Het uitsluiten van een producttype (bijv. -Type) werkte niet in de Elastic-stroom en resulteerde onterecht in een leeg resultaat. Dit filter werkt nu correct. Als alle producttypes expliciet worden uitgesloten, retourneert de API nu direct een leeg resultaat zonder de zoekindex onnodig te bevragen.

2. Paginering in full-text search: Bij het pagineren van de full-text zoekopdracht kon hetzelfde artikel door het ontbreken van een vaste sortering op opeenvolgende pagina's terugkomen, terwijl andere artikelen werden overgeslagen. Er is nu een vaste sortering (op artikel-ID) toegevoegd, waardoor paginering elk gevonden artikel gegarandeerd correct en slechts één keer (mits geen matrixartikel verdeeld over meerdere pagina's) verwerkt.

CN 77692

Redencode (Reason Code) REST API en Database

De entiteit 'Redencode' is uitgebreid met drie nieuwe velden. Deze wijziging betreft uitsluitend de backend (database en endpoints) en heeft geen impact op de huidige gebruikersinterface of applicatie.

Nieuwe API-velden

De volgende velden zijn toegevoegd aan de GET, GET all, POST, PATCH, DELETE en Search endpoints:

• discountScope: Bepaalt of de korting geldt als bonkorting, regelkorting, of beide.

• discountType: Bepaalt het type korting (percentage, bedrag, of eindbedrag).

• discountValue: De kortingswaarde. Acceptabele waarden vallen tussen 0 en 1.000.000 (bij percentages is dit 0,00 tot 1,00).

Validatie en Bedrijfslogica

Voor het gebruik van deze velden zijn specifieke afhankelijkheden en regels geïmplementeerd in de API:

• Beperkt tot kortingstypen: De velden worden alleen opgeslagen voor redencodes met het type Discount of TotalDiscount. Bij een POST of PATCH met een ander type worden de velden genegeerd.

• Automatische opschoning: Als het type van een bestaande redencode wordt gewijzigd naar een niet-kortingstype, worden de nieuwe velden in de database automatisch leeggemaakt.

• Onderlinge afhankelijkheden:

  • discountType en discountValue moeten altijd samen worden ingevuld.

  • discountScope is verplicht zodra discountType of discountValue wordt meegegeven.

  • Als discountScope wordt leeggemaakt in een PATCH-verzoek, worden discountType en discountValue automatisch ook leeggemaakt.

CN 77693

Uitbreiding REST API: Aanpasbare aantallen en kortingen op ontvangstregels

Het is vanaf nu mogelijk om bestaande ontvangstregels via de API te corrigeren zolang de ontvangst nog openstaat (onverwerkt is). Voorheen moesten regels verwijderd en opnieuw ingevoerd worden om aantallen of prijzen te wijzigen.

Nieuwe PATCH-functionaliteit

Via het endpoint PATCH api/receiving-lines/{id} kunnen de velden ProductQuantity, DiscountPercentage, Factor en PurchasePrice worden gewijzigd.

• Volledige herberekening: Een wijziging activeert direct een herberekening van de regelwaarden (o.a. totalen en btw), de ontvangsttotalen, én de verwachte ontvangstvoorraad (receivingsPendingQuantity) op het product.

• Transactiebasis: De update wordt in één transactie uitgevoerd. Bij een fout of weigering blijven alle originele waarden en totalen intact.

• Velden leegmaken: Via de parameter additionalParameters.propertiesToClear kunnen optionele velden (zoals Remarks, BoxNumber of ScanLine) worden leeggemaakt.

Wijzigingen bij tellingsregels en weergave

• Reasoncodes: Bij POST en PATCH van tellingsregels (api/receiving-counting-lines) kan nu een ReasonCodeId (uitsluitend type ReceivingDifferences) worden meegegeven. Deze is ook opvraagbaar via expand-parameters.

• Nieuw veld: De GET-endpoints voor ontvangstregels retourneren nu het veld PurchasePriceNett (de inkoopprijs ná aftrek van het kortingspercentage).

Verbeterde rekenregels (van toepassing op PATCH én POST)

De rekenlogica voor het aanmaken (POST) en updaten (PATCH) van ontvangsten is gelijkgetrokken. Dit lost enkele inconsistenties op:

• Kortingen: Een kortingspercentage berekent nu correct het DiscountAmount en PurchasePriceNett. Bij een wijziging overschrijft een percentage altijd een eventueel ingesteld vast kortingsbedrag. Vaste kortingsbedragen schalen niet mee als het aantal op de regel wijzigt.

• Kitproducten: Onderliggende regels van kitproducten volgen nu exact het bestelde aantal (OrderedQuantity) van de bovenliggende regel. Dit voorkomt eerdere fouten waarbij kitcomponenten of statiegeld terugvielen op aantal 1 en totalen niet meer klopten.

• Negatieve aantallen: Retouren of correcties (negatieve aantallen) zijn toegestaan; bedragen en de verwachte voorraad bewegen dan logischerwijs in omgekeerde richting.

Validaties en limieten

Er zijn striktere bereikcontroles toegevoegd, welke ook gelden bij het aanmaken van nieuwe ontvangsten:

• ProductQuantity: tussen -1.000.000 en 1.000.000.

• Factor en PurchasePrice: van 0 tot 1.000.000.

• DiscountPercentage: van 0 tot 100.

• Ook afgeleide totalen (zoals OrderedQuantity en TotalExclTax) mogen de limiet van +/- 99.999.999.999 niet overschrijden. Waarden hierbuiten resulteren in een weigering (HTTP 400).

Aandachtspunten voor bestaande data

• Regels die in het verleden via de API zijn aangemaakt met een expliciet meegegeven, afwijkend totaalbedrag, zullen bij een PATCH-actie automatisch worden herberekend op basis van de actuele inkoopprijs en het bestelde aantal.

• Bedragen worden afgerond op 2 decimalen via bankiersafronding (met uitzondering van PurchasePriceNett, welke 4 decimalen hanteert). Oude regels met een lege DiscountAmount of onjuiste PurchasePriceNett worden bij de eerste de beste PATCH-actie automatisch gecorrigeerd.

CN 77430

Nieuw API-endpoint voor telverschillen bij ontvangsten

In de REST API is een nieuw endpoint toegevoegd: GET /api/receivings/{id}/differences. Hiermee kunnen de telverschillen van een specifieke ontvangst worden opgevraagd. De response retourneert één rij per product, met daarin een vergelijking tussen het ontvangen aantal en het getelde aantal.

Werking en filters

Standaard toont het endpoint uitsluitend producten die daadwerkelijk geteld zijn én waarbij een verschil is geconstateerd. Dit gedrag kan worden aangepast met de volgende queryparameters:

• includeNonCounted=true: Toont ook producten die op de ontvangst staan, maar nog niet geteld zijn (het verschil is hierbij gelijk aan de volledige ontvangen hoeveelheid).

• includeNoDifference=true: Toont ook producten waarbij de getelde hoeveelheid exact overeenkomt met de ontvangen hoeveelheid (geen verschil).

• openLinesOnly=true: Negeert telregels die reeds verwerkt zijn, zodat alleen openstaande regels overblijven.

Rechten en validatie

• Toegang: Dit endpoint vereist specifieke rechten en is beschikbaar voor de rollen Webshop, DataImporter en Administrator.

• Foutmeldingen: Als een opgevraagde ontvangst niet bestaat, of wel bestaat maar buiten het toegestane winkelbereik van de aanroepende gebruiker valt, retourneert de API een 404-foutmelding.

Parameters, paginering en sortering

De rekenlogica voor het aanmaken (POST) en updaten (PATCH) van ontvangsten is gelijkgetrokken. Dit lost enkele inconsistenties op:

• Ondersteunde parameters: Het endpoint ondersteunt veldselectie (fields), expands (expand=product, expand=reasonCode) en het ophalen van het totaalaantal (includeTotalCount).

• Paginering: Wordt ondersteund via offset en limit (standaard 10, maximaal 50, of maximaal 10.000 voor de Administrator-rol).

• Sortering: De resultaten worden altijd vast gesorteerd op product-id. De parameter orderBy wordt bij dit endpoint expliciet niet ondersteund.

• Redencodes: Indien er een redencode is ingesteld op de telregel van het product, wordt de ID hiervan geretourneerd in het veld reasonCodeId.

Deze uitbreiding betreft een nieuw endpoint en heeft geen impact op de werking van de reeds bestaande API-endpoints.

CN 77614

Uitbreiding endpoint voor verwerking van ontvangstverschillen (REST API)

In de REST services zijn aanpassingen doorgevoerd voor het bestaande endpoint POST /api/receivings/{id}/ProcessDifferences, waarmee verschillen bij een ontvangst (receiving) worden verwerkt.

Werking en impact

• Controle op winkelinstelling: Bij het aanroepen van het endpoint wordt vanaf nu actief gekeken naar de bestaande winkelinstelling ReceivingCheckReclamation van de vestiging waarop de ontvangst is aangemaakt.

• Directe verzending en API-response: Wanneer deze instelling op True staat én er daadwerkelijk verschillen in de ontvangst zijn geconstateerd, worden de bijbehorende (reclamatie)mails nu direct door het systeem verzonden. Daarnaast retourneert de API-response vanaf nu de gegenereerde mailIds, zodat de koppelpartij direct terugkoppeling heeft over de aangemaakte en verzonden e-mails.

Systeeminstellingen en vereiste configuratie

Om gebruik te maken van de directe mailverzending en de mailIds in de response, dient de winkelinstelling ReceivingCheckReclamation op True te staan. Voor API-ontwikkelaars betekent dit dat de API-response nu verrijkt is en indien gewenst uitgelezen kan worden.

CN 77884

API-uitbreiding: Distributieregels van een ontvangst opvragen

Distributieregels, die vastleggen hoe ontvangen aantallen uit een multistore-inkooporder over verschillende winkels worden verdeeld, zijn vanaf nu via de REST API op te vragen. Voorheen was deze informatie uitsluitend in de applicatie-interface zichtbaar. Deze uitbreiding is volledig additief en heeft geen invloed op de werking van bestaande endpoints zonder de nieuwe parameters.

Nieuwe Endpoints (Alleen-lezen)

Er zijn twee nieuwe endpoints toegevoegd. Deze zijn 'read-only'; het aanmaken, wijzigen of verwijderen (POST, PATCH, DELETE) verloopt uitsluitend via de levensloop van de ontvangst zelf.

• GET /api/receiving-distribution-records (Lijst van distributieregels)

• GET /api/receiving-distribution-records/{id} (Individuele distributieregel)

• Rechten: Voor toegang is het recht Receivings.Read vereist (beschikbaar voor de rollen Administrator, DataImporter en Webshop).

Nieuwe expands en datastructuur

• Velden: De response bevat gegevens zoals ID's, statussen, toegewezen winkel/magazijn, hoeveelheden (receivedQuantity, customerOrderQuantity, minimum/maximum) en percentages. Velden zoals productId en purchaseUnitFactor worden on-the-fly afgeleid.

• Uitbreiding bestaand endpoint: Aan het ontvangstregels-endpoint (ReceivingLine) is de expand distributionRecords toegevoegd. Geneste expands zijn mogelijk, bijvoorbeeld: GET /api/receiving-lines?expand=distributionRecords(store,stockInfo).

• Nieuwe expands: Binnen de distributieregels zelf kan genest worden met warehouse, store en stockInfo (voor de actuele voorraad van het product in de betreffende winkel/magazijn).

Nieuwe expands en datastructuur

• Verwijderde regels: Regels met de status Deleted worden standaard verborgen in de lijst en in expands. Om deze te zien, moet expliciet de queryparameter states=Deleted worden meegegeven. (Bij het opvragen van een verwijderde regel via het detail-endpoint wordt een 404 geretourneerd).

• Winkelfiltering: Resultaten worden gefilterd op basis van de winkel waaraan de regel is toegewezen, niet op basis van de ontvangst. Regels voor winkels buiten de ingestelde winkelstructuur van de gebruiker worden niet geretourneerd.

• Sortering: Er kan gesorteerd worden (orderBy) op state, storeId, warehouseId en productId. Let op: sorteren op status gebeurt alfabetisch op de omschrijving (Active < Deleted < Processed), niet op een logische volgorde.

• Parameters: Bij meervoudige queryparameters moeten de keys herhaald worden (bijv. ?states=Active&states=Processed). Komma-gescheiden waarden resulteren in een foutmelding (HTTP 400).

• Totaaltelling: De header X-Total-Count wordt alleen geretourneerd indien includeTotalCount=true is meegegeven in de aanroep.

Levensloop en opgeloste fouten (Bugfixes)

In deze release zijn ook twee gerelateerde problemen opgelost rondom de levensloop van distributieregels:

• Wanneer een ontvangstregel werd verwijderd, bleven de bijbehorende distributieregels onterecht actief op de achtergrond. Vanaf nu worden deze correct op Deleted gezet.

• Bij het aanmaken van een tellijstregel werd de koppeling naar de distributieregel (receivingCountingLineId) niet goed opgeslagen. Hierdoor werden regels bij het verwijderen van de tellijstregel niet opgeruimd. Dit is hersteld.

CN 77885

Nieuw filter 'sourceIds' voor klantorders in de REST API

Aan het bestaande endpoint GET /api/customer-orders in de REST services is een nieuw filter toegevoegd.

Werking en impact

• Gericht filteren: Met de toevoeging van de query-parameter sourceIds is het voor API-gebruikers en koppelpartijen nu mogelijk om klantorders gericht op te halen op basis van één of meerdere bron-ID's.

• Geen inrichting vereist: Deze wijziging betreft uitsluitend een backend-uitbreiding van de API-functionaliteit. Er is geen aanvullende configuratie of aanpassing in de instellingen nodig om dit filter te kunnen gebruiken.

CN 78893