Using a field for the value of another field in a filter, like sumDebitDomestic:{_not_eq:sumCreditDomestic} is not currently supported. ... View more

ChTmms stores the same timestamp as ChDt and ChTm. Therefore, it does not bring anything new and is used in a single place (I've been told). Therefore, not really a field of much interest. ... View more

It would probably be of more help to provide the actual path, such as ["orderLine_create", "values", 1, "lineNo"] to indicate that the lineNo field of the first order line in the list was at fault.   Also, it could be a good idea to move the Status to the extensions part of the error message. This makes little sense for you but it helps us understand what error was produced internally. ... View more

Currently, the @export directive only supports exporting a single value, not a list or dictionary. Therefore, creating multiple orders at a time and the lines for those orders is not possible in one shot. You need to create one order and its lines in one request.   The other question that you're raising is, how would you know what operation produced an error message. For instance, if you add 10 lines but one of them fails, how would you know which order line failed. Currently, you can only figure that out by trying to match what you inserted and what is actually in the database. I understand that is not great. The question is how would you like to be informed about the error?   Let's take the following example: orderLine_create( values: [ { orderNo: $orderId, productNo: "101", quantity: 1 }, { orderNo: $orderId, productNo: "103", quantity: 2 } ] ) Let's say the first line was correctly added, but the second failed for some reason. How should we tell what line failed? Should it be the index of object in the values array? "errors": [ { "message": " A record with the same primary key already exists. Status: 3. Values index: 1" }, ] Would this "Value index: 1" help you? ... View more

I can confirm there is a bug here and the @export directive does not work as expected. We are investigating a fix for this problem. ... View more

So you're reading this data with SQL commands, not with the VBS API. I will add this to the backlog and see what we can do. ... View more

I had added this request to our backlog to investigate what we can do to make it possible. But I can't give you estimates at this point. ... View more

You want to use the OrderDocumentNo field from which table? There is no such field in the FreeInformation1 table, for instance. ... View more

I am not familiar with this scenario. Can you elaborate on it a bit? You're saying you are doing this in VB on-prem with VBS? If so, can you share a snippet? That would help me understand you needs better. ... View more

You can only filter on the fields of the table, not on joined data.  ... View more

This indeed should work. I will investigate the problem. ... View more

There are very small chances this could happen, but in any case, it is the responsibility of the VB backend team that owns the data model. GraphQL is only exposing in a query language what they define in the model. ... View more

To get this amount of data you need to use unoptimized queries. Put it on the order field and all inner queries will be executed unoptimized. order( first: 100 filter: {changedDate:{_gte: 20210101}}, unoptimized :true ) This allows you to ask for totalCount and pageInfo fields, which otherwise do not work with optimized joins. query($cid :Int!) { useCompany(no: $cid) { order( first: 100 filter: {changedDate:{_gte: 20210101}}, unoptimized :true ) { totalCount items { orderNo orderDate changedDateTime createdDateTime joindown_CustomerTransaction_via_Order { totalCount pageInfo { hasNextPage startCursor endCursor } items { orderNo invoiceNo customerNo voucherNo valueDateAsDate amountDomestic debitAmountDomestic creditAmountDomestic changedDateTime createdDateTime } } joindown_ProductTransaction_via_Order{ totalCount pageInfo { hasNextPage startCursor endCursor } items { orderNo transactionNo invoiceNo productNo quantity } } joindown_OrderLine_via_Order { totalCount pageInfo { hasNextPage startCursor endCursor } items { orderNo lineNo productNo } } } } } } We have the 1000 rows limit, but it's for each back-end query. If you run unoptimized, then this query will do: request for the 100 orders (within the 1000 limit) for each order: one request for customer transactions one request for product transactions one request for order lines So this should allow you to get up to 1000 customer transactions, 1000 product transactions, and 1000 order lines for each order.   When you use pageInfo, you can know whether you got all the data from a joined table, such as the order lines. Here I am limiting to 3:   joindown_OrderLine_via_Order(first: 3) { totalCount pageInfo { hasNextPage startCursor endCursor } items { orderNo lineNo productNo } } And I get back something like this: "joindown_OrderLine_via_Order": { "totalCount": 6, "pageInfo": { "hasNextPage": true, "startCursor": "MA==", "endCursor": "Mw==" }, "items": [ { "orderNo": 1, "lineNo": 1, "productNo": "312" }, { "orderNo": 1, "lineNo": 2, "productNo": "313" }, { "orderNo": 1, "lineNo": 3, "productNo": "" } ] }  You can use the endCursor to query the orderLines table directly, for the rest of the lines. But you need to use the right filter too (what order it belongs to): orderLine(filter: {orderNo :{_eq :1}}, after : "Mw==") { totalCount pageInfo { hasNextPage startCursor endCursor } items { orderNo lineNo productNo } }  And then you get the rest: "orderLine": { "totalCount": 6, "pageInfo": { "hasNextPage": false, "startCursor": "Mw==", "endCursor": "Ng==" }, "items": [ { "orderNo": 1, "lineNo": 4, "productNo": "" }, { "orderNo": 1, "lineNo": 5, "productNo": "" }, { "orderNo": 1, "lineNo": 6, "productNo": "311" } ] }, ... View more

Deleted records, including orders, are physically removed. That means you cannot actually query for "what has been deleted?"   At the time being, I don't see any other way than querying all order numbers, and comparing with what you have. Maybe someone from the VB core team could tell you more.   FYI, we are working on providing a way to get notified about events, such as when a record is deleted, but this will come sometime next year. ... View more

This must be a general problem with filters in _joindown fields. So sure, it would show up regardless what tables you query.   PS: I'd like to ask you when you paste snippets of queries to use the Insert/Edit code sample button so that you get preformatted text. That makes your queries more readable. ... View more

I can confirm there is a bug in our side. I have opened a ticket for fixing it. ... View more

I will test this on our side and come back with an answer. ... View more

I was told the following by my colleagues: if the suspension date has not been set, it is empty. When moving the suspension date, the last day in the previous month is suggested.   This means you don't have a suspension date set in your system. But when you're trying to actually set it to, the system suggests by default the last day of the previous month.   I hope this answers your question. ... View more

Perhaps this is a silly question but do you actually have data in this table for this customer price group? The filter you are using looks good to me. Here is how you can query the priceanddiscountmatrix table directly:   query data2($cid :Int!) { useCompany(no: $cid) { priceAndDiscountMatrix(filter : {customerPriceGroup1 : {_eq : 1}}) { totalCount items { productNo customerPriceGroup1 salesPrice1InCurrency } } } }     I am formatting your query here so it can be read better by others:     query data2 { useCompany(no: XXX) { product{ items { productNo joindown_PriceAndDiscountMatrix_via_Product(filter: { customerPriceGroup1:{_eq:1} } ) @include(if:true) { totalCount items { customerPriceGroup1 salesPrice1InCurrency } } } } } }       ... View more

At least one problem is that you cannot actually suggest a value in an interval for batchNo. This is not properly indicated in our API. I will try to see how to make this less error prone. ... View more

The suspension date is stored in the companyMaster table. This is a sort of key-value pair storage. The value of the suspension date is stored with key 12. So you need to do this:     query ($cid :Int!) { useCompany(no: $cid) { companyMaster(filter:{primaryKey : {_eq : 12}}) { items { value } } } }     ... View more

There is no such table as CompanyInformation_Processings. There is a table called CompanyInformation. Depending on the operation you want to do, there are various fields that are available.   For queries: - companyInformation - companyInformation_aggregates   For mutations: - companyInformation_create - companyInformation_update - companyInformation_delete - companyInformation_processings   I do not actually know how you can query the current suspension date but I will try to find that for you. ... View more

We have improved the execution of queries from joined tables. This is described in detail here: https://docs.business.visma.net/docs/features/unoptimized   Mind that this has some limitations and depending on your needs, you might need to execute queries with the unoptimized flag. By default, they are now executed in an optimized manner. ... View more

As answered in the other similar question you asked on the forum, we have a limit of 1000 records for a table. Mind that a query can contain requests to multiple tables. This limit is per table, not per query.   Moreover, although it's not entirely clear to know what you are saying in the second part, it seems you are describing the problem with optimize queries that is detailed here: https://docs.business.visma.net/docs/features/unoptimized.   Mind that his problem only occurs when you asked for joined data and pagination is in effect. Since you query for more than 1000 records and this limit is enforced, pagination does occur. The immediate workaround for you is to execute the query with the unoptimized flag.    Although we can consider increasing the page limit, a limit will exist and you may still get into the same issue even if we increase it to 5000 or 10000. ... View more

No, you cannot get more than 1000 at a time. This is a limit we set for performance reasons. Maybe it could be higher but currently it is set to 1000.   If you need to fetch more records, you should use pagination: https://docs.business.visma.net/docs/features/pagination. ... View more

We are investigating this problem and will return with comments as soon as we have a solution. ... View more

Unfortunately, you cannot do anything right now to fix the long time it takes to execute.   Fortunately, this is a performance issue that we were aware of and has been fixed this week. If everything goes well, it will be released to production next Thursday.   The problem occurs because of the joined table. For one query on the GeneralLedgerPeriodBalance table that returns N elements, there are additional N queries to the GeneralLedgerAccount table. This is known as the N+1 problem and we are working to optimize it so that only 2 queries are made.   I will keep you posted when the release it. ... View more