Summary: Shipment numbers are only locked once a batch finishes processing. If you import a second batch with the same numbers while the first one is still running, the rows import with no warning and the duplicates can ship. Let each batch finish before you import another that could share numbers.
Problem
A batch file with shipment numbers that are already in use imports anyway, and you end up with duplicates that can ship. Nothing on screen tells you it happened. It used to be that those rows would not import at all.
Cause
The duplicate check looks at shipment numbers that are fully committed. While a batch is still processing, its numbers are not committed yet, so a second batch with the same numbers does not see them as used and imports them.
Once a batch has fully processed, its numbers are locked and cannot be shipped again. That is why the same file behaves differently depending on when you import it.
How to check: look at the batch you imported just before this one. If it had not finished processing, that is the cause.
Fix
- Let each batch finish processing all the way through before you import another file that could use the same shipment numbers.
- Check the batch has fully processed, not just imported, before you send the next one.
- Map a unique Order Number for every row in your file, so each record can still be told apart when shipment numbers overlap.
- If duplicates already imported, void the duplicate shipments before they ship.
- If you cannot tell which shipments are the duplicates, email support@shipstore.com with the batch numbers and the shipment numbers you are worried about.
What you should see
A shipment number from a batch that has fully processed is turned down as a duplicate on the next import, and batches you send one after another stop bringing in duplicates.
Related articles
- Give each batch record a unique Order Number
- Batch import fails on a large file or reused shipment numbers
- Batch stays In Process and never rates or ships