Как проверить интеграцию сайта с 1С перед запуском: 18 сценариев приёмки
Чек-лист приёмки обмена сайта с 1С: товары, предложения, цены, остатки, заказы, повторные пакеты, сбои и контроль времени синхронизации.
В этой статье
Успешная первая выгрузка ещё не доказывает, что интеграция готова к работе. На демонстрации обычно виден удобный сценарий: несколько товаров приехали на сайт, тестовый заказ появился в 1С. В реальном магазине обмен сталкивается с нулевыми остатками, повторными пакетами, изменёнными заказами и обрывами связи.
Приёмку лучше проводить по заранее подготовленному набору сценариев. Ниже — основа такого набора для интернет-магазина, в том числе на «1С-Битрикс: Управление сайтом».
Подготовьте безопасный контур
Испытания не стоит начинать на боевом каталоге. Нужны тестовая копия сайта или отдельный каталог, тестовая база либо выделенный узел обмена в 1С и контрольные учётные записи.
Перед первым прогоном сохраните состояние: количество товаров и предложений, несколько контрольных цен и остатков, список заказов, время последнего обмена. Сделайте резервную копию и убедитесь, что её можно восстановить. Это позволит отличить последствия теста от прежних ошибок данных.
Для каждого сценария запишите четыре вещи: входные данные, действие, ожидаемый результат и фактическое время появления изменений. Проверка «визуально всё нормально» не оставляет материала для диагностики.
Каталог и торговые предложения
Создание простого товара. Добавьте в 1С новый товар с уникальным внешним идентификатором. Проверьте название, артикул, категорию, единицу измерения, ставку НДС и активность на сайте.
Изменение существующего товара. Поменяйте несколько полей, не затрагивая идентификатор. На сайте должен обновиться прежний объект, а не появиться новый.
Товар с вариантами. Создайте комбинации цвета и размера. Проверьте, что свойства попали в торговые предложения, а карточка не распалась на независимые товары.
Новое значение свойства. Передайте значение, которого раньше не было на сайте. Ожидаемый результат зависит от проекта: значение либо создаётся по правилу, либо отклоняется с понятной записью в журнале.
Перемещение между разделами. Смените группу товара в 1С. Убедитесь, что старая привязка снимается, если множественное размещение не предусмотрено.
Деактивация или удаление. Пометьте товар на удаление либо исключите его из выгрузки. Проверьте согласованное действие: скрытие, перевод в архив или сохранение без остатка. Физическое удаление карточки обычно требует отдельного решения, потому что оно затрагивает адрес и историю заказа.
Цены, остатки и изображения
Несколько типов цен. Передайте розничную и оптовую цену. Проверьте привязку к группам пользователей и убедитесь, что неизвестный тип цены не заменяет базовый.
Нулевая и отрицательная цена. Система должна выполнить заранее установленное правило, а не случайно открыть бесплатную покупку или оставить устаревшую стоимость.
Остатки по складам. Измените количество на двух складах. Проверьте сумму, региональную доступность и резерв, если они участвуют в расчёте.
Нулевой остаток. Товар должен перейти в ожидаемое состояние: «нет в наличии», доступность под заказ или скрытие. Одновременно проверьте, можно ли положить его в корзину.
Изображения. Замените основное изображение и добавьте дополнительное. Важно проверить не только наличие файлов, но и порядок, удаление устаревших картинок и отсутствие неконтролируемых копий.
Заказы и статусы
Новый заказ. Оформите заказ с зарегистрированным покупателем и гостем. Сверьте товары, количество, цены, скидки, доставку, оплату, контактные данные и комментарий.
Повторная передача. Запустите обмен тем же заказом ещё раз. В 1С не должен появиться второй документ. Это базовая проверка идемпотентности.
Изменение после оформления. Поменяйте адрес, состав или способ доставки разрешённым бизнес-процессом. Проверьте, какая система считается источником и как предотвращается взаимное перезаписывание.
Отмена и возврат. Отмените заказ на разных этапах: до оплаты, после оплаты и после начала комплектации заказа. Ожидаемые документы и статусы будут различаться, поэтому одного общего теста недостаточно.
Обратные статусы. Переведите заказ в 1С по цепочке сборки и отгрузки. На сайте должны появиться только согласованные статусы, а покупатель не должен получать преждевременное уведомление.
Устойчивость обмена
Обрыв в середине пакета. Ограничьте соединение или остановите обработку на части данных в тестовом контуре. После возобновления уже принятые объекты не должны дублироваться. Потерянные данные нельзя молча пропускать.
Боевой объём. Проведите обмен на объёме, близком к реальному: полный каталог, затем обычная порция изменений. Зафиксируйте продолжительность, нагрузку на сайт и 1С, размер пакетов и время восстановления после ошибки.
Что смотреть в журнале
Для каждого запуска журнал должен показывать начало и конец, направление, идентификатор пакета, число обработанных объектов и ошибки. Полезно отдельно видеть количество созданных, обновлённых и пропущенных записей.
Запись «ошибка импорта» не помогает. Нужны тип объекта, его идентификатор, этап обработки и причина. При этом в журнал не следует помещать пароли, ключи и лишние персональные данные.
Проверьте также уведомления. Если обмен остановился ночью, ответственный сотрудник должен узнать об этом раньше, чем покупатель обнаружит неправильный остаток.
Когда интеграцию можно принимать
До запуска должны быть выполнены не только функциональные сценарии. Команде нужны понятные показатели: допустимая задержка обновления, время полного обмена, максимальная длина очереди, срок реакции на ошибку и порядок отката.
Результат приёмки — не отметка «работает», а протокол с версиями систем, датой теста, входными данными и фактическими результатами. Незакрытые отклонения делят на блокирующие и допустимые. Тогда запуск становится управляемым решением, а не надеждой на то, что боевые данные поведут себя как пять демонстрационных товаров.
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
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.
Modifying an existing product. Change several fields without touching the identifier. The existing object on the site must update, not a new one appear.
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.
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.
Moving between sections. Change the product group in 1C. Ensure the old binding is removed if multiple placements are not supported.
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
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.
Zero and negative prices. The system must execute a pre-established rule, not accidentally enable free purchases or retain an outdated price.
Stock levels by warehouse. Change the quantity on two warehouses. Verify the total, regional availability, and reservation if they are involved in the calculation.
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.
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
New Order. Create an order for both a registered customer and a guest. Verify products, quantities, prices, discounts, delivery, payment, contact details, and comments.
Re-transmission. Run the exchange with the same order again. A second document must not appear in 1C. This is a basic idempotency check.
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.
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.
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
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.
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.
Обсуждение 0
Делись опытом и задавай вопросы. Комментарии без ссылок появляются после проверки редактором.
Пока никто не написал. Начни обсуждение.