Prediction and offset of OracleEBSMRP Module

Prediction and offset of OracleEBSMRP Module
The Oracle ebs mrp module defines the basic concepts of prediction and subtraction based on the original prediction. It uses the planned sales order to reduce the corresponding prediction quantity to get the current prediction. Current prediction = original prediction-customer order. The first type of prediction method is automatic offset when the order is planned, which means automatic offset prediction when the planned sales order is planned; the scheduler manager is required to run on the foreground (MRP> Settings> scheduler manager); the configuration file MRP: Consume Forecast = Yes needs to be set; the new sales order is scheduled, or when a planned sales order is changed, this charge is applicable. Oracle recommends this automatic offset method, because in this method, the offset is only for new orders or changed orders, and the new and old requirements are clearly divided, this effectively prevents historical orders from being mistakenly or excessively predicted. Substantive: only records with process_status = 2 in MRP_SALES_ORDER_UPDATES are processed. In the second type, there are two effective modes for the plan manager to take effect when copying, merging, or loading: foreground running (MRP> Settings> scheduler manager); If the configuration file MRP: perform Planning Manager Functions in Loads = Yes, it can replace all the Functions of the scheduler Manager when you run the copy, merge, and load programs. On the basis of the plan manager's effectiveness (that is, when at least one of the above two conditions is met), you can execute the prediction offset in the following two steps: replicate/merge the prediction; offset when loading predictions into MDS. Essence: Based on the prediction of the original quantity, all the order requirements in OE_ORDER_LINES_ALL are offset from the beginning. The specific offset logic is the same as the first type. Category 3: prediction Set offset: The prediction Set offset is irrelevant to the plan manager. Depending on the configuration file MRP: Consume Fcst Set Summary, the prediction Set Offset object may be all open order lines in OE_ORDER_LINES_ALL (when Set to Yes ), the status of the order line may not be distinguished, and all records in MRP_SALES_ORDER_UPDATES may be retrieved (when set to No ). The records captured in both cases are further limited by the demand start date on the Prediction set Offset request. Essence: After the prediction set Offset request is started, all the offset records of the current prediction set are cleared first. Then, based on the predicted original quantity, based on the configuration file MRP: the range of requirement records determined by the Consume Fcst Set Summary setting and request parameters is offset from the beginning. The specific offset logic is the same as the first type. When an enterprise officially uses MRP, the prediction set should be used with caution. You cannot change the configuration file MRP: Consume Fcst Set Summary without professional guidance. Basic settings: prediction set Offset Option
1. The offset box determines whether the prediction set can be offset. This option is valid for all the Offset methods. 2. The exception update percentage uses the maximum percentage of the original pre-measurement that can be offset by a single sales order to control the impact of the exception demand. For example, if you set the exception update percentage of the prediction set to 50% and add three rows of prediction, the original number of each row is 100, which means that each sales order line (line_id) A maximum of 50 values (100 * 50%) can be predicted for each row ):


