Как настроить обмен заказами между CRM и сайтом: поля, статусы и сроки

Какие данные заказа нужно передавать между сайтом и CRM

Главная ошибка при интеграции CRM и сайта — передавать либо слишком мало данных, либо всё подряд без правил. В первом случае менеджер всё равно вручную открывает админку сайта, во втором — обмен становится хрупким: меняется одно поле, и ломается весь сценарий обработки заказа.

Минимальный набор данных должен закрывать рабочую задачу: менеджер видит заказ в CRM, понимает состав покупки, связывается с клиентом, меняет статус, а сайт получает актуальное состояние заказа.

Обязательные поля заказа

В базовом обмене обычно передают:

• номер заказа на сайте;

• внешний ID заказа для CRM;

• дату и время создания заказа;

• ФИО клиента;

• телефон;

• email;

• состав заказа: товары, артикулы, количество, цена;

• итоговую сумму;

• скидку, промокод или бонусы, если они влияют на оплату;

• способ оплаты;

• статус оплаты;

• способ доставки;

• адрес доставки или пункт выдачи;

• комментарий клиента;

• комментарий менеджера, если он должен возвращаться на сайт;

• текущий статус заказа;

• источник заказа: сайт, мобильное приложение, маркетплейс, лендинг;

• UTM-метки, если CRM используется для оценки рекламы.

Если заказ может редактироваться после оформления, отдельно фиксируйте, какие поля разрешено менять в CRM. Например, менеджер может изменить количество товара, адрес доставки и комментарий, но не может менять технический ID заказа или сумму оплаченного заказа без отдельного сценария возврата/доплаты.

Поля клиента

Карточка клиента и карточка заказа — не одно и то же. Если обмен настроен неверно, в CRM появляются дубли клиентов: один и тот же человек создаётся по телефону, email и имени как три разные записи.

Для клиента стоит передавать:

• телефон в едином формате, например `+7XXXXXXXXXX`;

• email в нижнем регистре;

• имя, фамилию и отчество отдельными полями, если CRM это поддерживает;

• дату первого заказа;

• согласие на рассылку;

• источник первого обращения;

• ID клиента на сайте;

• ID клиента в CRM.

Главный идентификатор лучше выбирать заранее. На практике чаще всего используют телефон или внутренний ID клиента. Email не всегда надёжен: покупатель может указать рабочую почту, личную почту или случайный адрес только для получения чека.

Поля товаров и остатков

Если CRM участвует не только в обработке заказов, но и в учёте, нужно передавать данные по товарам аккуратно. В заказе должны быть не только названия товаров, но и стабильные идентификаторы:

• SKU или артикул;

• ID товара на сайте;

• ID товара в CRM или складской системе;

• название товара на момент заказа;

• цена на момент заказа;

• количество;

• ставка НДС, если она используется в документах;

• признак комплекта, услуги или цифрового товара.

Название товара нельзя использовать как основной ключ. Сегодня товар называется «Подписка Pro на 12 месяцев», завтра маркетолог переименует его в «Годовая подписка Pro», и обмен начнёт считать это разными позициями. Для синхронизации нужен стабильный ID или артикул.

Что не стоит передавать без необходимости

Не нужно включать в обмен все технические поля сайта только потому, что они есть в базе. Лишние поля усложняют поддержку и увеличивают стоимость переделок.

Обычно не стоит передавать:

• внутренние служебные флаги CMS, если они не нужны менеджерам;

• временные значения корзины после оформления заказа;

• технические токены оплаты;

• пароли, сессионные данные и чувствительные данные пользователя;

• черновики заказов, если бизнес-процесс их не обрабатывает;

• логи ошибок как часть карточки заказа.

Если нужны данные об оплате, передавайте статус и безопасные идентификаторы транзакции, а не полные платёжные реквизиты. Для большинства проектов достаточно полей: «ожидает оплаты», «оплачен», «частично оплачен», «возврат», «ошибка оплаты», «ID платежа».

Что зафиксировать в техническом задании

До разработки нужно описать не только список полей, но и правила обмена. В техническом задании стоит зафиксировать:

• направление передачи каждого поля: сайт → CRM, CRM → сайт или двусторонний обмен;

• обязательность поля;

• формат данных: строка, число, дата, справочник, массив товаров;

• допустимые значения;

• поведение при пустом значении;

