De nieuwste versie van PostgreSQL gebruikt scram-sha-256 als authenticatiemethode. Dit wordt nog niet ondersteund door de API. Gebruik deze handleiding om PostgreSQL te "downgraden" van scram naar md5: https://docs.google.com/document/d/1uh4-D6Fa9YphXoxGjudM6O7Z3YeiVAfsUrKwSMTwb5U

Probleem met getArticlesVariants opgelost als er artikelen zijn zonder uitvoeringen (dit hoort niet voor te komen bij normaal gebruik).

Probleem met AccessViolation opgelost in placeTableOrder.

Vanaf 1 juli 2021 gelden nieuwe btw-regels voor e-commerce (zie hier voor meer info).

Dit betekent dat onder bepaalde omstandigheden gerekend moet gaan worden met het BTW-percentage van het land waar de order naartoe gaat, en niet meer met het BTW-percentage van het land waar de webshop gevestigd is.

De order-functies (saveOrder, queueBranchOrder, etc) en factuur-functies (saveInvoice, etc) hebben twee nieuwe eigenschappen gekregen: vatCountryCode en vatCountryIso3.

Door een van deze mee te geven kun je zorgen dat alle BTW wordt doorgerekend op basis van de BTW-tarieven die in MplusKASSA voor dát land ingesteld staan.

Geef je dit niet mee, dan wordt (zoals vanouds) gebruik gemaakt van de BTW-tarieven van het land van het filiaal waar de order op aangemaakt wordt.

De opvraag-functies (getOrder(s), getInvoice(s)) retourneren de vatCountryCode/vatCountryIso3 ook indien die ingesteld is.

Omdat vatCountryCode een MplusKASSA-specifieke nummering is, die niet per definitie overal bekend is, kun je ook gebruik maken van de ISO3 landcode van het land waar de order heen gaat, via vatCountryIso3.

De lijst van ISO3 codes is hier te vinden: https://en.wikipedia.org/wiki/ISO_3166-1_alpha-3

Fix bug in api calls getPurchaseDeliveries(V2) waar de formattering van de datum filter velden ervoor zorgde dat het datum filter niet functioneerde

aan de volgende API calls is een deliveryAddress toegevoegd :

• getPurchaseDeliveries
• getPurchaseDeliveriesV2
• getPurchaseOrders
• getPurchaseOrdersV2

Bugfix voor getOverview: Als er geen scopeValues argument werd meegegeven, dan werd er toch getracht om een scoped veld op te halen, dat leverde een database-fout op. Dat is nu opgelost.

Tevens blijft nu de scoped indicator in het resultaat null als je geen scopeValues hebt opgevraagd.

De functie getTerminalSettings retourneert nu ook of je tijdens de direct-afrekenen modus ook nog tafelkeuze hebt, via directPaymentModeAllowTableSelection.

Bij het wijzigen van een (tafel)bestelling of verkooporder kun je nu van een regel ook alleen de korting wijzigen en dat wordt nu correct opgeslagen.

Via de nieuwe API-functie changeTableProperty kan nu de VIP-status van de keukenbonnen van een tafel gewijzigd worden. In de toekomst wordt deze functie uitgebreid om meer (indirecte) eigenschappen van een tafel te kunnen wijzigen, zonder een hele tafelbestelling door te hoeven geven.

Het object OccupiedTableDetails bevat nu ook de eigenschap isVip die aangeeft of de keukenbonnen van de tafel op dat moment VIP-status hebben.

De API-functie getTerminalSettings retourneert nu ook of het bijbehorende filiaal een keukenscherm heeft (branchHasKitchenScreen).

Via de API-functie updateBatch kunnen categorieën (multi_cats) nu ook bijgewerkt worden.

De preparationList van regels in een order worden nu ook weer gevuld, bijv. als je getOrders aanroept.

De eigenschappen deliveryDate, deliveryPeriodBegin en deliveryPeriodEnd zijn nu ook aanpasbaar via saveOrder en updateOrder.

Bij het gedeeltelijk splitsen van een tafelbestelling (via moveTableOrder) worden de juiste keukenbonnen nu ook aangemaakt.

Fix voor bijwerken merk (brandName) van een artikel via createProduct of updateProduct.

Fix voor toekennen locatie aan keukenbonnen

Bugfix in updateProduct (eigenlijk in dieperliggende import-functie), waardoor je nu in één aanroep van updateProduct meerdere imports kunt doen met verschillende kaartkolommen.

Reduceer geheugengebruik van getStockHistoryV2

Probleem verholpen waardoor de getActiveEmployeeList call een databasefout rapporteerde.

De functie getPurchaseOrders(V2) ondersteunt nu ook het filteren op basis van de inkoopopdrachtstatus via de parameter purchaseOrderStates.

The account number (accountNumber) of (pre) payments on a receipt, invoice or order is now also correct when it is an account number for a specifc branch or workplace.

Nieuwe functie getStockCorrections welke voorraadcorrecties retourneert, zoals ook te vinden in de Qline onder Hoofdmenu > Voorraad > Correcties.

Verhelpt een conversiefout in getReceipts.

De functie getPurchaseOrdersV2 vult nu ook extPurchaseOrderId in (die bleef voorheen altijd NULL, ook al had deze wel een waarde).

De nieuwe functie reportAverageSpending retourneert een overzicht van de gemiddelde besteding per (bestel-)bon en per gast (indien gastenregistratie ingeschakeld is). Er kan gefilterd worden op periode, filiaal en medewerker.

De velden articleVariantId (artikel_uitvoering_id), quantityInPackaging (verpakkingsvorm_aantal_eenheden) en packagingType (verpakkingsvorm) zijn toegevoegd aan elke functie die betrekking heeft op de opslag en opvragen van inkoopopdrachten en inkoopleveringen.

De functie getOverviewFields retourneert nu per veld ook de kolom en rij zoals ze op de kaart staan. De gebruikte eigenschappen hiervoor zijn cardColumn en cardRow.

De functie reportTurnover retourneert nu pér turnoverGroupType een record, en niet meer cumulatief van alle typen. Het is namelijk verwarrend en onzinnig om bijv. omzetrekeningen en tussenrekeningen op te tellen.

Als je dat alsnog wilt doen, dan heb je natuurlijk achteraf alsnog de mogelijkheid om dat zelf te doen.

Daarnaast kun je ook filteren op turnoverGroupTypes. Als je het filter niet meegeeft krijg je alles terug.

De functie getReceipts retourneert nu ook betaalwijze-wissel bonnen (ook wel betaalwijze overboeking of betaalwijzeboeking genoemd). De receiptType van deze bonnen is RECEIPT-TYPE-PAYMENT-METHOD-TRANSFER.

Extra validatie toegevoegd vlak voordat dat de giftcard betaling geregisteerd wordt in RegisterGiftcardPayment

Filteren op einddatum werkt nu ook in de getStockHistoryV2 call.

De achterliggende query is nu ook efficienter. Veel calls zullen nu ook een duidelijker foutmelding geven bij onvoldoende geheugen.

The article property "Uitlopend" has been added discontinued. This property indicates that an article is still for sale, but only as long as stock lasts.

Ondersteuning voor de bestellijst

• getPurchaseBook haal de lijst op voor opgegeven filiaal
• savePurchaseBook vervang de lijst van opgegeven filiaal met opgegeven lijst
• addToPurchaseBook voeg de opgegeven artikelen toe aan de lijst van het opgegeven filiaal

Besteleenheid (orderQuantity) wordt nu ook opgeslagen door saveProduct en updateProduct.

Deze functies werken nu ook weer alle velden van de standaard artikeluitvoeringen correct bij.

Verbeterde afhandeling database fouten.

Voorheen werden alle query fouten het zelfde gemeld naar de client, namelijk dat er contact opgenomen moet worden met apisupport. Nu worden constraint fouten naar de client gemeld als een probleem met de aangeboden data want dit is vrijwel altijd de oorzaak.

Probleem verholpen waardoor payOrder weigerde een filiaalorder van een slave te betalen als deze order al naar de master gesynchroniseerd was.

getOverview ondersteund nu multi selectie velden in de select lijst.

De keuzes worden als een json array geretourneerd in de value.

getOverview heeft nu ondersteuning voor het filteren op multi selectie velden

Er zijn drie operators

• CONTAINS alle keuzes uit filter moeten aanwezig zijn op de kaart
• OVERLAP minimaal 1 keuze uit het filter moet aanwezig zijn
• IS alle keuzes en geen andere keuzes moeten aanwezig zijn

De keuzes moeten gecodeerd als json array meegegeven worden aan het filter.

Fix crash in getReceipts waarschijnlijk ook in alle gerelateerde calls zoals getInvoices, getOrders.

Op api.mpluskassa.nl resulteerd dit in een 502 Bad Gateway error van de loadbalancer.

getReceipts is nu ook een stuk sneller als er veel bonnen in het resultaat zitten.

Probleem opgelost waardoor databaseconnecties niet goed hersteld werden na een netwerkstoring.

Probleem verholpen waardoor het opslaan van orders, pakbonnen, facturen, kassabonnen vereiste dat je de averagePurchasePrice mee gaf terwijl dit een readonly-veld is.

Opslaan van orders, pakbonnen, facturen en kassabonnen vereist ten onrechte dat je de averagePurchasePrice meegeeft.

Probleem verholpen waardoor payOrder van backoffice order synchronisatie problemen met slaves kon veroorzaken.

Mogelijkheid om van een filiaalorder een kassabon te maken

Dit kan via queueBranchOrderPayment door de bookingMethod op te geven of payOrder met prepay=false

