Changing Job Due Dates

No - Your scheduler owes YOU the coffee and donuts... YOU put the time in to make it work specifically for your process needs.

...I'd let it ride as is a while (work on other things) and you'll likley have an epiphany while working on something else that you can come back and give your scheduler his 'holy grail' (single dialog box process).

Actually, just typing this, maybe consider using Job Maintenance (which I beleive contains a multi-job scheduler process) tied to sales entry. It would be a little gorier to pass the parameters but probably not impossible. (Perhaps better done with BPM.)

Nice work!

Rob

--- On Thu, 12/11/08, ofcwiz <DavidH@...> wrote:

From: ofcwiz <DavidH@...>
Subject: [Vantage] Re: Changing Job Due Dates
To: vantage@yahoogroups.com
Date: Thursday, December 11, 2008, 6:56 PM






Rob,

Looks like your solution for semi-automating the rescheduling for Jobs
is working. I shared it with the Scheduler today after testing it and
your suggestion does work. The Scheduler is happier. Still looking for
the ability to change all linked Jobs with one dialog box.

I do indeed owe you coffee & doughnuts.

Thank you for your work on this,

Dave
Vista 8.03.406A Progress
Xybix
Our Sales Orders will typically have 20-50 Jobs linked to the Sales
Order lines. When a SO ShipDate changes, changing the Job Due Dates
seems like more work than it should be. Has anyone developed a
technique that reduces the work to change Job Due Dates other than one
Job at a time through the Scheduling Board or Scheduling Maintenance
dialog box? We do not have the MRP module.

Thanks,

Dave
Xybix
Vista Progress 8.03.406A
Seems quite doable (although be careful what you wish for!... It would not be a 'blink of an eye' process... Users would notice hourglasses.)

How best to do it depends on a few things.

Are these always backward sched jobs? (Simplest scenario.)

Are you infinite or finite resource capacity? (Infinite simplest to manage.)

Do you really just want to change Job Due (or rather change the fixed Job Req'd Date & then single job schedule to get a matching Job Due Date)?

Do you run Global (if so, are the schedules locked for all make direct jobs)? - Use say you don't have MRP so you may also not have Global.

Would you be averse to working it the other way - Change your make direct jobs in Job Entry & then have the linked order/line/release ship dates changed to suit?

Would you be averse to semi-automation? - Have Order Entry and Job Entry open (with Job Entry context linked to the make direct job field on the line/release detail tab) - Then (via client VB customization) add job entry adapter (and support assemblies) & an FKV of JobProd to get a subtable view of Job Head in order entry. Release ShipDate change would then trigger a Job Req'd Date change. Actual reschedule would be done manually in context linked job entry (or I suppose you could also call the job scheduler process and pass it the dataset to base its actions on).

Sorry for more questions than answers... 2 months ago I started playing around with an experimental customization of Job Entry to trigger changes to appropriate order release data for make-direct jobs (more logical to work it this way in our process)... Got sidetracked on more urgent needs and never got back to it.

Wondering how different our needs really are. If similar enough, perhaps we could share info directly and both get done faster.

If not similar enough, then hopefully the questiond above will at least help you define the process design in more detail (and in a way that leads to several possible ways to fulfill them).

Rob

--- On Fri, 11/28/08, ofcwiz <DavidH@...> wrote:
From: ofcwiz <DavidH@...>
Subject: [Vantage] Changing Job Due Dates
To: vantage@yahoogroups.com
Date: Friday, November 28, 2008, 3:49 PM











Our Sales Orders will typically have 20-50 Jobs linked to the Sales

Order lines. When a SO ShipDate changes, changing the Job Due Dates

seems like more work than it should be. Has anyone developed a

technique that reduces the work to change Job Due Dates other than one

Job at a time through the Scheduling Board or Scheduling Maintenance

dialog box? We do not have the MRP module.



Thanks,



Dave

Xybix

Vista Progress 8.03.406A
Rob,

1)Yes, the Jobs are always backwards scheduled.
2)We are infinite resource capacity scheduling.
3)Yes, we want to change the Job Due Date. The system should change
the Start Date based upon the Company Calendar.
4)We do not currently run the Global Scheduling Process because we
cannot find a method to adjust just one set of Jobs linked to a single
Sales Order. It looks like 'Plant' is the only filter and we are on
Vista which is just one Plant. We are not looking for a wholesale
change of all Due Dates.
5)I believe we would be averse to changing the Job Due Dates and then
having the Job Dates drive a Sales Order change. It doesn't make a lot
of sense to drive Sales Order dates from the bottom up in our
organization.
6)I'm never averse to semi-automation (or automation, for that
matter). I don't understand how what you are suggesting would be
easier than what we are doing now. We currently:
a)Change the SO date
b)Open Job Entry populated with just the Jobs for the affected SO.
c)Set up a hot key for "Actions-Schedule-Job Scheduling"
d)Change the Due Date & click OK and move on to the next one.

