Hi,   I think a breaking change was introduced on the /controller/api/v1/customer/{customerCode}/directdebit endpoint by the Release of 6 feb 2024.   Previously, this API call returned all direct debit lines present on a Customer. As of present, a significant amount (up to 80%) of the present direct debit lines in our Visma.net instance are no longer returned. I have not yet found a pattern in which data is/is not returned, but it looks like all data before a certain date (2024?) is not returned any more.     I have seen no mention of this endpoint in the Release notes. What could be the case here?   Regards,   Reinder ... View more

In the UI there is the option to add a mandate (dutch: Machtiging) on a Customer Invoice:   On the (V2) CustomerInvoice POST, there is no option to supply a mandate ID. I am assuming this is a bug?   ... View more

I am performing an API call to update (PUT) some data on a Customer. This is what happens: Update some, but not all of the fields of a customer record: { "AccountReference": { "Value": "F9" }, "CreditTermsId": { "Value": "01" }, "CustomerClassId": { "Value": "EUSTD" }, "DefaultPaymentMethod": { "Value": { "PaymentMethodId": { "Value": "9" } } }, "MainContact": { "Value": { "Attention": { } } }, "Name": { "Value": "Onno Overloon" }, "OverrideWithClassValues": true, "PrintStatements": { "Value": false }, "VatRegistrationId": { "Value": "213132" } }   ScreenId=AR303000 The Payment method is updated:   Execute the SAME api call again (same data, paymentmethod 9 is supplied): Payment method is NOT set to 9 (which was supplied), but set back to the default (1).   PUT again --> 9 PUT again --> 1 etc.   PUT 5 --> 5 PUT 5 again --> 1   It seems that the API endpoint interprets the data as such: "if the current paymentmethod is supplied in a PUT call, remove it and set it to the default value". This is different behaviour than I have encountered elsewhere (including in the same API call) and it is also not documented.   What is the reason and can this be fixed?   ... View more

I believe this is a functional oversight in the implementation of the Customer/PUT API call. If I POST a new Customer and supply only a Main Address, the optional addressses (Billing or Delivery address) will have the checkbox "same as main" marked, and the underlying address will be the same Address record (same Id property) as the main record:   If I have created an existing Billing or Delivery address and want to empty it, there is no option in the PUT API to do so. - supplying empty strings will throw an error (country must have a value) - supplying null will not update the address record - supplying the same data as the main record (overwrite the Billing address with the Main address) will result in a separate address record, and "same as main" will not be checked:   This matches the functionality as it is implemented in the screen. There is no way to empty a Country, because it must always have a value:   The way to empty a country in the screen is to manually check the "same as main" checkbox, this will overwrite the entire address record: However, the Customer/PUT API call offers no way to influence this checkbox at all, which means I cannot mirror the screen functionality using API calls. It means that I am never able to empty a Billing/Delivery address.       ... View more

I have PUT a DirectDebitLine (note: is for Netherlands only) on an existing customer in the /api/v1/customer/{customerCd} PUT call. Example PUT body:   { "directDebitLines": [ { "bic": { "value": "1234" }, "dateOfSignature": { "value": "2023-06-01T11:24:06.493Z" }, "iban": { "value": "4321" }, "isDefault": { "value": true }, "mandateDescription": { "value": "demo PUT" }, "mandateId": { "value": "1.12" }, "oneTime": { "value": true }, "operation": "Insert" } ] }   The header of the response does not return any key or ID property for the created record (the way the Customer POST returns the customerCode in the 'Location' Header): For reference, the property required to update (PUT) a DirectDebitLine is the Id property, which is a GUID. The only GUID in the response header (ipp-request-id) is not the ID of the newly created DirectDebitLine:   So I cannot identify the record I have created in order to later update (PUT/"Update") it, since I have no unique key to identify it by. Doing a GET on Customer with expanded DirectDebitLines returns all the records, but without a primary key I cannot identify which is the record I created.   Please fix this, I would recommend using the Location header, the same way is done on Customer/POST, since this works satisfactorily. ... View more

I am attempting to create a Customer using the POST API call. I get a 500 error:   { "name": { "value": "testpaymentmethod1" }, "defaultPaymentMethod": { "value": { "paymentMethodId": { "value": "1" } } } }   I am certain that payment Method 1 is present, I can even retrieve it using the paymentmethod endpoint:     I am guessing something broke in the underlying query? Both values are a string "1" and there is no truncation or anything like that. There are no other ID properties so I'm not using the wrong ID.   Please fix, as this is a central point of our implementation and without this fix, I cannot continue. ... View more

The Visma.net API documentation clearly states that the Swagger page (and the specification.json file hosted beneath it) can be taken as documentation for the working of the Visma.net API. There is no other documentation available and everyone points to the Swagger as the leading (and, I assumed, complete) documentation of the API. In that case, receiving 'undocumented' return types / objects back from the API should not be possible. I noticed just now (using /api/v1/paymentmethod/{paymentMethodNumber} as a use case) that 404 (NotFound) is not among the documented possible API return types: This breaks tooling that automatically generates a client based on the API swagger page / specification file. As a standard, documentation that is complete should document all possible API call return types, including at the very least 404 (NotFound) and 500 (Unhandled Error). Additionally I did not realise before (tested the API before a couple of times and forgetting to log in) that the 401 (Unauthorized) return type is also not documented. This does not apply to this single example but, as far as I can tell so far, is an API-wide issue on (nearly?) all API calls.   Please evaluate the API and update the data contracts to include all possible return types. It is very difficult to work with (auto)generated code based on incomplete API specification, and due to the size of the API it is very undesirable to implement every API call manually. ... View more

/api/v1/paymentmethod only returns the creditor payment methods, but not the debtor payment methods. This means I have no "get all" API call to retrieve all debtor payment methods all at once.   Demo: paymentmenthod GET: returns 1, 2, 3: as well as 9: but with the api/v1/paymentmethod/{id} I can prove that there is more data, for instance a paymentmethod 5:   There are 2 ways to interpret this issue: 1) it is a bug that the API call only returns creditor payment methods, but not debtor payment records. 2) it is intended that the API call only returns creditor payment methods. In this scenario there is no way to retrieve all debtor payment methods all at once.   Suggested resolution:   Add boolean properties to select which data to return (returnCreditorPaymentMethods, returnDebtorPaymentMethods). The default could be set to true and false, so that the API keeps on behaving the same as before (backwards compatibility).  ... View more