In bon-, factuur-, pakbon- en orderregels wordt nu ook de gemiddelde inkoopprijs geretourneerd averagePurchasePrice deze is van type xsd:decimal om meer dan 2 decimalen te kunnen ondersteunen.

Routines voor het opvragen en opslaan van artikel, relatie en medewerker kaarten ondersteunen nu meerdere categorieën.

Ondersteuning voor de vernieuwde artikeluitvoeringen.

• getArticleVariants
• newArticleVariant
• updateArticleVariant
• deleteArticleVariants

Het is nu mogelijk om getPurchaseOrders of getPurchaseOrdersV2 aan te roepen met purchaseOrderNumber of extPurchaseOrderId om een specifieke purchase order in te lezen.

Werking van savePurchaseOrder en savePurchaseOrderV2 verbeterd.

• extPurchaseOrderId is niet meer verplicht maar dan moet wel purchaseOrderNumber opgegeven zijn
• fix: functie maakte nieuwe purchaseOrder aan ingevallen waar hij eigenlijk een bestaande had moeten aanpassen

queueBranchOrder crashte als je geen extOrderId mee gaf.

Fixes in de articleVariants (artikel uitvoeringen).

• wijzigingen aan de standaard uitvoering worden nu ook doorgezet naar de kaart
• het instellen van een andere uitvoering als de standaard uitvoering werkt nu ook

Deze instelling werd door een naamswijziging nog niet correct uitgelezen in de API.

Wanneer een artikel met samengestelde artikelen op BPE werd gezet (bijv. via de Android-app) dan werden de subartikelen niet automatisch op BPE gezet.

Probleem in saveProduct verholpen waardoor deze mislukte zonder toelichting.

createAndPayTableOrder toegevoegd

getKitchenTicket call response uitgebreid met tafel of bestelnummer

createAndPayTableOrder toegevoegd

When lines are added (lineAdditions) during the start of a session (startSession), this will no longer cause an error (!m_IsOpgeslagen) in subsequent booking.

getApiVersion retourneert nu correct of een slave een filiaal- of een werkplek-slave is. Hiervoor werd altijd een filiaal-slave geretourneerd.

Geheugenlek verholpen bij gebruik van webhooks.

createAndPayTableOrder toegevoegd

API v26.3.0 bevatte een compilatiefout waardoor in elk geval het bijwerken van relaties (updateRelation) problemen kon opleveren.

De customfields van de artikel, relatie en medewerkerkaarten werkt nu met unicode.

(ook aanwezig in 24.0.2 maar niet in tussenliggende versies)

Bugfix voor getProducts waardoor deze weer altijd alle resultaten retourneert.

Diverse verbeteringen aan de stabiliteit.

The getConfiguration call works again.

De nieuwe functie getKitchenTickets kan gebruikt worden om keukenbonnetjes voor een bepaalde orderId of een bepaalde werkplek (branchNumber+workplaceNumber) op te vragen.

Performance van getProducts-call verbeterd voor artikelen met bereidingswijzen.

Nieuwe functie getTableListV3 die geen geregistreerde terminal meer vereist. Er moet wel een branchNumber meegegeven worden om aan te geven voor welk filiaal de tafels geretourneerd moeten worden.

Probleem hersteld waardoor handhelds ten onrechte de melding "non-existing order.relationNumber specified" terug kregen van de API.

Retourneert ten onrechte de volgende fout aan de handheld "non-existing order.relationNumber specified" bij het plaatsen van een bestelling.

De functie payOrder retourneert nu PAY_ORDER_RESULT_ORDER_ALREADY_INVOICED als de betaling mislukt omdat de order al gefactureerd is.

Validatie/foutmeldingen master/slave bestellingen uitgebreid voor API calls :

• createOrder
• createOrderV2
• payOrder
• saveOrder
• updateOrder
• updateOrderV2
• cancelOrder

Mogelijkheid om een slave order te betalen via API call payOrder ook als de bestelling nog niet op de slave aanwezig is.

Mogelijkheid om een slave order te annuleren via API call cancelOrder ook als de bestelling nog niet op de slave aanwezig is.

Gemiddelde inkoopprijs wordt nu ook teruggegeven met getProducts zie veld averagePurchasePrice

Geheugenlek verholpen.

Probleem verholpen waardoor getApiVersion soms access violations of integer overflows veroorzaakte.

De customfields van de artikel, relatie en medewerkerkaarten werkt nu met unicode.

The call getBranches once again works.

Probleem opgelost: Tafelbestellingen via de handheld kwamen niet meer binnen op het keukenscherm. Dit ging mis bij bestellingen op tafels waar al eerder op was besteld. Bestelling op lege tafel kwam wel goed binnen.

An incoming relationArticleDiscountList is once again properly processed.

In principe zelfde versie als 23.0.0, maar deze versie rapporteert zijn interne versienummer correct.

Externe referentie van de medewerker- (extEmployeeId) en relatiekaart (extRelationId) mag nu 512 karakters zijn, ipv. 50.

The function getTableList works again.

The function reportTurnoverByArticle now actually looks at the supplied turnoverGroupFilter.

De functie getTurnoverGroups kan nu aangeroepen worden met de parameter onlyActive om alleen omzetgroepen te retourneren die in gebruik zijn.

Nieuwe functie reportBranchPerformance die over een bepaalde periode per filiaal een aantal kernwaarden laat zien.

API v22.2.0 werkt niet goed samen met de laatste versie van de Q-line, daarom bij deze v22.2.1.

De functie getProducts is uitgebreid met de volgende functionaliteit:

• Er is een syncMarker veld toegevoegd aan preparationMethod.
• De product syncMarker word nu ook geupdate wanneer de preparationMethod.syncMarker wordt geüpdate.
• De syncMarker van de preparationMethod word ook gebruikt als je syncMarker als argument meegeeft aan de getProducts functie.

Prijsgroepen worden nu correct toegepast op basis van welke werkplek de bestelling plaats.

payOrder dacht van bepaalde orders ten onrechte dat dit filiaalorders waren en weigerde deze te betalen.

getPackingSlips werkt niet, geeft SQL error

getProducts() retourneert nu voor de bereidingswijzen (preparationMethod) ook de vatCode en vatPercentage.

Gebruik van ns:Uuid verwijderd sommige tools waaronder SoapUI gaven hier een foutmelding op.

It is now possible to indicate whether an order will be eaten in the establishment, or taken out. Use the property vatChange for this, with the possible values of VAT-CHANGE-TAKE-OUT and VAT-CHANGE-EAT-HERE.

queueBranchOrderPayment toegevoegd.

Met deze functie kunnen betalingen klaargezet worden voor filiaalorders die via queueBranchOrder aangemaakt zijn.

The function getArticlesInLayout didn't correctly return a different price set on a component article. It always returned the basis price of the article.

Regressie in functionaliteit van getStock ongedaan gemaakt. Als je getStock aanroept met branchNumber=0 krijg je nu weer de voorraad van alle filialen terug, in plaats van enkel die van het tussenfiliaal.

Nieuwe API call getSalePromotions toegevoegd hiermee kunnen de ingestelde sales en acties uitgelezen worden.

Resolved an issue in getStock when requesting stock from an intermediary branch during interbranch movements.

Resolved an issue in price calculation when a different vatPercentage is submitted, but no price.

De functie getAvailableTerminalList retourneert nu een SoapException als de Slave-configuratie niet compatibel is met tafelbestellingen.

Resolved an issue with missing column vor_bw_prijstype in certain functions.

Article ask-for is now also available through the API (article.askFor).

Price group (priceGroupNumber) added to the getBranches function.

Resolved an issue with missing column vor_bw_prijstype in certain functions.

getTerminalSettings() now also returns splitLineOnAddPreparationMethod

Solved an issue when working with preparation methods with a VAT percentage that differs from the normal VAT percentage of that preparation method.

It is now possible to call getProducts with productNumbers. This allows for the requesting of all the colour- and size-articles of a product.

Besides that, it is now also possible to add the parameter includeAllArticlesOfSelectedProducts when requesting by articleNumber, to include all the other colours and sizes of a product in the response.

The resullts of the function getOrderChanges have been improved in some instances.

Solved an issue where the API would fail when passing along the parameter siUnit in the function createProduct and updateProduct.

The resullts of the function getOrderChanges have been improved in some instances.

Resolved an issue that caused the API function queueBranchOrder to return a generic error when the supplied relationNumber did not exist in the administration. The generic error has been replaced with a specific error that explains that the relation could not be found.

The function getOrders once again returns entryBranchNumber, deliveryDate, deliveryPeriodBegin, deliveryPeriodEnd, invoiceAddress and deliveryAddress.

The API function getOrderChanges did not return the old and new total amount of a line if only the quantity of a line was changed. This made it hard to determine the financial consequences of a quantity change, since you would have to recollect a previous change to retrieve the price and use that in the calculation of the new amount. This will no longer be necessary.

When placing an order with text preparation methods, the entire line was being corrected and added again. That has been resolved now.

The installer for version 16.2.0 was missing a file. This has been resolved.

Delivery time (deliveryPeriod) will no longer be automatically filled out based on delivery date (deliveryDate), because this leads to delivery times of 00:00 (midnight).

The functions getPurchaseOrders and getPurchaseDeliveries no longer returns errors when the administration contains purchase orders or deliveries without lines.

Solved two issues where the API would give an unmerited error message, including one in findRelation.

Solved an issue where the API would fail when passing along the parameter siUnit in the function createProduct and updateProduct.

In various places the priceExcl is now being filled in, since this information is usually available.

Solved an issue where getPackingSlips would occasionally trigger errors.

