How does the system select a ShipNode during order scheduling if the destination zip code/postal code is not available in the YFS_ZIP_CODE_LOCATION table?

Answer

When an order is scheduled and the destination zip code or postal code is missing from the YFS_ZIP_CODE_LOCATION table, the system handles ShipNode selection based on the configured sourcing rule parameters, specifically around "Distance Prioritization" and "Priority-Based Optimization."

1. Distance Prioritization:

   • If the "Consider distance between ship-to and ship-from location for prioritization" flag is enabled in the sourcing rule, the system typically considers both "weightage for distance" and "weightage for ship node" when selecting the optimal ShipNode.
   • Impact of Missing Zip Code: If the postal code for a node (which implies the destination postal code is also used in the calculation, or the node's own postal code is used for distance calculation from the destination) is not available, the distance factor for that node will be considered as zero. This occurs regardless of the "weightage for distance" setting.
   • Result: In such cases, the node priority will be determined solely based on the "weightage given to the node" in the sourcing rule, as the distance component becomes negligible (zero).

2. Priority-Based Optimization:

   • If node selection is optimized based on "Priority," the system calculates the node priority using a formula that typically includes distance: $(WeightFactorfordistance\times distanceinmilesascalculatedbasedonlongitudeandlatitude)+(WeightFactorforpriority\times prioritysetupinthedistributionnodegroup.)$
   • Impact of Missing Zip Code: Since the distance calculation in this formula relies on zip code information (to derive longitude and latitude), if the destination zip code is not available in YFS_ZIP_CODE_LOCATION, the distance factor will be zero.
   • Result: Consequently, the node priority will be determined primarily by the "priority setup" in the distribution node group. The distance component, being zero, will not influence the prioritization.

Note: The product does not inherently throw an error if the Zip code/Postal code is not available in the YFS_ZIP_CODE_LOCATION table during order scheduling. However, users can implement custom logic to address this scenario. This can be achieved by:

• Implementing a User Exit: A user exit such as checkOrderBeforeProcessingUE can be utilized. Within this user exit, an API call or custom logic can be added to verify if the destination zip code from the order line exists in the YFS_ZIP_CODE_LOCATION table. If the entry is not found, the user exit can be configured to throw a custom error, preventing further processing or flagging the order for manual intervention.

This approach ensures that while the system can still process orders without complete zip code data, businesses have the flexibility to enforce data completeness and accuracy as per their operational requirements.