Purchase Order Loads

Purchase Order data does not support loading of historical records, as all usage of PO data is for forward-looking calculations, such as open on-order amounts. However, it is common to need some test data to be loaded prior to nightly batches so that you can validate the purchase order calculations in your Planning solutions during implementation. When loading PO data, make sure you develop the files following the guidance in the data files generation section of this document and in the RAP interfaces guide.

  1. Create the files ORDER_HEAD.csv and ORDER_DETAIL.csv containing a full snapshot of purchase order data for a single date. The DAY_DT value on every record in ORDER_DETAIL.csv must be the same and represent the current business date in RAP at the time the file will be loaded. The load will fail for any other value of DAY_DT besides the current business date, and it will fail if multiple dates are present in the file.

  2. Upload the data files and their context files to Object Storage using the RAP_DATA_HIST.zip file.

  3. Execute the HIST_ZIP_FILE_LOAD_ADHOC process.

  4. Execute the SEED_CSV_W_RTL_PO_ONORD_IT_LC_DY_F_PROCESS_ADHOC batch process to load the data. Example Postman message body:

    {
      "cycleName":"Adhoc", "flowName":"Adhoc",
      "processName":"SEED_CSV_W_RTL_PO_ONORD_IT_LC_DY_F_PROCESS_ADHOC"
    }

Purchase Order data functions similar to inventory in that it is a positional fact interface and cannot be loaded or reloaded multiple times for the same dates. If you load some data for a given business date and need to change or erase it, you must truncate the tables using support utilities and then load the new data. You also cannot load the data out of order. Once you load data for one date, you may only load new files for future dates after that point. The data warehouse target tables for this data are W_RTL_PO_DETAILS_D (for the ORER_HEAD.csv file) and W_RTL_PO_ONORD_IT_LC_DY_F (for the ORDER_DETAIL.csv file).

Prior to starting nightly loads of PO data, you must also choose your configuration option for the parameter PO_FULL_LOAD_IND in the C_ODI_PARAM_VW configuration table in Manage System Configurations. By default, this parameter is set to N, which means that the nightly interface expects to get all delta/incremental updates to your existing PO data each night. This delta includes zero balance records for when a PO is received in the source and moves to zero units on order. If tracking and sending deltas is not possible, you may change this parameter to Y, which indicates that your nightly file will be a full snapshot of open order records instead. The system will automatically zero out any purchase order lines that are not included in your nightly file, which allows you to extract only the non-zero lines in your source data.

You must also choose the configuration option for the parameter PDS_EXPORT_DAILY_ONORD, which determines whether the EOW_DATE used in the export data is allowed to contain non-end-of-week (EOW) dates, or if the system must convert it to a week-ending date in all cases. When set to a value of Y, it means daily dates are allowed in the EOW_DATE field on the export, if there is a daily date in the OTB_EOW_DATE column of ORDER_HEAD.csv. When set to a value of N, it means the system automatically converts the input dates from ORDER_HEAD.csv to be week-ending dates in all cases. For a base implementation of MFP with no customizations, you may want this setting to be N to force the export dates to be EOW dates even if the input file has non-EOW dates from the source. If you are altering RPAS to have a different base calendar intersection, then you may want to change this to Y instead to allow daily dates.