New Features

1. A new API call, getSalesDocumentActualReportsHTML
   has been added. Use this call to get a sales document printout on an Actual Reports template.
2. API now supports overwriting invoice reference numbers with custom values. Field "customReferenceNumber" has been added to API calls saveSalesDocument
   and getSalesDocuments
   .

Improvements

1. API call getSalesDocuments
   can now sort returned invoices by ID (orderBy=documentID), and
   this is now also the default sorting
   , instead of dateAndNumber.
2. Ability to sort records by ID has also been added to API calls getPurchaseDocuments
   , getEmployees
   ,getEvents
   , getSuppliers
   .
3. Support for a new POS application added.

Fixes

1. Fixed: re-saving a confirmed sales document with saveSalesDocument
   no longer loses information about promotion and price list discounts applied to that sale. (This information can be queried with API call getAppliedPromotionRecords
   .)
2. Fixed: re-saving a sales document with saveSalesDocument
   did not correctly update the component rows of a sold bundle.
3. Fixed: the savePayment
   call now respects input parameter "customerID". Formerly, if API client specified "documentID", "customerID" was always overwritten to invoice's customer.
4. Fixed: API call saveCustomer
   incorrectly returned an error if certain location IDs were used in the "signupStoreID" and "homeStoreID" input parameters.
5. Fixed: sometimes, after having edited your company's information in Berlin POS, attempting to re-save company card in back office failed with an error, "This form has been updated by another user.".
6. Fixed: sometimes, the Z Report did not correctly show the name of the cashier opening the day, or the cashier closing the day. On future day openings and closings, this will no longer happen.
7. Fixed: In case of errors, API now always returns error code 1000, instead of an empty response.

Other Notes

In future versions, if API client sends a bundled saveSalesDocument
+ savePayment
call in one bulk request, and API detects that the
sales document is a duplicate
, the bundled savePayment call will start returning
error code 1158
. Code 1158 is not an error condition. It just indicates that API has received the same command twice, but data has nevertheless been successfully saved. API clients should be updated to ensure that the error message does not get shown to an end-user. Right now, API will continue behaving as-is: the payment will be created nevertheless, resulting in duplicate data.
The described change will happen in a future API version.
 Only
savePayment
will start returning code 1158. A duplicate "saveSalesDocument" call returns the already-created document, and will continue to do so in the future. Additionally, if the "saveSalesDocument" call in that bulk request fails for any other reason, "savePayment" will start returning
error code 1157
. This is to avoid creating incomplete data. If the client application knows how to resolve the issue that caused saveSalesDocument to fail, it should re-send the whole bulk request, the document as well as the payment.