psdi.app.workorder

Class FldWOSchedDate

    • 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