I hope you get it, it would be great if we could change Fonts, not just size. Since this is very important for most customers, many of them have very customized appearance of forms. ... Skatīt vairāk

Just read the docs. Would be useful if when both parameters are defined it would use the lang: NORWEGIAN as a fallback if langNo is not defined or invalid. ... Skatīt vairāk

Hi, I realised I missed a step, thank you! ... Skatīt vairāk

I agree the message is obscure. I will add a ticket in our backlog to see how we can improve this. ... Skatīt vairāk

It's documented here https://docs.business.visma.net/docs/schema/mutations/inserts#insert-between-existing-records but works as described above basically. ... Skatīt vairāk

I want to second this NB. The order of fields assignment is important in BNXT. This is way putting the suggested fields at the end may lead to incorrect results. For this reason we made that feature obsolete a while ago (should be removed actually from our API). Use null as a value to indicate suggest.   voucher_create( values: [ { batchNo: $batchno, voucherNo: null, amountDomestic: 14296.19, debitAccountNo: 7519, valueDate: 20240602, voucherDate: 20240601, voucherType: 50 }, { batchNo: $batchno, voucherNo : null, amountDomestic: 14296.19, creditAccountNo: 2920, valueDate: 20240602, voucherDate: 20240601, voucherType: 50 }] ) { affectedRows } Note that I'm not saying this is the cause of your problem, but it can be the cause of problems in other cases. ... Skatīt vairāk

Thanks! My workaround broke this morning, so I figured you had fixed it 🙂 ... Skatīt vairāk

We have made some changes to that fields that are assigned from unset variables are ignored.  https://docs.business.visma.net/docs/schema/mutations/inserts#assigning-fields-from-unset-variables   ... Skatīt vairāk

Is this still occurring? We deployed last week a fix for a parsing error. It's possible that we have another one. But if you still experience this (as I assume from your question), can you share another trace ID?  ... Skatīt vairāk

Yes, we can add the database type to the model info. We will consider the access rights on tables, columns, etc. too. ... Skatīt vairāk

This problem is now fixed. When you got this message, the problem was a row locked by other process. There was an error in our parsing of this response from the backend.  ... Skatīt vairāk

This was implemeted a while ago. Can also be combined with @export to fetch keys from one table and look them up in another. ... Skatīt vairāk

In my code I do get the correct finished qty if I do a query directly after I have done the mutation but in my view I should not have to do that query because the mutation should project those values back. Could it be that the mutation returns to quickly before the finish processing has been completed ? ... Skatīt vairāk

Distinct is available for now only in the old table_aggregate fields. ... Skatīt vairāk

Ok, then we'll update the queries on our end. ... Skatīt vairāk

This problem is now fixed. https://docs.business.visma.net/docs/releasenotes ... Skatīt vairāk

This problem is now fixed. https://docs.business.visma.net/docs/releasenotes ... Skatīt vairāk

Hey,   This would be incredible useful. Please see if there's any chance to implement it. ... Skatīt vairāk

Haven't heard anything about this issue for a little while. Any plans to address these issues? ... Skatīt vairāk

This is due to a change we did for performance improvement in GraphQL. Previously, we would be selecting entire rows, no matter now many fields you wanted from a table. Now, we are only selecting exactly what you ask for. However, if you ask for nothing, you get nothing. Therefore, you cannot have join-only fields in the schema, such as here: taxAndAccountingGroup { items { joindown_TaxAndAccountingInformation_via_TaxAndAccGroup { items { joinup_TaxCode_via_TaxCodeSales { joinup_Vat { rate } } } } As you figured it out, it works, if you add at least one field. But you did that do that with joinup_TaxCode_via_TaxCodeSales. Here is a query that works: query GetTaxAndAccountGroups($cid: Int!) { useCompany(no : $cid) { taxAndAccountingGroup { totalCount items { taxAndAccountingGroupNo description joindown_TaxAndAccountingInformation_via_TaxAndAccGroup { totalCount items { taxAndAccountingGroup description joinup_TaxCode_via_TaxCodeSales { taxCode joinup_Vat { rate } } } } } } } } Result: { "data": { "useCompany": { "taxAndAccountingInformation": { "totalCount": 8, "items": [ { "taxAndAccountingGroup": 1, "description": "Avgiftspliktig høy sats", "joinup_TaxCode_via_TaxCodeSales": { "taxCode": 3, "description": "Utgående MVA - høy sats", "joinup_Vat": { "rate": 25 } } }, { "taxAndAccountingGroup": 2, "description": "Avgiftsfritt", "joinup_TaxCode_via_TaxCodeSales": { "taxCode": 4, "description": "Avgiftsfritt salg innland", "joinup_Vat": null } }, ... Skatīt vairāk

Great, thanks for letting me know. ... Skatīt vairāk

That's great, thanks! ... Skatīt vairāk

Yes, if orgUnit1 is department and orgUnit2 is project, we want the ability to query general ledger transactions grouped by year, period, account, department and project, so that we get individual numbers for each combination of department and project.   Edit: I looked briefly at the new groupBy feature, and it seems as if it covers what we need. ... Skatīt vairāk

What exactly do you mean? Do you want to find whether it's possible to do insert, update, or delete for a particular table? ... Skatīt vairāk

Did you set this adding / removing of bit-values on a feature-list for future versions?  We also see that this is needed. ... Skatīt vairāk

Hi, I tried these two but but both giving me null  query GetpaymentInfoFromCustomerTransaction { useCompany(no: 3867961) { customerTransaction( filter: { voucherType:{_eq:11} paidStatus:{_in:[3,4]} } ) { totalCount pageInfo { hasNextPage hasPreviousPage startCursor endCursor } items { customerNo orderNo invoiceNo voucherNo voucherType amountDomestic outstandingAmountDomestic cid dueDate crossReference paidStatus paidLast createdDateTime changedDateTime voucherDate } } } } ---------------------------------------------------------- query GetPaymentLines { useCompany(no: 3867961) { paymentLine(first: 1) { items { paymentNo lineNo currency : joinup_Currency { isoCode } supplier : joinup_Associate_via_Supplier { bankAccount country : joinup_Country { isoCode } } } } } } ... Skatīt vairāk

So you are saying that the functionality with suggesting values for entities using null is moot when you are using variables?   When I create or update entities I almost exclusively use variables for inputs. Using parameters for all just doesn't make any sense.   Please disable the suggest-functionality for entities in a variable, that is not enabled by suggest: { field: true }. ... Skatīt vairāk