Короткий ответ: связывайте ученика с контактом, отдельный заказ — со сделкой, а оплату и доступ к обучению храните как самостоятельные состояния. Тогда повторная покупка не затрёт старую продажу, доплата не создаст вторую сделку, а открытый курс не станет ложным подтверждением поступления денег.
Ниже — рекомендуемая модель для школы, где менеджеры продают в amoCRM, а заказы и обучение ведутся в GetCourse. Это проектная схема, которую нужно проверить на своём аккаунте и выбранном коннекторе. Она не описывает готовую настройку любого виджета.
Сначала разделите четыре объекта
В GetCourse заказ описывает оформленное предложение и условия продажи. Покупка — отдельный объект, связанный с доступом к продукту: она может появиться после полной или частичной оплаты, а также ручного завершения заказа. Следовательно, наличие покупки само по себе не доказывает поступление всей суммы. Основание: документация GetCourse о заказах и покупках.
| Объект | На какой вопрос отвечает | Как предлагаем учитывать |
|---|---|---|
| Ученик | Кто покупает или учится? | Связка ID пользователя GetCourse и ID контакта amoCRM. Если платит родитель или компания, плательщика и ученика не объединять автоматически. |
| Заказ | Что и на каких условиях оформлено? | Отдельная сделка с ID заказа и составом предложения. Для стартовой модели — одна сделка на один заказ. |
| Платёж | Сколько поступило по конкретному заказу? | Отдельная запись в журнале обмена; в сделке — проверенная сумма оплат и остаток. Несколько платежей могут относиться к одному заказу. |
| Доступ | К какому продукту и до какого срока можно приступить? | Состояние по конкретной покупке или продукту. Не выводить его из этапа сделки или суммы бюджета. |
У этой модели есть границы. Если школа сначала ведёт консультацию, а заказ создаёт позднее, не нужно заводить вторую сделку автоматически: согласуйте, как новый ID заказа прикрепляется к уже открытой продаже. Если один заказ включает несколько курсов, одного поля «Доступ открыт» недостаточно — нужны сведения по каждому продукту либо ссылка на первоисточник.
Как связать GetCourse и amoCRM
- Определите начало маршрута. Заказ с сайта сначала возникает в GetCourse или менеджер создаёт его из amoCRM? Для каждого варианта запишите, кто создаёт объект и кто возвращает его ID. Два параллельных создателя одного заказа требуют отдельного правила согласования.
- Назначьте владельцев данных. В предлагаемой схеме GetCourse отвечает за состав заказа, сведения об оплате и доступе; amoCRM — за ответственного менеджера, следующий шаг и этап работы с клиентом. Обратное изменение разрешайте только для явно согласованных полей.
- Проверьте способ обмена. Готовый коннектор подходит, если передаёт нужные события и умеет обновлять существующую сделку. Для собственной интеграции GetCourse описывает callback через процесс и массовый экспорт по API; это разные механизмы. Официальное описание API.
- Проверьте исключения до покупки решения. Попросите показать доплату, повторный заказ того же ученика, ручной платёж, отмену и восстановление после ошибки. Общее обещание «двусторонней синхронизации» не отвечает на эти вопросы.
- Запустите ограниченный пилот. Выберите одно предложение, назначьте ответственного за сверку и только после контрольных примеров расширяйте обмен.
При собственной реализации callback отправляет данные через операцию «Вызвать URL». GetCourse отдельно предупреждает, что этот механизм не предназначен для массовой передачи; ошибки нужно обработать в соответствующей ветке процесса. Для начальной загрузки базы используйте подходящий экспорт, а для текущих изменений — проверенный маршрут событий. Настройка callback.
В API GetCourse массовый экспорт выполняется последовательно, с ограничениями числа запросов. Поэтому расписание сверки и допустимую задержку согласуйте с учётом действующей документации, а не обещания мгновенной синхронизации. Выбор технологии подробнее разобран в статье «Готовый коннектор или разработка API-интеграции».
Что передавать в сделку
Передавайте данные, которые нужны менеджеру для действия и позволяют найти первоисточник. В amoCRM API сделки предусматривает бюджет, этап, ответственного и дополнительные поля; конкретную карту полей необходимо настроить в аккаунте. Документация сделок amoCRM.
- Идентификаторы: аккаунт школы, ID заказа, ID пользователя, ссылка на заказ; на стороне обмена — соответствующие ID сделки и контакта.
- Предмет продажи: название и устойчивый идентификатор предложения, состав заказа, согласованная стоимость и валюта. Названия могут меняться, поэтому одного текста недостаточно для сопоставления.
- Деньги: сумма подтверждённых оплат, возвраты отдельным значением и остаток по согласованной формуле. Бюджет сделки обозначает стоимость продажи; не подменяйте его суммой последнего платежа.
- Обучение: продукт, состояние доступа, начало и окончание — только если эти сведения действительно доступны выбранному способу обмена. Не вычисляйте открытие доступа по факту оплаты.
- Контроль: когда сведения получены, результат последнего обмена и ссылка на ошибку для ответственного. Если актуальность неизвестна, так и показывайте её менеджеру.
Это требования к карте данных, а не утверждение, что любой коннектор отдаёт все перечисленные поля. Для каждого поля в задании укажите источник, получателя, правило пустого значения и разрешённое направление изменения. Если поле недоступно, оставьте ссылку на GetCourse и ручной контроль вместо выдуманного статуса.
Повторная покупка, доплата и продление
Не используйте правило «найти любую сделку по телефону и обновить». Оно смешивает разные продажи одного человека. В базовой модели новый заказ с новым ID получает новую сделку, связанную с существующим контактом; новый платёж по прежнему ID заказа обновляет прежнюю сделку. Перед связыванием проверяйте роль контакта: ученик и плательщик могут различаться.
Учебный пример. У ученика есть заказ №101 на основной курс. Первый и второй взносы относятся к заказу №101, поэтому обновляют одну продажу. Позже он оформляет заказ №208 на другой курс: это новая сделка у того же контакта. Если продление оформлено отдельным заказом, применяйте тот же принцип; если изменяется существующий объект, сначала зафиксируйте его связь с исходной продажей.
При замене предложения или переоформлении заказа не стирайте прежнюю историю. Запишите связь старого и нового заказов и решите, какой из них участвует в отчёте продаж. Сумму нельзя складывать дважды только потому, что в двух карточках осталась одинаковая стоимость.
Как не создавать дубли
Разделите две проверки: принадлежность объекта и повтор доставки. Для заказа используйте ключ «аккаунт GetCourse + ID заказа». Для пользователя — отдельный ключ с ID пользователя. Для платежа нужен устойчивый идентификатор платежа, если источник его предоставляет; сумма и дата сами по себе не гарантируют уникальность.
Если ID платежа недоступен, не прибавляйте сумму каждого уведомления к итогу. Согласуйте получение и запись актуального подтверждённого итога по заказу либо отправляйте неоднозначную операцию на сверку. Первый поиск контакта по email или телефону допустим как этап сопоставления, но несколько совпадений должны приводить к проверке, а не случайному выбору.
Обработчик должен переживать повтор одного сообщения и одновременные запросы. После потери ответа сначала проверьте, создана ли сделка, и только потом повторяйте создание. Запоздавшее уведомление «не оплачен» не должно затирать более свежую оплату: сравнивайте версию или время изменения источника, а при отсутствии надёжного признака сверяйте текущее состояние. Время получения сообщения не равно времени изменения заказа.
Эти требования относятся к реализации обмена; они не появляются автоматически от добавления поля с внешним ID. Общий механизм разобран в материале о дублях при повторных запросах.
Карта событий онлайн-школы
Ниже — заготовка для обсуждения с интегратором. Это бизнес-события, а не обещание готовых одноимённых триггеров GetCourse. Для каждой строки исполнитель должен назвать реальный источник сигнала, доступные поля, допустимую задержку и способ сверки. Если автоматического сигнала нет, фиксируется ручной или периодический контроль.
| Событие и источник | Действие в amoCRM | Что проверить |
|---|---|---|
| Создан заказ в GetCourse | Найти связь по ID; создать сделку или прикрепить заказ к существующей консультации по согласованному правилу. | Повтор доставки не создаёт вторую продажу; ответственный назначен. |
| Зафиксирован первый неполный платёж | Обновить сумму оплат и остаток; при необходимости поставить задачу на доплату. | Вся стоимость заказа не записана как полученные деньги; доступ проверяется отдельно. |
| Получена доплата | Обновить ту же сделку; проверить условие завершения продажи и актуальность задачи. | Не появилась новая сделка или повторная задача; итог совпадает с источником. |
| Появился новый заказ прежнего ученика | Создать самостоятельную продажу, сохранить связь с контактом. | Старая сделка, её сумма и история остались без изменений. |
| Заказ отменён или поступил запрос на возврат | Отразить состояние; назначить разбор. Факт возврата денег фиксировать отдельным подтверждением. | Отмена и запрос не представлены как уже выполненный возврат. |
| Изменён доступ к продукту | Обновить сведения о доступе либо задачу на проверку; не менять факт оплаты. | Сверены нужный продукт и срок; ограничение доступа не переписало продажу. |
| Обмен прервался или выявлено расхождение | Зафиксировать ошибку и ответственного; после восстановления повторить обработку безопасно. | Видны ID объекта и результат повтора; контрольная сверка закрыла расхождение. |
Почему статусы заказа и сделки могут отличаться
Этап amoCRM обычно отвечает на вопрос, что сейчас делает отдел продаж. Статус заказа описывает состояние заказа, а покупка — условия доступа. Совпадение названий не делает их одним и тем же показателем.
Например, школа может считать продажу состоявшейся после первого взноса, оставив контроль доплаты отдельной задачей. Тогда успешная сделка и неполная оплата не противоречат друг другу, если правило явно зафиксировано и отчёт не выдаёт бюджет сделки за полученные деньги. Если критерием успеха выбрана полная оплата, такой же результат уже будет ошибкой настройки.
В GetCourse автоматическое завершение заказа при оплате зависит от настройки предложения; бесплатное предложение также может завершаться без денежного поступления. У покупки может быть будущая дата начала доступа. Поэтому при расхождении сначала сравните ID заказа, оплаты, настройку завершения и конкретную покупку, затем время последнего обмена. Эти особенности описаны в указанных выше официальных материалах о заказах и покупках.
Как принять интеграцию
Проведите испытания на тестовых пользователях и согласованных тестовых заказах. Для платежей используйте разрешённый вашей платёжной схемой способ тестирования; не отмечайте реальные неоплаченные заказы оплаченными ради проверки.
- Создайте заказ, передайте его повторно и убедитесь, что в amoCRM осталась одна нужная сделка.
- Проверьте два взноса по одному заказу и отдельный заказ того же ученика: ожидаются две продажи, а не три.
- Проверьте бесплатное предложение и доступ с будущей датой: отсутствие денежного поступления и ещё не открытое обучение должны быть различимы.
- Разберите отмену, запрос возврата и подтверждённый возврат как разные контрольные ситуации.
- Смоделируйте недоступность получателя, повтор и нарушение порядка уведомлений: восстановление не должно создавать дубли или возвращать устаревшее состояние.
- Сверьте выбранный период по ID заказов: наличие сделок, стоимость, оплаты, возвраты и доступ. Используйте одинаковые фильтры, валюту и границы времени; сравнения одной общей суммы недостаточно.
Результат проверки — таблица «сценарий → ID объектов → ожидаемое → фактическое → исправление → повторный тест». У каждой оставшейся ошибки должен быть ответственный. Запуск можно принимать, когда согласованные сценарии проходят, расхождения объяснены, а команда умеет находить и повторно обрабатывать сбой.
Для настройки или восстановления такой связи передайте карту событий в проект интеграции CHECK CRM. По ней можно определить состав обмена, проверить подходящий модуль и согласовать мониторинг после запуска. Условия сопровождения и границы ответственности фиксируются отдельно.