Интеграции и миграция в YetiForce: почта, телефония, 1С и переезд с amoCRM без потери базы

Почта — самая сильная встроенная интеграция YetiForce

Когда меня спрашивают, с чего начинать внедрение YetiForce, я всегда отвечаю одинаково: с почты. Это единственная интеграция, которая в YetiForce работает из коробки на уровне зрелого продукта, а не заготовки. В системе есть полноценный почтовый клиент — модуль Mail, — которым менеджер реально пользуется вместо Outlook, и есть сканер IMAP (Mail Scanner), который в фоне разбирает входящие письма и сам привязывает переписку к нужному контакту, организации, сделке или тикету. Для отдела продаж это означает, что вся история общения с клиентом лежит в карточке, а не растекается по личным ящикам сотрудников.

Разберу, как это настраивается на практике. Почтовый клиент подключается к корпоративному ящику по стандартным протоколам. Для приёма писем это IMAP, для отправки — SMTP, и я категорически рекомендую только защищённые порты. На большинстве российских почтовых серверов и у облачных провайдеров это IMAP на порту 993 с SSL/TLS и SMTP на порту 465 (SSL) либо 587 (STARTTLS). Настройка YetiForce IMAP почты делается в два приёма: сначала личный ящик менеджера в модуле Mail, затем — служебный ящик для сканера в разделе Mail Scanner, который и делает всю автоматику.

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

Автосоздание тикетов из писем для сервисного контура

Отдельно ценно то, что сканер умеет не просто привязывать письма, а создавать из них тикеты в модуле поддержки (HelpDesk). Это закрывает типовой сценарий сервисной компании: клиент пишет на support@, и в CRM автоматически рождается заявка, привязанная к его организации, с темой письма в заголовке и телом в описании. Дальше письмо в той же цепочке подклеивается к существующему тикету, а не плодит новые — сопоставление идёт по идентификаторам письма и по номеру заявки в теме.

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

Грабли: самоподписанные сертификаты и большие ящики

