Функционал обновления сущностей по ID

Часто стоит задача не создавать новые сущности, а находить имеющиеся. Допустим, для их обновления или, к примеру, чтобы найдя существующий контакт и добавить к нему сделку.

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

Первый способ — это работа через поиск дублей, она подробно описана в отдельной инструкции.

Второй вариант — поиск по внутреннему ID сущности. Ключевым моментом здесь является понятие внутренний ID — идентификатор который этой сущности назначила сама система внутри которой происходит поиск.

Пример платформ, предоставляющих такой функционал:

• amoCRM: Найти сделку по ID, Обновить сделку по ID;
• Битрикс24: Найти сотрудника по ID, Обновление сделки по ID, Найти контакт по ID, Найти счёт по ID, Найти сделку по ID;
• RetailCRM: Поиск пользователя по ID, Обновить заказ по ID;
• Мегаплан: Получить клиента по ID;
• МойСклад: Обновить заказ по ID.
• U-ON: Добавление напоминания в заявку

*Список является неполным и может изменяться.

Пример распространенной ошибки

Часто при настройке данного функционала встречаются ошибки вроде этой:

Выше мы видим, как в поисковый запрос для amoCRM, передается ID из Tilda, в то время как amoCRM ожидает получить свой внутренний ID.

Если в отдающем сервисе не содержатся внутренние ID принимающей стороны, то поиск следует осуществлять по номеру телефона, названию, email, и прочим пересекающимся параметрам, воспользовавшись, упомянутом выше, «первым способом».

Корректное использование поиска по ID

Как вы уже поняли, для поиска по ID внутри принимающей системы, отдающий сервис должен хранить его в отдельном поле. Сценарии могут быть разными. Например, многие складские системы по умолчанию имею такое поле — “внешний ID”. Если подходящего поля нет, создайте кастомное именно под эту задачу. Также, можно сохранять внешний ID в качестве названия сущности.

Разберем последний вариант на кейсе, когда два подразделения одной фирмы работают в разных CRM-системах: отдел продаж в amoCRM а техническая служба в Битрикс24.

Этап I

При переводе сделки в amoCRM на определенный этап менеджером, создаются контакт и сделка в Битрикс24 для инженеров:

При этом, на 3м шаге, создавая сделку в Битрикс24, мы передаем в ее название ID сделки из amoCRM:

В дальнейшем, когда инженеры выполнят свою часть работы и переведут сделку в Битрикс24 в определенный статус, такое название позволит нам найти соответствующeю сделку в amoCRM, так как никаких других пересекающихся значений сделка из Битрикс24 содержать не будет.

Этап II

Итак, мы получили из Битрикс24 сделку в нужном статусе и теперь хотим обновить сделку на стороне amoCRM:

Здесь нам и пригождается название сделки Битрикс24, состоящее из внутреннего ID amoCRM. По нему будет найдена нужная сделка а в остальных полях мы указываем, какие именно значения нужно перезаписать. В этом примере мы обновляем статус в amoCRM:

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

Заключение

Мы разобрали пример обновления сущности по ID. Использования этой функции для других сервисов будет аналогичным. Главное, чтобы выполнялось два правила:

• В поисковый запрос вставляется внутренний ID системы в которой мы ищем нужную сущность.
• Сервис который отдает информацию, должен содержать, в числе прочего, внутренний ID системы в которой мы ищем нужную сущность.