New API function: getCurrentTableOrders()

If you use getStock with branchNumber 0, you now receive stock of all branches.

Solved an issue that temporarily made it impossible to create table orders.

Solved an issue when working with preparation methods with a VAT percentage that differs from the normal VAT percentage of that preparation method.

Solved an issue where getPackingSlips did not work when a packing slip was linked to a front-office transaction instead of a back-office transaction.

Solved an issue with getPackingSlips.

Solved a small issue in regards to delivery times of a table order.

Resolved an issue in getFinancialJournalByCashCount which could cause discrepancies in the resulsts.

Resolved an issue with the handheld and table orders containing a preparation method.

getPackingSlips return an error when filtering on date. Filtering on syncMarker did work properly.

Also when using getOrder to retrieve branch orders, the field order.branchOrderNumber will be filled, instead of order.orderNumber.

Fixed an issue in getProducts which caused almost all requests to fail.

When retrieving branch orders, the field order.branchOrderNumber will be filled, instead of order.orderNumber.

The fields article.colourSequenceNumber and article.sizeSequenceNumber have been added, this designate the position of the colour and size in the colour list and the size list, respectively.

Saving the field extRelationId now works correctly.

The API now checks if a valid siUnit is supplied when using createProduct and updateProduct. An invalid value will trigger a SOAP fault that explains this.

New function for retrieving packing slips: getPackingSlips

New API functions for managing activities:

• getActivities
• createActivity
• updateActivity
• deleteActivity

Also added the following properties:

• receipt.activityId
• invoice.activityId
• order.activityId
• proposal.activityId
• packingSlip.activityId

And the following filter properties:

• getReceipts(activityId)
• getInvoices(activityId)
• getOrders(activityId)
• getProposals(activityId)

The line.data now also contains (when applicable) cancelledQuantity and cancelledDecimalPlaces to return how much of an order line has been cancelled.

New function for retrieving cashdrawer balancing moments: getCashDrawerBalancingList

New V2 of the functions savePurchaseOrderV2 and savePurchaseDeliveryV2 where purchasePrice is a string instead of an int64. This allows for decimal values with more than two decimal places.

New V2 of the functions getPurchaseOrdersV2 and getPurchaseDeliveriesV2 that also return purchasePrice as a string instead of a int64 .

All functions that return relationNumber and relationName, now also return relationCategoryId and relationBankAccountNumber (e.g. getOrders, getReceipts, getInvoices).

The function getOrder now also returns a filled-in paymentList (as long as actual order down payments were made of course).

When articles, relations or employees have more than 117 cards fields, the creation or updating of these cards through the API did not work.

The resullts of the function getOrderChanges have been improved in some instances.

The function getOrder now also returns a filled-in paymentList (as long as actual order down payments were made of course).

getTicketCounterSales now also returns entryTimestamp and financialDate.

When retrieving tables (getTableList and getTableListV2), you will also receive configured NFC tags (also known as RFID or MIFARE). Amongst other things, this enables the Android order app to open tables based on NFC tags.

Solved an issue with lock-ups during execution of deliverOrder.

Added new API call: getRelationPoints. The syncMarker that is used here has also been added as relationPointsSyncMarker to the result of getCurrentSyncMarkers.

getTableListV2 now also returns the OnFloorPlan property.

Solved an issue when using component articles through the API.

Solved an issue: When applying a discount percentage to an article (eg. in the handheld), this article will no longer be designated as a return.

The function getOrder now also returns a filled-in paymentList (as long as actual order down payments were made of course).

Added support for the TURNOVER_GROUP_TYPE_BALANCE_UPGRADE type. In case unknown types are detected, the API will return these as TURNOVER_GROUP_TYPE_UNKNOWN.

Solved an issue when using component articles through the API.

payTableOrder now returns an extended error message, when certain problems occur.

Added support for CA-signed certificates when calling Webhooks.

The API now also supports the webhook event completeSession. This event is called when using the function payTableOrder(V2).

Resolved an issue in getFinancialJournalByCashCount which could cause discrepancies in the resulsts.

This version correctly works with the 11.0.0 database.

This version does not yet correctly work with the 11.0.0 database.

Under special circumstances, it was possible that createProduct and updateProduct froze.

The workplace number that is supplied with queueBranchOrder is now actually used when saving the branch order, instead of reverting to the default workplace 1.

The function getReceipts() has received an extra includeOrderReferences request parameter, which can be used to request references (receipt.orderIds) to the order(s) that preceded each receipt in the response. Default behaviour used to be that these references were automatically included, but this is no longer the case because it can severely impact performance.

We suspect few used these references, but if you are please update your integration. The PHP client has also been updated to support this parameter.

When articles, relations or employees have more than 117 cards fields, the creation or updating of these cards through the API did not work.

Under special circumstances, it was possible that createProduct and updateProduct froze.

Solved an issue with getRelations.

Solved an issue with getPurchaseOrders and getPurchaseDeliveries.

The function getShifts() now also returns the field reference.

New function deliverOrderV2 that enables you to create partial shipments. This makes it possible to create multiple packing slips of an order.

New function getPackingSlipsByOrder that returns the packing slip(s) of the given order.

It is now possible to retrieve related transaction details for EFT (or PIN) payments. You need to have the correct authorization to see this data. To find out which autorisation you have, you can check your Partner Page.

The API function getProducts now at most returns syncMarkerLimit number of articles instead of products. However, when the first product contains more than this limit of articles, this product will be returned completely. Otherwise the situation could occur wherein getProducts returns nothing at all.

The API function getProducts using a filter such as onlyActive and a syncMarker could fail to return some of the changed articles since the provided syncMarker. This could result in articles not being returned by getProducts.

The API function getButtonLayout now returns a lay-out based on the assumption that main groups are always shown above the sub groups and article buttons. As is the case with the Android app.

With every API call that has terminal as a parameter, the Last ping time will be also updated.

New functions for the management of proposals:

• getProposals - retrieve list of proposals
• getProposal - retrieve single proposal
• saveProposal - save new proposal or change existing proposal
• cancelProposal - cancel proposal, where possible
• createOrderFromProposal - create order from proposal, where possible
• createInvoiceFromProposal - create invoice from proposal, where possible

New function getArticleGroupChanges() that returns all changed article groups since the previous syncMarker. It is also possible to filter on specific groupNumbers. The difference between this function and the already existing getArticleGroups is that the latter returns article groups in their hierarchical structure, while the new function returns the article groups in a "flat" list. Use the parentGroupNumber property to determine where the changed article group should go.

It was possible for the VAT percentages of articles in the componentArticleList to be wrong. It was also possible that articles erroneously occured multiple times. This has been resolved.

The lines of receipts, orders and invoices now contain optional metadata related to Webhooks. These are the following optional properties:

• line.webhookData.webhookLineId - The UUID of the line regel as communicated through the Webhooks.
• line.webhookData.webhookConsumerId - (optional) The UUID of the Webhook Consumer (external application) if this line has been added by this external application.
• line.webhookData.webhookExternalDiscount.discountId - (optional) The UUID of the discount if it has been added by a Webhook Consumer.
• line.webhookData.webhookExternalDiscount.discountDescription - (optional) Description of the external discount if it was supplied.
• line.webhookData.webhookExternalDiscount.webhookConsumerId - (optional) The UUID of the Webhook Consumer (external application) that added this discount.
• line.webhookData.webhookExternalDiscount.discountPercentage - (optional) The externally applied discount percentage.
• line.webhookData.webhookExternalDiscount.discountAmount - (optional) The externally applied discount amount.

New article properties:

• article.course - Indicates to which course the article belongs, including name, abbreviaton and sequence number of the course.
• article.specialPrice - Indicates whether the article has special price handling, such as "Free", "Ask price (positive)" or "Ask price (negative)".
• article.showPreparationMethodsDirectly - Indicates whether the available preparation methods should be shown directly after selecting the article.
• article.showPreparationMethodsPerGroup - Indicates whether the available preparation methods should be shown per group or all at once.

A sales order (order) now contains the properties onDeliveryUrl and onInvoiceUrl. The URL's that you supply here will be opened from MplusKASSA in the default browser at the moment that you create a packing slip or an invoice from the order.

A turnover group number (turnoverGroup) outside of the supported range (0-999) will now be refused.

After completing a request the API now takes much less time to get ready to accept the next request.

Solved an issue with getPurchaseOrders and getPurchaseDeliveries.

New function deliverOrderV2 that enables you to create partial shipments. This makes it possible to create multiple packing slips of an order.

New function getPackingSlipsByOrder that returns the packing slip(s) of the given order.

The API function getProducts now at most returns syncMarkerLimit number of articles instead of products. However, when the first product contains more than this limit of articles, this product will be returned completely. Otherwise the situation could occur wherein getProducts returns nothing at all.

The API function getProducts using a filter such as onlyActive and a syncMarker could fail to return some of the changed articles since the provided syncMarker. This could result in articles not being returned by getProducts.

The API function getButtonLayout now returns a lay-out based on the assumption that main groups are always shown above the sub groups and article buttons. As is the case with the Android app.

With every API call that has terminal as a parameter, the Last ping time will be also updated.

A turnover group number (turnoverGroup) outside of the supported range (0-999) will now be refused.

Orders with weight articles that were updated through the API were always removed and added again, even though the respective lines did not change.

New function getArticleGroupChanges() that returns all changed article groups since the previous syncMarker. It is also possible to filter on specific groupNumbers. The difference between this function and the already existing getArticleGroups is that the latter returns article groups in their hierarchical structure, while the new function returns the article groups in a "flat" list. Use the parentGroupNumber property to determine where the changed article group should go.

