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.
Article5 min readViews0

How to Verify Website Integration with 1C Before Launch: 18 Acceptance Scenarios

Acceptance checklist for website–1C exchange: products, offers, prices, stock levels, orders, repeated batches, failures, and synchronization time monitoring.

АльбинаCommunity author★ 73Discuss0
Testing the online store exchange with 1C on a local machine
In this article

A successful initial export does not prove that the integration is ready for production. Demos typically show a convenient scenario: a few products arrive on the site, and a test order appears in 1C. In a real store, the exchange faces zero stock levels, repeated batches, modified orders, and connection drops.

Acceptance testing should be conducted using a pre-prepared set of scenarios. Below is the foundation for such a set for an online store, including those built on 1C-Bitrix: Site Management.

Prepare a secure environment

Do not start testing on a live catalog. You need a test copy of the site or a separate catalog, a test database, or a dedicated exchange node in 1C, along with control user accounts.

Before the first run, save the current state: the number of products and offers, several control prices and stock levels, the order list, and the time of the last exchange. Create a backup and verify that it can be restored. This will help distinguish test consequences from pre-existing data errors.

For each scenario, record four items: input data, action, expected result, and actual time of change appearance. A check like 'visually everything is fine' provides no material for diagnostics.

Catalog and commercial offers

  1. Creating a simple product. Add a new product with a unique external identifier in 1C. Verify the name, article number, category, unit of measure, VAT rate, and site activity.

  2. Modifying an existing product. Change several fields without touching the identifier. The existing object on the site must be updated, not replaced by a new one.

  3. Product with variants. Create color and size combinations. Verify that properties are transferred to commercial offers and the card does not split into independent products.

  4. New property value. Transmit a value that did not previously exist on the site. The expected result depends on the project: the value is either created according to a rule or rejected with a clear entry in the log.

  5. Moving between sections. Change the product group in 1C. Ensure the old binding is removed if multiple placements are not configured.

  6. Deactivation or deletion. Mark the product for deletion or exclude it from the export. Verify consistent action: hiding, moving to archive, or saving without stock. Physical deletion of the card usually requires a separate solution because it affects the URL and order history.

Prices, Stock Levels, and Images

  1. Multiple Price Types. Submit both retail and wholesale prices. Verify the linkage to user groups and ensure that an unknown price type does not replace the base price.

  2. Zero and Negative Prices. The system must execute a pre-set rule rather than randomly enabling free purchases or retaining outdated pricing.

  3. Warehouse Stock Levels. Change quantities on two warehouses. Verify the total, regional availability, and reserves if they are part of the calculation.

  4. Zero Stock. The product must transition to an expected state: out of stock, available for order, or hidden. Simultaneously verify whether it can be added to the cart.

  5. Images. Replace the main image and add an additional one. It is critical to check not only the presence of files but also the order, removal of outdated images, and the absence of uncontrolled copies.

Orders and Statuses

  1. New Order. Place an order with both a registered buyer and a guest. Compare products, quantities, prices, discounts, shipping, payment, contact details, and comments.

  2. Repeated transmission. Run the exchange with the same order again. A second document must not appear in 1C. This is a basic idempotency check.

  3. Changes after order placement. Modify the address, composition, or delivery method using an approved business process. Verify which system is considered the source and how mutual overwriting is prevented.

  4. Cancellation and returns. Cancel the order at different stages: before payment, after payment, and after transfer to picking. Expected documents and statuses will differ, so a single generic test is insufficient.

  5. Reverse statuses. Move the order through the picking and shipping chain in 1C. Only approved statuses should appear on the website, and the buyer must not receive premature notifications.

Exchange robustness

  1. Mid-packet interruption. Limit the connection or halt processing partway through the data in the test environment. After resumption, already accepted objects must not be duplicated, and lost data must be silently skipped.

  2. Production volume. Run the exchange at a volume close to real-world conditions: a full catalog followed by a standard batch of changes. Record duration, site and 1C load, packet sizes, and recovery time after errors.

What to check in the log

For each run, the log must show the start and end times, direction, package ID, number of processed objects, and errors. It is useful to separately track the counts of created, updated, and skipped records.

An "import error" entry is not helpful. You need the object type, its ID, the processing stage, and the cause. However, do not include passwords, keys, or unnecessary personal data in the log.

Also check notifications. If the exchange stops overnight, the responsible employee must learn about it before a customer discovers an incorrect stock level.

When to accept the integration

Before launch, functional scenarios are not enough. The team needs clear metrics: acceptable update latency, total exchange time, maximum queue length, error response time, and the rollback procedure.

The acceptance result is not a "works" checkmark, but a protocol with system versions, test date, input data, and actual results. Unresolved deviations are split into blocking and acceptable. This makes the launch a managed decision, not a hope that production data will behave like five demo items.

GENERAL IT

Help with your project

GENERAL IT

Read more on this topic

Discussion0

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

No comments yet. Start the discussion.