Hello, What is the status about rate limiting today? I can't find any documentation about this, nor do I observe any limitations occurring. I started 500 calls in parallel and as far as I can tell from the logs, none of them failed. Does it depend on what the query is trying to fetch? Thank you for your help. ... View more

Hi,   I work with Florian and have additional information about the issue.   First: It is easy to verify that a query on a large table (>500k rows) returns different rows for the same "first" and "skip" arguments when OrderBy is not given. (You have to skip ca 300k rows to trigger the problem.)   Second: The model information query for columns (Model information | Documentation (vismasoftware.no)) does not return information about which columns constitute the PK of the table. Because composite PKs are possible, the model information query should flag each PK column with its physical position in the composite PK. Requesting ordering by PK columns in different order than their physical order will return a correct result, but with a heavy performance hit. (Example: if a table has schema (A, B, C, D) with (A, B) as composite PK, then column A should be flagged with "PK[0]" and column B with "PK[1]".)   Third: Using GraphQL schema introspection query, it is possible to get a "description" for each column. The "description" for PK columns begins with "[PK]", but there is no indication of the column's physical position in the PK.   Lastly: The GraphQL API exposes date and time columns both as integers and as "proper" date/time types (with "AsDate", "AsTime" suffix). The schema introspection query flags both the "int" column and "AsDate" column as PK, presumably because they map to the same physical column. The "AsDate"/"AsTime" columns should never be flagged as PK (when present in the PK) because they're not even available for use in OrderBy. ... View more

What is the status here? We also need the suspension date info and still can't get this information from the API. We wonder how to do it? ... View more

Hi Oskar,   no, the problem was solved after we escalated it internally in Visma in the weekend. We could not wait until today since the whole integration platform stopped. I think somebody in the connect team knows exactly what happened, but I think it was due to a lot of token traffic from our side after the API got to live again. But we have to find out how we can quick enough answers when all is stopping due to such incidents also during a weekend.   Florian ... View more

@Magnus Johnsen Does this apply for the salesorder /api/v1/salesorder andpoint as well?  ... View more

Yes there is:  We currently offer a solution tailored for accounting offices. In this context, it is essential for us to identify any open customer transactions and perform specific processes on them. Presently, our approach involves executing a SQL query to determine the existence of open transactions, and subsequently, we record this information in either a master client or the vbsys. This allows us to selectively carry out the necessary processes only for those clients with active open transactions. However, this method may pose challenges in Bnxt due to the need to iterate through over 1000 companies to identify where open transactions exist. To streamline this process, we initially considered leveraging the TaskOverview. While an alternative solution involving webhooks might be viable, it could introduce technical complexities and potentially be less stable compared to the simplicity of retrieving information directly from a table.   Florian ... View more

Yes, also we have reported this before.  ... View more

Did you set this adding / removing of bit-values on a feature-list for future versions?  We also see that this is needed. ... View more

Hi, we would also like this.   Is it possible for you to add notes to the lines aswell? ... View more

Thank you  ... View more

The fix for this has been deployed to production. ... View more

We have added support for including status code names in the response. Example:   { "errors": [ { "message": "A record with the same primary key already exists.", "path": [ "useCompany", "order_create", "values/0" ], "extensions": { "data": { "status": 3, "status_name": "PrimaryKeyAssignmentFailed" } } } ], "data": { "useCompany": { "order_create": { "items": null } } } }   You can read about it here: https://docs.business.visma.net/docs/features/errors#understanding-error-information   ... View more

What I want is for the api to have a different level of access than a user.  When it’s a user context it’s it should be like today, but when we are using the service client ids we should have the same access as the edi import. ... View more

Ok, That would also be a very rare scenario. But good to know.   Thank you ... View more

The limitation is enforced in the reverse proxy. ... View more

The companyNo should be a 7 digit number which relates to the companyID from the Visma Connect plattform and not the internal Visma Business CompanyNumber. The advantage is that you can write API-integrations across different customers by using the Visma-unique companyNumbers.   ... View more

Hi, I did get the same errors, what i found out it's the field externalId must have unique value. So when trying to save empty string, i think either the api or model looks at it as same value ... View more

Hey @Anonymous  Just to be clear: The official you expect returned, it is from orgUnit8 right? My test on the same query (except the filter) seems to work fine: query ($cid: Int!){ useCompany(no: $cid) { orgUnit8(filter: {orgUnit8No: {_eq:"ABC"}}, sortOrder: {createdDate: ASC _thenBy: {createdTime: ASC}}) { items { orgUnit8No orgUnit1 name official joinup_Associate_via_Official { employeeNo associateNo name shortName} } } } } {"data": { "useCompany": { "orgUnit8": { "items": [ { "orgUnit8No": "ABC", "orgUnit1": 11, "name": "Alfa", "official": 4, "joinup_Associate_via_Official": { "employeeNo": 4, "associateNo": 322, "name": "Ole Olsen", "shortName": "Ole Olsen" } .... @Florian Haase wrote: Hi,   I can't get the joinup from orgUnit8 working on the associate by official:   query { useCompany(no: 4655191) { orgUnit8(sortOrder: {createdDate: ASC _thenBy: {createdTime: ASC}}) { items { orgUnit8No orgUnit1 name official joinup_Associate_via_Official { employeeNo associateNo name shortName } } } } }     Result: "data": { "useCompany": { "orgUnit8": { "items": [ { "orgUnit8No": "A1000", "orgUnit1": 1000, "name": "Avdeling 2", "official": 14179, "joinup_Associate_via_Official": null }, .....   Why is the official on OrgUnit8 14179 but the result of the joinup is null - we have checked the data consistency and all seems okay. Also the UI is working on that.    Florian      ... View more

Maybe I have to go the otherway around: query { useCompany(no: 9999) { picList ( filter: {pickListStatus: {eq:8}} ) { totalCount items { joindown_OrderDocument_via_Order{ orderDocumentNo documentType group3 } } } } } That should work I guess ? ... View more

They are primarily used with order documents via AutoInvoice as far as I know, without going into details🙂 ... View more

Would be cool if batch operations were executed in parallel, since they won’t share any data between them. And if you need something executed sequentially you could use the “inline batch”. ... View more

To follow the status: https://status.visma.com/incidents/dhqjdnqv4g0w ... View more

Yes! That seems to work now, thank you!   ... View more

Thank you, that was exactly what we wanted. I see, we used the wrong joining path - sorry ... View more