v8.03.404B - Finite Global Scheduling of Overlapping Operations

Fred,

Material constraints is one of those 'great theory - near useless in real world (because of how it was implemented)' features. I would not ever use it. No ETA from my sources on when (if at all) they will get it working as I don't think it is a high priority issue relative to other critical problems to be resolved.

Yes: Minimize WIP is defined in the scheduling code - and absolutely does not work and should not be used. From what I'm told, don't count on it being usable even in v9. They totally blew it when coding.

While I've been officially told the use of the wrong date by calculate global scheduling order will be fixed in 8.03.5, a source I trust tells me not to count on it until v9.

Yes: Even when backward scheduling in 404, everything is forward scheduled. Another thing my source says won't be really fixed until v9.

That said, we are getting desired results using forward finite with the array of priorities previously described. The key to making it work is to lock a start date in once a planner determines it. Backward scheduled orders use the Req'd by date as hard fence 'from' date but all forward scheduled jobs try to start immediately (and that's why you get the screwed up results). We lock our start dates by having a zero cycle time/setup OP as our 1st OP which relates (in our process) to issuing the required materials for the jobs. Once the planner firms (default backward scheduled) unfirmed jobs to firmed, we have a job entry customization which automatically changes the sched code to a lowest priority forward sched code and also calculates a jobheader.date### ud field stored earliest start date which is calculated backwards from the required by date using the part's LT (in working days - taking into account weekends and holidays).

Job Entry/Scheduling is customized to detect the scheduling direction of the specific job (and use it) and also, if forward, use this ud field stored start date as the start date.

Once a job is initially firmed/engineered and scheduled, we have a server process running every 5 minutes that punches in joboper.setuppctcomplete = 1 on our 1st OP. This locks the start date as the global will not move an in process op schedule.

This combo of manipulations makes the global behave to the standards of a 1978 MRPII forward finite scheduling system with the additional benefits of prioritized scheduling code multipliers (so high - human planner assigned - prioritized jobs DO get '1st crack' at capacity over low priority jobs).

It is a total cludge but it works.

While it makes a nice sales pitch (to decision makers who have never done planning/finite-scheduling), Vantage blew it focussing the product to be a backwards sched model biased system. Backwards scheduling (and MRP based on actual as-scheduled job due dates and material requirement dates tied to actual as-scheduled material linked OP start dates) is a system designed to fail as MRP (a 'push' system) ends up driving planners (via messaging) to make the jobs later and later (stretching lead times - to your customers).