It was possible for the VAT percentages of articles in the componentArticleList to be wrong. It was also possible that articles erroneously occured multiple times. This has been resolved.

getCashCountList now also returns the details of each extra workplace that was included in the count, through cashCountExtraWorkplaceList.

getReceiptsByCashCount could return more receipts than intended. Receipts from other branches that had a coincidental overlap with the selected cash count were also returned.

Orders with weight articles that were updated through the API were always removed and added again, even though the respective lines did not change.

The imageList of an article is now equal for all articles of a product.

The properties priceIncl, priceExcl, originalPriceIncl and originalPriceExcl are now filled out where they were missing.

The function getReceipts now also returns answered questions for every receipt, that were asked during the check-out process. These answers (and the accompanying questions) can be found in the property receipt.answerList.

Added the function setSubTableCount.

This function sets the maximum amount of sub tables of a table.

cancelInvoice has now been implemented. Cancelling an invoice creates a credit invoice for the cancelled invoice.

Where applicable, getArticleGroups now also returns the image of an article group (through image).

New functions: getRetailSpaceRental() and getRetailSpaceRentals().

New properties: order.orderBarcode, receipt.receiptNumber, receipt.receiptBarcode, invoice.invoiceBarcode, saveInvoice.info.invoiceNumber, saveInvoice.info.invoiceBarcode, articleStockHistory.invoiceBarcode, articleStockHistory.receiptBarcode.

New property: line.data.turnoverGroupAccountNumber. This contains the account number for the specific turnover group and the specific branch.

New functions getPurchaseOrders, getPurchaseDeliveries, savePurchaseOrder and savePurchaseDelivery, to respectively request and store purchase orders and purchase deliveries.

getInvoices and getReceipts now also return orderIds when the invoices or receipts are based of order(s). The property extOrderIds will also be returned when the original order(s) had these.

New function getLicenceInformation which can be used to retrieve information about the license, including which modules are enabled.

The function getLicenseInformation now also returns the value isGKS with each branch, which indicates whether or not the licensed branch has a GKS license.

New functions added to provide support for sub tables (e.g. table 1A, 1B, etc):

• getTableListV2
• getTableOrderCourseListV2
• requestNextTableOrderCourseV2
• cancelTableOrderV2
• printTableReceiptV2

New fields for sub tables:

• order.tableSubNumber
• MoveTableOrderRequest.tableSubNumber
• GetTableOrderRequest.tableSubNumber
• ReleaseTableRequest.tableSubNumber
• GetTableOrderCourseListResponse.tableSubNumber

If these new fields are not supplied, the default sub table 1 (A) will be used.

The property product.description will never be based on the description of a non-active article, if there are also active articles present.

The recent addition of turnoverGroupAccountNumber caused an error when it was not filled in.

Solved an issue that could occur when determining a free articleNumber when inserting new articles.

New function getTicketCounterSales().

Solved an issue that could occur when determining a free articleNumber when inserting new articles.

It was possible for the VAT percentages of articles in the componentArticleList to be wrong. It was also possible that articles erroneously occured multiple times. This has been resolved.

The lines of receipts, orders and invoices now contain optional metadata related to Webhooks. These are the following optional properties:

• line.webhookData.webhookLineId - The UUID of the line regel as communicated through the Webhooks.
• line.webhookData.webhookConsumerId - (optional) The UUID of the Webhook Consumer (external application) if this line has been added by this external application.
• line.webhookData.webhookExternalDiscount.discountId - (optional) The UUID of the discount if it has been added by a Webhook Consumer.
• line.webhookData.webhookExternalDiscount.discountDescription - (optional) Description of the external discount if it was supplied.
• line.webhookData.webhookExternalDiscount.webhookConsumerId - (optional) The UUID of the Webhook Consumer (external application) that added this discount.
• line.webhookData.webhookExternalDiscount.discountPercentage - (optional) The externally applied discount percentage.
• line.webhookData.webhookExternalDiscount.discountAmount - (optional) The externally applied discount amount.

New article properties:

• article.course - Indicates to which course the article belongs, including name, abbreviaton and sequence number of the course.
• article.specialPrice - Indicates whether the article has special price handling, such as "Free", "Ask price (positive)" or "Ask price (negative)".
• article.showPreparationMethodsDirectly - Indicates whether the available preparation methods should be shown directly after selecting the article.
• article.showPreparationMethodsPerGroup - Indicates whether the available preparation methods should be shown per group or all at once.

A turnover group number (turnoverGroup) outside of the supported range (0-999) will now be refused.

getCashCountList now also returns the details of each extra workplace that was included in the count, through cashCountExtraWorkplaceList.

getReceiptsByCashCount could return more receipts than intended. Receipts from other branches that had a coincidental overlap with the selected cash count were also returned.

The imageList of an article is now equal for all articles of a product.

The properties priceIncl, priceExcl, originalPriceIncl and originalPriceExcl are now filled out where they were missing.

The function getReceipts now also returns answered questions for every receipt, that were asked during the check-out process. These answers (and the accompanying questions) can be found in the property receipt.answerList.

The properties order.lineList.line.pluNumber, .supplierRelationNumber and .supplierArticleNumber are now also filled out.

Since Q-line v8.0.0 it was possible to manage article button per branch. These locally managed article buttons are now also supported by the API.

It is now possible to import priceGroupList and salesPriceList through createProduct and updateProduct.

The property vatGroupList is now always present, even when its contents are empty.

When the pickup-and-delivery module is enabled, a new order will produce table-order-tickets, instead of order tickets

Solved an issue with stock changes caused by order changes.

Optimalisation which drastically reduces the overhead of each API call.

If the total of prepay payments is lower than the amount that was going to be prepaid, the API will now return an error.

When calling saveInvoice without a financialDate, the API did not automatically use the current financial date, but instead return an error message: Voorwaarde niet voldaan: BoekDag != TDate()

The function getReceipts now also returns answered questions for every receipt, that were asked during the check-out process. These answers (and the accompanying questions) can be found in the property receipt.answerList.

The imageList of an article is now equal for all articles of a product.

The properties priceIncl, priceExcl, originalPriceIncl and originalPriceExcl are now filled out where they were missing.

Solved a sometimes occurring issue with printing tickets when moving the contents of a table to another table.

When calling saveInvoice without a financialDate, the API did not automatically use the current financial date, but instead return an error message: Voorwaarde niet voldaan: BoekDag != TDate()

Optimalisation which drastically reduces the overhead of each API call.

To prevent a crash, a change has been made in the function that claims tables for specific workplaces.

Article links can now be read from the API through the property article.linkedArticleList.

To prevent a crash, a change has been made in the function that claims tables for specific workplaces.

Resolved an issue that could occur when processing composite articles.

Added support for v7.1.0.

Article links can now be read from the API through the property article.linkedArticleList.

To prevent a crash, a change has been made in the function that claims tables for specific workplaces.

To prevent a crash, a change has been made in the function that claims tables for specific workplaces.

Resolved an issue that could occur when processing composite articles.

getDatabaseVersion now contains serverMajorNumber, serverMinorNumber and serverRevisionNumber, which is the version of the database server. getApiVersion now contains serviceDate, which is the date of the machine where the API service is running. serverDate is now used for the date of the machine where the database is running.

The property tableStatus now remains set to TABLE-STATUS-TAKEN-AND-RECEIPT-PRINTED until a table has finished or until a change has been made to the table. Previously the table would change to TABLE-STATUS-TAKEN-AND-ACTION-REQUIRED or TABLE-STATUS-TAKEN-AND-TIME-LIMIT-REACHED after a variable amount of time.

getReceiptsByCashCount could return the same receipt for multiple cash counts . Obviously this was not our intent and has now been fixed.

Solved an issue that could occur when determining a free articleNumber when inserting new articles.

getReceiptsByCashCount could return the same receipt for multiple cash counts . Obviously this was not our intent and has now been fixed.

getReceipts didn't return results anymore when you filtered on date. Filtering by syncMarker did still work.

New function getReceiptsByCashCount() which can be used to retrieve all receipts in the period of the supplied cash count.

When reading tables through getTableList the returned tables now contain the properties createTimestamp (when the current order on the table started), changeTimestamp (when the current order on the table was changed), totalInclAmount, totalExclAmount and prepaidAmount. When the table has no current order, these properties will not be present.

Solved an issue with saveInvoice which caused the financial date that was supplied through financialDate to not be used with new invoices.

registerTerminal now returns an error message if you try to register a terminal without an uniqueDeviceIdentifier.

ArticleStockHistory now contains internalShipmentNumber and internalDeliveryNumber when relevant.

Added function getStockHistoryV2 that can be used to request stock history for more than one branch number.

Article now has a property stockArticle that signifies whether the article is a stock article.

getStockHistory now also returns invoiceNumber, receiptNumber and deliveryNumber in ArticleStockHistory (where applicable).

registerTerminal now returns an error message if you try to register a terminal without an uniqueDeviceIdentifier.

Minimal changes to part of the service defintion file (WSDL), which should solve the problem with a missing definition of a property type called ns__NumberLst.

To prevent a crash, a change has been made in the function that claims tables for specific workplaces.

getReceipts didn't return results anymore when you filtered on date. Filtering by syncMarker did still work.

New function getReceiptsByCashCount() which can be used to retrieve all receipts in the period of the supplied cash count.

registerTerminal now returns an error message if you try to register a terminal without an uniqueDeviceIdentifier.

ArticleStockHistory now contains internalShipmentNumber and internalDeliveryNumber when relevant.

Added function getStockHistoryV2 that can be used to request stock history for more than one branch number.

