You’re offline. This is a read only version of the page.
5
hi,
Is there any setup for the Azure Active Directory Application?
The problem is that during the web service call the UTC time zone is taken as a base, but we would need to have a user-specific time zone. In the case of default BC users there is such setup but in the case of OAuth users what?
Thank you so much! If my assistance is needed, the MS engineer can come to me.
Hello,
I meant a support ticket to Microsoft support via partnercenter.microsoft.com. This helps us to track it correctly. \\
Thank you.
Hi Marco,
Thanks.
Do you mean open issue on the github.com/.../issues or other areas? Could you pinpoint me to the correct direction?
br,
Dmitry
Hi,
Makes sense what you say. Please raise the scenario to Microsoft so we can ask the product group to reevaluate the initial fix / scenario. The supporter that will assist may ask you for a repro in standard CRONUS Company, but you can also refer to this community thread as I think the repro is clear.
Thank you.
Hi Marco,
Thank you for the fast reply.
I'm referring to the BC20.
If I understand correctly the procedure GetCurrentDateTimeInUserTimeZone gets the time zone base on the user settings, but in the case of OAuth there is no real user in the user's table, so there are no user personalization settings and there are no time zones for the Azure Application Registrations user, so the time will be UTC always.
Or the Time Zone setup is present somewhere for the Azure Active Directory Application user?
Hello,
As far as I know, the issue has already been resolved in version 19 and later releases. What release are you operating from? If it is version 18x, then the issue happens. You can add following code to the api pages if you are on an older build:
trigger OnInit()
var
TypeHelper: Codeunit "Type Helper";
begin
WorkDate := DT2Date(TypeHelper.GetCurrentDateTimeInUserTimeZone());
end;
This will also resolve the issue. If that is not possible due to Sana's restrictions, then consider an upgrade via them.
Thank you.
Hello Marco,
Understood, but unfortunately passing the date\time via API is not the case, the ISV's (Sana) webservice strictly works in the UTC date tame timezone + the API contract doesn't consider passing additional date\time, which means ERP has to solve that task.
In the case of Basic authentication(which is going to be deprecated) is quite easy to bind to the user's time zone and calculate the correct date or time. But now with the OAuth our customers (especially NZ\AU) experience issues with wrong data on the documents.
We would really appreciate if you guys force the issue and provide us a solution.
BR,
Dmitry
Hello,
Understood, thank you. Here are some mitigations steps.
When a Sales Header record is inserted Posting Date is checked, if it is empty then WorkDate is assigned to Posting Date. Since web services session always runs on the UTC timezone, Posting Date is left as UTC. We have created a repair item to address the issue in future as there can be many ways to address it (in NST or in App).
You can fill the postingDate field in the JSON body when creating an invoice from API, then the issue can be considered as mitigated.
Thank you.
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
#1
André Arnaud de Cal...
291,253
Super User 2024 Season 2
#2
Martin Dráb
230,188
Most Valuable Professional
#3
nmaenpaa
101,156
Share
Report
All responses (
Answers (