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 readViews1

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

Website-to-1C Exchange Acceptance Checklist: Products, Product Variants, Prices, Stock Levels, Orders, Repeated Packages, Failures, and Synchronization Time Control.

АльбинаCommunity author★ 141
Comments 0

Checking Product Samples and Orders Next to a Laptop
In this article

A successful initial export does not prove that the integration is ready for production. Demonstrations 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 encounters zero stock levels, repeated packages, modified orders, and connection interruptions.

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

Prepare a Safe 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 1C exchange node, along with control user accounts.

Before the first run, save the current state: the number of products and product variants, 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 allows you to distinguish the consequences of the test from previous data errors.

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

Catalog and product variants

  1. Creating a simple product. Add a new product in 1C with a unique external identifier. 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 update, not a new one appear.

  3. Product with variants. Create color and size combinations. Verify that properties are reflected in the product variants and the card does not split into independent products.

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

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

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

Prices, stock levels, and images

  1. Multiple price types. Submit retail and wholesale prices. Verify the binding 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-established rule, not accidentally enable free purchases or retain an outdated price.

  3. Stock levels by warehouse. Change the quantity on two warehouses. Verify the total, regional availability, and reservation if they are involved in the calculation.

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

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

Orders and statuses

  1. New Order. Create an order for both a registered customer and a guest. Verify products, quantities, prices, discounts, delivery, payment, contact details, and comments.

  2. Re-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 Placement. Modify the address, composition, or delivery method using an allowed business process. Verify which system is considered the source and how mutual overwriting is prevented.

  4. Cancellation and Return. Cancel the order at different stages: before payment, after payment, and after order picking has begun. Expected documents and statuses will differ, so a single general test is insufficient.

  5. Reverse Statuses. Transition the order to 1C through the assembly and shipping chain. Only approved statuses should appear on the site, and the customer must not receive premature notifications.

Exchange resilience

  1. Mid-Package Interruption. Limit the connection or stop processing partway through the data in the test environment. Once resumed, already accepted objects must not be duplicated. Lost data must not be silently skipped.

  2. Test volume. Perform the exchange on a volume close to real-world conditions: a full catalog first, then a standard batch of changes. Record the duration, site load, 1C load, package sizes, and recovery time after an error.

What to look for in the log

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

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

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

When the integration can be accepted

Before launch, not only functional scenarios must be completed. The team needs clear metrics: acceptable update latency, total exchange time, maximum queue length, error response time, and rollback procedure.

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

GENERAL IT

Help with your project

GENERAL IT

Read more on this topic

Discussion 0

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

No comments yet. Start the discussion.