VERSIE: 6.0.2026Oslo

Toetsenbordnavigatie in de matrixschermen

In Backoffice NXT is de toetsenbordnavigatie in de matrixschermen verbeterd, onder andere bij het opzetten van de kleur- en maatmatrix van een product. Je kunt nu met de pijltjestoetsen en Enter of spatie door de matrixcellen navigeren en selecties maken zonder muis, zodat het invullen van matrixen sneller gaat.

CN 78954

Uniforme bevestigingsdialogen in de Backoffice NXT

Technische aanpassing waarbij de bevestigingsdialogen in de Backoffice NXT centraal en vereenvoudigd zijn opgezet. Er zijn geen functionele wijzigingen: bestaande bevestigingen werken zoals voorheen.

CN 78960

Berichten in de kassa

Wat is er nieuw?

De kassa toont nu de berichten die vanuit het backoffice naar de winkel zijn gestuurd. De kassamedewerker ziet ze zonder de kassa te verlaten, en dringende berichten komen vanzelf in beeld. Zo bereikt een productterugroep, een prijswijziging of een werkinstructie de kassa op het moment dat het nodig is.

Werking

• Onder Backoffice staat een nieuwe knop Berichten. Die opent de berichtenlijst.

• Zolang er een ongelezen bericht is toont hij het aantal ongelezen berichten.

• Klik op een bericht om het volledig te lezen. Opmaak uit het backoffice, zoals vet en opsommingen, blijft behouden.

• Een bericht dat u opent, wordt automatisch als gelezen gemarkeerd. Met Markeer als ongelezen zet u dat terug.

• Met Verberg gelezen toont u alleen wat nog openstaat; Toon gelezen zet alles weer in de lijst.

• Berichten met prioriteit verschijnen vanzelf als pop-up, met de melding PRIORITEIT. De pop-up sluit u met Sluiten, waarna het bericht als gelezen geldt.

• De kassa haalt de berichten op van de afgelopen twee weken.

Wanneer verschijnt een prioriteitsbericht?

Alleen op een rustig moment, nooit tijdens het afrekenen. Concreet: bij een lege bon, of nadat een transactie is afgerond en de medewerker terug is op het kassascherm. Tijdens het kiezen van een betaalwijze, het invoeren van een bedrag of op het scherm Voltooid onderbreekt de pop-up de verkoop niet.

Aandachtspunten

• Eén keer lezen per winkel. Zodra een bericht op één kassa is gelezen, geldt het voor de hele winkel als gelezen. Op de andere kassa's verschijnt de pop-up dan niet meer en staat het bericht als gelezen in de lijst. Wilt u zeker weten dat iedere medewerker een dringend bericht ziet, gebruik dan ook uw gebruikelijke werkoverleg.

• De functie staat altijd aan. Er is geen winkelinstelling die berichten in- of uitschakelt; wat u in het backoffice verstuurt, komt op de kassa.

• Berichten ouder dan twee weken verdwijnen uit de lijst, ook als ze nog niet gelezen zijn.

CN 77698

Onjuiste kortingsweergave bij kitproducten

Wijziging doorgevoerd zodat de kassa bij samengestelde producten (kits) de korting correct berekent en toont. Wanneer korting voor een onderdeel niet is toegestaan via de productgroep, subgroep of het merk, wordt op de kassabon voor die regel geen korting meer vermeld, zodat de korting op de bon overeenkomt met het kortingstotaal.

CN 78612

Pakbonafdruk onderdrukken bij afronden als factuur

Wat is opgeleverd?

Bij het afronden van een kassatransactie wordt de pakbon niet meer afgedrukt; de klant krijgt alleen de factuur mee.

Hoe werkt het?

De pakbon wordt nog steeds aangemaakt en direct gefactureerd, alleen de afdruk blijft achterwege. Kiest u aan de kassa bewust voor pakbon als betaalsoort, dan wordt die wel afgedrukt.

Waar in de software?

Kassa (POS), bij het afronden van een transactie. De pakbon zelf blijft op te zoeken en af te drukken via de backoffice.

Instellingen/parameters?

De bestaande instelling POSCompleteAsInvoice bepaalt het gedrag. Nieuwe instellingen zijn er niet.

Benodigde inrichting?

Geen.

Niet inbegrepen?

De pakbon blijft beschikbaar, alleen de automatische afdruk.

Vereiste actie?

Geen.

CN 79514

Rapportages

Factuurvoettekst 3 altijd onderaan de factuur

Factuurvoettekst 3 wordt op de klantspecifieke factuurlayout weer altijd onderaan de factuur getoond, ongeacht of bij de klant het vinkje Incasso aan staat. De eerdere aanpassing waarbij deze voettekst alleen bij incassoklanten werd getoond, is teruggedraaid.

CN 79457

Aanpassing klantspecifiek schaplabel

Aanpassing doorgevoerd op klantspecifiek label naar wensen van de klant

CN 79749

Producten

Centraal bestellen op basis van vrije DC-voorraad

Wat is opgeleverd?

Nieuwe optie "Bestel op vrije DC voorraad" op inkoopadviesprofielen. Bij centraal bestellen wordt nu ook de vrije voorraad op het distributiecentrum (DC) meegewogen: producten zonder (voldoende) vrije DC-voorraad worden niet (volledig) besteld.

Hoe werkt het?

• Bij het genereren van het advies: vrije voorraad op het DC = fysieke voorraad − openstaande klantorders.

