Duplicates and Validation
How the app decides whether an article is already known – and how to avoid false positives.
Last updated
⌘Ctrlk
How the app decides whether an article is already known – and how to avoid false positives.
A duplicate exists when an imported article corresponds to one you already have. That is the normal case for every catalogue refresh – the supplier delivers the same articles with new prices.
The app checks each article against three areas:
Articles within the same file
always – catches conflicts inside the delivery itself
Existing items in Business Central
always
Not yet synchronised staging data from other sessions
only when Check Pending Staging for Duplicates is on
DATANORM Article No.
The supplier's article number
Default case. The supplier assigns stable numbers.
EAN/GTIN
Barcode; the item's GTIN field is checked as well
You carry articles from several suppliers and want to unify them by barcode.
Vendor Item No.
Vendor item number; item-vendor entries are evaluated as well
You already maintain supplier numbers in Business Central.
The field is set through Duplicate Match Field in Base Configuration.
DATANORM article numbers are only unique within a given supplier. Two suppliers may use the same number for different articles.
With Match Duplicates per Vendor enabled, the app only compares within the same vendor, so articles from different suppliers no longer overwrite each other.
This setting is on by default. Only turn it off if you deliberately want to unify articles across all suppliers.
A DATANORM 4 article consists of two lines sharing the same article number: the A record and the B record. Checked naively, the second line looks like a duplicate of the first.
The app merges both lines into one staging record and counts in Merged Source Records how many file lines went in. A value of 2 is the normal case for DATANORM 4 and not a sign of trouble.
If an import reports a suspicious number of duplicates, check these two things first:
Was the same file read in twice by accident? Then the reports are correct.
Is Check Pending Staging for Duplicates on while an older session is still unsynchronised? Then its records show up as matches.
Skip
Known articles are ignored. Only new ones get through.
Update
Existing items are overwritten with the new data. For regular catalogue refreshes.
Create New
A new item is always created. Produces duplicates quickly – use deliberately.
Mark for Manual Review
Every match waits for your decision. The safest setting, especially at the start.
For very large files the check can be switched off entirely with Skip Duplicate Check, which speeds up the import considerably.
Without the duplicate check, importing the same file a second time creates duplicate items. Only use the option for a controlled initial import into an empty environment.
Besides duplicate detection, the app checks while reading:
Record structure – lines whose layout does not match the record type are logged and skipped rather than aborting the import.
Completeness – the end record confirms that the file is complete.
Mandatory values – an article without an article number cannot be processed.
Deletion flag – articles flagged as deleted are handled according to the Delete Flag Handling setting: mark for review, block the item, or end-date the price.
Last updated