• источник истины для спорных данных;

• правила обновления уже существующего заказа;

• обработку ошибок и повторную отправку.

Для тиража или проекта запросите 3 сметы: базовую, оптимальную и срочную; отдельно отметьте сроки 3–7 дней, гарантию и стоимость переделки. Для простой связки сайта и CRM стоимость часто начинается от 25 000–40 000 ₽, интеграция с нестандартными полями, доставкой, оплатой и журналом ошибок может стоить 80 000–180 000 ₽ и выше. Срочный запуск обычно дороже на 20–50%, потому что разработчик закладывает внеплановую нагрузку и ускоренное тестирование.

Как сопоставить статусы заказа без конфликтов

Статусы — самая конфликтная часть обмена. На сайте статусы нужны клиенту: он хочет понимать, принят заказ или уже отправлен. В CRM статусы нужны менеджеру: он ведёт продажу, проверяет оплату, связывается со складом, передаёт заказ в доставку. Если просто связать все статусы один к одному, быстро появятся противоречия.

Разделите клиентские и внутренние статусы

На сайте обычно достаточно короткой цепочки:

• новый;

• принят в работу;

• ожидает оплаты;

• оплачен;

• собирается;

• передан в доставку;

• выполнен;

• отменён.

В CRM статусов может быть больше:

• новый заказ;

• требуется звонок;

• клиент не ответил;

• ждём оплату;

• оплата получена;

• нет товара;

• согласование замены;

• на комплектации;

• передан в службу доставки;

• частичный возврат;

• полный возврат;

• закрыт успешно;

• закрыт с отказом.

Не каждый внутренний статус нужно показывать клиенту. Например, «клиент не ответил» можно оставить только в CRM, а на сайте продолжать показывать «принят в работу». Иначе покупатель увидит внутреннюю кухню и может неправильно понять ситуацию.

Составьте таблицу соответствия статусов

Перед разработкой удобно сделать простую карту:

В этой таблице важно не количество строк, а правила. Например, если заказ уже «выполнен», он не должен автоматически возвращаться в «новый» из-за повторной отправки старого события. Для этого используют проверку версии записи, время последнего изменения или запрет обратных переходов.

Защитите критические статусы

Некоторые статусы нельзя менять без условий:

• «оплачен» — только после подтверждения платёжной системы;

• «возврат» — только после отдельной операции возврата;

• «отменён» — с причиной отмены;

• «выполнен» — после закрытия доставки или ручного подтверждения;

• «нет товара» — после проверки остатков.

Если CRM и сайт меняют один и тот же статус одновременно, побеждать должен не последний по времени, а более авторитетный источник. Например, статус оплаты должен приходить от платёжного шлюза, а не от менеджера, если нет отдельного права на ручную корректировку.

Учитывайте ручные правки менеджеров

Ручные правки неизбежны: клиент попросил поменять адрес, заменить товар, перенести доставку, применить скидку. Поэтому в интеграции нужно определить, какие изменения возвращаются на сайт, а какие остаются только в CRM.

Хорошее правило: всё, что влияет на клиента, оплату, доставку или состав заказа, должно синхронизироваться и логироваться. Всё, что относится к внутренней работе отдела продаж, можно оставить только в CRM.

Сроки и частота синхронизации: онлайн, по расписанию или по событию

Частота обмена зависит от бизнес-процесса. Не всем нужен обмен каждую секунду. Иногда достаточно обновления раз в 10 минут, если менеджеры не обещают клиенту мгновенную обработку. Но если сайт показывает остатки, принимает онлайн-оплату и подключён к доставке, задержки становятся заметными.

Онлайн-синхронизация

Онлайн-синхронизация подходит, когда данные должны обновляться почти сразу после действия пользователя или менеджера. Обычно это делается через API и вебхуки: событие произошло на сайте — сайт отправил данные в CRM; статус изменился в CRM — CRM отправила событие обратно.

Плюсы:

• заказ быстро появляется в CRM;

• клиент быстрее видит новый статус;

• меньше ручной проверки;

• удобно для онлайн-оплаты и доставки.

Минусы:

• выше требования к стабильности API;

• нужна обработка недоступности CRM или сайта;

• обязательно нужны повторы отправки;

• сложнее тестировать конфликтные сценарии.

