to get a personalized navigation.
to get a personalized navigation.
Hi,
I am trying to create a SupplierInvoice using the Service API, but I immediately get an error saying that I do not have access to (any) branches. I do not understand the error, as an API user all branches seem accessible, at least when GETting. I get the error even when trying the Swagger and filling in ONLY the branchNumber (which in my case is 1 and does exist), while only removing the splitLine argument.
Have I missed a step? The tenant is accessible via the application as the Swagger does respond to GETs. Please advise, thanks!
{ "message": "Error creating supplierInvoice. No access to branch 1." }
Solved! Go to Solution.
Hi,
This thread is regarding issues with the service api towards endpoints in the standard Financials API.
There is no deadline on when the old authentication methods stops working overall, we have been saying that the salesorder endopints were getting removed during the summer, but this is no longer the case. An exact date for this has not yet been decided.
When will the new removal date be communicated?
We would like to plan our customer communication so that it will include both required authentication changes and information about the sales order changes.
Hi,
Currently we don't have a clear date. When it is decided, we will communicate this on the forum.
At the very latest, this happens 3 months before a breaking change, but most likely you will have a date before that.
Hello, according to our investigation, this issue is related to the Service Type API (Token) . Our development team has been informed on this issue, and we're currently looking into possible solutions. In the meantime, we recommend using either old authentication method or interactive API. Thank you for your understanding.
Hello Michel, unfortunately the plan has not been revealed yet.
Hi,
We are collecting the information from the cases that seems to be affected by this and informing the developers.
We will post more information here as soon as we have more information.
Thank you!
Hi,
For your information, we have no problems with companies that do not use branch protection (user access roles). When a company of ours has no restricting roles, then after a day or two, the error dissappears and the endpoint becomes fully funcitonal.
Hope this input helps!
I have the exact same issue and error, and have been trying to get this working for the last week.
When I change the API authentication back to the older VNI authentication, using the exact same body other than the different bearer token and including ipp-company-id headers, it works fine. But using the new Visma Connect Authentication I get this error "Error creating supplierInvoice. No access to branch 101". I am able to GET data without issue, just cant POST to this endpoint.
As such, this implies its not a user permission issue (as it works using old authentication under my same user account), but rather an issue with the permission / scope of the Visma Connect authentication.
Perhaps its not respecting the vismanet_erp_service_api:create scope in the token request? The token request does respond with that scope confirmation though:
Hi,
Thanks for your reply! I was testing it in Swagger, but I get the same error when trying via our application registered with the Visma Developer Portal. I have a client ID and secret, and the tenantID I would like to reach, but I do not see a possibility for giving roles to an application, or am I misunderstanding? I do have writing access as creating a Supplier did work via the Swagger.
Hope you can help!
Hi,
The API role gives the user access to the API via the new authentication method, sort of how the "Financials User" gives access to the UI.
For the operations in the ERP via the API you still need the rights setup in the ERP settings.
For the moment "Financials User" & "Financials Administrator" are still needed to perform all actions.
If it helps, we are working with a Service to Service type app via the Service API.
Hi,
Thanks for your reply! I was testing it in Swagger, but I get the same error when trying via our application registered with the Visma Developer Portal. I have a client ID and secret, and the tenantID I would like to reach, but I do not see a possibility for giving roles to an application, or am I misunderstanding? I do have writing access as creating a Supplier did work via the Swagger.
Hope you can help!
Hi,
Did you use the same user? And did you confirm that your user has the roles "Financials User" & "Financials Administrator"?
Hi,
I am not using a user, it is a Service Application, so I have a client-id, client-secret and tenant-id.
When using my own user account via the Swagger, I am able to add (write) new Suppliers to the environment, but I cannot create a SupplierInvoice, as I mentioned in my post.
Alright, thank you we'll inform the development team.
Hi, any update? Has it been marked as a bug? Thanks ahead!
Hello,
For the moment, the endpoints that are not working with the service API are because of the way the ERP system works. It's designed to pin actions on users, since the service api does not carry any information regarding the user, it's not possible to do for the time being at least. We've registered cases about this with the developers.
Meantime,
there is an option called "offline_access" so that if you need your integration to work after the user has logout of your app, then you can implement the OAuth with offline_access.
Hi,
Thanks for the answer. Though it seems I will have to wait for the fix, because this option is not available for me I think.
Hi,
The "offline_access" token is used in conjunction with the interactive API.
So you'd have the user logon to perform the actions that needs a user, the after they log out, you run the operations you need to with your service api, for the actions needing a user, you use the users offline token.
So for how long will this offline token work? This is also extra work for developers because for the service API we don't need to support user auth flows.
Cheers,
Copyright © 2022 Visma.com. All rights reserved.