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.

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.

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

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.

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

getProducts has been heavily optimized to increase speed.

New function getPaymentMethodsV2 that supports filtering by accountNumber.

The functions createProduct, updateProduct, createRelation, updateRelation, createEmployee and updateEmployee no longer delete the contents of fields that are available in the API, but not sent in the request.

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 with saveInvoice which caused the financial date that was supplied through financialDate to not be used with new invoices.

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

The functions createProduct, updateProduct, createRelation, updateRelation, createEmployee and updateEmployee no longer delete the contents of fields that are available in the API, but not sent in the request.

New function getPaymentMethodsV2 that supports filtering by accountNumber.

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.

Attention: This release has been revkoed because of wrongly registered compatibility with the database version.

Attention: This release has been revkoed because of wrongly registered compatibility with the database version.

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.

An order can now contain a delivery time. You can use the following properties for this: deliveryPeriodBegin and deliveryPeriodEnd. By entering both, you can define a delivery timeframe, in which the order should be delivered.

If a payment (through payOrder, payInvoice or payTableOrder) has a financialDate that's different from the current financial date, this different date will be used instead of ignored.

The imageList in getProducts now also contains the imageUrl en thumbUrl, when available.

The parameter onlyWebshop that can be added to getProducts now actually works as expected, returning only the products that have Webshop set to 'Yes'.

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.

When payInvoice is called with a payment method that does not yet exist in Mplus, you will now receive a clear error message.

MplusQservice 1.6.1 was not a succesful release, e.g. the function getProducts did not work well.

The function getProducts does not work well in this release.

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

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.

When saveOrder or updateOrder is used on an order which is (partially) delivered or (partially) cancelled), you will now receive a clear error message, in place of a vague exception.

In some places the vatPercentage was not yet multiplied with 100 before being sent through the API.

All places that use ns__LineData, now also have proper values for turnoverGroup, vatCode and vatPercentage.

When an article with preparation methods was ordered multiple times, optional additional costs were also erroneously added once for every multiple.

Solved problems with memory management. This was causing problems in findOrder.

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.

Added compatibility with schema 1.12.0.

Added compatibility with schema 1.11.0.

The version number of the API protocol is no longer dependent on the version number of the Mplus API Service. This means we can update the software, without necessarily changing the protocol version.

Added compatibility with schema 1.10.0.

New function: cancelOrder()

When the API Service has no configuration or is connected to a non-supported database version, this will be communicated through a SoapFault that is sent back. Previously you simply received no reply at all.

getProducts(): Now returns the products wrapped in a productList variabele. The variabele that contains the articles of a product has been renamed from articles to articleList to be more consistent with the rest of the API.

createOrder(): Now returns an orderUuid instead of an orderId.

createRelation(): Added support for delivery address, mobile phone number and contact person.

findOrder(): orderDeliveryState/orderCancelState/orderCompleteState have been added.

updateOrder(): Workplace is now based on the branch number from the order. No longer deletes all lines, but updates lines based on the article number.

When saving and paying table orders, the complete time will be used, and not only the date.

Fixed a problem where placing a table order through the API caused multiple active orders on one single table.

New function: getProducts()

New function: updateOrder()

New function: findOrder()

New function: createRelation()

New function: getRelation()

New function: createOrder()

New function: findRelation()

In the attachment you will find an example batch file for automatically running the service and an example configuration file.

In case of a database error the message of the error is now displayed, which helps find the cause of the problem.

This version probably always fails when saving an order. Please update to 0.0.10.

New function: getTableList()

New function: getApiVersion()

The function getButtonLayout() now also sends the configured columns and rows.