Hello!
I have no idea who came up with this concept, but it would be swell if the production calendar exceptions weren’t handled via 24 checkboxes per day.
It is a nightmare to work with or report off this layout. Who thought that storing a date / time range with check-boxes was the best solution here?
Having an entry for each date / date time range would make things a LOT more palatable and a lot more useful to work with. Even for internal Epicor logic such as MRP
How would that be populated? You would have an infinitely large table if every date needed to be in the table wouldn’t you. How would you handle multiple time periods per day?
I don’t like how it works either, and I curious how a better solution would work.
Only add entries for the dates that have exceptions. So it wouldn’t have to be infinitely large. Like PartBin a record only exists if an exception exists. Multiple time periods per day is easy one entry per range. You’d have a max of 24 entries in a day… (Which would never happen realistically)
You’d have an entry of
10/10/2018 8:00 AM To 10/10/2018 10:00AM
another one
10/10/2018 3:00 PM to 10/10/2018 5:00 PM
etc…
right, but if you have every Friday afternoon off, you would need every Friday from here to eternity.
The check boxes make it so you can have everything on one row.
Today you can’t have all Fridays off either? Except manually creating the exception. What’s the difference? Or handle it at the whole Production Calendar level (remove fridays)
Just uncheck the boxes on the calendar. I must not be understanding what you are getting at. We have every Saturday and Sunday off, why not Friday?
Exceptions have their own table.
That’s different I’m talking about Exceptions (Holidays, Maintenance , DAys off) etc…
Now I see what you are talking about. I thought you were looking at the ProdCal table. I’ve only messed with a total day exception, not a range of time.
My guess is since the Check Boxes are the same as the ProdCal, someone thought it would be easier, since you have to do the conversion to relate it to the ProdCal table anyways.
Also, hours in actual time can be problematic if you day starts and ends across the midnight line. So they divorced actual time, to show work hours so your day can start at 8:00 and run 24 hours instead of starting at midnight.
Maybe however there are 128 checkboxes in ProdCal and 24 in ResCal the whole thing is odd. I still beleive this could be handled differently. For example even for the BIG ProdCal they could do Start Date with no end Date for “always off” days and have a frequency (weekyl, monthly etc like outlook does)
Checkboxes are a nightmare IMO.
The problem of re-curring date has been solved and it has been solved well by pretty much any calendar system out there… Outlook, Gmail, you name it. I don’t understand why re-invent the wheel with checkboxes.
Maybe the check boxes were first. There is a lot inherited from older versions.
Right, hence my request for improvement 
Right now I have a customer who wants to create a bunch of exceptions (easier) than going through and selecting check-boxes. With Date Ranges and recurrence etc… so I’m having to do that in a UD Table and the use BPMs and a lot of crazy logic to go update the right checkboxes.
With a little bit of design work this can be accomplished with 2 or 3 tables, an Event Table a recurring type of flag and an exception table. Its not too difficult and a lot more flexible.
Aka, Job security 
hehe common misconception, my job is not to stick around forever maintaining some monster customization. My goal is to solve the problem and get the customer to a point where they are stable and happy and hopefully they never have to call me again about that particular issue.
So if Epicor can fix this for me then that’s a LOT of code I can take out of circulation in the future.
So out of curiosity, how would a software that has so much legacy code to worry about go about making this change? Anyone who has any customization based on those confusing check boxes would have to revamp everything wouldn’t they? Is it just rip off the band-aid and prepare as best you can? Or is there an elegant way to roll this out?
Would you have to have duplicate functionality for a version or two to allow people to adjust? Syncing up the two different tables or something?
I just think this an interesting discussion.
Yeah absolutely there would have to be some bridge gap… And that’s how most break/change features are introduced.
Version 1 would be add the functionality but copy it to the existing solution (AKA what I’m writing, so any time an “event” is created, the right check-boxes are checked / unchecked etc as well as storing it in the new format)
Then on V2 or V3 you can transition it out. With plenty of warning and fanfare its not a trivial thing but very much doable.
