Maintenance work
AnnouncementDue to maintenance work, the sevdesk application will be unavailable on Thursday, 24.10.2024 from 21:00 for approx. 60 minutes.
Change in creation of check accounts
We are introducing new endpoints for the creation of check accounts, they are now tailored better to their specific use cases.
Setting or changing the property ‘enshrined’
Enshrined objects should not be modifiable.
Status Quo:
In sevDesk system version 1.0 it is possible to directly set and unset / change the value of the property enshrined for Invoice, Voucher, CreditNote and CheckAccountTransaction. This is already not possible in sevDesk-Update 2.0.
Future:
The property enshrined must be set via the dedicated endpoint. It can no longer be set directly.
Changing some 500 HTTP status codes to 422
We have noticed that some of our validations for orders, invoices, vouchers and credit notes are returning a HTTP status code of 500 instead of 422. This is a bug that will be addressed.
New invoice status: Partially paid
To better distinguish between open, partially paid and paid invoices we, will introduce a new status.
sevDesk-Update 2.0 - API Changes
In the future, we will provide our customers with more guidance and help them to avoid error in their accounting. To this end, we are introducing fundamental changes to our software, which will take the form of a major update. In addition, new functions will be made available that offer our customers even more insights & therefore opportunities for their company. In the documents linked below we will focus on the changes of the sevDesk-Update 2.0 for our public API. The PDF is also including a detailed timeline for the roll-out of all changes and the migration of users.
Handbook sevDesk-Update 2.0:
Changing the status for invoices and credit notes
It will no longer be possible to change the status of invoices and credit notes manually. Instead, the respective endpoints must be used.
Forbid orders with negative totals sum
Saving proposals (aka estimates) / orders / delivery notes with a negative total will result in a validation exception. This is necessary so that the resulting invoices can be booked correctly.
Invoice date validation of final invoices
Status Quo:
The invoice date of a final invoice can be earlier than the date of an associated partial invoice.
Future:
The invoice date of a final invoice must be on the same day or later than the highest date of the associated partial invoices.
Affected endpoints:
Increased voucher validation
Vouchers will be validated more strongly in the future. The endpoint affected is /api/v1/Voucher/Factory/saveVoucher/