psdi.app.workorder

Class FldWOSchedDate

java.lang.Object

psdi.mbo.MboValueAdapter

psdi.app.workorder.FldWOSchedDate

All Implemented Interfaces:

MboConstants, MboValueListener

public class FldWOSchedDate
extends MboValueAdapter

Attribute handler for both Schedule dates, SchedStart and SchedFinish. See also the handlers for ActStart/Finish and TargStart/CompDate.

See Also:

FldWOActualDate, FldWOTargetDate

Field Summary

Fields inherited from class psdi.mbo.MboValueAdapter

mboValue

Fields inherited from interface psdi.mbo.MboValueListener

TYPE_DOMAIN, TYPE_FIELDCLASS, TYPE_KEY, TYPE_UNKNOWN

Fields inherited from interface psdi.mbo.MboConstants

ALLROWS, CHANGEDBY_USER, COUNT_ADDITIONS, COUNT_AFTERSAVE, COUNT_DATABASE, COUNT_DELETED, COUNT_EXISTING, DBCONFIG, DELAYVALIDATION, DELAYVALIDATIONONLY, DISCARDABLE, GOTCOMPLETEWHERE, HIDDEN, NO_RELATEDMBOS_OF_OWNERSCHILDREN_FETCH, NOACCESSCHECK, NOACTION, NOADD, NOCOMMIT, NODELETE, NONE, NOOVERWRITE, NOSAVE, NOSETVALUE, NOUPDATE, NOVALIDATION, NOVALIDATION_AND_NOACTION, NOVALIDATION_AND_NOACTION_ALLOWCROSSOVER, READONLY, REBUILD, REQUIRED, SAMEVALUEVALIDATION, SETBYPARENT, USER

Constructor Summary

Constructors

Constructor and Description
FldWOSchedDate(MboValue mbv) construct and attach to the MboValue.

Method Summary

Methods

Modifier and Type	Method and Description
void	action() When the SchedStart is updated, the RequireDate fields on any WPMaterial records are to be updated, subject to certain limitations.
void	validate() This field can be null.

Methods inherited from class psdi.mbo.MboValueAdapter

getAppLink, getIntegrationService, getList, getLookupName, getMatchingAttr, getMatchingAttr, getMboValue, getMboValue, getType, hasList, init, initValue, setType, setValueFromLookup, smartFill, smartFind, smartFind

Methods inherited from class java.lang.Object

equals, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Constructor Detail

FldWOSchedDate

public FldWOSchedDate(MboValue mbv)

construct and attach to the MboValue.

Parameters:

mbv - the MboValue which this field attach to.

Method Detail

validate

public void validate()
              throws MXException,
                     java.rmi.RemoteException

This field can be null. If SchedStart and SchedFinish aren't both null, SchedStart must be before SchedFinish. The Schedule dates may be outside the Constraint range, but if either one is, a warning is issued and the user must explicitly decide to go forward. The only exception to this is if it's not an interactive session: if an outside agent like Scheduler is writing data to Maximo, no warning is issued (since the user has presumably already decided to have Scheduled Dates outside the Constraint Range).

Specified by:

validate in interface MboValueListener

Overrides:

validate in class MboValueAdapter

Throws:

MXApplicationException - "workorder", "StartAfterFinish" when the schedule startdate is after schedule finishdate.

MXApplicationYesNoCancelException - "workorder", "SchedDateEarlierThanStConst", when a schedule date is before the Start Constraint.

MXApplicationYesNoCancelException - "workorder", "SchedDateLaterThanFinConst", when a schedule date is after the Finish Constraint.

MXException

java.rmi.RemoteException

action

public void action()
            throws MXException,
                   java.rmi.RemoteException

When the SchedStart is updated, the RequireDate fields on any WPMaterial records are to be updated, subject to certain limitations. The basic equation is: New WPMaterial RequireDate = Old WPMaterial RequireDate + ( (New SchedStart Date) - (Old SchedStart Date) ) That is, the WPMaterial RequireDate is changed by whatever factor the SchedStart date was. Limitations relate to cases where one or more of the terms in the equation are missing. Also, the WPMaterial RequireDate must be in the future (we wish to avoid triggering an exception from the field validation method). Further details: 1) There's a MaxVar called UpdateWPMatReqDate; if it doesn't exist or if it's set to false, then no processing of this kind is done. 2) If the WPMaterial row is Direct Issue and has been re-ordered, which is shown by the presence of a value in the PR field, then the dates are not to be touched. 3) If there was no previous entry in the SchedStart field, meaning there's no delta change to be calculated, then use the entered SchedStart date itself to replace the WPMaterial Required dates, *provided* it's in the future; if it's in the past, do nothing. 4) If the RequireDate field of a WPMaterial record is empty, meaning that there's nothing to add a delta change to, insert the SchedStart date just entered (assuming it's in the future; see (3)). 5) If an existing SchedStart date and the WPMaterial RequireDates are different, it's possible that moving a SchedStart date back might move the WPMaterial RequireDates into the past; if this happens, examine the RequireDate. If it's already in the past, leave it alone: moving dates around in the past serves no purpose. If the original Required Date is in the future, move it back as far as possible, which is to the current DateTime. Finally, code has been added to WPMaterialSet so that any change to a WPMaterial RequireDate will propagate down into the RequiredDate fields of related InvReserve records, subject to the limitations there.

Specified by:

action in interface MboValueListener

Overrides:

action in class MboValueAdapter

Throws:

MXException

java.rmi.RemoteException