Is deze ≤ 0, dan wordt het product niet in het advies opgenomen. Is er wel vrije voorraad, dan blijft het geadviseerde aantal ongewijzigd (nog niet afgetopt op dit moment).

• Bij het verwerken van het advies wordt de vrije DC-voorraad opnieuw gecontroleerd:

• Voldoende vrije voorraad → volledige aantal wordt besteld.

• Deels voldoende → bestelling wordt afgetopt op de beschikbare vrije voorraad (naar beneden afgerond op de inkoopeenheid).

• Geen vrije voorraad meer → regel wordt niet verwerkt en blijft open staan in het advies; gebruiker krijgt een melding met de betreffende producten.

• Bestaande verwerking (inkooporder aanmaken, interfiliaal ontvangst, gekoppelde klantorder) blijft ongewijzigd.

Waar in de software?

Backoffice → Inkoop → Inkoopadviesprofielen (tabblad Extra) en het besteladvies-scherm (verwerken van adviesregels).

Instellingen/parameters?

Nieuw vinkje "Bestel op vrije DC voorraad" op het inkoopadviesprofiel. Alleen bruikbaar/actief wanneer "Bestel centraal" én "Altijd centraal bestellen" beide aan staan; het DC is de winkel/het magazijn die al op het profiel is ingesteld.

Benodigde inrichting?

Bestaande centrale inkoopadviesprofielen die dit gedrag moeten krijgen, moeten handmatig worden aangepast: vink "Bestel centraal", "Altijd centraal bestellen" én het nieuwe "Bestel op vrije DC voorraad" aan.

Niet inbegrepen?

Geautomatiseerde/geplande verwerking (achtergrondtaak) is niet los geverifieerd — aangenomen dat dezelfde controle wordt toegepast. Geen wijziging in bestaande meldingsteksten; de bestaande meldingpopup wordt hergebruikt voor de nieuwe waarschuwingen.

Vereiste actie?

Beheerder moet gewenste inkoopadviesprofielen handmatig voorzien van het nieuwe vinkje — er gebeurt niets automatisch voor bestaande profielen.

CN 77416

Verdeling direct invullen bij handmatig toevoegen aan verzameld besteladvies

Wat is opgeleverd?

Bij het handmatig toevoegen van een product aan een centraal/verzameld besteladvies kan de verdeling over de winkels/magazijnen nu direct in hetzelfde toevoegscherm worden ingevuld, in plaats van achteraf via een apart scherm.

Hoe werkt het?

In het toevoegscherm verschijnt — alleen wanneer het besteladvies een verzameladvies met verdeelsleutel betreft — een keuzelijst met verdeelsleutels. Na het kiezen van een sleutel en het toepassen ervan wordt de verdeling per winkel/magazijn direct in hetzelfde scherm getoond; de voorgestelde aantallen kunnen daar nog handmatig worden aangepast voordat wordt opgeslagen. Er zijn twee knoppen: "Opslaan" (verwerkt de verdeling en sluit het scherm) en "Opslaan + volgende regel" (verwerkt de verdeling en houdt het scherm open om direct het volgende product toe te voegen). Na het opslaan worden automatisch alle leveranciers geselecteerd en het filter toegepast, zodat het toegevoegde product meteen zichtbaar is in het overzicht.

Waar in de software?

Backoffice, Inkoop > Besteladvies, bij het handmatig toevoegen van een productregel aan een centraal/ verzameld besteladvies.

Instellingen/parameters?

Geen. De functionaliteit verschijnt alleen wanneer het besteladvies een verdeelsleutel betreft; voor een regulier (niet-centraal) besteladvies verandert er niets.

Benodigde inrichting?

Geen. Bestaande verdeelsleutels worden hergebruikt.

Niet inbegrepen?

Wordt er geen verdeelsleutel toegepast, dan wordt de verdeling niet automatisch ingevuld en blijft deze op nul staan — de verdeling moet dan alsnog achteraf via het bestaande verdeling-icoon in het overzicht worden ingevuld. De verwerking van het besteladvies zelf (omzetten naar inkooporders) is verder ongewijzigd.

Vereiste actie?

Geen.

CN 77436

DC verdelen vanuit een andere winkel

Wat is opgeleverd?

De "DC verdelen"-popup is uitgebreid: een gebruiker met het recht "Voorraad verdelen vanaf winkel" kan voorraad nu ook verdelen vanuit een andere winkel, niet alleen vanuit het DC. Daarnaast is verdelen tussen winkels onderling (winkel naar winkel, en winkel naar DC) binnen dezelfde groep mogelijk gemaakt.

Hoe werkt het?

Boven "Voorraad DC" staat een nieuwe dropdown met de winkels die al in de popup getoond worden; het DC staat hier standaard geselecteerd, zodat de bestaande werking ongewijzigd blijft zolang niets wordt aangepast.

Kiest de gebruiker een andere winkel als bron, dan wordt de vrije voorraad gecontroleerd (fysieke voorraad min klantorders): is die nul, dan verschijnt een foutmelding en blijft de vorige keuze staan; is er wel vrije voorraad, dan worden de voorraadgegevens en de bestemmingslijst bijgewerkt — het DC verschijnt dan zelf ook als mogelijke bestemming.

De inkooporder die ontstaat, gebruikt voortaan de leverancier van de gekozen bronwinkel in plaats van altijd die van het DC. De instelling voor automatische verwerking (FILW/ontvangst) blijft op dezelfde manier werken, ongeacht welke winkel als bron is gekozen.