Для онлайн-обмена нормальной считается задержка от нескольких секунд до 1–2 минут. Если CRM временно недоступна, событие не должно теряться: его нужно положить в очередь и повторить отправку позже.

Синхронизация по расписанию

Обмен по расписанию запускается раз в определённый интервал: например, каждые 5, 10, 15 или 30 минут. Это проще в поддержке и часто достаточно для малого бизнеса.

Подходит, если:

• заказов немного;

• менеджеры не работают в режиме мгновенной реакции;

• нет критичных остатков в реальном времени;

• интеграция делается с CRM, где API имеет ограничения;

• нужно снизить стоимость разработки.

Примеры частоты:

• каждые 5 минут — для активного интернет-магазина;

• каждые 15 минут — для умеренного потока заказов;

• каждый час — для B2B-заявок или сложных заказов с ручной обработкой;

• один раз в сутки — только для отчётов, но не для оперативной обработки заказов.

Минус расписания — задержка. Если заказ оформлен в 10:01, а обмен идёт раз в 15 минут, менеджер может увидеть его только в 10:15. Для части бизнесов это нормально, для других — потеря конверсии.

Обмен по событию

Событийный обмен — практичный вариант для большинства проектов. Система отправляет данные не постоянно, а при конкретном действии:

• создан заказ;

• изменилась оплата;

• изменился статус;

• изменился состав заказа;

• добавлен трек-номер;

• заказ отменён;

• оформлен возврат.

Такой подход снижает лишнюю нагрузку и делает логику понятнее. Но нужно продумать, что делать, если событие не доставлено. Минимальный набор: очередь, повторная отправка, журнал ошибок и уведомление ответственному сотруднику.

Ограничения API и лимиты

У CRM и CMS могут быть ограничения: количество запросов в минуту, размер пакета, лимиты на создание сделок или контактов. Их нужно проверить до разработки.

Что уточнить у подрядчика или разработчика:

• сколько API-запросов делает один заказ;

• есть ли пакетная отправка заказов;

• что будет при ошибке 429 или превышении лимита;

• сколько раз повторяется неуспешная отправка;

• где хранится журнал синхронизации;

• можно ли вручную переотправить заказ;

• сохраняется ли исходный JSON/XML запроса для диагностики.

Для проектов со стабильным потоком заказов стоит закладывать SLA по обмену. Например: 95% заказов передаются в CRM за 2 минуты, 99% — за 10 минут, критические ошибки фиксируются в течение 4 рабочих часов. Это не банковская доступность, но понятная измеримая метрика для поддержки.

Критерии проверки обмена заказами перед запуском

Перед запуском нельзя ограничиваться проверкой «один тестовый заказ дошёл». Нужно пройти сценарии, которые реально произойдут в работе: оплата, отмена, изменение адреса, дубль клиента, недоступность CRM, повторная отправка, ручная правка менеджера.

Проверьте портфолио, техническое задание, смету, сроки, гарантию, порядок правок, поддержку и документы на материалы или услугу. В случае интеграции документами будут ТЗ, смета, договор, акт, регламент поддержки, описание API, доступы к тестовой среде и карта полей.

1. Проверка создания заказа

Создайте тестовый заказ на сайте и проверьте, что в CRM появились:

• правильный номер заказа;

• клиент с телефоном и email;

• все товарные позиции;

• цена каждой позиции;

• итоговая сумма;

• способ оплаты;

• способ доставки;

• комментарий клиента;

• источник заказа;

• UTM-метки, если они нужны.

Затем сравните данные в двух системах. Сумма заказа на сайте и в CRM должна совпадать до копейки. Если есть скидка, доставка или бонусы, они должны отображаться отдельными строками или понятными полями, а не теряться в общей сумме.

2. Проверка обновления статусов

Пройдите всю цепочку:

1. Новый заказ.

2. Ожидает оплаты.

3. Оплачен.

4. В работе.

5. Передан в доставку.

6. Выполнен.

7. Отменён или возврат — отдельным тестом.

На каждом шаге проверьте:

• изменился ли статус в нужной системе;

• не перезаписался ли статус старым значением;

• видит ли клиент корректное состояние в личном кабинете;

• ушли ли уведомления, если они подключены;

• сохранилось ли время изменения статуса.

Если заказ отменён в CRM, сайт не должен снова сделать его активным после следующей синхронизации. Это типовая ошибка, когда обмен по расписанию отправляет старое состояние без проверки приоритета.