We have tried using the Scheduling Board to accomplish this but it
still requires moving through one Job at a time. In my opinion, this
is where the automation could be most easily implemented.

No problem with the questions. If we could solve this one, our
Production manager would fall all over himself. He swears Epicor said
the software could do this, in the initial Sales conversation before
purchasing Epicor.

It sounds like our needs are not that different and that some code
might solve the problem. I'm just not smart enough on Progress coding
to even know where to start with this one. Maybe a BPM? Change SO date
and all linked Job Due Dates are changed? All of our Jobs begin with
the SO Number.

Would be very willing to share information to work through a solution
to the problem.

(We can handle hourglasses if we have confidence the processing is
working correctly.)

Thanks Rob,

Dave
Xybix
Vista Progress 8.03.406A

--- In vantage@yahoogroups.com, Robert Brown <robertb_versa@...> wrote:
>
> Seems quite doable (although be careful what you wish for!... It
would not be a 'blink of an eye' process... Users would notice
hourglasses.)
>
> How best to do it depends on a few things.
>
> Are these always backward sched jobs? (Simplest scenario.)
>
> Are you infinite or finite resource capacity? (Infinite simplest to
manage.)
>
> Do you really just want to change Job Due (or rather change the
fixed Job Req'd Date & then single job schedule to get a matching Job
Due Date)?
>
> Do you run Global (if so, are the schedules locked for all make
direct jobs)? - Use say you don't have MRP so you may also not have
Global.
>
> Would you be averse to working it the other way - Change your make
direct jobs in Job Entry & then have the linked order/line/release
ship dates changed to suit?
>
> Would you be averse to semi-automation? - Have Order Entry and Job
Entry open (with Job Entry context linked to the make direct job field
on the line/release detail tab) - Then (via client VB customization)
add job entry adapter (and support assemblies) & an FKV of JobProd to
get a subtable view of Job Head in order entry. Release ShipDate
change would then trigger a Job Req'd Date change. Actual reschedule
would be done manually in context linked job entry (or I suppose you
could also call the job scheduler process and pass it the dataset to
base its actions on).
>
> Sorry for more questions than answers... 2 months ago I started
playing around with an experimental customization of Job Entry to
trigger changes to appropriate order release data for make-direct jobs
(more logical to work it this way in our process)... Got sidetracked
on more urgent needs and never got back to it.
>
> Wondering how different our needs really are. If similar enough,
perhaps we could share info directly and both get done faster.
>
> If not similar enough, then hopefully the questiond above will at
least help you define the process design in more detail (and in a way
that leads to several possible ways to fulfill them).
>
> Rob
>
> --- On Fri, 11/28/08, ofcwiz <DavidH@...> wrote:
> From: ofcwiz <DavidH@...>
> Subject: [Vantage] Changing Job Due Dates
> To: vantage@yahoogroups.com
> Date: Friday, November 28, 2008, 3:49 PM
>
>
>
>
>
>
>
>
>
>
>
> Our Sales Orders will typically have 20-50 Jobs linked
to the Sales
>
> Order lines. When a SO ShipDate changes, changing the Job Due Dates
>
> seems like more work than it should be. Has anyone developed a
>
> technique that reduces the work to change Job Due Dates other than one
>
> Job at a time through the Scheduling Board or Scheduling Maintenance
>
> dialog box? We do not have the MRP module.
>
>
>
> Thanks,
>
>
>
> Dave
>
> Xybix
>
> Vista Progress 8.03.406A
>
Dave,

