getTerminalSettings retourneert nu (via askToKeepTableName) of bij het afrekenen van een tafel ook de vraag moet worden gesteld of de tafelnaam behouden moet worden.
Wanneer de knoppenindeling die via getButtonLayout wordt opgevraagd niet-bestaande artikelen bevat, dan worden deze geconverteerd naar tekstknoppen en wordt "(article missing)" aan de knoptekst toegevoegd.
Wanneer de Mplus API Service niet als service werd uitgevoerd, maar direct of via een batchbestand, dan werd er een blauwe tekst "MplusQservice running..." getoond in de linkerbovenhoek. Deze tekst is nu standaard verborgen, inclusief het programma-icoon in de taakbalk. Via het opstartargument --visible kun je deze tekst en het programma-icoon weer zichtbaar maken.
Probleem opgelost dat optrad als birthDate niet werd ingevuld bij het toevoegen (createRelation) of bijwerken (updateRelation) van een relatie.
De verplaatsbon die aangemaakt worden via de moveTableOrder functie past nu op de juiste manier de woordaliassen toe (zodat je niet meer {Tafel} ziet staan) èn toont nu ook de medewerker die de verplaatsing heeft uitgevoerd.
Deze release is vervangen door v2.1.1.
getOrder retourneert nu GET_ORDER_RESULT_NOT_FOUND als er een lege orderId wordt meegegeven, in plaats van een onbedoelde foutmelding.
Nieuwe voorraadwijzigingstype STOCK_HISTORY_TYPE_MANUAL
Nieuwe voorraadwijzigingstype STOCK_HISTORY_TYPE_MANUAL
getProducts is sterk geoptimaliseerd om snelheid te verbeteren.
Nieuwe functie getPaymentMethodsV2 die filtering op accountNumber ondersteunt.
De functies createProduct, updateProduct, createRelation, updateRelation, createEmployee en updateEmployee zullen niet meer de inhoud van velden wissen die wel in de API aanwezig zijn, maar niet in het verzoek zijn meegestuurd.
De functies createProduct, updateProduct, createRelation, updateRelation, createEmployee en updateEmployee zullen niet meer de inhoud van velden wissen die wel in de API aanwezig zijn, maar niet in het verzoek zijn meegestuurd.
Nieuwe functie getPaymentMethodsV2 die filtering op accountNumber ondersteunt.
getProducts is sterk geoptimaliseerd om snelheid te verbeteren.
getProducts is sterk geoptimaliseerd om snelheid te verbeteren.
getOrder retourneert nu GET_ORDER_RESULT_NOT_FOUND als er een lege orderId wordt meegegeven, in plaats van een onbedoelde foutmelding.
Het meegeven van deliveryMethod PICKUP in een order vertaalt zich nu ook in een echte afhaalorder, en het meegeven van DELIVERY in een bezorgorder.
Het meegeven van deliveryMethod PICKUP in een order vertaalt zich nu ook in een echte afhaalorder, en het meegeven van DELIVERY in een bezorgorder.
De functie getTableList retourneert nu ook of een tafel gereed is om uit te serveren, door middel van de tableStatus TABLE_ORDER_READY_TO_BE_SERVED.
Nieuwe functie getMessages() waarmee voor een bepaalde werkplek (branchNumber and terminalNumber) de berichten opgevraagd kunnen worden, evt. vanaf een bepaald berichtnummer (sinceMessageId). Ook kan opgegeven worden of de berichten nà opvragen geregistreerd moeten worden als "gelezen" (setDelivered) en of er alleen ongelezen berichten ingelezen moeten worden (onlyUndelivered).
De verkoopeenheid (kolom verkoop_eenheid) van een artikel wordt nu ook via de API meegegeven, in de eigenschap siUnit.
imageURL werd niet op de juiste manier ingevuld.
imageURL werd niet op de juiste manier ingevuld.
imageURL werd niet op de juiste manier ingevuld.
getStockHistory retourneert nu waar mogelijk de volgende eigenschappen: stockId, packingSlipId, invoiceId, receiptId of correctionNumber.
getStockHistory retourneert nu waar mogelijk de volgende eigenschappen: stockId, packingSlipId, invoiceId, receiptId of correctionNumber.
Functie getCustomFieldList toegevoegd waarmee de klantvelden van de artikel-, relatie- en medewerkerkaart opgevraagd kunnen worden.
Het was via de API niet mogelijk om dubbele extArticleId's in te voeren, terwijl we dat in de database verder niet geblokkeerd hadden. Daarom wordt er nu niet meer gecontroleerd op reeds bestaan van een extArticleId.
Bij het teruggeven van een branchAccountNumberList werd de eerste extBranchId nooit gevuld, zelfs wanneer die wel bestond.
payTableOrderV2 toegevoegd, waaraan meegegeven kan worden of de tafelnaam behouden moet worden, via keepTableName.
Er is nu ook ondersteuning voor voorraadaantallen (quantity), klantensaldo's (balance) en kredietlimieten (creditLimit) hoger dan 2.147.483.647.
Veel optimalisatie in het verwerken van orders en facturen. Dit zal de totale tijd die het kost om bijv. een tafelorder op te slaan verkorten.
Het object Terminal bevat nu optioneel ook de eigenschappen terminalSoftwareName en terminalSoftwareVersion. Wanneer deze ingevuld worden bij de aanroep naar registerTerminal, dan wordt de inhoud van deze waarden geregistreerd bij de werkplek. Daarnaast wordt nu ook bijgehouden wanneer registerTerminal voor de laatste keer is aangeroepen.
Bij het aanroepen van getProducts, getRelations en getEmployees en filterend op syncMarker worden de resultaten nu geretourneerd gesorteerd op syncMarker. Dit is iets dat je waarschijnlijk zelf ook al had moeten doen bij het verwerken.
Als bij getProducts alle producten vanaf een bepaalde syncMarker worden opgevraagd, dan worden nu per product alle artikelen geretourneerd in de articleList, en niet meer alleen de artikelen vanaf de meegegeven syncMarker.
Vanwege de overgang naar de nieuwe Builder konden we de Mplus API Service niet langer als console-applicatie uitbrengen. Het logbestand van de API moet nu expliciet worden opgegeven via het opstartargument --output.
getCashCountList vereist nu een WorkplaceYearNumber in plaats van een YearNumber als de derde, optionele parameter. Dit is zonder backwards-compatibility toegevoegd, omdat enkel een jaar en nummer niet uniek is voor alle kastellingen, en dus nooit goed is.
De functie getArticleGroups retourneert nu per artikelgroep ook een lijst van alle productnummers die in die groep zitten.
Versnelde implementatie van getReceipts toegevoegd.
De functie payOrder met eigenschap prepay = TRUE ondersteunt nu ook een gedeeltelijke aanbetaling.
Nieuwe functie setStock die een absolute waarde voor de voorraad accepteert.
De parameter dataType van het object CustomField is nu optioneel. Bij het opsturen naar de API hoef je deze niet per se op te geven, want in de database is bekend welk type deze velden hebben.
Het object Article bevat nu ook changeTimestamp en createTimestamp die respectievelijk aangeven wanneer een artikel voor de laatste keer is gewijzigd en wanneer het is aangemaakt.
Als je geen productNumber meegeeft aan een aanroep van updateProduct, zal nu geprobeerd worden het juiste productNumber te bepalen aan de hand van de meegegeven articleNumbers.
Het aantal kassabonnen dat getReceipts teruggeeft als je zoekt vanaf een bepaald syncMarker is nu ook configureerbaar via de parameter --sync_marker_limit. Standaardwaarde is 1000.
getActiveEmployeeList() retourneert nu per medewerker ook de volgende autorisatie-opties: allowNextCourse, allowSplit en allowPay.
Relation bevat nu ook de eigenschap relationCode waarmee het veld relatiecode van de relatiekaart ingelezen en gemanipuleerd kan worden. Maximale lengte van dit veld is 128 alfanumerieke karakters.
Het Transaction object bevat nu ook de eigenschap extBranchId.
Het VatGroup object bevat nu ook de eigenschap extBranchId.
De API controleert nu elke 10 minuten op welke machine hij draait en met welk ip-adres (of ip-adressen als het er meerdere zijn) en verstuurt dit naar de database. Op basis hiervan kan in de kassa of op andere plekken getoond worden of de API online is en waar deze allemaal bereikbaar is.
Bug opgelost die problemen opleverde bij importeren datum en tijdstippen via create/updateProduct en soortgelijke functies.
Als er een betaling op een order gedaan wordt (payOrder), en de order is een filiaalorder van een Slave-filiaal, dan wordt de achterliggende transactie aangemaakt in het filiaal en werkplek dat staat ingesteld als standaard filiaal en werkplek voor de momenteel aangemelde API-gebruiker. Voorheen werd de transactie aangemaakt op het filiaal en werkplek van het Slave-filiaal, maar dat kon duplicaten opleveren (overigens zover bekend nog nooit gebeurd).
Bij het aanroepen van getRelations, getEmployees en getProducts wordt nu in het logboek getoond welke filters zijn toegepast, bijvoorbeeld:
000039cc 2016-06-30 12:03:59.974 INFO [main.requests]: Filtered on syncMarker groter of gelijk aan 338498
Bij het opgeven van het opstartargument --debug moet je nu ook direct de locatie van het logbestand erachter zetten. Het debug-bestand wordt dus niet meer standaard naar logs/debug.txt weggeschreven.
De API geeft nu elke tien minuten een statusmelding in het logbestand waarin staat op welke poort de API draait en òf en met welke database de API verbonden is.
Voorbeelden:
API Service running on port 18083 and connected to database qline@127.0.0.1
API Service running on port 18083 and NOT connected to database qline@127.0.0.1
updateStock geeft geen foutstatus meer als de voorraad van een artikel wordt bijgewerkt dat geen voorraadartikel is.
payOrder controleert nu of de meegegeven betaalwijzen wel bestaan.
Zoals ingesteld onder "Kassa > Tafels > Tafelomschrijving behouden" wordt de naam nu wel of niet bewaard na het afhandelen van de tafel.
Het is nu mogelijk om bestellingen bestaande uit alleen maar tekstregels af te rekenen.
De functies getRelations, getProducts, getEmployees, getOrders, getInvoices en getReceipts worden nu allemaal gelimiteerd door de ingestelde standaard --sync_marker_limit. Daarnaast is het ook mogelijk deze limiet te overschrijven tijdens de aanvraag door middel van de meegegeven syncMarkerLimit. Vanzelfsprekend werkt syncMarkerLimit alleen in combinatie met syncMarker.
De functies getRelations, getProducts, getEmployees, getOrders, getInvoices en getReceipts worden nu allemaal gelimiteerd door de ingestelde --sync_marker_limit. Daarnaast is het ook mogelijk deze limiet te overschrijven tijdens de aanvraag door middel van de meegegeven syncMarkerLimit. Vanzelfsprekend werkt syncMarkerLimit alleen in combinatie met syncMarker.
Versnelde implementatie van getReceipts, welke niet alleen veel sneller is dan de oude implementatie, maar ook een gelimiteerd aantal kassabonnen teruggeeft, om geheugenproblemen te voorkomen.
Probleem opgelost waardoor verschillende functies stilletjes konden vastlopen.
Probleem verholpen waardoor bestellen op een tafel kon mislukken met een database foutmelding op de PDA.
Probleem opgelost dat soms optrad bij findRelation waardoor een relatie niet werd geretourneerd ook al bestond die wel.
Probleem opgelost waardoor het inlezen van artikelen op basis van PLU-nummer mislukte.
Probleem opgelost waardoor het inlezen van artikelen op basis van PLU-nummer mislukte.
Probleem verholpen waardoor het niet mogelijk was een tafel te splitsen.
Bij het afrekenen van een tafel kon het gebeuren dat de API dacht dat het om een splitsing ging omdat de orders als verschillend werden gezien als een regel twee of meer identieke bereidingswijze had.
Dit had tot gevolg dat na het afrekenen vanaf de handheld de tafel bleef open staan. Alles was dan wel tegengeboekt en het totaal bedrag van de tafel was dan nul.
Probleem opgelost waardoor sinds v2.1.0 turnoverGroup niet meer kon worden bijgewerkt via createProduct en updateProduct.
Dezelfde artikelgroepen werden bij getProducts ten onrechte meerdere malen teruggegeven in de groupNumbers en sortOrderGroupList lijsten.
queueBranchOrder controleerde nog niet op dubbele extOrderId's in zijn eigen "buffer". Als je snel was kon je daardoor meerdere orders met hetzelfde extOrderId invoeren.
getTurnoverGroups gaf een foutmelding als je het gebruikte in combinatie met afzonderlijk ingestelde rekeningnummers per filiaal.
Elke imageList bevat nu (logischerwijs) niet meer de afbeeldingen die verwijderd zijn.
Probleem opgelost uit v2.1.0 waardoor omzetgroepen altijd op 0 gezet werden als ze niet geconfigureerd waren onder Beheer.
Probleem opgelost uit v2.1.0 met het opslaan van verkooporders.
Probleem opgelost waardoor de imageList van een article soms meerdere keren dezelfde afbeelding bevatte.
Probleem opgelost bij bereidingswijzen die een artikelnummer hoger dan 2.147.483.647 hebben.
Zowel bij getInvoices als getReceipts kwam het probleem naar voren dat als je een syncMarker hoger dan de hoogste waarde in de database meegaf, hij het hele syncMarker filter negeerde en gewoon weer van voren af aan begon met de resultaten.
Probleem opgelost waardoor overboekingen van betaalwijzen niet goed in de dagtotalen werden teruggegeven. Dit had invloed op getJournals.
Probleem opgelost waardoor overboekingen van betaalwijzen niet goed in de dagtotalen werden teruggegeven. Dit had invloed op getJournals.
Zowel bij getInvoices als getReceipts kwam het probleem naar voren dat als je een syncMarker hoger dan de hoogste waarde in de database meegaf, hij het hele syncMarker filter negeerde en gewoon weer van voren af aan begon met de resultaten.
Via de eigenschap active en de functie updateProduct kan aangegeven worden of een artikel op actief of niet-actief moet staan.
Een fout opgelost in de API-functies updateProduct, updateRelation en updateEmployee die recentelijk geïntroduceerd was.
createProduct en updateProduct verwerken nu goed de customFieldList.
Bij het volledig verplaatsen van een tafel via de API functie moveTableOrder wordt nu ook zoals verwacht de verplaatsbon afgedrukt op elke printerlocatie waarvan artikelen in de tafelbestelling aanwezig zijn.
Na het uitvoeren van updateOrder was het mogelijk dat de API probeerde een printopdracht te genereren voor het afdrukken van de order. Hierbij werd echter het verkeerde id meegegeven aan de printopdracht, waardoor updateOrder met een exceptie tot stilstand kwam.
Probleem opgelost dat wellicht de oorzaak was van vastlopers zonder duidelijke oorzaak.
Hier en daar werden in de onderliggende libraries foutdialogen getoond als er een query-fout optrad. Dit kon ervoor zorgen dat de API ogenschijnlijk zonder oorzaak vastliep, maar eigenlijk kwam dit doordat er een onzichtbaar dialoog moest worden weggeklikt. De onzichtbaarheid van dit dialoog maakte dit natuurlijk een grote uitdaging.
Probleem opgelost dat wellicht de oorzaak was van vastlopers zonder duidelijke oorzaak.
Hier en daar werden in de onderliggende libraries foutdialogen getoond als er een query-fout optrad. Dit kon ervoor zorgen dat de API ogenschijnlijk zonder oorzaak vastliep, maar eigenlijk kwam dit doordat er een onzichtbaar dialoog moest worden weggeklikt. De onzichtbaarheid van dit dialoog maakte dit natuurlijk een grote uitdaging.
Probleem opgelost met importeren van producten via createProduct of updateProduct.
Probleem opgelost met importeren van producten via createProduct of updateProduct.
Probleem opgelost met importeren van producten via createProduct of updateProduct.
Probleem opgelost waardoor de API naar ong. 1000 importhandelingen (zoals het aanmaken of bijwerken van een artikel, relatie of medewerker) opeens foutmeldingen begon te retourneren.
Bepaalde foutmeldingen werden niet gelogd als ze veroorzaakten dat de software beëindigd werd.
Bepaalde foutmeldingen werden niet gelogd als ze veroorzaakten dat de software beëindigd werd.
