Payments are experiencing issues due to temporary restrictions in Russia. If your payment does not go through, please submit a support request.Our support team is available 24/7 — we are always here to help with hosting and server issues.We are now accepting requests for dedicated server rental and colocation services in our data center.Reminder: we recommend enabling backups for additional data protection.A new VPS/VDS lineup with NVMe storage and improved performance is now available.Maintenance work on some servers has been completed. All services are operating normally.
Article8 min readViews0

Catalog Acceptance After Import: How Many Cards to Check and How Long It Takes

A training model helps assemble a risk-oriented sample after catalog import, calculate labor effort, and determine when a single found error requires searching the entire product group.

Comments 0

Catalog acceptance workstation with products, scanner, and magnifying glass
In this article

After importing a catalog, you do not need to manually open all 10,000 cards. For managed acceptance, a risk-oriented sample is needed: mandatory edge cases, several typical cards from each homogeneous group, and re-verification after fixes. In the training example, this amounts to 78 checks and 8.7 hours of work. There is no universal number: the volume depends on the number of import rules and the cost of a missed error.

This approach does not provide statistical guarantees and is not equivalent to a full check. Its goal is to confirm the main data transformation rules within a reasonable time, identify systemic failures, and determine in advance when the sample must be expanded.

First, divide the catalog into homogeneous groups

A random 1% of the catalog looks convincing only until the first rare combination. If the sample misses product variants, multiple prices, or a product without an image, a critical import rule may go entirely untested. Therefore, the planning unit is not the entire catalog, but a group of cards with the same source and the same transformation.

Groups can be defined by product type, data source, property set, catalog section, or a specific processing rule. Below is a sample set, not a mandatory template for any system.

Group

What distinguishes the data

What to confirm

Simple product

One card without variants

Name, category, price, stock, status

Product with variants

Product variants exist

Link between the variant and the product, variant properties, prices, and stock levels

Multiple price types

Price depends on the buyer group

Mapping of price type and currency

Multiple warehouses

Stock levels come from different sources

Summed or stored separately according to the specified rule

New section

Section created via import

Parent section, code, and card availability

Card without an image

Image missing in source

Import did not substitute an image from another product and did not hide the card without a separate rule

Inactive product

Product removed from sale

Status after import and behavior on the storefront

Re-import

Identifier already exists

Update the correct product card without creating a duplicate

Preparing data before migration is a separate task. The article about a catalog with 10,000 products explains how to evaluate the cleaning and normalization of source data. Here we consider the next stage: acceptance testing of the result after the import has occurred.

Assemble a sample using an open formula

Let's calculate a sample for a catalog with 10,000 cards. Assume the team has defined eight groups with different processing rules. For each group, we take six standard cards, add 18 mandatory edge cases separately, and reserve 12 cards for re-verification after fixes.

Number of checks = mandatory cases + groups × standard cards per group + re-verification checks.

18 + 8 × 6 + 12 = 78 checks.

Sample: 18 mandatory cases, 8 groups of 6 cards each, and 12 re-verification checks, totaling 78.
Sample model: 18 mandatory cases + 48 standard cards + 12 re-verification checks = 78.

The number six in this model is not an industry standard. It changes with risk. If rules are simple and uniform, fewer cards may be needed. If a group combines different sources, suppliers, or property entry methods, it is better to split it rather than mask heterogeneity with a large average number.

What to include in mandatory edge cases

  • a product with minimum and maximum prices, as well as with a zero price, if such a scenario is allowed;

  • zero, small, and large stock levels;

  • a card without an image and a card with multiple images;

  • the longest name and property values at the boundary of the allowed format;

  • inactive products and products missing from the new file;

  • products with multiple variants, prices, or warehouses;

  • re-importing an already existing identifier;

  • a card that must change its section or another managed field.

The list is built based on the actual rules of a specific import. If the store does not use multiple warehouses, there is no need to check them for the sake of appearance. If prices come from three sources, a single price example is no longer sufficient.

Calculate effort separately from catalog size

For the training calculation, we allocate four minutes per card check. This time includes opening the card, comparing pre-defined fields, and recording the result. Another 90 minutes are needed for aggregate checks, and 120 minutes are reserved for resolving deviations, agreeing on fixes, and re-importing if necessary.

Work

Calculation

Time

Verification of 78 product cards

78 × 4 minutes

312 minutes, or 5.2 hours

Aggregated reconciliations

Fixed block

90 minutes, or 1.5 hours