Article now has a property stockArticle that signifies whether the article is a stock article.

getStockHistory now also returns invoiceNumber, receiptNumber and deliveryNumber in ArticleStockHistory (where applicable).

Solved issues in getOrderChanges and getArticlesInLayout.

v6.3.0 was a wrong build, old bugs were reintroduced. This release is what v6.3.0 should have been.

Resolved an issue that could occur when processing composite articles.

getReceipts didn't return results anymore when you filtered on date. Filtering by syncMarker did still work.

New function getReceiptsByCashCount() which can be used to retrieve all receipts in the period of the supplied cash count.

Solved issues in getOrderChanges and getArticlesInLayout.

Minimal changes to part of the service defintion file (WSDL), which should solve the problem with a missing definition of a property type called ns__NumberLst.

Solved issues with regards to the release of table claims after (pre)payment and moving (parts of) orders.

Moving a full order to another table through moveTableOrder works properly again.

Solved an issue that could occur when calling payTableOrder on a table order with text preparation methods.

Solved an issue in getOrderChanges that prevented requests based on syncMarker from functioning properly.

Protocol version 1.0.1

A call to registerTerminal now also releases any possible claims to tables the terminal had.

getButtonLayout now also contains the optionally defined default main group (defaultMainGroup) and sub group (defaultSubGroup).

New function getOrderChanges, returns all changes to (table) orders, grouped by version number.

Downgrade to API v1.0.0.

Solved an issue in getOrderChanges that prevented requests based on syncMarker from functioning properly.

Protocol version 1.0.1

A call to registerTerminal now also releases any possible claims to tables the terminal had.

getButtonLayout now also contains the optionally defined default main group (defaultMainGroup) and sub group (defaultSubGroup).

New function getOrderChanges, returns all changes to (table) orders, grouped by version number.

New functions: getRetailSpaceRental() and getRetailSpaceRentals().

getStockHistory now also returns the stock values before (beforeCorrectionQuantity) and after (afterCorrectionQuantity) the correction, but of course only when the change was made through a correction. Even when the stock values before and after are equal, the change will be returned, so you can rely on afterCorrectionQuantity being present.

When getStock is requested based on stockId, the result is now also sorted on stockId.

The property article.categoryId was never being filled, even though it was defined in the object and could have a database value. This has now been added.

This releasenote does not really apply to the API, but is being placed here so the API developers will also receive it. It is now possible to submit an issue report for a specific API directly from the patner page. This will help our support team quickly determine the subject of the issue.

invoiceAddress and deliveryAddress is now properly stored when calling queueBranchOrder

New properties: order.orderBarcode, receipt.receiptNumber, receipt.receiptBarcode, invoice.invoiceBarcode, saveInvoice.info.invoiceNumber, saveInvoice.info.invoiceBarcode, articleStockHistory.invoiceBarcode, articleStockHistory.receiptBarcode.

The recent addition of turnoverGroupAccountNumber caused an error when it was not filled in.

New property: line.data.turnoverGroupAccountNumber. This contains the account number for the specific turnover group and the specific branch.

registerTerminal now returns an error message if you try to register a terminal without an uniqueDeviceIdentifier.

ArticleStockHistory now contains internalShipmentNumber and internalDeliveryNumber when relevant.

Added function getStockHistoryV2 that can be used to request stock history for more than one branch number.

Article now has a property stockArticle that signifies whether the article is a stock article.

getStockHistory now also returns invoiceNumber, receiptNumber and deliveryNumber in ArticleStockHistory (where applicable).

Solved an issue with saveInvoice which caused the financial date that was supplied through financialDate to not be used with new invoices.

Solved an issue that could occur when calling payTableOrder on a table order with text preparation methods.

Solved an issue that caused wrong numbers to be returned when using create and update of product, relation and employee.

When getStock is requested based on stockId, the result is now also sorted on stockId.

getStockHistory now also returns the stock values before (beforeCorrectionQuantity) and after (afterCorrectionQuantity) the correction, but of course only when the change was made through a correction. Even when the stock values before and after are equal, the change will be returned, so you can rely on afterCorrectionQuantity being present.

Allergens per article can be requested and saved. See the property allergenList of article for the required structure.

getArticlesInLayout now also uses the default price groups of the terminal that is doing the request and also takes into account differing prices for the specific branch.

Minimal changes to part of the service defintion file (WSDL), which should solve the problem with a missing definition of a property type called ns__NumberLst.

getButtonLayout now also contains the optionally defined default main group (defaultMainGroup) and sub group (defaultSubGroup).

New type for stock changes: STOCK_HISTORY_TYPE_MANUAL

getProducts has been heavily optimized to increase speed.

When getStock is requested based on stockId, the result is now also sorted on stockId.

getStockHistory now also returns the stock values before (beforeCorrectionQuantity) and after (afterCorrectionQuantity) the correction, but of course only when the change was made through a correction. Even when the stock values before and after are equal, the change will be returned, so you can rely on afterCorrectionQuantity being present.

paymentList in getJournals once again has contents, as intended.

The property product.description will never be based on the description of a non-active article, if there are also active articles present.

registerTerminal now returns an error message if you try to register a terminal without an uniqueDeviceIdentifier.

ArticleStockHistory now contains internalShipmentNumber and internalDeliveryNumber when relevant.

Added function getStockHistoryV2 that can be used to request stock history for more than one branch number.

Article now has a property stockArticle that signifies whether the article is a stock article.

getStockHistory now also returns invoiceNumber, receiptNumber and deliveryNumber in ArticleStockHistory (where applicable).

Solved an issue with saveInvoice which caused the financial date that was supplied through financialDate to not be used with new invoices.

When getStock is requested based on stockId, the result is now also sorted on stockId.

getStockHistory now also returns the stock values before (beforeCorrectionQuantity) and after (afterCorrectionQuantity) the correction, but of course only when the change was made through a correction. Even when the stock values before and after are equal, the change will be returned, so you can rely on afterCorrectionQuantity being present.

getProducts has been heavily optimized to increase speed.

Entering a value of PICKUP in the deliveryMethod of an order now translates into an actual pickup order, and a value of DELIVERY translates into a delivery order.

The function getTableList now also returns whether or not a table is ready to be served, through the tableStatus TABLE_ORDER_READY_TO_BE_SERVED.

New function getMessages() which returns the messages that have been sent to a specific workplace (branchNumber and terminalNumber). Optionally messages can be retrieved from a specific starting message ID (sinceMessageId). You can also specify whether the messages should be registered as having been "read" (setDelivered) and whether to only return unread messages (onlyUndelivered).

Account numbers through getTurnoverGroups and getPaymentMethods(V2) are now always returned, even if they have a value of zero or lower.

getStockHistory now also returns the stock values before (beforeCorrectionQuantity) and after (afterCorrectionQuantity) the correction, but of course only when the change was made through a correction. Even when the stock values before and after are equal, the change will be returned, so you can rely on afterCorrectionQuantity being present.

When getStock is requested based on stockId, the result is now also sorted on stockId.

New type for stock changes: STOCK_HISTORY_TYPE_MANUAL

Entering a value of PICKUP in the deliveryMethod of an order now translates into an actual pickup order, and a value of DELIVERY translates into a delivery order.

The sales unit of an article is now also available through the API, in the property siUnit.

imageURL was not being filled in correctly in all applicable situations.

Where possible getStockHistory now returns the following related properties: stockId, packingSlipId, invoiceId, receiptId or correctionNumber.

payOrder now checks whether or not the supplied payment methods exist.

Solved an issue with saveInvoice which caused the financial date that was supplied through financialDate to not be used with new invoices.

getStockHistory now also returns the stock values before (beforeCorrectionQuantity) and after (afterCorrectionQuantity) the correction, but of course only when the change was made through a correction. Even when the stock values before and after are equal, the change will be returned, so you can rely on afterCorrectionQuantity being present.

When getStock is requested based on stockId, the result is now also sorted on stockId.

getOrder now returns GET_ORDER_RESULT_NOT_FOUND when an empty orderId is supplied, in stead of an unintended error message.

getProducts has been heavily optimized to increase speed.

getOrder now returns GET_ORDER_RESULT_NOT_FOUND when an empty orderId is supplied, in stead of an unintended error message.

imageURL was not being filled in correctly in all applicable situations.

Where possible getStockHistory now returns the following related properties: stockId, packingSlipId, invoiceId, receiptId or correctionNumber.

Solved a problem that caused a failure when trying to load products based on PLU number.

Solved an issue that caused various functions to silently fail.

Solved an issue that prevented being able to split a table.

Solved an issue that could cause a database failure while trying to save a table order.

When creating a receipt for a table, it was possible that the API thought you were trying to split up the table order.

This caused the table to remain open, even though there was nothing left on the table.

payTableOrderV2 added, that accepts an additional keepTableName, which does what it says.

getTerminalSettings now returns the property askToKeepTableName, which indicates if this question should be asked when registering payment of a table.

When the button layout that you get through getButtonLayout contains non-existing articles, those are converted to text buttons and the button text is appended with "(article missing)."

The object Terminal now also contains the optional properties terminalSoftwareName and terminalSoftwareVersion. When these are filled out when calling registerTerminal, the contents of these values is also registered. Besides that the function now also registers when it was last called.

It is now possible to pay orders that consist of only text lines.

Solved an issue in getOrderChanges that prevented requests based on syncMarker from functioning properly.

New function getOrderChanges, returns all changes to (table) orders, grouped by version number.

When getStock is requested based on stockId, the result is now also sorted on stockId.

