- Input parameter
"searchNameIncrementally"in API call getCustomers now additionally returns customers whose company registry code, or a person’s National ID number exactly matches the specified search phrase.
- Compliance with General Data Protection Regulation can now be activated on demand on non-EU accounts, too — with configuration parameter
"gdpr_features_enabled" = 1.
"reasonID"has been added to API calls saveInventoryRegistration and getInventoryRegistrations.
- Input parameters
"documentDateEnd"have been added to API call getSalesReport, allowing to filter a Cost of Goods Sold (COGS) Report by document date (as an alternative to filtering by inventory transaction date).
Please see the documentation for that API call for a more in-depth explanation about the COGS report and date ranges. This feature requires Classic back office, version 4.12 or newer.
- API calls getSalesDocuments and saveSalesDocument now support per-row waybill IDs which indicate which row on an invoice has originated from which waybill. API call getSalesDocuments outputs a new field
"sourceWaybillID"on each row; saveSalesDocument accepts input parameter
"variationDescription" → "order"and
"variationList" → "order"have been added to API call getProducts. This allows to sort a list of matrix variations in the same order in which the respective colors / sizes have been arranged.
- Support for Thai and Faroese languages has been added.
- Configuration parameter
"api_getpointsofsale_all_invoice_numbers_not_returned" = 1enables an optimization: API call getPointsOfSale returns the field
"lastInvoiceNo"to Berlin POS only if POS asks for one specific register, and not the whole list.
- Fixed: when creating a new payment with savePayment, API will now populate “last modification timestamp” with current timestamp, not user-supplied data. (Input parameter
"added"is still accepted, but it won’t affect last modification timestamp any more.)
- Fixed: the checkbox “Customer does not earn new reward points” on customer form was interpreted incorrectly, and API did not allow the customer to spend those points, either. This restriction has been lifted from API calls editEarnedRewardPointRecord, editUsedRewardPointRecord,getCustomerRewardPoints, saveIssuedCoupon and subtractCustomerRewardPoints.
- Fixed: When deciding whether to instruct POS to issue a coupon or not, API call calculateShoppingCart ignored the check box “Customer does not earn new reward points” and always assumed that customer is going to earn points from the current transaction, too.