1, 2 & 4 make it easier.

5 was just a question to see if you had considered flip-flopping your process. As an IE, I know things often are done the way they are done 'because we always did it that way'. Sounds like you have good reasons. There is a very small (programming simplicity) advantage from doing everything out of job entry - but not enough to make it worth pushing consideration of a process change people will have discomfort with (or flat out is less suitable to your business needs).

I'm still fuzzy on 3. You say you change Job Due Dates (as a result of a Job Entry launched backward/infinite reschedule from a specific due date matching your linked sales order/line/release ship date). Do you not also change Job Req'd Date? Changing it which would do two things:

3.a. If the Job is already Engineered and scheduled, and Job Req'd Date is changed, the user is auto prompted to reschedule the job.
3.b. The job scheduler automatically defaults to using backward/Infinite from the Job Req'd Date.

Do you purposefully NOT change job req'd date (perhaps as it serves another purpose in your process... like some initial job promise date that you want to maintain)?

Final (new) question (really!): Do you need to have job entry open for other reasons? (Checking Material availability status, traveler printing & Releasing as you go, etc.,?)

If would clarify 3 for me (and the new question), I'm pretty sure I can get you going with some actual code.

Rob



--- On Mon, 12/1/08, ofcwiz <DavidH@...> wrote:
From: ofcwiz <DavidH@...>
Subject: [Vantage] Re: Changing Job Due Dates
To: vantage@yahoogroups.com
Date: Monday, December 1, 2008, 11:56 AM











Rob,



1)Yes, the Jobs are always backwards scheduled.

2)We are infinite resource capacity scheduling.

3)Yes, we want to change the Job Due Date. The system should change

the Start Date based upon the Company Calendar.

4)We do not currently run the Global Scheduling Process because we

cannot find a method to adjust just one set of Jobs linked to a single

Sales Order. It looks like 'Plant' is the only filter and we are on

Vista which is just one Plant. We are not looking for a wholesale

change of all Due Dates.

5)I believe we would be averse to changing the Job Due Dates and then

having the Job Dates drive a Sales Order change. It doesn't make a lot

of sense to drive Sales Order dates from the bottom up in our

organization.

6)I'm never averse to semi-automation (or automation, for that

matter). I don't understand how what you are suggesting would be

easier than what we are doing now. We currently:

a)Change the SO date

b)Open Job Entry populated with just the Jobs for the affected SO.

c)Set up a hot key for "Actions-Schedule- Job Scheduling"

d)Change the Due Date & click OK and move on to the next one.



We have tried using the Scheduling Board to accomplish this but it

still requires moving through one Job at a time. In my opinion, this

is where the automation could be most easily implemented.



No problem with the questions. If we could solve this one, our

Production manager would fall all over himself. He swears Epicor said

the software could do this, in the initial Sales conversation before

purchasing Epicor.



It sounds like our needs are not that different and that some code

might solve the problem. I'm just not smart enough on Progress coding

to even know where to start with this one. Maybe a BPM? Change SO date

and all linked Job Due Dates are changed? All of our Jobs begin with

the SO Number.



Would be very willing to share information to work through a solution

to the problem.



(We can handle hourglasses if we have confidence the processing is

working correctly.)



Thanks Rob,



Dave

Xybix

Vista Progress 8.03.406A



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

>

> Seems quite doable (although be careful what you wish for!... It

would not be a 'blink of an eye' process... Users would notice

hourglasses. )

>

> How best to do it depends on a few things.

>

> Are these always backward sched jobs? (Simplest scenario.)

>

