Reviewing Important Implementation and End-User Guidelines

When integrating two software systems, it is important to understand and work with the differences of the two systems to maximize the integration success. This is most notably due to subtle functional differences between the two systems.

Here are some important guidelines to help with the integration:

• Determine transaction size, volume, and frequency.

  The typical size and volume of the change orders determines how often and how much to process through the PeopleSoft within a single PDX file. Care should be taken to reduce the chance of extremely large files (files over 8 megabytes not recommended). PeopleSoft recommends sending more PDX files with smaller numbers of change orders more frequently rather than very large files containing volumes of changes with less frequency.

  Schedule the PDX Daemon (PDXDMON) within PeopleSoft to compliment the typical flow of change orders being sent.

  For example, if you typically have 6 to 10 change orders released each hour (interval), you should schedule the PDXDMON to look for new change orders more frequently (such as wake up perhaps every 5 minutes so a maximum of 20 change orders per hour could be processed). Again, if you want to process changes more quickly, you can schedule the Daemon to look more frequently for new packages.

• Avoid the redo and resend markup pitfall.

  Once a change order has been processed and sent to PeopleSoft, it is highly recommended that you never back out and unrelease a change order in the PLM, change the BOM markup data, and then resend it to PeopleSoft. This will frequently cause unpredictable integration errors and BOM synchronization problems, because PeopleSoft has already successfully processed each of the original released markups for the initial change order.

• Define field lengths and required fields in the PLM.

  This is critical to the reliability of the integration to ensure that all PeopleSoft required fields have valid values, and that these values have the correct lengths for PeopleSoft. If they do not, transaction errors occur on the back end (PeopleSoft side) of the integration.

• Use caution regarding processing multiple revisions for an item in one day.

  The PeopleSoft Manufacturing revision scheme supports only one revision per day. Some environments may require that multiple revisions be released for the same item in one day. If this occurs in the environment, note that by default only the latest revision number can be tracked within PeopleSoft for that day. Furthermore, all the revision changes for a BOM are combined with the latest revision for the day. For example:

  • Revision A on 6/1/2003, 9 am: Adds component XYZ-1 to BOM 123

  • Revision B on 6/1/2003, 10 am: Adds component XYZ-2 to BOM 123

  • Revision C on 6/1/2003, 1 pm: Adds component XYZ-3 to BOM 123

    Within PeopleSoft Manufacturing, the net effect is revision C showing XYZ-1, XYZ-2, and XYZ-3 added for BOM 123 under revision C.

    If a prior revision (such as revision A or B in the previous example) has already been used within production (on a production ID or production schedule) and a new revision for the same item and effective date is sent, the change order will error out within PeopleSoft (PDX Change Order Exceptions page) as seen in this screenshot. This occurs because when you send multiple revisions during one day, you are overwriting an original revision, for example, the production ID would be left tagged with a revision that no longer exists in the system.

Send multiple revisions each day in an environment where you can anticipate that this is not a problem, because you normally want to pick up the latest revision for existing production IDs created on that day.

In this case, use these PDX exceptions as an alert that the production IDs must be unreleased (blank revision) and allow the newest revision to be assigned to the production ID once the revision is sent to the PeopleSoft system.