Nieuwe call getBranchInformation voor het ophalen van stamgegevens van filialen.
placeTableOrder ondersteunt nu het automatisch proberen te maken van menu's voor het nieuwe menu systeem. Wel moet daarvoor automaticNewMenus aangezet worden, wat standaard uit staat. Aangeraden is om dit niet te gebruiken, maar menuId en menuLinesId te zetten op de regels.
Voor Android Handheld
forcedActivityId toegevoegd aan de CreateInvoiceFromPackingSlips request. De aangegeven activiteit id zal gebruikt worden indien er pakbonnen zijn opgegeven met verschillende activiteiten. Dit werkt alleen als de nieuwe instelling aan staat.
Verzamelfactuur kunnen maken van pakbonnen met verschillende activiteitenisSupplierGroup toegevoegd aan ns__CardCategorie. Hiermee geeft getCardCategories nu terug of het om een leverancier relatie categorie gaat.
createRelation en updateRelation ondersteunen nu beide branchesNonPurchasable.
findRelationV2, getRelation en getRelations geven nu allemaal branchesNonPurchasable terug. Dit zijn de filialen waarop geen artikelen besteld mogen worden van deze leverancier.
getReceipts en getInvoices geven nu in hun resultaat terug van welke kassabon/factuur de eventuele creditering gemaakt is.
Zie ns__Receipt::creditedReceiptId en ns__Invoice::creditedInvoiceId
Het is nu mogelijk om met findRelation een relatie te zoeken op custom velden.
Het is nu mogelijk om aan placeTableOrder en andere API calls die een order aanmaken/aanpassen een fooi/toeslag artikel toe te voegen. Het is de bedoeling dat dan alleen het artikelnummer en prijs van de fooi/toeslag ingevuld wordt. De overige regel waarden wordt automatisch door de API ingevuld.
Ondersteuning toegevoegd voor externalDiscount die vanuit een webhook kan worden meegegeven.
Release van API v57.5.0
Nieuwe idempotent API call toegevoegd: registerGiftcardPaymentV2. Het is noodzakelijk om aan deze nieuwe call een lineList op te geven. Het totaalbedrag van alle regels is uiteindelijk de cadeaupas betaling. De call maakt automatisch een kassabon, een transactie en historie aan, om de cadeaupas betaling te verantwoorden.
De oude registerGiftcardPayment call verwacht nu ook een lineList, en zal intern doorverwijzen naar registerGiftcardPaymentV2.
Het is nu mogelijk om via payInvoice en placeTableOrder een cadeaupas betaling te doen. Het is noodzakelijk om een giftcardNumber aan de betaling mee te geven, als je een cadeaupas betaalwijze opgeeft. De cadeaupas betaling zal terechtkomen in het cadeaupassen overzicht.
De setRelationPresence zal nu de melding "Can't move relation to table, the requested table is not empty." terug geven, wanneer de tafel die in de request wordt meegegeven al bezet is door een relatie.
getArticlesVariants geeft nu ook een lijst van leveranciers terug, net zoals getArticleVariants.
Gefixed dat een getupdateV2 call naar de MplusQAPIService de tekstregelposities in de orderregels behoudt
ns__Line bevat nu ook retourReason. Verkooptypen die retourneren ondersteunen vullen in hun calls retourReason in.
getInvoices geeft nu ook onderstaande velden terug:
- orderCategoryNumber
- creditedReason
- sessionIdUpdate 20-8-2024:
In de response van elke API call die een ns__Line teruggeeft, wordt ns__Line::suppressDisposableComponent en ns__Line::tempId weglaten indien ze geen waarde hebben.
Nieuwe idempotente API call toegevoegd: createInvoiceFromPackingSlips. Deze API call kan gebruikt worden om van één of meerdere pakbonnen een factuur te maken.
Het is nu mogelijk om proposalIds of proposalNumbers mee te geven aan getProposals. Daarnaast bevat ns__Proposal nu orderCategoryNumber.
Twee nieuwe API calls: getMainTableList en getSubTableList. De calls kunnen gebruikt worden om een tafellijst op te bouwen, i.p.v. getTableListV3 te gebruiken. getMainTableList geeft de hoofdtafels terug van het meegegeven filiaal met de absolute basis data. getSubTableList geeft alle subtafels terug die afwijken van de standaard met hun specifieke data.
Nieuwe idempotente saveTodoListV2 die een todolijst zowel kan toevoegen (branchNumber, category en name vereist) en als bijwerken (id vereist).
Alle calls die een order retourneren, zoals getOrder(s) of findOrder, bevatten nu ook het "bestelnummer" dat ingevuld wordt door (tafel)bestelbonnen. In de API heet dit veld cateringOrderNumber.
Nieuwe call linkGiftcardsToRelation toegevoegd. Deze call kan gebruikt worden om een of meerdere cadeaupassen aan een relatie te koppelen.
Nieuwe functie payOrderV2.
Deze is functioneel gelijk aan payOrder, maar is idempotent waardoor je kunt garanderen dat de order maar één keer wordt aanbetaald, ook als je de request meerdere keren herhaalt.
Nieuwe functie createOrderV3.
Deze is functioneel gelijk aan createOrderV2, maar is idempotent waardoor je kunt garanderen dat de order maar één keer wordt aangemaakt, ook als je de request meerdere keren herhaalt.
Het is nu mogelijk om met getEmployeeAuthorizationGroups de filiaal en filiaalgroep gekoppelde autorisatiegroepen los op te vragen. Doe dit door de optionele request parameter separateBranchesAndBranchGroups op true te zetten.
Uitbreiding van getArticleVariants. ArticleVariant bevat nu een lijst van leveranciers (suppliers) welke relationNumber, isPreferredSupplier en isPurchasable bevatten.
Fix voor API request PayTableOrderV2: error: You're trying to move more articles than were in the original order.' als sales-en-acties actief is op artikelen
Ondersteuning toegevoegd om via de sendWebhook call ook de startPayment en cancelPayment webhooks te triggeren.
Elke API-call retourneert nu het versienummer van de API in een aparte Mplus-Service-Version response header.
Bijvoorbeeld:
Mplus-Service-Version: 57.2.0.0
Elke API-call retourneert nu het versienummer van de API in een aparte Mplus-Service-Version response header.
Bijvoorbeeld:
Mplus-Service-Version: 56.3.0.0
De volgende API calls hebben nu ondersteuning om op basis van een of meerdere ids of numbers te filteren:
getPackingSlips.packingSlipIds & packingSlipNumbersgetInvoices.invoiceIds & invoiceNumbersgetOrders.orderIds & orderNumbersDe functie createOrderV2 retourneert nu ook het ingevulde order-object bij een filiaalorder (Slave-filiaal) die binnen de "Wachttijd synchronisatie Master naar Slave" verwerkt is, en bij het resultaat CREATE_ORDER_RESULT_EXT_ORDER_ID_ALREADY_EXISTS.
Dit maakt het gedrag van de call weer consistent ongeacht of het filiaal toevallig een Slave is.
De installer update nu automatisch de reeds geinstalleerde versie ook als deze in een afwijkende locatie is geinstalleerd.
Elke API is nu out-of-the-box in staat om tot drie parallele requests af te handelen.
(Voorheen was de standaard één)
Elke API is nu out-of-the-box in staat om tot drie parallele requests af te handelen.
(Voorheen was de standaard één)
De API heeft nu ondersteuning voor opstarten met een --connection, welke verwijst naar een databaseconnectie in %PROGRAMDATA\MplusQ\database.dat. Hierdoor hoeft de API niet meer een apart database.inibestand te hebben.
De placeTableOrder call geoptimaliseerd.
Bij het doorgeven van eftTransactionDetails kan nu ook worden aangegeven dat de betaling betaald is via een offline-modus.
(state = EFT-TRANSACTION-STATE-PAID-OFFLINE)
getFinancialJournal geeft nu ook purchaseAmount terug voor groep types anders dan BPE.
De idempotente calls placeTableOrder en createOrderV3 doen nu geen lock meer op de transactietabel, maar vertrouwen op het retry-mechanisme van de API om bij een evt. conflict de order nogmaals proberen te plaatsen.
Alle idempotente requests hebben nu in principe ondersteuning voor het automatisch herhalen van een request als er tijdens de uitvoer een potentieel gelijktijdigheidsprobleem optreedt.
Dat wil niet automatisch betekenen dat vaker herhalen altijd het probleem zal oplossen.
getConfiguration geeft nu ook per terug, wat aangeeft of de instelling per kassa, filiaal of globaal ingesteld mag worden.
Als er geen credentials worden meegegeven retourneerd de api nu een HTTP Status 401 (was 500).
Dit helpt oa in .NET je kunt dan namelijk de credentials instellen op de client en deze zal wanneer deze de 401 ziet een Authentication header meesturen.
saveInvoice geeft nu ook invoiceNumber en invoiceBarcode terug wanneer je een factuur aanmaakt, niet alleen wanneer je een factuur wijzigt.
getCardCategories houdt nu rekening met eigenaarslabels als het eigenaarslabelssysteem en het filiaalgroepensysteem aan staan.
createImage en createImageFromUrl retourneren nu een aparte resultaatcode CREATE_IMAGE_NOT_SUPPORTED als het uploaden van afbeeldingen via de API überhaupt niet ondersteund wordt, omdat MIS niet aan staat. Zo zien we het sneller in onze online apps.
De call getPackingSlips retourneert nu ook:
packingSlipTypeorderCategoryNrvatMethodsessionIdDe functie placeTableOrder ondersteunt nu ook het doorgeven van een levertijdstip (via deliveryPeriodBegin).
GetBranchGroups API call geeft nu ook per filiaalgroep ownerLabelId terug, als het filiaalgroep een gekoppelde eigenaarslabel heeft.
De functie getAuthorizationTree retourneert nu onlineAuthorizationsVersion en de functie updateOnlineAuthorizationTree accepteert nu onlineAuthorizationsVersion. Op die wijze is snel te controleren of de autorisatieboom up-to-date is.
Opgelost dat getInvoices, getOrders, getPackingSlips, getProposals, getReceipts en getSalesRepeatTemplates deze error konden teruggeven:
Database error on the server. Please contact API support at dev@mpluskassa.nl.Kolom niet gevonden: vor_bw_regelnr
Probleem opgelost waardoor er via de android handheld geen (oude)menu artikelen geboekt konden worden wanneer het menu gebruik maakte van de optie op hoofdartikel boeken.
Foutmelding die dan in api log kwam was deze: msg: QCheckWerkplek(): Bij MplusQservice moet expliciet werkplek meegegeven worden (QGetHuidigeBoekDag())
Opgelost dat splitsen d.m.v. moveTableOrderV3 een SOAP exception gaf als de te splitsen tafel wijzigingen heeft gehad, door bijvoorbeeld meerdere keren artikelen op de tafel te boeken.
Gaf uiteindelijk deze foutmelding:
Het is niet mogelijk om af te splitsen vanwege een verschil.
Split NOT possible, divergent properties: (WijzigingsTeller: 0 <> 1)Probleem opgelost in placeTableOrder als je wel numberOfGuests meegeeft, maar geen lineList.
Veroorzaakt de Foutmelding in api log: SEVERE req: placeTableOrder, exception: EAccessViolationmsg: Access violation at address 00F4D9DA in module 'MplusQservice.exe'. Read of address 00000010 in het api logboek.
Op de handheld krijg je dan te zien: PIN betaling is GELUKT Bijwerken van tafel is mislukt.
Probleem opgelost waardoor getCurrentTableOrders alle orders retourneerde als er geen actieve tafelorders waren. Dit resulteerde bij klanten met veel historie in out of memory errors.
Probleem in de API gefixed voor Online Handheld betalingen in Duitsland (issue met place-tableorder en TSE/Fiscaltrust module)
Fix dat SetRelationPresence ten onrechte de volgende exceptie kon geven:
The request is trying to add duplicate data to the database, please check your inputs
Lost probleem op waardoor de API vooral voor online extra traag kon zijn als de optie "Mag een medewerker op meerdere werkplekken tegelijk ingelogd zijn?" aan stond.
Probleem opgelost waardoor je geen categorieën meer kon bijwerken via createProduct, updateProduct, createRelation, updateRelation, createEmployee en updateEmployee.
getOrders retourneerd nu ook deliveredQuantity en cancelledQuantity
Subtiele raceconditie in IdempotentRequests opgelost waardoor bij de parallel uitvoer van twee identieke requests, de ene request niet goed "zag" dat de andere request al hetzelfde gedaan had.
Daardoor kon de tweede call allerlei verschillende fouten gaan geven omdat de uitvoer dus niet meer mogelijk was.
Er wordt ook in deze situaties nu weer correct teruggevallen op het IdempotentRequest principe, waardoor beide calls exact hetzelfde antwoord geven, zonder foutmeldingen, en zonder dubbele uitvoer.
Verhelpt probleem waardoor getArticlesInLayout tekst bereidingswijze dubbel retourneerde. Deze call wordt door de MplusKASSA Android Bestel App gebruikt.
Opgelost dat placeTableOrder, prepayTableOrderV2, payTableOrder en payTableOrderV2 de volgende foutmelding konden geven als er een receiptFooter werd teruggegeven als antwoord op een completeSession webhook, die niet als blocking was ingesteld:
The request caused a constraint error in the database, most likely some of the data supplied is incorrect.Fix voor raceconditie in setRelationPresence call als er gelijktijdig 2 relaties aangemeld worden bij hetzelfde filiaal was er een kans dat ze hetzelfde tafel nummer toegewezen kregen.
Verhelpt probleem waardoor de API de juiste regels niet kan vinden tijdens het splitsen van een bestelling. Trad op als er spaarpunt attributen van de omzetgroep van het artikel waren gewijzigd.
Verhelpt probleem waardoor de API de juiste regels niet kan vinden tijdens het splitsen van een bestelling. Trad op als er spaarpunt attributen van de omzetgroep van het artikel waren gewijzigd.
Sinds payOrderV2 in v58 is toegevoegd, werkte payOrder niet meer. Dat is bij deze opgelost.
Order.reference is nu niet meer verplicht bij het aanmaken/aanpassen van orders.
Als er ooit een artikel verkocht is met omzetgroep 0, geven de API-functies reportTurnoverByTurnoverGoup, reportTurnoverByArticle en reportBPE nu geen foutmeldingen meer, in plaats daarvan retournerneren ze de standaardwaarde voor omzetgroep.
getRenderedPrintLayout geeft nu een error terug als het om een bon print lay-out gaat, dat als PDF gerenderd dient te worden. Dit is alleen mogelijk voor grafische print lay-outs (A4).
Opgelost dat companyName niet werd opgeslagen met UpdateRelation.
Opgelost dat het aanpassen van een orderregel op een verkooporder er voor zorgt dat na het opslaan alle geleverde aantallen van de verkooporder verdwenen zijn.
Opgelost dat het verplaatsen van een volledige tafel order d.m.v. moveTableOrderV2 en moveTableOrderV3 de volgende foutmelding gaf als er gebruikt werd gemaakt van TSE:
Error on the server. Please contact API support at dev@mpluskassa.nl.
Voorwaarde niet voldaan: Order.VersieNr > 1
Opgelost dat placeTableOrder niet meer TSE-data opstuurde.
Dit lost onder andere het probleem op dat een tafelorder doen en/of betalen met de Android handheld geen TSE-data opstuurt.
Opgelost dat priceType van een determinePricing regel een niet valide waarde bevatte als het om een tekstregel ging.
Bugfix updateProducts ging mis wanneer er alleen een update of een insert gedaan moest worden.
Gaf dan een UPDATE-PRODUCT-RESULT-FAILED in de response.
getOrders error opgelost:
Database error on the server. Please contact API support at dev@mpluskassa.nl.getOrders, getInvoices en getPackingSlips input validatie minder restrictief gemaakt. Het is daardoor nu weer mogelijk om een sync marker en datum filter toe te passen.
Opgelost dat kassabonnen/bestelbonnen niet uitgeprint werden wanneer er gebruik werd gemaakt van het nieuwe print lay-out systeem.
Probleem opgelost als je een order ging opslaan mét deliveryPeriodBegin maar zónder deliveryPeriodEnd.
CreateRelation nieuwe kaartnummer bepaling ging mis
Database connectie herstel werkt weer.
Opgelost dat wanneer met updateArticleGroup d.m.v. sortOrder een artikelgroep naar de één na laatste plek werd gesorteerd, de artikelgroep op de laatste plek terechtkwam.
Opgelost dat het uitvoeren van de getJournals of getFinancialJournal API call een foutmelding gaf.
Database error on the server. Please contact API support at dev@mpluskassa.nl.Foutmelding opgelost als je in een GKS-administratie een tafel volledig wilde verplaatsen.
Het kassaldo en kasverschil dat geretourneerd wordt door reportPrintableFinancialTotals() wordt nu niet meer verborgen, mits de medewerker daarvoor geautoriseerd is.
Als het nieuwe filiaalgroepen systeem aan staat, zal de getCardCategories API call nu op basis van de Mplus-Employee header de kaart categorieën ophalen, i.p.v. op basis van de Mplus-Workplace header.
De functie updateProduct geeft nu ook apart een foutmelding als een opgegeven artikelnummer al bestaat: UPDATE_PRODUCT_RESULT_FAILED_ARTICLE_NUMBER_ALREADY_TAKEN
Lost probleem op waardoor de API vooral voor online extra traag kon zijn als de optie "Mag een medewerker op meerdere werkplekken tegelijk ingelogd zijn?" aan stond.
getOverview geeft nu de juiste minimumprijs terug.
Probleem verholpen met de webhooks (HTTP_PARSING_ERROR).
Sinds een recente update ging de API waar mogelijk ineens onbedoeld proberen te communiceren via HTTP/2. Dit werd echter nog niet goed ondersteund door de rest van onze software. Daarom wordt nu geforceerd dat we altijd HTTP/1.1 gebruiken.
Probleem verholpen met de webhooks (HTTP_PARSING_ERROR).
Sinds een recente update ging de API waar mogelijk ineens onbedoeld proberen te communiceren via HTTP/2. Dit werd echter nog niet goed ondersteund door de rest van onze software. Daarom wordt nu geforceerd dat we altijd HTTP/1.1 gebruiken.
Probleem verholpen met de webhooks (HTTP_PARSING_ERROR).
Sinds een recente update ging de API waar mogelijk ineens onbedoeld proberen te communiceren via HTTP/2. Dit werd echter nog niet goed ondersteund door de rest van onze software. Daarom wordt nu geforceerd dat we altijd HTTP/1.1 gebruiken.