VERSIE: 6.0.2026Paris

Verbeterpunten op diverse pagina’s van Backoffice NXT

Wat is opgeleverd?

Een verzameling verbeterpunten op de Backoffice NXT-pagina's en de bijbehorende API. Het gaat om strengere controles bij campagnes, drie schermcorrecties (Kleuren, Taken, Vervoerders), een templateveld dat de dialoog vult, en twee API-aanpassingen die de sortering van kleuren en het verwijderen van importmodi netter maken.

Hoe werkt het?

Bij een campagne is een vouchertype nu verplicht zodra "Voucher versturen" aanstaat, en het voucherbedrag is een bedragveld geworden in plaats van een vrij tekstveld — met twee decimalen en een maximum van 999.999. Aantal dagen voor/na kan niet meer negatief zijn.

Op het Kleuren-scherm valt het aanmaakvenster niet langer weg achter een uitgeklapte kleurenboom, de datums naast een taakomschrijving blijven op één regel staan, en het XML-veld bij een vervoerder én het templateveld vullen nu de hoogte van hun dialoog in plaats van een vast klein vak te blijven.

Waar in de software?

Backoffice: Campagnes, Kleuren, Taken, Vervoerders, Templates en Importmodi. Aan de API-kant:

campagnes, matrixkleuren (orderBy toegevoegd, standaardsortering teruggezet) en het verwijderen van tweefase-instelwaarden per importmodus, dat nu op code gaat in plaats van op een intern ID.

Instellingen/parameters?

Geen nieuwe store settings. De bestaande security doors blijven gelden: CAMPAIGNS, COLOURS, TASKS, IMPORTMODESMENU, CARRIERDEFINITIONSMENU / CARRIERDEFINITIONADDEDIT en TEMPLATES.

Niet inbegrepen?

Drie punten zijn onderweg bewust geaccepteerd in plaats van opgelost:

• Zoeken en sorteren op voucherbedrag is niet meer mogelijk. POST campaigns/Search geeft op dat veld een foutmelding. Dit komt uit een oudere implementatie en wordt als vervolgitem opgepakt.

• Een voucherbedrag dat als tekst met een komma wordt aangeleverd, wordt anders gelezen. Een externe client die "1,00" stuurt, krijgt 100 — de komma geldt als duizendtalscheiding. Besloten door diverse devs en productowners:

het veld wordt nauwelijks gebruikt en niet door externe clients, dus hier wordt geen uitzondering voor gebouwd. Bestaande databasewaarden worden apart omgezet.

• Enkele velden zijn niet meer leeg te maken via de generieke wis-functie: vouchertype, aangemaakt door, gewijzigd door, externe code en dagen voor/na. Dat zijn verplichte kolommen; leegmaken leverde voorheen een melding "gelukt" op terwijl er niets gebeurde. Een vouchertype verwijder je door het veld leeg te laten, niet door het te wissen.

Vereiste actie?

Geen actie voor gebruikers of beheerders.

Wel een aandachtspunt voor eventuele koppelingen: stuurt een externe partij het voucherbedrag als tekst, gebruik dan een punt als decimaalteken (1.00). Met een komma wordt het bedrag honderd keer zo groot.

CN 80012

Pinnen via CCV Cloud

Wat is opgeleverd?

De POS kan pinnen via CCV Cloud. De betaling loopt nu via de PaymentService, net als bij WorldLine Cloud en PayNL Cloud. De ingebouwde browser (Firefox) is uit de koppeling gehaald.

Hoe werkt het?

De kassamedewerker rekent af met Pin zoals gewoonlijk. De POS wacht op de uitkomst van de terminal en reageert zo:

• Goedgekeurd: de betaling wordt geboekt en de klantbon wordt geprint. Vraagt de terminal om een handtekening, dan wordt eerst de bon om te tekenen geprint.

• Retour op de pinpas: eerst de bon om te tekenen, dan de kopie voor de kaarthouder, dan de retourbon.

• Geweigerd: melding "Pinterminal: Transactie gefaald". Er wordt niets geboekt.

• Onzeker (CCV geeft geen antwoord, of de terminal vraagt handmatig ingrijpen): melding "Het is onzeker of de pinbetaling gelukt is. Controleer de pinterminal en boek de betaling niet nogmaals." Er wordt niets geboekt.

• Gedeeltelijk goedgekeurd: het goedgekeurde bedrag wordt als deelbetaling geboekt; de rest blijft openstaan.

Waar in de software?

POS (afrekenen en retour met pin), de PaymentService en de pinkoppeling (PinTerminals) voor CCV Cloud.

Instellingen/parameters?

• PaymentService: een betaalprovider CCVCloud met Endpoint, ApiKey en ManagementSystemId.

• Winkel: PaymentServiceEndpoint en PaymentServiceApiKey.

• Workstation: Gebruik pin aan, pintype CCVCloud, terminalcode = het terminal-ID van CCV.

• Retour op de pinpas: POSAllowRefundEFT.

• De POS leest de winkelgroep-instellingen CCVCloudendpoint, CCVCloudapikey en CCVCloudmanagementID niet meer, en ook niet de EFT-instellingen CCVBrowserLocation, CCVDeviceIp, CCVDevicePort en CCVReturnUrl.

Benodigde inrichting?

De waarden uit de winkelgroep-instellingen gaan over naar de PaymentService: CCVCloudendpoint wordt Endpoint, CCVCloudapikey wordt ApiKey, CCVCloudmanagementID wordt ManagementSystemId. Voorbeeld:

PaymentService (configuratie van de tenant), PaymentProviders:

Provider = CCVCloud Settings = { "Endpoint": "<endpoint van CCV Cloud>", "ApiKey": "<API-key van CCV>", "ManagementSystemId": "<management-ID van CCV>" } Winkel <winkel>:

PaymentServiceEndpoint = <URL van de PaymentService> PaymentServiceApiKey = <API-key van de PaymentService> Workstation <workstation>:

