We’re migrating supply planning data to CloudSuite ICS 2022 and encountering database constraint violations during import. The Supply Plan Import tool fails with: “Foreign key constraint violation - supplier code ‘SUPP-2847’ does not exist in supplier master table”.
Our legacy planning system contains 6 months of supply plan history with approximately 25,000 planned orders referencing various suppliers. The issue is that not all suppliers from our legacy system were migrated to CloudSuite - we rationalized our supplier base and consolidated several vendors during the implementation.
The supply plan records reference these obsolete supplier codes, causing referential integrity enforcement failures. We can’t simply update the supplier codes in the supply plan data because the original supplier assignments were made for specific reasons (pricing, lead times, quality ratings) that don’t directly translate to the consolidated suppliers.
This is creating supply chain disruption because our planners can’t see historical planning patterns and supplier performance data. The legacy supplier mapping to new CloudSuite suppliers isn’t one-to-one, and we’re unsure how to handle supply plans that reference suppliers that no longer exist in the system. Do we need to import all legacy suppliers just to preserve planning history, or is there a better approach?
From a procurement perspective, you need that historical supplier data for contract negotiations and performance reviews. When we consolidated suppliers, we maintained the legacy supplier codes in CloudSuite specifically to preserve this history.
The key is marking them clearly as legacy/inactive so they don’t pollute current operations. But trying to rewrite history by mapping everything to current suppliers creates more problems than it solves. The supply chain disruption you’re experiencing is exactly because planners can’t access historical patterns - fix that by importing the legacy suppliers.
We went through similar supplier consolidation during our ICS 2022 implementation. Our approach was to import ALL legacy suppliers (even obsolete ones) but mark them as INACTIVE with a “DO NOT USE - LEGACY” flag in the supplier name.
This satisfied the referential integrity constraints and preserved the historical supply plan context. Planners could see the original supplier assignments and understand past planning decisions. The inactive status prevents anyone from accidentally creating new orders with obsolete suppliers. After 12 months, we archived the legacy supplier records.
CloudSuite enforces referential integrity strictly - every supplier code in supply planning data must exist in the supplier master. You have three options: import legacy suppliers as inactive, map legacy suppliers to current suppliers, or filter out supply plans for obsolete suppliers.
For your scenario with supplier rationalization, I’d recommend mapping legacy suppliers to their current equivalents. Create a supplier translation table showing which legacy suppliers were consolidated into which current suppliers, then update your supply plan data before import.
Consider the downstream impact of your decision. Supply planning data feeds into supplier performance metrics, lead time analysis, and demand forecasting models. If you map legacy suppliers incorrectly, these analytics will be skewed.
Document which legacy suppliers map to which current suppliers and why. This mapping becomes critical for interpreting historical planning data. Also check if any supply plans for obsolete suppliers are still open or need to be converted to current suppliers before import.