Labor Posting

Well…it is what it is…the employee rate is how the basic system works. It was designed that way and has been functioning since version 5.0 that I know of. If you have fairly accurate production standards, labor back flushing might be something to consider, but if and only if your production standards are good.


Thanks Mike - not very happy

Thank you Claudia. We may need a customization.

Can I ask a business question? Why does the labor rate for your guys use case need to change for different resources? From what I understand, that’s what burden rate is designed to do. Why do you need it on the labor rate?

Burden is manufacturing overhead. Labor should not be a part of the burden rate. I want to use separate rates to determine what my labor and overhead variances are. If I combine the rates, I won’t be able to see the separate issues. If the system has reporting that helps me identify labor variances, then I am open to that. But, we don’t know enough yet. EPICOR consulting has not provided any options. We’ll see on Monday when the consultant arrives.

But why doesn’t the labor rate follow the employee? I don’t understand how that rate can change because the are working in a different area.

Our machines have a crew of 2 or more. We have to blend the rates. We have different rates for operators and helpers. In addition, we have built in overtime. This blend is optimal for us. Employees sometimes move around but that is difficult to track. So, the machine rate for labor works best for us.

The resource grp rate is what is used when you do a cost roll on a mfg part. So basically, it’s an estimated labor cost of manufacturing the part.
For example:

*if the resource grp rate = $10/hr and it takes 2 hrs estimated in the method master (routing) file to finish the job, then the part’s labor portion is costed as $20 ($10/hr x 2 hrs)

  • When you go and manufacture that part and the employee reports time against that part on a job, then the employee rate is used to calculate actual labor cost (Employee Rate x Actual hrs = Actual labor cost). So, if the employee rate was $11/hr and it took 2.50 hrs, then the actual labor cost would be = $27.50 ($11/hr x 2.50 hrs). The difference between the actual and estimated cost would be labor variance.

So you aren’t having employees actually clock into a job, you are essentially “clocking in a machine” instead of an employee. Does that sound correct?

Would it be a better solution for you to make “employees” in the system that are actually machines, and use those ID’s for employees to clock into the job? Then the machine could have the labor rate you want.

(FWIW, I don’t agree with this method, I would rather have each employee clock into the operation so I know what each is doing, but I do know that can be difficult to impossible to accomplish because of the amount of transactions required)

Ok - I am with you. Next question - when setting up the employee in emp maint, do I need to use a gl control / type to capture the applied labor account?

Do not quote me on this (I’m not great with GL accounts), but I think there is a hierarchy somewhere for what GL account it’s applied to. We do not have employees with a GL control, so that means you don’t need them, as long as they are all going to the same place. I think you set up a control if you need something other than what you have set up as the default. In your case, it might not be a bad idea, but it all depends on what accounting wants to see…

I am the Controller - I want to see detail… Just have to figure out how.

I agree with Brandon - no GL controls on my employee records either.

However, I disagree with generic employee logins - you lose the auditability that way - if you care to have it. If not, then generic employee logins with the proper labor rate would work just fine without any special/custom work being done.

Remember, You can have more than one person clocking into an operation at the same time. So if you have a crew of 2 they can both be clocked into it. This would capture the labor rate for both people.

I would have to do some testing to what that does with the burden in that case. The system is set up for 1 person to run multiple machines, or just run 1 machine at a time (there is a labor=burden setting in the resource group). Basically this setting is for if you have an employee clock into 3 different operations at the same time, is he running 3 machines at once? (you would accrue the actual time for burden, so all 3 operations would have as much burden as his labor. 3 ops for 1 hour = 1 hour labor and 3 hours burden, one for each op) or is he doing them one at at time? (this would be where you set burden = labor, 1 hour labor = 1 hour burden split between the 3 ops).

So if you really want to know how many labor hours are on an operation, if each employee clocks into the operation, it will capture that employees labor at the rate set up by the employee record.

I got it now. It’s different than our plan, but, we will adjust. Thanks everyone!

1 Like

We don’t have GL control setup for employees but if your employees do work indirect labor and report those hrs, then i believe, you need to setup GL control for Indirect labor.

When you enter labor entry > select “Indirect” as labor type > enter hrs > then select the “Indirect labor code” under Indirect drop-drop (GL control linked).

The way we have setup is that each employee reports all his/her time on a labor sheet for the day which is entered in Epicor via Time and Expense entry. The time includes direct labor (setup and Run hrs) and also Indirect labor for a total of say 8 hrs/day. All the direct labor goes against the jobs and all the indirect labor is put against what ever indirect labor they performed, each one linked to a Indirect labor code which has GL control linked.

We have multiple indirect codes setup up (ex. maintenance, housekeeping, rework, etc).

In our setup my understanding is that the direct labor GL transactions come from the expense code (and associated GL Control) that is assigned to each employee. Indirect labor, as Al said, comes from the GL control attached to each indirect labor code.

I haven’t tested this but my assumption would be that any GL control assigned to the employee would take precedence followed by any assigned to the expense code and finally any at the department level. We don’t have any assigned at the employee or department level.

When you say direct labor GL transactions do you mean WIP labor? Just want to be sure I understand the issue.

Correct. Within that GL control you can set Applied Labor, Applied Overhead, COS Burden and COS Labor.

Got it…those accounts are only found in the product group and the inventory/Wip/cos GL control codes.