By using this website, you agree to our Terms of Use (click here)
Hello you guys.
The scenario I have is the following:
ย ย ย ย 1] I have a Sales Order Generic Inquiry.
ย ย ย ย 2] I have a dashboard with a bar-graph widget that shows total invoiced sales order values per month. This widget shows the information for all branches in ourย ย ย ย ย ย ย ย ย ย ย ย ย company.
Management wants me to add the functionality to the widget/dashboard to only show invoiced sales orders that belong to the current branch the user is logged into.
I have done plenty of research but the best option I saw was to use AccessInfo.BranchID = SOrder.BranchID. Sadly see that this is a virtual table and not accessible via GI parameters nor conditions or filters( Invalid Object error) Of course this table does not exist in the DB.
I see that the current branchID variable is kept in the session cookie though but am not sure how to use this value in my GI.
Is there a way I can show/extract data for the GI for the current user logged in branch only please?
We use Acumatica 2017 R2.
Kindest regards,
Christopherย ย
Good morning everyone.
ย
So; this cost a lot of learning; but in the end I ditched trying to use AccessInfo to try and filter data per logged in users company/branch.
ย
What I did in the end was to leave the single generic inquiry and I added shared filters for the multiple branches.
I then created a single Dashboard and added multiple bar graph widgets for each company and I set "Allow users to Personalize" to true.
The effect:
All users from different companies could view the single dashboard - Acumatica of course automatically restricts data not belonging to the users so the users not belonging to certain companies/branches saw empty widgets.
Because I set "Allow users to Personalize" to true; the users could delete/remove the "empty" widgets from their dashboard and all looks gret.
Even if the user from one branch tries to change the widget shared GI filter the system will still not populate date for that user because the user belongs to the incorrect role.
We linked our branches to roles.
ย
Kind regards,
Christopher
Great solution for your case.
Has anyone actually been successful with the original request- get the current user to be recognized as a condition in the GI?
We have some GI's that would use distinct parameters based on user.
Example: A Sales Generic inquiry.
For performance purposes, when the typical user runs the GI you would want to limit the start date to a fairly recent date and let the user extend if needed. But if the GI is being accessed via Odata automatically, you might want all sales from beginning of time.
I can't think of a way to achieve that without the GI knowing the User ID.
The only special parameter variables that I am aware of are @Me, @MyGroups, @MyWorktree, and @Today.
But it would be nice if we had a @Company and @Branch variable (or something like that).
Both @Company and @Branch would be needed because in 2018 R2 there aren't just Branches, but both Companies and Branches.
Company/Branch that you have selected doesn't mean that you're "logged in" to a Company or Branch. It's just a default value for any new transactions. This was made more clear in 2018 R2 by moving the selector to the top next to the Business Date which is also just a default value for any new transactions.

But even though the Company/Branch selector and the Business Date are default values for new transactions, the @Today variable respects the Business Date, so it would make sense to me that we could also have @Company and @Branch variables which respect the Company/Branch selector.
I created an idea for this in case you want to vote on it:
https://feedback.acumatica.com/ideas/ACU-I-1784
Hey guys.
ย
This is how you do it (Thank you Sergey) - a bit more work but you get tonnes of extra functionality:
https://asiablog.acumatica.com/2018/11/dashboards-based-on-real-screen.html
Kind regards,
Christopher
Thanks for the link Christopher! I have been getting braver and braver to start learning how to write code for situations like this. You definitely get a lot more control with writing BQL. It's all of the C# that you have to wrap around the BQL that still scares me ๐
