Set up:
- Use the usual working schedule from 8:00 to 12:00 and 13:00 to 17:00.
- Set the OS and user TZ to Australia/Sidney TZ (restart your browser)
- Create a BOM with 3 work orders, taking 1, 2 and 3 minutes (you can
use the 'Assemble Furniture' routing)
- Create a MO using the previously created BOM, e.g. for '[FURN001]
Computer Desk'
Case 1: Plan to start the next day at 08:00, e.g. 2017-06-08
The result is amazing. The system probably hit a flaw in the space-time
continuum, which can only be explained with M-theory:
- WO1 is planned from 2017-06-08 08:00:00 to 2017-06-07 08:01:00
- WO2 is planned from 2017-06-07 08:01:00 to 2017-06-06 08:02:00
- WO3 is planned from 2017-06-06 08:02:00 to 2017-06-05 08:03:00
Case 2: Plan to start the next day at 11:00, e.g. 2017-06-08
Once again, the result is literally a piece of art:
- WO1 is planned from 2017-06-08 11:00:00 to 2017-06-08 08:01:00
- WO2 is planned from 2017-06-08 08:01:00 to 2017-06-07 08:02:00
- WO3 is planned from 2017-06-07 08:02:00 to 2017-06-06 08:03:00
To solve the problem, a first commit is made in MRP to force the end
date to be larger than the start date. That hides the issue, but it
doesn't solve it.
To prevent the system to hit the 88 mph and go back in time, we force a
'hard limit' to prevent any selection of intervals starting before the
requested start time.
opw-745905
Nicolas Martinelli
34736b0a6c