Order type credit card order

[omelhus]

Hey,

Is there a way to create orders with orderType 9 using the API?

- Ole

[omelhus]

I think this actually is part of a bigger issue with the API-implementation. The API is treated as a user, and access to fields and values that would be useful for an integration but not a user in the UI is not available.

Another example of this is voucherType on voucher where a voucherType might be protected from being used manually ("sperret"), but it would be good to be able to set this through the API and still have it disabled for end users. I also want to set origin on batch, but that's read-only in the model.

I understand that these are limitations in the core of Business and not the API per say, but I think that this is an issue worth discussing.

[Marius Bancila]

I understand your needs here. I think there is a nice solution (that we can't have now) and not a so nice solution (that could be implemented).

The nice solution would be to have different schemas. But the schema is built generically from the model. And currently, we only support one model for everyone. This may change in the future. But as long as there is one model we have one schema.

What could potentially be possible are two schemas:

- one for user scenarios, when you logon with a user and use the https://business.visma.net/api/graphql endpoint

- one for service scenarios, when you logon with a service's client id/secret and use the https://business.visma.net/api/graphql-service endpoint

The other solution that I don't like is that we expose in the schema fields that could be accessible by a system (not a user). However, in the one-model-one-schema world, that means showing those fields to everyone and then returning access right errors when they try to use them. Which will create confusion and support tickets. For this reason, I am against such a solution.

[omelhus]

What we have today is already the latter that you don't prefer (and this is one of the support tickets from a confused user, myself.). I'm not asking for the ability to write to fields like ePw etc, but rather setting values in fields like orderType or voucherSeriesNo to values that are not available to users.

This would not be a change in the schema, but an ability to set values that are not accessible as a user. Maybe this could be a flag on the client id in the developer portal? Or maybe a setting on the access in "Connect application"?

I suspect that this is a core issue with Business though, and not an issue with the API.

[Marius Bancila]

Yes, the GraphQL schema is generically built from the Business model. The limitations are imposed in the model for both the on-prem API and the GraphQL API.

[omelhus]

So how can we include the core team in this discussion going forward? 

Øyvind, have you raised this issue already? Any feedback?

[Øyvind Årseth]

I agree, and will raise the issue internally. 

[Øyvind Årseth]

Hi Ole, 
For the record, since we discussed the issue in another channel: 
Order type 9 was created for use in conjunction with Zpider. You can not use order type 9 with manual entry, it can only be imported with the EDI-clock in Visma Business. Consequently, it is not available in the API.
The EDI-clock does not exist in VBNXT, nor is there a plan to replace it directly. If the functionality is still needed, it will have to be API-based = some changes needed. Discussion is on I suppose😉

Øyvind