People, People, People

Experts' Corner
1

While no expert, I’ll take a shot at what I have experienced:

User
To access E10, you need a User login. This is the primary point for authentication. The User record controls authorization through Security Groups or toggles on this record. A User entry is required for Requisition Entry.

User Name must be unique in addition to the UserID.

Tables: Erp.UserFile and Ice.UserFile. The Ice version is where the real action is (encrypted password, etc.) and the Erp version is a copy of used for non-security information.

Employee
This represents a person who can report time and/or expenses. It doesn’t require a matching User entry when using MES but it is mandatory when using the Time/Expense Apps. It may also be associated with a Supplier entry in order to pay expenses back to the employee.

Employee Records hold labor rates and there can be multiple rates based on role for Projects. There is also Department/Shiift/Resource and G/L Controls to help with labor/burden reporting.

Employee name and ID must both be unique.
Tables: EmpBasic

Work Force
A Work Force record is used for workflow within E10. It appears that Epicor initially developed workflow within the Sales cycle as the Workflow record is actually stored in the Erp.SalesRep table. As Workflow moved to other areas (ECO, Case, Time and Expense approval, …) the Workflow entry included non-sales people. Each Work Force entry has a role and task approval can be restricted to members of a particular role. In order to act as a Work Force entry, the logged-in user must be an Authorized User of that Work Force record.

In the role of Sales Person, the Sales Territory uses Work Force entries to provide limited visibility to customers and their activity if required.

Work Force ID and Name must be unique.
Tables: SalesRep

Buyer
This represents someone who is authorized to create purchase orders or approve purchase orders. Like Work Force, it requires Authorized User(s) for someone to act in the role of that buyer record.

Buyer Name and ID must be unique.
Tables; Erp.PurAgent, Erp.PurAuth

Person
This record is used by Global Alert and Shop Warnings to associate with them with particular Alert Groups. These do not have to be Epicor Users.
Tables: Erp.Person

Person/Contact
This record represents a person - anywhere. Think of it as a CRM person entry - as Epicor does. However, not only does it link to Customers and Ship-Tos but also to Suppliers, Users, Work Force, Buyers, Employees and Payroll. This contains GDPR sensitive data.

(This is a normalized table within Epicor!)

Tables: Erp.Percon, Erp.PerConLnk

I’m sure I’ve missed some things but this gets the conversation started…

Mark W.

19 Likes
2

Well done @Mark_Wonsil!

And I’ll add that the Person Contact record can be used repeatedly for various reasons or linked to more than one of the other entities mentioned. This function allows for ‘employees’ to become customers (and vice versa), or ‘agents’ to be associated with more than one customer, etc., etc…

And in turn, this data model makes writing queries sort of a nightmare at first until you get your head around you data set and how your folks have added all of these entities.

2 Likes
3

Great explanation @Mark_Wonsil!

I’d 2nd what you said about writing queries a nightmare at first @MikeGross. We went live on E10 last month so we’re very familiar with the nightmare that is Person/Contacts. It makes sense once you understand how it all works. But is very confusing to new Epicor users.

2 Likes
4

A couple of thoughts on contacts.

  1. Make a contact specific to the relationship you have with the contact. Example: customer contacts. if a contact leaves one of your customer and starts working for another of your customer. Make a new contact, don’t update the existing contact with the new information. Why? records gets a bit messy and you lose the history you had in case entry with the first customer when you transfer the contact.

  2. Don’t delete a contact - even if ERP allows you to delete a contact don’t do it. In case entry - you won’t know who called in after you delete the contact.

  3. Understand how the sync fields in contacts affects your record in person/contact

4 Likes
5

Awesome post, Mark. I learned several things from it.

Since I was just looking at this, I’ll add that Buyers are the table Erp.PurAgent and their users are Erp.PurAuth.

Of course they are also cross-referenced in part class, part plant, PO header, etc.

2 Likes
6

Good catch. I’ve updated the main post. Also, I added where ID and Name must both be unique within the tables.

Thanks!

Mark W.

7

Can’t find my complete notes from our operational consultant but in his Ukranian Engineer’s way he said

A user is a social security number meaning a unique individual

A person is a function falling into one of these:
Customer contact
Ship to contact
Supplier contact
Supplier PP contact
Employee (Labor and/or Payroll participant)
Work force (sales team member)
Buyer

A ‘Person’ may be linked to none, one or more than one user to fulfill their function.

3 Likes
8

a cool use case for Person:

if you have automatic emails, whether they’re controlled by breaking/routing records or hard-coded in a bpm, it. can be risky to allow the people who manage the people, to also edit the recipient lists in whatever form.

Use an alert group for each report, and then let managers or power users use Person to assign people to the report. In your report, use a query to get the email addresses from the people who’ve been set to receive the alert group.

1 Like
9

I missed this years ago … But Buyer (as Epicor uses it) isn’t a “someone”, but rather a group. Authorized users are added to it.

2 Likes
10

Unless you work at a public company. SOX controls do not allow for anyone to be an Authorized User of an approver. Which really hurts small companies.

11

It’s still a group. SOX just requires it to be a group with no more than one member.
:wink:

12

When I had to do SOX audits, it was OK to have back ups in case the primary approvers were out due to illness, vacation, etc. The spirit of the law was to make sure there were compensating controls in those cases. This could include a formal request from a non-conflicting manager and lots of communication and open disclosure to document the non-standard event.

1 Like
13

Your auditor was nicer than mine :joy:

14

We were so lucky to have finance and IT managers who knew the law well and would request our auditors (internal) to pay to be educated by our staff. :rofl:

15

I use the “secret” type data tags on Person to tag people who can disposition material in a
custom quality hold application we use.

ref → “secret” data tags @timshuwy :heart:

1 Like