getStockHistory now also returns the stock values before (beforeCorrectionQuantity) and after (afterCorrectionQuantity) the correction, but of course only when the change was made through a correction. Even when the stock values before and after are equal, the change will be returned, so you can rely on afterCorrectionQuantity being present.

When getStock is requested based on stockId, the result is now also sorted on stockId.

getStockHistory now also returns the stock values before (beforeCorrectionQuantity) and after (afterCorrectionQuantity) the correction, but of course only when the change was made through a correction. Even when the stock values before and after are equal, the change will be returned, so you can rely on afterCorrectionQuantity being present.

When getStock is requested based on stockId, the result is now also sorted on stockId.

getStockHistory now also returns the stock values before (beforeCorrectionQuantity) and after (afterCorrectionQuantity) the correction, but of course only when the change was made through a correction. Even when the stock values before and after are equal, the change will be returned, so you can rely on afterCorrectionQuantity being present.

When getStock is requested based on stockId, the result is now also sorted on stockId.

getStockHistory now also returns the stock values before (beforeCorrectionQuantity) and after (afterCorrectionQuantity) the correction, but of course only when the change was made through a correction. Even when the stock values before and after are equal, the change will be returned, so you can rely on afterCorrectionQuantity being present.

When getStock is requested based on stockId, the result is now also sorted on stockId.

getStockHistory now also returns the stock values before (beforeCorrectionQuantity) and after (afterCorrectionQuantity) the correction, but of course only when the change was made through a correction. Even when the stock values before and after are equal, the change will be returned, so you can rely on afterCorrectionQuantity being present.

When getStock is requested based on stockId, the result is now also sorted on stockId.

getStockHistory now also returns the stock values before (beforeCorrectionQuantity) and after (afterCorrectionQuantity) the correction, but of course only when the change was made through a correction. Even when the stock values before and after are equal, the change will be returned, so you can rely on afterCorrectionQuantity being present.

When getStock is requested based on stockId, the result is now also sorted on stockId.

getStockHistory now also returns the stock values before (beforeCorrectionQuantity) and after (afterCorrectionQuantity) the correction, but of course only when the change was made through a correction. Even when the stock values before and after are equal, the change will be returned, so you can rely on afterCorrectionQuantity being present.

When getStock is requested based on stockId, the result is now also sorted on stockId.

getStockHistory now also returns the stock values before (beforeCorrectionQuantity) and after (afterCorrectionQuantity) the correction, but of course only when the change was made through a correction. Even when the stock values before and after are equal, the change will be returned, so you can rely on afterCorrectionQuantity being present.

When getStock is requested based on stockId, the result is now also sorted on stockId.

getStockHistory now also returns the stock values before (beforeCorrectionQuantity) and after (afterCorrectionQuantity) the correction, but of course only when the change was made through a correction. Even when the stock values before and after are equal, the change will be returned, so you can rely on afterCorrectionQuantity being present.

New type for stock changes: STOCK_HISTORY_TYPE_MANUAL

imageURL was not being filled in correctly in all applicable situations.

updateStock no longer returns an error state if the stock of a non-stock article is updated.

Solved a problem that caused a failure when trying to load products based on PLU number.

It was not possible to enter duplicate extArticleId's through the API, evne though it was not blocked in the database. The API now no longer checks for the existence of an extArticleId.

Solved an issue that was present since v2.1.0 that prevented turnoverGroup from being changed through createProduct and updateProduct.

When returning a branchAccountNumberList, the first extBranchId was never filled, even when it did exist.

getProducts returned erroneously returned the same article groups multiple times in the groupNumbers and sortOrderGroupList lists of articles.

queueBranchOrder was not yet checkink for duplicate extOrderId's in its own "buffer". This meant that if you were quick about it, you could add multiple orders with the same extOrderId.

getTurnoverGroups was returning an error message if you were using it in combination with separately configured account numbers per branch.

When the Mplus API Service is not run as a service, but directly or through a batch file, a blue text reading "MplusQservice running..." was shown in the top left corner. This text is now hidden by default. Through the start argument --visible this text can be made visisble again.

Each imageList no longer contains images that were deleted.

Support added for stock amounts (quantity), customer balances (balance) and customer credit limits (creditLimit) higher than 2.147.483.647.

Much optimization in processing orders and invoices. Amongst other things, this will reduce the total time it takes to save a table order.

As configured under the setting "POS > Tables > Remember table description", the name of a table will now be properly reset or remembered after completion.

Solved an issue introduced in v2.1.0 where turnover groups were always set to 0 if they were not fully configured.

Solved an issue introduced in v2.1.0 when saving orders.

Solved an issue where the imageList of an article sometimes contained the same image multiple times.

Solved an issue where preparation methods with an article number higher than 2.147.483.647 misfunctioned.

This release has been replaced by v2.1.1.

Solved an issue where transfer of payment between payment methods was not properly returned in the daily totals. This affected getJournals.

Both getInvoices and getReceipts had the problem that when you supplied a syncMarker higher than the highest value in the database, the function ignored the entire syncMarker filter and just started returning data from the start.

The functies getRelations, getProducts, getEmployees, getOrders, getInvoices and getReceipts are now all limited by the predefined default --sync_marker_limit. It is also possible to overwrite this limit with the syncMarkerLimit that can be added to the request. Naturally, the syncMarkerLimit only works in combination with syncMarker.

Solved an issue that occasionally occurred with findRelation, where it would not return the relation even though it did exist.

Solved an issue that occurred when birthDate was not given a value when adding (createRelation) or updating (updateRelation) a relation.

The "table-moved" ticket that is generated through the moveTableOrder function now correctly applies word aliases (this prevent the occurence of {Tafel} on the ticket). Also the employee is now properly displayed on the ticket.

When calling getProducts, getRelations and getEmployees and filtering on syncMarker, the results are now also returned sorted by syncMarker. This is something you would probably have to do yourself anyway when processing the results.

When getProducts is used to retrieve all products since a specific syncMarker, the product now contains all its articles in the articleList instead of just the articles since the provided syncMarker.

Because of our transition to a new IDE, we could no longer build the Mplus API Service as a console application. The log file of the API must now explicitly be set through the start up argument --output.

Solved a problem where transfer of payment between payment methods was not properly returned in the daily totals. This affected getJournals.

Both getInvoices and getReceipts had the problem that when you supplied a syncMarker higher than the highest value in the database, the function ignored the entire syncMarker filter and just started returning data from the start.

The functies getRelations, getProducts, getEmployees, getOrders, getInvoices and getReceipts are now all limited by the predefined default --sync_marker_limit. It is also possible to overwrite this limit with the syncMarkerLimit that can be added to the request. Naturally the syncMarkerLimit only works in combination with syncMarker.

getCashCountList now requires a WorkplaceYearNumber instead of a YearNumber as the third optional parameter. This was added because only a year and number is not an unique value across all cash counts.

Through the property active and the function updateProduct you can now set whether or not an article should be active.

Fixed a bug in the functions updateProduct, updateRelation and updateEmployee that was introduced recently.

When completely moving a table through the API function moveTableOrder, the "movement ticket" is now also printed on all relevant printer locations, as is expected.

The function getArticleGroups now also returns a list of all product numbers for every group.

The function payOrder with property prepay = TRUE now also supports a partial prepayment.

New function setStock that accepts an absolute value for the stock.

The parameter dataType of the object CustomField is now optional. When sending this to the API, you do not have to supply it, because the database knows which type these fields have.

The Article object now also contains the changeTimestamp and createTimestamp properties that contain the timestamp of the last change to an article and the timestamp when the article was first created, respectively.

When no productNumber is used in a call to updateProduct, the service will now try to determine the correct productNumber through the supplied articleNumbers.

Faster implementation of getReceipts added.

createProduct and updateProduct now properly process the customFieldList.

Added function getCustomFieldList which can be used to retrieve the custom fields from the article, relation and employee layout.

