API calls getBranchInformation, savePurchaseOrderV2, savePurchaseDeliveryV2 uitgebreid ter voorbereiding op online functionaliteit voor inkoop-orders met betrekking tot het opvragen en doorgeven van ontvangstadres gegevens
Voor api call savePurchaseOrder en savePurchaseOrderV2 is er een nieuwe instelling 'Inkoopopdracht datum controle op vandaag of in de toekomst' . Als deze instelling actief is kunnen alleen inkoopopdrachten worden opgeslagen met een opdrachtdatum van vandaag of in de toekomst
Api getSubTableList: het medewerker-nummer en naam zijn nu toegevoegd aan het resultaat van de api call getSubTableList
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 in de response van de API call adjustPoints het nieuwe puntsaldo is opgenomen in plaats van het saldo van voor de wijziging
API: Snelheid van het openen van de tafellijst gettable (in online) verbeterd
Probleem met deze API versie: Subtafels verdwijnen direct na toevoegen in online handheld.
Zit bug in Kolom niet gevonden: ext_ext_payment_id
Opgelost dat het updaten van een artikel btw-code er voor kon zorgen dat de API een SQL foutmelding teruggaf, indien er geen brutoprijs was ingesteld op het artikel en er gebruik werd gemaakt van de verkoopprijs. Deze fout kon optreden bij alle formule velden die opnieuw berekend moesten worden omdat een refererend veld veranderd werd en er uit de formule geen waarde kwam.
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.
Drie nieuwe idempotente API calls toegevoegd welke gebruikt kunnen worden om verkoop objecten te processen. Dit houdt in dat; voucher scans, menu's, prijsbepaling, sales & acties en het contracten systeem doorgelopen worden op het meegegeven verkoop object.
De request objecten hebben ook een processorContext property. Indien daar dryRun op false staat, kunnen deze calls ook gebrukt worden om het desbetreffende verkoop object gelijk op te slaan. Deze calls kunnen dus gebruikt worden i.p.v. de combinatie van determinePricing en saveInvoice/saveProposal/createOrderV3/updateOrderV2.
getTableOrderV3 uitgebreid met de optie forceCondensedLines. Deze optie negeert de eventuele uncondensedLines optie en wat er in de Q-line qua verdichting staat ingesteld. De teruggegeven regels (ns__Line) bevatten nu ook een uncondensedLines lijst. Dit zijn de regels waarop de verdichte regels gebaseerd zijn.
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.placeTableOrder heeft request parameter releaseTable er bij gekregen, als deze wordt weggelaten is deze true zodat oude gedrag in stand blijft.
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.
updateLastTableActionTime toegevoegd aan de tableProperties van changeTableProperty. Indien updateLastTableActionTime true is zal changeTableProperty de laatste handeling van de tafel updaten zodat de tafelstatus kleur van oranje naar groen gaat.
Het is nu mogelijk om een kastelling uit te voeren via de API. Hiervoor zijn twee nieuwe API-calls beschikbaar:
getCashCountInfo: Retourneert alle benodigde informatie voor het uitvoeren van een kastelling op basis van de opgegeven bronwerkplek en het medewerkernummer.saveCashCount: Registreert de kastelling op basis van de gegevens verkregen via getCashCountInfo. Hierbij wordt verwacht dat een werkplek uit de getCashCountInfo-respons wordt gekozen, de betaalwijzen worden samengevoegd en de getelde bedragen worden ingevuld. Indien er een storting plaatsvindt, moet ook de bestemming van de storting worden opgegeven.Het interfiliale planningsalgoritme dat door de RunnerApp gebruikt wordt is nu ook via de API aan te roepen via de nieuwe call runInterbranchPlanner.
Dit is ook voorbereiding op het kunnen integreren van de RunnerApp in de mpluskassa.online suite.
Nieuwe API call setArticleRecalled toegevoegd. Hiermee kan een artikel teruggeroepen worden, of een terugroeping ongedaan gemaakt worden.
recalled veld toegevoegd aan getOverview voor producten. Geeft een JSON structuur terug indien het product teruggeroepen is.
Formaat:
{
"reason": "Test reden",
"recalledOn": "2025-02-28T10:01:54.271711"
}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.
Nieuwe getFloorplans API call toegevoegd. Deze API call geeft alle tafelplattegronden terug voor het meegegeven filiaal, inclusief of ze momenteel actief zijn, en alle bijhorende wijken. De tafelplattegrond definities worden in JSON formaat teruggestuurd.
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.De response van GetInvoices en GetReceipts (en GetInvoice en GetReceipt) is uitgebreid met de verkoopcategorie informatie.
getTableOrderV3 had al een optie om de opgevraagde tafel ook te claimen, maar je kunt nu ook een bestaande claim overschrijven via '<claimMethod>FORCE</claimMethod>'.
Via sendWebhook kun je nu ook de events startSession, pauseSession, resumeSession, and cancelSession versturen.
getPackingSlips geeft nu ook proposalId, extProposalId, proposalNumber terug als de pakbon is gemaakt op basis van een order welke gemaakt is op basis van een offerte.getInvoices resultaat toevoegingen:
orderNumberspackingSlipIds, packingSlipNumbers indien de factuur gemaakt is op basis van één of meerdere pakbonnen.proposalIds, extProposalIds, proposalNumbers iendien de factuur gemaakt is op basis van een offerte, of op basis van een pakbon die gemaakt is op basis van een order welke gemaakt is op basis van een offerte.getProposals resultaat toevoegingen:
orderNumberpackingSlipIds, packingSlipNumbers indien er op basis van de offerte een order is gemaakt waarvan weer pakbonnen zijn gemaakt.invoiceIds, extInvoiceIds, invoiceNumbers indien er op basis van de offerte een factuur is gemaakt, of er op basis van de offerte een order is gemaakt waarvan weer pakbonnen zijn gemaakt waarvan weer facturen zijn gemaakt.getOrders resultaat toevoegingen:
invoiceNumberspackingSlipIds, packingSlipNumbers indien er op basis van de order pakbonnen zijn gemaakt.proposalId, extProposalId, proposalNumber indien de order op basis van een offerte is gemaakt.Daarnaast opgelost dat een pakbon/factuur soms geen order informatie terug gaf, en vice versa.
Nieuwe API-call getPrintLayoutMarkup waarmee je een printlayout kunt genereren in een bepaalde opmaak. Momenteel wordt enkel nog de Star Document Markup ondersteund.
getOverview ondersteunt nu ook de filter operators BIGGER_OR_EQUAL en SMALLER_OR_EQUAL.
getReceipts retourneert nu ook evt. tableNumber/tableSubNumber. Ook kun je nu direct op basis van specifieke receiptIds opvragen.
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.
getOverview heeft nu ondersteuning voor filiaal_brutoprijs en filiaal_verkoopprijs. Hiervoor moet branchNumber in de request ook ingevuld zijn.
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.
De determinePricing call geeft nu ook priceExcl, discountAmountExcl en amountExcl terug.
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.
De API calls getOrders, getInvoices, getPackingSlips, getProposals en getReceipts zijn efficiënter geworden. Vooral getOrders en getInvoices zijn aanzienlijk sneller indien er heel veel verkoopobjecten teruggegeven worden.
Als de functie savePurchaseOrderV2 tijdens de verwerking tijdens een fout aan loopt in een van de aangeleverde opdrachtregels, dan wordt in de response nu aangegeven op welke regel het probleem zich heeft voorgedaan, samen met andere nuttige informatie.
getTableOrderV3 controleert nu niet meer of het werkplektype mobiel is.
Als je via de API een tafel claimt, dan wordt de claim nu ook daadwerkelijk bij alle andere werkplekken verwijderd.
De API retourneert nu ook webhookConsumerId bij de lineAdditions, lineChanges, en lineDeletions, zodat je weet welke webhook-koppeling de regels heeft aangeleverd.
Optimalisatie van getOverview doorgevoerd, waardoor filters op categorie veel sneller zijn geworden.
Versnelt het ophalen van:
Opgelost dat API geen requests meer kon afhandelen nadat een verloren verbinding succesvol opnieuw opgezet werd.
Opgelost dat in een API call maximaal 100.000 regels in een elementlijst kan worden doorgegeven. Maximum verhoogd tot 2.147.483.647 (max.voor 32bits gehele getallen)
Opgelost dat getPaymentMethods en getPaymentMethodsV2 een SQL error konden geven indien de cadeaukaarten ook opgevraagd werden.
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.
saveSalesRepeatTemplate ondersteunt nu ook yearlyDateMonth en yearlyDateDay, tevens zijn die velden nu optioneel, wat ze al hoorden te zijn.
Opgelost dat de entryTimestamp van betalingen die de getInvoices, getOrders en getReceipts teruggaven niet juist waren.
Opgelost dat getTableOrderV3 geforceerd niet samenvoegen een hogere prioriteit gaf dan geforceerd wel samenvoegen.
Opgelost dat als een artikel terugroepactie ongedaan gemaakt is d.m.v. setArticleRecalled, de getOverview aanroep alsnog de vorige terugroepactie teruggaf.
Opgelost dat het mogelijk was om een al teruggeroepen artikel nogmaals terug te roepen d.m.v. de setArticleRecalled API functie. De API kan nu één van de volgende foutmeldingen teruggeven: SET-ARTICLE-RECALLED-FAILED-ALREADY-RECALLED of SET-ARTICLE-RECALLED-FAILED-NOT-YET-RECALLED.
Opgelost dat getConfiguration de keukenmanagement instellingen potentieel dubbel teruggaf. De group was dan de ene keer "Keukenmanagment" en de andere keer "keukenmanagment". Nu is dit altijd met kleine letters. Dit had tot gevolg dat onder andere de narrowcasting schermen de instellingen niet goed kon inlezen.
Geheugenlekken verholpen in:
Opgelost dat de webhooks ten onrechte een INVALID_APPLY_TO_QUANTITY error gaven met een session.line.id die niet in de response zat. Dit gebeurde voor negatieve regels in de session.
Opgelost dat o.a. updateOrderV2 er in een specifiek scenario er voor kon zorgen dat een regel ten onrechte verwijderd werd.
Verhelpt de foutmelding: "This order is currently being paid on terminal ..." vanuit de determinePricing call.
Probleem uit v59.8.8 opgelost, het is weer mogelijk om een externalPayment-flow uit te voeren via de API.
Opgelost dat samengestelde componenten in het resultaat van getReceipts LINE-TYPE-NONE hadden i.p.v. LINE-TYPE-COMPONENT.
Als je een lege regeltekst (line.text) meegeeft aan registerGiftcardPayment(v2), dan wordt deze nu niet meer gebruikt om de artikelnaam te overschrijven. Dit lost het probleem op van lege tekstregels op deze bonnen.
Opgelost dat PNG/JPEG renderen van een print lay-out niet meer werkte via de API call getRenderedPrintLayout.
Het veld payment.externalPaymentId wordt nu ook daadwerkelijk ingevuld bij het opvragen van kassabonnen, bestellingen, etc.
Als je meerdere webhooks hebt geconfigureerd die naar scanCode luisteren, maar de eerste heeft een pattern filter waardoor het event niet wordt doorgestuurd, dan krijg je nu niet meer de lege response van die eerste webhook terug via de API.
Fix voor placeTableOrder wanneer deze door de kiosk werd gebruikt op een filiaal waar geen tafelplatttegrond gekoppeld is gaf de call de volgende foutmelding:
A supplied branch number does not exist in the database
ERROR: insert or update on table "tafel_data_plattegrond" violates foreign key constraint "tafel_dataplattegrondfiliaal_nr_plattegrond_nr_fkey"
DETAIL: Key (filiaal_nr, plattegrond_nr)=(4, 0) is not present in table "tafel_plattegrond".
De getEmployeeAuthorizationSyncMarkers call houdt nu bij het bepalen van de authGroepRechtenSyncMarker en authGroepSyncMarker ook rekening met de gekoppelde filiaalgroep-autorisatiegroepnummers van de medewerker.
Opgelost dat bij een IDEMPOTENCY_RESULT_REPLAY_RESPONSE response, de methoden placeTableOrder, createInvoiceFromPackingSlips en payOrderV2 niet correct de voucherIssuances en unappliedVoucherIssuances terug gaven zoals bij de oorspronkelijke aanroep.
Het is niet langer mogelijk om payOrder(V2) te gebruiken voor het afrekenen van tafelbestellingen. Gebruik in plaats daarvan payTableOrderV2 of placeTableOrder. Deze wijziging voorkomt tevens een SQL-fout die optrad wanneer payOrder(V2) werd gebruikt bij een tafelbestelling zonder gekoppelde relatie.
De API gaf onterecht de waarde 3 terug in plaats van YEAR in het geval van bpeConfiguration.budgetPeriod.
Opgelost dat o.a. getOrders in het resultaat nooit discountAmountExcl invult.
Probleem opgelost waarbij placeTableOrder een gescande voucher niet toepaste, ondanks dat determinePricing dit wel deed.
Opgelost dat wanneer je met determinePricing of placeTableOrder een menu samenstelt via de velden menuId en menuLinesId, bij succesvolle creatie van het menu de oorspronkelijke tempId niet werd teruggegeven op het nieuwe menu hoofdartikel.
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.
getOrderHistory kon een foute query genereren, wat de volgende foutmelding in de API veroorzaakte:
> trailing junk after parameter at or near
De API stuurt nu altijd het webhook scanCode object door, ook als de scannedCode leeg is, op die manier is het consistent met de Q-line.
De API zal nu minder vaak de melding input is too large for an __int64 geven bij het inlezen van orders, bestellingen, kassabonnen, facturen, etc.
Opgelost dat getOverview een SQL error kon veroorzaken, wanneer er gebruik wordt gemaakt van een sortOrder.
Probleem opgelost dat je in sommige gevallen geen inkoopopdrachten of inkoopleveringen via de API meer kon aanmaken.
Fix voor de melding "502 Bad Gateway" die voor kon komen bij de API calls voor saveInvoice en creditInvoice.
getSubTableList geeft nu ook claimedBy terug en houdt rekening met het actuele subtafel aantal. Daarnaast worden tafels niet meer teruggegeven als ze puur alleen standaard waardes bevatten, daar is getMainTableList voor bedoeld.
Het opslaan/aanmaken van een order d.m.v. de API respecteert nu de aangegeven sequenceNumber om de volgorde van de regels te bepalen.
Bij het aanmaken van een factuur op basis van een order, bijv. bij deliverOrderV2, wordt de kredietlimiet van de relatie nu pas gecontroleerd nadat evt. aanbetalingen verrekend zijn. Als de gehele order immers al aanbetaald was, zal het krediet van de relatie niet wijzigen.
Mocht de kredietlimiet alsnog overschreden worden, dan volgt er nu een duidelijkere terugkoppeling in de errorMessage.
Opgelost dat als een artikel gedeeltelijk van een tafel wordt afgesplitst, en datzelfde artikel daarvoor ook al eens gedeeltelijk was afgesplitst op diezelfde tafel, de daarbijhorende keukenscherm maakbonnen niet worden geüpdate.
Opgelost dat getOverview een SQL foutmelding kon geven.
ERROR: syntax error at or near ANDcolumn reference nr is ambiguoussaveSalesRepeatTemplate gedrag aangepast, als er een regelid meegegeven wordt zal die regel aangepast worden. Als er een bepaalde regel niet meer meegegeven wordt, zal die verwijderd worden. Als je een nieuwe regel meegeeft zonder id zal die toegevoegd worden.
cancelOrderV2 kan nu ook een geannuleerde order weer niet geannuleerd maken. Dit werkt alleen voor niet-filiaalorders.
Opgelost dat getPurchaseDeliveries de volgende foutmelding gaf:
ERROR: missing FROM-clause entry for table "artikel"