Теперь честно про то, где спотыкаются почти все. Первая и самая частая беда — самоподписанные или неполные (без промежуточной цепочки) SSL-сертификаты на почтовом сервере клиента. PHP-расширение IMAP по умолчанию проверяет сертификат, и при кривом сертификате соединение просто не устанавливается, а в интерфейсе вы видите невнятную ошибку подключения. Правильный путь — привести сертификат в порядок (Let's Encrypt закрывает вопрос бесплатно). Костыльный путь, к которому иногда приходится прибегать на внутренних серверах, — явно ослабить проверку в строке подключения, и это надо понимать как осознанный компромисс, а не норму.

Вторая грабля — большие и старые ящики. Если натравить сканер на ящик с десятками тысяч писем и историей за годы, первый проход может идти часами и создавать заметную нагрузку на сервер, а при неудачных настройках PHP — падать по таймауту или памяти. Я всегда начинаю сканирование с ограниченного интервала (например, письма за последний месяц), убеждаюсь, что привязка идёт корректно, и только потом расширяю глубину. И обязательно выношу запуск сканера в системный cron, а не полагаюсь на запуск из веб-интерфейса.

Пример строки подключения к ящику по IMAP через защищённый порт — именно в таком виде параметры уходят в настройки модуля Mail и сканера:

Сервер IMAP:   mail.company.ru
Порт:          993
Шифрование:    SSL/TLS
Логин:         crm-scanner@company.ru
Папка:         INBOX

Сервер SMTP:   mail.company.ru
Порт:          465
Шифрование:    SSL

# Запуск сканера по расписанию (crontab пользователя веб-сервера),
# каждые 5 минут, отдельно от общего планировщика YetiForce:
*/5 * * * * /usr/bin/php /var/www/yetiforce/vendor/bin/... mailscanner >> /var/log/yf-mailscanner.log 2>&1

REST API и Webservice: фундамент всех интеграций

Если почта — это витрина, то REST API — это несущая стена, на которой держатся все остальные интеграции YetiForce. Всё, для чего нет готового модуля (а для российских сервисов готового нет почти ничего), делается через YetiForce API. Поэтому разобраться в нём стоит до того, как вы вообще начнёте планировать интеграции.

Механика такая. В системе есть приложение Webservice (Web service app), где заводятся ключи приложений — по сути, учётные записи для внешних систем. Каждому ключу назначается пользователь и роль, а значит, внешняя интеграция работает ровно с теми правами, что и обычный сотрудник: видит те модули и записи, что разрешены его ролью, и не видит остального. Это правильная модель — я всегда завожу отдельного технического пользователя под каждую интеграцию (сайт, 1С, телефония), чтобы по логам было видно, кто именно создал запись, и чтобы можно было отозвать один ключ, не сломав остальные.

Аутентификация двухступенчатая: сначала логин по учётным данным технического пользователя и ключу приложения — в ответ приходит токен сессии, — затем все последующие запросы идут с этим токеном в заголовке. Дальше вы работаете с сущностями через единый набор операций: получить список записей модуля, получить одну запись, создать, обновить, удалить. Названия модулей в API совпадают с системными: Leads (лиды), Contacts (контакты), Accounts (организации), Potentials (сделки), HelpDesk (тикеты).

Вот типовой сценарий, ради которого API внедряют в первую очередь: форма на сайте отправляет заявку, промежуточный обработчик кладёт её в YetiForce как лид, сохраняя UTM-метки в кастомные поля. Пример создания лида через REST API (после того как токен уже получен предыдущим запросом):

curl -X POST 'https://crm.company.ru/webservice/Leads/Record/' \
  -H 'x-api-key: 3f9c1a7e8b2d4c6f0a1b2c3d4e5f6071' \
  -H 'x-token: 9a8b7c6d5e4f30211a2b3c4d5e6f7080' \
  -H 'Content-Type: application/json' \
  -d '{
        "lastname": "Заявка с сайта",
        "company": "ООО Ромашка",
        "phone": "+7 495 000-00-00",
        "email": "info@romashka.ru",
        "leadsource": "Website",
        "cf_utm_source": "yandex",
        "cf_utm_medium": "cpc",
        "cf_utm_campaign": "crm-vnedrenie",
        "assigned_user_id": "19x7"
      }'

# Ответ: {"success":true,"result":{"id":"11x2451", ... }}

Обратная задача — выгрузка сделок, например для отчётности или для передачи в 1С, — делается запросом на получение списка записей модуля Potentials с фильтром и постраничной навигацией. Забирать всё одним запросом нельзя: API отдаёт данные страницами, и вы листаете их, пока не кончатся записи:

curl -X GET 'https://crm.company.ru/webservice/Potentials/RecordsList' \
  -H 'x-api-key: 3f9c1a7e8b2d4c6f0a1b2c3d4e5f6071' \
  -H 'x-token: 9a8b7c6d5e4f30211a2b3c4d5e6f7080'
# В ответе — массив записей и общее число; следующую страницу
# запрашивают, передавая смещение/номер страницы в параметрах.

Телефония: Asterisk, FreePBX и облачные АТС

Телефония в YetiForce исторически строится вокруг Asterisk — встроенный модуль PBX именно на него и рассчитан. Что даёт связка: при входящем звонке у менеджера всплывает карточка звонящего с его контактом и открытыми сделками, работает click-to-call (клик по номеру в карточке инициирует вызов через АТС), а после разговора в CRM остаётся запись о звонке с длительностью и — если АТС отдаёт файл — ссылкой на запись разговора.

С self-hosted решениями на базе Asterisk/FreePBX это заводится относительно предсказуемо. Схема стандартная: на стороне АТС настраивается отправка событий о звонках (через AMI — интерфейс управления Asterisk — или через веб-хуки FreePBX), YetiForce принимает эти события и сопоставляет номер с базой контактов. У нас в проектах связка YetiForce Asterisk телефония с FreePBX поднималась без экзотики: базовый функционал всплывающей карточки и логирования звонков завёлся на штатном модуле, а вот сопоставление внутренних номеров сотрудников с пользователями CRM и корректную обработку переводов звонка пришлось донастраивать вручную — из коробки многосторонние сценарии учитываются не полностью.