Verdelen náár het DC blijft voorbehouden aan een gebruiker die op DC-niveau (of een hoger gelegen knooppunt) is ingelogd; een winkelgebruiker met het recht kan dus wel vanuit een andere winkel verdelen, maar niet naar het DC zelf versturen. Heeft het DC zelf geen vrije voorraad, dan blijft de popup gewoon bruikbaar zodat een andere winkel gekozen kan worden.

Waar in de software?

Backoffice, Productbeheer, voorraadpopup (Alt+I) → "DC verdelen".

Instellingen/parameters?

Het gebruikersrecht "Voorraad verdelen vanaf winkel" bepaalt of een gebruiker de nieuwe dropdown en functionaliteit ziet.

Dit recht wordt niet standaard aan beveiligingsgroepen toegekend en moet bewust worden gegeven aan de gewenste gebruikers/groepen. Welke winkels een gebruiker mag zien, blijft bepaald door de bestaande storesettings ShowShopsUntilNode/ShowStockLevelUntilNode — daar verandert niets aan.

Benodigde inrichting?

Voor elke winkel die als bron gebruikt gaat worden, moet een interstore-leverancier- én klantrecord aanwezig zijn (hetzelfde principe dat al gold voor het DC). Zonder deze koppeling kan er niet vanuit die winkel verdeeld worden.

Niet inbegrepen?

Gebruikers zonder het recht "Voorraad verdelen vanaf winkel" merken niets van deze wijziging — voor hen blijft de bestaande DC-only werking ongewijzigd.

Vereiste actie?

Ken het recht "Voorraad verdelen vanaf winkel" toe aan de gebruikers/groepen die vanuit een andere winkel moeten kunnen verdelen. Controleer dat de benodigde interstore-leverancier- en klantrecords aanwezig zijn voor de betreffende winkels.

CN 77931

Categoriegroepen in de 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 79659

Opslaan van nieuwe bestelprofielen

Wijziging doorgevoerd zodat nieuwe bestelprofielen in de Backoffice weer worden opgeslagen. Voorheen werd een nieuw profiel na het opslaan zonder foutmelding niet bewaard.

CN 79858

Prijstype op de productkaart

Het prijstype op de productkaart in Productbeheer wordt weer correct opgeslagen en getoond, ook in een andere taal dan Nederlands.

CN 79920

Gebruikers

Beveiligingsingangen voor toevoegen en wijzigen gesplitst

Wat is er opgeleverd?

De gecombineerde "Toevoegen/wijzigen"-beveiligingsingangen zijn opgesplitst in aparte "Toevoegen"- en "Wijzigen"-beveiligingsingangen voor de resterende beveiligingsingangen. Hiermee is de opzet die eerder alleen voor Productgroepen en Merken gold doorgetrokken naar alle overige onderdelen. Rechten om iets toe te voegen en om iets te wijzigen kunnen nu afzonderlijk toegekend worden.

Hoe werkt het?

Voor elke gecombineerde beveiligingsingang zijn twee nieuwe ingangen aangemaakt: één voor toevoegen en één voor wijzigen. De oude, gecombineerde beveiligingsingang is niet verwijderd maar hernoemd zodat duidelijk zichtbaar is dat deze verouderd is. De nieuwe beveiligingsingangen zijn toegevoegd aan alle beveiligingsgroepen die de oude beveiligingsingangen al actief hadden, zodat bestaande gebruikers hun rechten behouden. In de BackOffice Next-pagina's die al beschikbaar zijn, bepalen vanaf nu de nieuwe beveiligingsingangen of de knoppen voor toevoegen en wijzigen beschikbaar zijn. De klassieke BackOffice blijft de "oude" beveiligingsingangen gebruiken.

Waar in de software?

De nieuwe verdeling is alleen van toepassing op Backoffice Next. De beveiligingsingangen die nu als "oud" zijn gemarkeerd, zijn nog van toepassing in de klassieke Backoffice.

Instellingen/parameters?

Per gesplitste functie zijn er nu twee beveiligingsingangen in plaats van één, bijvoorbeeld "Merken toevoegen" en "Merken wijzigen" naast de hernoemde, verouderde "Merken toevoegen/wijzigen". De rechten worden zoals gebruikelijk per beveiligingsgroep toegekend.

Benodigde inrichting?

Geen inrichting nodig bij oplevering. De nieuwe beveiligingsingangen zijn via een script automatisch toegevoegd aan alle beveiligingsgroepen die de bijbehorende oude ingang al hadden, dus de bestaande rechten blijven één-op-één gelijk. Wil een beheerder het onderscheid daadwerkelijk benutten, dan kan diegene vanaf nu bij een beveiligingsgroep bijvoorbeeld wel de "Wijzigen" variant en niet de "Toevoegen" variant toewijzen.

Niet inbegrepen?

Het gedrag van pagina's die nog niet in BackOffice Next bestaan verandert niet; die blijven in de oude BackOffice op de verouderde gecombineerde beveiligingsingang werken. De verouderde ingangen worden in deze release ook nog niet verwijderd; dat gebeurt pas wanneer de laatste pagina's naar BackOffice Next zijn gemigreerd.

Vereiste actie?

Geen verplichte actie. Bestaande rechten blijven werken zoals voorheen. Aanbevolen:

controleer per beveiligingsingang of de nieuwe "Toevoegen"- en "Wijzigen" ingangen overeenkomen met wat die groep daadwerkelijk mag, en pas ze aan waar toevoegen en wijzigen gescheiden moeten worden.

