We are currently experiencing an issue with adding Posts to Discussion Topics. You can click a REPLY button to reply to an existing Post, but you can't click ADD REPLY to add a Post to the bottom of a Topic. This is being investigated.
Company Tree and Approval Maps
As I was setting up approval mapping for PO Approvals for one of our clients, I came across something that was a bit interesting and isn't currently clearly documented in the Acumatica Help Wikis, so I thought I would share it with you.
On my approval map, I had set up the items needing approval to go to specific workgroups for approval, since this requires less maintenance over time as employees come and go. But what I noticed is that employees in higher work groups in the company tree could also approve these items. However, if you explicitly name an employee and remove the workgroup, only the named employee can approve the document. This may or may not be an issue for some companies, but more of something to be aware of.
Two ways of looking at it:
1. Setting it up to go to a workgroup allows a more senior employee to approve something on a more junior employee's behalf while they are on vacation
2. If you have high level workgroup on your tree to accommodate delegation of authority / vacation coverage, this group may include employees who shouldn't be approving specific types of transactions but would have access to do so if a lower workgroup is assigned the approval (rather than a specific employee).
Thanks for pointing this out Megan. I agree, this can be unexpected behavior. Personally, I try to avoid the Company Tree altogether and just assign individual employees to approval maps if possible to keep things simple. I also don't like that there is only one Company Tree because sometimes there is the need for a different structure for a different approval map.
But, I also agree with your point that it's easier to maintain using Workgroups.
Have you tried the Employee from Document or Employees by Filter options on the Approval Maps (EP205015) screen? I haven't, but they look like promising alternatives to Workgroups.
Tim, you can also think of the company tree in Acumatica as a copse of trees rather than a single organism. Kind of like a bunch of Aspen. If you see an Aspen grove, many people don't realize that it is all one organism and they are all interconnected underground.
In the Acumatica tree, I believe you can have many trunks from which to build. Each trunk can serve its own purpose. By building a new trunk from the base level, you can avoid hierarchical inheritance when you don't want it. Just be sure to not add people to the very base layer of the tree.
As with most things in life, this is a double-edged sword and should be used in moderation. Otherwise, you can find yourself with a lot of independent units that have to be maintained.
Definitely a needed feature is a vacation approval mapping feature. We struggle with getting employees to do their approvals and if they knew that if they just didn't do their jobs someone else would do it for them... Trust me when I say - they will just not do their jobs. More of an organizational problem, but having a designated "on vacation" checkbox or something would be nice :).
Thinking outloud, but you could have an attribute on an employee that said "on vacation" and then under an approval step always check that attribute? Would automatically push it to the next level. Although wouldn't be helpful for a workgroup. Not sure ha.
If you see an Aspen grove, many people don't realize that it is all one organism and they are all interconnected underground.
In the Acumatica tree, I believe you can have many trunks from which to build. Each trunk can serve its own purpose.
Brilliant analogy @shawn-slavin and brilliant insight. I hadn't thought about the ability to use one Company Tree for multiple top level independent nodes. Great idea!
Did you have troubles using workgroup/owner with multiple levels? The situation I'm dealing with right now is 4 levels of authority required and the top 2 are switching:
System is triggering approvals in this sequence 1 --> 2 --> 4 --> 3.
However, when I assign the Employee ID vs. using the workgroup/owner on the approver field the sequence is triggered in the correct order 1 --> 2 --> 3 --> 4.
Sounds like you might have found a bug Mike 🙁
I have a puzzle to solve around the same topic.
I am implementing a site who will use projects and each expense is coded to a project with a project manager being responsible for approving all project expenses. After a certain limit, the second, third and fourth level approval will be sought. There is about 70 approvers.
I set up approvals with using Employee from Document. In other words, the Approval map looks at the PO line Project and picks up Project Manager from the Project.
For second-level approval, the first level approvers "Reports To" is picked as an approver. And so on.
The above works really well and it would be very easy to maintain going forward as the client will only need to update the Project Manager field on Projects.
Now, the issue I have is with the approvers going on leave. The approving on behalf of somebody only seems to work via Workgroups. In the above case, I don't have a workgroup assigned to PO as it's not possible "to pick up" a workgroup from a document/employee. Workgroups would need to be hardcoded into the approval map, which in the case of 60 approvers would mean a lot of hard-codings and far from ideal.
Does anybody have any ideas on how to get around the above issue on needing to pick up approvers from documents, but also handling people going on leave?