to get a personalized navigation.
to get a personalized navigation.
What I tried to do
Create an invoice through the API in my organization's sandbox company.
request headers:
{ "accept": "application/json", "authorization": "Bearer 12345678-abcd-abcd-abcd-123456789012", "ipp-application-type": "Visma.net Financials", "ipp-company-id": "2628707" }
request body:
{ "customerNumber": { "value": "200508" }, "documentDate": { "value": "2020-10-27T00:00:00.000Z" }, "financialPeriod": { "value": "202010" }, "invoiceLines": [ { "accountNumber": { "value": "80200" }, "operation": "Insert", "quantity": { "value": 100 }, "unitPriceInCurrency": { "value": 5 } } ] }
What did I expect
Just as in my developer ISV company I expect a HTTP 201 response and to see the invoice created.
What did I see
HTTP 400 response with the following ...
headers:
Date: Wed, 04 Nov 2020 19:09:22 GMT Strict-Transport-Security: max-age=31536000; includeSubDomains, max-age=31536000; includeSubDomains Content-Type: application/json; charset=utf-8 ipp-request-id: eb49fa86-f7b4-49ff-86a1-2ac6001f2ec5 X-Content-Type-Options: application/json Pragma: no-cache X-Handled-By: Acumatica-PX.Export/AuthenticationManagerModule Referrer-Policy: origin-when-cross-origin VnfInstanceId: ERP_NL_DEMO_0009 Cache-Control: no-cache,no-cache Feature-Policy: geolocation 'none'; vr 'none'; payment 'none'; midi 'none'; microphone 'none'; fullscreen 'none'; encrypted-media 'none'; camera 'none'; autoplay 'none'; Expires: -1 X-XSS-Protection: 1;mode=block Set-Cookie: LegacyUI=0; path=/; secure; HttpOnly,UserBranch=15; path=/; secure; HttpOnly,Locale=TimeZone=GMTE0000U&Culture=en-GB; path=/; secure; HttpOnly,LicenseRoles=; expires=Tue, 03-Nov-2020 19:09:19 GMT; path=/; secure; HttpOnly,UserDisplayName=; expires=Tue, 03-Nov-2020 19:09:19 GMT; path=/; secure; HttpOnly Connection: close Transfer-Encoding: chunked
message:
{ "message": "Error: Inserting 'Sales invoice/note' record raised at least one error. Please review the errors.\r\nError: Branch '1 ' cannot be found in the system.\r\n" }
Discussion
There are several odd things about this situation:
Solved! Go to Solution.
Hi,
For the incident where this error occurs after the initial request with a Service type token the status remains the same. The development team is still working on resolving the root cause, which seems to be that the user that is created after the initial request is not shared to the cache of all servers fast enough.
When subsequent requests are sent, the loadbalancer might route it to a server where this user is not yet properly set up.
Hi,
Is this company newly created?
In the past when this has been encountered, it has usually been due to an caching issue.
The company has been around for several months at least, perhaps over a year. But I was only granted access to it yesterday.
Hi,
Alright, could you please make sure that you have both the "Financials Administrator" & "Financials User" roles applied for this company?
Please let us know and we'll have a look at it.
Thank you.
Yes, both roles were already assigned yesterday.
Just now I tried the same request again, and now it's successful!
So perhaps it's a temporary problem the first 6-12 hours after:
Ok, we have some cases in the backlog regarding cache issue in these scenarios.
Good to hear it's resolved, please let us know if it happens again.
We might have encountered this again.
Moving one client away from the old token authentication and starting to use the new authentication has generated this error.
Posting with the old token works (ipp-company-id and so on), but with the new authentication fails for the same request.
We have seen cache-errors today so it might be related to that ... for now, we have to use the old token, and then try to switch to the new auth tomorrow again to see if it starts to work
Tested today with tenant auth, and today it worked. Looks like a cache issue with the credentials?
Hi,
Yes, that's what we've seen as well. When it comes to the new authentication it's due to that the user that is created when sending the first request has not yet been cached on all servers.
The development team is looking in to this.
Any updates here?
Moving clients to tenant auth, and then move it back again, wait about 24 hours and then back to tenant, seems to be the only workaround for now, and thats not very user friendly
Hi!
The development team has found a solution that is planned to be released 21/11, version 9.71
Any updates? This is still an issue
This still fails the same way as it did before the latest update.
Copyright © 2022 Visma.com. All rights reserved.