CN 78124

Instellingen

Dealermenu in de Backoffice NXT

Het Dealermenu is nu beschikbaar in de Backoffice NXT onder Instellingen. Op het tabblad IP-adres check zoek je op (een deel van) een IP-adres of opmerking en zie je bij welke winkel het adres hoort; op het tabblad Werkplek check zoek je een werkplek op code of omschrijving en open je de details met de algemene gegevens en de mogelijkheden van die werkplek. Het tabblad Actie check is een rekenhulp voor kortingen: je stelt een winkelmand samen met scancodes en aantallen (of laadt een bestaande bon) en ziet direct de totalen en per regel welke kortingen zijn toegepast. Op het tabblad Downloads download je per winkel de audit-export (Excel met gebruikers, beveiligingsgroepen, rechten en IP-adressen) en de voorraad-/balansexport (CSV met barcode, artikelnummer, omschrijving, verkoop- en inkoopprijs, btw en productgroep). Via de API zijn hiervoor zoekacties op IP-adressen en werkplekken beschikbaar (POST /api/store-ip-addresses/Search en POST /api/workstations/Search) en de exports GET /api/security/audit-export en GET /api/products/balance-export.

CN 77095

Redencodes in de Backoffice NXT

Het beheer van redencodes (bijvoorbeeld voor retouren, kortingen en correcties) is nu beschikbaar in de Backoffice NXT. Je ziet de redencodes in een overzicht met code, omschrijving, type, volgorde en zichtbaarheid, kunt filteren op type en zoeken op code of omschrijving, en redencodes aanmaken, wijzigen en (ook meerdere tegelijk) verwijderen. Bij kortingsredenen stel je in het bewerkvenster ook bereik, soort en waarde van de korting in. Een winkel kan bij een redencode die hoger in de organisatie is aangemaakt de grootboekrekeningen en de zichtbaarheid voor die winkel overschrijven; de overige gegevens blijven van het niveau dat de code beheert en worden op winkelniveau alleen-lezen getoond. Via de API zijn deze winkelinstellingen beschikbaar via GET, PATCH en DELETE op /api/reason-codes/{id}/store-settings, en weigert de API wijzigingen aan een redencode van een ander organisatieniveau.

CN 78349

Bezorggebieden in de Backoffice NXT

Het scherm Bezorggebieden is nu beschikbaar in de Backoffice NXT. Net als in de oude Backoffice is dit een import- en exportscherm: de gebieden (postcode van/tot, winkel, bezorgkosten en inkoopkosten) worden in een doorzoekbare lijst getoond met winkelnaam en plaats, en kunnen via Excel worden geïmporteerd en geëxporteerd, per regel worden verwijderd of in hun geheel worden verwijderd. Het bestandsformaat is gelijk aan dat van de oude pagina, zodat bestanden uitwisselbaar blijven; een import voegt regels toe en fouten worden per rij in het bestand gemeld. Via de API kunnen bezorggebieden nu ook in bulk worden verwijderd, en het bulk-toevoegen via POST /api/delivery-centres/bulk meldt een geslaagde import weer correct als geslaagd.

CN 79542

Financeel

Dagtotalen in de Backoffice NXT

Het scherm Dagtotalen is nu beschikbaar in de Backoffice NXT. Je zoekt dagtotalen op datum en op een of meer winkels en opent per dagtotaal een detailvenster met drie tabbladen: de totalen (waaronder begin- en eindsaldo), de omzet per productgroep met marge, en de betalingen per betaalwijze met het verschil. Dagtotalen van kluislades worden niet getoond, dagtotalen zonder kassalade wel; die vielen in het oude scherm onterecht weg. Ook wordt het totaal van de verschilkolom bij de betalingen nu correct opgeteld, waar het oude scherm altijd 0,00 toonde. Via de API kunnen dagtotalen nu worden gezocht (POST /api/daily-totals/Search) en per winkel worden opgevraagd, zijn begin- en eindsaldo beschikbaar, en zijn de dagtotalen per productgroep nieuw op te vragen via GET /api/daily-group-totals (lijst en per id) en POST /api/daily-group-totals/Search.

Het menu-item gebruikt nu het recht Dagtotalen, hetzelfde recht dat de pagina zelf al vroeg, in plaats van het recht voor dagtotalenadministratie. Controleer of gebruikers die het menu-item tot nu toe zagen ook het recht Dagtotalen hebben.

CN 79131

Klanten

Document verwijderen bij een klantorder

Wijziging doorgevoerd zodat een document via de Documenten-tab van een klantorder daadwerkelijk wordt verwijderd na bevestiging, ook na het opslaan en opnieuw openen van de order.

CN 79195

Sendcloud-deelleveringen: herleidbaar ordernummer en kopie van de bezorgmethode

Wat is opgeleverd?

Bij deelleveringen van een webshoporder neemt ASPOS de bij de eerste levering gekozen bezorgmethode nu één-op-één over naar de vervolgzendingen in Sendcloud. Daarnaast is elke afzonderlijke zending in Sendcloud te herleiden aan de ASPOS-order en de bijbehorende pakbon.

Hoe werkt het?

