MplusQService API: Opgelost dat voor updateProduct de update van prijsgroep informatie correct wordt uitgevoerd (en tevens voor salesprijzen)
API calls getBranchInformation, savePurchaseOrderV2, savePurchaseDeliveryV2 uitgebreid ter voorbereiding op online functionaliteit voor inkoop-orders met betrekking tot het opvragen en doorgeven van ontvangstadres gegevens
Opgelost dat Api call getfinancialjournal de btw specificatie ook doorgeeft als voor een omzetgroep het verkoopbedrag 0 is en het inkoopbedrag hoger is dan 0
API: Incidenteel een afrondingsfout in de berekening voor totaalincl bedragen van een (bon)regel bij percentage korting en volledig spaarpunten verzilveren
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 er een duidelijkere foutmelding wordt geretourneerd als CreateRelation wordt aangeroepen op een API die een slave db connectie heeft. (Dit wordt alleen ondersteund voor API's met een master-db connectie)
Opgelost dat in de response van de API call adjustPoints het nieuwe puntsaldo is opgenomen in plaats van het saldo van voor de wijziging
MplusQAPIService: Extra filters voor call getSalesRepeatTemplates. Er kan nu ook op specifieke 'template-ids' en/of template types (ORDER/FACTUUR) gefilterd worden
API: Snelheid van het openen van de tafellijst gettable (in online) verbeterd
Opgelost dat API call getRenderedPrintLayout bij het opvragen van de afdruk van meer dan een factuur de juiste factuurinformatie voor alle facturen oplevert.
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.
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.
Nieuwe API call toegevoegd printPrintLayout om een print lay-out naar een printer te sturen die aan de Q-line gekoppeld staat. De printer en print lay-out combinaties van Beheer - Instellingen - Print lay-outs toewijzen worden hiervoor gehanteerd.
getOverview heeft nu ondersteuning voor filiaal_brutoprijs en filiaal_verkoopprijs. Hiervoor moet branchNumber in de request ook ingevuld zijn.
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.
Er is nu een releaseTableV2 die aangeroepen kan worden zonder geregistreerde terminal.
De functie getEmployeeAuthorizationSyncMarkers heeft nu ook een employeeBranchGroupSyncMarker die wijzigt als er een filiaalgroep aan de desbetreffende medewerker wordt gekoppeld of ontkoppeld. Tevens wordt nu ook direct de desbetreffende employeeSyncMarker geretourneerd.
Je kunt nu de branchGroupSyncMarker opvragen met getCurrentSyncMarkersV2.
Alle releasenotes van API v59.5.2.
API calls houden nu rekening met relatie budgetten.
De API call getPrintLayouts is nu aan te roepen met een extra fieldType filter om enkel layouts in te lezen die een bepaald veldtype bevatten.
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.
Api call getOrderChanges : Er is opgelost dat als er alleen een syncmarker in de request aanwezig is, en de lijst van dus ordertypes leeg is, dat dan de wijzigingen van alle ordertypes in de response wordt doorgegeven in plaats van alleen die van verkoop-, herhaal-, en externe-orders.
De properties dialog.dialogIdAsString en dialog.options[].optionIdAsString worden nu ook geserialized in de idempotency opslag.
Contractregels ondersteuning toegevoegd.
determineContractLines call toegevoegd die de contractregels teruggeeft op basis van de meegegeven regels.determineContractLines kan doorgegeven aan API calls die een LineList verwachten.getOrders, getReceipts, getPackingSlips, getProposals, getInvoices geven nu allemaal ook de opgeslagen contractregels terug.getSalesRepeatTemplates heeft nu een contractFrequencyFilter om specifieke contracten op te vragen. In het resultaat staat ook een contractFrequency.createOrder(V2) en saveOrder vullen automatisch de contractLines in indien die nog niet ingevuld waren.getOrderCategories geeft nu ook de categorie afhankelijkheden terug via orderCategoryDependencyNumbers.
Aanmaken/bewerken van orders geeft nu het volgende bericht terug als het niet mag i.v.m. afhankelijkheden van de orderCategoryNumber:
Invalid orderCategoryNumber supplied. Ensure that the category exists, and that the category is either dependent on the current category, or that it, AND the current category have no dependencies.Daarnaast worden ook de wijzig autorisaties van die categorieën gecontroleerd.
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.
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.
getWebhookConsumers kan nu aangeroepen worden met een syncMarker en retourneert nu ook:
De functie determinePricing retourneert nu ook de opgestuurde webhookData.
getNutritionalCharacteristicsRequest ondersteund nu combinatie van syncMarker en numbers filter.
Voorheen retourneerde zo'n request de data voor alle gevraagde nummers, nu is deze data ook werkelijk gefilterd op syncMarker en het antwoordt bevat ook de syncMarkers.
Verhelpt dat de API een soapfault geeft als je getOverview een INCOLLECTION filter geeft met een lege lijst.
Database error on the server. Please contact API support at dev@mpluskassa.nl.
ERROR: syntax error at or near ")"
LINE 1: ...rds FROM public.relatie a WHERE TRUE AND a.nr IN() AND (a.... ^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.
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 ambiguouscancelOrderV2 kan nu ook een geannuleerde order weer niet geannuleerd maken. Dit werkt alleen voor niet-filiaalorders.
saveSalesRepeatTemplate 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.
Opgelost dat getPurchaseDeliveries de volgende foutmelding gaf:
ERROR: missing FROM-clause entry for table "artikel"Opgelost dat het mogelijk was dat updateOrderV2 soms een kortingspercentage niet toepast omdat er ook een automatische korting toegepast kon worden.
Opgelost dat determinePricing het meegegeven kortingspercentage niet toepast als er onderwater automatisch een prijsgroep toegepast wordt.
Databasefout in de API opgelost bij het uitvoeren van getNutritionalCharacteristics voor een relatie.
Databasefout in de API opgelost bij het uitvoeren van getNutritionalCharacteristics voor een relatie.
Een BoostAssertionException opgelost die kon optreden als je een inkoopopdracht of inkooplevering bewerkte zónder een aritkeluitvoering te specificeren.
getArticlesVariants is nu aanzienlijk sneller
Probleem opgelost waardoor het niet meer mogelijk was verkooporders af te drukken.
Diverse verbeteringen aan opslaan van inkoopopdrachten en levering
De API call getRenderedPrintLayout kon crashen als je geen printInfo meegaf.
De API call createInvoiceFromPackingSlipsRequest keurde een lege forcedActivityId altijd af, ook al is die parameter optioneel.
Opgelost dat getSubTableList ook tafeldata van andere filialen terug kon geven.
Het oude menu systeem houdt nu ook rekening met SUP artikelen op het hoofdartikel van menu's. Het nieuwe menu systeem hield hier al rekening mee. Lost vreemde situatie op in de api. Neem bijvoorbeeld de volgende situatie:
saveTableOrderV2 met een menuartikel. Oude menu systeem voegt automatisch hoofdartikel toe. Hoofdartikel hoort normaal gesproken ook een SUP toeslag subartikel te krijgen. Dit wordt nu niet gedaan.getTableOrderV2 om de order zoals die op de tafel staat op te vragen.payTableOrderV2 om deze order af te rekenen. De api geeft terug dat de VerkoopPrijsIncl niet overeen komt, omdat payTableOrderV2 door heeft dat het SUP toeslag subartikel mist, en dit automatisch toevoegt aan de regels die zijn meegegeven. Echter komt dat dus niet meer overeen met wat er op de tafel staat.