About Marius Bancila

Marius Bancila · ‎26-09-2024

Working on a fix. For a query like: query read_orders($cid : Int!) { useCompany(no : $cid) { order(first: 10) { items { orderNo orderDate customerNo supplierNo employeeNo joinup_Associate_via_Customer { customerNo supplierNo employeeNo name } joinup_Associate_via_Supplier { customerNo supplierNo employeeNo name } joinup_Associate_via_Employee { customerNo supplierNo employeeNo name } } } } } The results will be as follows: { "data": { "useCompany": { "order": { "items": [ { "orderNo": 1, "orderDate": 20210212, "customerNo": 10002, "supplierNo": 51004, "employeeNo": 0, "joinup_Associate_via_Customer": { "customerNo": 10002, "supplierNo": 0, "employeeNo": 0, "name": "Me AS" }, "joinup_Associate_via_Supplier": { "customerNo": 0, "supplierNo": 51004, "employeeNo": 0, "name": "Abc AS" }, "joinup_Associate_via_Employee": null }, { "orderNo": 2, "orderDate": 20130203, "customerNo": 0, "supplierNo": 0, "employeeNo": 0, "joinup_Associate_via_Customer": null, "joinup_Associate_via_Supplier": null, "joinup_Associate_via_Employee": null }, { "orderNo": 3, "orderDate": 20130401, "customerNo": 10004, "supplierNo": 0, "employeeNo": 0, "joinup_Associate_via_Customer": { "customerNo": 10004, "supplierNo": 0, "employeeNo": 0, "name": "You AS" }, "joinup_Associate_via_Supplier": null, "joinup_Associate_via_Employee": null },

Marius Bancila · ‎26-09-2024

Your observation is correct. The result is not as expected. My only comment is that it joins the first associate that has employeeNo set to 0, which of course is not an employee (should be a customer or supplier), as you mentioned. We are looking for a solution to fix this problem.

Marius Bancila · ‎03-09-2024

I reported this internally.

Marius Bancila · ‎03-09-2024

_Ppn stands for Processing Parameter Node _Rpn stands for Report Parameter Node There are some additional suffixes. The reason for this is that there were cases with colliding type names which resulted in invalid schema (a schema that didn't reflect well the data model).

Marius Bancila · ‎19-07-2024

This is now available. See https://docs.business.visma.net/docs/schema/queries/modelinfo#language-selection

Marius Bancila · ‎05-07-2024

Yes, you can do that with @export, but it doesn't work because of way we read the no argument in useCompany/useCustomer. This doesn't currently work: query companies_and_all($cid : Int = 0) { availableCompanies(customerNo : ...) { totalCount items { vismaNetCompanyId @export(as : "cid") name } } useCompany(no : $cid) { generalLedgerAccount(first :5) { items { name accountNo } } } } But can easily be made to work.

Marius Bancila · ‎05-07-2024

Thanks for reporting the problem in the docs. It's fixed now.

Marius Bancila · ‎05-07-2024

And how would that look?

Marius Bancila · ‎05-07-2024

Unfortunately, I was wrong. Assigning an Int to a Long is not possible. GraphQL specification prohibits coercing one scalar type into another. Therefore, changing this would be a significant breaking change. An alternative would be to have yet another argument, of type Long, with the same meaning of the arg no. I'm afraid such an approach would lead to lot of confusion (even if we deprecate the existing one).

Marius Bancila · ‎03-07-2024

I agree the message is obscure. I will add a ticket in our backlog to see how we can improve this.

Marius Bancila · ‎02-07-2024

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

Marius Bancila · ‎02-07-2024

Assigning an int to a long should not be a problem. But will investigate different scenarios.

Marius Bancila · ‎02-07-2024

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.

Marius Bancila · ‎02-07-2024

Yes, the two are inconsistent. I would invoke historical reasons for this. But I suppose we can make no in useCompany an argument of the type Long too. I don't think this would have breaking changes for anyone.

Marius Bancila · ‎02-07-2024

We can add an additional numeric parameter langNo, as alternative to lang.

Marius Bancila · ‎20-06-2024

I will bring this to the attention of those who can change it.

Marius Bancila · ‎20-06-2024

We released a fix for this problem today (https://docs.business.visma.net/docs/releasenotes). We will be correcting the data that was stored base64 encoded instead of binary.

Marius Bancila · ‎20-06-2024

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

Marius Bancila · ‎14-06-2024

Just to clarify one thing, about specifying insert position/direction: we won't have both the option of a boolean and an enum. Those two are possible options for designing these schema changes. I tend to opt for the enum (even making it optional) but any feedback here is welcomed.

Marius Bancila · ‎13-06-2024

For this feature, we need to provide a better way to find the place where the new rows are to be inserted. So instead of providing a number as mentioned above, we would provide a filter. The schema is exactly as for the filter argument in read/update/delete operations. However, I suggest we call it differently, such as "insertAtRow". Here is an example of inserting a new line after the 2nd line (in sort order) for the order with number 123: mutation insert_line($cid : Int!) { useCompany(no : $cid) { orderLine_create( values : [{ productNo : "uno", quantity : 1, priceInCurrency : 100 }], insertAtRow : {_and : [ { orderNo : {_eq : 123}} { sortSequenceNo : {_eq : 2}} ]}, insertPosition : AFTER) { affectedRows items { orderNo lineNo sortSequenceNo productNo quantity priceInCurrency } } } } You can also specify whether the insertion should occur before or after. Here there are two choices: have an argument like I suggest of an enum type with the values BEFORE and AFTER, which should be mandatory have an optional Boolean argument "insertAfter" that indicates whether the insertion occurs after the identified row; the default, if missing, could be true, so you only need to specify it with the value false if you want inserting before. If the filter matches multiple lines, the insertion occurs after/before the first result row. Ideally, the filter should contain the primary key to ensure you identify the right position, but it actually can contain anything that will match the desired row for insert position. Also notice that when inserting like this, the primary key should not be specified in the "values" objects. This is because the primary key is automatically populated when inserting between existing rows. If you do specify it, an error will occur.

Marius Bancila · ‎13-06-2024

We are working on fixing the base64 encoding problem.

Marius Bancila · ‎13-06-2024

I suppose the problem you are reporting is that you get back base64-encoded-base64-encoded content. For instance, an example binary field is htmlFile in emailTemplate table. So I took this HTML text: <html> <body> <h1>Base64-encoding</h1> </body> </html> and encoded it to base-64, which is: PGh0bWw+Cjxib2R5Pgo8aDE+QmFzZTY0LWVuY29kaW5nPC9oMT4KPC9ib2R5Pgo8L2h0bWw+ And I run the following mutation: mutation upload_invoice_attachment_directly( $cid: Int!, $description: String!, $data: String!) { useCompany(no :$cid) { emailTemplate_create(values : [ { description : $description htmlFile : $data } ]) { affectedRows items { emailTemplateNo htmlFile } } } } with vars: { "cid" : ..., "description": "testing base64-encoding", "data": "PGh0bWw+Cjxib2R5Pgo8aDE+QmFzZTY0LWVuY29kaW5nPC9oMT4KPC9ib2R5Pgo8L2h0bWw+" } What I get back is: { "data": { "useCompany": { "emailTemplate_create": { "affectedRows": 1, "items": [ { "emailTemplateNo": 1, "htmlFile": "UEdoMGJXdytDanhpYjJSNVBnbzhhREUrUW1GelpUWTBMV1Z1WTI5a2FXNW5QQzlvTVQ0S1BDOWliMlI1UGdvOEwyaDBiV3cr" } ] } } } } At this point, the htmlFile contains base64 in the database and that's what we get back, and then we get back a base64-encoded of a base-64 encoded text.

Marius Bancila · ‎13-06-2024

I'm investigating the issue. Generally speaking, it's always helpful to post the query that has error or works unexpectedly. It's much easier to repro the exact problem.

Marius Bancila · ‎11-06-2024

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?

Marius Bancila · ‎06-06-2024

Yes, we can add the database type to the model info. We will consider the access rights on tables, columns, etc. too.

Marius Bancila · ‎05-06-2024

It is possible that we do that. Is there a specific shape of the request that you're thinking of? Like an extra argument, for instance oderLine_create(values : [{...}], insertAfter : 1) { }

Marius Bancila · ‎04-06-2024

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.

Marius Bancila · ‎31-05-2024

I'd want our API to be as simple and usable as possible. But building APIs is hard. There is always something that people want different. We are trying to meet the needs but it's not always possible. Sometimes bugs become features, sometimes unintentional breaking changes happen. Changing the functionality as described is possible and not very complicated. I'm only trying to figure out if it makes more sense this way or the way it works now.

Marius Bancila · ‎31-05-2024

I can change the implementation so that fields assigned from unset variables are ignored. In your example, you set phone, mobilePhone, and privatePhone: mutation UpdateCompany( $companyID: Int! $customerNo: Int!, $phone: String, $mobilePhone: String, $privatePhone: String, ) { useCompany(no: $companyID) { associate_update( filter: { customerNo: { _eq: $customerNo } }, value: { phone: $phone mobilePhone: $mobilePhone privatePhone: $privatePhone } ) { affectedRows } } } But only set $phone in the variables: { "companyID" : 4000000, "customerNo": 11000, "phone": "94000000" } We can identify variables that are not given a value, and then leave out the fields assigned through them. The query would be treated by our service as it was written like this: mutation UpdateCompany( $companyID: Int! $customerNo: Int!, $phone: String ) { useCompany(no: $companyID) { associate_update( filter: { customerNo: { _eq: $customerNo } }, value: { phone: $phone } ) { affectedRows } } } Is this what you would want?

Marius Bancila · ‎30-05-2024

I understand that this is a problem because it's a breaking change. I want to mention that this has not been done on purpose, although we did not realize the change in behavior. To be honest, we didn't have a test where fields are set in an insert/update operation from a variable that is not set. I'll make sure to include that now.

Re: Issue with joinup when the foreign key is 0

Re: Issue with joinup when the foreign key is 0

Re: Memo-Content caching in UI

Re: Many types with new names after the last relea...

Sv: Inconsistencies in data type for companyNo/vis...

Re: Inconsistencies in data type for companyNo/vis...

Sv: Invalid_scope when fetching access token with ...

Re: Inconsistencies in data type for companyNo/vis...

Re: Inconsistencies in data type for companyNo/vis...

Sv: Upload document to voucher errorfailedToFetchD...

Sv: Setting sortSequenceNo on orderLine

Re: Inconsistencies in data type for companyNo/vis...

Re: Inconsistency in voucher_create mutation

Re: Inconsistencies in data type for companyNo/vis...

Sv: Inconsistencies in data type for companyNo/vis...

Re: Fields that are writeable should always be rea...

Re: Encoding issues with base64 fields

Re: Fields are cleared on update mutation

Re: Setting sortSequenceNo on orderLine

Re: Setting sortSequenceNo on orderLine

Re: Encoding issues with base64 fields

Re: Encoding issues with base64 fields

Re: Encoding issues with base64 fields

Re: The request could not be executed: get availab...

Re: Model info should include databasetypeno on ta...

Re: Setting sortSequenceNo on orderLine

Re: Error: The request could not be executed: unab...

Re: Fields are cleared on update mutation

Re: Fields are cleared on update mutation

Re: Fields are cleared on update mutation

Useful pages

About Visma

Contact us

Follow us