The naive check if (code in tracesList) return PASS; This is the bug almost every homegrown validation contains. It answers "does this number appear somewhere on a list" when the actual requirement is "is this facility currently approved ...
The naive check
if (code in tracesList) return PASS;
This is the bug almost every homegrown validation contains. It answers "does this number appear somewhere on a list" when the actual requirement is "is this facility currently approved for the activity that matches the goods I am importing".
Why the difference bites
TRACES NT publishes establishments by country and by activity type. Meat products, fish and seafood, dairy, eggs, animal fats and oils, animal by-products. A facility approved for dairy is not approved for meat products. A cold store listing does not imply processing approval.
So a code can be genuinely present, genuinely current, and still wrong for your consignment. The explanation of approved establishment requirements covers how those activity sections are organised.
The corrected check
match = tracesList.find(e =>
e.code === code &&
e.country === exportCountry &&
e.activity === requiredActivity &&
e.status === 'listed'
);
nameMatches(match, supplier) ? PASS : FLAG;
Four conditions plus a name and address match, not one.
Mapping goods to activity
Rough guide by HS chapter: meat in 2 and 16, fish in 3 and 16, dairy and eggs in 4, animal fats and oils in 15, animal by-products in 5 and 23. Composite products containing processed animal ingredients still need approval evidence, which is the case teams most often miss.
Fail loudly
A validation that returns PASS on partial matches is worse than no validation, because it manufactures confidence. Flag, do not assume.
Watch a demo