Inventory WIP. STK-MTL shows as today. Labor shows as tomorrow

Is this just a deal with before end of the month or is there a way to stop Epicor travelling into the future?

Need more info. Epicor labor records shouldn’t be in the future. PayrollDate sometimes can be in the future if you have someone clocking way outside their set shift, but other than that the labor trans is the labor trans.

It seems to be applying by payroll date.

Oh sure I see, you mentioned wip so I assumed jobs but yeah it might post the labor head in GL by payroll date. When did they clock in vs what is their shift set for. My guess is they are way outside their shift so it bumped them to the next day.

I have been testing myself so have been very diligent on clocking in & out. It’s been happening for the past 3 days. This is in TEST and may have been happening for a while.

The only things I can think of are factors to stop the posting and having them manually adjusted towards the last couple of working days of the month. Just seems odd Epicor is setting future date.

Other than a few bucks in the wrong month what other issues is it causing? Are you using the payroll module?

Will there not be an issue for month end if we’re posting to the next month?

Prevent future transactions in general or prevent activities in a future fiscal period?

Earliest apply date prevents transactions in a prior date.
To prevent future transactions, you can control this in the fiscal calendar. Either create the periods and mark them closed until you need them, or do not create period in advance.

Hi Brian,

This is the only issue where future dates will cause a problem. If we have the month closed will the labor posting just hit current month?

We are not using the Payroll module

@Matt_Belshaw as long as the earliest apply dates are set properly then nothing will post in previous periods.
They could however go to future ones. I recently found some years of 4444 and 5039 in our data just waiting to be captured.

It looks like the shift is set from 12AM to 12AM or not set so everything is tomorrow. Ours are close to what our three shifts are, but I think something like 6AM to 9PM for all would be fine for all employees.

Hi Greg. The

They could however go to future ones

bit is what finance are worried about. Should they be? Or do we just look to prevent by running BAQs showing future dates for Labor and correctly manually?

set the shifts to not 12AM - 12AM and test. I believe that will clear the issue.

1 Like

Looks like that was it Greg. Thanks alot for this:

It’s up to them if they want to be worried about it or not. It all washes out in the end. Unless you have super strict budgets, commissions, or earnings targets it’s nothing I would get wound up about personally.

Hi Joshua.

Greg Payne provided a resolution to this.

Thanks

Matt

Understood but i’m just answering your additional question about finances concern. This won’t be the first or last time you have to put your finance hat on. Welcome to the wonderful world of ERP where you are not just IT you are also Finance :slight_smile:.

Also to be fair I said it was the shift settings in my first post ;). Setting 12a-12a is a solution but if you ever wanted to report on shift data you’ve lost flexibility of using those values and having to hard code shift info into your reports. Ideally you want to set the shifts correctly and make sure that folks are clocking in and out at the correct times for their shifts.

1 Like

Thanks Joshua. Noted on shift reporting item. We are moving from a legacy system that does 10% of what Epicor will do for us. Once the dust has settled I am sure we will review items like shift reporting.

Thanks