Foward finite with human planner set locked start dates (with prioritization to 'pull' the most critical jobs through resource available work queues) is where it is at (and a very "lean" paradigm that is easier to transition to kanban over time). It reduces lead time and increases customer service levels. Careful controls (not provided by vantage - but easily implemented via custom reports or trackers) to keep the WIP from going wild (cluttered up with low priority jobs that won't ever see activity until true customer demand requirements 'pull them' to a higher priority).


Re: My comment about it taking time for a major scheduling paradigm change to really impact actual schedules:

No one in the right mind (on the shop floor) is going to stand for for breaking time intensive CNC set ups on in-process OPs (even if they were mis-scheduled - and even if someone higher in the management chain dictates it be done). Those OPs are going to be completed before the 'get out of the way' and start allowing your new paradigm schedules to take effect. Skilled set up resources are always true limiters and few companies can break every set up in the building in a single day and res-et up 'the right' jobs. There just isn't enough man-power (or valium! :))

Indeed, the global WON'T 'break' these in process OPs. If your OPs typically take 1-5 days to complete and you have a heavily loaded shop, expect it to take 4-8 weeks before your new scheduling paradigm fully takes over the shop schedules - as the old junk must 1st be physically processed and cleared out. The 'clearing out' part can be about 80% accomplished in a week or so - but until all is done, the schedules won't settled down into your new mode.

Rob







--- On Thu, 5/15/08, fredcarnot <fredcarnot@...> wrote:

From: fredcarnot <fredcarnot@...>
Subject: [Vantage] Re: v8.03.404B - Finite Global Scheduling of Overlapping Operations
To: vantage@yahoogroups.com
Date: Thursday, May 15, 2008, 10:27 AM






Thanks again Rob

I have had to turn most of my material constraints off, we had lead
times set on some components and even when they are all received onto
the job the scheduler still see's the lead time as a constraint and
will not schedule the job earlier.

We too have set our priority codes similar to yours, so the priority
over rides the date.

I am running tests on an off line copy so should be OK, although I am
not sure I understand you comments ref working on the live system,
grateful for a bit more explination if poss please.

For the time being, (until we get a working patch from EPICOR) I plan
to stick to backward scheduling all jobs, although it does not do
what it says on the tin, it gives us a usable result.

We are not as far as I can tell using minimize WIP, the only place I
can see this set is on the priority codes and I have this unticked.

Thanks again
Tim

--- In vantage@yahoogroups .com, Robert Brown <robertb_versa@ ...>
wrote:
>
> Are any of your materials Constrained? (Best not to use except in
VERY small doses - and then with care to return a material to not
Constrained when it isn't needed.)
>
> How much of a spread are you using in your priority multipliers
defined in your scheduling codes? We use 16 levels ranging from 1
(lowest priority) to 5000 (highest) in an non linear style increasing
series (1, 2, 4, ...2500, 5000).
>
> That garauntees the highest assigned sched priority jobs (no matter
how early or late) will definitely be in the early group of jobs to
get 1st crack at capacity during a global resched.
>
> If you are experimenting on a live system with lots of in process
OPs (particularly long running ones) you need to give a change in
scheduling paradigm time to clear out the old WIP as in-process OPs
(even if they were mis-scheduled and are low priority) won't
be 'broken' and pushed out. That could take days to weeks. (In our
environment, about 3 weeks for things to clear out, settle down and
stabilize.)
>
> Also: I hope you are not using the 'minimize WIP' scheduling option
as whoever conceived and implemented it should be unemployed. Using
it results in the opposite of what you would expect (and VERY much
what you describe). Late, critical jobs get later. Not critical early
jobs get earlier.
>
> Hope the info helps. Sounds like you have your hands full.
>
> Rob
>
> --- On Wed, 5/14/08, fredcarnot <fredcarnot@ ...> wrote:
>
> From: fredcarnot <fredcarnot@ ...>
> Subject: [Vantage] Re: v8.03.404B - Finite Global Scheduling of
Overlapping Operations
> To: vantage@yahoogroups .com
> Date: Wednesday, May 14, 2008, 6:57 AM
>
>
>
>
>
>
> Thanks Rob
> We are running a mix of forward and backward scheduling codes, but
> even my very highest priority forward scheduled job does not start
as
> early as possible, it appears to calculate a start date into the
> future and then delivers late. I have checked all material and PO
> constraints. If I finite or infinitly schedule it from Job Entry it
> schedules OK.
>
> I have since reset all codes to forward schedule, the results were
> very poor, again high priority jobs were getting start dates into
the
> future and delivering late.
>
> However, when I set them all to backward schedule I got a much
better
> schedule, but the jobs were not backward scheduling, they all
appear
> to have forward scheduled, all starting as early as possible.
>
> Thanks again
>
> --- In vantage@yahoogroups .com, Robert Brown <robertb_versa@ ...>
> wrote:
> >
> > It sounds like you are loaded to peak capacity or, more likely,
> (since having load and capacity perfectly match is about as likely
as
> balancing a pin on end) you are overloaded.
> >
> > In overloaded environments, backward scheduling rarely works in
> real life.
> >
> > Having a mix of backward and forward scheduled jobs only makes
the
> scheduling results worse as, backward sched jobs with sched codes
> assigned high scheduling priority multipliers attempt to be
scheduled
> as close to just in time as possible, where as forward scheduled
jobs
> with high priority sched code multipliers attempt to be scheduled
as
> soon as possible.
> >
> > This ends up creating (systemically) impossible conditions and
> desired results to fulfill and (mentally) for your planners, a
> difficult conceptual image of how to get the most important jobs
done
> 1st.
> >
> > Vantages has a natural bias toward scheduling backward sched jobs
> over equal priority forward sched jobs. It also has the weakest
> support for forward scheduling I've ever seen as you cannot specify
> a 'no earlier than' start date fence - and all jobs set as forward
> try to schedule to start immediately.
> >
> > Pick your poison and stick with one scheduling direction. If you
> shop truly is as overloaded as it sounds, go with forward and use
> different sched codes with a wide range of priority multipliers to
> truly enforce your real world priorities.
> >
> > You mention the Calculate Scheduling Order program still
> miscalculates the days early/late. If memory serves correctly, it
is
> calculating calendar days early/late - since 'working days' can
(and
> often does) vary from resource to resource.
> >
> > That may be the source of the deceptive results, or (perhaps in
> 404B), they 'fixed' something (and actually further broke the
> application) . On 404A, the days/early late do seem to be correctly
> calculated wants you do the import of ReqBy date into Due Date
prior
> to program run.
> >
> > Rob Brown
> >
> > --- On Fri, 5/9/08, fredcarnot <fredcarnot@ ...> wrote:
> >
> > From: fredcarnot <fredcarnot@ ...>
> > Subject: [Vantage] Re: v8.03.404B - Finite Global Scheduling of
> Overlapping Operations
> > To: vantage@yahoogroups .com
> > Date: Friday, May 9, 2008, 9:24 AM
> >
> >
> >
> >
> >
> >
> > We have also managed to fix the date issue by replacing the due
> date
> > with the required date before running the set order process,
> although
> > it still calculate the days late wrong.
> >
> > Our real problem in 404B is that Global scheduling gives very
> strange
> > results.
> >
> > Some forward scheduled jobs get a start date after their Rquired
> date
> > and therefore schedule late, I am not sure where it gets the
start
> > date from, but if we then schedule the Job from Job entry it
> > schedules fine.
> >
> > We also have backward shceduled jobs that it schedules to finish
> many
> > days early, but again if we schedule them from Job entry every
> thing
> > is fine.
> >
> > EPICOR UK are struggling with this at presnt, but any help most
> > welcome.
> >
> > --- In vantage@yahoogroups .com, "Monte Tomerlin" <monte@> wrote:
> > >
> > > Rob - Thanks for your help. I called Epicor and SCR48782 is the
> > > resolution for my problem. It is supposed to be fixed in 405
and
> it
> > > should be out sometime in May - Thx again - Monte Tomerlin
> > >
> > > --- In vantage@yahoogroups .com, Robert Brown <robertb_versa@ >
> > > wrote:
> > > >
> > > > We are on 404 (not yet upgraded to 404B) and I've not seen
the
> > > behavior you described when I've TRIED to create crazy
conditions
> > to
> > > determine the Globals tolerance for them.
> > > >
> > > > Your conditions (overlapping OPs either start2start or
> > > finish2finish) aren't crazy (and I expect to use them as we
> > > increasingly go Lean & set up cells in our Machine shop). I
> wonder
> > if
> > > this is a new bug introduced in 404B.
> > > >
> > > > We are FORWARD scheduling our complex finite resource machine
> > shop
> > > (several hundred resources grouped under about 70 resource
> groups -
> > > all to create a capacity model equivalent to what we were able
to
> > do
> > > with 70 work centers in our legacy system) - so this may also
> > explain
> > > why we haven't encountered what you describe in our 'make it
> break'
> > > testing.
> > > >
> > > > One thing we did learn is that Calculate Global Scheduling
> Order
> > > has a SERIOUS bug in it (reported in Feb 2008 and under SCR
48782
> > and
> > > still no ETA on resolution):
> > > >
> > > > When Calculate Global Scheduling Order does it passes to
> > determine
> > > the relative days early/late (and thus the date-based sequence
> > BEFORE
> > > multiplying by each Job's Scheduling Code Multiplier) IT IS
USING
> > THE
> > > WRONG DATE.
> > > >
> > > > It is incorrectly using the previous as-scheduled Due Date of
> > each
> > > Job instead of the fixed target Req'd By Date.
> > > >
> > > > As a result, you could literally run the 3 step global
process
> 10
> > > consecutive times in a row (with no changed/cancelled/
additional
> > Jobs
> > > and no activity progress reported) and you would get 10
different
> > > schedules (each progressively worse than the last in actually
> > > fulfilling you Req'd By Date needs).
> > > >
> > > > We gave up waiting for Epicor to correct it. It is a simple
> > > remapping of a single fields in the dataview used by Calculate
> > Global
> > > Scheduling Order that should take about 2 minutes to recode and
> > > recompile (and it is approaching 3 months with no action).
> > > >
> > > > Our 'fix' is to recurring schedule a temporary DTS based
import
> > of
> > > all Jobs' Req'd By Dates into the JobHead.DueDate field - and
> then
> > > proceeed with the multi-step global process & MRP (all done at
> > night).
> > > >
> > > > ALSO: Testing we did on 403B showed the Global choking on
Jobs
> > > where Finish to Start defined consecutive Ops were activity
> > reported
> > > as having had parallel activity occur. (A
> desirable 'opportunistic'
> > > occurrence when proceding OP resources become available sooner
> than
> > > the Resource model expects - desireable as it increase
> utilization
> > > AND gets the job done sooner - so we can fulfill customers
order
> > > sooner than expected.)
> > > >
> > > > Re-testing this on 404 showed it had been fixed (before we
ever
> > got
> > > around to reporting it to Epicor) and no longer resulted in
these
> > > Jobs/OPs being partially/fully left unscheduled.
> > > >
> > > > Perhaps the 'fix' (that was a benefit to us) caused the
broken
> > > behavior you describe.
> > > >
> > > > Rob Brown
> > > >
> > > >
> > > >
> > > > --- On Wed, 4/23/08, Monte Tomerlin <monte@> wrote:
> > > >
> > > > From: Monte Tomerlin <monte@>
> > > > Subject: [Vantage] v8.03.404B - Finite Global Scheduling of
> > > Overlapping Operations
> > > > To: vantage@yahoogroups .com
> > > > Date: Wednesday, April 23, 2008, 4:39 PM
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > We are getting some very unexplicable results after running
> > Global
> > > > Scheduling. Job scheduling order seemed to work well until we
> > > > implemented Operation Overlap (using both Start-to-Start and
> > Finish-
> > > to-
> > > > Finish) in our Job-MoMs. Since then there are a whole host of
> > > problems:
> > > > Job/Operation launch sequencing, subsequent operations
> scheduled
> > to
> > > > start and to finish before earlier operations are to begin,
> > > overloading
> > > > of resources group well beyond their capacity, et al.
Launching
> > Job
> > > > Priority only made things worse. If anyone is successfully
> using
> > > Global
> > > > Scheduling with Overlapped Operations and Job Priority,
please
> > > contact
> > > > me. Thanks
> > > >
> > > > Monte Tomerlin
> > > > VP Finance
> > > > Accratronics Seals Corp
> > > > Burbank, CA
> > > > 818-237-4948
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > ____________ _________ _________ _________ _________ _________ _
> > > ____________ __
> > > > Be a better friend, newshound, and
> > > > know-it-all with Yahoo! Mobile. Try it now.
> > > http://mobile. yahoo.com/ ;_ylt=Ahu06i62sR 8HDtDypao8Wcj9tA cJ
> > > >
> > >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> ____________ _________ _________ _________ _________ _________ _
> ____________ __
> > Be a better friend, newshound, and
> > know-it-all with Yahoo! Mobile. Try it now.
> http://mobile. yahoo.com/ ;_ylt=Ahu06i62sR 8HDtDypao8Wcj9tA cJ
> >
>
We are getting some very unexplicable results after running Global
Scheduling. Job scheduling order seemed to work well until we
implemented Operation Overlap (using both Start-to-Start and Finish-to-
Finish) in our Job-MoMs. Since then there are a whole host of problems:
Job/Operation launch sequencing, subsequent operations scheduled to
start and to finish before earlier operations are to begin, overloading
of resources group well beyond their capacity, et al. Launching Job
Priority only made things worse. If anyone is successfully using Global
Scheduling with Overlapped Operations and Job Priority, please contact
me. Thanks

Monte Tomerlin
VP Finance
Accratronics Seals Corp
Burbank, CA
818-237-4948
We are on 404 (not yet upgraded to 404B) and I've not seen the behavior you described when I've TRIED to create crazy conditions to determine the Globals tolerance for them.

Your conditions (overlapping OPs either start2start or finish2finish) aren't crazy (and I expect to use them as we increasingly go Lean & set up cells in our Machine shop). I wonder if this is a new bug introduced in 404B.

We are FORWARD scheduling our complex finite resource machine shop (several hundred resources grouped under about 70 resource groups - all to create a capacity model equivalent to what we were able to do with 70 work centers in our legacy system) - so this may also explain why we haven't encountered what you describe in our 'make it break' testing.

One thing we did learn is that Calculate Global Scheduling Order has a SERIOUS bug in it (reported in Feb 2008 and under SCR 48782 and still no ETA on resolution):

When Calculate Global Scheduling Order does it passes to determine the relative days early/late (and thus the date-based sequence BEFORE multiplying by each Job's Scheduling Code Multiplier) IT IS USING THE WRONG DATE.

It is incorrectly using the previous as-scheduled Due Date of each Job instead of the fixed target Req'd By Date.

As a result, you could literally run the 3 step global process 10 consecutive times in a row (with no changed/cancelled/additional Jobs and no activity progress reported) and you would get 10 different schedules (each progressively worse than the last in actually fulfilling you Req'd By Date needs).

We gave up waiting for Epicor to correct it. It is a simple remapping of a single fields in the dataview used by Calculate Global Scheduling Order that should take about 2 minutes to recode and recompile (and it is approaching 3 months with no action).

Our 'fix' is to recurring schedule a temporary DTS based import of all Jobs' Req'd By Dates into the JobHead.DueDate field - and then proceeed with the multi-step global process & MRP (all done at night).

ALSO: Testing we did on 403B showed the Global choking on Jobs where Finish to Start defined consecutive Ops were activity reported as having had parallel activity occur. (A desirable 'opportunistic' occurrence when proceding OP resources become available sooner than the Resource model expects - desireable as it increase utilization AND gets the job done sooner - so we can fulfill customers order sooner than expected.)

Re-testing this on 404 showed it had been fixed (before we ever got around to reporting it to Epicor) and no longer resulted in these Jobs/OPs being partially/fully left unscheduled.

Perhaps the 'fix' (that was a benefit to us) caused the broken behavior you describe.

Rob Brown



--- On Wed, 4/23/08, Monte Tomerlin <monte@...> wrote:

From: Monte Tomerlin <monte@...>
Subject: [Vantage] v8.03.404B - Finite Global Scheduling of Overlapping Operations
To: vantage@yahoogroups.com
Date: Wednesday, April 23, 2008, 4:39 PM






We are getting some very unexplicable results after running Global
Scheduling. Job scheduling order seemed to work well until we
implemented Operation Overlap (using both Start-to-Start and Finish-to-
Finish) in our Job-MoMs. Since then there are a whole host of problems:
Job/Operation launch sequencing, subsequent operations scheduled to
start and to finish before earlier operations are to begin, overloading
of resources group well beyond their capacity, et al. Launching Job
Priority only made things worse. If anyone is successfully using Global
Scheduling with Overlapped Operations and Job Priority, please contact
me. Thanks

Monte Tomerlin
VP Finance
Accratronics Seals Corp
Burbank, CA
818-237-4948
















____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Rob - Thanks for your help. I called Epicor and SCR48782 is the
resolution for my problem. It is supposed to be fixed in 405 and it
should be out sometime in May - Thx again - Monte Tomerlin

--- In vantage@yahoogroups.com, Robert Brown <robertb_versa@...>
wrote:
>
> We are on 404 (not yet upgraded to 404B) and I've not seen the
behavior you described when I've TRIED to create crazy conditions to
determine the Globals tolerance for them.
>
> Your conditions (overlapping OPs either start2start or
finish2finish) aren't crazy (and I expect to use them as we
increasingly go Lean & set up cells in our Machine shop). I wonder if
this is a new bug introduced in 404B.
>
> We are FORWARD scheduling our complex finite resource machine shop
(several hundred resources grouped under about 70 resource groups -
all to create a capacity model equivalent to what we were able to do
with 70 work centers in our legacy system) - so this may also explain
why we haven't encountered what you describe in our 'make it break'
testing.
>
> One thing we did learn is that Calculate Global Scheduling Order
has a SERIOUS bug in it (reported in Feb 2008 and under SCR 48782 and
still no ETA on resolution):
>
> When Calculate Global Scheduling Order does it passes to determine
the relative days early/late (and thus the date-based sequence BEFORE
multiplying by each Job's Scheduling Code Multiplier) IT IS USING THE
WRONG DATE.
>
> It is incorrectly using the previous as-scheduled Due Date of each
Job instead of the fixed target Req'd By Date.
>
> As a result, you could literally run the 3 step global process 10
consecutive times in a row (with no changed/cancelled/additional Jobs
and no activity progress reported) and you would get 10 different
schedules (each progressively worse than the last in actually
fulfilling you Req'd By Date needs).
>
> We gave up waiting for Epicor to correct it. It is a simple
remapping of a single fields in the dataview used by Calculate Global
Scheduling Order that should take about 2 minutes to recode and
recompile (and it is approaching 3 months with no action).
>
> Our 'fix' is to recurring schedule a temporary DTS based import of
all Jobs' Req'd By Dates into the JobHead.DueDate field - and then
proceeed with the multi-step global process & MRP (all done at night).
>
> ALSO: Testing we did on 403B showed the Global choking on Jobs
where Finish to Start defined consecutive Ops were activity reported
as having had parallel activity occur. (A desirable 'opportunistic'
occurrence when proceding OP resources become available sooner than
the Resource model expects - desireable as it increase utilization
AND gets the job done sooner - so we can fulfill customers order
sooner than expected.)
>
> Re-testing this on 404 showed it had been fixed (before we ever got
around to reporting it to Epicor) and no longer resulted in these
Jobs/OPs being partially/fully left unscheduled.
>
> Perhaps the 'fix' (that was a benefit to us) caused the broken
behavior you describe.
>
> Rob Brown
>
>
>
> --- On Wed, 4/23/08, Monte Tomerlin <monte@...> wrote:
>
> From: Monte Tomerlin <monte@...>
> Subject: [Vantage] v8.03.404B - Finite Global Scheduling of
Overlapping Operations
> To: vantage@yahoogroups.com
> Date: Wednesday, April 23, 2008, 4:39 PM
>
>
>
>
>
>
> We are getting some very unexplicable results after running Global
> Scheduling. Job scheduling order seemed to work well until we
> implemented Operation Overlap (using both Start-to-Start and Finish-
to-
> Finish) in our Job-MoMs. Since then there are a whole host of
problems:
> Job/Operation launch sequencing, subsequent operations scheduled to
> start and to finish before earlier operations are to begin,
overloading
> of resources group well beyond their capacity, et al. Launching Job
> Priority only made things worse. If anyone is successfully using
Global
> Scheduling with Overlapped Operations and Job Priority, please
contact
> me. Thanks
>
> Monte Tomerlin
> VP Finance
> Accratronics Seals Corp
> Burbank, CA
> 818-237-4948
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
______________________________________________________________________
______________
> Be a better friend, newshound, and
> know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
>
Glad to help Monte.
I'm not 'holding my breath' re: the May 405 release.
Until then, I suggest you try the batch import/update of Req'd Date into the Due Date fields prior to Calculate Global Scheduling Order (as described below).
It works like a charm.
Rob

--- On Fri, 4/25/08, Monte Tomerlin <monte@...> wrote:
From: Monte Tomerlin <monte@...>
Subject: [Vantage] Re: v8.03.404B - Finite Global Scheduling of Overlapping Operations
To: vantage@yahoogroups.com
Date: Friday, April 25, 2008, 2:41 PM











Rob - Thanks for your help. I called Epicor and SCR48782 is the

resolution for my problem. It is supposed to be fixed in 405 and it

should be out sometime in May - Thx again - Monte Tomerlin



--- In vantage@yahoogroups .com, Robert Brown <robertb_versa@ ...>

wrote:

>

> We are on 404 (not yet upgraded to 404B) and I've not seen the

behavior you described when I've TRIED to create crazy conditions to

determine the Globals tolerance for them.

>

> Your conditions (overlapping OPs either start2start or

finish2finish) aren't crazy (and I expect to use them as we

increasingly go Lean & set up cells in our Machine shop). I wonder if

this is a new bug introduced in 404B.

>

> We are FORWARD scheduling our complex finite resource machine shop

(several hundred resources grouped under about 70 resource groups -

all to create a capacity model equivalent to what we were able to do

with 70 work centers in our legacy system) - so this may also explain

why we haven't encountered what you describe in our 'make it break'

testing.

>

> One thing we did learn is that Calculate Global Scheduling Order

has a SERIOUS bug in it (reported in Feb 2008 and under SCR 48782 and

still no ETA on resolution):

>

> When Calculate Global Scheduling Order does it passes to determine

the relative days early/late (and thus the date-based sequence BEFORE

multiplying by each Job's Scheduling Code Multiplier) IT IS USING THE

WRONG DATE.

>

> It is incorrectly using the previous as-scheduled Due Date of each

Job instead of the fixed target Req'd By Date.

>

> As a result, you could literally run the 3 step global process 10

consecutive times in a row (with no changed/cancelled/ additional Jobs

and no activity progress reported) and you would get 10 different

schedules (each progressively worse than the last in actually

fulfilling you Req'd By Date needs).

>

> We gave up waiting for Epicor to correct it. It is a simple

remapping of a single fields in the dataview used by Calculate Global

Scheduling Order that should take about 2 minutes to recode and

recompile (and it is approaching 3 months with no action).

>

> Our 'fix' is to recurring schedule a temporary DTS based import of

all Jobs' Req'd By Dates into the JobHead.DueDate field - and then

proceeed with the multi-step global process & MRP (all done at night).

>

> ALSO: Testing we did on 403B showed the Global choking on Jobs

where Finish to Start defined consecutive Ops were activity reported

as having had parallel activity occur. (A desirable 'opportunistic'

occurrence when proceding OP resources become available sooner than

the Resource model expects - desireable as it increase utilization

AND gets the job done sooner - so we can fulfill customers order

sooner than expected.)

>

> Re-testing this on 404 showed it had been fixed (before we ever got

around to reporting it to Epicor) and no longer resulted in these

Jobs/OPs being partially/fully left unscheduled.

>

> Perhaps the 'fix' (that was a benefit to us) caused the broken

behavior you describe.

>

> Rob Brown

>

>

>

> --- On Wed, 4/23/08, Monte Tomerlin <monte@...> wrote:

>

> From: Monte Tomerlin <monte@...>

> Subject: [Vantage] v8.03.404B - Finite Global Scheduling of

Overlapping Operations

> To: vantage@yahoogroups .com

> Date: Wednesday, April 23, 2008, 4:39 PM

>

>

>

>

>

>

> We are getting some very unexplicable results after running Global

> Scheduling. Job scheduling order seemed to work well until we

> implemented Operation Overlap (using both Start-to-Start and Finish-

to-

> Finish) in our Job-MoMs. Since then there are a whole host of

problems:

> Job/Operation launch sequencing, subsequent operations scheduled to

> start and to finish before earlier operations are to begin,

overloading

> of resources group well beyond their capacity, et al. Launching Job

> Priority only made things worse. If anyone is successfully using

Global

> Scheduling with Overlapped Operations and Job Priority, please

contact

> me. Thanks

>

> Monte Tomerlin

> VP Finance

> Accratronics Seals Corp

> Burbank, CA

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

____________ _________ _________ _________ _________ _________ _

____________ __

> Be a better friend, newshound, and

> know-it-all with Yahoo! Mobile. Try it now.

http://mobile. yahoo.com/ ;_ylt=Ahu06i62sR 8HDtDypao8Wcj9tA cJ

>



























____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
We have also managed to fix the date issue by replacing the due date
with the required date before running the set order process, although
it still calculate the days late wrong.

Our real problem in 404B is that Global scheduling gives very strange
results.

Some forward scheduled jobs get a start date after their Rquired date
and therefore schedule late, I am not sure where it gets the start
date from, but if we then schedule the Job from Job entry it
schedules fine.

We also have backward shceduled jobs that it schedules to finish many
days early, but again if we schedule them from Job entry every thing
is fine.

EPICOR UK are struggling with this at presnt, but any help most
welcome.

--- In vantage@yahoogroups.com, "Monte Tomerlin" <monte@...> wrote:
>
> Rob - Thanks for your help. I called Epicor and SCR48782 is the
> resolution for my problem. It is supposed to be fixed in 405 and it
> should be out sometime in May - Thx again - Monte Tomerlin
>
> --- In vantage@yahoogroups.com, Robert Brown <robertb_versa@>
> wrote:
> >
> > We are on 404 (not yet upgraded to 404B) and I've not seen the
> behavior you described when I've TRIED to create crazy conditions
to
> determine the Globals tolerance for them.
> >
> > Your conditions (overlapping OPs either start2start or
> finish2finish) aren't crazy (and I expect to use them as we
> increasingly go Lean & set up cells in our Machine shop). I wonder
if
> this is a new bug introduced in 404B.
> >
> > We are FORWARD scheduling our complex finite resource machine
shop
> (several hundred resources grouped under about 70 resource groups -
> all to create a capacity model equivalent to what we were able to
do
> with 70 work centers in our legacy system) - so this may also
explain
> why we haven't encountered what you describe in our 'make it break'
> testing.
> >
> > One thing we did learn is that Calculate Global Scheduling Order
> has a SERIOUS bug in it (reported in Feb 2008 and under SCR 48782
and
> still no ETA on resolution):
> >
> > When Calculate Global Scheduling Order does it passes to
determine
> the relative days early/late (and thus the date-based sequence
BEFORE
> multiplying by each Job's Scheduling Code Multiplier) IT IS USING
THE
> WRONG DATE.
> >
> > It is incorrectly using the previous as-scheduled Due Date of
each
> Job instead of the fixed target Req'd By Date.
> >
> > As a result, you could literally run the 3 step global process 10
> consecutive times in a row (with no changed/cancelled/additional
Jobs
> and no activity progress reported) and you would get 10 different
> schedules (each progressively worse than the last in actually
> fulfilling you Req'd By Date needs).
> >
> > We gave up waiting for Epicor to correct it. It is a simple
> remapping of a single fields in the dataview used by Calculate
Global
> Scheduling Order that should take about 2 minutes to recode and
> recompile (and it is approaching 3 months with no action).
> >
> > Our 'fix' is to recurring schedule a temporary DTS based import
of
> all Jobs' Req'd By Dates into the JobHead.DueDate field - and then
> proceeed with the multi-step global process & MRP (all done at
night).
> >
> > ALSO: Testing we did on 403B showed the Global choking on Jobs
> where Finish to Start defined consecutive Ops were activity
reported
> as having had parallel activity occur. (A desirable 'opportunistic'
> occurrence when proceding OP resources become available sooner than
> the Resource model expects - desireable as it increase utilization
> AND gets the job done sooner - so we can fulfill customers order
> sooner than expected.)
> >
> > Re-testing this on 404 showed it had been fixed (before we ever
got
> around to reporting it to Epicor) and no longer resulted in these
> Jobs/OPs being partially/fully left unscheduled.
> >
> > Perhaps the 'fix' (that was a benefit to us) caused the broken
> behavior you describe.
> >
> > Rob Brown
> >
> >
> >
> > --- On Wed, 4/23/08, Monte Tomerlin <monte@> wrote:
> >
> > From: Monte Tomerlin <monte@>
> > Subject: [Vantage] v8.03.404B - Finite Global Scheduling of
> Overlapping Operations
> > To: vantage@yahoogroups.com
> > Date: Wednesday, April 23, 2008, 4:39 PM
> >
> >
> >
> >
> >
> >
> > We are getting some very unexplicable results after running
Global
> > Scheduling. Job scheduling order seemed to work well until we
> > implemented Operation Overlap (using both Start-to-Start and
Finish-
> to-
> > Finish) in our Job-MoMs. Since then there are a whole host of
> problems:
> > Job/Operation launch sequencing, subsequent operations scheduled
to
> > start and to finish before earlier operations are to begin,
> overloading
> > of resources group well beyond their capacity, et al. Launching
Job
> > Priority only made things worse. If anyone is successfully using
> Global
> > Scheduling with Overlapped Operations and Job Priority, please
> contact
> > me. Thanks
> >
> > Monte Tomerlin
> > VP Finance
> > Accratronics Seals Corp
> > Burbank, CA
> > 818-237-4948
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
______________________________________________________________________
> ______________
> > Be a better friend, newshound, and
> > know-it-all with Yahoo! Mobile. Try it now.
> http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
> >
>
It sounds like you are loaded to peak capacity or, more likely, (since having load and capacity perfectly match is about as likely as balancing a pin on end) you are overloaded.

In overloaded environments, backward scheduling rarely works in real life.

Having a mix of backward and forward scheduled jobs only makes the scheduling results worse as, backward sched jobs with sched codes assigned high scheduling priority multipliers attempt to be scheduled as close to just in time as possible, where as forward scheduled jobs with high priority sched code multipliers attempt to be scheduled as soon as possible.

This ends up creating (systemically) impossible conditions and desired results to fulfill and (mentally) for your planners, a difficult conceptual image of how to get the most important jobs done 1st.

Vantages has a natural bias toward scheduling backward sched jobs over equal priority forward sched jobs. It also has the weakest support for forward scheduling I've ever seen as you cannot specify a 'no earlier than' start date fence - and all jobs set as forward try to schedule to start immediately.

Pick your poison and stick with one scheduling direction. If you shop truly is as overloaded as it sounds, go with forward and use different sched codes with a wide range of priority multipliers to truly enforce your real world priorities.

You mention the Calculate Scheduling Order program still miscalculates the days early/late. If memory serves correctly, it is calculating calendar days early/late - since 'working days' can (and often does) vary from resource to resource.

That may be the source of the deceptive results, or (perhaps in 404B), they 'fixed' something (and actually further broke the application). On 404A, the days/early late do seem to be correctly calculated wants you do the import of ReqBy date into Due Date prior to program run.

Rob Brown

--- On Fri, 5/9/08, fredcarnot <fredcarnot@...> wrote:

From: fredcarnot <fredcarnot@...>
Subject: [Vantage] Re: v8.03.404B - Finite Global Scheduling of Overlapping Operations
To: vantage@yahoogroups.com
Date: Friday, May 9, 2008, 9:24 AM






We have also managed to fix the date issue by replacing the due date
with the required date before running the set order process, although
it still calculate the days late wrong.

Our real problem in 404B is that Global scheduling gives very strange
results.

Some forward scheduled jobs get a start date after their Rquired date
and therefore schedule late, I am not sure where it gets the start
date from, but if we then schedule the Job from Job entry it
schedules fine.

We also have backward shceduled jobs that it schedules to finish many
days early, but again if we schedule them from Job entry every thing
is fine.

EPICOR UK are struggling with this at presnt, but any help most
welcome.

--- In vantage@yahoogroups .com, "Monte Tomerlin" <monte@...> wrote:
>
> Rob - Thanks for your help. I called Epicor and SCR48782 is the
> resolution for my problem. It is supposed to be fixed in 405 and it
> should be out sometime in May - Thx again - Monte Tomerlin
>
> --- In vantage@yahoogroups .com, Robert Brown <robertb_versa@ >
> wrote:
> >
> > We are on 404 (not yet upgraded to 404B) and I've not seen the
> behavior you described when I've TRIED to create crazy conditions
to
> determine the Globals tolerance for them.
> >
> > Your conditions (overlapping OPs either start2start or
> finish2finish) aren't crazy (and I expect to use them as we
> increasingly go Lean & set up cells in our Machine shop). I wonder
if
> this is a new bug introduced in 404B.
> >
> > We are FORWARD scheduling our complex finite resource machine
shop
> (several hundred resources grouped under about 70 resource groups -
> all to create a capacity model equivalent to what we were able to
do
> with 70 work centers in our legacy system) - so this may also
explain
> why we haven't encountered what you describe in our 'make it break'
> testing.
> >
> > One thing we did learn is that Calculate Global Scheduling Order
> has a SERIOUS bug in it (reported in Feb 2008 and under SCR 48782
and
> still no ETA on resolution):
> >
> > When Calculate Global Scheduling Order does it passes to
determine
> the relative days early/late (and thus the date-based sequence
BEFORE
> multiplying by each Job's Scheduling Code Multiplier) IT IS USING
THE
> WRONG DATE.
> >
> > It is incorrectly using the previous as-scheduled Due Date of
each
> Job instead of the fixed target Req'd By Date.
> >
> > As a result, you could literally run the 3 step global process 10
> consecutive times in a row (with no changed/cancelled/ additional
Jobs
> and no activity progress reported) and you would get 10 different
> schedules (each progressively worse than the last in actually
> fulfilling you Req'd By Date needs).
> >
> > We gave up waiting for Epicor to correct it. It is a simple
> remapping of a single fields in the dataview used by Calculate
Global
> Scheduling Order that should take about 2 minutes to recode and
> recompile (and it is approaching 3 months with no action).
> >
> > Our 'fix' is to recurring schedule a temporary DTS based import
of
> all Jobs' Req'd By Dates into the JobHead.DueDate field - and then
> proceeed with the multi-step global process & MRP (all done at
night).
> >
> > ALSO: Testing we did on 403B showed the Global choking on Jobs
> where Finish to Start defined consecutive Ops were activity
reported
> as having had parallel activity occur. (A desirable 'opportunistic'
> occurrence when proceding OP resources become available sooner than
> the Resource model expects - desireable as it increase utilization
> AND gets the job done sooner - so we can fulfill customers order
> sooner than expected.)
> >
> > Re-testing this on 404 showed it had been fixed (before we ever
got
> around to reporting it to Epicor) and no longer resulted in these
> Jobs/OPs being partially/fully left unscheduled.
> >
> > Perhaps the 'fix' (that was a benefit to us) caused the broken
> behavior you describe.
> >
> > Rob Brown
> >
> >
> >
> > --- On Wed, 4/23/08, Monte Tomerlin <monte@> wrote:
> >
> > From: Monte Tomerlin <monte@>
> > Subject: [Vantage] v8.03.404B - Finite Global Scheduling of
> Overlapping Operations
> > To: vantage@yahoogroups .com
> > Date: Wednesday, April 23, 2008, 4:39 PM
> >
> >
> >
> >
> >
> >
> > We are getting some very unexplicable results after running
Global
> > Scheduling. Job scheduling order seemed to work well until we
> > implemented Operation Overlap (using both Start-to-Start and
Finish-
> to-
> > Finish) in our Job-MoMs. Since then there are a whole host of
> problems:
> > Job/Operation launch sequencing, subsequent operations scheduled
to
> > start and to finish before earlier operations are to begin,
> overloading
> > of resources group well beyond their capacity, et al. Launching
Job
> > Priority only made things worse. If anyone is successfully using
> Global
> > Scheduling with Overlapped Operations and Job Priority, please
> contact
> > me. Thanks
> >
> > Monte Tomerlin
> > VP Finance
> > Accratronics Seals Corp
> > Burbank, CA
> > 818-237-4948
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
____________ _________ _________ _________ _________ _________ _
> ____________ __
> > Be a better friend, newshound, and
> > know-it-all with Yahoo! Mobile. Try it now.
> http://mobile. yahoo.com/ ;_ylt=Ahu06i62sR 8HDtDypao8Wcj9tA cJ
> >
>
















____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Thanks Rob
We are running a mix of forward and backward scheduling codes, but
even my very highest priority forward scheduled job does not start as
early as possible, it appears to calculate a start date into the
future and then delivers late. I have checked all material and PO
constraints. If I finite or infinitly schedule it from Job Entry it
schedules OK.

I have since reset all codes to forward schedule, the results were
very poor, again high priority jobs were getting start dates into the
future and delivering late.

However, when I set them all to backward schedule I got a much better
schedule, but the jobs were not backward scheduling, they all appear
to have forward scheduled, all starting as early as possible.

Thanks again

--- In vantage@yahoogroups.com, Robert Brown <robertb_versa@...>
wrote:
>
> It sounds like you are loaded to peak capacity or, more likely,
(since having load and capacity perfectly match is about as likely as
balancing a pin on end) you are overloaded.
>
> In overloaded environments, backward scheduling rarely works in
real life.
>
> Having a mix of backward and forward scheduled jobs only makes the
scheduling results worse as, backward sched jobs with sched codes
assigned high scheduling priority multipliers attempt to be scheduled
as close to just in time as possible, where as forward scheduled jobs
with high priority sched code multipliers attempt to be scheduled as
soon as possible.
>
> This ends up creating (systemically) impossible conditions and
desired results to fulfill and (mentally) for your planners, a
difficult conceptual image of how to get the most important jobs done
1st.
>
> Vantages has a natural bias toward scheduling backward sched jobs
over equal priority forward sched jobs. It also has the weakest
support for forward scheduling I've ever seen as you cannot specify
a 'no earlier than' start date fence - and all jobs set as forward
try to schedule to start immediately.
>
> Pick your poison and stick with one scheduling direction. If you
shop truly is as overloaded as it sounds, go with forward and use
different sched codes with a wide range of priority multipliers to
truly enforce your real world priorities.
>
> You mention the Calculate Scheduling Order program still
miscalculates the days early/late. If memory serves correctly, it is
calculating calendar days early/late - since 'working days' can (and
often does) vary from resource to resource.
>
> That may be the source of the deceptive results, or (perhaps in
404B), they 'fixed' something (and actually further broke the
application). On 404A, the days/early late do seem to be correctly
calculated wants you do the import of ReqBy date into Due Date prior
to program run.
>
> Rob Brown
>
> --- On Fri, 5/9/08, fredcarnot <fredcarnot@...> wrote:
>
> From: fredcarnot <fredcarnot@...>
> Subject: [Vantage] Re: v8.03.404B - Finite Global Scheduling of
Overlapping Operations
> To: vantage@yahoogroups.com
> Date: Friday, May 9, 2008, 9:24 AM
>
>
>
>
>
>
> We have also managed to fix the date issue by replacing the due
date
> with the required date before running the set order process,
although
> it still calculate the days late wrong.
>
> Our real problem in 404B is that Global scheduling gives very
strange
> results.
>
> Some forward scheduled jobs get a start date after their Rquired
date
> and therefore schedule late, I am not sure where it gets the start
> date from, but if we then schedule the Job from Job entry it
> schedules fine.
>
> We also have backward shceduled jobs that it schedules to finish
many
> days early, but again if we schedule them from Job entry every
thing
> is fine.
>
> EPICOR UK are struggling with this at presnt, but any help most
> welcome.
>
> --- In vantage@yahoogroups .com, "Monte Tomerlin" <monte@> wrote:
> >
> > Rob - Thanks for your help. I called Epicor and SCR48782 is the
> > resolution for my problem. It is supposed to be fixed in 405 and
it
> > should be out sometime in May - Thx again - Monte Tomerlin
> >
> > --- In vantage@yahoogroups .com, Robert Brown <robertb_versa@ >
> > wrote:
> > >
> > > We are on 404 (not yet upgraded to 404B) and I've not seen the
> > behavior you described when I've TRIED to create crazy conditions
> to
> > determine the Globals tolerance for them.
> > >
> > > Your conditions (overlapping OPs either start2start or
> > finish2finish) aren't crazy (and I expect to use them as we
> > increasingly go Lean & set up cells in our Machine shop). I
wonder
> if
> > this is a new bug introduced in 404B.
> > >
> > > We are FORWARD scheduling our complex finite resource machine
> shop
> > (several hundred resources grouped under about 70 resource
groups -
> > all to create a capacity model equivalent to what we were able to
> do
> > with 70 work centers in our legacy system) - so this may also
> explain
> > why we haven't encountered what you describe in our 'make it
break'
> > testing.
> > >
> > > One thing we did learn is that Calculate Global Scheduling
Order
> > has a SERIOUS bug in it (reported in Feb 2008 and under SCR 48782
> and
> > still no ETA on resolution):
> > >
> > > When Calculate Global Scheduling Order does it passes to
> determine
> > the relative days early/late (and thus the date-based sequence
> BEFORE
> > multiplying by each Job's Scheduling Code Multiplier) IT IS USING
> THE
> > WRONG DATE.
> > >
> > > It is incorrectly using the previous as-scheduled Due Date of
> each
> > Job instead of the fixed target Req'd By Date.
> > >
> > > As a result, you could literally run the 3 step global process
10
> > consecutive times in a row (with no changed/cancelled/ additional
> Jobs
> > and no activity progress reported) and you would get 10 different
> > schedules (each progressively worse than the last in actually
> > fulfilling you Req'd By Date needs).
> > >
> > > We gave up waiting for Epicor to correct it. It is a simple
> > remapping of a single fields in the dataview used by Calculate
> Global
> > Scheduling Order that should take about 2 minutes to recode and
> > recompile (and it is approaching 3 months with no action).
> > >
> > > Our 'fix' is to recurring schedule a temporary DTS based import
> of
> > all Jobs' Req'd By Dates into the JobHead.DueDate field - and
then
> > proceeed with the multi-step global process & MRP (all done at
> night).
> > >
> > > ALSO: Testing we did on 403B showed the Global choking on Jobs
> > where Finish to Start defined consecutive Ops were activity
> reported
> > as having had parallel activity occur. (A
desirable 'opportunistic'
> > occurrence when proceding OP resources become available sooner
than
> > the Resource model expects - desireable as it increase
utilization
> > AND gets the job done sooner - so we can fulfill customers order
> > sooner than expected.)
> > >
> > > Re-testing this on 404 showed it had been fixed (before we ever
> got
> > around to reporting it to Epicor) and no longer resulted in these
> > Jobs/OPs being partially/fully left unscheduled.
> > >
> > > Perhaps the 'fix' (that was a benefit to us) caused the broken
> > behavior you describe.
> > >
> > > Rob Brown
> > >
> > >
> > >
> > > --- On Wed, 4/23/08, Monte Tomerlin <monte@> wrote:
> > >
> > > From: Monte Tomerlin <monte@>
> > > Subject: [Vantage] v8.03.404B - Finite Global Scheduling of
> > Overlapping Operations
> > > To: vantage@yahoogroups .com
> > > Date: Wednesday, April 23, 2008, 4:39 PM
> > >
> > >
> > >
> > >
> > >
> > >
> > > We are getting some very unexplicable results after running
> Global
> > > Scheduling. Job scheduling order seemed to work well until we
> > > implemented Operation Overlap (using both Start-to-Start and
> Finish-
> > to-
> > > Finish) in our Job-MoMs. Since then there are a whole host of
> > problems:
> > > Job/Operation launch sequencing, subsequent operations
scheduled
> to
> > > start and to finish before earlier operations are to begin,
> > overloading
> > > of resources group well beyond their capacity, et al. Launching
> Job
> > > Priority only made things worse. If anyone is successfully
using
> > Global
> > > Scheduling with Overlapped Operations and Job Priority, please
> > contact
> > > me. Thanks
> > >
> > > Monte Tomerlin
> > > VP Finance
> > > Accratronics Seals Corp
> > > Burbank, CA
> > > 818-237-4948
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> ____________ _________ _________ _________ _________ _________ _
> > ____________ __
> > > Be a better friend, newshound, and
> > > know-it-all with Yahoo! Mobile. Try it now.
> > http://mobile. yahoo.com/ ;_ylt=Ahu06i62sR 8HDtDypao8Wcj9tA cJ
> > >
> >
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
______________________________________________________________________
______________
> Be a better friend, newshound, and
> know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
>
Are any of your materials Constrained? (Best not to use except in VERY small doses - and then with care to return a material to not Constrained when it isn't needed.)

How much of a spread are you using in your priority multipliers defined in your scheduling codes? We use 16 levels ranging from 1 (lowest priority) to 5000 (highest) in an non linear style increasing series (1, 2, 4, ...2500, 5000).

That garauntees the highest assigned sched priority jobs (no matter how early or late) will definitely be in the early group of jobs to get 1st crack at capacity during a global resched.

If you are experimenting on a live system with lots of in process OPs (particularly long running ones) you need to give a change in scheduling paradigm time to clear out the old WIP as in-process OPs (even if they were mis-scheduled and are low priority) won't be 'broken' and pushed out. That could take days to weeks. (In our environment, about 3 weeks for things to clear out, settle down and stabilize.)

Also: I hope you are not using the 'minimize WIP' scheduling option as whoever conceived and implemented it should be unemployed. Using it results in the opposite of what you would expect (and VERY much what you describe). Late, critical jobs get later. Not critical early jobs get earlier.

Hope the info helps. Sounds like you have your hands full.

Rob

--- On Wed, 5/14/08, fredcarnot <fredcarnot@...> wrote:

From: fredcarnot <fredcarnot@...>
Subject: [Vantage] Re: v8.03.404B - Finite Global Scheduling of Overlapping Operations
To: vantage@yahoogroups.com
Date: Wednesday, May 14, 2008, 6:57 AM






Thanks Rob
We are running a mix of forward and backward scheduling codes, but
even my very highest priority forward scheduled job does not start as
early as possible, it appears to calculate a start date into the
future and then delivers late. I have checked all material and PO
constraints. If I finite or infinitly schedule it from Job Entry it
schedules OK.

I have since reset all codes to forward schedule, the results were
very poor, again high priority jobs were getting start dates into the
future and delivering late.

However, when I set them all to backward schedule I got a much better
schedule, but the jobs were not backward scheduling, they all appear
to have forward scheduled, all starting as early as possible.

Thanks again

--- In vantage@yahoogroups .com, Robert Brown <robertb_versa@ ...>
wrote:
>
> It sounds like you are loaded to peak capacity or, more likely,
(since having load and capacity perfectly match is about as likely as
balancing a pin on end) you are overloaded.
>
> In overloaded environments, backward scheduling rarely works in
real life.
>
> Having a mix of backward and forward scheduled jobs only makes the
scheduling results worse as, backward sched jobs with sched codes
assigned high scheduling priority multipliers attempt to be scheduled
as close to just in time as possible, where as forward scheduled jobs
with high priority sched code multipliers attempt to be scheduled as
soon as possible.
>
> This ends up creating (systemically) impossible conditions and
desired results to fulfill and (mentally) for your planners, a
difficult conceptual image of how to get the most important jobs done
1st.
>
> Vantages has a natural bias toward scheduling backward sched jobs
over equal priority forward sched jobs. It also has the weakest
support for forward scheduling I've ever seen as you cannot specify
a 'no earlier than' start date fence - and all jobs set as forward
try to schedule to start immediately.
>
> Pick your poison and stick with one scheduling direction. If you
shop truly is as overloaded as it sounds, go with forward and use
different sched codes with a wide range of priority multipliers to
truly enforce your real world priorities.
>
> You mention the Calculate Scheduling Order program still
miscalculates the days early/late. If memory serves correctly, it is
calculating calendar days early/late - since 'working days' can (and
often does) vary from resource to resource.
>
> That may be the source of the deceptive results, or (perhaps in
404B), they 'fixed' something (and actually further broke the
application) . On 404A, the days/early late do seem to be correctly
calculated wants you do the import of ReqBy date into Due Date prior
to program run.
>
> Rob Brown
>
> --- On Fri, 5/9/08, fredcarnot <fredcarnot@ ...> wrote:
>
> From: fredcarnot <fredcarnot@ ...>
> Subject: [Vantage] Re: v8.03.404B - Finite Global Scheduling of
Overlapping Operations
> To: vantage@yahoogroups .com
> Date: Friday, May 9, 2008, 9:24 AM
>
>
>
>
>
>
> We have also managed to fix the date issue by replacing the due
date
> with the required date before running the set order process,
although
> it still calculate the days late wrong.
>
> Our real problem in 404B is that Global scheduling gives very
strange
> results.
>
> Some forward scheduled jobs get a start date after their Rquired
date
> and therefore schedule late, I am not sure where it gets the start
> date from, but if we then schedule the Job from Job entry it
> schedules fine.
>
> We also have backward shceduled jobs that it schedules to finish
many
> days early, but again if we schedule them from Job entry every
thing
> is fine.
>
> EPICOR UK are struggling with this at presnt, but any help most
> welcome.
>
> --- In vantage@yahoogroups .com, "Monte Tomerlin" <monte@> wrote:
> >
> > Rob - Thanks for your help. I called Epicor and SCR48782 is the
> > resolution for my problem. It is supposed to be fixed in 405 and
it
> > should be out sometime in May - Thx again - Monte Tomerlin
> >
> > --- In vantage@yahoogroups .com, Robert Brown <robertb_versa@ >
> > wrote:
> > >
> > > We are on 404 (not yet upgraded to 404B) and I've not seen the
> > behavior you described when I've TRIED to create crazy conditions
> to
> > determine the Globals tolerance for them.
> > >
> > > Your conditions (overlapping OPs either start2start or
> > finish2finish) aren't crazy (and I expect to use them as we
> > increasingly go Lean & set up cells in our Machine shop). I
wonder
> if
> > this is a new bug introduced in 404B.
> > >
> > > We are FORWARD scheduling our complex finite resource machine
> shop
> > (several hundred resources grouped under about 70 resource
groups -
> > all to create a capacity model equivalent to what we were able to
> do
> > with 70 work centers in our legacy system) - so this may also
> explain
> > why we haven't encountered what you describe in our 'make it
break'
> > testing.
> > >
> > > One thing we did learn is that Calculate Global Scheduling
Order
> > has a SERIOUS bug in it (reported in Feb 2008 and under SCR 48782
> and
> > still no ETA on resolution):
> > >
> > > When Calculate Global Scheduling Order does it passes to
> determine
> > the relative days early/late (and thus the date-based sequence
> BEFORE
> > multiplying by each Job's Scheduling Code Multiplier) IT IS USING
> THE
> > WRONG DATE.
> > >
> > > It is incorrectly using the previous as-scheduled Due Date of
> each
> > Job instead of the fixed target Req'd By Date.
> > >
> > > As a result, you could literally run the 3 step global process
10
> > consecutive times in a row (with no changed/cancelled/ additional
> Jobs
> > and no activity progress reported) and you would get 10 different
> > schedules (each progressively worse than the last in actually
> > fulfilling you Req'd By Date needs).
> > >
> > > We gave up waiting for Epicor to correct it. It is a simple
> > remapping of a single fields in the dataview used by Calculate
> Global
> > Scheduling Order that should take about 2 minutes to recode and
> > recompile (and it is approaching 3 months with no action).
> > >
> > > Our 'fix' is to recurring schedule a temporary DTS based import
> of
> > all Jobs' Req'd By Dates into the JobHead.DueDate field - and
then
> > proceeed with the multi-step global process & MRP (all done at
> night).
> > >
> > > ALSO: Testing we did on 403B showed the Global choking on Jobs
> > where Finish to Start defined consecutive Ops were activity
> reported
> > as having had parallel activity occur. (A
desirable 'opportunistic'
> > occurrence when proceding OP resources become available sooner
than
> > the Resource model expects - desireable as it increase
utilization
> > AND gets the job done sooner - so we can fulfill customers order
> > sooner than expected.)
> > >
> > > Re-testing this on 404 showed it had been fixed (before we ever
> got
> > around to reporting it to Epicor) and no longer resulted in these
> > Jobs/OPs being partially/fully left unscheduled.
> > >
> > > Perhaps the 'fix' (that was a benefit to us) caused the broken
> > behavior you describe.
> > >
> > > Rob Brown
> > >
> > >
> > >
> > > --- On Wed, 4/23/08, Monte Tomerlin <monte@> wrote:
> > >
> > > From: Monte Tomerlin <monte@>
> > > Subject: [Vantage] v8.03.404B - Finite Global Scheduling of
> > Overlapping Operations
> > > To: vantage@yahoogroups .com
> > > Date: Wednesday, April 23, 2008, 4:39 PM
> > >
> > >
> > >
> > >
> > >
> > >
> > > We are getting some very unexplicable results after running
> Global
> > > Scheduling. Job scheduling order seemed to work well until we
> > > implemented Operation Overlap (using both Start-to-Start and
> Finish-
> > to-
> > > Finish) in our Job-MoMs. Since then there are a whole host of
> > problems:
> > > Job/Operation launch sequencing, subsequent operations
scheduled
> to
> > > start and to finish before earlier operations are to begin,
> > overloading
> > > of resources group well beyond their capacity, et al. Launching
> Job
> > > Priority only made things worse. If anyone is successfully
using
> > Global
> > > Scheduling with Overlapped Operations and Job Priority, please
> > contact
> > > me. Thanks
> > >
> > > Monte Tomerlin
> > > VP Finance
> > > Accratronics Seals Corp
> > > Burbank, CA
> > > 818-237-4948
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> ____________ _________ _________ _________ _________ _________ _
> > ____________ __
> > > Be a better friend, newshound, and
> > > know-it-all with Yahoo! Mobile. Try it now.
> > http://mobile. yahoo.com/ ;_ylt=Ahu06i62sR 8HDtDypao8Wcj9tA cJ
> > >
> >
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
____________ _________ _________ _________ _________ _________ _
____________ __
> Be a better friend, newshound, and
> know-it-all with Yahoo! Mobile. Try it now.
http://mobile. yahoo.com/ ;_ylt=Ahu06i62sR 8HDtDypao8Wcj9tA cJ
>
Thanks again Rob

I have had to turn most of my material constraints off, we had lead
times set on some components and even when they are all received onto
the job the scheduler still see's the lead time as a constraint and
will not schedule the job earlier.

We too have set our priority codes similar to yours, so the priority
over rides the date.

I am running tests on an off line copy so should be OK, although I am
not sure I understand you comments ref working on the live system,
grateful for a bit more explination if poss please.

For the time being, (until we get a working patch from EPICOR) I plan
to stick to backward scheduling all jobs, although it does not do
what it says on the tin, it gives us a usable result.

We are not as far as I can tell using minimize WIP, the only place I
can see this set is on the priority codes and I have this unticked.

Thanks again
Tim

--- In vantage@yahoogroups.com, Robert Brown <robertb_versa@...>
wrote:
>
> Are any of your materials Constrained? (Best not to use except in
VERY small doses - and then with care to return a material to not
Constrained when it isn't needed.)
>
> How much of a spread are you using in your priority multipliers
defined in your scheduling codes? We use 16 levels ranging from 1
(lowest priority) to 5000 (highest) in an non linear style increasing
series (1, 2, 4, ...2500, 5000).
>
> That garauntees the highest assigned sched priority jobs (no matter
how early or late) will definitely be in the early group of jobs to
get 1st crack at capacity during a global resched.
>
> If you are experimenting on a live system with lots of in process
OPs (particularly long running ones) you need to give a change in
scheduling paradigm time to clear out the old WIP as in-process OPs
(even if they were mis-scheduled and are low priority) won't
be 'broken' and pushed out. That could take days to weeks. (In our
environment, about 3 weeks for things to clear out, settle down and
stabilize.)
>
> Also: I hope you are not using the 'minimize WIP' scheduling option
as whoever conceived and implemented it should be unemployed. Using
it results in the opposite of what you would expect (and VERY much
what you describe). Late, critical jobs get later. Not critical early
jobs get earlier.
>
> Hope the info helps. Sounds like you have your hands full.
>
> Rob
>
> --- On Wed, 5/14/08, fredcarnot <fredcarnot@...> wrote:
>
> From: fredcarnot <fredcarnot@...>
> Subject: [Vantage] Re: v8.03.404B - Finite Global Scheduling of
Overlapping Operations
> To: vantage@yahoogroups.com
> Date: Wednesday, May 14, 2008, 6:57 AM
>
>
>
>
>
>
> Thanks Rob
> We are running a mix of forward and backward scheduling codes, but
> even my very highest priority forward scheduled job does not start
as
> early as possible, it appears to calculate a start date into the
> future and then delivers late. I have checked all material and PO
> constraints. If I finite or infinitly schedule it from Job Entry it
> schedules OK.
>
> I have since reset all codes to forward schedule, the results were
> very poor, again high priority jobs were getting start dates into
the
> future and delivering late.
>
> However, when I set them all to backward schedule I got a much
better
> schedule, but the jobs were not backward scheduling, they all
appear
> to have forward scheduled, all starting as early as possible.
>
> Thanks again
>
> --- In vantage@yahoogroups .com, Robert Brown <robertb_versa@ ...>
> wrote:
> >
> > It sounds like you are loaded to peak capacity or, more likely,
> (since having load and capacity perfectly match is about as likely
as
> balancing a pin on end) you are overloaded.
> >
> > In overloaded environments, backward scheduling rarely works in
> real life.
> >
> > Having a mix of backward and forward scheduled jobs only makes
the
> scheduling results worse as, backward sched jobs with sched codes
> assigned high scheduling priority multipliers attempt to be
scheduled
> as close to just in time as possible, where as forward scheduled
jobs
> with high priority sched code multipliers attempt to be scheduled
as
> soon as possible.
> >
> > This ends up creating (systemically) impossible conditions and
> desired results to fulfill and (mentally) for your planners, a
> difficult conceptual image of how to get the most important jobs
done
> 1st.
> >
> > Vantages has a natural bias toward scheduling backward sched jobs
> over equal priority forward sched jobs. It also has the weakest
> support for forward scheduling I've ever seen as you cannot specify
> a 'no earlier than' start date fence - and all jobs set as forward
> try to schedule to start immediately.
> >
> > Pick your poison and stick with one scheduling direction. If you
> shop truly is as overloaded as it sounds, go with forward and use
> different sched codes with a wide range of priority multipliers to
> truly enforce your real world priorities.
> >
> > You mention the Calculate Scheduling Order program still
> miscalculates the days early/late. If memory serves correctly, it
is
> calculating calendar days early/late - since 'working days' can
(and
> often does) vary from resource to resource.
> >
> > That may be the source of the deceptive results, or (perhaps in
> 404B), they 'fixed' something (and actually further broke the
> application) . On 404A, the days/early late do seem to be correctly
> calculated wants you do the import of ReqBy date into Due Date
prior
> to program run.
> >
> > Rob Brown
> >
> > --- On Fri, 5/9/08, fredcarnot <fredcarnot@ ...> wrote:
> >
> > From: fredcarnot <fredcarnot@ ...>
> > Subject: [Vantage] Re: v8.03.404B - Finite Global Scheduling of
> Overlapping Operations
> > To: vantage@yahoogroups .com
> > Date: Friday, May 9, 2008, 9:24 AM
> >
> >
> >
> >
> >
> >
> > We have also managed to fix the date issue by replacing the due
> date
> > with the required date before running the set order process,
> although
> > it still calculate the days late wrong.
> >
> > Our real problem in 404B is that Global scheduling gives very
> strange
> > results.
> >
> > Some forward scheduled jobs get a start date after their Rquired
> date
> > and therefore schedule late, I am not sure where it gets the
start
> > date from, but if we then schedule the Job from Job entry it
> > schedules fine.
> >
> > We also have backward shceduled jobs that it schedules to finish
> many
> > days early, but again if we schedule them from Job entry every
> thing
> > is fine.
> >
> > EPICOR UK are struggling with this at presnt, but any help most
> > welcome.
> >
> > --- In vantage@yahoogroups .com, "Monte Tomerlin" <monte@> wrote:
> > >
> > > Rob - Thanks for your help. I called Epicor and SCR48782 is the
> > > resolution for my problem. It is supposed to be fixed in 405
and
> it
> > > should be out sometime in May - Thx again - Monte Tomerlin
> > >
> > > --- In vantage@yahoogroups .com, Robert Brown <robertb_versa@ >
> > > wrote:
> > > >
> > > > We are on 404 (not yet upgraded to 404B) and I've not seen
the
> > > behavior you described when I've TRIED to create crazy
conditions
> > to
> > > determine the Globals tolerance for them.
> > > >
> > > > Your conditions (overlapping OPs either start2start or
> > > finish2finish) aren't crazy (and I expect to use them as we
> > > increasingly go Lean & set up cells in our Machine shop). I
> wonder
> > if
> > > this is a new bug introduced in 404B.
> > > >
> > > > We are FORWARD scheduling our complex finite resource machine
> > shop
> > > (several hundred resources grouped under about 70 resource
> groups -
> > > all to create a capacity model equivalent to what we were able
to
> > do
> > > with 70 work centers in our legacy system) - so this may also
> > explain
> > > why we haven't encountered what you describe in our 'make it
> break'
> > > testing.
> > > >
> > > > One thing we did learn is that Calculate Global Scheduling
> Order
> > > has a SERIOUS bug in it (reported in Feb 2008 and under SCR
48782
> > and
> > > still no ETA on resolution):
> > > >
> > > > When Calculate Global Scheduling Order does it passes to
> > determine
> > > the relative days early/late (and thus the date-based sequence
> > BEFORE
> > > multiplying by each Job's Scheduling Code Multiplier) IT IS
USING
> > THE
> > > WRONG DATE.
> > > >
> > > > It is incorrectly using the previous as-scheduled Due Date of
> > each
> > > Job instead of the fixed target Req'd By Date.
> > > >
> > > > As a result, you could literally run the 3 step global
process
> 10
> > > consecutive times in a row (with no changed/cancelled/
additional
> > Jobs
> > > and no activity progress reported) and you would get 10
different
> > > schedules (each progressively worse than the last in actually
> > > fulfilling you Req'd By Date needs).
> > > >
> > > > We gave up waiting for Epicor to correct it. It is a simple
> > > remapping of a single fields in the dataview used by Calculate
> > Global
> > > Scheduling Order that should take about 2 minutes to recode and
> > > recompile (and it is approaching 3 months with no action).
> > > >
> > > > Our 'fix' is to recurring schedule a temporary DTS based
import
> > of
> > > all Jobs' Req'd By Dates into the JobHead.DueDate field - and
> then
> > > proceeed with the multi-step global process & MRP (all done at
> > night).
> > > >
> > > > ALSO: Testing we did on 403B showed the Global choking on
Jobs
> > > where Finish to Start defined consecutive Ops were activity
> > reported
> > > as having had parallel activity occur. (A
> desirable 'opportunistic'
> > > occurrence when proceding OP resources become available sooner
> than
> > > the Resource model expects - desireable as it increase
> utilization
> > > AND gets the job done sooner - so we can fulfill customers
order
> > > sooner than expected.)
> > > >
> > > > Re-testing this on 404 showed it had been fixed (before we
ever
> > got
> > > around to reporting it to Epicor) and no longer resulted in
these
> > > Jobs/OPs being partially/fully left unscheduled.
> > > >
> > > > Perhaps the 'fix' (that was a benefit to us) caused the
broken
> > > behavior you describe.
> > > >
> > > > Rob Brown
> > > >
> > > >
> > > >
> > > > --- On Wed, 4/23/08, Monte Tomerlin <monte@> wrote:
> > > >
> > > > From: Monte Tomerlin <monte@>
> > > > Subject: [Vantage] v8.03.404B - Finite Global Scheduling of
> > > Overlapping Operations
> > > > To: vantage@yahoogroups .com
> > > > Date: Wednesday, April 23, 2008, 4:39 PM
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > We are getting some very unexplicable results after running
> > Global
> > > > Scheduling. Job scheduling order seemed to work well until we
> > > > implemented Operation Overlap (using both Start-to-Start and
> > Finish-
> > > to-
> > > > Finish) in our Job-MoMs. Since then there are a whole host of
> > > problems:
> > > > Job/Operation launch sequencing, subsequent operations
> scheduled
> > to
> > > > start and to finish before earlier operations are to begin,
> > > overloading
> > > > of resources group well beyond their capacity, et al.
Launching
> > Job
> > > > Priority only made things worse. If anyone is successfully
> using
> > > Global
> > > > Scheduling with Overlapped Operations and Job Priority,
please
> > > contact
> > > > me. Thanks
> > > >
> > > > Monte Tomerlin
> > > > VP Finance
> > > > Accratronics Seals Corp
> > > > Burbank, CA
> > > > 818-237-4948
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > ____________ _________ _________ _________ _________ _________ _
> > > ____________ __
> > > > Be a better friend, newshound, and
> > > > know-it-all with Yahoo! Mobile. Try it now.
> > > http://mobile. yahoo.com/ ;_ylt=Ahu06i62sR 8HDtDypao8Wcj9tA cJ
> > > >
> > >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> ____________ _________ _________ _________ _________ _________ _
> ____________ __
> > Be a better friend, newshound, and
> > know-it-all with Yahoo! Mobile. Try it now.
> http://mobile. yahoo.com/ ;_ylt=Ahu06i62sR 8HDtDypao8Wcj9tA cJ
> >
>