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

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

Где находится источник истины

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

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

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

Как системы узнают один и тот же объект

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

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

Какое событие запускает обмен

«Передавать заказы» — слишком общее описание задачи. Нужно уточнить момент передачи: оформление, подтверждение оплаты или другое согласованное событие.

Для одной выбранной операции полезно записать:

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

Так бизнес-решения не останутся неявными предположениями разработчика.

Что делать с исключениями

Основной маршрут — только часть процесса. До запуска стоит разобрать отмену заказа, частичный возврат, отсутствие соответствия для товара и временную недоступность одной из систем.

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

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

Когда таблица действительно полезна

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

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

Источник и границы примера

В качестве тематического источника использован кейс Josie Maran об интеграции в e-commerce, подготовленный APPSeCONNECT: https://www.appseconnect.com/wp-content/uploads/2022/09/Josie-Maran-Success-Story.pdf

Это материал поставщика, а не независимая оценка. Приведённые выше вопросы — рекомендации для проектирования обмена, а не описание внутреннего процесса Josie Maran. Численные показатели эффекта не используются; упомянутая платформа не является заранее выбранной рекомендацией для внедрения в РФ.

Напишите «ЗАВОД» — разберём одну повторяющуюся операцию.