De eerste levering gebruikt nog altijd de zending die de webshop heeft aangemaakt. Zet u daarna een volgende deellevering om naar pakbon, dan maakt ASPOS een nieuwe Sendcloud-zending aan en neemt daarbij het gekozen servicepunt of het afwijkende afleveradres en de verzendmethode van de eerste levering over. De verzendpop-up laat bij zo'n vervolglevering geen bezorgopties meer zien, omdat die keuze bij de eerste levering al is gemaakt; het gewicht, het aantal colli, de afmetingen en de ophaaldatum vult u wel per levering in het scherm in en die worden ook zo aangemeld.

Waar in de software?

Backoffice, klantorders: het omzetten van een klantorder naar pakbon en de verzendpop-up die daarbij verschijnt.

Onderliggend de Sendcloud-koppeling die de zending aanmeldt.

Instellingen/parameters?

Er zijn geen nieuwe instellingen. De bestaande Sendcloud-instellingen blijven gelden, waaronder Carrier, CarrierShowDialog, CarrierDefaultTransporter, CarrierDefaultSvcLevel, CarrierDefaultWeight en ShippingColli.

Benodigde inrichting?

Geen extra inrichting. Voorwaarde is de bestaande werkwijze dat de webshop bij het plaatsen van de order het Sendcloud-verzendnummer meegeeft aan de klantorder; op basis daarvan wordt de bezorgmethode van de eerste levering overgenomen.

Niet inbegrepen?

Tijdsloten worden bewust niet meegenomen naar een vervolglevering, omdat die op dat moment al verstreken zijn. De wijziging geldt voor de tweede en volgende leveringen; de eerste levering houdt de zending en de nummering van de webshop. Bij een order zonder Sendcloud-verzendnummer van de webshop blijft de keuze voor vervoerder en serviceniveau in de verzendpop-up staan. Het meesturen van de zendinginhoud en de Sendcloud-retourmodule zijn afzonderlijke onderdelen.

Vereiste actie?

Geen.

CN 79447

Vestigingen

StoreXML blijft behouden bij opslaan vestiging

Wijziging doorgevoerd waardoor de storeXML niet meer onterecht wordt aangepast na opslaan van de vestiging via de backoffice.

CN 80478

Klantorder aanmaken bij transaction commit

In de REST services kan bij het committen van een transactie via POST /api/transactions/Commit nu meteen een klantorder worden aangemaakt, in plaats van dat dit een aparte stap is. Hiervoor is het onderdeel customerOrder aan het request toegevoegd, waarin de klant, bezorgen of ophalen, bezorgvoorkeuren en een eventuele aanbetaling kunnen worden meegegeven.

Het id van de aangemaakte klantorder komt terug in de response als customerOrderId.

Voorbeeld: Request waarbij bij de commit een klantorder wordt aangemaakt die in de winkel wordt opgehaald

{

"workstationId": 1,

"transaction": { ... },

"customerOrder": { // nieuw: klantorder aanmaken bij de commit

"customerContactId": 123,

"isDeliveryOrder": false,

"pickupStoreCode": "M001", // de klant haalt de order op in winkel M001

"preferredDeliveryDate": "2026-10-05",

"deposit": 25.00, // aanbetaling op de klantorder

"remarks": "Klant wordt gebeld als de order klaarstaat"

}

}

Response

{

"id": 98765,

"number": 100234,

"customerOrderId": 55012, // nieuw: id van de aangemaakte klantorder

...

}

CN 59434

Ontvangstregels in bulk toevoegen

In de REST services is het endpoint POST /api/receiving-lines/bulk toegevoegd. Hiermee kunnen in een keer meerdere ontvangstregels (maximaal 500 per ontvangst) voor een bestaande ontvangst worden aangemaakt, in plaats van een voor een via POST /api/receiving-lines. De regels worden gevalideerd en gesorteerd, de totalen van de ontvangst worden opnieuw berekend en kitproducten worden automatisch als extra regels toegevoegd.

Met de parameter deletePreviousLines=true worden de bestaande regels van de ontvangst vervangen in plaats van aangevuld. Dat kan alleen zolang de ontvangst nog geen verwerkte regels heeft.

Voorbeeld: Request

POST /api/receiving-lines/bulk?deletePreviousLines=false

[

{

"receivingId": 4821, // de ontvangst waar de regels bij horen

"productId": 55012,

"productQuantity": 10,

"purchasePrice": 12.95,

"taxCodeId": 1

},

{

"receivingId": 4821,

"productId": 55013,

"productQuantity": 5,

"purchasePrice": 8.50,

"taxCodeId": 1

}

]

Response

[ 9301, 9302 ] // ids van de aangemaakte ontvangstregels

CN 76944

Journaals en journaalregels opvragen

Via de API zijn nu de journaals en journaalregels op te vragen: de financiële boekingen die ASPOS klaarzet voor de export naar het boekhoudpakket. Per journaal zijn onder meer winkel, status, type, relatiedatum, omschrijving, dagboek en exportdatum beschikbaar; per journaalregel onder meer grootboekrekening, factuurgegevens, debet- en creditbedragen (ook in vreemde valuta), btw, kostenplaats en kostendrager. Beide zijn te filteren op onder meer status, type, relatietype, datumbereik en of ze al geëxporteerd zijn, en kunnen gesorteerd en per pagina worden opgehaald. De endpoints zijn alleen-lezen: GET /api/journals en GET /api/journal-records (lijst en per id) en de zoekacties POST /api/journals/Search en POST /api/journal-records/Search.

CN 77685

Labels aanmaken vanuit een ontvangst

Wat is opgeleverd?

