No access to branch when trying to create SupplierInvoice

[ExactGebruiker]

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."
}

[Yıldırım]

ℹ️ This has been fixed in [Release Notes] - Visma.Net API 9.59.0 - 16.08.2023

[ExactGebruiker]

Hi,

It seems this has not been fixed. Maybe I am misunderstanding the fix? When trying to create a SupplierInvoice we still get the no_access error. How am I supposed to provide access if there is no user account linked to the access role?

'No access to branch 1' is the exact same error as before. Could you explain the fix? Thanks.

[Yıldırım]

You can check available branches for the company by checking it via the Supplier Invoice > Document Line or Financials Details branches. 

- In our test, we're able to POST Supplier invoice with available branches with Service_Type token. 

1) Organization Settings (ScreenId=CS101500)

1.1) Main Org. with 2 Branches  

1.2) Secondary org. with 2 branches

2) POST Supplier Invoice (Generated token with Service_API)
e.g. to
- Main Organization > "02" Branch ✔️
- Main Organization > "021" Branch ✔️

- Secondary Organization > "03" Branch ✔️
- Secondary Organization > "031" Branch ✔️

View more

{

    "documentType": {

        "value": "Invoice"

    },

    "date": {

        "value": "2021-09-16"

    },

    "postPeriod": {

        "value": "072019"

    },

    "financialPeriod": {

        "value": "201909"

    },

    "supplierReference": {

        "value": " VAT UI TEST API1234"

    },

    "description": {

        "value": "TEST"

    },

    "supplierNumber": {

        "value": "50000"

    },

    "supplierTaxZone": {

        "value": "02"

    },

    "creditTermsId": {

        "value": "14"

    },

    "paymentMethod": {

        "value": "1"

    },

    "cashAccount": {

        "value": "1910"

    },

    "branchNumber": {

        "value": "031"

    },

    "invoiceLines": [

        {

            "operation": "Insert",

            "transactionDescription": {

                "value": "Test"

            },

            "inventoryNumber": {

                "value": "122"

            },

            "quantity": {

                "value": 1

            },

            "costInCurrency": {

                "value": 50

            },

            "accountNumber": {

                "value": "3260"

            },

            "vatCodeId": {

                "value": "01"

            },

            "branchNumber": {

                "value": "031"

            }

        }

    ]

}

Financials Output:

[ExactGebruiker]

Thanks. Ok, but did you try it with an access_role attached to a branch? See below. When applied to a branch, only users attached to the access_role can access the branch, which an API cannot as does not have a user.

Please try it with a user role attached to the branch (and wait a day or 2) and try again. It seems you have some saved cache on this subject so immediate change in these roles is not the case via the API. 

That, or try to recreate the error (no access to branch n) on your own, as without this, you would not get the error I feel.

[Yıldırım]

Hi, I've added "Administrator" role and did POST, it works, however I'll wait 2–3 days as you mentioned and test this again. 

[ExactGebruiker]

Hi Yildirim,

Could you also try it with a custom made access role? We use access roles to split access to branches between users, so we cannot use Admin for the split, as there should be multiple roles assigned to different branches. Thanks!   

[Yıldırım · Accepted solution]

Hello, 

tested the case again today, I'm able to POST Supplier Invoice without receiving Branch not found error.  If you're still receiving the error, we might need to specifically check your company & integration setup, so please contact us via developersupport@visma.com and share your companyID & Application details from the developer portal. 

Thanks.  

[Yıldırım]

Hi, tested it again after a day of the setup, and it is working, I'll wait a little longer before testing it again.

Configuration:

1) Created a custom User Role & Assigned the user/s

2) Restricted the access with the User Role

3) Re-generated a service_type Token 
4) POST Supplier Invoice to User Role restricted branchID: "03"

View more

{

    "documentType": {

        "value": "Invoice"

    },

    "date": {

        "value": "2023-08-29"

    },

    "postPeriod": {

        "value": "082023"

    },

    "financialPeriod": {

        "value": "202308"

    },

    "supplierReference": {

        "value": " VAT UI TEST API12345"

    },

    "description": {

        "value": "TEST"

    },

    "supplierNumber": {

        "value": "50000"

    },

    "supplierTaxZone": {

        "value": "02"

    },

    "creditTermsId": {

        "value": "14"

    },

    "paymentMethod": {

        "value": "1"

    },

    "cashAccount": {

        "value": "1910"

    },

    "branchNumber": {

        "value": "03"

    },

    "invoiceLines": [

        {

            "operation": "Insert",

            "transactionDescription": {

                "value": "Test"

            },

            "inventoryNumber": {

                "value": "122"

            },

            "quantity": {

                "value": 1

            },

            "costInCurrency": {

                "value": 50

            },

            "accountNumber": {

                "value": "3260"

            },

            "vatCodeId": {

                "value": "01"

            },

            "branchNumber": {

                "value": "03"

            }

        }

    ]

}

