v6.3.0 was niet goed, oude bugs werden gereïntroduceerd. Deze release is wat v6.3.0 eigenlijk moest zijn.
Protocolversie 1.0.1
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.
Er is een nieuwere versie van winsw (namelijk v2.0.2) aan de installatiehandleiding toegevoegd. Download het betreffende zip-bestand dus even opnieuw via de installatiehandleiding als je deze ergens lokaal had staan.
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.
Minimale aanpassingen aan een gedeelte van het service definitiebestand (WSDL), waardoor een ontbrekende definitie van ns__NumberLst opgelost moet zijn
Minimale aanpassingen aan een gedeelte van het service definitiebestand (WSDL), waardoor een ontbrekende definitie van ns__NumberLst opgelost moet zijn
Minimale aanpassingen aan een gedeelte van het service definitiebestand (WSDL), waardoor een ontbrekende definitie van ns__NumberLst opgelost moet zijn
Problemen opgelost met betrekking tot het vrijgeven van tafels ná aanbetaling en splitsing.
Het verplaatsen van een volledige bestelling via moveTableOrder gaat nu weer goed. Deze functie wordt oa. gebruikt door de handheld via de SPLITS-functie.
Protocolversie 1.0.1
Rekeningnummers via getTurnoverGroups en getPaymentMethodsV2 worden nu altijd teruggegeven, ook als ze een waarde van nul of lager hebben.
Een aanroep naar registerTerminal zorgt er nu ook voor dat evt. claims op tafels worden vrijgegeven.
Een aanroep naar registerTerminal zorgt er nu ook voor dat evt. claims op tafels worden vrijgegeven.
getButtonLayout bevat nu ook de evt. ingestelde standaard hoofdgroep (defaultMainGroup) en subgroep (defaultSubGroup).
getButtonLayout bevat nu ook de evt. ingestelde standaard hoofdgroep (defaultMainGroup) en subgroep (defaultSubGroup).
getButtonLayout bevat nu ook de evt. ingestelde standaard hoofdgroep (defaultMainGroup) en subgroep (defaultSubGroup).
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.
Nieuwe functie getOrderChanges, geeft alle wijzigingen aan verkooporders en/of (tafel)-bestellingen terug, gegroepeerd per versie van de order/bestelling.
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
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.
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.
Nieuw opstartargument --profile: Voeg toe om in het API-log meer inhoudelijke statistieken over het tijdsverloop van de functie te zien, zoals hoe lang besteedt wordt aan de verschillende stappen van de functie. Profiling is nog (lang) niet bij alle functies toegevoegd.
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).
Downgrade naar API v1.0.0.
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.
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 in getOrderChanges en getArticlesInLayout.
Probleem opgelost in getOrderChanges en getArticlesInLayout.
Probleem in getOrderChanges opgelost waardoor ophalen op basis van syncMarker niet goed werkte.
Probleem in getOrderChanges opgelost waardoor ophalen op basis van syncMarker niet goed werkte.
Probleem in getOrderChanges opgelost waardoor ophalen op basis van syncMarker niet goed werkte.
Probleem opgelost dat kan optreden tijdens het betalen van tafelbestellingen met tekstbereidingswijzen.
Probleem opgelost dat kan optreden tijdens het betalen van tafelbestellingen met tekstbereidingswijzen.
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.
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.