Het is nu mogelijk om via de API labels aan te maken vanuit een ontvangst (receiving). Er zijn drie manieren: automatisch per ontvangen product, handmatig met een zelf gekozen labellayout, en klantlabels voor producten die aan een klantorder gekoppeld zijn.

Hoe werkt het?

• Automatisch (per product): voor elk ontvangen product wordt op basis van de productinstelling bepaald of er een schaplabel, een prijslabel of beide worden aangemaakt. Een schaplabel krijgt aantal 1, een prijslabel krijgt als aantal de ontvangen hoeveelheid (afgerond naar boven op een heel aantal).

• Handmatig (met layout): de gebruiker kiest zelf een labellayout; het labeltype en aantal worden daarvan afgeleid.

• Klantlabels: per klantorderregel op de ontvangst wordt één klantlabel aangemaakt; regels zonder klantorderkoppeling worden overgeslagen.

• Alleen nieuw ontvangen producten worden standaard voorzien van een automatisch label — een product dat al eerder op voorraad was, wordt overgeslagen, tenzij dit expliciet wordt aangevraagd.

Waar in de software?

Aan te roepen via de API met het endpoint POST api/receivings/{id}/CreateLabels

Instellingen/parameters?

LET OP allemaal bestaande storesettings

• RecvMakeLabelsForNewOnly — bepaalt of automatisch aanmaken standaard alleen voor nieuw ontvangen producten geldt.

• ProductLabelCheckESL — als aan, worden producten met een actief elektronisch schaplabel overgeslagen bij automatisch aanmaken.

• ReceivingDefShelfLabel / ReceivingDefPriceLabel — bepalen het standaard schap- resp. prijslabeltype bij automatisch aanmaken; zonder instelling wordt het label "Schap" resp. "Prijs" gebruikt.

• KLBLabelSortOrder — bepaalt de volgorde van klantlabels (standaard op ordernummer, optioneel op achternaam van de klant).

Benodigde inrichting?

Geen aparte inrichting nodig — bestaande labeltypes en -layouts worden gebruikt. Voor klantlabels moet op het hoofdkantoor een labeltype met code CUSTOMERLABEL zijn ingericht; is dit niet het geval, dan geeft de aanvraag een foutmelding.

Niet inbegrepen?

Het presentatieaantal van een product (instelling UsePresQtyForShelfLabel) wordt hier niet toegepast — een schaplabel vanuit een ontvangst krijgt altijd aantal 1. Deze instelling werkt alleen bij labels die worden aangevraagd vanuit prijswijzigingen.

Vereiste actie?

Geen.

CN 78007

Vertaalde omschrijvingen van systeemwaarden (SMDL)

In de REST services worden omschrijvingen uit de systeemstamgegevens (SMDL), zoals status- en typeomschrijvingen, nu vertaald. De taal wordt bepaald met de bestaande parameter locale, bijvoorbeeld en-GB. Zonder deze parameter geldt de taal van de gebruiker of winkel. Is er geen vertaling beschikbaar, dan wordt de bestaande ASPOS-omschrijving teruggegeven.

Voorbeeld: Request

GET /api/system-master-data-lists?listNames=CustomerOrderType&locale=en-GB

Response (deel)

[

{

"id": 12,

"listName": "CustomerOrderType",

"code": "Normal", // systeemwaarde, wordt niet vertaald

"value": "Normal order" // nieuw: omschrijving in de gevraagde taal

}

]

CN 78021

Triggers omgezet naar de nieuwe base repository

De triggers in de REST services zijn omgezet naar de nieuwe base repository.

CN 78216

Maximale lengte van vertalingen per veld

Next beperkte alle vertaalde teksten tot 255 tekens

Wat is opgeleverd?

Next hanteerde één vaste maximale lengte van 255 tekens voor alle vertaalde teksten, ongeacht om welk veld het ging. Daardoor kon je lange teksten die ASPOS wél toestaat — zoals de bonkop en de bonvoet — niet via Next onderhouden. Vanaf nu geldt per veld de maximale lengte die dat veld zelf heeft.

Hoe werkt het?

Bij het opslaan van een vertaling wordt de lengte getoetst aan het veld waar de vertaling bij hoort. De foutmelding noemt de toegestane lengte van dát veld, bijvoorbeeld "Value must be between 1 and 60 characters". Dit geldt ook voor vertalingen die je meestuurt bij het aanmaken van een product, groep, prijslijst, klantgroep of kassa.

De belangrijkste grenzen:

• Bonkop en bonvoet (kassa-instellingen): 100.000 (was 255)

• Memo van een webnode: 4.000 (was 255)

• Omschrijving mastertabel-item: 200

• Online omschrijving product: 120

• Omschrijving kitgroep: 100

• Omschrijving webnode: 70

• Omschrijving en 2e omschrijving product: 60

• Omschrijving categoriegroep / kassagebeurtenis: 60

• Omschrijving artikelsubgroep / prijslijst / reden / welkomsttekst klantendisplay: 40

• Omschrijving klantgroep / beveiligingsgroep: 30

• Omschrijving artikelgroep / dynamische menuknop: 25

• Merkomschrijving, kortingsomschrijving, betaalwijze, menutabtitel, memo-velden: 255 (ongewijzigd) Wijzig je een bestaande vertaling naar een ander veld, dan wordt de opgeslagen tekst opnieuw getoetst aan de grens van dat nieuwe veld. Past de tekst er niet in, dan wordt de wijziging geweigerd — er kan dus geen vertaling ontstaan die te lang is voor zijn eigen veld.