getActiveEmployeeList() now also returns the following authorization options for every employee: allowNextCourse,allowSplitandallowPay`.

Relation now also contains the property relationCode. Maximum length for this value is 128 alphanumeric characters.

The Transaction object now also contains the property extBranchId.

The VatGroup object now also contains the property extBranchId.

The Order, Invoice and Receipt objects now also contain the following properties: entryExtBranchId en financialExtBranchId.

The Payment object in a paymentList now also contains the properties entryTimestamp, branchNumber, extBranchId, workplaceNumber, employeeNumber and employeeName.

getProducts() now also supports the onlyActive parameter. When this is set to TRUE, only the active products are returned.

getTerminalSettings() now also returns unknownTableAction. This property indicates what should happen when an unknown table is selected.

allowTableRetour added to EmployeeName

When calling getJournals() the API stores which data served as source for the reply. The requester can add an optional reference.

New function requestTableOrderCourse() that can be used to request a certain course for a specific table.

payInvoice() now returns a proper message when a payment fails because the payment method is disabled.

New function logMistake() which can be used to record a mistake made on a handheld or similar device.

New function getTableOrderCourseList() which can be used to retrieve the currently present and already delivered course of a specified branch and table number.

Courses have new properties: sequenceNumber, isPresent and isDelivered.

New function getCardCategories which can be used to retrieve the categories of the article, relation and employee cards. For example, in the case of relations, these can be "Customer" and "Supplier".

Any menu prices are automatically applied. This can be disabled through a setting in the Mplus POS. When this setting is disabled, the POS will ask which menu's should be made when you open the table.

Menu information is now also added to article lines. Can be used to see whether or not an article line is part of a larger menu. The properties used are menuHash (unique value per menu combination), menuDescription (representable description of the menu), menuAmount (total amount of this article within the menu combination).

The BPE information (Dutch abbrevation that stands for Breakage/Promotion/Own use) is now also added to the article lines. This can be used to differentiatie between actual discounts and "discounts" because of breakage/promotion/own use. The properties used are bpeId (internal identification), bpeDescription (representable description), bpeAmount (amount incl. VAT), bpeAmountExcl (amount excl. VAT).

New API function getWordAliases that returns the configured word aliases. Can be used to translate a certain word to another word, like converting "Customer" to "Guest".

When retrieving an invoice you can now also see whether an invoice is finalized (finalized) and when (finalizedTimestamp).

When sending a message through sendMessage you can now also specify the sender and the messageType. Choose from OK, INFO and WARNING.

When retrieving a cash count through getCashCountList the account number of the difference is now also returned through the parameter differenceAccountNumber. The account number of the deposit account is also returned through the parameter depositAccountNumber.

You can now use the parameter sinceCashCountNumber to retrieve all cash counts since a certain cash count.

The function getJournals now also returns the payment type per payment method, such as: "PAYMENT", "EFT", "SUSPENSE, "DEPOSIT", "BPE".

You can now add the finalizeInvoices parameter to a getInvoices request to lock the invoices after retrieving them. Use this when you want to do a one-time export of the invoices to an external system, like accountancy software, to prevent the invoice from being changed anymore in the Mplus POS.

When requesting the version number of the API through getApiVersion there is a new parameter called serverDate which returns the set date of the API server and can be used to synchronize external devices with the server.

When retrieving cash counts through getCashCountList the first and last id's of the related receipts are also returned, via the properties shiftFirstReceiptId and shiftLastReceiptId. The first and last transaction (shiftFirstTransaction en shiftLastTransaction) now also contain the transaction label via the property transactionString.

The following objects now also contains the extBranchId (external reference for the branch): Branch, CashCount, Journal, FinancialGroup and Shift.

The API function getEmployees can now also be used with a syncMarker. Read the Sync Marker Tutorial for an in-depth explanation.

The API function getTurnoverGroups now also returns the externe account numbers that have been defined for every branch, through the list branchAccountNumberList.

API functions that return payment methods per branch (such as getFinancialJournal and getFinancialJournalByCashCount) now also return the correct account number (through the field accountNumber) when this differs from the default account number.

API functions that return turnover groups per branch (such as getFinancialJournal and getFinancialJournalByCashCount) now also return the correct account number (through the field accountNumber) when this differs from the default account number.

When an API function with customer fields is used (such as createProduct, createRelation or createEmployee) and the customer fields are required, but these are not supplied and don't have a default value, there will be a clear error message.

Through the field financialPeriodClosed, getFinancialJournal now also shows whether or not the period for which a financial journal has been requested has officially concluded. It is possible that a financial date doesn't end until 6 AM instead of midnight exactly.

Employee can now also be retrieved individually through getEmployee. Additionally, it now also returns the customer field (the customFieldList) and the following standard fields: syncMarker, changeTimestamp, createTimestamp, extraText, categoryId, personNumber.

When retrieving, creating and updating relations, it is now also possible to work with customer fields (the customFieldList) and the following standard fields: createTimestamp, bankAccountNumber, creditLimit, paymentWithinDays, vatNumber, commerceNumber, extraText, defaultVatMethod, neverPrintOrEmailReceipt, alwaysPrintReceipt, alwaysPrintLargeFormatReceipt, alwaysEmailReceipt, condenseCombinedInvoice.

When storing returned order line through saveTableOrder the API will also store a "reason for return" to be used in various reports.

getTableList() now also returns the information about the highest requested course of each table, through the properties courseNumber, courseName and courseAbbreviation.

getJournals can now be called without a branch filter, this will return all available branches.

It is now possible to insert and update the customer's card number through createRelation and updateRelation. The name of the field is cardNumber.

After running updateOrder it was possible for the API to try to generate a print job for the updated order. However, the wrong id was used for this, causing the updateOrder to crash to a halt with an exception.

Discount percentage was accidentally inverted when saving a counter line. This gave problems, for example when calculating the total amount of a line.

Negative decimal amounts were not correctly returned. Every amount was rounded to the nearest integer.

When running getJournals with a filter for receipts or invoices the list with payments (paymentList) and VAT groups (vatGroupList) will now also be properly filtered.

When the customer is using a Master/Slave setup, it is now possible to set a wait time during which the function saveOrder will wait until the Slave has synchronized a branch order. By default this wait time is set to 0 seconds. In that case the API does not wait at all. There is also an upper limit of 5 minutes.

By checking the function result you can see whether or not the order has been synchronized to the Slave. When the parameter orderQueued is set to TRUE, the order still has to be synchronized, when it is set to FALSE it has already been synchronized and you can rest assured that the Slave has received the order.

The functionality of queueBranchOrder has been combined with saveOrder. This means the API developer no longer has to pay attention to calling the proper function based on the master/slave-configuration of the customer. If the order has been added to the queue of a slave-branch, the function will return a special boolean called orderQueued with value TRUE.

If the rate for a certain VAT-code has not been properly configured in Mplus, the API will now return the following error message: The rate for VAT-code 2 is not properly configured. Please contact API support at dev@mpluskassa.nl.

This prevents the misconfiguration being missed and wrong tax rates being used by our API developers.

Problem solved where turnover groups with accents and other strange characters in their names could not be requested.

When retrieving relations the properties active, changeTimestamp and syncMarker are now properly filled out. There is also a new property, createTimestamp.

Problem solved in updateRelation that caused failure in updating certain properties of relations, like the active parameter.

The number of receipts returned by getReceipts when searching from a specific syncMarker is now also configurable through the parameter sync_marker_limit. Default is 1000.

Sped up implementation of getReceipts, which is not only much faster than the old implementation, but also returns a limited amount of receipts, to prevent memory problems.

When creating a relation through the function createRelation, you can now also use relationNumber to specify a number for the new relation, in stead of the service generating a number for you.

Attention: This release does work with the correct database version, which the revoked v1.7.7.2 does not.

When splitting a table order through the API function moveTableOrder (which is mostly used on handhelds), the workplace number of the transaction is always reset to 1.1, instead of using the actual workplace of the handheld. This caused a synchronization error in case of a Master/Slave set-up with multiple Slaves.

Attention: This release has been revoked because of a bug in the payTableOrder function.

Attention: This release has been revoked because of a problem when paying a split-up order.

If component articles are added to an order by the API developer, they will not also be added by the API itself. This prevents situations where calculated prices are wrong because too many component articles are added.

It was no longer possible to move order lines to an empty table with moveTableOrder.

Every error message that tells the API developer to contact API Support now also contains the proper email address to do so: dev@mpluskassa.nl.

Whenever an order line with discount is countered, the discount will also be properly countered, instead of being doubled.

When placing an order with combined articles, the price of the combined article was not correctly calculated when the article originially had no combined articles, but does so in the updated order.

A number of parameters in Line have been made optional, this being: lineId, employeeNumber, pluNumber, en lineType. When these parameters are omitted, the default value for each corresponding article will be used.

New function queueBranchOrder added to create branch orders through an API that is connected to a master/slave set-up.

A number of parameters in LineData have been made optional, this being: turnoverGroup, vatCode, vatPercentage, pricePerQuantity and siUnit. When these parameters are omitted, the default value for each corresponding article will be used.

It is now possible to revert a prepayment of a sales order through payOrder. To do this, make a negative prepayment of the exact amount.

When managing orders through the API the service will now also check vatCode and turnoverGroup for deviating values. Please consider this when creating or changing orders through the API.

If an error occurs while printing a receipt, order or other printable object, the API function won't be aborted with an exception anymore. The error message that occurred during printing will be put in the errorMessage parameter, but the remainder of the function's result will be as if there was not error during printing.

Of course when you are calling a function that is specifically used to print something, like printReceipt or printTableReceipt, the result will not be as normal.

getCurrentSyncMarkers now also works when one of the syncMarkers doesn't have any records yet. In that case the value 0 will be returned.

Attention: In this release the version of the API protocol is updated to 1.0.0. Check the release notes to determine if your application is still compatible.

It is now possible to read the components of a composite article, through the componentArticleList. The main article is also always present in this component list. Take note that the vatPercentage of components can differ from each other. In that case, the main article won't have a vatCode, because you need to look to the vatCodes of the components.

The price of the main article already contains the price of the components, so existing applications should continue functioning as expected.

When ordering a composite article, the components will be automatically added to the order or invoice.

New functione getCurrentSyncMarkers that returns the most recent value of the different syncMarkers.

getReceipts and getInvoices now also return the following article properties: supplierRelationNumber, supplierRelationName and supplierArticleNumber. It is also possible to filter on supplierRelationNumbers.

The function getFinancialJournalByCashCount is working again. This was temporarily disabled because cash counts can now also span multiple workplaces, and the implementation in the API service was not yet modified for this possibility. The function has also been improved, because it now actually only returns the financial journal of the branche that the cash count was performed on.

getRelations now includes a categoryId filter.

It is now possible to retrieve a list of the configured sales prices with the function getSalesPriceList.

New function: getPriceGroupList. Returns a list of all configured price groups.

When requesting turnover groups with getTurnoverGroups, the service now also returns turnover groups that are not configured, yet already used in the articles.

The service now also runs when there is no database connection. In that case every request will directly return a SoapFault telling you that there is no connection to the database. As soon as the database is available again, the service will automatically reconnect when processing the next request.

If the priceIncl of an article is entered, but the priceExcl is not, the priceExcl will be filled out based on the priceIncl and the vatPercentage. This also works vice versa.

When available, a table order will also contain the amount of guests in the property numberOfGuests. It is also possible to change this value through this property.

Improved memory management.

The financialDate of an invoice is actually used when calling saveInvoice (and createInvoice and updateInvoice).

It is now possible to read the price groups of articles, through the property priceGroupList.

To know if a relation should use a specific price group, you can read the property priceGroupNumber of relations.

Changes in an invoice (through saveInvoice or updateInvoice) will also be detected when the invoice lines have not changed.

The name of an article retrieved through getArticlesInLayout now uses the receipt text when available, otherwise it will fall back to the description.

If the supplied productNumber used in updateProduct doesn't exist, you will now get a specific error UPDATE_PRODUCT_RESULT_NOT_FOUND instead of the more general UPDATE_PRODUCT_RESULT_FAILED.

It is now possible to change the customFieldList through createProduct and updateProduct.

Problem solved where preparation methods without an articleNumber (that means with only a buttonText) were only sent once per article.

deliveryDate is now correctly filled out when retrieved through getOrder, getOrders or findOrder.

New function updateTurnoverGroups to modify turnover groups.

Problem solves that caused the error message "Werkplek is niet correct ingesteld." ("Workplace not set correctly.") when creating or updating an order.

Problem solved with createRelation and updateRelation where active was NULL.

When retrieving the articles on the button through getArticlesInLayout an extra property (buttonText) is returned with every preparation method which contains the text to display on the button. The value in the property name now always contains the receipt text or description from the article.

The functions createProduct and updateProduct can now also be used to change the category of an article through the property categoryId.

The certificate on https://api.mpluskassa.nl has been extended because it was about to expire this month. The new certificate is valid until 2018.

The function getProducts now also returns a list of preparation methods per article.

Through the property active and the function updateRelation you can change if a relation should be active or not.

When creating or modifying an order you can now also supply a delivery date through the property deliveryDate.

New function printTableReceipt to print the intermediate receipt of a table.

New function adjustPoints for editing the number of saved points of a relation.

Turns out that this function was accidentally disabled in this release. Update to the latest version to use this function.

Problem solved where the API service sent back invalid XML when a text in the message contained invalid symbols.

Problem solved that sometimes caused a 1 cent mistake in amount of change returned.

When registering change the API Service used the payment method gebruik Contant, instead of the proper CONTANT.

Compatible with database version 1.23.0.

createProduct and updateProduct now also save the colour and size supplied.

Bugfix in updateProducts where you could only add one article to a product every time.

Changes in updateProduct so that article barcodes are first deleted and then created again, preventing a database error.

Compatibility with database version 1.22.0 added.

When calling updateProduct the created and updated article numbers are also returned. This is done through the properties newArticleNumbers and existingArticleNumbers.

When calling createProduct the newly created article numbers are also returned, and not just the productNumber. The property for this is articleNumbers.

Probably solved the issue where paying tables failed in special circumstances, such as when paying a table with separate text lines.

When creating or updating a relation through createRelation and updateRelation, the relation is automatically added to the category "Customer".

New function payInvoice to pay invoices.

When a table order is being paid on the cash register, it will no longer be able to open, change or pay the same order through the API.

Compatibility with database version 1.20.0.

When saving a table order (through saveTableOrder) you can now also add a tableDescription that will be used as description of the table and is saved next to or instead of the table number.

New function getDatabaseVersion. Retourns the version number of the database.

When retrieving the active employee list (getActiveEmployeeList) the API Service now only returns the employees that are actually authorized for the request branch (terminal.branchNumber).

ns__Article now also contains the property supplierArticleNumber, which is the article number used by the supplier of this article.

Compatibility with database version 1.19.0.

All places that can return a relation (such as findRelation and getRelation) now return proper values for all properties. For instance, the property city and all values of the delivery address were missing.

getVatGroupList now also returns the branchNumber, because the VAT percentage could differ per branch since Q-line 1.18.0.

It is now possible to supply the deliveryAddress and invoiceAdress of an order. This is very useful when these are different from the normal address of the customer.

The sales prices of articles are now also sent through the property salesPriceList of the Article.

It is now possible to supply the deliveryMethod of an Order. Only predefined values may be used here. The available options can be requested through the API method getDeliveryMethods.

It is now possible to supply the orderCategoryNumber of an Order. In the POS this is known as the "ordersoort."

Order now also contains vatGroupList.

The new function getOrders can now be used to retrieve multiple orders. With the syncMarker and other filter options, the result can be limited.

A list of available order types can be requested through getOrderCategories.

Relations (customers, suppliers, etc.) can now be returned in multiples, through the new function getRelations. With syncMarker the results can be limited to the changes since a specific moment.

lineData such as is used in the lines of an Invoice, Receipt or Order now also contain the purchase price, through the property purchasePrice.

findRelation now searches the databases based on all lower case values and also partial matches. E.g. a relation with the name "John Smith" will be found by looking for "john s."

When saveInvoice is supplied with an extOrderId that already exists, that extOrderId will now also be shown in the error message.

getInvoices now also adds the transactionString to the invoices in the results.

When a button layout was configured with a default main and sub group, and any of those groups were removed, the system could get into a state where it was trying to use a non-existing group as default. The software will now automatically disable the default group if this is the case.

When saving an order through saveTableOrder or saveOrder, the API now also considers what the default VAT switch is set to, in regards to "Eat here" or "Take-out."

The methods saveTableOrder and saveOrder won't remove text lines from orders anymore.

Solved a problem in saveOrder and saveTableOrder which caused the lines of the order to be stored in a different order than in which they were received.

The methods createOrder, updateOrder and saveOrder will now also print an order receipt.

Incoming texts are now properly converted from UTF-8 encoding.

The function getButtonLayout now uses the proper UTF-8 encoding to allow for special characters to be transmitted.

The function saveTableOrder now also closes the table when there are no order lines left on the table.

The function getArticlesInLayout now also returns the preparation lines without an article (purely text).

When saving an order (through saveTableOrder, createOrder, updateOrder, saveOrder) any amount of discount is now properly converted from cents to whole units of currency. This solves the problem of ever increasing discounts.

getArticlesInLayout now also returns the component articles, through the property componentArticles.

When a preparation method in getArticlesInLayout contains no text, the field name will be filled with a description of the attached article, if available.

quantity is now accompanied by decimalPlaces to be able to transfer decimal amounts. decimalPlaces indicates how many positions the comma should be shifted.

For example, let's say we want to transfer the number 1,55: quantity = 155 decimalPlaces = 2

Or the number 935,401: quantity = 935401 decimalPlaces = 3

Finally, a round number, 50: quantity = 50 decimalPlaces = 0

When payTableOrder is requested with only part of an order, the API Service now actually checks the content of every order line, instead of simply comparing the number of lines. Because the old method caused issues when the new order had the same amount of lines as the old order, but with different amounts.

Images that are returned in the imageList through getProducts are now sorted by actual sequence number, instead of order of creation. That way any changes in that sequence are properly transferred.

A call to getAvailableTerminalList now checks whether the database is a Master or a Slave and only returns the work places that are allowed to connect to that database.

This means that a connection to a Master database will prevent all workplaces that belong to a Slave database from being returned, and a connection to a Slave database will only return the workplaces that belong to that Slave.

General optimization to improve the speed of the API.

createOrder now checks if the supplied employeeNumber actually exists, to prevent a database error.

Improvement in the stability of functions like getTableOrder.

Issue solved with moveTableOrder and payTableOrder which could cause an AccessViolation.

Issue solved when running payTableOrder that would wrongly try to split an order, which caused a crash.

getTableOrder will now also enter the value of the lineId of lines, even if they are condensed lines. The values of lineId will simply start at "1" and count up.

When calling payTableOrder, there will be a better check if the incoming order is equal to the existing order.

When saveTableOrder receives an order without changes, the order will not be saved again.

This prevents identical order receipts from being printed.

The ButtonLayout_Button object that is returned through getButtonLayout now contains two new properties:

• askForText: Indicates whether the client should ask for a text when this article is added to an order, which should then be used as name for the order line.
• isPreparationMethod: Indicates whether or not the button is a preparation method, which should be applied to the currently selected order line.

The Table object that is returned through functions like getTableList now also contains the relationNumber and the relationName of that table.

It is now possible to pay part of a table order (through payTableOrder). The remaining articles remain on the table order.

It is now possible to move articles from one table to the other (moveTableOrder).

Added support for the GET requests ?wsdl and ?docs, which return the WSDL and documentation respectively.

relationNumber in Order is now optional. Also relationName has been added.

Every exception is now returns as a SOAP error, instead of silently crashing the API Service.

Article now also contains the webshop field.

saveTableOrder will now correctly combine identical lines that are separated from each other, and not leave anything out.

When updateRelation is called without relationNumber, you will now receive an error message (as was intended), instead of crashing the API Service.

When request products (getProducts) you can now specify to only receive products that were changed since a specific time.

It is now possible to progress a sales order to a packing slip (deliverOrder).

It is now possible to pay a sales order (payOrder). In this case, you can choose between a prepayment or progressing to an invoice.

It is now possible to request the work time registration by using getShifts.

It is now possible to request images (getImages), including the actual image data, so that synchronization of images can run fully through the API.

It is now possible to request the work time registration by using getShifts.

It is now possible to request images (getImages), including the actual image data, so that synchronization of images can run fully through the API.

It is now possible to retrieve all employees through getEmployees.

The articles (ArticleSimple) of a article layout (getArticlesInLayout) now also contains the PLU number and whether or tot the preparation methods should be directly shown on selection.

When the database version is not supported, this will be shown with extended error codes. For example, whether or not the database has a schema version that is too high or too low.