3. Проверка дублей клиентов и заказов

Сделайте несколько заказов:

• с одним телефоном и разными email;

• с одним email и разными телефонами;

• с телефоном в формате `8XXXXXXXXXX` и `+7XXXXXXXXXX`;

• с повторной отправкой одного и того же заказа;

• с обновлением уже существующего заказа.

Правильный результат: CRM не создаёт лишние сделки и контакты, если заказ уже существует. Для этого в обмене должны использоваться внешние ID: ID заказа на сайте, ID клиента на сайте, ID сделки в CRM.

Если после теста в CRM появились три карточки одного клиента, интеграция не готова к запуску. После реального старта такие дубли быстро испортят аналитику, рассылки и историю покупок.

4. Проверка ошибок и повторов

Отключите тестовый доступ к CRM или временно заблокируйте отправку запроса. Затем оформите заказ и посмотрите, что произойдёт.

Нормальное поведение:

• заказ сохраняется на сайте;

• событие попадает в очередь;

• в журнале появляется ошибка;

• система повторяет отправку;

• ответственный сотрудник видит уведомление;

• после восстановления связи заказ можно отправить повторно без дубля.

Плохое поведение: заказ пропал, клиент оплатил, а менеджер ничего не видит. Именно поэтому журнал синхронизации — не дополнительная опция, а обязательная часть рабочей интеграции.

5. Проверка ручных изменений

Измените в CRM:

• адрес доставки;

• комментарий менеджера;

• статус заказа;

• состав заказа;

• скидку;

• трек-номер доставки.

Проверьте, какие изменения вернулись на сайт. Если клиент должен видеть трек-номер, он обязан появиться в личном кабинете или уведомлении. Если скидка изменила сумму к оплате, нужно проверить сценарий доплаты или возврата, а не просто поменять число в CRM.

6. Проверка нагрузки

Даже если сейчас заказов немного, протестируйте пакетную отправку. Минимум — 20–50 тестовых заказов подряд. Для активного магазина — 100–300 заказов в тестовом прогоне.

Смотрите на конкретные метрики:

• среднее время передачи заказа;

• максимальная задержка;

• количество ошибок;

• количество повторов;

• нагрузка на сайт;

• превышение лимитов API;

• время восстановления после сбоя.

Если обмен должен работать каждые 5 минут, тест должен показать, что пачка заказов успевает обработаться быстрее этого интервала. Иначе следующая синхронизация начнёт накладываться на предыдущую.

7. Проверка прав доступа

У интеграции должен быть отдельный технический пользователь или токен, а не личный аккаунт менеджера. Если сотрудник уволится или сменит пароль, обмен не должен остановиться.

Проверьте:

• кто владеет API-ключом;

• где он хранится;

• можно ли ограничить права только нужными сущностями;

• кто получает уведомления об ошибках;

• как быстро можно перевыпустить ключ;

• фиксируются ли действия интеграции в логах CRM.

Для цифровых сервисов это критично: одна неограниченная учётная запись может дать доступ не только к заказам, но и к клиентской базе, финансовым данным и внутренним комментариям.

Риски интеграции: дубли, потеря статусов и ручные правки

Интеграция заказов ломается не только из-за плохого кода. Чаще проблема возникает из-за неописанных правил: кто главный, что делать при конфликте, какие поля можно менять, где смотреть ошибку.

Типовые риски: нет ТЗ, размытые сроки, устные правки, скрытая стоимость материалов, неподходящий формат файлов или отсутствие поддержки. В цифровом проекте вместо «материалов» обычно выступают доступы, лицензии, платные модули, API-лимиты, формат выгрузки и документация CRM.

Дубли заказов

Дубли появляются, когда система не понимает, что заказ уже был передан. Причины:

• нет внешнего ID заказа;

• повторная отправка создаёт новую сделку;

• разные каналы создают похожие заказы;

• менеджер вручную создал сделку до прихода заказа с сайта;

• интеграция не проверяет существующие записи.

Как снизить риск:

• использовать неизменяемый ID заказа;

• хранить ID сделки CRM на стороне сайта;

• проверять заказ перед созданием;

• разрешить повторную отправку только как обновление;

• логировать каждую попытку синхронизации.

Потеря статусов