Waar in de software?

De vertalingen (FieldLanguageTranslations), zowel los bij te werken als meegestuurd bij het aanmaken van het bovenliggende gegeven. Naast de teksten in de tabel hierboven zijn nu ook de factuurvoetteksten van een winkel via Next bij te werken; die waren voorheen helemaal niet aanpasbaar.

Instellingen/parameters?

Geen store settings of nieuwe instellingen. Voor het bijwerken van vertalingen zijn de bestaande rechten van toepassing (Administrator, DataImporter en Webshop).

Benodigde inrichting?

Geen.

Niet inbegrepen?

• De factuurvoetteksten van een winkel blijven begrensd op 255 tekens. Dat is een bewuste keuze: bij het uitlezen wordt een winkelvertaling na 250 tekens afgekapt, dus een hogere grens zou tekst toestaan die nooit volledig op de factuur komt.

• Bij het wijzigen van een product worden meegestuurde vertalingen nog niet op lengte gecontroleerd; bij het aanmaken wel.

• De online omschrijving van een product blijft op 120 tekens; die grens is niet verruimd.

Vereiste actie?

Let op: dit is niet alleen een verruiming. Voor 17 velden is de grens strenger dan de oude 255 tekens.

Teksten die eerder werden geaccepteerd, worden nu geweigerd — bijvoorbeeld een artikelomschrijving van 200 tekens (nu maximaal 60) of een klantgroepomschrijving van 100 tekens (nu maximaal 30).

Loop daarom na of koppelingen en imports die vertalingen aanleveren binnen de nieuwe grenzen blijven, en kort te lange teksten in. Reeds opgeslagen te lange teksten blijven staan, maar kunnen niet ongewijzigd opnieuw worden opgeslagen.

CN 78457

Zoeken in ontvangstregels

In de REST services is het zoekendpoint POST /api/receiving-lines/Search toegevoegd. Hiermee kunnen ontvangstregels worden gezocht met filters en een vrije zoekterm, die zoekt op de leveranciersproductcode en het productnummer. Ook op velden van de bijbehorende ontvangst kan worden gefilterd en gesorteerd, via de notatie Receiving.veldnaam.

Voorbeeld: Request

{

"storeId": 1,

"searchQuery": "blauw", // vrije zoekterm

"searchRecords": [

{

"fieldName": "Receiving.Code", // filter op een veld van de ontvangst

"operator": "IsEqualTo",

"value": "ONT-2026-00042"

}

],

"limit": 50

}

Response (deel)

[

{

"id": 9301,

"receivingId": 4821,

"productId": 55012,

"productQuantity": 10,

"processed": false,

...

}

]

CN 78950

Klantorderregels filteren op ontvangst

Aan het endpoint GET /api/customer-order-lines in de REST services is de filterparameter receivingIds toegevoegd. Hiermee kunnen de klantorderregels worden opgevraagd die aan een of meer ontvangsten gekoppeld zijn, bijvoorbeeld om te zien welke klantorders door een ontvangst (deels) zijn geleverd. Geef de parameter per ontvangst-id opnieuw mee.

Voorbeeld: Request

GET /api/customer-order-lines?storeId=1&receivingIds=4821&receivingIds=4822

Response (deel)

[

{

"id": 77001,

"customerOrderId": 33012,

"productId": 55012,

"quantity": 2,

...

}

]

CN 78953

Ontvangst verwijderen: retourontvangsten en foutafhandeling

Het endpoint DELETE /api/receivings/{id} in de REST services is uitgebreid. Een retourontvangst kan nu ook worden verwijderd, zolang die uit het retourmagazijn van de winkel komt. Bij het verwijderen worden openstaande inkoop-pending aantallen teruggedraaid, wordt teruggeboekte retourvoorraad naar het standaardmagazijn verplaatst en wordt de ontvangst losgekoppeld van een eventuele multi-ontvangstcontrole.

Een niet-bestaande ontvangst geeft nu een 404 terug in plaats van een validatiefout. Een ontvangst die al verwerkt is, geeft nog steeds een 400 met een validatiemelding.

Voorbeeld: Request

DELETE /api/receivings/4821

Response

200 OK // ontvangst verwijderd

404 Not Found // nieuw: ontvangst bestaat niet

400 Bad Request // ontvangst mag niet worden verwijderd, bijvoorbeeld al verwerkt

CN 78957

Ontvangst verwerken: aangemaakte klantordermails

Het endpoint POST /api/receivings/{id}/Process in de REST services geeft nu in de response terug welke mails zijn aangemaakt voor klantorders die door de ontvangst (deels) zijn geleverd, en of die mails al verstuurd zijn. Met de winkelinstelling RecAutoSendCustOrdMail worden ze automatisch verzonden. Anders blijven ze klaarstaan om later te versturen via POST /api/mails/{id}/Send. De instelling MailCOFulfilled bepaalt of er voor een deels geleverde order een mail wordt aangemaakt.

Voorbeeld: Request

POST /api/receivings/4821/Process

{ }

Response

{

"mailIds": [ 9001, 9002 ], // nieuw: aangemaakte mails voor de klantorders

"mailsSent": false // nieuw: false, want RecAutoSendCustOrdMail staat uit

}

Een mail later alsnog versturen

POST /api/mails/9001/Send

{ } // antwoord: 202 Accepted

CN 79339

Backorders van inkooporders opvragen