> Are you infinite or finite resource capacity? (Infinite simplest to

manage.)

>

> Do you really just want to change Job Due (or rather change the

fixed Job Req'd Date & then single job schedule to get a matching Job

Due Date)?

>

> Do you run Global (if so, are the schedules locked for all make

direct jobs)? - Use say you don't have MRP so you may also not have

Global.

>

> Would you be averse to working it the other way - Change your make

direct jobs in Job Entry & then have the linked order/line/release

ship dates changed to suit?

>

> Would you be averse to semi-automation? - Have Order Entry and Job

Entry open (with Job Entry context linked to the make direct job field

on the line/release detail tab) - Then (via client VB customization)

add job entry adapter (and support assemblies) & an FKV of JobProd to

get a subtable view of Job Head in order entry. Release ShipDate

change would then trigger a Job Req'd Date change. Actual reschedule

would be done manually in context linked job entry (or I suppose you

could also call the job scheduler process and pass it the dataset to

base its actions on).

>

> Sorry for more questions than answers... 2 months ago I started

playing around with an experimental customization of Job Entry to

trigger changes to appropriate order release data for make-direct jobs

(more logical to work it this way in our process)... Got sidetracked

on more urgent needs and never got back to it.

>

> Wondering how different our needs really are. If similar enough,

perhaps we could share info directly and both get done faster.

>

> If not similar enough, then hopefully the questiond above will at

least help you define the process design in more detail (and in a way

that leads to several possible ways to fulfill them).

>

> Rob

>

> --- On Fri, 11/28/08, ofcwiz <DavidH@...> wrote:

> From: ofcwiz <DavidH@...>

> Subject: [Vantage] Changing Job Due Dates

> To: vantage@yahoogroups .com

> Date: Friday, November 28, 2008, 3:49 PM

>

>

>

>

>

>

>

>

>

>

>

> Our Sales Orders will typically have 20-50 Jobs linked

to the Sales

>

> Order lines. When a SO ShipDate changes, changing the Job Due Dates

>

> seems like more work than it should be. Has anyone developed a

>

> technique that reduces the work to change Job Due Dates other than one

>

> Job at a time through the Scheduling Board or Scheduling Maintenance

>

> dialog box? We do not have the MRP module.

>

>

>

> Thanks,

>

>

>

> Dave

>

> Xybix

>

> Vista Progress 8.03.406A

>
Rob,

5) Regarding 'Jobs driving SO' or 'SO driving Jobs'. Our ship dates
are tied to having resources in the field in place for an install, and
therefore it takes an act of Congress to move the Due Dates. If the
Due Date is moved, it's usually a Customer install change or a
rearrangement of field install personnel availability. We don't
normally ship/not ship based upon parts availability.

3) We do not change the Job Req'd Date because in the Epicor 'Help' it
says:
"Do not confuse the Req'd By date with the scheduled Start or Due
dates. The Start and Due dates are calculated through the scheduling
process and will change as you reschedule the job. The Required By
date does not change through the scheduling process; it remains fixed
for your reference. If you need, however, you can enter a different
date in this field."
I believe this date serves as a good benchmark for the original
scheduled date. Fundamentally, there is no reason why this date could
not changed along with the DueDate. It does not appear to be used in
any of the reports that matter. I have trouble understanding why it
matters for automation purposes.
3a) I guess I was not aware of the auto prompt because we were not
using it. Still a manual process though.
3b) Using the scheduling method I described in the last email, using
the 'Schedule Job' maintenance screen, the default is "backwards"

There is no requirement to have Job Entry open when changing the Due
Date. If there was a button on the Sales Order Entry screen that said
"We're changing the Job Due Dates linked to this SO when you press
this button", I can see no difficulty. It is a requirement though that
when the Due Date on the Job is changed, backward scheduling is
allowed to happen, and the Start Date is properly set back based upon
labor hours. We could care less if the Job Entry/Tracker opened (or
not) or if an hourglass spun for a few.

Dave
Xybix
8.03.406A Progress


