🚧

Payments endpoints will not allow future payment date

In order to align to the behaviour inside eAccounting the API will not allow payment dates in the future when using POST /v2/customerinvoices/{invoiceId}/payments and POST /v2/supplierinvoices/{invoiceId}/payments endpoints. A validation exception will be returned in that case.

🚧

New mapping on empty InvoiceAddress1 and InvoiceAddress2 for POST /v2/customerinvoicedrafts

In order to fix a bug and align to the behaviour inside eAccounting when doing a POST on /v2/customerinvoicedrafts and not providing a value for InvoiceAddress1 and InvoiceAddress2 the values will be taken from the customer.

ReplaceUnitPriceWhenZero:

Release of a highly requested feature by AOs in collaboration with customers.
This will enable end users to save manual journal entries as a draft and then allow the AO to review them and edit if needed before posting them to ledger.
The new endpoints enable the possibility to create, get, update, delete a draft or convert it to a voucher.

New properties on v2/companysettings.

🚧

New validation error on POST /v2/customerinvoices - RotReducedInvoicingPropertyName

In order to fix a bug and align to the behaviour inside eAccounting the API will now return a 2000 - DataModelValidationError when using POST /v2/customerinvoices with a set RotPropertyType but empty RotReducedInvoicingPropertyName.

Backorder:
If an existing order has a delivered quantity that is smaller than the ordered quantity, this endpoint will take the order id and automatically create a backorder for the remaining amount. The order must be in status shipped or invoiced and may not have an existing backorder already.

Address properties on v2/customerinvoices are not read-only anymore.

eAccounting has been extended with some article updates and additions. They are all related to stock and stock handling. There's a few updates to the API related to this aswell:

The patch verb was released a few months back in our Sandbox environment together with some experimental endpoints. After further investigation and self assessment we decided to postpone the PATCH verb implementation in the production environment in order to implement a solution that alligns more with the industry standards and with the quality and structure that the Visma eAccounting API has.