Rescheduling planning date - MWS910

MWS910 - Rescheduling Planning Date is designed to handle all types of orders. It functions as follows:

Detect that an acquisition order has changed date/time.

This mostly happens in (MMS910). We save the date for the MITPLO record that is being changed, then check after the change if the date/time changed. If it did, then we also check if any links exist (a link can be either an order initiated link or a pre-allocation). If any links exist, then we write a record to table (MMW910) to trigger a rescheduling.

(MMS910) checks for the change and calls MMMNGPRR with *RESC if a link exists. MMMNGPRR calls MMMNGPRA with *DATE to write to (MMW910).

A number of programs write to (MMW910) directly. This is usually because they update MITPLO directly OR they deal with line type 2 (no MITPLO exists).
Write a record to (MMW910).
Perform or trigger the reschedule.
This is done by (MWS910). This is an auto start job.

(MWS910) waits for new records to be written into table (MMW910). When a new record arrives, it is processed by (MWS910), then deleted.

(MWS910) first checks if the order to be rescheduled has rescheduling turned on (this is a flag on the various order types). If so, then it performs a reschedule according to the type of order. In all cases, notification is done if required according to a parameter passed in (MMW910) (message 256 in M3 Mail).
- CO is done in (MWS910) by calling OOLINEPI.
- Service orders are done inside MWS910 itself.
- RO/DO is done inside (MWS910).
- MO rescheduling is done by writing a record to (MPM010). Note that we reschedule the start date of the connected operation in all cases except when the acquisition order that triggered the reschedule is a subcontract PO. For subcontract operations, we reschedule using the new date as the finish date.