In de REST services is het endpoint GET /api/receivings/backorder-purchase-orders toegevoegd. Met de parameter receivingIds is op te vragen welke inkooporders van die ontvangsten nog openstaande backorderregels hebben en dus geannuleerd kunnen worden. Per inkooporder komen onder meer het aantal open en ontvangen regels, de orderdatum, de leverancier en de automatische annulering van de backorder terug.

Voorbeeld: Request

GET /api/receivings/backorder-purchase-orders?storeId=1&receivingIds=4821&receivingIds=4822

Response (deel)

[

{

"receivingId": 4821,

"purchaseOrderId": 61044,

"supplierId": 210,

"openLines": 3, // regels met een openstaande backorder

"linesOrdered": 10,

"linesReceived": 7,

"orderDate": "2026-08-15T00:00:00",

"autoCancelBackOrder": false

}

]

CN 79362

Foutmelding bij te hoge offset of limit op /Search

Wijziging doorgevoerd zodat een te hoge offset of limit op een /Search endpoint wordt teruggemeld op het veld dat daadwerkelijk fout is — Offset respectievelijk Limit — in plaats van op het eerste zoekcriterium (SearchRecords[0].Offset/Limit). Beide velden krijgen nu hun eigen foutmelding, zodat een koppeling of applicatie de melding aan het juiste invoerveld kan koppelen. De bovengrens voor limit is daarbij gelijkgetrokken met het maximum dat al voor de rol gold (10.000), waardoor de melding het werkelijke maximum noemt.

CN 79633

Multi-ontvangstcontrole aanmaken

In de REST services is het endpoint POST /api/receivings/CreateMultiCheckJob toegevoegd. Hiermee kan voor 2 tot 5 niet-verwerkte ontvangsten van dezelfde winkel en leverancier een multi-ontvangstcontrole worden aangemaakt, zodat ze samen op een handheld gecontroleerd kunnen worden. Een ontvangst die al aan een multi-ontvangstcontrole gekoppeld is, kan niet in een nieuwe worden opgenomen.

Voorbeeld: Request

{

"receivingIds": [ 4821, 4822, 4823 ] // 2 tot 5 ontvangsten

}

Response

{

"storeJobId": 71005 // id van de aangemaakte multi-ontvangstcontrole

}

CN 79916

Transaction commit: verwijzing naar kioskbestelling

Wanneer bij POST /api/transactions/Commit in customerOrder een kioskCustomerOrderId wordt meegegeven, wordt de oorspronkelijke kioskbestelling zoals gebruikelijk geannuleerd. Nieuw is dat de aangemaakte klantorder een verwijzing naar die kioskbestelling krijgt, als extension met de key kioskCustomerOrderId. Zo blijft de relatie tussen beide orders achteraf te herleiden.

De verwijzing is op te vragen via GET /api/customer-orders/{id}?expand=Extensions.

Voorbeeld: Request (deel) met de kioskbestelling

{

...

"customerOrder": {

"customerContactId": 123,

"kioskCustomerOrderId": 555 // kioskbestelling die door deze klantorder wordt vervangen

}

}

Response van GET /api/customer-orders/55012?expand=Extensions (deel)

{

"id": 55012,

...

"extensions": [

{

"id": 9001,

"customerOrderId": 55012,

"key": "kioskCustomerOrderId", // nieuw: verwijzing naar de kioskbestelling

"value": "555"

}

]

}

CN 80249

Transaction commit: bezorgadres als losse velden

Bij het aanmaken van een klantorder via POST /api/transactions/Commit wordt het bezorgadres nu als losse velden in customerOrder meegegeven, in plaats van via een verwijzing naar een bestaand adres. Zo kan ook een bezorgadres worden opgegeven dat nog niet bij de klant in ASPOS is vastgelegd. Met deliveryTimePeriod kan daarnaast het gewenste bezorgtijdvak als vrije tekst worden meegegeven.

Let op: de property deliveryAddressId is vervallen. Integraties die deze gebruikten, moeten overstappen op de Delivery_ velden.

Voorbeeld: Request (deel) voor een klantorder die wordt bezorgd

{

...

"customerOrder": {

"customerContactId": 123,

"isDeliveryOrder": true,

"delivery_Name": "J. Jansen", // nieuw: bezorgadres als losse velden

"delivery_Street": "Hoofdstraat",

"delivery_HouseNumber": "12",

"delivery_HouseNumberExtension": "A",

"delivery_PostalCode": "1234 AB",

"delivery_City": "Utrecht",

"delivery_CountryCode": "NL",

"delivery_PhoneNumber": "0612345678",

"deliveryTimePeriod": "Avond" // nieuw: gewenst bezorgtijdvak

}

}

CN 80289

Redencodes uniek in de hele omgeving

Wijziging doorgevoerd zodat een reasoncode binnen de hele omgeving maar één keer kan voorkomen. Voorheen keek de controle op een dubbele code alleen naar de eigen winkel en de winkels daarboven. Daardoor kon het hoofdkantoor — of een winkel in een andere tak — een code aanmaken of hernoemen die een onderliggende winkel al gebruikte. Op de kassa leverde dat problemen op bij artikelen met kitgroepen: de scancode kon niet meer worden herleid. De code moet nu uniek zijn in de volledige winkelboom, ongeacht het soort reasoncode en ongeacht hoofd- of kleine letters. Bij een dubbele code volgt de melding dat de code al in gebruik is. Let op: de bestaande code kan bij een winkel liggen die je zelf niet ziet — de melding noemt niet welke winkel dat is.

CN 80406