MplusQService API: Opgelost dat voor updateProduct de update van prijsgroep informatie correct wordt uitgevoerd (en tevens voor salesprijzen)
Nieuwe call getBranchInformation voor het ophalen van stamgegevens van filialen.
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
MplusQAPIService: Extra filters voor call getSalesRepeatTemplates. Er kan nu ook op specifieke 'template-ids' en/of template types (ORDER/FACTUUR) gefilterd worden
Opgelost dat API call getRenderedPrintLayout bij het opvragen van de afdruk van meer dan een factuur de juiste factuurinformatie voor alle facturen oplevert.
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.
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.
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
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
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.
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)
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
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
Verhelpt dat de API een soapfault geeft als je getOverview een INCOLLECTION filter geeft met een lege lijst.
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.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.