--- In vantage@yahoogroups.com, Robert Brown <robertb_versa@...> wrote:
>
> Dave,
>
> 1, 2 & 4 make it easier.
>
> 5 was just a question to see if you had considered flip-flopping
your process. As an IE, I know things often are done the way they are
done 'because we always did it that way'. Sounds like you have good
reasons. There is a very small (programming simplicity) advantage from
doing everything out of job entry - but not enough to make it worth
pushing consideration of a process change people will have discomfort
with (or flat out is less suitable to your business needs).
>
> I'm still fuzzy on 3. You say you change Job Due Dates (as a result
of a Job Entry launched backward/infinite reschedule from a specific
due date matching your linked sales order/line/release ship date). Do
you not also change Job Req'd Date? Changing it which would do two
things:
>
> 3.a. If the Job is already Engineered and scheduled, and Job Req'd
Date is changed, the user is auto prompted to reschedule the job.
> 3.b. The job scheduler automatically defaults to using
backward/Infinite from the Job Req'd Date.
>
> Do you purposefully NOT change job req'd date (perhaps as it serves
another purpose in your process... like some initial job promise date
that you want to maintain)?
>
> Final (new) question (really!): Do you need to have job entry open
for other reasons? (Checking Material availability status, traveler
printing & Releasing as you go, etc.,?)
>
> If would clarify 3 for me (and the new question), I'm pretty sure I
can get you going with some actual code.
>
> Rob
Thanks for the additional info Dave,

Very clear now (also 3:30am and very LATE!).

Need to get a few hours shuteye. Tomorrow (today?!?!) I'll email you a suggested customization to do it the easiest (but not necessarily long term efficient) way. You'll be adding some foreign key views (at least one) to the hotkey launched scheduling form & from those added dataviews you will than have the data to auto set your Due date with a 3,4 line subroutine.

It's often best to start simple and let the users play with it. They often surprise you and come back saying thank you - It is good enough.

(Anyone have any ambien out there? Maybe I could then catch some ZZzzzzzzzs) {:(

Rob

--- On Tue, 12/2/08, ofcwiz <DavidH@...> wrote:

From: ofcwiz <DavidH@...>
Subject: [Vantage] Re: Changing Job Due Dates
To: vantage@yahoogroups.com
Date: Tuesday, December 2, 2008, 11:01 AM






Rob,

5) Regarding 'Jobs driving SO' or 'SO driving Jobs'. Our ship dates
are tied to having resources in the field in place for an install, and
therefore it takes an act of Congress to move the Due Dates. If the
Due Date is moved, it's usually a Customer install change or a
rearrangement of field install personnel availability. We don't
normally ship/not ship based upon parts availability.

3) We do not change the Job Req'd Date because in the Epicor 'Help' it
says:
"Do not confuse the Req'd By date with the scheduled Start or Due
dates. The Start and Due dates are calculated through the scheduling
process and will change as you reschedule the job. The Required By
date does not change through the scheduling process; it remains fixed
for your reference. If you need, however, you can enter a different
date in this field."
I believe this date serves as a good benchmark for the original
scheduled date. Fundamentally, there is no reason why this date could
not changed along with the DueDate. It does not appear to be used in
any of the reports that matter. I have trouble understanding why it
matters for automation purposes.
3a) I guess I was not aware of the auto prompt because we were not
using it. Still a manual process though.
3b) Using the scheduling method I described in the last email, using
the 'Schedule Job' maintenance screen, the default is "backwards"

There is no requirement to have Job Entry open when changing the Due
Date. If there was a button on the Sales Order Entry screen that said
"We're changing the Job Due Dates linked to this SO when you press
this button", I can see no difficulty. It is a requirement though that
when the Due Date on the Job is changed, backward scheduling is
allowed to happen, and the Start Date is properly set back based upon
labor hours. We could care less if the Job Entry/Tracker opened (or
not) or if an hourglass spun for a few.

Dave
Xybix
8.03.406A Progress

