The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
I hate it when my senior partner gets an idea in her head, like changing the presentation/logic for an application without understanding how much plumbing and re-wiring will be required to implement. (while at the same time remaining largely unchanged for a previous customer)
BTW, it's a totally weird situation with a new customer where they have employees working different shifts of non-contiguous hours. I've now spent almost a week on a solution that apparently doesn't fit with the vision. Oh well, time to break out the jackhammer!
even 24 hour shops, supermarkets and food outlets have this.
OP perhaps hard coded too much "logic" or/an assumptions of what/when shifts are.
Doing a similar project for a manufacturing company, in particular they want to capture real project man hours, sure they very concisely told me what the typical scenario is including a very precise definition of what a "shift" was (need to to capture OT) - there were no exceptions. 3 months on there's never been a single job that fit the standard scenario, and yes, what they define as a shift now has variants (heck, what they define as a "man hour" has variants.)
There's nothing to hard code, but regardless there nothing that should be hard coded.
For sure shifts have nothing to do with time of day, duration, break intervals... and even less to do with any other shifts parameters even in the same role.
I don't understand the OP's issue - regardless situation if "shifts" overlap or not (which seems to be his "problem") should have been irrelevant from the very start. Sounds like a very poor implementation, and I will go as far to say there's really no excuse for that.
Signature ready for installation. Please Reboot now.
When systems collide... We have one system that tracks time/costs.
Another that generates work. Load the work, get the costs.
LONG AFTER Implementation, they mention parallel efforts?
Oh, so we have a MACHINE that cuts stuff up. We load it, cut it, move to the next load.
Oh, but that next load was processed by hand to PREP it for loading. Oh, so we need to create a VIRTUAL Work Center that tracks that effort, because it happens in parallel. A design that makes sense, in the end, but WHERE was the original business analyst that approved the first version that we coded to? Oh, they had NEVER TALKED to a single actual worker. The ONLY watched the first shift, while starting, that does not have this opportunity, so it looked like 2 steps on one machine.
Don't get me started about the COST of going to lunch when they forgot to hit the right button on the machine! LOL
I think you need to talk with your so called senior partner and put the
idea on paper first and tackle all the problems that may arise implementing
the new requirement.Then document the design change (including UI and BL)
in a new design document and do a review and both of you agree that this
is what is needed to be done to achieve the solution to your new customer.
Then you could design your objects, classes and functional business logic
as a separate layer and then implement test cases for your processing function
to ensure that all the outcomes and test are covered. You need to implement functions that
take into consideration the duty,shift,24hrs....then I'm sure you knew all
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
employees working different shifts of non-contiguous hours.
I don't see why the computer should care. WHere I work, now, aside from those who earn overtime (ad-hoc hours), there are about six different schedules that overlap to varying degrees - they never abut.
Two cases really exist:
Totally random starting times for shifts.
Specific sets of hours scattered throughout the day.
The first requires values to be set as their schedule
The second can use a lookup table (in database) for scheduling sanctioned sets of hours.
One could add further complexity:
* Random hours vary continuously. Just get a time-clock and read-back the data.
* Fixed hours change daily (lookup schedule for employees on days 0-6), but are constant with respect to the day of the week.
So - if any sort of regular scheduling exists, create hours list in table and assign them for each day of the week, reference back to the worker. All of this, of course, will work fine for a standard office with a fixed schedule. Just hope you don't have to set up the schedule.
Programming is a good way to prove to yourself that everything you think you know about the universe is wrong. You think shifts are contiguous? Someone out there disagrees.
The company I work for tracks vehicles and as part of that we record the VIN of the vehicle. The program was originally written to require VINs be unique but then we ran into a set of vehicles that lie and always say their VIN is 00000. So we had to go and remove the requirement that VINs be unique.