Веб

Битрикс импорт заказов: миграция JSON с измененными инфоблоками

Как корректно импортировать заказы в 1С-Битрикс с нового сайта при измененных инфоблоках и свойствах. Маппинг пользователей, трансформация JSON, инструменты Protobyte, Sprint.Migration, тестирование и типичные проблемы миграции.

1 ответ• 1 просмотр

Как корректно импортировать заказы со старого сайта на новый, если на новом изменены инфоблоки и добавлены новые свойства (экспорт/импорт через JSON)?

Описание:

  • Есть старый рабочий сайт и новый сайт, сделанный по бэкапу старого.
  • Нельзя просто перенести базу данных: на новом сайте отличаются инфоблоки и добавлены дополнительные свойства.
  • Был написан скрипт, который экспортировал пользователей и заказы в JSON.
  • При загрузке на новом сайте нарушаются соответствия: меняются ID пользователей, e‑mail и привязки заказов к пользователям.

Требуется:

  • Перенести заказы, сохранив связь «заказ → пользователь» и избежать дублей пользователей.
  • Корректно сопоставить поля и свойства заказов/инфоблоков.
  • Сохранить статусы, даты, позиции, суммы, способы оплаты/доставки и другие метаданные.

Вопросы:

  1. Какие практичные подходы и алгоритмы вы рекомендуете для маппинга пользователей и заказов (сопоставление по e‑mail, маппинг ID, создание новых пользователей и т.д.)?
  2. Как лучше подготовить и трансформировать JSON перед импортом (примерный алгоритм или псевдокод)?
  3. Какие инструменты или готовые модули для импорта вы посоветуете? Как безопасно тестировать импорт и откатывать изменения?
  4. На какие типичные проблемы при такой миграции (например, различия в инфоблоках, дополнительные свойства, ссылки на товары) стоит обратить внимание?

Прилагаю файлы экспорта и импорта (JSON).

Для корректного битрикс импорт заказов при изменённых инфоблоках и новых свойствах выполните предобработку JSON с явным маппингом полей/свойств и пользователей, затем импортируйте поэтапно: сначала пользователи → затем товары/SKU → затем заказы, сохранив таблицу соответствий старый_id→новый_id (XML_ID или UF_*). При маппинге пользователей используйте приоритет: e‑mail (нормализация) → телефон (цифры) → внешний/старый ID; если совпадений нет — создавайте пользователя и фиксируйте соответствие в mapping-файле. Такой подход предотвращает дубли пользователей и позволяет сохранить статусы, даты, позиции, суммы и способы оплаты/доставки.

Содержание

Битрикс импорт: стратегия и общий алгоритм

Коротко: сначала понять различия в структурах, затем написать трансформер JSON (маппинг полей), выполнить импорт в несколько проходов и вести лог/таблицу соответствий. Порядок операций обычно такой:

  • Инвентаризация

  • Соберите схему старого экспорта: какие поля в заказах, какие свойства инфоблоков, формат позиций (SKU, XML_ID), платежи/доставки, статусы.

  • Соберите схему нового сайта: коды инфоблоков, коды свойств, типы свойств, обязательные поля, существующие способы оплаты/доставки и статусы.

  • Зафиксируйте отличия в документе mapping (properties_map.json, statuses_map.json, payment_map.json, delivery_map.json, product_map.json).

  • План импорта (рекомендуемая последовательность)

  1. Подготовка тестовой среды — клон нового сайта (БД + файлы).
  2. Импорт/сопоставление пользователей (получить old_user_id → new_user_id).
  3. Убедиться, что товары/SKU доступны или подготовить placeholders (маппинг по XML_ID).
  4. Трансформировать заказы с учётом маппинга полей, статусов, платёжных/доставочных кодов.
  5. Импорт заказов: создавать заказы программно через API Bitrix с явной установкой позиций и цен.
  6. Проверка контрольных выборок и целостности (сравнение сумм, даты, статусов).
  7. Полный импорт после успешного теста.

Полезные инструменты для миграции — модули и руководства. Например, модуль переноса пользователей и заказов на маркетплейсе Битрикс помогает с экспортом/импортом (см. модуль Protobyte) и модуль миграций для скриптовых правок БД (Sprint.Migration): https://marketplace.1c-bitrix.ru/solutions/protobyte.dump/ , https://marketplace.1c-bitrix.ru/solutions/sprint.migration/ . Также полезно ознакомиться с рекомендуемым порядком миграции в официальной документации: https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=43&LESSON_ID=15284&LESSON_PATH=3913.3435.2379.15282.15284

Импорт заказов — маппинг пользователей и ID