С российскими облачными АТС (Манго, Телфин, UIS и подобными) ситуация иная: встроенный модуль их напрямую не понимает, потому что у каждого провайдера свой формат веб-хуков и свой API. Здесь мы идём через тот самый REST API YetiForce: пишем небольшой промежуточный обработчик, который принимает веб-хук от облачной АТС, нормализует его в понятный вид и создаёт/обновляет запись о звонке в CRM, а для click-to-call дёргает API провайдера. Для одной российской облачной АТС нам пришлось дописать именно такой адаптер — примерно на два-три человеко-дня работы, включая разбор недокументированных нюансов формата событий.

Итого по телефонии — честная развилка:

• Свой Asterisk/FreePBX — встроенный модуль PBX, минимум доработок, полный контроль над записями разговоров, но нужен инженер, который поднимет и будет сопровождать АТС.
• Российская облачная АТС — готовой интеграции нет, требуется адаптер через API (несколько человеко-дней), зато не надо держать свою телефонную инфраструктуру.

Обмен с 1С: реальность без розовых очков

Здесь я сразу снимаю розовые очки, потому что на этом месте чаще всего рушатся ожидания. Готового коробочного коннектора YetiForce 1С интеграция в природе не существует. Это не Битрикс24 с его штатным модулем обмена — YetiForce про такое даже не заявляет. Любой обмен с 1С здесь проектируется и пишется под конкретную задачу, и делается он через REST API с обеих сторон: со стороны YetiForce — его Webservice, со стороны 1С — публикация HTTP-сервиса или OData-интерфейс информационной базы.

Рабочая архитектура, которую мы применяем, выглядит так: между 1С и YetiForce ставится промежуточный скрипт-синхронизатор на отдельном VPS. Он по расписанию забирает данные из 1С (контрагенты, счета, статусы оплат), приводит их к формату CRM и заливает через API YetiForce, а обратно — переносит из CRM то, что нужно 1С (например, новые сделки и контрагентов из лидов, дошедших до оплаты). Промежуточный слой нужен именно потому, что напрямую сшивать боевую 1С с CRM рискованно: скрипт-посредник даёт буфер, логирование, повторные попытки и место, где живёт вся логика сопоставления.

Ключевой принцип, без которого обмен превращается в генератор дублей, — идемпотентность. Каждая операция синхронизации должна быть безопасна при повторе: если скрипт отработал дважды (а он рано или поздно отработает дважды — из-за сбоя сети, таймаута, перезапуска), результат должен быть тем же, что и при однократном запуске. Для контрагентов юрлиц естественный ключ идемпотентности — связка ИНН+КПП: перед созданием организации в CRM скрипт ищет её по ИНН+КПП и, если находит, обновляет, а не плодит вторую. Для физлиц и ИП ключом обычно берём ИНН плюс телефон или e-mail.

# Псевдокод скрипта-синхронизатора 1С -> YetiForce
# Запускается по cron, идемпотентен по ИНН+КПП

for contragent in one_c.get_contractors(changed_since=last_run):
    inn = contragent["ИНН"]
    kpp = contragent.get("КПП", "")     # у ИП/физлиц КПП пустой
    key = inn + "|" + kpp

    # Ищем организацию в YetiForce по естественному ключу
    found = yf_api.query("Accounts", filter={"cf_inn": inn, "cf_kpp": kpp})

    payload = {
        "accountname": contragent["Наименование"],
        "cf_inn": inn,
        "cf_kpp": kpp,
        "phone":  contragent["Телефон"],
        "assigned_user_id": DEFAULT_MANAGER,
    }

    if found:
        yf_api.update("Accounts", found[0]["id"], payload)   # обновляем
    else:
        yf_api.create("Accounts", payload)                   # создаём один раз

    log(key, "ok")

save_last_run(now())   # следующий запуск возьмёт только изменившееся

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

• 1С → CRM (выгрузка): контрагенты и счета уезжают в CRM по расписанию, менеджеры видят актуальные документы и суммы. Самый частый и самый безопасный сценарий.
• CRM → 1С (загрузка): из CRM в 1С уходят выигранные сделки и новые контрагенты, чтобы бухгалтерия выставила счёт. Требует аккуратной валидации на стороне 1С.
• Статусы оплат 1С → CRM: обратный тонкий канал — только признак «счёт оплачен» и дата, чтобы воронка в CRM отражала реальные деньги. Дёшево и очень полезно.