Статусы теряются, когда одна система перезаписывает другую без проверки. Например, CRM поставила «отменён», а сайт при следующем обмене отправил старое «ожидает оплаты». В итоге менеджер думает, что заказ закрыт, а клиент получает напоминание об оплате.

Защита:

• запрет обратных переходов для финальных статусов;

• приоритет источника для оплаты и отмены;

• хранение времени последнего изменения;

• журнал смены статусов;

• отдельная причина отмены или возврата.

Финальные статусы — «выполнен», «отменён», «возврат» — не должны меняться автоматически без отдельного правила.

Потеря данных при изменении заказа

Если менеджер меняет состав заказа в CRM, сайт должен понимать, что делать с оплатой, остатками и уведомлениями. Простое изменение суммы может привести к расхождению: клиент оплатил 5 000 ₽, а в CRM заказ уже на 5 800 ₽.

Для таких сценариев нужны правила:

• если сумма увеличилась — создаётся доплата;

• если сумма уменьшилась — оформляется частичный возврат или скидка;

• если товар заменён — сохраняется история замены;

• если адрес изменён — пересчитывается доставка;

• если заказ уже отгружен — изменение блокируется или требует подтверждения.

Ручные правки без журнала

Когда менеджеры могут менять всё без ограничений, расследовать ошибки почти невозможно. Через месяц никто не вспомнит, кто поменял статус и почему заказ ушёл клиенту дважды.

Нужны:

• журнал изменений;

• роли и права;

• комментарий к критическим действиям;

• отдельные права на отмену, возврат и изменение оплаты;

• уведомления о сбоях синхронизации.

Скрытая стоимость поддержки

Интеграция не заканчивается запуском. CRM обновляет API, сайт меняет модуль оплаты, добавляется новая доставка, бизнес просит новые статусы. Если поддержка не оговорена, каждая мелкая правка становится отдельным спором.

До старта уточните:

• сколько стоит час доработки: часто 1 500–4 000 ₽/час;

• есть ли минимальный платёж за обращение;

• входит ли исправление ошибок в гарантию;

• сколько стоит добавление нового поля;

• кто отвечает за изменения на стороне CRM;

• какие сроки реакции: 4 часа, 1 рабочий день или 3 рабочих дня.

Оптимально разделить работы: гарантийные ошибки, плановые доработки и срочные аварийные обращения. Тогда бизнес понимает, за что платит, а подрядчик не спорит по каждому изменению.

Когда такой вариант интеграции не подходит

Прямая связка «сайт — CRM» не всегда лучший вариант. Она может не подойти, если:

• у вас несколько сайтов, маркетплейсов и офлайн-точек;

• остатки ведутся в отдельной учётной системе;

• заказы проходят сложное производство или сборку;

• нужно обмениваться не только заказами, но и складом, закупками, возвратами;

• CRM не должна быть центром операционного учёта;

• требуется высокая отказоустойчивость и обработка тысяч заказов в сутки.

В таких случаях лучше рассматривать промежуточный слой: шину данных, отдельный сервис интеграции, ERP или учётную систему как главный источник. Это дороже на старте, но снижает хаос, когда каналов продаж становится больше.

Что может пойти не так при простом запуске:

• заказы с сайта приходят, а изменения из CRM не возвращаются;

• статусы доставки обновляются с задержкой;

• оплаченный заказ попадает в CRM как неоплаченный;

• менеджеры создают дубли вручную;

• при сбое API заказы не повторяются;

• после обновления модуля сайта обмен перестаёт работать;

• подрядчик не оставил инструкцию и журнал ошибок.

Если процесс критичен для продаж, не запускайте интеграцию сразу на всех заказах. Сначала прогоните тестовый контур, затем включите обмен на ограниченной группе заказов, затем переводите весь поток.

Чек-лист перед решением

Перед тем как утверждать разработку и запуск обмена заказами между CRM и сайтом, проверьте:

• есть техническое задание с картой полей;

• указано направление обмена для каждого поля;

• определён главный источник данных по оплате, статусам и клиенту;

• составлена карта соответствия статусов;

• описаны финальные статусы и запрет обратных переходов;

• выбрана частота синхронизации: онлайн, событие или расписание;

• известны API-лимиты CRM и сайта;

• есть очередь повторной отправки при ошибке;

• есть журнал синхронизации;