--- In vantage@yahoogroups .com, Robert Brown <robertb_versa@ ...> wrote:
>
> Dave,
>
> 1, 2 & 4 make it easier.
>
> 5 was just a question to see if you had considered flip-flopping
your process. As an IE, I know things often are done the way they are
done 'because we always did it that way'. Sounds like you have good
reasons. There is a very small (programming simplicity) advantage from
doing everything out of job entry - but not enough to make it worth
pushing consideration of a process change people will have discomfort
with (or flat out is less suitable to your business needs).
>
> I'm still fuzzy on 3. You say you change Job Due Dates (as a result
of a Job Entry launched backward/infinite reschedule from a specific
due date matching your linked sales order/line/release ship date). Do
you not also change Job Req'd Date? Changing it which would do two
things:
>
> 3.a. If the Job is already Engineered and scheduled, and Job Req'd
Date is changed, the user is auto prompted to reschedule the job.
> 3.b. The job scheduler automatically defaults to using
backward/Infinite from the Job Req'd Date.
>
> Do you purposefully NOT change job req'd date (perhaps as it serves
another purpose in your process... like some initial job promise date
that you want to maintain)?
>
> Final (new) question (really!): Do you need to have job entry open
for other reasons? (Checking Material availability status, traveler
printing & Releasing as you go, etc.,?)
>
> If would clarify 3 for me (and the new question), I'm pretty sure I
can get you going with some actual code.
>
> Rob
Dave,

OK. For a quick and dirty solution that you can expand upon later (if needed... You may find it is enough as is) - The premise is that:

1. You will have Order Entry open with an order loaded (or search list group of orders selected & one loaded) and be on the Releases/Detail subtab.

2. From the Jobs grid (bottom right of form) you will have put your cursor on the linked/Make-Direct job number and right click menu launched job entry (which will then have that job loaded & as you switch order/line/releases, the appropriate linked jobs will load in Job Entry automatically).

3. Your people will edit the Ship By date in the Release Detail tab form & then (Alt-TAB) switch to the Job Entry window. I believe you said you had a hotkey combo set up to launch the Job Entry Job Scheduler so your people will then hit that hot-key combo and launch the Scheduling form.

You are going to customize that Scheduling form application (instructions below) so it automatically uses the just edited Order Line Release Ship By date as the target (infinite/backward scheduled) Due Date.

4. Your people will press OK on the scheduling form & it will schedule your job to the new Ship By matching Due Date. Your people will then <Alt-TAB> back to Order Entry and go to the next order line release (repeating the process until all order line releases & their corresponding jobs are rescheduled).

As there will be more mouseclicks/keystrokes to enter a new Ship By date than will be required to switch to job entry, launch scheduling & schedule & then return to Order Entry - it should be pretty efficient.

Now: On to the customization -

Click on customization mode and launch job entry. Select your active customization (if any - otherwise load Base) and once the app is open, find a job that can be scheduled (or rescheduled) & load it. (You just need any Engineered Job.)

Hotkey launch the Job Scheduler (again, select your active customization if any - otherwise load Base).

When it pops up, right click on a blank section of the form and when the right click menu pops up, select Customization.

When the VB editor loads, go to Tools menu and select Data Tools. You are now going to create two Custom Views.

(1) Click Custom View and enter the following info:

View Name: OrdHd
Parent View Name: JobProd
View Type: Foreign Key View

Foreign Key View Info:

Column Name: JobProd.OrderNum
Like Column Value: OrderHed.OrderNum
Adapter Name: SalesOrderAdapter
Get By Type: IntegerGetByID

- and then press the Add button. You shuld get a messagebox saying the view was added (and you should see "FKV: OrdHd" in the left pane tree view as a branch off of "NV: JobProd").

(2) Because OrderRel & JobProd tables must be linked through 4 columns (Company, OrderNum, OrderLine, OrderRelNum) this time you're going to create a Sub Table View in stead fo a simple FKV (FOreign Key View). Again click Add View and enter the following:

View Name: OrdRel
Parent View Name: OrdHd
View Type: Sub Table View

