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.
Eventueel ingestelde menu-setprijzen worden automatisch toegepast. Dit is via een instelling in Mpluskassa uit te schakelen. Als je deze instelling uitschakelt, dan krijg je bij het openen van de tafel op de kassa de vraag of en welke menu's je wil samenstellen.
Menu-informatie wordt nu ook aan artikelregels toegevoegd. Kan gebruikt worden om te zien dat een artikelregel onderdeel is van een groter menu. De gebruikte eigenschappen zijn menuHash (unieke waarde per menu-combinatie), menuDescription (toonbare omschrijving van het menu), menuAmount (totaalbedrag van dit artikel binnen de menu-combinatie).
Bij het opslaan van geretourneerde regels via saveTableOrder wordt nu ook altijd de "reden retour" ingevuld zodat dat goed kan worden uitgelezen in de overzichten.
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.
Attentie: Deze release is teruggetrokken vanwege een bug in de bugfix in payTableOrder in deze release.
Attentie: Deze release is teruggetrokken vanwege een probleem met het betalen van een splitsing.
Attentie: Deze release is teruggetrokken vanwege verkeerd ingevulde compatibilteit met databaseschema.
Attentie: Deze release is teruggetrokken vanwege verkeerd ingevulde compatibilteit met databaseschema.
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.
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 Order, Invoice en Receipt objecten bevatten nu ook de volgende eigenschappen: entryExtBranchId en financialExtBranchId.
Het Payment object in een paymentList bevat nu ook de eigenschappen entryTimestamp, branchNumber, extBranchId, workplaceNumber, employeeNumber en employeeName.
getProducts() ondersteunt nu ook de onlyActive parameter. Wanneer deze op TRUE staat, worden alleen de actieve artikelen geretourneerd.
getTerminalSettings() retourneert nu ook unknownTableAction. Deze eigenschap geeft aan wat er gedaan moet worden als er een onbekende tafel gekozen wordt.
allowTableRetour toegevoegd aan EmployeeName
Bij het aanroepen van getJournals(), getFinancialJournal() en getFinancialJournalByCashCount() wordt nu altijd opgeslagen welke data gediend heeft als bron voor het antwoord. Eventueel kan de aanvrager een eigen referentie meegeven.
payInvoice() geeft nu goed aan als een betaling niet kan worden uitgevoerd omdat de gewenste betaalwijze is uitgeschakeld.
Nieuwe functie requestTableOrderCourse() waarmee een gewenste gang voor een bepaalde tafel kan worden uitgevraagd.
Nieuwe functie logMistake() die gebruikt kan worden om een foutaanslag op bijv. een handheld te registreren.
Nieuwe functie getTableOrderCourseList() waarmee voor een bepaald filiaal- en tafelnummer de op dat moment aanwezige en uitgevraagde gangen kunnen worden opgevraagd.
Gangen hebben nieuwe eigenschappen: sequenceNumber, isPresent en isRequested.
Nieuwe functie getCardCategories waarmee de categorieën van de artikel-, relatie- en medewerkerkaarten opgevraagd kunnen worden. Bij relaties gaat het bijvoorbeeld om de categorieën "Klant" en "Leverancier".
De BPE-informatie (Breuk/Promotie/Eigen gebruik) wordt nu ook aan artikelregels meegegeven. Zo kan er onderscheid gemaakt worden tussen echte korting en "korting" vanwege BPE. De gebruikte eigenschappen zijn bpeId (interne identificatie), bpeDescription (toonbare omschrijving), bpeAmount (bedrag incl. BTW), bpeAmountExcl (bedrag excl BTW).
Nieuwe API-functie getWordAliases die ingestelde woordaliassen kan teruggeven. Kan bijvoorbeeld gebruikt worden om een woord altijd te vertalen naar een ander woord, zoals "Klant" naar "Gast".
Bij het opvragen van factuurinformatie wordt nu ook evt. meegegeven of de factuur vergrendeld is (finalized) en wanneer (finalizedTimestamp).
Bij het versturen van een bericht via sendMessage kan nu ook de sender en messageType worden meegegeven. Kies uit OK, INFO of WARNING.
Bij het opvragen van een kastelling via getCashCountList wordt nu ook het rekeningnummer waarop het kasverschil wordt gestort teruggegeven via de parameter differenceAccountNumber. Ook wordt het rekeningnummer van de afstortrekening teruggegeven via de parameter depositAccountNumber.
Je kunt nu ook de parameter sinceCashCountNumber invullen om alle kastellingen sinds een bepaalde kastelling op te vragen.
De functie getJournals retourneert nu per betalingswijze ook het betalingswijzesoort, zoals: "BETAAL", "EFT", "TUSSEN", "AFSTORT", "BPE".
De finalizeInvoices parameter kan worden toegevoegd aan een getInvoices aanvraag om de facturen die opgehaald zijn te vergrendelen. Gebruik dit wanneer de facturen eenmalig geëxporteerd dienen te worden naar een extern systeem, zoals een boekhoudpakket. Het voorkomt namelijk dat de factuur daarna nog verder gewijzigd kan worden in de kassa.
Bij het opvragen van het versienummer van de API via getApiVersion wordt nu ook de ingestelde datum van de API-server teruggegeven via de parameter serverDate. Dit kan gebruikt worden om externe apparaten te synchroniseren met de server.
Bij het opvragen van kastellingen via getCashCountList wordt nu ook de eerste en laatste id's van de achterliggende kassabonnen meegegeven, via de eigenschappen shiftFirstReceiptId en shiftLastReceiptId. Daarnaast bevat de eerste en laatste transactie (shiftFirstTransaction en shiftLastTransaction) nu ook het transactielabel via de eigenschap transactionString.
Attentie: Deze release werkt wel met het juiste databaseschema, in tegenstelling tot de teruggetrokken v1.7.7.2 die per ongeluk op een versie te ver was uitgegeven.
De volgende objecten bevatten nu ook het extBranchId (externe referentie voor het filiaal):
Branch, CashCount, Journal, FinancialGroup en Shift.
De API-functie getEmployees kan nu ook worden gebruikt met een syncMarker. Lees de Sync Marker Tutorial (Engels) voor een uitgebreide uitleg.
De API-functie getTurnoverGroups retourneert nu ook de ingestelde externe rekeningnummers per filiaal, via de lijst branchAccountNumberList.
API-functies die werken met betaalwijzen per filiaal, zoals getFinancialJournal en getFinancialJournalByCashCount, retourneren nu ook het juiste rekeningnummer in het veld accountNumber als deze afwijkt van het standaard rekeningnummer.
API-functies die werken met omzetgroepen per filiaal, zoals getFinancialJournal en getFinancialJournalByCashCount, retourneren nu ook het juiste rekeningnummer in het veld accountNumber als deze afwijkt van het standaard rekeningnummer.
Wanneer een API-functie wordt gebruikt met klantvelden (zoals createProduct, createRelation of createEmployee) en de klantvelden zijn verplicht, maar deze worden niet meegegeven en hebben ook geen standaardwaarde, dan wordt er een duidelijke foutmelding teruggegeven.
getFinancialJournal geeft nu ook aan of de periode waarover een financieel journaal is aangevraagd al officieel is afgesloten, door middel van het veld financialPeriodClosed. Het kan namelijk voorkomen dat een boekingsdag pas afloopt om 6 uur 's ochtends, in plaats van exact middernacht.
Medewerkers kunnen nu ook per stuk opgehaald worden via getEmployee, daarnaast worden daarbij nu ook de klantvelden (de customFieldList) en de volgende standaardvelden meegegeven: syncMarker, changeTimestamp, createTimestamp, extraText, categoryId, personNumber.
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
Bij het afrekenen van een afsplitsing via payTableOrder werd de nieuwe bestelling met daarin de afsplitsing niet goed opgeslagen, waardoor de API een foutmelding teruggaf. Hier liep vooral de Android Kassa tegenaan.
Bij het afrekenen van een afsplitsing via payTableOrder werd de nieuwe bestelling met daarin de afsplitsing niet goed opgeslagen, waardoor de API een foutmelding teruggaf. Hier liep vooral de Android Kassa tegenaan.
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.
getTableList() retourneert nu ook de informatie over de hoogst uitgevraagde gang van elke tafel, dit gebeurt via de eigenschappen courseNumber, courseName en courseAbbreviation.
getJournals kan nu aangeroepen worden zonder filiaalfilter. In dat geval worden alle aanwezige filialen geretourneerd.
Bij het aanmaken van een relatie wordt het meegegeven relationNumber nu ook gebruikt als relatienummer voor de nieuwe relatie, in plaats van het genereren van een nieuw relatienummer.
Probleem opgelost dat soms optrad bij findRelation waardoor een relatie niet werd geretourneerd ook al bestond die wel.
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.
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.
Kortingspercentage werd per ongeluk ook omgekeerd bij het opslaan van een tegenboeking. Dit gaf problemen in bijv. totaalberekening van een regel.
Negatieve decimale aantallen werden niet correct doorgegeven. Elk aantal werd afgerond doorgegeven.
Bij het uitvoeren van getJournals met een filter op kassabonnen of facturen worden de lijst met betaalwijzen (paymentList) en BTW-groepen (vatGroupList) nu ook correct gefilterd.
Bij het splitsen van een tafel via de API-functie moveTableOrder (welke vooral door de handheld gebruikt wordt), werd het werkpleknummer van de transactie altijd naar F1W1 gezet, in plaats van het werkpleknummer van de handheld. Dit veroorzaakte een synchronisatiefout in het geval van een Master/Slave-opstelling met meerdere Slaves.
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.
Bij het aanbetalen van een order via payTableOrder was het mogelijk dat de order van de tafel gehaald werd. Dit was een bug veroorzaakt door een eerdere bugfix in v1.7.7.4.
