В принципе организация взаимодействия с клиентом с помощью Bitrix24 устраивает практически полностью. В части визуализации вопросов нет совсем: все достаточно удобно и на своих местах.
Не нравится реализация привязки писем к сущностям CRM (контакты, компании, сделки) - то письмо не привязалось, то оно привязалось куда-то в другое место.
Ознакомившись с имеющимися в интернете вариантами решения схожих проблем
- https://blog.bedrosova.ru/2016/03/03/битрикс24-входящая-почта-без-единого-по/
- https://www.infospice.ru/blog/bitrix_inside/bitriks24-kp-crm-kak-sdelat-svoye-pravilo-dlya-obrabotki-pisem/
было принято решение написать свой обработчик, т.к. оказалось, что штатную логику привязки (функция CCrmEMail::EmailMessageAdd) изменить практически не возможно.
Кратко опишем затрагиваемые таблиц в БД для общего понимания процесса, ну и чтобы не забыть:
- b_mail_message - все письма сохраняются в эту таблицу, после получения из через IMAP.
- b_mail_mailbox - список почтовых ящиков.
- b_crm_act_comm - для каждого события прописываются параметры.
- b_mail_msg_attachment - вложения
- b_file - файлы (из вложений)
Что удалось получить в итоге
- Если находим контакт(ы) с нужным почтовым адресом - крепим письмо туда.
- Находим компанию у контакта - крепим письмо туда (дополнительно контролируем, чтобы ничего не задублировалось).
- Если в теме письма указан номер сделки в фигурных скобках [4384] - туда тоже крепим письмо.
- Если на момент получения \ написания письма контакта нет в CRM - не беда, обработаем, когда пользователь создаст контакт. Скрипт добавлен в CRON и обрабатывает последние 1000 писем.
- Что очень важно - мы не меняем исходный код продукта, что всегда позитивно сказывается как на обновлениях, так и на безболезненном отказе от использования текущей схемы.
Особенности
- Почему-то не сохраняются вложения, если нет правила обработки ящика. Даже пустого. Пришлось насоздавать для каждого ящика пустое правило обработки.
- Не у всех вложений корректно переносятся наименования, также по какой-то неведомой логике вложение имеет наименование в виде хэша без расширения файла, хотя в таблице b_mail_msg_attachment корректное наименование присутствует - пришлось добавить функцию принудительного переименования файла как в БД, так и в файловой системе.
- У нас в компании практически у всех почт существуют алиасы, например, petrov.a@ будет еще иметь короткий адрес pa@ - эту информацию решил записывать в описание почтового ящика, столбец DESCRIPTION (нужна для определения направления письма).
- Если в БД у почтового ящика USER_ID поставить 0, то ящик будет считаться системным. Решил, что ящики должны быть системными и ID пользователя перенес в столбец LINK.
Логика работы
- Проверяем есть ли необработанные письма.
- Определяем направление коммуникации.
- Ищем контакты \ компании с совпадающим адресом электронной почты.
- Добавляем во все контакты и связанные компании событие с письмом.
- Обновляем EXTERNAL_ID у письма, чтобы больше его не обрабатывать (записываем туда ID события, больше нужно для отладки).
Финал
___
Добавляем скрипт в cron, забываем о его существовании и наслаждаемся результатом.
Оригинал статьи и ссылка на исходный код доступны по ссылке: https://alyssia.ru/bitrix24-mail-attach/
Занимаемся сложными интеграциями. Почта для связи - sales@alyssia.ru.