SubTable View Info:

Sub Table Name: OrderRel
Link Columns View: JobProd (If 'JobProd' not selectable, select 'OrdHd')

Parent View Columns Child View Columns
------------------------------------------
JobProd.Company OrderRel.Company
JobProd.OrderNum OrderRel.OrderNum
JobProd.OrderLine OrderRel.OrderLine
JobProd.OrderRelNum OrderRel.OrderRelNum

(If you had to select 'OrdHd' in the Link Columns View section above instead of 'JobProd', all the ParentView Columns will be "OrdHd." instead of "JobProd.").

- and the press the Add button. You should again get a messagebox telling you the view was successfully added (and you should also see it displayed in the left pane tree view as a 3rd level deep branch off of "NV: JobProd" with "FKV: OrdHd" in the middle).

Press OK and close the Data Tools window.

In the VB editor, go to File/Save As and give it a unique (short) customization name with a pertinent description - and then save it.

Now go to Script Editor tab and enlarge the code window to a usable size.

Add the two "Public withEvents...." declarations below where shown:

Module Script

'// ** Wizard Insert Location - Do Not Remove
'Begin/End Wizard Added Module Level Variables' Comments! **

'// Begin Wizard Added Module Level Variables **

'// End Wizard Added Module Level Variables **

Public withEvents edvSchedEng As EpiDataView
Public withEvents edvOrdRel As EpiDataView

'// Add Custom Module Level Variables Here **

Add the last two statements below where shown in the InitializeCustomCode sub:

Sub InitializeCustomCode()
'// ** Wizard Insert Location - Do not delete
'Begin/End Wizard Added Variable Intialization
' lines **

'// Begin Wizard Added Variable Intialization

'// End Wizard Added Variable Intialization

edvSchedEng = CType(oTrans.EpiDataViews("ScheduleEngine"), EpiDataView)
edvOrdRel = CType(oTrans.EpiDataViews("OrdRel"), EpiDataView)

Add the last two statements below where shown in the DestroyCustomCode sub:

Sub DestroyCustomCode()
'// ** Wizard Insert Location - Do not delete
'Begin/End Wizard Added Object Disposal
' lines **

'// Begin Wizard Added Object Disposal

'// End Wizard Added Object Disposal

edvSchedEng = Nothing
edvOrdRel = Nothing

Now add the subroutine below as shown at the end of the module - right before the "End Module" final statement:

Private Sub ScheduleForm_Load(ByVal sender As object, ByVal args As EventArgs) Handles ScheduleForm.Load
'// '// Add Event Handler Code
'//
edvSchedEng.dataView(edvSchedEng.Row)("EndDate") = edvOrdRel.dataView(edvOrdRel.Row)("ReqDate")

End Sub

Go to the Tools menu and "Test Code". Assuming everything was entered correctly, you should get this message:

Compiling Custom Code ...

** Custom Code Compiled Successfully. **

If you don't, the message will tell you what lines have code errors (and some detail as to what those errors are). Check them for typos & repeat until clean.

Now go to File & Save. I strongly urge you to also Export to XML as well for a backup.

Close the VB editor and unclick yourself out of customization mode.

The only thing remaining is to activate your customized job scheduler form so it is the default. This is done in SubProcess menu maintenance. (Read the help file if needed. My memory of the actions to take are fuzzy.)

Close Vantage completely and reopen/login.

Verify your new customized Job Entry/Job Scheduler Form is active and working by following process steps 1-4 (outlined at the start of this email).

When the Schedule Form pops up in step 3, right click on an empty form area and launch "About" from the menu that popped up.

Hit the System Info button on the window that pops up.

Click on the Software Environment tab and verify the Customization Name's value is the customization name you just created and activated. If it isn't, you did something wrong in SubProcess menu maintenance.

Assuming all went well (and you religously follow process steps 1-4), the job scheduler should now automatically be using the linked order/line/release Ship By date as the Due Date to schedule backward/infinite from.

Happy trails.... Demand coffee & donuts for payment! :)

