As described in the documentation https://docs.business.visma.net/docs/schema/queries/query   Accessing company tables requires specifying a company number. Similarly, accessing a system table requires specifying a customer number. These are the Visma.net identifiers for the company and the customer and can be either found in the Visma.net portal or can be retrieved with a query ... View more

Can you try to use the following filter and see if there is any difference? filter: { _and :[ {logType :{_eq : 1}}, {tableNo :{_eq : 152}}, {columnNo :{_eq : 4084}}, _or : [ {changedDate : {_gte : 20230905}}, _and : [ {changedDate : {_eq : 20230905}}, {changedTime : {_gte : 110}} ] ] ] } ... View more

When you upload a file, you must encode it using base64 encoding. In general, that increases the size by 1/3. So a 3.5MB file would end up with a ~ 4.7MB payload. That is well under the 15MB limit we have.   But can you check the actual size of the request? ... View more

The BNXT GraphQL schema is dynamically built from the data model. I have checked the model manually, and there is no relation defined from OrderDocument to PickList. Therefore, we can't define such a joinup in the schema.   I'm not arguing that you are wrong on your assumption, maybe it's been overlooked. But I am not experienced with the business model here to tell you more. ... View more

This is something else. Previously, you could not set a null, you were getting: "Argument 'values' has invalid value. In field 'textNo': [Expected 'Long!', found null.]" Now, you can. The fact that you get a runtime error is a completely different problem. ... View more

The schema is now modified so that you can pass null for all fields that support suggesting value. ... View more

20 affected Rows and 20 Items but a bunch of error-messages (because the customers already exists).   Would we always get all rows back (also the failed ones) or is this just on the associate table or is this a bug? This is what we get back from the backend. There is no data created in GraphQL. GraphQL is just a middleman that transforms the request into something the backend understands and then back the response into the shape that was requested. ... View more

OK, then this is a problem. I will investigate what needs to be done here. It probably shouldn't be Long! but just Long. So we might need to update the schema. ... View more

$textNo must be null for a suggest to occur. What are the values of the variables that you pass for the mutation? ... View more

We have added support for batching requests. See documentation: https://docs.business.visma.net/docs/features/batches ... View more

Batching requests is now available. See the documentation here: https://docs.business.visma.net/docs/features/batches ... View more

Thank you for reporting. Will be looking into it. ... View more

I don't think you can close topics. You can mark them as resolved though.    But I didn't quite understand: did you realize what you were doing wrong? Or what you misunderstood the way the API is supposed to work? ... View more

I understand your concern and frustration. It's my fault for not documenting this properly. hasNextPage is not exhaustive but rather a hint that sometimes provides false positives. hasPreviousPage should work correctly. But for hasNextPage to always return the correct result we would have to retrieve the count of (filtered) rows from the backend which we don't do currently. So if you ask for N records but get < N, then it will properly tell you that there is no next page. But if you get exactly N, it will say there is a next page. However, fetching for the next page should return an empty set. I understand that is a request too many that incurs costs, but it shouldn't generate an infinite loop (like you seemed to suggest). We will investigate how to improve this. ... View more

These are internal error codes, that's why they are returned as numbers ... View more

What I can tell is that the problem is now fixed in the backend. Since we have one release per week, happening on Thursdays, I expect this will only be rolled out to production next week. ... View more

Here is a link to the other bug report for the same problem that we got: https://community.visma.com/t5/Diskusjon/Outstanding-amount-per-customer/m-p/585629#M291   ... View more

I can confirm there is a bug in the backend that produces this outcome when querying a view (not a table). We are currently investigating it. ... View more

I can confirm this is due to a bug on our backend that has been already reported with a query for another view. We are investigating the problem. ... View more

I can confirm this is not working anymore. I'll investigate and fix the issue.    What works for now is this: filter: {changedDateAsDate: {_gte: "2023-06-03"}} ... View more

We put this on our backlog.   For the time being, there is a level of "batching" that you can do, by merging multiple queries into a single request (you cannot have both a query and a mutation though). Something like this: query multiples { company_1 : useCompany(no: ...) { request_1 : order { totalCount } request_2 :order(filter :{changedDate : {_gt : 20230606}}) { totalCount } request_3 :order(filter :{orderNo : {_lt : 100}}) { totalCount } } company_2 : useCompany(no: ...) { order { totalCount } } } Of course, you'll want to use variables, and this probably means you'll have a large number of variables. But you could probably also use a dictionary or array to handle the complexity. ... View more

We now have support for _in and _not_in operators in filters. See documentation here: https://docs.business.visma.net/docs/features/filtering   ... View more

Please elaborate on the request. ... View more