Warehouse transfer import fails when target period is closed in data migration scenario

SCM Epicor SCM
, , , , , , , ,
1

We’re migrating warehouse transfer data from our legacy system to Epicor SCM 10.2.500 and encountering duplicate bin location errors during import. The transfer records reference bin codes that appear to be unique in our source data, but the import process throws validation errors about duplicates.

The error occurs during the bin code uniqueness enforcement step:


ERROR: Duplicate bin location 'A-01-B' in warehouse 'WH-CENTRAL'
Violation of UNIQUE KEY constraint 'UQ_BinLocation_Code'

We’ve verified our source data doesn’t have obvious duplicates. The bin validation logic seems to be checking something beyond simple code matching. Our warehouse go-live is blocked until we resolve this. Has anyone dealt with similar bin location validation issues during data migration? What’s the proper way to handle inventory merge scenarios when bins might exist across multiple source systems?

2

Another common cause is existing inventory transactions that reference bin locations not yet imported. Epicor’s inventory merge logic can create placeholder bins automatically when processing transfer records, and then your explicit bin import hits those auto-created records. Check the PartBin table for any records created before your bin master import. You might need to sequence your imports: bins first, then inventory balances, then transfer history. This ensures the merge logic has proper bin references to work with.

3

Good point on case sensitivity. I ran a case-insensitive duplicate check and found 14 instances where bins differ only by case. However, we still get errors on bins that are definitely unique even with case-insensitive comparison. Could this be related to how the pre-import data validation handles warehouse hierarchies? Our legacy system had location groups that might be conflicting with Epicor’s structure.

4

Exactly right - you’ve identified the root cause. Here’s the proper sequence that addresses all three validation concerns:

1. Bin Code Uniqueness Enforcement: First, clean your source data with case-insensitive duplicate detection:

SELECT WarehouseCode, UPPER(BinCode), COUNT(*)
FROM StagingBins
GROUP BY WarehouseCode, UPPER(BinCode)
HAVING COUNT(*) > 1

Resolve any duplicates by appending location suffixes.

2. Pre-Import Data Validation: Import in this strict order:

  • Warehouse master (parent locations first, then child)
  • Bin location master (validates against warehouse structure)
  • Part master
  • Inventory on-hand balances (creates PartBin records)
  • Transfer history (references existing bins)

3. Inventory Merge Logic: For bins that exist in multiple source systems, implement a merge strategy:

UPDATE StagingBins
SET BinCode = SourceSystem + '-' + BinCode
WHERE SourceSystem IN ('LEGACY_A', 'LEGACY_B')

Before running your full import, execute this validation script:

-- Verify no auto-created bins exist
SELECT * FROM PartBin pb
WHERE NOT EXISTS (
  SELECT 1 FROM BinLocation bl
  WHERE bl.WarehouseCode = pb.WarehouseCode
  AND bl.BinCode = pb.BinNum
)

If any auto-created bins exist, either delete them (if no transactions posted) or update your staging data to match the auto-created bin codes. The key is ensuring bin master import happens before ANY transaction imports that might reference bins. This prevents the automatic bin creation that’s causing your uniqueness violations.

Also enable verbose logging in your import tool to catch warehouse hierarchy conflicts early - bins must respect the parent-child location structure or you’ll get constraint violations even if codes are unique.

5

The warehouse hierarchy is likely your issue. Epicor validates bin codes across the entire warehouse structure, including parent-child relationships. If you have bins in sub-locations that share codes with the parent warehouse level, you’ll hit this constraint. I recommend running a query to identify all bin codes grouped by warehouse and checking for any that appear in multiple location levels. You might need to prefix bins with their location identifier during import to maintain uniqueness.

6

That’s interesting about the auto-created bins. I found 23 bin records in PartBin that don’t exist in our BinLocation master table. They were created with today’s timestamp, which matches when we started testing transfer imports. So the transfer import is creating bins on-the-fly, then our bin master import fails because they already exist. What’s the recommended import sequence to avoid this?