Gebruik pin = aan Pintype = CCVCloud Pin naam = <naam terminal> Terminalcode = <terminal-ID van CCV> ` CCV meldt de uitkomst van een betaling via een webhook. De ApplicationUrl van de PaymentService moet daarom vanaf internet bereikbaar zijn; anders toont de POS na de time-out "onzeker", ook als de klant wel betaald heeft.

Niet inbegrepen?

De SelfCheckOut en ASPOS Next zijn niet aangepast: de SCO pint via CCV Cloud nog steeds via Next en leest de winkelgroep-instellingen. Er zijn dus twee routes naar CCV Cloud.

Vereiste actie?

• Database-migratie van de PaymentService uitvoeren (nieuwe kolom Payments.MerchantReceipt).

• Voor elke POS-winkel op CCV Cloud de provider CCVCloud in de PaymentService inrichten. Zonder die inrichting kan de POS niet meer pinnen via CCV Cloud.

• De winkelgroep-instellingen voor CCV Cloud laten staan, de SCO gebruikt ze nog.

• Firefox en de Visual C++ Redistributable zijn niet meer nodig op de workstation voor CCV Cloud.

CN 74715

Koppeling met SOS vanuit de kassa

Integratie met SOS opgeleverd vanuit de ASPOS POS.

Wanneer er op de ASPOS POS een transactie wordt afgerond met "Reference: GUID" in de memo wordt het transactie resultaat opgestuurd naar SOS.

De functionaliteit wordt geactiveerd door het werkstation in te richten middels deze configuratie:

<GenericSettingHolder> <SettingObject xsi:type="SOSSettings"> <APIUrl></APIUrl> <APIKey></APIKey> </SettingObject> <SettingTypeName>SOSSettings</SettingTypeName> </GenericSettingHolder>

CN 79161

Verbeteringen in de Global Blue-koppeling

Wijziging doorgevoerd in de global blue koppeling op de POS zodat na het scannen een 2e scan direct mogelijk is (het inputfield wordt leeggehaald). Ook worden de totalen bij het scannen van meerdere bonnen goed weergegeven.

CN 79842

Voucher verzilveren bij afrekenen op kassa en zelfscan

Wijziging doorgevoerd zodat een voucher waarmee op de kassa of zelfscan wordt betaald, bij het afrekenen zelf wordt verzilverd: het saldo wordt met het betaalde bedrag verlaagd, en de afwaardering wordt geboekt op de winkel waar de verkoop plaatsvindt in plaats van op het hoofdkantoor en is terug te vinden bij de bijbehorende bon. Voorheen werd het vouchernummer alleen als tekst bij de betaling bewaard, waardoor het saldo bleef staan en dezelfde voucher opnieuw gebruikt kon worden. Is de voucher onbekend, nog niet actief, verlopen, al verzilverd of heeft hij te weinig saldo, dan wordt de verkoop geweigerd en is er geen bon aangemaakt. Kassasystemen die deze verzilvering niet aanvragen, werken ongewijzigd.

CN 80571

Retourneren van DirectSales-orders op pakbon- of ordernummer

Pakbonnen die zijn aangemaakt vanuit een DirectSales-klantorder zijn nu te vinden via Transacties zoeken in de kassa, zodat de artikelen op basis van de pakbon geretourneerd kunnen worden. Zoeken kan op pakbonnummer, klantordernummer of klantreferentie, net als bij andere pakbonnen. Dit werkt wanneer de winkelinstelling POSAllowReturnOnDelv aan staat.

Bij het omzetten van een DirectSales-order naar een pakbon ontstaan twee pakbonnen: de pakbon zelf en een tegenboeking. Alleen de pakbon zelf verschijnt in de zoekresultaten; de tegenboeking niet, omdat die nooit geretourneerd wordt. Het omzetten naar een pakbon verandert verder niets aan voorraad of voorraadwaarde.

Dit geldt alleen voor pakbonnen die na deze wijziging worden aangemaakt. Bestaande DirectSales-pakbonnen worden niet bijgewerkt en blijven onvindbaar in de zoekfunctie.

CN 80934

Rapportages

Logo dat niet kan worden opgehaald wordt weggelaten op factuur en pakbon

Wijziging doorgevoerd zodat een logo of afbeelding die de rapportserver niet kan ophalen wordt weggelaten, in plaats van dat er een foutmelding in de factuur of pakbon wordt afgedrukt.

CN 80983

Producten

Ontvangsten: ontvangstcontrole

Wat is opgeleverd?

De Ontvangstcontrole is opnieuw gebouwd in de Backoffice NXT. Een magazijnmedewerker telt hiermee de goederen van één nog niet verwerkte ontvangst: scannen of intypen van productcodes, geteld aantal en verschil per regel, min/max aanpassen, een nieuwe verkoopprijs vastleggen, prijslabels aanmaken en aan het eind de verschillen en/of de ontvangst verwerken.

Hoe werkt het?

Het scherm opent als venster boven het Ontvangsten-overzicht. In het scanpaneel voer je een scancode of productcode in met een aantal en bevestig je met Controleren; de geteld- en verschilkolommen en de tellers bovenin lopen direct mee. Min, Max en Geteld zijn per regel in te vullen en worden meteen opgeslagen; via de prijskolom leg je een nieuwe verkoopprijs vast. Met de knop Verwerken doorloop je — afhankelijk van de winkelinstellingen — het aanmaken van prijslabels en het verwerken van de verschillen en/of de ontvangst.

Waar in de software?

Ontvangsten → selecteer precies één ontvangst → Opties → Ontvangstcontrole.

Instellingen/parameters?

• Rechten: RECEIVINGVIEW (scherm alleen-lezen openen), RECEIVINGEDIT (tellen en verwerken), REVEIVINGCHECKADJUSTMINMAX (min/max aanpassen), RECEIVINGSPROCESS (verschillen/ontvangst verwerken), RECEIVINGSCHECKLOG (loggen van onbekende scancodes).

• Winkelinstellingen: RecAskPrintLabelMessage (vraagt om prijslabels), ReceivingsAskAutoProcess (vraagt om verwerken) en BackofficeMaxQuantity (maximum aantal per invoer).

Benodigde inrichting?

Voor het aanmaken van prijslabels moeten labeltypes én labelsjablonen ingericht zijn: in de dialoog kies je beide, en de sjabloonlijst toont alleen sjablonen die bij het gekozen labeltype horen.

Niet inbegrepen?

• Directe afdruk (ja/nee) in de prijslabel-dialoog. De Next API biedt op dit moment geen endpoint waarmee de Backoffice de beschikbare printers kan ophalen, terwijl afdrukken een printer vereist. De regel is daarom voorlopig uit de dialoog gehaald; labels worden wel aangemaakt en kunnen later worden afgedrukt.

• Winkeldistributie op de controleregels — de knop is zichtbaar bij distributieontvangsten maar nog niet actief; dit volgt in een apart werkitem.

• Multi-Check (meerdere ontvangsten tegelijk controleren) valt buiten dit werkitem.

Vereiste actie?

Controleer per winkel de instellingen RecAskPrintLabelMessage, ReceivingsAskAutoProcess en BackofficeMaxQuantity, en ken de benodigde rechten toe aan de gebruikers die de ontvangstcontrole moeten kunnen uitvoeren. Instellingen en rechten worden bij het inloggen gelezen: na een wijziging moet de gebruiker opnieuw inloggen.

CN 77901

Gericht teladvies op basis van een productselectie

Wat is opgeleverd?

Een gericht teladvies kan nu worden aangemaakt op basis van een vooraf bepaalde productselectie: in Backoffice Next door een barcodebestand te uploaden, en via de API door een lijst met productId's mee te geven. In plaats van de telling te laten samenstellen op basis van filters, bepaalt de gebruiker zelf welke producten geteld moeten worden. Dit ondersteunt situaties zoals telecom-planogrammen en producten met een negatieve voorraad.

Hoe werkt het?

Backoffice Next. Kies in de telwizard het tellingstype teladvies. In de stap Parameters verschijnt het blok Productselectie via barcodebestand, waar een .txt- of .csv-bestand kan worden geselecteerd met één barcode per regel of komma-gescheiden. Na het selecteren toont het scherm hoeveel producten zijn gevonden en hoeveel barcodes niet konden worden herleid. Zodra er een selectie is, vervalt het veld Aantal producten: het bestand bepaalt dan de omvang van de telling.

De volgorde van de barcodes in het bestand, respectievelijk van de productId's in de lijst, is de telvolgorde.

Waar in de software?

• Backoffice Next, Tellingen → Toevoegen → tellingstype teladvies → stap Parameters.

• De API, bij het aanmaken van een telling.

• Telcycli: daar is de productselectie niet toegestaan.

Instellingen/parameters?

• De selectie is uitsluitend beschikbaar bij het tellingstype teladvies. Kiest men in de wizard een ander tellingstype, dan verdwijnt het blok en vervalt de selectie; via de API wordt de lijst geweigerd.

• Maximaal 500 producten per telling.

• De bestaande instelling Alleen getelde voorraad blijft bepalen of producten die niet geteld zijn op 0 worden gezet. Dit is een keuze van degene die de telling aanmaakt en verandert niet door deze oplevering.

• Rechten: het aanmaken van een telling vereist zoals voorheen het recht om tellingen toe te voegen.

• Het wijzigen van de vestiging in de wizard wist een gemaakte selectie, omdat barcodes per vestiging worden herleid.

Benodigde inrichting?

Geen inrichting vooraf. Let er wel op dat een aangeboden product alleen in de telling terechtkomt wanneer het aan de gebruikelijke voorwaarden voor een teladvies voldoet — onder andere een voorraadpositie in het telmagazijn en een ingestelde minimum- of maximumvoorraad. Producten die daar niet aan voldoen worden niet stilzwijgend overgeslagen, maar met reden getoond: in Backoffice Next in het resultaatscherm, via de API in de uitvallijst op de telling.

Grenzen van het barcodebestand: maximaal 1 MB en maximaal 2.000 barcodes. Dezelfde barcode meerdere keren opnemen, of meerdere barcodes van hetzelfde product, levert dat product één keer op.

Niet inbegrepen?

• In Backoffice Next werkt de selectie op barcodes; productnummers worden niet herkend.

• Andere tellingstypen dan teladvies kennen geen productselectie, en telcycli ondersteunen deze niet.

• Er wordt geen voorbeeldbestand of sjabloon meegeleverd; een kale tekst- of csv-regel per barcode volstaat.

CN 78208

Niet-leverbare producten uit het besteladvies houden

Wat is opgeleverd?

Met de nieuwe winkelinstelling *Besteladvies alleen leverbare producten* (PAProdOnlyDeliverable) worden producten die bij de geselecteerde leverancier niet leverbaar zijn, niet meer meegenomen bij het verwerken van een besteladvies. De gebruiker krijgt een melding met de producten die zijn overgeslagen.

Hoe werkt het?

Bij het verwerken van besteladviesregels controleert ASPOS per regel de leverbaarheid bij de leverancier *van die regel*. Een regel wordt overgeslagen wanneer bij die product-leveranciercombinatie het vinkje *Is leverbaar* uit staat, of wanneer de *Leverstatus* op *Niet leverbaar* of *Tijdel. niet verkrijgbaar* staat. De overgeslagen regels komen niet op de inkooporder en blijven openstaan in het besteladvies, zodat ze later alsnog verwerkt kunnen worden.

De overige geselecteerde regels worden gewoon besteld. Na het verwerken verschijnt de melding "De volgende producten zijn niet verwerkt omdat ze niet leverbaar zijn bij de geselecteerde leverancier", gevolgd door de betreffende producten.

Is een product aan meerdere leveranciers gekoppeld, dan telt alleen de leverancier waarvoor de adviesregel is aangemaakt. Dat een andere leverancier het product wél kan leveren, maakt voor die regel niets uit.

Waar in de software?

• Backoffice, *Inkoop > Besteladvies*: het verwerken van de geselecteerde adviesregels en de melding die daarop volgt.

• Backoffice, *Artikelen*: het tabblad met de leveranciers van een product, waar *Is leverbaar* en *Leverstatus* per leverancier worden vastgelegd.

Instellingen/parameters?

Nieuwe instelling PAProdOnlyDeliverable, prompt *Besteladvies alleen leverbare producten*, groep *Algemeen*, type Ja/Nee met standaardwaarde Nee. De instelling is per winkel te overschrijven. Het is de tegenhanger van de bestaande instelling POProdOnlyDeliverable, die hetzelfde doet voor inkooporders.

Benodigde inrichting?

Zet de instelling aan voor de winkels of winkelgroep waar de controle moet gelden. Verder is het van belang dat *Is leverbaar* en *Leverstatus* per product-leveranciercombinatie juist zijn vastgelegd, want die twee velden bepalen de uitkomst.

Niet inbegrepen?

De controle grijpt aan op het moment van verwerken, niet bij het genereren van het advies of bij het handmatig toevoegen van een regel: een niet-leverbaar product komt dus nog wel op het advies te staan en wordt pas bij het verwerken geweigerd. De status van het artikel zelf (actief of inactief) weegt bewust niet mee — een uitgefaseerd artikel dat de leverancier nog kan leveren, blijft bestelbaar. De werking van POProdOnlyDeliverable voor inkooporders is ongewijzigd.

Vereiste actie?

Geen. De instelling staat standaard op Nee, waardoor het gedrag voor bestaande winkels hetzelfde blijft. Alleen winkels die niet-leverbare producten willen blokkeren, zetten de instelling aan.

CN 79163

Niet-leverbare producten overslaan bij verwerken van inkooporders

Wat is opgeleverd?

Bij het verwerken van inkooporders kunnen regels waarvan het product niet leverbaar is bij de leverancier worden overgeslagen. De overige regels worden gewoon verwerkt, en de gebruiker ziet na afloop welke regels niet zijn verwerkt en waarom. Dit wordt aangestuurd door de nieuwe winkelinstelling POProcessOnlyDeliverable.

Hoe werkt het?

Bij Verwerken controleert het systeem per orderregel of het product leverbaar is bij de leverancier van de order. Een product geldt als niet leverbaar wanneer het bij die leverancier niet als leverbaar is gemarkeerd, of wanneer de status End of life of Suspended is. Die regels blijven openstaan; de rest van de order wordt normaal besteld. Eén niet-leverbaar product laat dus nooit de hele order mislukken.

Na het verwerken toont het resultaatvenster welke regels zijn overgeslagen. Bij meerdere overgeslagen regels worden ze alle genoemd, en bij het verwerken van meerdere orders tegelijk wordt dit per order gemeld.

Waar in de software?

Inkooporders → selecteer één of meer orders → Verwerken.

Instellingen/parameters?

Winkelinstelling POProcessOnlyDeliverable (per winkel). Standaardwaarde False: het gedrag blijft dan ongewijzigd en alle regels worden verwerkt, ook niet-leverbare. Op True worden niet-leverbare regels overgeslagen en gemeld.

Voor het verwerken zelf is het recht PURCHASEORDERSPROCESS nodig. De instelling wordt bij het inloggen gelezen: na een wijziging moet de gebruiker opnieuw inloggen.

Benodigde inrichting?

De leverbaarheid komt uit de koppeling tussen product en leverancier: het kenmerk "leverbaar" en de status van die koppeling (End of life, Suspended). Controleer deze gegevens bij de leveranciers waarvoor de instelling wordt aangezet, want ze bepalen welke regels worden overgeslagen.

Niet inbegrepen?

Wanneer alle regels van een order niet leverbaar zijn, krijgt de order toch de status Besteld terwijl er in werkelijkheid niets is besteld. Dit gedrag bestond ook vóór deze wijziging, maar was toen niet zichtbaar omdat er geen melding werd getoond. Het is als apart werkitem opgepakt.

Vereiste actie?

Zet POProcessOnlyDeliverable op True bij de winkels waar niet-leverbare regels moeten worden overgeslagen, en laat de betrokken gebruikers opnieuw inloggen. Gebeurt dit niet, dan blijft het bestaande gedrag ongewijzigd.

CN 79164

Ontvangsten: ontvangstregels importeren uit Excel

Wat is opgeleverd?

Een ontvangst kan nu gevuld worden vanuit een Excel-bestand, in plaats van elke regel met de hand toe te voegen. Handig bij leveranciers die een digitale pakbon aanleveren. Anders dan in de oude Backoffice laat één foute rij de import niet meer mislukken, is er een sjabloon om mee te beginnen, en kunnen de bestaande regels eerst worden verwijderd.

Hoe werkt het?

Kies een .xlsx-bestand (maximaal 500 regels en 10 MB) en klik op Importeren. Het venster toont welke kolommen er zijn en welke verplicht zijn; via Sjabloon downloaden krijgt u een leeg bestand met precies die kolommen.

Een product wordt gezocht op productnummer en anders op scancode; zijn beide gevuld, dan is het productnummer leidend. Laat u inkoopprijs of korting leeg, dan komt de standaardwaarde uit het leveranciersassortiment.

Rijen die niet geïmporteerd kunnen worden, worden overgeslagen; de rest wordt gewoon toegevoegd. Na afloop toont het importresultaat per overgeslagen rij het rijnummer, de waarden uit het bestand en de reden. Verbeter die rijen en importeer hetzelfde bestand opnieuw: rijen die al zijn toegevoegd worden dan als "al toegevoegd" overgeslagen, zodat niets dubbel komt.

Met de schakelaar Verwijder bestaande regels aan worden alle huidige regels eerst verwijderd, zodat de ontvangst alleen de regels uit het bestand bevat. Een ongeldig bestand (verkeerd type, te groot, leeg of meer dan 500 regels) wordt vooraf geweigerd, en mislukt het opslaan, dan wordt er niets geïmporteerd.

Waar in de software?

Ontvangsten → open een ontvangst → regelgrid → pijltje naast Toevoegen → Importeren. De actie is alleen beschikbaar zolang de ontvangst nog gewijzigd mag worden: niet na verwerken, niet tijdens een telling en niet wanneer de ontvangst in een lopende multi-ontvangstcontrole zit.

Instellingen/parameters?

Nieuw recht RECEIVINGSIMPORT ("Ontvangsten importeren"); zonder dit recht is de actie niet zichtbaar. Voor een ontvangst met controletype Nooit is daarnaast ALLOWEDITRECEIVINGCHECKTYPENOOIT nodig. Er zijn geen winkelinstellingen voor deze functie.

Benodigde inrichting?

De producten moeten in het assortiment van de leverancier van de ontvangst staan, met een bestelcode (of de bestelcode staat in het bestand). Gebruik het sjabloon uit het importvenster als uitgangspunt.

Niet inbegrepen?

Een inkoopordernummer dat niet bestaat wordt niet gemeld: de regel wordt geïmporteerd, maar zonder koppeling aan een inkooporder (gelijk aan de oude Backoffice). Matrixmodellen kunnen niet worden geïmporteerd.

Vereiste actie?

Ken het recht RECEIVINGSIMPORT toe aan de gebruikersgroepen die ontvangstregels mogen importeren.

CN 79365

Categoriegroepen in Backoffice NXT

Het scherm Categoriegroepen is nu beschikbaar in de Backoffice NXT. Categoriegroepen worden getoond als boomstructuur die op status kan worden gefilterd; door te slepen kan een groep binnen dezelfde bovenliggende groep van volgorde veranderen of onder een andere groep worden gehangen. In het bewerkvenster worden code, omschrijving (met vertalingen), status, marge en de vier grootboekrekeningen onderhouden. Een groep die nog onderliggende groepen heeft kan niet worden verwijderd. Voor koppelingen is het endpoint POST /api/category-groups/{id}/Move beschikbaar om een categoriegroep te verplaatsen of van volgorde te veranderen; een nieuw aangemaakte categoriegroep krijgt via de API nu automatisch de laatste positie onder zijn bovenliggende groep.

CN 79541

Segmenten in Backoffice NXT

Wat is opgeleverd?

De pagina Segmenten is opnieuw gebouwd in de Backoffice NXT en vervangt de oude pagina, met dezelfde mogelijkheden: segmenten zoeken, toevoegen, wijzigen, verwijderen en aan vestigingen koppelen. Nieuw zijn een tabblad Dashboard, filteren op vestiging en meerdere segmenten tegelijk verwijderen. Daarnaast is de API voor segmenten uitgebreid, zodat zoeken en het beheren van de gekoppelde vestigingen ook via de API kunnen.

Hoe werkt het?

De lijst toont omschrijving en code; zoeken kan op beide, sorteren per kolom en filteren op vestiging. Een segment open je in een venster met de tabbladen Algemeen (omschrijving en code, beide verplicht, maximaal 25 tekens en uniek) en Vestigingen (de vestigingen die het segment gebruiken, aan te vinken in de boom).

• Een segment dat nog aan een vestiging of een product gekoppeld is, kan niet verwijderd worden; je krijgt daarvan een melding.

• Het standaardsegment regulier heeft een vaste omschrijving en code en kan niet verwijderd worden; de vestigingen ervan kun je wel aanpassen.

• Segmenten worden alleen vanuit het hoofdkantoor onderhouden; vanuit een andere vestiging is de lijst alleen in te zien.

• Wijzig je alleen het tabblad Vestigingen en sluit je zonder Opslaan, dan wordt dat niet bewaard en volgt er geen waarschuwing. Bij wijzigingen op Algemeen vraagt het venster wel om bevestiging.

• Wordt een vestiging van een segment ontkoppeld, dan ziet die vestiging de producten van dat segment direct niet meer.

Waar in de software?

• Backoffice: Instellingen → Segmenten.

• API: product-segments (nieuw: POST product-segments/Search, POST product-segments/{id}/UpdateStores, en de velden creationDate / lastModifiedDate), product-segments-stores (nieuw filter productSegmentIds) en products (productSegments via PATCH, POST products/{id}/UpdateSegment).

Instellingen/parameters?

Beveiligingsingangen: Segmenten (pagina), Segment inzien, Segmenten toevoegen, Segmenten wijzigen en Segment verwijderen. Toevoegen en wijzigen zijn losse rechten: met alleen Segmenten toevoegen kun je een nieuw segment opslaan, maar geen bestaand segment wijzigen. Via de API is zoeken alleen beschikbaar voor Administrator-koppelingen.

Benodigde inrichting?

Geen.

Niet inbegrepen?

• Spaties aan het begin of eind van een code of omschrijving worden niet weggehaald: " A1 " en "A1" gelden als verschillende waarden. Een code of omschrijving van alleen spaties wordt wel geweigerd. Dit is bewust zo besloten door diverse devs en productowners: de API past ingevoerde waarden nergens aan.

• Zoeken via de API op een veld dat niet doorzoekbaar is, geeft foutcode 500 in plaats van 400. Dit is het bestaande gedrag van alle zoek-endpoints en is bewust niet gewijzigd.

• Een koppeling met een inactieve vestiging vervalt zodra de vestigingen van een segment opnieuw worden opgeslagen. Wordt die vestiging later weer actief, koppel het segment dan opnieuw.

Vereiste actie?

Geen. Controleer wel of beveiligingsgroepen die het oude recht Segmenten toevoegen/wijzigen (oud) hadden, nu Segmenten toevoegen en/of Segmenten wijzigen hebben.

Voor API-koppelingen:

• PATCH products/{id} met productSegments vervangt alle segmenten van het product; een lege lijst wordt geweigerd.

• POST products/{id}/UpdateSegment op een product dat de vestiging niet kan zien, geeft nu 404 (was 400).

• creationDate en lastModifiedDate meesturen bij aanmaken of wijzigen van een segment wordt geweigerd (400).

• De validatiemeldingen voor code en omschrijving zijn gewijzigd (bijvoorbeeld "Must be between 1 and 25 characters" en "Code must not be empty").

CN 79662

Retourorder op inkooporders

Wat is opgeleverd?

Een inkooporder kan als retourorder gemarkeerd worden. Op een retourorder zijn alle orderregels negatief; bij het aan- of uitzetten van de markering worden de bestaande regels automatisch omgeklapt en worden de bedragen en ordertotalen opnieuw berekend.

Hoe werkt het?

Zet je 'Retourorder' aan, dan worden alle openstaande regels negatief: aantal, voorraadaantal, kortingsbedrag, totaal excl. btw, btw-bedrag en totaal incl. btw, inclusief de ordertotalen. De stukprijs en de prijs na korting blijven ongewijzigd, en de verwachte inkoopaantallen bij het product bewegen mee. Uitzetten klapt alles terug naar positief en wist de vastgelegde retourreden.

Nieuwe of gewijzigde regels op een retourorder moeten een negatief aantal hebben; een positief aantal wordt per regel afgekeurd met een duidelijke melding. De markering kan niet meer gewijzigd worden zodra de order verwerkt of geannuleerd is, of zodra een regel ontvangen of verwerkt is of nog openstaande distributieregels heeft — het scherm kan vooraf opvragen of wijzigen nog is toegestaan.

Waar in de software?

Inkooporders: het aanmaken en wijzigen van een inkooporder en van inkooporderregels (los en in bulk), plus het opvragen van de toegestane handelingen op een order. In het scherm: tabblad Extra, vinkje Retourorder.

Instellingen/parameters?

Geen store settings. Het veld retourreden mag alleen gevuld worden als de order een retourorder is; er wordt een redencode van het type PurchaseOrderReturns verwacht.

Benodigde inrichting?

Alleen wanneer je met retourredenen wilt werken: richt daarvoor redencodes van het type PurchaseOrderReturns in. Zonder die inrichting werkt de retourorder zelf gewoon, alleen zonder reden.

Niet inbegrepen?

Negatieve aantallen op een gewone inkooporder blijven toegestaan; alleen de regel "retourorder ⇒ regels negatief" wordt afgedwongen. Al ontvangen of verwerkte regels worden niet omgeklapt — op zulke orders is de markering sowieso niet meer te wijzigen.

Vereiste actie?

Geen, behalve de inrichting uit punt 5 als je retourredenen wilt gebruiken.

CN 80058

Setgroepen in Backoffice NXT

Het scherm Setgroepen is nu beschikbaar in de Backoffice NXT en vervangt de aparte overzichts- en detailpagina door één scherm. De lijst kan worden doorzocht op omschrijving, gefilterd en op elke kolom gesorteerd, en onthoudt kolomindeling en filters; met een directe link kan één setgroep worden geopend. In het bewerkvenster worden omschrijving en memo (vertaalbaar bij meertaligheid), minimum, maximum en zichtbaarheid onderhouden, met de tabbladen Regels en Gekoppelde producten. Regels worden in een eigen venster bewerkt, met afwijkende kost- en verkoopprijs, waarbij de verkoopprijs exclusief btw automatisch wordt berekend; regels verwijderen en producten ontkoppelen gebeurt direct na bevestiging. Een setgroep met regels kan nu worden verwijderd (de regels gaan mee), zolang geen product de setgroep gebruikt, en bij het verwijderen van meerdere setgroepen wordt per setgroep gemeld of dit is gelukt. Een setgroep van een bovenliggende winkel is alleen-lezen; op de regels kan dan een lokale afwijking worden vastgelegd. Via de API kunnen setgroepen nu worden gezocht met POST /api/kit-groups/Search.

CN 80506

Prijswijzigingen per product in Backoffice NXT

Het overzicht Prijswijzigingen per product is nu beschikbaar in de Backoffice NXT en vervangt de oude pagina; het menu-item verwijst voortaan naar het nieuwe scherm. In het overzicht staan per prijsregel onder meer de start- en einddatum, het product met productgroep en subgroep, de prijs, het prijstype, korting, prijslijst, leverancier en status. Er kan worden gezocht en gefilterd op startdatum (standaard vandaag tot en met 60 dagen vooruit), status, prijstype, product, leverancier en, bij meerdere winkels, per winkel. Door op een regel te klikken opent een detailvenster met alle prijzen incl. en excl. btw, inkoopprijzen en -kortingen en de verwerkingsstatus. Het scherm is alleen-lezen en heeft ook een dashboard-tab met widgets. Via de API kunnen prijswijzigingen nu worden doorzocht met POST /api/product-pricings/Search, en de antwoorden bevatten nu ook de omschrijving van prijstype en status, de prijslijst en de aanmaakdatum.

CN 80521

Voorraadmutaties in Backoffice NXT

Wat is opgeleverd?

De pagina Voorraadmutaties is beschikbaar in de Backoffice NXT. Die vervangt zowel het oude voorraadmutatie-overzicht als de losse detailpagina daarachter. Gebruikers zoeken hier de voorraadmutaties van hun vestigingen op, bekijken de regels van een mutatie, boeken een selectie tegen en openen het voorraadmutatie-rapport.

Hoe werkt het?

Bij het openen toont de lijst de mutaties van de eigen vestiging van de afgelopen zeven dagen, nieuwste bovenaan. Via het filtermenu is de periode, het soort mutatie en één of meer vestigingen aan te passen; het zoekveld zoekt op omschrijving én document. Klikken op een mutatie opent een alleen-lezen venster met de kopgegevens en de bijbehorende regels, met een eigen link die te delen of te bewaren is.

Er zijn drie verschillen met de oude pagina die opvallen. Het zoekveld vindt nu tekst ergens in de omschrijving of het document, waar de oude pagina alleen op het begin zocht. Het btw-percentage in de regels wordt als percentage getoond in plaats van als bedrag. En een tegenboeking slaat mutaties over die nog niet verwerkt zijn — die werden voorheen ook omgekeerd, waardoor voorraad werd teruggeboekt die nooit geboekt was. Na afloop meldt de pagina hoeveel mutaties zijn tegengeboekt en hoeveel zijn overgeslagen.

Naast het overzicht is er een dashboardtabblad met een tabel- en een telwidget, net als op de andere pagina's van de Backoffice NXT.

Waar in de software?

Backoffice, menu-item Voorraadmutaties onder de productadministratie. Dat menu-item opent nu de nieuwe pagina in plaats van de oude.

Instellingen/parameters?

Geen winkelinstellingen — deze pagina hangt van geen enkele store setting af.

Wel van zes rechten:

• Tonen voorraadmutatie tabel: De pagina en het menu-item

• Voorraadmutatie inzien: Het detailvenster

• Voorraadmutatie wijzigen: Het detailvenster (alternatief voor "inzien")

• Voorraadmutatie tegenboeking maken: Tegenboeken, samen met "toevoegen"

• Voorraadmutatie toevoegen: Tegenboeken, samen met "tegenboeking maken"

• Rapport Voorraadmutatie: Het rapport Het oude gecombineerde recht "Voorraadmutatie toevoegen/wijzigen" is gesplitst in toevoegen en wijzigen. Bestaande toekenningen zijn bij de splitsing naar allebei overgezet. Tegenboeken vraagt nu om het recht *toevoegen* in plaats van het oude gecombineerde recht, omdat een tegenboeking een nieuwe mutatie aanmaakt.

Een actie waarvoor het recht ontbreekt wordt niet getoond. Is het recht er wel maar is er niets geselecteerd, dan staat de actie er grijs bij met een uitleg.

Benodigde inrichting?

Het rapport Stockmutations moet in de rapportgenerator geregistreerd staan, anders werkt de rapportknop niet.

Verder is het verstandig om na de splitsing van het oude recht per beveiligingsgroep te controleren of de toekenningen nog kloppen — vooral of groepen die alléén mochten inzien niet ongewild ook "toevoegen" hebben gekregen en daarmee kunnen tegenboeken.

Niet inbegrepen?

Voorraadmutaties toevoegen, wijzigen of verwijderen kan niet op deze pagina. De oude pagina bood die knoppen wel, maar ze werkten daar niet. Het optiemenu van de oude pagina is niet overgenomen, en er zijn geen filters op Verwerkt en Geëxporteerd — die stonden ook niet in het oude scherm. Een mutatie en zijn tegenboeking worden niet aan elkaar gekoppeld, dus dezelfde mutatie kan meerdere keren worden tegengeboekt.

Vereiste actie?

Controleer de rechtentoekenning van de beveiligingsgroepen, zie punt 4 en 5. Verder geen actie.

CN 80527

Ontvangsten: tabblad Klantorders

Wat is opgeleverd?

Het tabblad Klantorders in het ontvangstdetailscherm is gevuld. Bij een verwerkte ontvangst is nu direct te zien welke klantorders ermee zijn bediend: welk artikel naar welke klant ging, in welke doos het binnenkwam en hoe die klant wordt geïnformeerd. De vraag "is het artikel van deze klant binnen, en in welke doos zit het?" is daarmee te beantwoorden zonder de ontvangst te verlaten.

Hoe werkt het?

De lijst toont één regel per toewijzing: de combinatie van een ontvangstregel en een klantorderregel.

Een klantorderregel die uit twee ontvangstregels of twee dozen is geleverd, staat dus twee keer, elk met een eigen aantal en doosnummer. Het getoonde aantal is wat bij het verwerken aan die klant is toegewezen — niet het bestelde aantal en niet het totaal van de ontvangstregel.

De kolommen zijn: Productcode, Omschrijving, Aantal, Doos, Klantcode, Klantnaam, Mobiel, E-mail, Berichttype, KlantorderNr, Klantorderdatum en KLB-labelbarcode. Er kan op elke kolom worden gesorteerd en de lijst is gepagineerd. Er is geen totaalregel: de aantallen horen bij verschillende artikelen. Het e-mailadres is een link die de mailclient opent.

Waar in de software?

Ontvangsten → een ontvangst openen → tabblad Klantorders, tussen Verschillen en Levering.

Het tabblad verschijnt uitsluitend bij een verwerkte ontvangst. Bij een nog niet verwerkte ontvangst is het tabblad niet aanwezig: de koppeling tussen ontvangen goederen en klantorders ontstaat pas tijdens het verwerken.

Instellingen/parameters?

Het tabblad heeft geen eigen recht en volgt de rechten van het ontvangstdetail (RECEIVINGS en RECEIVINGVIEW). Wie de ontvangst mag openen, ziet het tabblad.

Drie store settings bepalen wat er in de lijst komt:

• ReceivingNoCustOrderCheck: Er wordt niets toegewezen, dus het tabblad is bij elke ontvangst leeg

• ReceivingCustOrderReq: Alleen klantorderregels die aan de inkooporder gekoppeld zijn, worden getoond

• RecSkipOpenPickingLines: Klantorderregels met een openstaande pickregel worden overgeslagen

Benodigde inrichting?

Geen. De regels ontstaan automatisch bij het verwerken van de ontvangst.

Niet inbegrepen?

• Geen acties op het tabblad. De klantorder openen, het klantlabel opnieuw afdrukken of de klantnotificatie opnieuw versturen kan hier niet; het tabblad is puur een weergave van wat het verwerken al heeft bepaald.

• Filteren is niet mogelijk, sorteren wel. Dat is gelijk aan de oude pagina.

• Het klantorder-icoon op het ontvangstenoverzicht is niet aangepast. Dat icoon komt van de inkooporder achter de ontvangst, niet van de toewijzing. Een ontvangst kan dus het icoon tonen terwijl het tabblad leeg is.

Een leeg tabblad bij een verwerkte ontvangst is overigens normaal — bijvoorbeeld bij retouren, bij reclamaties, of wanneer een filiaal helemaal niet aan klantorders toewijst. Er verschijnt dan de gewone lege-lijstmelding en geen foutmelding.

CN 80587

Gebruikers

Beveiligingsingangen in Backoffice NXT

Wijziging doorgevoerd zodat beveiligingsingangen voortaan in de Backoffice NXT te raadplegen zijn, met zoeken op omschrijving, filteren op groep, type en status, sorteerbare kolommen en paginering. De kolom Code is nieuw ten opzichte van de oude pagina. Daarnaast is het sorteren op Code hersteld, en duurt het opslaan van een beveiligingsingang niet langer enkele minuten maar een fractie van een seconde.

CN 80524

Beveiligingsgroepen in Backoffice NXT

Het scherm Beveiligingsgroepen is nu beschikbaar in de Backoffice NXT en vervangt de oude overzichts- en detailpagina. In het overzicht staan omschrijving, code, niveau, groep en type, met zoeken en een filter op type. Beveiligingsgroepen kunnen worden aangemaakt en gewijzigd (omschrijving vertaalbaar, code na aanmaken niet meer te wijzigen, niveau optioneel); verwijderen is, net als voorheen, niet mogelijk. Op het tabblad Beveiligingsdeuren zijn de rechten van een groep te zoeken en filteren, kunnen deuren worden toegevoegd of in een keer meerdere worden verwijderd, en kan de set als XML worden geëxporteerd en weer geïmporteerd; na een import toont het scherm welke deuren niet gevonden zijn. Bij Franse fiscale certificering wordt, net als in de oude pagina, een fiscale gebeurtenis vastgelegd bij aanmaken en bij het toevoegen of verwijderen van fiscale deuren. Via de API kunnen beveiligingsgroepen nu worden gezocht, aangemaakt en gewijzigd (POST /api/security-groups/Search, POST /api/security-groups, PATCH /api/security-groups/{id}) en kunnen de deuren van een groep worden opgevraagd, geëxporteerd en geïmporteerd (/api/security-groups/{id}/security-doors/Search, /Export en /Import).

Let op: een import vervangt alle deuren van de groep en zoekt deuren nu ook in bovenliggende groepen, zodat een import voor een groep buiten het hoofdkantoor niet langer leeg uitvalt.

CN 80525

Instellingen

Giftcard logging in Backoffice NXT

Het scherm Giftcard logging is nu beschikbaar in de Backoffice NXT. Je zoekt op giftcardnummer (verplicht), eventueel beperkt tot een datum- en tijdbereik, en ziet per logregel de datum, het bericht, de giftcardconfiguratie, de werkplek en de transactie. Is de giftcardservice voor de winkel(groep) niet geconfigureerd, dan toont het scherm een melding in plaats van een lege lijst. Via de API kunnen deze giftcardberichten nu worden opgevraagd via GET /api/gift-card-message-logs, met filters op giftcardnummer en periode, sortering en paginering.

CN 79532

Giftcardconfiguraties in Backoffice NXT

Het beheer van giftcardconfiguraties is nu beschikbaar in de Backoffice NXT. Je ziet alle configuraties met onder meer configuratie-id, provider, werkplek, terminal-id, endpoint, gebruikersnaam, merchant-id en eigenaar, en kunt configuraties aanmaken, wijzigen en verwijderen. Bij het aanmaken kies je de provider (onder andere Intersolve, TCS, FashionCheque, Paagman, ICP, CinemaCard, Xafax, Bovertis en Piggy) en vul je werkplek en endpoint verplicht in, aangevuld met de inloggegevens en sleutels die de provider vraagt. Via de API zijn de configuraties beschikbaar via /api/gift-card-configurations (opvragen, aanmaken, wijzigen en verwijderen).

Verwijderen vraagt het nieuwe recht Giftcardconfig verwijderen. Dit recht wordt niet automatisch toegekend: ken het toe aan de gebruikers of groepen die configuraties mogen verwijderen. Openen, aanmaken en wijzigen gaan via het bestaande recht voor giftcardconfiguratie.

CN 79533

Transportkosten in Backoffice NXT

Het scherm Transportkosten is nu beschikbaar in de Backoffice NXT. De lijst toont de transportkosten van de huidige winkel en de onderliggende winkels, en kan worden doorzocht op onder meer code, omschrijving, land, ordertype, product en winkel. In het bewerkvenster worden de staffels (minimaal en maximaal orderbedrag met de transportkosten exclusief btw) direct in een tabel onderhouden; staffels kunnen nu ook worden verwijderd, overlappende staffels worden geweigerd en bij opslaan worden ze gesorteerd op minimumbedrag. Via de API kunnen transportkosten van een onderliggende winkel nu ook vanuit het hoofdkantoor worden gewijzigd en verwijderd door de winkel mee te geven.

CN 79543

Templates in Backoffice NXT

Het scherm Templates is nu beschikbaar in de Backoffice NXT en vervangt de oude overzichts- en detailpagina. Met de nieuwe editor maak en wijzig je kassabontemplates eenvoudig: de beschikbare tags zijn direct zichtbaar en voeg je met een klik aan je bon toe, terwijl een live voorbeeld laat zien hoe de bon eruit komt te zien. Ook bij de mailtemplates zie je per soort mail welke tags beschikbaar zijn, zodat je snel weet welke gegevens je in een mail kunt opnemen.

Templates zijn te zoeken en te filteren op type en taal, en kunnen worden aangemaakt, gewijzigd, gekopieerd en verwijderd; per template zie je ook de winkelspecifieke versies. Op het tabblad Labels kunnen labellay-outs worden gewijzigd en gekopieerd. Voor koppelingen zijn nieuwe endpoints beschikbaar om templates te zoeken, aan te maken, te kopiëren, te verwijderen en vooraf te bekijken (onder /api/templates) en om labellay-outs te zoeken, te wijzigen en te kopiëren (onder /api/label-layouts).

CN 79865

Veldcodes in Backoffice NXT

Het scherm Veldcodes is nu beschikbaar in de Backoffice NXT, op dezelfde plek in het menu onder Instellingen. De lijst toont veldcode, veldtype, groep, systeemveld en overerfbaar, standaard gesorteerd op veldcode met 50 regels per pagina, en kan worden doorzocht op veldcode en gefilterd op veldcode en groep; elke kolom sorteert nu op wat hij toont. In het bewerkvenster kunnen type, groep, formaat, keuzes (bij type DropDown), standaardwaarde, gebruikersprompt en de schakelaars verplicht, systeemveld, overerfbaar, vervallen en gebruikersveld worden aangepast, evenals de gebruikers- en interne toelichting met opmaak. De veldcode zelf is niet wijzigbaar en, net als voorheen, kunnen veldcodes niet worden aangemaakt of verwijderd. Ook zijn een lijst- en tellerwidget voor het dashboard beschikbaar. Via de API kunnen veldcodes nu worden opgevraagd, gezocht en gewijzigd (/api/field-definitions).

CN 80504

Stamtabellen in Backoffice NXT

Wijziging doorgevoerd zodat de pagina Stamtabellen in de Backoffice NXT beschikbaar is

CN 80516

Klanten

Reparatiepagina aangepast aan de consumentenkoopwetgeving

Wat is opgeleverd?

De reparatiepagina bepaalt niet langer vooraf of een reparatie onder garantie valt; dat gebeurt pas na technisch onderzoek. De intakevragen zijn herschikt en hernoemd, er is een vraag over de wettelijke garantieperiode bijgekomen en Herhalingsreparatie en Coulancereparatie zijn verwijderd. Het afgiftebewijs, de werkbon en de reparatiemails tonen het antwoord op de nieuwe vraag.

Hoe werkt het?

Intake (tabblad Algemeen)

De garantievragen staan in deze volgorde, allemaal als vinkvak:

• Defect door klant veroorzaakt?

• Binnen de fabrieksgarantieperiode? (was "Binnen fabrieksgarantie")

• Binnen de wettelijke garantieperiode? (nieuw)

• Geldig garantiebewijs? (was "Garantiebewijs")

• Herhalingsreparatie en Coulancereparatie (met het vorige reparatienummer) zijn van de pagina verdwenen.

• Het afgeleide oordeel "Garantie" onder de vragen is weg.

• Bij het kiezen van een aankoop van de klant wordt "Binnen de fabrieksgarantieperiode?" niet meer automatisch aangevinkt, ook niet als de garantie-einddatum van die aankoop nog in de toekomst ligt. De medewerker beantwoordt de vragen zelf.

Rapporten

Het afgiftebewijs en de werkbon tonen de regel "Wettelijke garantie: Ja" of "Nee". Is de vraag nooit beantwoord, dan ontbreekt de regel. De regel "Herhaling" verschijnt alleen nog bij bestaande reparaties die als herhalingsreparatie waren vastgelegd; bij alle andere reparaties is hij weg (voorheen stond daar altijd "Nee").

E-mail

De garantieregel in de reparatiemails kent een eigen tekst voor de wettelijke garantie: "Binnen wettelijke garantie".

De volgorde is: defect door klant veroorzaakt → "Geen garantie", daarna fabrieksgarantie, dan wettelijke garantie, dan garantiecertificaat.

API

Reparatieorders hebben een nieuw veld voor de wettelijke garantie. Herhalingsreparatie, coulancereparatie en het vorige reparatienummer zijn alleen-lezen: bestaande waarden blijven opvraagbaar, maar ze kunnen niet meer worden gezet of gewijzigd.

Waar in de software?

• Backoffice: Klantbeheer → Reparaties → reparatie bewerken, tabblad Algemeen.

• Rapporten Afgiftebewijs en Werkbon (via Rapportage in het reparatie-overzicht), inclusief de klantspecifieke-variant.

• Reparatiemails met de garantieregel, waaronder de e-mail Afgiftebewijs.

• API: reparatieorders (aanmaken, wijzigen en opvragen).

Instellingen/parameters?

Geen nieuwe instellingen.

Benodigde inrichting?

Geen. Mailtemplates die de garantieregel al tonen, krijgen de nieuwe tekst vanzelf. Voorbeeld van zo'n regel in een template:

Garantie = De tekst van het klantspecifieke-template voor de e-mail Afgiftebewijs is met deze oplevering bijgewerkt naar de aangeleverde tekst.

Niet inbegrepen?

• De garantieregel blijft in de e-mail Afgiftebewijs staan. Verwijderen of herformuleren ervan is een aparte opdracht voor de specifieke klant.

• Bestaande reparaties behouden hun vastgelegde herhalings- en coulancegegevens; die zijn niet omgezet of gewist.

• De melding bij een ontbrekend certificaatnummer gebruikt nog de oude benaming "Garantie certificaat".

Vereiste actie?

Geen voor gebruikers. Koppelingen die via de API herhalings- of coulancereparatie of een vorig reparatienummer invullen, moeten dat niet meer doen: "ja" of een nummer wordt geweigerd, "nee" of leeg wordt geaccepteerd.

CN 79165

Ontvangst aanmaken op de PDA

Op de PDA kan een medewerker nu zelf een ontvangst aanmaken, controleren en verwerken, zonder backoffice en zonder bestaande pakbon of inkooporder. Goederen die binnenkomen worden direct geregistreerd, zodat de voorraad meteen klopt. Met dezelfde functie maak je een negatieve ontvangst (retour) aan, bijvoorbeeld voor een retour aan de leverancier of een voorraadcorrectie.

Werking

• In het menu Nieuwe taak staan twee nieuwe taken: Ontvangst aanmaken en Negatieve ontvangst aanmaken.

• De medewerker kiest de leverancier. Daarna kan hij een eigen pakbonreferentie typen of scannen. Met Annuleren maakt de PDA zelf een referentie aan in de vorm PB-jaarmaanddaguurminuutseconde, bijvoorbeeld PB-20260930121752.

• Daarna kiest de medewerker of hij snel wil scannen. Bij snel scannen telt elke scan als één. Zonder snel scannen verschijnt elke scan in beeld, en kan per product het aantal worden aangepast.

• Met de winkelinstelling WifiPurchaseQty aan telt een scan als één inkoopeenheid, bijvoorbeeld een doos van 6. Het scherm toont het aantal stuks per inkoopeenheid en het totaal aantal stuks. De voorraad wordt bijgewerkt met het juiste aantal stuks. Een aantal stuks dat geen hele inkoopeenheid is, mag ook.

• Een product dat nogmaals wordt gescand, telt op bij de bestaande regel.

• Bij Verwerken kiest de medewerker Nu of Later. Nu verwerkt de ontvangst direct. Later bewaart hem als openstaande ontvangst, die later via het menu Ontvangsten wordt opgehaald, gecontroleerd en volgens het normale proces verwerkt.

• Bij een negatieve ontvangst voert de medewerker een pakbonnummer en een omschrijving in. De gescande aantallen worden als negatieve aantallen vastgelegd, en de ontvangst wordt gemarkeerd als retour.

Inrichting

• Winkelinstelling WIFITaskReceiving (Ja/Nee, standaard Nee) toont de taken in het menu Nieuwe taak.

• Recht WIFI Toon taak Aanmaken Ontvangst (WIFISHOWCREATERECEIVINGTASK) toont de taak Ontvangst aanmaken.

• Recht WIFI Toon taak Negatieve Ontvangst (WIFISHOWCREATENEGATIVERECEIVINGTASK) toont de taak Negatieve ontvangst aanmaken. Zo kun je die aan minder gebruikers geven.

• Het bestaande recht Ontvangsten verwerken bepaalt of Nu beschikbaar is. Zonder dit recht is Nu uitgeschakeld, en kan de ontvangst alleen worden opgeslagen.

CN 74461

Vouchermutaties bij saldowijziging via de API

Wat is opgeleverd Het wijzigen van een vouchersaldo via Next legde geen vouchermutatie vast, en een afwaardering werd op het hoofdkantoor geboekt zonder verwijzing naar de transactie. Beide zijn opgelost.

Vouchermutatie bij saldowijziging Een saldowijziging via de API legt nu een vouchermutatie vast met saldo vóór, saldo na en de omvang van de mutatie. Soort mutatie volgt uit het saldo vóór de wijziging: van 0 naar een bedrag = activering, verdere verhoging = opwaardering, verlaging = afwaardering. Wijzigt het saldo niet (bijv. alleen "getoond" of "afgedrukt" aanpassen), dan wordt er géén mutatie meer vastgelegd. Een voucher mag via een wijziging op saldo 0 worden gezet; dat werd voorheen geweigerd. Het mutatiebedrag is altijd positief; de richting zit in het soort mutatie.

Boeking op de juiste winkel Retailer en terminal komen uit de e-loyalty-instellingen van de winkel waarvoor het verzoek wordt gedaan, niet meer standaard van het hoofdkantoor. Bij een klantorder is dat de winkel van de order, ook als de order elders wordt afgerond. Zijn de e-loyalty retailer of terminal niet in te lezen, dan mislukt de actie zichtbaar in plaats van dat er een mutatie op een lege retailer ontstaat.

Afwaardering herleidbaar naar de transactie Bij het afronden van een klantorder met vouchertbetaling wordt het transactienummer van de verkoop op de afwaardering gezet — ook wanneer de commit geen directe verkoop is; dan wordt de betalingstransactie van de order gebruikt. documentId en storeId zijn toe te geven op POST /vouchers, PATCH /vouchers/{id} en POST /vouchers/{id}/redeem (1–25 tekens; storeId valt terug op de winkel van het token). POSNxt kan hiermee het transactienummer meesturen.

CN 79402

Factuurcontrolerecords van een ontvangst

In de REST services is de resource /api/receiving-invoice-records toegevoegd (GET, POST en PATCH) voor de factuurcontrole van een verwerkte ontvangst. Per ontvangstregel staan de ontvangen hoeveelheid en inkoopprijs naast de waarden van de leveranciersfactuur, inclusief korting en verkoopprijs. Met POST /api/receivings/{id}/CreateInvoiceRecords worden de records voor een hele ontvangst in een keer aangemaakt en wordt de ontvangst als factuurgecontroleerd gemarkeerd.

Via PATCH kunnen de gecontroleerde waarden worden bijgewerkt. Met moveDiscountToProduct en moveDiscountedPurchasePriceToProduct wordt de aangepaste korting of inkoopprijs ook op het product vastgelegd.

Voorbeeld: Request

POST /api/receivings/4821/CreateInvoiceRecords

Response (deel)

[

{

"id": 5501,

"receivingId": 4821,

"receivingLineId": 9301,

"productId": 55012,

"receivedQuantity": 10,

"purchasePrice": 12.95,

"discountPercentage": 0,

"sellingPrice": 24.95,

...

}

]

Voorbeeld: gecontroleerde korting aanpassen en op het product vastleggen

PATCH /api/receiving-invoice-records/5501

{

"newDiscountPercentage": 10,

"moveDiscountToProduct": true, // korting ook op het product vastleggen

"newSellingPrice": 22.95

}

CN 79449

Markdowns beheren via de API

Wat is opgeleverd?

De markdown is beschikbaar als eigen resource in ASPOS Next: aanmaken, opvragen, wijzigen en verwijderen, plus een zoekendpoint waarop het overzicht van markdowns (UI-2) draait. Een markdown is de paraplu boven de afprijsrondes; de rondes zelf zijn opgeleverd in PBI 79684.

Hoe werkt het?

Een markdown heeft een code (1 tot 25 tekens) en een omschrijving. De code is uniek over de hele database, ongeacht hoofd- of kleine letters (SALE2026 en sale2026 zijn dezelfde). De code van een verwijderde markdown mag opnieuw worden gebruikt. De omschrijving is altijd te wijzigen. De code alleen zolang de markdown nog geen rondes heeft, daarna ligt hij vast, omdat de rondes hem meenemen naar de stickers en de prijshistorie.

De markdown heeft geen eigen status en geen "open sinds". Die komen van de actieve ronde: de laatste ronde die de markdown nog heeft. Die verwijzing wordt automatisch bijgehouden bij elke ronde die wordt aangemaakt, gewijzigd of verwijderd, en is van buitenaf niet te zetten. Met expand=activeMarkDownRound komt de actieve ronde direct mee, ook in de lijst en de zoekresultaten. Dan heeft het overzicht geen tweede aanroep per regel nodig. Status en type van de ronde komen terug als code en omschrijving. Met een locale wordt de omschrijving vertaald.

Verwijderen is een soft delete: de markdown en zijn rondes in Draft verdwijnen uit alle resultaten.

Het zoeken werkt op code en omschrijving, en filtert en sorteert ook op de gegevens van de actieve ronde: status, type, start- en einddatum en kleurlabel, zowel op code als op omschrijving. Tekstfilters negeren hoofd- en kleine letters en ondersteunen Like met % en _. Voor meerdere waarden tegelijk gebruik je Like, want In werkt alleen op getallen. Bij oplopend sorteren op een veld van de actieve ronde komen markdowns zonder ronde vooraan.

Waar in de software?

De API, op de nieuwe resource markdowns en markdowns/Search. Er is nog geen backofficescherm. Het overzicht volgt in een apart item (UI-2).

Instellingen/parameters?

Alleen het hoofdkantoor maakt markdowns. De winkel wordt bij het aanmaken automatisch het hoofdkantoor en wordt niet gevraagd. Een winkel onder het hoofdkantoor mag markdowns bekijken, maar niet aanmaken, wijzigen of verwijderen. Alle acties, ook het zoeken, zijn voorbehouden aan de rol Administrator.

Elke wijziging legt vast welke medewerker hem deed: bij aanmaken en wijzigen geeft de aanroeper de group user mee.

Benodigde inrichting?

Geen.

Niet inbegrepen?

• Het overzichtsscherm in de backoffice (UI-2).

• Effectueren en terugtrekken van rondes (API-16, API-24). Daardoor is ook de regel "een markdown met een geëffectueerde ronde kan niet worden verwijderd" nog niet in de praktijk te zien, want alle rondes staan in Draft.

• De artikelen van een ronde komen alleen mee bij een losse markdown of ronde die op id wordt opgevraagd, niet in de lijst of de zoekresultaten. Een ronde kan tot 10.000 artikelen bevatten.

Vereiste actie?

Geen.

CN 79671

Afprijsrondes van een markdown

Wat is opgeleverd?

De ronde van een markdown is beschikbaar als eigen resource in ASPOS Next: aanmaken, opvragen, wijzigen en verwijderen, met de regels die een ronde bij elkaar houden. Een ronde heeft een eigen type, status en datums, zodat ronde 2 van een markdown een promotie kan zijn waar ronde 1 een prijswijziging was.

Hoe werkt het?

Een ronde is een prijswijziging (PriceChange) of een promotie (Promotion). Elke nieuwe ronde start in Draft en krijgt het volgende rondenummer, geteld over de rondes die de markdown nog heeft.

Een markdown heeft maximaal één ronde in Draft tegelijk, zodat er nooit twee voorstellen naast elkaar bestaan die elkaar tegenspreken.

De startdatum ligt minstens een dag na vandaag, bij aanmaken en bij wijzigen. "Vandaag" is de Nederlandse datum, dezelfde als die van de taak die de prijzen verwerkt, ook rond middernacht. Alleen een promotie heeft een einddatum, en die ligt na de startdatum. Een prijswijziging heeft er geen.

SalesFromWeek legt vast vanaf welke week de verkopen meetellen, als ISO 8601-week in de vorm yyyyww (maandag tot en met zondag, 52 of 53 weken per jaar). De API vult hem vooraf in op 26 weken terug. Bij aanmaken kan een andere week worden opgegeven, daarna niet meer. Een week die niet bestaat (zoals 202553) of een week die nog loopt of nog moet komen, wordt geweigerd.

Een ronde kan een kleurlabel krijgen. Alleen een bestaande waarde uit de stamtabel wordt geaccepteerd. Status en type komen terug als code en omschrijving.

Een ronde in Draft kan worden gewijzigd en verwijderd. Na verwijderen wijst de markdown weer naar de ronde die hij daarna nog heeft, of naar geen.

Waar in de software?

De API, op de nieuwe resource markdown-rounds. De artikelen van een ronde zijn alleen te lezen, via markdown-round-records of bij één ronde die op id wordt opgevraagd. Er is nog geen backofficescherm (UI-3).

Instellingen/parameters?

Alle acties zijn voorbehouden aan de rol Administrator. Een winkel onder het hoofdkantoor mag de rondes van een markdown van het hoofdkantoor bekijken, maar niet aanmaken, wijzigen of verwijderen. Bij aanmaken en wijzigen geeft de aanroeper de group user mee.

Benodigde inrichting?

Wie kleurlabels wil gebruiken, legt die vast in de stamtabel MarkDownStickerColor (Stamtabellen).

Zonder waarden daar kan een ronde zonder kleurlabel worden aangemaakt.

Niet inbegrepen?

• Effectueren van een ronde (API-16). Daarmee worden ook pas zichtbaar dat een ronde na Draft niet meer te wijzigen of te verwijderen is, en dat ronde 2 een promotie kan zijn na een geëffectueerde prijswijziging.

• Terugtrekken naar Draft (API-24), SalesFromWeek verversen (API-6) en de herstelronde (API-19).

• Het vullen van een ronde met artikelen; een nieuwe ronde is leeg.

Vereiste actie?

Geen, tenzij er kleurlabels gebruikt gaan worden (zie punt 5).

CN 79684

Afrondingsmethoden en -staffels

Wat is opgeleverd?

Nieuwe API-endpoints om afrondingsmethoden en hun staffels te beheren: price-rounding-methods en price-rounding-steps (opvragen, aanmaken, wijzigen, verwijderen en zoeken). Een methode legt per bedragbereik vast op welke vaste prijs wordt afgerond; dit is de basis voor het afprijzen (markdowns).

Hoe werkt het?

Een methode heeft een unieke code (max. 10 tekens, uniek over de hele database), een omschrijving en een type:

SellingPriceInclTax (verkoopprijs incl. btw) of PurchasePrice (inkoopprijs). Een staffel heeft een van-bedrag, een tot-bedrag en een prijs, in hele centen; beide grenzen horen bij de staffel. Staffels binnen één methode mogen elkaar niet overlappen; de foutmelding noemt de staffel(s) waarmee overlapt wordt. Gaten tussen staffels zijn toegestaan. Het type van een methode kan alleen worden gewijzigd zolang er geen staffels zijn, en het verwijderen van een methode verwijdert ook de staffels.

Waar in de software?

ASPOS Next API: price-rounding-methods (met filter methodType) en price-rounding-steps (per methode via priceRoundingMethodId), beide ook met /Search. Een methode hoort bij de winkel die hem aanmaakt en is zichtbaar voor die winkel en de onderliggende winkels.

Instellingen/parameters?

Eigen rechten, los van de markdown-rechten: aspos.price-rounding-methods.read/search/create/update/delete en aspos.price-rounding-steps.read/search/create/update/delete. Standaard alleen voor Administrator-clients.

Bedragen en prijzen liggen tussen 0 en 1.000.000. Een onbekend methodType in het filter geeft een validatiefout.

Benodigde inrichting?

Methoden en staffels moeten worden aangemaakt voordat ze bij het afprijzen gebruikt kunnen worden. Valuta en land zijn geen eigenschap van een methode: maak per land of valuta een aparte methode en maak dat herkenbaar in code en omschrijving. Voorbeeld: methode EUR-VK, staffel 0,00–9,99 → 4,95 en 10,00–19,99 → 14,95.

Niet inbegrepen?

Het toepassen van de afronding bij het afprijzen en het scherm in de Backoffice worden apart opgeleverd.

Methoden van het type inkoopprijs kunnen al worden vastgelegd, maar worden nog nergens gebruikt. Geen afrondingsrichting, eindcijferregels, margebodem, maximale afwijking of afronding op landdecimalen.

Vereiste actie?

Geen.

CN 79691

Factuurcontrole verwerken via de API

Wat is opgeleverd?

De factuurcontrole van een verwerkte ontvangst kan nu volledig via de ASPOS Next API worden verwerkt, met hetzelfde resultaat als de factuurcontrole in de backoffice. Daarnaast zet het instellen van een voorkeursleverancier via de API nu ook echt de voorkeursleverancier op het artikel.

Hoe werkt het?

Maak de factuurregels aan (automatisch voor alle ontvangstregels, of per artikel), pas waar nodig de nieuwe inkoopprijs, korting, regeltotaal of verkoopprijs aan, en verwerk daarna de factuurcontrole. De verwerking boekt de prijsverschillen als voorraadmutatie, legt de voorraadwaardemutatie vast, zet desgewenst de nieuwe korting en/of inkoopprijs door naar de leverancier (en bij de voorkeursleverancier naar het artikel), maakt een nieuwe verkoopprijs direct actief en maakt het journaal aan; daarna staan de factuurregels op verwerkt en is de factuurcontrole van de ontvangst afgerond. Lukt één onderdeel niet, dan wordt niets opgeslagen.

Waar in de software?

ASPOS Next API: POST receivings/{id}/InvoiceCheck (nieuw), in combinatie met POST receivings/{id}/CreateInvoiceRecords en de receiving-invoice-records-endpoints. Daarnaast PATCH product-suppliers/{id}/store-settings/{storeId} (voorkeursleverancier).

Instellingen/parameters?

Recht aspos.receiving-invoice-records.process, beschikbaar voor de rollen Administrator en DataImporter (niet voor Webshop). Winkelinstellingen die de uitkomst bepalen: StockValueCalcType (voorraadwaarde), AutoPriceChange (verkoopprijs) en LedgerJournalReceivings, LedgerExpPurchaseDayBook, LedgerInvCheckJournalType, LedgerRcvInvoicePendIntSt en ASPOSCustomerID (welk journaal wordt aangemaakt).

Benodigde inrichting?

Bij LedgerInvCheckJournalType = 0 (het oude factuurcontrolejournaal) is grootboekrekening 1320 op de hoofdwinkel nodig; ontbreekt die, dan wordt de factuurcontrole geweigerd met een melding die dat aangeeft. Richt de rekening in of gebruik LedgerInvCheckJournalType = 1.

Niet inbegrepen?

De factuurgegevens van de ontvangst (factuurnummer, boekingsnummer, factuurdatum, vervaldatum) worden niet in deze stap meegegeven; die worden vooraf via het wijzigen van de ontvangst vastgelegd. Het backoffice-recht om de inkoopprijs vanuit de factuurcontrole naar het artikel door te zetten wordt in de API niet apart gecontroleerd.

CN 79883

Looplijst-acties op customer-order-requests

Wat is opgeleverd?

Ter voorbereiding van de PDA aanpassing voor de "looplijst" zijn er 4 nieuwe acties toegevoegd in ASPOS Next op customer-order-requests: het aantal te verzenden stuks opvragen, een looplijst starten op basis van de capaciteit die de medewerker kan dragen, de verzonden regels afmelden, en een gestarte looplijst weer vrijgeven.

Hoe werkt het?

De medewerker ziet eerst hoeveel stuks er nog te verzenden zijn voor zijn filiaal. Daarna geeft hij op hoeveel hij kan meenemen en krijgt hij een looplijst terug: de regels in de volgorde waarin PFA ze aanlevert, met barcodes, en aangevuld met de ASPOS-gegevens die PFA niet kent (verkoopprijs, locatie en merk). Na het picken meldt hij de lijst af met een SSCC-barcode en een vervoerder; wil hij er toch mee stoppen, dan geeft hij de lijst vrij en komt die weer vrij te liggen voor een collega.

Vier dingen zijn goed om te weten over het gedrag van PFA. De capaciteit telt transferregels, en PFA knipt nooit een bon doormidden — je krijgt dus minstens zoveel regels als gevraagd en vaak meer.

Een tweede keer starten terwijl er een lijst openstaat geeft dezelfde lijst terug, geen nieuwe. Een gestarte lijst die niet wordt afgemeld blijft gereserveerd tot hij wordt vrijgegeven. En het aantal te verzenden stuks verandert niet door het reserveren, dus die teller is geen controle op starten of vrijgeven.

Het afmelden is bewust een doorgeefluik: de regels die de PDA meestuurt gaan één op één naar PFA, en PFA bepaalt wat er met een regel gebeurt. Een regel met aantal 0 geldt daar als manco.

Waar in de software?

De API, op de bestaande resource customer-order-requests. Er is geen backofficescherm bij; de acties worden aangeroepen door de PDA. De bijbehorende PDA-functionaliteit zit in een apart item.

Instellingen/parameters?

De storesetting PFASoapServiceURL bepaalt naar welke PFA-omgeving de berichten gaan. Die instelling bestond al voor de bestaande PFA-koppeling; er is geen nieuwe instelling bijgekomen. Let op dat dit niet PFARestServiceURL is — dat is de andere PFA-koppeling en die kent de looplijst niet.

Op de acties zitten geen rechten. Of de PDA het menu toont wordt aan de winkelkant bepaald.

Wel is een ingevulde UserID op de medewerker noodzakelijk: PFA legt daarmee vast wie de looplijst heeft gedraaid. Zonder UserID komt er geen enkele aanroep bij PFA aan. Het veld is maximaal 10 tekens breed; een langere waarde wordt door PFA afgekapt. Een medewerker mag de looplijst draaien voor zijn eigen filiaal en voor filialen die daaronder in de winkelboom hangen — een medewerker van het hoofdkantoor kan dus voor een winkel werken, een medewerker uit een andere tak van de boom niet.

Benodigde inrichting?

Vier dingen moeten kloppen voordat er iets werkt:

• Een actief filiaal dat in de winkelboom hangt en waarvan PFA het filiaalnummer kent.

• Een medewerker op dat filiaal met een ingevulde UserID.

• PFASoapServiceURL die naar de juiste PFA-omgeving wijst, via https — een release-build van de API praat uitsluitend https.

• Het IP-adres van de server moet bij PFA zijn vrijgegeven; dat loopt via PFA zelf.

Wijst de instelling naar een adres met een eigen (self-signed) certificaat, dan moet dat certificaat op de server vertrouwd zijn, anders komt de verbinding niet tot stand.

Niet inbegrepen?

De looplijst wordt niet in ASPOS vastgelegd — starten, afmelden en vrijgeven gebeuren volledig bij PFA, dus in ASPOS is achteraf niet terug te zien welke lijsten er gedraaid zijn. ASPOS bepaalt ook geen manco's; dat doet PFA, die een tekort zelf over de transfers verdeelt.

Twee punten liggen nog ter verificatie bij PFA. Het aantal te verzenden stuks daalt niet nadat een lijst is afgemeld. En een regel die de PDA weglaat komt niet terug op een volgende looplijst: die gedraagt zich als manco, terwijl hij volgens de beschrijving zou blijven openstaan.

Tot slot vult PFA het veld *lijstcode* nooit; het is daarom uit de berichten gehaald.

Vereiste actie?

Controleer per omgeving de vier punten uit hoofdstuk 5 — met name of PFASoapServiceURL op de juiste PFA-omgeving staat en of de medewerkers die de looplijst gaan gebruiken een UserID hebben. Gebruik nooit het productieadres van een andere klant.

CN 80025

Bonkorting via de API

Er kan nu via de API een korting op de hele bon geven, net als de bonkorting in de POS. Dat kan bij het berekenen van de winkelwagen (carts/Calculate) en bij het afrekenen van een transactie (transactions/{id}/Commit).

Hoe geef je de korting op?

Je geeft de korting mee in manualReceiptDiscountParameters. Kies één van deze kortingen:

• Percentage: discountPercentage, bijvoorbeeld 10 voor 10% korting.

• Vast bedrag: discountAmountInclTax of discountAmountExclTax, bijvoorbeeld € 2,50 korting.

• Nieuw eindtotaal: newTotalInclTax of newTotalExclTax, bijvoorbeeld "maak er € 10,00 van".

Je kunt maar één korting tegelijk gebruiken. Geef je er meer mee, dan krijg je een validatie melding. Hetzelfde gebeurt bij een percentage boven 100 of een negatief bedrag.

Voorbeeld: winkelwagen berekenen met 10% bonkorting POST api/carts/Calculate

{

"storeId": 1,

"lines": [

{ "productId": 101, "quantity": 1 },

{ "productId": 102, "quantity": 2 }

],

"additionalParameters": {

"manualReceiptDiscountParameters": {

"discountPercentage": 10

}

}

}

Voorbeeld: € 2,50 bonkorting bij afrekenen POST api/transactions/{id}/Commit

{

"...": "bestaande velden van de commit",

"manualReceiptDiscountParameters": {

"discountAmountInclTax": 2.50

}

}

Voorbeeld: eindtotaal van € 10,00 "manualReceiptDiscountParameters": { "newTotalInclTax": 10.00 } Let op het verschil in plaats: bij carts/Calculate staat manualReceiptDiscountParameters onder additionalParameters, bij Commit staat het direct in het request.

Hoe wordt de korting berekend?

• Eerst worden de gewone kortingen op de regels toegepast, zoals acties en handmatige regelkorting. Die blijven gewoon staan.

• Daarna wordt de bonkorting eerlijk verdeeld over de artikelen. Een duurder artikel krijgt naar verhouding een groter deel van de korting.

• Artikelen waarop geen korting mag, doen niet mee. Dat geldt ook voor een nieuw eindtotaal: dat gaat alleen over de artikelen waarop korting mag.

• Is er al een bonkorting met korting over korting toegepast, dan kan er geen handmatige bonkorting meer bij. Dat werkt hetzelfde als in de POS.

• Het nieuwe veld isManualReceiptDiscountAllowed op de winkelwagen en op de regels laat zien of handmatige bonkorting mogelijk is.

CN 80245

Geannuleerde inkooporderregels opvragen

In de REST services bij de GET /api/purchase-orders endpoints is het middels de parameter $includeCancelledLines op de expand purchaseOrderLines nu ook mogelijk om geannuleerde regels terug te krijgen.

CN 80332

Verouderde webpagina-endpoints verwijderd

Wijziging doorgevoerd zodat de verouderde webpagina-endpoints (web-pages, web-page-routes en web-page-versions, GET en POST) en de bijbehorende rechten aspos.web-page-routes.* uit de API zijn verwijderd; een aanroep geeft nu een 404. De databasetabellen en hun gegevens blijven staan.

CN 80346

Langere carriercodes op klantorders

Wijziging doorgevoerd zodat carriercodes tot 100 tekens op een klantorder bewaard kunnen worden, zowel via de API als bij opslaan vanuit de klassieke Backoffice, waar een servicelevel eerder werd afgekapt of het opslaan mislukte.

CN 80623

Retourtransactie herleiden naar de klantorder

In de REST services bij de GET /api/transactions endpoints zijn de nieuwe expand opties "returnLines" en "customerOrder" toegevoegd.

CN 80624

Puntensaldo bij kaarttransacties

Het puntensaldo bij kaarttransacties wordt nu alleen nog herberekend als een klant meerdere kaarten heeft. Heeft de klant een enkele kaart, dan worden het begin- en eindsaldo per transactie voortaan ongewijzigd teruggegeven zoals ze in de loyaliteitsadministratie staan.

Vindt de herberekening wel plaats, dan worden de transacties van de verschillende kaarten samengevoegd op mutatiedatum in plaats van op volgnummer. Daardoor klopt het doorlopende saldo ook als transacties later zijn ingelezen of gecorrigeerd en hun volgnummer dus een andere volgorde heeft dan hun datum.

CN 80632

Juist magazijn voor thuisbezorgorders uit transaction commit

Wat is opgeleverd?

Een thuisbezorgorder die vanuit het afrekenen van een kassatransactie ontstaat, komt nu op het magazijn dat de winkel voor thuisbezorgorders heeft ingesteld, in plaats van altijd op het standaardmagazijn van de kassa. Hoort dat magazijn bij een andere winkel, dan wordt de order ook op die winkel aangemaakt.

Hoe werkt het?

Is de order een bezorgorder, dan pakt hij het magazijn voor thuisbezorgorders. Voorraadreservering, besteladvies en picking volgen daarna dat magazijn. De kassatransactie zelf blijft op de verkopende winkel staan met de omzet en het eigen magazijn — alleen de klantorder verhuist.

Verhuist de order naar een andere winkel én is er aanbetaald, dan volgt die aanbetaling mee via twee correctieboekingen over de rekening-courant: het saldo staat daarna op de winkel die gaat bezorgen.

Waar in de software?

Het afronden van een kassatransactie. Geldt voor elke klantorder die daarbij ontstaat, of die nu uit een gewone kassaverkoop komt of uit een kiosk- of webshoporder.

Instellingen/parameters?

Op de webshop-tab van de winkelkaart: standaard magazijn thuisbezorgorders. De winkelgroepinstelling POSCOTransferPrepay bepaalt hoe een aanbetaling meeverhuist: bij 1 blijft het een aanbetaling op de ontvangende winkel, bij 0 wordt het omgeboekt naar de betaalwijze thuisbezorgorders van de verkopende winkel. Staat KioskOrderAsSale aan, dan worden de bestelde regels direct afgerekend en is er geen aanbetaling om te verplaatsen.

Benodigde inrichting?

Het magazijn moet op de winkelkaart ingevuld zijn; zonder invulling verandert er niets. Wijst het naar een andere winkel, dan hebben beide winkels een kassa nodig en een kassalade 906 (webshop) — die lade wordt niet automatisch aangemaakt, en zonder die lade komen de correctieboekingen zonder lade te staan. Bij POSCOTransferPrepay = 0 moet ook de betaalwijze voor thuisbezorgorders gevuld zijn.

Niet inbegrepen?

Afhaalorders zijn niet meegenomen. Alleen thuisbezorgorders kijken naar het ingestelde magazijn; een afhaalorder houdt het magazijn van de kassa, ook als er een magazijn voor afhaalorders is ingevuld.

Verder worden bestaande klantorders niet met terugwerkende kracht naar het ingestelde magazijn verplaatst, en wordt de magazijninstelling nergens automatisch gevuld; dat blijft handwerk per winkel. En een order die op een andere winkel terechtkomt, is vanaf de verkopende winkel niet meer in te zien — dat volgt de normale winkelafscherming en is niet apart opgelost.

Vereiste actie?

Winkels die hiervan gebruik willen maken, vullen het magazijn voor thuisbezorgorders in op de winkelkaart en controleren de inrichting uit punt 5. Doet een winkel niets, dan blijft het gedrag ongewijzigd — geen actie nodig.

CN 80633

Consistente location headers in 201-responses

In de REST services zijn de location headers in de 201-responses consistent gemaakt. In sommige gevallen was de URL afwijkend of onjuist.

CN 80677

Artikelen verwijderen via de API

In de REST services is een fout opgelost bij het verwijderen van artikelen via DELETE /api/products. In bepaalde gevallen gaf dit een foutmelding (500 Internal Server Error) en werd het artikel niet verwijderd. Het verwijderen werkt nu weer zoals verwacht.

CN 80685

Extensions per klantorderregel bij aanmaken

Bij het aanmaken van een klantorder kunnen nu ook per orderregel extensions worden meegestuurd, net zoals dat op de order zelf al kon. Een order met bijvoorbeeld een prioriteit per regel is daarmee in een keer aan te maken, in plaats van met een extra call per regel achteraf.

De sleutels komen uit de lijst CustomerOrderLineExt en worden op dezelfde manier gecontroleerd als op het losse endpoint voor orderregel-extensions: een onbekende sleutel, een lege extension of dezelfde sleutel twee keer op een regel levert een validatiefout op en de order wordt dan niet aangemaakt. Meesturen kan alleen bij het aanmaken; bij een bestaande orderregel blijft het losse endpoint nodig, met een foutmelding die daarnaar verwijst. Een order zonder regel-extensions werkt ongewijzigd.

Daarnaast is de sleutel PriorityNeleos aan de lijst CustomerOrderLineExt toegevoegd, en controleert het losse endpoint bij het toevoegen van een extension nu op een dubbele waarde voor de aangeleverde sleutel in plaats van altijd op de retourreden.

CN 80820

Extra vervoerdersinstellingen in transaction commit

Bij het aanmaken van een klantorder via POST /api/transactions/Commit kunnen in customerOrder nu naast de vervoerder (carrier) ook serviceLevelTimeCode, serviceLevelOtherCode en incoTerm worden meegegeven. Deze worden op de klantorder vastgelegd en zijn alleen toegestaan bij een bezorgorder. De waarden moeten horen bij de gekozen vervoerder, behalve bij SendCloud, dat de controle zelf doet.

Wordt er een kioskCustomerOrderId meegegeven, dan neemt de nieuwe klantorder gegevens van de kioskbestelling over. Bij een bezorgorder zonder vervoerder, of met dezelfde vervoerder als de kioskbestelling, worden de vervoerder en de pakketinstellingen van de kioskbestelling gebruikt; waarden die in het request zijn meegegeven gaan daarbij voor. Bij een andere vervoerder worden alleen de waarden uit het request gebruikt. Daarnaast worden de bron en de klantreferentie van de kioskbestelling overgenomen. Een klantreferentie op de kioskbestelling gaat voor op die uit het request.

Voorbeeld: Request (deel) voor een bezorgorder vanuit een kioskbestelling

{

...

"customerOrder": {

"customerContactId": 123,

"isDeliveryOrder": true,

"kioskCustomerOrderId": 555, // kioskbestelling met vervoerder PostNL

"carrier": "PostNL", // zelfde vervoerder als de kioskbestelling

"serviceLevelTimeCode": "EVENING" // nieuw: gaat voor op de waarde van de kioskbestelling

// serviceLevelOtherCode en incoTerm worden // overgenomen van de kioskbestelling } }

CN 80986

Kortingen per soort vastgelegd bij afrekenen via de API

Bij het afrekenen van een transactie met een handmatige bonkorting via de REST services worden de kortingen op de transactieregels nu per soort vastgelegd. De handmatige bonkorting staat in discountManualTransaction, met het percentage in discountManualTransactionPercentage. Een klantkorting staat in discountCustomerTransaction, met discountCustomerPercentage. Voorheen werd de bonkorting samen met de actiekortingen in discountTokenRules opgeslagen. Zo sluiten de kortingsgegevens aan op transacties uit de POS.

De nieuwe velden zijn alleen-lezen en komen terug bij het opvragen van transacties.

Voorbeeld: Response van GET /api/transactions/300?expand=Records (deel), na een commit met 10% bonkorting

{

"id": 300,

"discountAmount": 2.50,

"discountManualTransactionPercentage": 10, // nieuw: percentage van de bonkorting

...

"records": [

{

"productId": 101,

"discountAmount": 2.50,

"discountManualTransaction": 2.50, // handmatige bonkorting, nu apart

"discountManualTransactionPercentage": 10, // nieuw

"discountTokenRules": 0, // actiekortingen, zonder de bonkorting

"discountCustomerTransaction": 0, // nieuw: klantkorting

"discountCustomerPercentage": 0, // nieuw

...

}

]

}

CN 81482

Juiste btw-tarieven bij verkoop op afstand

Wijziging doorgevoerd zodat bij verkoop op afstand (VOA) een gratis product dat via een actie aan de order wordt toegevoegd het btw-tarief van het leveringsland krijgt, in plaats van het Nederlandse tarief. Daarnaast worden nieuwe of gewijzigde btw-tarieven nu binnen 15 minuten gebruikt. Eerder kon dat tot een dag duren of pas na een herstart van de API.

CN 81940