Allergenen per artikel kunnen nu opgevraagd en opgeslagen worden. Zie de eigenschap allergenList van article voor de benodigde structuur.
getArticlesInLayout houdt nu ook rekening met ingestelde standaard prijsgroepen van de opgevraagde werkplek en met eventueel ingestelde eigen filiaalprijzen op de artikelkaart.
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.
getProducts is sterk geoptimaliseerd om snelheid te verbeteren.
getStockHistory retourneert nu ook de voorraad vóór (beforeCorrectionQuantity) en ná (afterCorrectionQuantity) een correctie, indien de voorraadwijziging door een correctie heeft plaatsgevonden. Ook als de voorraad vóór en ná precies gelijk is zal de wijziging doorgegeven worden, zodat afterCorrectionQuantity altijd aanwezig is.
Indien getStock wordt opgevraagd op basis van stockId, dan wordt het resultaat nu ook gesorteerd op stockId.
getStockHistory retourneert nu ook de voorraad vóór (beforeCorrectionQuantity) en ná (afterCorrectionQuantity) een correctie, indien de voorraadwijziging door een correctie heeft plaatsgevonden. Ook als de voorraad vóór en ná precies gelijk is zal de wijziging doorgegeven worden, zodat afterCorrectionQuantity altijd aanwezig is.
Indien getStock wordt opgevraagd op basis van stockId, dan wordt het resultaat nu ook gesorteerd op stockId.
Indien getStock wordt opgevraagd op basis van stockId, dan wordt het resultaat nu ook gesorteerd op stockId.
getStockHistory retourneert nu ook de voorraad vóór (beforeCorrectionQuantity) en ná (afterCorrectionQuantity) een correctie, indien de voorraadwijziging door een correctie heeft plaatsgevonden. Ook als de voorraad vóór en ná precies gelijk is zal de wijziging doorgegeven worden, zodat afterCorrectionQuantity altijd aanwezig is.
Indien getStock wordt opgevraagd op basis van stockId, dan wordt het resultaat nu ook gesorteerd op stockId.
getStockHistory retourneert nu ook de voorraad vóór (beforeCorrectionQuantity) en ná (afterCorrectionQuantity) een correctie, indien de voorraadwijziging door een correctie heeft plaatsgevonden. Ook als de voorraad vóór en ná precies gelijk is zal de wijziging doorgegeven worden, zodat afterCorrectionQuantity altijd aanwezig is.
Indien getStock wordt opgevraagd op basis van stockId, dan wordt het resultaat nu ook gesorteerd op stockId.
getStockHistory retourneert nu ook de voorraad vóór (beforeCorrectionQuantity) en ná (afterCorrectionQuantity) een correctie, indien de voorraadwijziging door een correctie heeft plaatsgevonden. Ook als de voorraad vóór en ná precies gelijk is zal de wijziging doorgegeven worden, zodat afterCorrectionQuantity altijd aanwezig is.
getStockHistory retourneert nu ook de voorraad vóór (beforeCorrectionQuantity) en ná (afterCorrectionQuantity) een correctie, indien de voorraadwijziging door een correctie heeft plaatsgevonden. Ook als de voorraad vóór en ná precies gelijk is zal de wijziging doorgegeven worden, zodat afterCorrectionQuantity altijd aanwezig is.
Indien getStock wordt opgevraagd op basis van stockId, dan wordt het resultaat nu ook gesorteerd op stockId.
getStockHistory retourneert nu ook de voorraad vóór (beforeCorrectionQuantity) en ná (afterCorrectionQuantity) een correctie, indien de voorraadwijziging door een correctie heeft plaatsgevonden. Ook als de voorraad vóór en ná precies gelijk is zal de wijziging doorgegeven worden, zodat afterCorrectionQuantity altijd aanwezig is.
Nieuwe functie getOrderChanges, geeft alle wijzigingen aan verkooporders en/of (tafel)-bestellingen terug, gegroepeerd per versie van de order/bestelling.
Indien getStock wordt opgevraagd op basis van stockId, dan wordt het resultaat nu ook gesorteerd op stockId.
De eigenschap article.categoryId werd nooit gevuld, terwijl deze wel gewoon in het object gedefinieerd was en een databasewaarde kon hebben. Dat is nu opgelost.
Deze releasenote is niet echt van toepassing op de API, maar wordt hier geplaatst zodat de API-developers hem ook zullen zien. Het is nu mogelijk om direct vanaf de partnerpagina voor een specifieke API een probleem te melden of vraag te stellen. Dit helpt aan de kant van onze supportafdeling om snel te weten waar het over gaat.
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.
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
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.
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 de juiste nummers niet altijd werden teruggegeven bij create en update van product, relation en employee.
paymentList in getJournals wordt weer ingevuld.
Opslaan van invoiceAddress en deliveryAddress bij queueBranchOrder werkt nu.
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.
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.
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.
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.