Rob

--- On Tue, 12/2/08, ofcwiz <DavidH@...> wrote:

From: ofcwiz <DavidH@...>
Subject: [Vantage] Re: Changing Job Due Dates
To: vantage@yahoogroups.com
Date: Tuesday, December 2, 2008, 11:01 AM






Rob,

5) Regarding 'Jobs driving SO' or 'SO driving Jobs'. Our ship dates
are tied to having resources in the field in place for an install, and
therefore it takes an act of Congress to move the Due Dates. If the
Due Date is moved, it's usually a Customer install change or a
rearrangement of field install personnel availability. We don't
normally ship/not ship based upon parts availability.

3) We do not change the Job Req'd Date because in the Epicor 'Help' it
says:
"Do not confuse the Req'd By date with the scheduled Start or Due
dates. The Start and Due dates are calculated through the scheduling
process and will change as you reschedule the job. The Required By
date does not change through the scheduling process; it remains fixed
for your reference. If you need, however, you can enter a different
date in this field."
I believe this date serves as a good benchmark for the original
scheduled date. Fundamentally, there is no reason why this date could
not changed along with the DueDate. It does not appear to be used in
any of the reports that matter. I have trouble understanding why it
matters for automation purposes.
3a) I guess I was not aware of the auto prompt because we were not
using it. Still a manual process though.
3b) Using the scheduling method I described in the last email, using
the 'Schedule Job' maintenance screen, the default is "backwards"

There is no requirement to have Job Entry open when changing the Due
Date. If there was a button on the Sales Order Entry screen that said
"We're changing the Job Due Dates linked to this SO when you press
this button", I can see no difficulty. It is a requirement though that
when the Due Date on the Job is changed, backward scheduling is
allowed to happen, and the Start Date is properly set back based upon
labor hours. We could care less if the Job Entry/Tracker opened (or
not) or if an hourglass spun for a few.

Dave
Xybix
8.03.406A Progress

--- In vantage@yahoogroups .com, Robert Brown <robertb_versa@ ...> wrote:
>
> Dave,
>
> 1, 2 & 4 make it easier.
>
> 5 was just a question to see if you had considered flip-flopping
your process. As an IE, I know things often are done the way they are
done 'because we always did it that way'. Sounds like you have good
reasons. There is a very small (programming simplicity) advantage from
doing everything out of job entry - but not enough to make it worth
pushing consideration of a process change people will have discomfort
with (or flat out is less suitable to your business needs).
>
> I'm still fuzzy on 3. You say you change Job Due Dates (as a result
of a Job Entry launched backward/infinite reschedule from a specific
due date matching your linked sales order/line/release ship date). Do
you not also change Job Req'd Date? Changing it which would do two
things:
>
> 3.a. If the Job is already Engineered and scheduled, and Job Req'd
Date is changed, the user is auto prompted to reschedule the job.
> 3.b. The job scheduler automatically defaults to using
backward/Infinite from the Job Req'd Date.
>
> Do you purposefully NOT change job req'd date (perhaps as it serves
another purpose in your process... like some initial job promise date
that you want to maintain)?
>
> Final (new) question (really!): Do you need to have job entry open
for other reasons? (Checking Material availability status, traveler
printing & Releasing as you go, etc.,?)
>
> If would clarify 3 for me (and the new question), I'm pretty sure I
can get you going with some actual code.
>
> Rob
Rob,

WOW
I think coffee and doughnuts will work.

I will be looking into this tomorrow (Fri) and will get back to by
Monday at the latest.

Your work is already appreciated.

Thank you,
Dave
Xybix
8.03.406A Progress
Rob,

Looks like your solution for semi-automating the rescheduling for Jobs
is working. I shared it with the Scheduler today after testing it and
your suggestion does work. The Scheduler is happier. Still looking for
the ability to change all linked Jobs with one dialog box.

I do indeed owe you coffee & doughnuts.

Thank you for your work on this,

Dave
Vista 8.03.406A Progress
Xybix