Hi all,
I am very new to Epicor (2 months of experience) and my company is looking to either update from current 10.2.500.32 to .40 or jump to 10.2.700 (latest version). Could someone give me some insight on the major changes/differences between .500 and .700? Trying to see if it’s worth our while to just go to either the latest 500 patch or update to .700! Thank you for any information.
Welcome Nick!
The most recent version of ERP is 2024.1. 10.2.700 is well into sustaining support. Why not move to the most recent? Especially since you don’t have to move to the browser right away.
Welcome to the party!
But 10.2.700 is NOT the latest version… it is almost 4 years out of date (released in October-ish 2020). the current version is 11.3.100, aka Kinetic 2024.1.
Correct, we plan on upgrading to Kinetic Q4 of next year. We currently have minor problems/errors at the moment we are hoping either .40 patch or .700 will resolve until we are prepared fully to do a complete upgrade. Just trying to get a high-level overview on differences between 500 & 700 or if it’s in our best interest to just update to the latest 500 patch since we plan on fully upgrading next year.
Probably the best way to find out the “major” new features would be to go onto EpicWeb and search for the “What’s New In [version number]” document… which will bring you to the powerpoint that Sales uses to brag on new features.
And to find out if a SPECIFIC issue you’re having has been resolved, go to Epicweb and search for the Release Notes for the version you’re thinking of upgrading to. If you’re currently on 10.2.500.32, go to the downloads area for 10.2.500.40 and download the Release Notes for it… then go to the download area for 10.2.700.whatever and download THOSE release notes. They’re very detailed.
Yes sir, have already been sifting through those. Problem is, because I’m so new, I have only encountered 2-3 “issues” and don’t have a wide field of view on what has happened previously as well as if they have been resolved or not. One for example is our hourly labor employee’s time clock in time for production jobs. We currently have company configuration to track idle time for when labor workers are clocked in but doing something other than production on a certain Job #. When they first clock in, in the morning using “indirect production” it will incorrectly time stamp their hours saying they clocked in at 12AM. Once they clock into a job #, it accurately time stamps stating 10:38-1:15pm. They will also be able to clock back to “Indirect Production” after a job and it will then accurately track their time stamp. It will always correctly track the total number of hours clocked in, but just not the accurate time stamp if they clock in using “indirect production” in the morning. This does not occur if they clock into a job first thing. I have figured out it’s due to the Calc idle time but haven’t found a solution yet and was told this feature was fixed in “later” versions.
The “Calc Idle Time” functionality only actually records a number of hours… not the time that those recorded hours took place. Their LaborHed record will record the daily clockin time… each employee with have a single LaborHed record (that records timeclock clockin and clockout) and multiple LaborDtl records (one for each job clocked into, and one that holds the Idle time.
This isn’t a bug, it’s a feature. It’s also a pain in the butt to figure out!
Makes sense, don’t want to pick your brain too much but what is the correct way to set this up and where is it located? Is it within Epicor or our something I need to change in our sql database? I have looked under employee, company config, company main. and time. Would like to have this set up properly so it doesn’t continue to occur. Thank you for your words of wisdom!
It’s in Company Configuration, under Modules > Production > MES
What does this mean? What, to you, would be “set up properly”?
Where employee time stamps are tracked accurately, instead of showing 12AM clock in time. Even if they are working using “indirect production” such as a receptionist, shop maintenance worker, etc who never clocks into a specific job # that is in production. Or an hourly employee who does work on production jobs but isn’t clocked into a specific job # in the morning when they first arrive. Is using “indirect production” the wrong way to have them clock in for this?
Epicor doesn’t work that way, and never has (at least since Vantage 5). If you want an actual timestamp then your employees will need to clock into either a Production or an Indirect activity.
What you’re saying is, I need to create an Indirect activity for users to clock into instead of just indirect production. For instance, the receptionist would clock into “office calls”, a shop employee would clock into “shop work”, etc. Essentially creating a job for them to clock into that is not a production job #.
It’s actually an Indirect Labor Code (not a job) and these codes can be set to hit specific GL accounts.
Alternatively, if you don’t want to track idle time for anyone else, you can just use the LaborHed record (that is automagically created on clock in) that has both the ClockIn and ClockOut times, and set their EmpID up with the appropriate GL control.
Typically, Payroll-type time recording utilizes the LaborHed table precisely for that reason (1 record per employee workday). Earned Hours and other production-related time recording utilizes the LaborDtl table (multiple records per employee per day).
If my memory is right, Epicor Functions were first introduced in 10.2.500 but they really started to make sense in 10.2.700.
IMHO, Epicor Functions is one of the (if not THE) best new feature in recent years. Just for this single reason, you should consider upgrading to 10.2.700.
As other said, upgrading to the latest version would be even better.
The clock in and clock out times are stored in the labor head table… the idle time is a calculation based on any time that they were not clocked into work… If you want to know when they clocked in/out of the system, look at Labor Header. the individual details in Labor Detail is typically accurate for start/stop of actual work.