Api createOrderV3 Verbetering van de controle op ordertype en de invoer van een tafel en subtafel nummer: 1) Voor ordertype 'TABLE-ORDER' moet het tafelnummer worden doorgegeven. 2) Een tafelnummer mag alleen worden doorgegeven als het ordertype 'TABLE-ORDER' is.
Opgelost dat bij saveInvoice het veld 'workplacenumber' daadwerkelijk wordt gebruikt om de factuur op de juiste werkplek te registreren
Opgelost dat de totaalbedragen van savePurchaseDelivery en savePurchaseOrder onjuist waren wanneer er gebruik werd gemaakt van verpakkingen, vooral bij geneste verpakkingsstructuren.
createOrderV3 kan nu ook direct betalingen verwerken, zoals payOrderV2. Het voordeel is dat alles in zijn geheel verwerkt wordt, of in zijn geheel niet.
De getOverview call heeft er een optie bijgekregen om filters caseSensitive toe te passen (standaardgedrag is dat dat niet gebeurd).
De getOverview call heeft er twee filter operators bijgekregen: ISEMPTY (waarde mag NULL of lengte 0 zijn) en ISNOTEMPTY (precies het tegenovergestelde).
Het ns__Relation object bevat nu naast cardNumber, ook cardNumbers welke alle pasnummers van de relatie bevat. getRelation,getRelations, createRelation en updateRelation houden hier rekening mee.
Daarnaast heeft getOverview nu een virtueel selectFieldNameList genaamd card_numbers welke de pasnummers als JSON array teruggeeft. Tenslotte ondersteunt de filterList van getOverview nu ook de CONTAINS, OVERLAP, IS, OVERLAPORNONE operators voor het pasnummer veld. De EQUAL operator wordt op het pasnummer veld onderwater automatisch geinterpreteerd als OVERLAP.
Je kunt een interfiliale opdracht, verzending of ontvangst nu ook voorzien van een scancode. Dat kan bijv. een barcode zijn, of een QR-code, of zelfs een NFC-tag. Met behulp van die scancode kun je het desbetreffende item direct openen.
Nieuwe call updateInterbranchOrder toegevoegd, getInterbranchOrders heeft extra filters gekregen, en shipInterbranchOrder ondersteunt nu deelzendingen.
getOverview houdt nu rekening met de eventuele filiaalspecifieke THT datum in het geval dat scopeValues ingevuld is. (oldest_best_before_date)getArticleBranchDeviations en saveArticleBranchDeviations ondersteunen nu beide de THT datum.Twee nieuwe calls getSpecialBarcodePatterns en parseSpecialBarcode. parseSpecialBarcode test of een barcode bijvoorbeeld een prijsbarcode is en retourneerd dan welk artikel en prijs. De getSpecialBarcodePatterns retourneerd een lijst van reguliere expressies waarmee getest kan worden of het zin heeft om parseSpecialBarcode aan te roepen.
Letop dat je bij het gebruik van de reguliere expressies zorgt dat deze de hele string moet matchen en niet een substring. Eventueel kun je de expressies natuurlijk ook uitbreiden met regel start en eind of witruimte voor en achter afhankelijk van hoe hij precies gebruikt gaat worden.
De calls getOrders, getReceipts, getInvoices, getProposals, getPackingSlips en getSalesRepeatTemplates ondersteunen nu de nieuwe includeLineList optie. Deze optie maakt het mogelijk om verkoopobjecten aanzienlijk sneller op te vragen.
Daarnaast wordt de relatie filter nu toegepast op hetzelfde niveau als de syncMarker filter. Dit betekent dat wanneer je bijvoorbeeld een syncMarkerLimit van 100 instelt in combinatie met een relatie filter, je de eerste 100 verkoopobjecten voor die specifieke relatie terugkrijgt. Voorheen werden eerst 100 verkoopobjecten geselecteerd en pas daarna gefilterd op relatie.
Het is nu mogelijk om keukenbonnen van tafels te snoozen d.m.v. de API functie ChangeTableProperty.
Nieuwe API call getCardFilterOptions toegevoegd. Deze API call kan voor een bepaalde kaart (zoals bijv. artikelen) teruggeven wat de filter opties zijn per opgevraagd veld.
determinePricing geeft nu ook lineId en tempLineId terug. Dat is de identificatie voor de regels die door de kassa gemaakt zijn. Als het een al opgeslagen regel is, wordt er een lineId teruggegeven, anders wordt er een tijdelijke identificatie van de regel teruggegeven tempLineId. Het gedrag van de oorspronkelijke tempId die zelf meegegeven kan worden aan determinePricing blijft hetzelfde.
Twee API calls toegevoegd voor het nieuwe dynamische min/max voorraad systeem.
updateArticleDynamicMinMaxStock om een berekende dynamisch min/max in te schieten op een bepaald filiaal, voor een bepaald artikelen en voor een vanaf datum/tijd.getArticleDynamicMinMaxStock om de berekende dynamische min/max voorraad in te lezen voor een bepaalde periode. Hier zijn een aantal filters op toe te passen.redeemVoucherIssuance API call toegevoegd die een bepaalde voucher direct kan verzilveren, dit kan momenteel alleen voor ENTREE voucher uitgiftes.
getRedeemableVoucherIssuances API call toegevoegd die voor een bepaalde voucher type teruggeeft hoevaak welke voucher uitgiftes te verzilveren zijn op de opgevraagde datum.
getPaymentMethodsV2 en getAvailablePaymentMethodsV2 retourneren nu optioneel (als je includeGiftcardType meegeeft), ook bij welk giftcardType ze horen.
getSalesRepeatTemplates heeft nu ook een branchNumbers filter gekregen, en geeft nu ook discountAmountIncl en discountAmountExcl terug op de regels.
De volgende API calls hebben nu een ownerFilter en branchGroupFilter gekregen:
getInvoicesgetProposalsgetOrdersgetPackingSlipsgetSalesRepeatTemplatessourceSalesTurnoverLineId en startDate toegevoegd aan de regels die teruggegeven worden in de getSalesRepeatTemplates call.
issueVouchers API call toegevoegd om directe voucher uitgiftes te doen. Normaalgesproken worden vouchers (ook in de API) uitgegeven door bijvoorbeeld facturen, of andere omzet te maken. Echter hoef je voor deze call niet expliciet omzet te maken, de call doet dit onderwater zelf. Per uit te geven voucher is mee te geven welke scancode en welke groepsscancode de voucher zal moeten gebruiken.
Voucher calls toegevoegd om de scancodes van een voucher te beheren. De voucher moet als externe voucher ingesteld zijn, specifiek voor jouw koppeling.
issueVoucherExternalScanCodes: Met deze call kunnen scancodes ingeschoten worden. Als de voucher dan uitgegeven wordt zal automatisch één van die scancodes gebruikt worden. Indien er geen scancodes meer zijn zal het uitgeven van de voucher geblokkeerd worden.getVoucherExternalScanCodes: Met deze call zijn de al ingeschoten scancodes op te vragen voor de voucher.Daarnaast is de getVouchers call uitgebreid met twee nieuwe filters. Er is nu op voucher type te filteren, en op externalIdent. Op die manier zijn de vouchers te vinden die door jouw koppeling te beheren zijn.
Opgelost dat getRelations, getProducts en getEmployees veel trager waren sinds versie 59.4.0
Bij het opvragen van getGiftcardTypes wordt nu ook het maximum saldo (maximumBalance) teruggegeven.
Naar aanleiding van dat webhook configuratie nu op de master opgeslagen wordt en ondersteuning heeft voor filiaalgroepen, veriest getWebhookConsumers nu dat er een werkplek meegestuurd wordt.
Per API call kan nu beter gespecificeerd worden of die: (1) altijd naar de master moet, of (2) naar de slave indien bijv. een bepaald branchNumber in de request gebruikt wordt.
De API calls getRedeemableVoucherIssuances en redeemVoucherIssuance zijn nu ook op een slave API aan te roepen, indien de Voucher verzilveringen mogen doen zonder master verbinding instelling aan staat.
Verbeterde controles in saveArticleAlterationsGroup voor alteration groups van het type MENU. Elke alteration moet een artikel hebben en de artikelen moeten uniek zijn binnen de groep.
Opgelost dat getOverview kaarten onterecht niet terug gaf indien de OVERLAPORNONE modus werd gebruikt en de kaart wel één of meerdere van de opgegeven fieldValue waarden bevatte, maar niet allemaal.
Opgelost dat bij savePurchaseDelivery altijd een deliveredQuantity moest worden opgegeven, zelfs wanneer er een quantityOfPackagesDelivered was opgegeven.
Opgelost dat savePurchaseDelivery onjuiste aantallen per regel opsloeg wanneer er gebruik werd gemaakt van een verpakkingsstructuur met meerdere niveaus (bijvoorbeeld: stuks → zakje → doos).
getOrders, getReceipts, getInvoices, getPackingSlips en getProposals vullen nu ook bpeAccordationEmployeeNumber in.
De filter operators ISNULL and ISNOTNULL van de getOverview calls werken nu daadwerkelijk.
getOrderChanges en getOrderHistory zijn nu aanzienlijk sneller op grote databases.
Bij getOrders wordt nu ook de deliveryMethod ingevuld.
Opgelost dat o.a. updateOrderV2 er in een specifiek scenario er voor kon zorgen dat een regel ten onrechte verwijderd werd.
Opgelost dat PNG/JPEG renderen van een print lay-out niet meer werkte via de API call getRenderedPrintLayout.
Probleem opgelost waarbij placeTableOrder een gescande voucher niet toepaste, ondanks dat determinePricing dit wel deed.
Wanneer aan determinePricing een vouchergroepsscancode werd meegegeven, en die groep meerdere voucheruitgiftes bevatte die gebaseerd waren op dezelfde voucher, kon het voorkomen dat:
Dit probleem is nu verholpen, zodat elke artikelregel correct wordt gekoppeld aan de juiste voucheruitgifte.
Opgelost dat als determinePricing een gescande voucher uitgifte code meekrijgt, en het toe te voegen artikel al op de bon staat, en al verzilverd is d.m.v. de gescande voucher uitgifte code, het artikel nogmaals werd toegevoegd.
De call deliverOrderV2 kan nu ook negatieve regels leveren. Voorheen kwamen deze niet op de pakbon, als ze wel meegegeven waren.
v1.9.0 // © Mplus Software 2014 - 2025