Статья
практическое руководствоОбновлено: · Wapp.az
До соединения сайта с CRM и складом определите главный источник каждого вида данных. Сайт может принимать заказ, CRM — вести коммуникацию, а склад — контролировать остатки и сборку. Это пример распределения обязанностей, который зависит от возможностей программ. Сценарий ниже помогает спроектировать обмен и не является заявлением о результатах действующей клиентской интеграции.
Источник данных
Отдельно определите главную систему для артикула, цены, остатка и статуса заказа. Если остаток приходит со склада, уточните, что произойдет с ручной правкой на сайте после следующего обновления. Несогласованное изменение одного поля в двух системах создает расхождения. Постоянный артикул удобнее для связи записей, чем изменяемое название товара.
Путь учебного заказа
- Сайт принимает условный заказ S-001 и сохраняет коды товаров.
- CRM создает связанное обращение и определяет ответственного.
- Склад проверяет наличие и резервирует товар по согласованному правилу.
- Оплата и сборка получают статусы из своих источников.
- Сведения об отправке возвращаются на сайт для уведомления покупателя.
S-001 — вымышленный идентификатор для объяснения. Момент резервирования, например до оплаты или после нее, выбирается по правилам бизнеса.
Согласуйте значения статусов
«Закрыто» в CRM может означать согласованную продажу, а «завершено» на складе — отправленный товар. Не приравнивайте их автоматически. Опишите переходы между состояниями «новый», «ожидает оплаты», «собирается», «отправлен» и «отменен». Освобождение резерва после отмены и отправку уведомления проверяйте отдельно.
Что происходит при обрыве связи?
Отсутствие ответа не доказывает, что другая система не приняла заказ. Должны быть доступны сведения о попытке отправки, ответе и итоговом состоянии. Чтобы повторная передача не создавала новый заказ, нужен постоянный связующий идентификатор и согласованная обработка повторов. В задании укажите, кто увидит накопившиеся ошибки и когда должен вмешаться.
Набор проверок для приемки
- Заказ с одним и несколькими товарами.
- Неизвестный артикул и недостаточный остаток.
- Повторная отправка одного заказа.
- Поздний ответ и временная недоступность системы.
- Влияние отмены на резерв.
- Совпадение суммы, количества и состояний во всех системах.
Где заканчивается пример?
Публичная документация Finex помогает начать изучение интеграционных возможностей; функции конкретного аккаунта и условия доступа требуют отдельного подтверждения. Страница Finex API. Публичный каталог Timmybaby показывает представление товаров покупателю. Здесь не утверждается, что между этими сайтами работает интеграция. Для вашего проекта схема составляется по названиям систем, документации и списку передаваемых полей.
Материалы по теме
Дополнительная проверка перед решением
Различайте время последней успешной передачи и ожидающие операции. Общая отметка соединения не доказывает доставку конкретного заказа.
После исправления записи повторно проверьте именно ее. Убедитесь, что повторная обработка не изменила другие заказы.
Пример сценария
Пример приемки: принимающая система сохранила заказ, но ответ потерян. При повторной попытке должен распознаваться тот же идентификатор. Проверяются отсутствие повторной записи и повторного выполнения операции.