Когда проще ограничиться односторонней выгрузкой? Если 1С остаётся единственным источником истины по деньгам и документам (а так почти всегда и есть), а CRM нужна для работы с воронкой — берите выгрузку из 1С в CRM плюс тонкий обратный канал статусов оплат. Полноценную двустороннюю синхронизацию имеет смысл затевать, только когда менеджеры реально создают контрагентов и счета в CRM, а не в 1С.

Миграция с amoCRM и Битрикс24: пошаговый план

Переезд с облачной CRM — это отдельный жанр, где цена ошибки высока: можно потерять историю, наплодить дубли и получить недоверие менеджеров к новой системе с первого дня. Расскажу, как мы делаем миграцию с amoCRM и переезд с Битрикс24 на open source, чтобы этого избежать. Общая канва — пять этапов, и я их прохожу именно в таком порядке.

Этап 1. Экспорт: что отдаёт API и что не отдаёт

И amoCRM, и Битрикс24 позволяют выгрузить основные сущности через API: сделки, контакты, компании, задачи, примечания, поля, справочники стадий. Это хорошая новость. Плохая новость — часть данных выгружается неполно или не выгружается вовсе, и об этом надо знать заранее, до обещаний заказчику.

Вывод, который я всегда проговариваю с заказчиком до старта: чистые структурированные данные (контакты, компании, сделки) переезжают хорошо; сквозная история переписки, звонков и полный аудит изменений — переезжают плохо или никак. Если история критична, старую систему держат в архивном доступе на чтение ещё несколько месяцев после переключения.

Этап 2. Маппинг полей и воронок

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

Отдельно про воронки: в amoCRM и Битрикс24 стадий часто наплодили десятки, половина из которых дублирует смысл или давно не используется. Миграция — идеальный повод навести порядок: мы вместе с отделом продаж сводим стадии к рабочему минимуму и фиксируем сопоставление старых стадий с новыми. Кастомные поля создаём в YetiForce заранее и с правильными типами (число, дата, список, справочник), иначе импорт свалит всё в текст.

Этап 3. Импорт в YetiForce: CSV против API

Дальше развилка по способу заливки. Штатный CSV-импорт хорош для простых и средних объёмов и для сущностей без сложных связей: справочники, контакты, компании. Он нагляден, его видит и контролирует сам заказчик. Но у него есть потолок: большие файлы и связи между записями (сделка ссылается на компанию, которая ещё не загружена) он тянет плохо. Для больших и связанных переносов мы заливаем через API — скриптом, который грузит данные в правильном порядке (сначала организации, потом контакты, потом сделки со ссылками на уже созданные записи) и умеет повторять упавшие пачки.

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

# MariaDB (my.cnf) — иначе большие пакеты данных обрываются:
max_allowed_packet = 128M

# php.ini — иначе большой CSV не загрузится и импорт упадёт:
post_max_size      = 100M
upload_max_filesize = 100M
max_input_vars     = 10000

# после правки — перезапустить MariaDB и PHP-FPM/веб-сервер

Этап 4. Дедупликация и выверка

Финальный и самый недооценённый этап. После заливки данные надо свести и проверить, иначе новая CRM стартует с дублями и дырами. Дедупликацию делаем по устойчивым ключам: организации — по ИНН (а лучше ИНН+КПП), контакты — по телефону и e-mail, приведённым к единому формату (телефон в +7XXXXXXXXXX, e-mail в нижний регистр). Совпадения сливаем, сохраняя самую полную версию записи и все связи.

Выверку строим на контрольных цифрах «до и после». Мы фиксируем в старой системе количество контактов, компаний, активных сделок и их суммарную сумму по воронке — и сверяем ровно те же цифры в YetiForce после миграции. Расхождение больше пары процентов — сигнал искать потерю. Только когда цифры сошлись и отдел продаж подтвердил, что их клиенты и сделки на месте, переходим к пятому этапу — переключению: старая система переводится в режим только для чтения, работа начинается в YetiForce.

