Nieuwe call getBranchInformation voor het ophalen van stamgegevens van filialen.
Alle releasenotes van 58.4.3 zitten hier ook in.
MplusQAPIService: nieuwe API call getOrdersByExtOrderIds: opvragen van orders aan de hand van de externe referentie(s)
bugfix API call 'getordersbyreceiptids'
Het is nu mogelijk om via de nieuwe API call getOrdersByReceipts de ordergegevens op te vragen aan de hand van een lijst van receipt-ids (kassabon-ids)
Error logging uitgebreid voor placetableorder
MplusQAPI: Controle op aanwezigheid en inhoud van het veld 'reference' bij saveProposal en saveInvoice is vervallen
Het ns__Address object bevat nu ook supplierInformation. Dit is informatie voor een specifieke leverancier dat ingevuld kan staan op ontvangstadressen van inkoopopdrachten.
Nieuwe instelling toegevoegd waarmee aangegeven kan worden of het verplicht is om een deliveryAddress in te vullen voor savePurchaseOrderV2.
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.
Het is nu mogelijk om d.m.v. scannedVoucherIssuanceCodes gescande vouchers door te geven aan determinePricing, placeTableOrder, createOrderV2 en createOrderV3. determinePricing geeft in zijn resultaat daarnaast ook nog een lijst terug van scannedVoucherIssuances.
Het is nu mogelijk om voucher uitgifte ingangsdatums aan te geven door pendingVoucherIssuanceStartTs op ns__LineData of ns__PlaceTableOrderLineDataElem in te vullen.
getTableOrderV3 geeft nu ook de voucher uitgifte kandidaten terug in voucherIssuanceCandidates.
Bugfix:getProducts gedrag; customfields: multiselect velden worden doorgestuurd ook als deze voor het artikel/product nog geen waarde hebben.
Het is nu mogelijk om via DeliverOrder en DeliverOrderV2 een kassabon aan te maken, eerder kon alleen maar een factuur aan worden gemaakt.
Het is nu mogelijk dat er automatisch een factuur kan worden afgedrukt nadat een order betaald wordt via de api via de call payorder. Dit is afhankelijk van een instelling: Beheer->Instellingen->Instellingen, Api->Afdrukken 'Automatisch printen van de factuur'
Tevens is er een bug opgelost dat de instelling voor Automatisch printen van de kassabon ook gecontroleerd wordt, deze instelling was er al wel maar werkte nog niet.
unappliedVoucherIssuances (vouchers die niet toegepast zijn i.v.m. een verzilver restrictie) toegevoegd aan response van de onderstaande calls:
CreateInvoiceFromPackingSlipsDeliverOrderDeliverOrderV2PayTableOrderCreateAndPayTableOrderPlaceTableOrderPrepayTableOrderV2PayOrderPayOrderV2CreateInvoiceFromProposalCreateOrderFromProposalgetVoucherSettings call toegevoegd waarmee in bulk de instellingen van verschillende vouchers opgevraagd kan worden. De requestedVoucherId is een voucher id die opgevraagd werd, voucherId is de voucher id + versie van de instellingen, die daar daadwerkelijk voor teruggegeven is. (Als je b.v.b. versie 0 opvraagd, krijg je de nieuwste versie terug.)
Opgelost dat het kortingspercentage wordt gecontroleerd bij het toevoegen of een wijzigen van een relatie. Het kortingspercentage van een relatie mag maximaal 100 procent zijn (en moet hoger dan 0 zijn)
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.
getJournals zorgt er nu voor dat de teruggegeven betalingen voor JOURNAL-FILTER-ORDER opgeteld nu altijd op 0 uitkomt, door tegen te boeken op de "Verrekening aanbetaling" betaalwijze. Zodra er daadwerkelijk omzet is gemaakt, zullen deze betalingen namelijk opgehaald kunnen worden met JOURNAL-FILTER-RECEIPT/JOURNAL-FILTER-INVOICE.
Via een instelling is het oude gedrag van de getPackingSlips functie (van vóór v48) weer te activeren. Daardoor retourneert deze functie alle uitgifte-types, en niet enkel pakbonnen.
setRelationPresence zal nu ook relatie synchronisatie starten op de slave als de relatie gewijzigd is op de master
getVoucherIssuances heeft nu een fromDate en throughDate in het request object.
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.
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())
Herstelt dat oa getTableOrderV3 verkeerde aantallen voor bereidingwijze kon retourneren als uncondensedLines false is. Hier had oa de Android handheld last van.
Opgelost dat saveSalesRepeatTemplate een access violation SOAP exception kon geven.
Verholpen dat in de WSDL en documentatie miste dat sommige response types een basis type hadden.
Dit verhelpt dat calls die deze types retourneerden niet goed werkten als je de service importeerde in visual studio.
Probleem opgelost met savePurchaseDelivery.
Opgelost dat getPurchaseDeliveries(V2) een verkeerd totalExclAmount kon laten zien op de regel wanneer er met verpakkingen gewerkt werd.
Daarnaast ook opgelost dat quantityOfPackagesDelivered niet ingevuld was terwijl dat wel moest gebeuren.
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
Als je dialog.id of dialog.options[].id "asString" doorgeeft, dan wordt dat nu ook goed doorgespeeld in de uiteindelijke webhook payload.
De moveTableOrder API calls houden nu ook rekening mee met of er op de virtuele relatie aanwezigheidstafel range geboekt mag worden of niet, afhankelijk van hoe die instellingen staan.
Opgelost dat getOrders deze error teruggaf: Unknown consumption location indien je gebruik maakte van consumptie locaties per regel.
Opgelost dat setRelationPresence aangaf dat de tafel bezet was, indien er aangemeld probeerd te worden op een tafel die nog nooit eerder gebruikt was.
Opgelost dat setRelationPresence soms ten onrechte aangaf dat de tafel al bezet was als er een specifieke subtafel werd gebruikt om op aan te melden.
getNutritionalCharacteristics geeft nu ook de allergieën terug van de ingrediënten van een artikel
Opgelost dat de minimum prijs berekening van een artikel de minimum prijs van een verplichte bereidingswijze op het hoofdartikel meenam op de prijs van een vervangend artikel, indien het vervangend artikel goedkoper is. Dit is niet logisch omdat de bereidingswijze keuze voor het hoofdartikel is, niet voor het vervangend artikel. Deze berekening kan d.m.v. min_price_incl opgevraagd worden met de getOverview call.
Opgelost dat getArticleVariants een SOAP exceptie gaf als de call artikelen probeerde terug te geven welke geen uitvoeringen bevatten.
Als de API een betaling probeert uit te voeren op een betaalwijze die wel aanwezig is, maar uitgeschakeld, dan veroorzaakt dat nu geen fout meer.
Het uitschakelen van een betaalwijze moet invloed hebben op de keuze welke betaalwijzes je kan selecteren, maar als er eenmaal een betaling op uitgevoerd is mogen we die niet meer weigeren.
Dit lost bijvoorbeeld de volgende foutmelding op: One or more payment methods are NOT enabled WEBSHOP.
Oplossing gevonden voor het probleem dat meldingen als "No order.orderId specified" en "Error while trying to save packing slip of order." kon veroorzaken bij het betalen van een tafel via de online handheld.
Oplossing gevonden voor het probleem dat meldingen als "No order.orderId specified" en "Error while trying to save packing slip of order." kon veroorzaken bij het betalen van een tafel via de online handheld.
Verhelpt probleem dat bij gebruik van placeTableOrder om af te rekenen met automatisch afdrukken van de bon aan de TSE gegevens missen op de bon.
Lost probleem op waardoor API meer CPU belasting kon geven dan zou moeten.
Lost probleem op waardoor API meer CPU belasting kon geven dan zou moeten.
Opgelost dat updateProduct altijd alle prijsgroepen en salesprijzen van de te updaten artikelen afhaalde.
Om toch nog specifiek een prijsgroep/salesprijs van een artikel af te halen met deze call, is dit mogelijk door alleen de priceGroupNumber/salesPriceNumber in te vullen.
Crash opgelost in de getOverview call wanneer de min_price_incl opgevraagd werd van een artikel dat d.m.v. menu/vervangend artikel/bijverkoop zichzelf weer kon verkopen.
Dit lost bijvoorbeeld de volgende scenario op:
artikel A -> artikel B (vervangend artikel) -> artikel A (bijverkoop)getPackingSlips, getReceipts, getInvoices werkt weer.
getPackingSlips, getReceipts, getInvoices werkt weer.
Verhelp "Database error on the server" foutmelding bij getPurchaseDeliveriesV2
Fout zat er in sinds v58.3.0.
deliverOrderV2 levert nu weer de opgegeven aantallen ipv een volledige levering te doen.
De createOrder functies trekken niet meer de component prijs af van de opgegeven prijs.
Tevens probleem opgelost dat de functie faalde met een assertion failure nadat de order correct opgeslagen was.
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 het aanpassen van een orderregel op een verkooporder er voor zorgt dat na het opslaan alle geleverde aantallen van de verkooporder verdwenen zijn.