• можно вручную переотправить заказ без дубля;

• проверены тестовые заказы с оплатой, отменой и возвратом;

• проверены дубли клиентов по телефону и email;

• настроен отдельный технический пользователь для интеграции;

• доступы не завязаны на личный аккаунт менеджера;

• согласованы сроки запуска: например, 3–7 дней для простой связки и 2–4 недели для сложной;

• получены минимум 3 сметы: базовая, оптимальная и срочная;

• отдельно указана стоимость переделки и срочных работ;

• зафиксирована гарантия, например 14–30 дней;

• есть регламент поддержки после запуска;

• понятно, кто отвечает за сбои: подрядчик, штатный разработчик или администратор CRM.

Если хотя бы по статусам, дублям и журналу ошибок нет ответа, запуск лучше отложить. Иначе интеграция будет выглядеть готовой только в демонстрации, а в реальных заказах начнёт создавать ручную работу.

Какие поля заказа обязательно передавать из сайта в CRM?

Минимум: номер заказа, ID заказа, дата, клиент, телефон, email, товары, количество, цена, сумма, способ оплаты, статус оплаты, доставка, адрес, комментарий и текущий статус. Если CRM используется для маркетинга, добавьте источник заказа и UTM-метки.

Нужно ли передавать заказы из CRM обратно на сайт?

Да, если менеджеры меняют статус, адрес, доставку, трек-номер, состав заказа или сумму. Если CRM используется только для просмотра заявок, обратный обмен может не понадобиться, но это нужно явно зафиксировать в ТЗ.

Как часто синхронизировать заказы?

Для большинства проектов достаточно обмена по событию или каждые 5–15 минут. Онлайн-обмен нужен, если важны мгновенная оплата, остатки, доставка и быстрые уведомления клиента. Обмен раз в сутки подходит только для отчётов, а не для обработки заказов.

Что лучше: API, вебхуки или обмен файлами?

API и вебхуки лучше для оперативной синхронизации. Файлы CSV или XML подходят для простых периодических выгрузок, но хуже обрабатывают статусы, ошибки и повторы. Если заказов много, лучше использовать API с очередью и журналом ошибок.

Как избежать дублей заказов?

Используйте внешний ID заказа, храните ID сделки CRM, проверяйте существование заказа перед созданием и делайте повторную отправку как обновление, а не как новое создание. Также проверьте сценарий, когда менеджер создал сделку вручную.

Кто должен быть главным источником статуса?

Зависит от статуса. Оплату должна подтверждать платёжная система, сборку — CRM или склад, доставку — служба доставки, отмену — CRM или сайт по заданному правилу. Один общий «главный источник для всего» часто приводит к ошибкам.

Что делать, если CRM недоступна?

Заказ должен сохраниться на сайте, событие должно попасть в очередь, а система — повторить отправку после восстановления связи. В журнале должна быть видна ошибка, время попытки и результат повторной отправки.

Сколько стоит настройка обмена заказами?

Простая интеграция может стоить 25 000–40 000 ₽. Проект с нестандартными полями, статусами, оплатой, доставкой, журналом ошибок и тестовым контуром часто стоит 80 000–180 000 ₽ и выше. Срочная работа обычно дороже на 20–50%.

Сколько времени занимает настройка?

Простая связка при готовом API и понятном ТЗ может занять 3–7 рабочих дней. Сложный обмен с картой статусов, очередью, логами, доставкой и оплатой обычно занимает 2–4 недели, включая тестирование и исправления.

Нужен ли тестовый контур?

Да. Тестовый контур позволяет проверить оплату, отмену, дубли, статусы и сбои без риска для реальных заказов. Запуск сразу на рабочем сайте допустим только для очень простой формы заявки, но не для полноценного интернет-магазина.

Что должно быть в акте приёмки?

В акте или приложении к нему стоит указать, что настроены передача заказов, карта полей, карта статусов, журнал ошибок, повторная отправка, тестовые сценарии и инструкция. Иначе будет сложно доказать, что конкретная функция входила в работу.

Можно ли сначала запустить простой обмен, а потом доработать?

Можно, если сразу заложить внешние ID, понятные статусы и журнал ошибок. Если сделать временную интеграцию без этих основ, последующая доработка может превратиться в полную переделку. Для первого этапа лучше урезать количество полей, но не убирать контроль дублей и ошибок.