Миграция с vtiger и Excel

Два особых случая, которые встречаются постоянно. С vtiger переезд идёт мягче, чем с облаков, — и это не случайно: YetiForce вырос из кода vtiger, поэтому модель данных у них родственная, названия сущностей и логика похожи. Но не обольщайтесь: перенести базу «в лоб», подсунув дамп чужой БД, не выйдет. Версии за годы разошлись так сильно, что структуры таблиц несовместимы, и попытка залить старый дамп в новую схему кончится испорченной базой. Переезд с vtiger всё равно идёт через выгрузку и загрузку данных — CSV для простого, API для сложного, — просто маппинг полей получается почти очевидным, а не мучительным, как с амо.

С Excel (и любыми выгрузками в таблицы из самописных учёток) картина обратная: технически залить проще некуда, а вся настоящая работа — до импорта, в нормализации справочников. Именно на грязных таблицах разбивается большинство самостоятельных миграций. Вот мой чек-лист подготовки таблиц перед импортом:

• Одна сущность — один лист/файл: отдельно компании, отдельно контакты, отдельно сделки. Смешанные простыни не импортируются.
• Заголовки колонок — в одну строку, латиницей или понятными именами, без объединённых ячеек и «шапок» на пол-листа.
• Телефоны — к единому формату +7XXXXXXXXXX, лишние символы и вторые номера — в отдельную колонку.
• ИНН/КПП — текстовым форматом, иначе Excel срежет ведущие нули и превратит их в экспоненту.
• Даты — в один формат (ГГГГ-ММ-ДД), без «вчера» и текстовых пометок в ячейке даты.
• Справочники (стадии, источники, типы) — свести к конечному списку значений и выверить орфографию: «Ндс», «НДС», «ндс» для системы это три разных значения.
• Кодировка файла — UTF-8, разделитель — согласован с настройками импорта, иначе кириллица приедет «кракозябрами».
• Удалить пустые строки, тестовые записи и явный мусор — в CRM это переносить незачем.

Правило простое: сколько времени вложите в нормализацию таблиц до импорта, столько сэкономите на разгребании дублей и битых записей после. По моему опыту, на грязных Excel-выгрузках подготовка занимает больше времени, чем сама заливка.

Каких интеграций нет и что с этим делать

Финальная и самая честная секция. YetiForce — европейский продукт, и готовых модулей под российские сервисы в нём нет. Нет коннекторов к СБИС и Контуру, нет интеграции со службами доставки вроде СДЭК, нет штатных каналов WhatsApp и Telegram. Всё это либо делается через API соответствующего сервиса и API YetiForce, либо дописывается как доработка. Это не приговор — это природа продукта, и её надо принять до внедрения, а не обнаружить после.

Чтобы разговор был предметным, приведу ориентировочную трудоёмкость типовых доработок из нашей практики. Цифры усреднённые — конкретика зависит от API сервиса и требований, — но порядок величин честный:

Отсюда главный вывод про YetiForce интеграции, который я повторяю каждому клиенту на старте: YetiForce — это не готовое решение «включил и работает», а мощный конструктор для команды с руками. У него отличная бесплатная база (полноценная почта, зрелый REST API, гибкая ролевая модель, ERP-функции), но всё, что касается стыковки с российской экосистемой, вы либо делаете сами, либо отдаёте подрядчику. И это, кстати, нативный сценарий: YetiForce с его открытым кодом и API изначально рассчитан на то, что интеграции под него допиливают под конкретный бизнес, а не покупают в маркетплейсе.

Мой практический совет по выбору: если у вас есть или будет технический партнёр, готовый сопровождать доработки, — YetiForce даёт огромную свободу и нулевую лицензионную стоимость. Если же вам нужно «чтобы всё из коробки и с российскими сервисами сразу» и своей технической команды нет — трезво оцените бюджет на подрядчика, потому что экономия на лицензии частично уйдёт в разработку интеграций. Зато результат вы контролируете полностью и ни от какого вендора не зависите.