Какие алгоритмы маппинга пользователей применять? Вот практический набор правил и их реализация.

  1. Правила сопоставления (в порядке приоритета)
    1. По e‑mail (нормализация: trim, lowercase). Быстро и надёжно.
    1. По телефону (остаются только цифры, сравнение по последним 7–10 цифрам при необходимости).
    1. По внешнему идентификатору (XML_ID, UF_OLD_ID) — если экспорт содержит старые ID, лучше их записать в пользовательское поле на новом сайте.
    1. Фаззи‑сопоставление (имя + адрес, дата регистрации) — только как последний шаг и с ручной проверкой.
  1. Что делать при совпадении e‑mail в новой системе?
  • Если найден пользователь с тем же e‑mail — привязывайте заказ к существующему аккаунту (предпочтительнее). Но проверьте несовпадение адресов/телефонов — логируйте для ручной экспертизы.
  • Если политика проекта не допускает слияния (например, разные юридические лица) — создавайте нового пользователя и модифицируйте e‑mail временно (например, append +import_old) и уведомляйте администраторов для последующей дедупликации.
  1. Стратегия создания новых пользователей
  • При создании нового юзера: запишите оригинальный old_user_id в поле (UF_OLD_ID или отдельное свойство), установите XML_ID или другой уникальный маркер.
  • Пароль: создайте произвольный временный пароль и отправьте пользователю письмо с предложением сброса пароля, либо пометьте как “гостевой” аккаунт.
  • Фиксируйте в mapping-файле: { “old_user_id”: 123, “new_user_id”: 456, “email”: “…” } — этот файл нужен для обратных операций и отката.
  1. Маппинг заказов
  • Устанавливайте заказам внешний идентификатор: ORDER.XML_ID = “old_order_123”. Это даёт идемпотентность: при повторном запуске импорта вы увидите уже импортированный заказ и обновите его, а не создадите дубликат.
  • При импорте используйте mappingUsers[old_user_id] для USER_ID в новом заказе.
  • Если пользователь не найден и создание запрещено — импортируйте заказ в статус «требует проверки» и логируйте.

Пример короткого псевдокода маппинга пользователя (логика):

function findOrCreateUser(oldUser):
 email = normalize(oldUser.email)
 user = findUserByEmail(email)
 if user:
 return user.id
 phone = normalizePhone(oldUser.phone)
 if phone:
 user = findUserByPhone(phone)
 if user: return user.id
 // fallback: создать
 newId = createUser({email: email, phone: phone, name: oldUser.name, UF_OLD_ID: oldUser.id})
 recordMapping(oldUser.id, newId)
 return newId

(Реализуйте с учётом бизнес‑правил и ручной валидации.)

Трансформация JSON перед импортом (псевдокод)

Перед отправкой в API нужно получить «готовый к импорту» JSON, где все поля уже соответствуют новым кодам и типам. Общий алгоритм трансформации:

  1. Загрузить исходный export.json и mapping‑файлы (properties_map, statuses_map, payment_map, delivery_map, product_map).
  2. Нормализовать e‑mail и телефоны.
  3. Подготовить таблицу пользователей: пройти по всем пользователям из экспорта, выполнить findOrCreateUser и записать mappingUsers.
  4. Подготовить таблицу продуктов: сверить по XML_ID / внешнему коду; создать placeholder если продукт отсутствует (или пометить позицию для ручной проверки).
  5. Преобразовать заказы: для каждого заказа заменить старые коды свойств на новые, преобразовать даты в формат Y-m-d H:i:s, заменить статусы/платежи/доставки по map.
  6. Сохранить готовые файлы users_import.json, orders_import.json и mappingFiles.

Ниже — сокращённый PHP‑псевдокод (для понимания логики, не production‑копия):

php
// Загрузка
$export = json_decode(file_get_contents('export.json'), true);
$maps = load_maps(); // statuses_map, properties_map, product_map, etc.
$mappingUsers = [];

foreach($export['users'] as $u){
 $email = mb_strtolower(trim($u['email']));
 $id = findUserByEmail($email);
 if (!$id) {
 $id = createUserInBitrix($u); // создаём и сохраняем UF_OLD_ID => $u['id']
 } else {
 // обновить поля, если нужно
 }
 $mappingUsers[$u['id']] = $id;
}

// Преобразование заказов
$ordersOut = [];
foreach($export['orders'] as $ord){
 $newUserId = $mappingUsers[$ord['user_id']] ?? null;
 if (!$newUserId) {
 // пометка для ручной проверки
 $ord['import_note'] = 'no_user';
 }
 $newOrder = [];
 $newOrder['XML_ID'] = 'old_order_'.$ord['id'];
 $newOrder['USER_ID'] = $newUserId;
 $newOrder['DATE_INSERT'] = date('Y-m-d H:i:s', strtotime($ord['date']));
 $newOrder['STATUS_ID'] = $maps['statuses'][$ord['status']] ?? 'NEW';
 // map properties
 foreach($ord['props'] as $k=>$v){
 $newKey = $maps['properties'][$k] ?? null;
 if ($newKey) $newOrder['PROPS'][$newKey] = transformValue($v);
 }
 // map basket items by product XML_ID
 foreach($ord['items'] as $i){
 $prodId = findProductByXML($i['xml_id']);
 if (!$prodId) { createPlaceholderProduct($i); $prodId = findProductByXML($i['xml_id']); }
 $newOrder['BASKET'][] = [
 'PRODUCT_ID' => $prodId,
 'PRICE' => (float)str_replace(',', '.', $i['price']),
 'QUANTITY' => (float)$i['qty'],
 'PRODUCT_XML_ID' => $i['xml_id']
 ];
 }
 $ordersOut[] = $newOrder;
}