3. the number of days for reverse push and the number of days for pre-push are the number of working days that can be deducted from the planned sales order date, behind or forward. Non-workdays are not included. When defining a prediction set, you can enter the number of days for reverse push and backward push. The number of days for offset defines the time period included in the prediction entry. When the prediction date that is not found to be exactly the same as the sales order date, or even if the exact match date is found but the quantity cannot meet the sales order quantity, the offset will first move behind the workday range (reverse push) to find the pre-measurement to be offset; if the search fails, the offset will move forward within the workday range (forward ). For example, set the number of days for the prediction to 5 and the number of days for the prediction to 20. The original prediction falls into 6 working days respectively. If there is a sales order at this time, the shipping date is scheduled to be 8 and the quantity is 100. Then, the scheduler manager will offset the number in the order of 8, 4, 1, 11, and 12, at last, only the predictions on the 15th are left:
Answer:
The configuration file MRP: Compute Sales Order Changes indicates whether to calculate and use the Sales Order requirements to execute prediction and track the Sales Order information. Available values: yes-calculate and use the sales order information. No-do not calculate and use the sales order information. When this configuration file is set to "no", the sales orders of the new plan cannot be scaled normally. When you set the configuration file option to "yes", the scheduler manager will offset the file and set it to "no" to all the sales orders planned. This configuration file is used to control how the scheduler Manager processes process_status = 2 (to be processed) records in the MRP_SO-LINES-TEMP: Once a sales order is scheduled, MRP_SO_LINES_TEMP is inserted, and process_status = 2 (to be processed ); when the profile is set to no, the scheduler manager does not process them and records remain in the pending state; when the profile is set to yes, the scheduler manager captures all pending entries in the MRP_SO-LINES-TEMP, insert MRP_SALES_ORDER_UPDATES and update process_status = 5 (succeeded) in TEMP ). MRP: Consume Scst Set Summary is-only order lines that meet the parameters on the scheduled shipping date and have not yet been delivered for confirmation can be used to offset the prediction Set. No-All Order Lines with planned shipment dates meeting request parameters can be used to offset the prediction set. Depending on the configuration file MRP: Consume Fcst Set Summary, the prediction Set Offset object may be all open order lines in OE_ORDER_LINES_ALL (when Set to Yes ), the status of the order line may not be distinguished, and all records in MRP_SALES_ORDERS_UPDATES may be retrieved (when set to No ). This configuration file is only valid for the prediction Set offset, and is invalid for the prediction Automatic offset through the plan manager. MRP: Old Sales Orders Cutoff DaysOld Sales Orders Cutoff Days. This configuration file is used to deal with the order updated during the unexpected suspension period of the scheduler manager, prevent expired orders that have been closed from being constantly offset by predictions. The prediction offset is directly related to the MRP_SALES_ORDER_UPDATES table. Whether the label of current_availabe_to_mrp in this table is Y or N determines whether the order line participates in the prediction offset. If I have an order and its shipment occurs during the pause period of the scheduler manager, after the scheduler manager is restarted, the order is still in the Y state in the MRP_SALES_ORDER_UPDATES table (if the scheduler manager continues to run, for normal orders, the value is Y at registration and N after the order is closed ). The configuration file "Old Sales Orders Cutoff Days" takes effect for the order line in the "Y" state in this table to prevent the closed expired Orders from being continuously offset by the prediction.
To test the function, follow these steps: Set the Old Sales Orders Cutoff Days to null (indicating an infinite number of Days), close the scheduler manager, register a new order, and confirm the change; re-open the scheduler manager and test the offset. You will find that the order that has been closed is still able to offset the prediction. Principles of the Offset logical database
The main steps are as follows: Once a Sales Order is scheduled, MRP_SO_LINES_TEMP will be inserted. process_status = 2 (to be processed) The scheduler manager will verify the configuration file MRP: Compute Sales Order Changes settings, if it is set to yes, the scheduler manager crawls all pending entries in MRP_SO_LINES_TEMP, inserts them into MRP_SALES_ORDER_UPDATES, and updates process_status = 5 (succeeded) in TEMP) the initial status process_status = 2 (to be processed) of the record inserted with MRP_SALES_ORDER_UPDATES verifies the configuration file MRP: Consume Forecast settings. If it is configured as yes, the scheduler manager balances all pending entries in MRP_SALES_ORDER_UPDATES, updates MRP_FORECAST_UPDATES Based on the offset record, and updates the MRP_FORECAST_UPDATES table _ Process_status = 5 (succeeded) in SALES_ORDER_UPDATES: The prediction offset principle is implemented in the prediction set. The plan of a sales order line can be offset by Multiple Prediction sets containing the item prediction entries, the total number of dashes of a sales order line in a prediction set cannot be greater than the planned number of shipments of this order line. The same requirement category is prioritized. After the planned sales order is placed, the prediction offset process will first offset the prediction with the same requirement classification. If no prediction of the same requirement category is found in the prediction offset process, it will offset the entries without the requirement category. If no demand category is associated with a sales order, the prediction offset process first attempts to offset the prediction entries associated with the default demand category of the organization, and then offset the entries that have not yet been defined. The predicted demand date must be within the time period greater than (planned order line change date-days of reverse push) and less than (planned order line shipment date + days before push, can be used to match and offset the sales order line. The offset logic assumes that the prediction set FCS contains the prediction FC01 and the Prediction FC02, and the two predictions contain the same item. The following is the idea of matching the sales order line and the forecast item when the prediction is executed: sort the sales order line to be offset from small to large according to the planned shipping date; sort the prediction entries of item A in the prediction set from small to large by the demand date; find the prediction entries of item, the predicted demand date is the one or more forecast entries closest to the planned shipment date of the sales order line. If there is only one row, this row is used for offset. If there are multiple rows, the values are sorted from small to large in alphabetical order of prediction names, which are offset in turn.