Analysis of deviations and coordination

Training model reserve

120 minutes, or 2 hours

Total

312 + 90 + 120 minutes

522 minutes, or 8.7 hours

For comparison: a full check of 10,000 cards at the same four minutes per card would take 40,000 minutes, or approximately 666.7 hours. This is not an argument that a sample is better. A full check has broader coverage, but it requires a completely different budget.

Effort comparison: about 667 hours for a full check and 8.7 hours for a risk-oriented training sample
Two different coverage volumes: full check ≈ 667 hours, training risk-oriented model — 8.7 hours.

If an actual card check takes seven minutes instead of four, the formula must be recalculated. With 78 card checks, the variable portion will increase from 5.2 to 9.1 hours, and the total budget will rise to 12.6 hours. Therefore, it is useful to first time five to ten cards, and only then approve the estimate.

Perform aggregate reconciliations before manual sampling

Card previews show how results appear to buyers but often miss mass omissions. Before manual verification, generate a report for the entire catalog and compare it against expected control figures.

  • total number of products and variants before and after import;

  • number of active and inactive cards;

  • number of cards missing a required identifier, name, price, or category;

  • duplicate identifiers and unexpected new identifiers;

  • distribution of cards by section;

  • cards with zero price, negative or unexpectedly large stock;

  • number of items without an image and number of broken links between an item and its variant;

  • items missing from the new file and the action the system took on them.

For CSV import into 1C-Bitrix, file fields are mapped to infoblock fields, and the XML_ID or name is used to search for an existing record. The documentation also specifies the action for items not present in the new file: keep, deactivate, or delete. Therefore, the field map, the mapping key, and the rule for missing items must be fixed before acceptance testing. This is documented behavior, not the result of testing a specific store; see the official CSV import instructions.

The first error changes the scope of verification

Acceptance testing loses meaning if a detected deviation is simply recorded and the count of successful cards continues. First, determine the nature of the error: are the individual data points corrupted in the source, or is the transformation rule malfunctioning?

Observation

Hypothesis

Next action

One product received an incorrect category

Source line error or category mapping rule error

Check the source, then check another 3–5 products with the same category

All variants lost their price

System error in the field map or price type

Stop acceptance testing for the group, fix the rule, repeat the import and selection

A duplicate appeared after the second import

Incorrect mapping key

Stop acceptance, verify identifiers across the entire affected group

A product became inactive that is not in the file

A pre-selected rule for missing products triggered

Verify the expected action; this is an error only if it deviates from the task

One card has a broken image

File or path error

Check the source and expand the selection for the same supplier or import rule

For a deterministic rule, a single confirmed error is sufficient to reject the affected group. After fixing the issue, repeat the import in a safe environment or agreed-upon window, re-run the aggregate reconciliation, and verify the original cards plus several new ones. Do not average out a systemic error with successful examples.

Document the protocol to ensure the repeat is comparable

  1. Record the file version, import date, source, and applied field mapping.

  2. For each group, list the selected identifiers and the reason for inclusion in the sample.

  3. Set expected values before opening the cards: section, activity, price, stock, variant, image.

  4. Save the actual result and proof without personal data and secrets.

  5. For each error found, specify the violated rule, the fix owner, and the decision on expanding the sample.

  6. After fixing, repeat the aggregate checks, the original failed tests, and new cards from the same group.

  7. Accept the group only after the expected and actual results match.

General acceptance of an online store covers not only the catalog but also checkout, payment, delivery, notifications, and rights. The sequence for general acceptance is detailed in a separate article «Online store acceptance after demonstration». This article provides a different result: the calculated scope of testing specifically for the imported catalog and the stop rule in case of a system error.

What constitutes a result

The result of acceptance testing is not the phrase 'checked 78 cards,' but a protocol: which rules were covered, which aggregate figures matched, where the sampling expanded, and what was re-verified after fixes. For a training catalog, the model suggests an estimate of 8.7 hours, but the actual budget is approved only after a pilot time measurement and splitting the data into actual groups.

If the cost of an error is high—for example, an incorrect price is immediately sent to the buyer—increase not the cosmetic sampling percentage, but the control of the specific rule: automatic validation of the entire array, blocking publication upon deviation, and a repeated manual check of the affected group. This keeps the estimate transparent, and the decision to launch relies on verifiable conditions.

Discussion 0

Share your experience and ask questions. Comments without links appear after editorial review.

No comments yet. Start the discussion.