5) Financials output:

[Yıldırım]

Hei, sure, could you please share that custom user setup (Steps you've followed etc.) via developersupport@visma.com ? 
To make sure that I'll apply the same config. 

[roy_muller]

We have a fix for this issue that is currently being tested. If all goes well, I expect this to be part of next release (9.59) which is scheduled for next week.

[ExactGebruiker]

Great to hear!

[roy_muller]

Seems this might be related to role access set up for the branch. One can choose a role that a user must have in order to access a branch. This is administered in screen CS101500:

If a role is stated here, the user associated with the API request must have this role in order for the logic behind to successfully access the branch.

When using the service-API, there is no ordinary user associated with the API request, but rather a system user associated with the integration client. These "users" will not have regular roles. A workaround is to let this field be empty, or set it to "Administrator".

We will find and remove these limitations; when using service-API, all branches should be available. However, there are some endpoints requiring a "human user" to be associated with and API request - for the time being, these are only accessible via the interactive-API since only these are associated with a "real" user.

[ExactGebruiker]

Hi,

This was already know. It is simply rediculous that the new authentification process omits your own Service API way of working. Am I to understand that there will be no fix for this? We do use access roles in over half of our companies (around 30 contexts) in order to divide access rights to certain branches for certain users. This means that for these companies our new application is simply unusable. This seems to me honestly like an urgent problem for the API department, but apparently Visma thinks otherwise.

[roy_muller]

Of course we will fix this issue. This was just to offer a possible workaround until the problem is fixed.

[KonsultVn]

Hi,
What is the latest news on this? We just did a test today where we converted an integration in test to use Visma Connect authentication (Service API), instead of VNI. Mostly it went fine, but when we tried to post a SupplierInvoice, we got "Error creating supplierInvoice. No access to a branch." We repeated the process, and got the same error from Postman. However, roughly 1h later, we tried again from both postman and the integration, and it worked. Any idea why it did not work at first? And why it works now?

We are planning on moving several hundred Service-integrations to Visma Connect during the fall, starting august. But we also need to be able to trust the new authentication system, before we reliably can start any migrations.

 

[Joonas_Virtasoft]

I also encountered this problem when we were supposed to update my clients integration to use the new SalesOrder API and also change the authentication method for the Service endpoints at the same time. Everything else seemed to work (SalesOrders, Inventory items and quantities, Customers..) but when trying to add a payment to a SalesOrder using CustomerPayment we received the error:

"Error creating payment. Error: BranchID' not found in the system. Check whether you have access rights to this object."

We have decided to rollback to the older version for now. I hope the culprit is found for this issue (be it requirements for user settings or something that needs to be fixed in the API itself), I'm also happy to provide additional information if needed.

[Magnus Johnsen]

Hi,

For the time being, this is how endpoints that require an user are to be handled:

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. 

Documentation

[Michel V]

Hi Magnus,

What is the best way to work with the new Sales Order API? Does it work properly with a 'Service' type application?
You are unable to select the required integration in the developers portal if you choose a 'Web' type application.

It seems a bit weird that you are not able to make a Web type application for the new Sales Order API. 

[ExactGebruiker]

Hi,

Does that mean we have to create a new application with different authentification methods (As we now use the Service to Service API, we would have to switch to Web based for example)? That seems like saying 'this API service does not work, please try a different one'. Why offer this one then if authorizations are based on users and this service does not include user rights? Seems like a top priority to fix, and now it sounds like you are fine with the current situation for the time being.

[JohanFriedrichsen]

We're planning an authentication upgrade of 60+ customers in preparation of moving to the SalesOrder service. However, there seem to be more and more issues where the "solution" is to use the old auth model or v1/v2 endpoints. This seems a bit strange sine the communicated deadline is now less than 2 months away.

With multiple customers affected we need to be sure that we can have clear communication with them regarding when things need to change. As it seem right now this is not a production ready implementation.