I would first like to thank the community for all input and comments.   Have been working with integration methods against Business for a long time, from edi files and with VBS, and now with GraphQL. There are different working methods in all the import methods.   In this thread my experience is that we had to think very differently than earlier methods. The solution we could do earlier also. But earlier we could send inn suggest(VBS) og look up next voucherno and set in the edi file, but then the counter for nextvoucherno was triggered   None of the examples in the GraphQL documentation give the solution we want, some of the suggestion in the thread give some solution.   Our scope of what we want to achieve, is to set the same voucherno on all the voucherlines, and we have not got it to work with the suggestion in this thread or from the documentation.   What we ended up as a solution is that do meet our scope: In the request for the batch, we set the voucherSeriesNo to the series we want, and set the batchProcessing on 8 For the voucher import, we set no suggest and doesn't send any voucherno field All the voucherlines is imported, but no voucherno are set.  To set the voucherno: From the VBNXT ERP on the batch register screen, you can run the process assignVoucherNumber (On Norwegian: Tildel bilagsnummer). The process set the same voucherno on all the voucherline, different voucherno on each batch Send a batch_processing request with the BatchProcessing.assignVoucherNumer with the filter with the batchno you want to process. in the filter part for BatchProcessing.assignVoucherNumer where are using the operator _in and sends in an array of integer of the batchno we want to process.  The only question i have to Visma () is what if a processing is gone wrong, do we get a error back with reference to which batch that gone wrong? because the response item we can set ar only succeeded   ... Meer weergeven

@David Tandberg-Johansen There are no company-specific limits directly, no. There is a rate-limit on requests per second per client session (access token) of 15, with occasional bursts of 25 allowed. You would see a 429 response in these cases.  There is a size limit on the toal request (including attachments) of 15 MBs, where you would see a 413 in the response.  In case of mentioned timeouts, you should still not get a 500-error. Feel free to create a case if it happens again or with any regularity. As much info as possible is useful, customerID, timestamp + what the request is meant to do etc.  ... Meer weergeven

Hi, most of the endpoints have fields related error handling, for sure in some cases they might be vague. In those cases, by far the best option is trying the same operation with the same values in the UI, so that the system can highlight the error with more information.  Yes, we have a plan for moving all the endpoints over time, meantime we're still working to improve existing endpoints.  ... Meer weergeven