// Сохранить готовый JSON
file_put_contents('orders_import.json', json_encode($ordersOut, JSON_UNESCAPED_UNICODE|JSON_PRETTY_PRINT));

Советы по трансформации:

  • Конвертируйте стоимости в десятичный формат с точкой.
  • Приводите даты к часовому поясу сайта.
  • Для enum‑полей (статусы, способы оплаты/доставки) используйте заранее подготовленные маппинги.
  • Пометьте все созданные сущности (users/orders/products) внешним идентификатором (XML_ID или UF_OLD_ID).

Подробнее о маппинге данных и его практиках можно прочитать в тексте про маппинг: https://apptractor.ru/info/techhype/chto-takoe-mapping-dannyh.html и по работе с JSON в 1С/импорте: https://topkoder.ru/stati/json-chtenie-import-preobrazovanie-v-sisteme-programmy-1s/

Инструменты и модули для импорта в Битрикс

Рекомендованные инструменты (из анализа и практики):

Когда использовать модуль, а когда скрипт:

  • Для одноразовой миграции с готовым модулем (Protobyte) — удобно и быстро.
  • Если структура сильно изменилась и нужны тонкие правила/идемпотентность — пишите собственный трансформер + используйте Sprint.Migration для фиксации изменений и отката.

Тестирование, безопасность и откат при импорте заказов

Как безопасно тестировать и откатывать:

  1. Среда
  • Работайте в копии нового сайта (стейдж). Никогда не импортируйте в продакшн без успешных тестов.
  • Делайте полный бэкап БД и файлов перед каждым массовым импортом.
  1. Dry‑run
  • Реализуйте режим dry‑run: скрипт выполняет все преобразования и логирует создаваемые SQL/объекты, но не выполняет записи.
  • На первом проходе импортируйте 10–100 заказов (выборка: разные статусы, разные покупатели, несколько товаров).
  1. Проверки после импорта на стейдже
  • Сравнить суммы: суммарная цена корзин vs корзины в экспортном JSON.
  • Контрольные выборки: открыть 20 случайных заказов, проверить позиции, статусы, даты.
  • Проверить привязки: у 100% заказов USER_ID должен совпадать с mapping-файлом.
  1. Откат
  • Храните mapping-файлы с перечнем созданных сущностей: users_created.json, orders_created.json. Для отката достаточно пройти по этому списку и удалить записи через API/модули.
  • Если импорт делался через миграции Sprint.Migration — используйте down() для отката.
  • В крайнем случае — восстановление из резервной копии БД.
  1. Preventions
  • Отключите рассылки/уведомления при импорте.
  • Временно отключите обработчики событий, которые могут менять данные (например, перерасчёт цен, автокомплектация адресов), или добавьте флаг IMPORT_MODE, на который обработчики ориентируются.

Типичные проблемы при переносе заказов и чек‑лист проверки

Частые сложности и как их решать:

  • Несовпадающие коды свойств инфоблоков — решается маппингом (properties_map) или созданием недостающих свойств на новом сайте.
  • Новые обязательные поля на новом сайте — заполнить дефолтами при трансформации или создать поле “import_note” и пометить для ручной доработки.
  • Статусы/способы доставки/оплаты с разными кодами — заранее создать соответствия и/или добавить недостающие справочники.
  • Товары не найдены по SKU — использовать XML_ID; если нет, создавать placeholder или откладывать позицию на ручную проверку.
  • Автоматический перерасчёт сумм — при импорте задавайте цены позиций явно и отключайте автоматические обработчики, иначе итоговые суммы могут отличаться.
  • Дублирование пользователей — решается строгим поиском по email/phone и записью UF_OLD_ID. Рекомендуется ручная проверка кейсов с коллизиями.
  • Проблемы кодировки/формата чисел и дат — нормализуйте (UTF‑8, точка в числах, Y-m-d H:i:s).

Чек‑лист перед полным импортом:

  • [ ] Сделан бэкап продакшн-базы
  • [ ] Отработан импорт на стейдж‑сайте
  • [ ] mapping-файлы актуальны и проверены
  • [ ] Логирование создания сущностей включено
  • [ ] Отключены уведомления и побочные обработчики
  • [ ] Подготовлен план отката (скрипт/резервная копия)

Источники

Заключение

Ключевая идея: подготовьте корректный маппинг и трансформатор JSON, импортируйте в порядке пользователи → товары → заказы и храните соответствия старый_id→новый_id (XML_ID или UF_OLD_ID). Такой рабочий подход к битрикс импорт и перенос заказов минимизирует дубли, сохраняет связи и даёт идемпотентность — вы сможете повторять импорт без риска создать дублирующие записи. Если хотите, пришлите экспортный JSON (или его фрагмент) — помогу составить properties_map и пример трансформера для вашего случая.

Авторы
НейроОтветы
Автор
Проверено модерацией
НейроОтветы
Модерация
Битрикс импорт заказов: миграция JSON с измененными инфоблоками